summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-04-04ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()Alexey Kodanev
Add 'connected' parameter to ip6_sk_dst_lookup_flow() and update the cache only if ip6_sk_dst_check() returns NULL and a socket is connected. The function is used as before, the new behavior for UDP sockets in udpv6_sendmsg() will be enabled in the next patch. Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04ipv6: add a wrapper for ip6_dst_store() with flowi6 checksAlexey Kodanev
Move commonly used pattern of ip6_dst_store() usage to a separate function - ip6_sk_dst_store_flow(), which will check the addresses for equality using the flow information, before saving them. There is no functional changes in this patch. In addition, it will be used in the next patch, in ip6_sk_dst_lookup_flow(). Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04net: phy: marvell10g: add thermal hwmon deviceRussell King
Add a thermal monitoring device for the Marvell 88x3310, which updates once a second. We also need to hook into the suspend/resume mechanism to ensure that the thermal monitoring is reconfigured when we resume. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04pptp: remove a buggy dst release in pptp_connect()Eric Dumazet
Once dst has been cached in socket via sk_setup_caps(), it is illegal to call ip_rt_put() (or dst_release()), since sk_setup_caps() did not change dst refcount. We can still dereference it since we hold socket lock. Caugth by syzbot : BUG: KASAN: use-after-free in atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline] BUG: KASAN: use-after-free in dst_release+0x27/0xa0 net/core/dst.c:185 Write of size 4 at addr ffff8801c54dc040 by task syz-executor4/20088 CPU: 1 PID: 20088 Comm: syz-executor4 Not tainted 4.16.0+ #376 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x1a7/0x27d lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x23c/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x137/0x190 mm/kasan/kasan.c:267 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278 atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline] dst_release+0x27/0xa0 net/core/dst.c:185 sk_dst_set include/net/sock.h:1812 [inline] sk_dst_reset include/net/sock.h:1824 [inline] sock_setbindtodevice net/core/sock.c:610 [inline] sock_setsockopt+0x431/0x1b20 net/core/sock.c:707 SYSC_setsockopt net/socket.c:1845 [inline] SyS_setsockopt+0x2ff/0x360 net/socket.c:1828 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x4552d9 RSP: 002b:00007f4878126c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007f48781276d4 RCX: 00000000004552d9 RDX: 0000000000000019 RSI: 0000000000000001 RDI: 0000000000000013 RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000 R10: 00000000200010c0 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000000526 R14: 00000000006fac30 R15: 0000000000000000 Allocated by task 20088: save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3542 dst_alloc+0x11f/0x1a0 net/core/dst.c:104 rt_dst_alloc+0xe9/0x540 net/ipv4/route.c:1520 __mkroute_output net/ipv4/route.c:2265 [inline] ip_route_output_key_hash_rcu+0xa49/0x2c60 net/ipv4/route.c:2493 ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2322 __ip_route_output_key include/net/route.h:126 [inline] ip_route_output_flow+0x26/0xa0 net/ipv4/route.c:2577 ip_route_output_ports include/net/route.h:163 [inline] pptp_connect+0xa84/0x1170 drivers/net/ppp/pptp.c:453 SYSC_connect+0x213/0x4a0 net/socket.c:1639 SyS_connect+0x24/0x30 net/socket.c:1620 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Freed by task 20082: save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527 __cache_free mm/slab.c:3486 [inline] kmem_cache_free+0x83/0x2a0 mm/slab.c:3744 dst_destroy+0x266/0x380 net/core/dst.c:140 dst_destroy_rcu+0x16/0x20 net/core/dst.c:153 __rcu_reclaim kernel/rcu/rcu.h:178 [inline] rcu_do_batch kernel/rcu/tree.c:2675 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline] rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 The buggy address belongs to the object at ffff8801c54dc000 which belongs to the cache ip_dst_cache of size 168 The buggy address is located 64 bytes inside of 168-byte region [ffff8801c54dc000, ffff8801c54dc0a8) The buggy address belongs to the page: page:ffffea0007153700 count:1 mapcount:0 mapping:ffff8801c54dc000 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffff8801c54dc000 0000000000000000 0000000100000010 raw: ffffea0006b34b20 ffffea0006b6c1e0 ffff8801d674a1c0 0000000000000000 page dumped because: kasan: bad access detected Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04net: dsa: mt7530: Use NULL instead of plain integerFlorian Fainelli
We would be passing 0 instead of NULL as the rsp argument to mt7530_fdb_cmd(), fix that. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04net: dsa: b53: Fix sparse warnings in b53_mmap.cFlorian Fainelli
sparse complains about the following warnings: drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in initializer (different address spaces) drivers/net/dsa/b53/b53_mmap.c:33:31: expected unsigned char [noderef] [usertype] <asn:2>*regs drivers/net/dsa/b53/b53_mmap.c:33:31: got void *priv and indeed, while what we are doing is functional, we are dereferencing a void * pointer into a void __iomem * which is not great. Just use the defined b53_mmap_priv structure which holds our register base and use that. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04af_unix: remove redundant lockdep classCong Wang
After commit 581319c58600 ("net/socket: use per af lockdep classes for sk queues") sock queue locks now have per-af lockdep classes, including unix socket. It is no longer necessary to workaround it. I noticed this while looking at a syzbot deadlock report, this patch itself doesn't fix it (this is why I don't add Reported-by). Fixes: 581319c58600 ("net/socket: use per af lockdep classes for sk queues") Cc: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04Merge branch 'net-Broadcom-drivers-sparse-fixes'David S. Miller
Florian Fainelli says: ==================== net: Broadcom drivers sparse fixes This patch series fixes the same warning reported by sparse in bcmsysport and bcmgenet in the code that deals with inserting the TX checksum pointers: drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: cast from restricted __be16 drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: incorrect type in argument 1 (different base types) drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: expected unsigned short [unsigned] [usertype] val drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: got restricted __be16 [usertype] protocol This patch fixes both issues by using the same construct and not swapping skb->protocol but instead the values we are checking against. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()Florian Fainelli
skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons() against the different constants such that the compiler can resolve the values at build time. Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()Florian Fainelli
skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons() against the different constants such that the compiler can resolve the values at build time. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04rxrpc: Fix undefined packet handlingDavid Howells
By analogy with other Rx implementations, RxRPC packet types 9, 10 and 11 should just be discarded rather than being aborted like other undefined packet types. Reported-by: Jeffrey Altman <jaltman@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-04MAINTAINERS: Add John Garry as maintainer for HiSilicon LPC driverJohn Garry
Add John Garry as maintainer for drivers/bus/hisi_lpc.c, the HiSilicon LPC driver. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-04-04HISI LPC: Add ACPI supportJohn Garry
Based on the previous patches, this patch supports the LPC host on Hip06/Hip07 for ACPI FW. It is the responsibility of the LPC host driver to enumerate the child devices, as the ACPI scan code will not enumerate children of "indirect IO" hosts. The ACPI table for the LPC host controller and the child devices is in the following format: Device (LPC0) { Name (_HID, "HISI0191") // HiSi LPC Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000) }) } Device (LPC0.IPMI) { Name (_HID, "IPI0001") Name (LORS, ResourceTemplate() { QWordIO ( ResourceConsumer, MinNotFixed, // _MIF MaxNotFixed, // _MAF PosDecode, EntireRange, 0x0, // _GRA 0xe4, // _MIN 0x3fff, // _MAX 0x0, // _TRA 0x04, // _LEN , , BTIO ) }) Since the IO resources of the child devices need to be translated from LPC bus addresses to logical PIO addresses, and we shouldn't modify the resources of the devices generated in the FW scan, a per-child MFD is created as a substitute. The MFD IO resources will be the translated bus addresses of the ACPI child. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2018-04-04ACPI / scan: Do not enumerate Indirect IO host childrenJohn Garry
Through the logical PIO framework, systems which otherwise have no IO space access to legacy ISA/LPC devices may access these devices through so-called "indirect IO" method. In this, IO space accesses for non-PCI hosts are redirected to a host LLDD to manually generate the IO space (bus) accesses. Hosts are able to register a region in logical PIO space to map to its bus address range. Indirect IO child devices have an associated host-specific bus address. Special translation is required to map between a logical PIO address for a device and its host bus address. Since in the ACPI tables the child device IO resources would be the host-specific values, it is required the ACPI scan code should not enumerate these devices, and that this should be the responsibility of the host driver so that it can "fixup" the resources so that they map to the appropriate logical PIO addresses. To avoid enumerating these child devices, add a check from acpi_device_enumeration_by_parent() as to whether the parent for a device is a member of a known list of "indirect IO" hosts. For now, the HiSilicon LPC host controller ID is added. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-04ACPI / scan: Rename acpi_is_serial_bus_slave() for more general useJohn Garry
Currently the ACPI scan has special handling for serial bus slaves, in that it makes it the responsibility of the slave device's parent to enumerate the device. To support other types of slave devices which require the same special handling but where the bus is not strictly a serial bus, such as devices on the HiSilicon LPC controller bus, rename acpi_is_serial_bus_slave() to acpi_device_enumeration_by_parent(), so that the name can fit the wider purpose. Also rename the associated device flag acpi_device_flags.serial_bus_slave to .enumeration_by_parent. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-04HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindingsZhichang Yuan
The low-pin-count (LPC) interface of Hip06/Hip07 accesses I/O port space of peripherals. Implement the LPC host controller driver which performs the I/O operations on the underlying hardware. We don't want to touch existing drivers such as ipmi-bt, so this driver applies the indirect-IO introduced in the previous patch after registering an indirect-IO node to the indirect-IO devices list which will be searched by the I/O accessors to retrieve the host-local I/O port. The driver config is set as a bool instead of a tristate. The reason here is that, by the very nature of the driver providing a logical PIO range, it does not make sense to have this driver as a loadable module. Another more specific reason is that the Huawei D03 board which includes Hip06 SoC requires the LPC bus for UART console, so should be built in. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zou Rongrong <zourongrong@huawei.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org> # dts part
2018-04-04of: Add missing I/O range exception for indirect-IO devicesZhichang Yuan
There are some special ISA/LPC devices that work on a specific I/O range where it is not correct to specify a 'ranges' property in the DTS parent node as CPU addresses translated from DTS node are only for memory space on some architectures, such as ARM64. Without the parent 'ranges' property, of_translate_address() returns an error. Here we add special handling for this case. During the OF address translation, some checking will be performed to identify whether the device node is registered as indirect-IO. If it is, the I/O translation will be done in a different way from that one of PCI MMIO. In this way, the I/O 'reg' property of the special ISA/LPC devices will be parsed correctly. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> # earlier draft Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
2018-04-04PCI: Apply the new generic I/O management on PCI IO hostsZhichang Yuan
After introducing the new generic I/O space management (Logical PIO), the original PCI MMIO relevant helpers need to be updated based on the new interfaces defined in logical PIO. Adapt the corresponding code to match the changes introduced by logical PIO. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> # earlier draft Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2018-04-04PCI: Add fwnode handler as input param of pci_register_io_range()Gabriele Paoloni
In preparation for having the PCI MMIO helpers use the new generic I/O space management (logical PIO) we need to add the fwnode handler as an extra input parameter. Changes the signature of pci_register_io_range() and its callers as needed. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
2018-04-04PCI: Remove __weak tag from pci_register_io_range()Gabriele Paoloni
pci_register_io_range() has only one definition, so there is no need for the __weak attribute. Remove it. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2018-04-04fscache: Attach the index key and aux data to the cookieDavid Howells
Attach copies of the index key and auxiliary data to the fscache cookie so that: (1) The callbacks to the netfs for this stuff can be eliminated. This can simplify things in the cache as the information is still available, even after the cache has relinquished the cookie. (2) Simplifies the locking requirements of accessing the information as we don't have to worry about the netfs object going away on us. (3) The cache can do lazy updating of the coherency information on disk. As long as the cache is flushed before reboot/poweroff, there's no need to update the coherency info on disk every time it changes. (4) Cookies can be hashed or put in a tree as the index key is easily available. This allows: (a) Checks for duplicate cookies can be made at the top fscache layer rather than down in the bowels of the cache backend. (b) Caching can be added to a netfs object that has a cookie if the cache is brought online after the netfs object is allocated. A certain amount of space is made in the cookie for inline copies of the data, but if it won't fit there, extra memory will be allocated for it. The downside of this is that live cache operation requires more memory. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Anna Schumaker <anna.schumaker@netapp.com> Tested-by: Steve Dickson <steved@redhat.com>
2018-04-04fscache: Add more tracepointsDavid Howells
Add more tracepoints to fscache, including: (*) fscache_page - Tracks netfs pages known to fscache. (*) fscache_check_page - Tracks the netfs querying whether a page is pending storage. (*) fscache_wake_cookie - Tracks cookies being woken up after a page completes/aborts storage in the cache. (*) fscache_op - Tracks operations being initialised. (*) fscache_wrote_page - Tracks return of the backend write_page op. (*) fscache_gang_lookup - Tracks lookup of pages to be stored in the write operation. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04fscache: Add tracepointsDavid Howells
Add some tracepoints to fscache: (*) fscache_cookie - Tracks a cookie's usage count. (*) fscache_netfs - Logs registration of a network filesystem, including the pointer to the cookie allocated. (*) fscache_acquire - Logs cookie acquisition. (*) fscache_relinquish - Logs cookie relinquishment. (*) fscache_enable - Logs enablement of a cookie. (*) fscache_disable - Logs disablement of a cookie. (*) fscache_osm - Tracks execution of states in the object state machine. and cachefiles: (*) cachefiles_ref - Tracks a cachefiles object's usage count. (*) cachefiles_lookup - Logs result of lookup_one_len(). (*) cachefiles_mkdir - Logs result of vfs_mkdir(). (*) cachefiles_create - Logs result of vfs_create(). (*) cachefiles_unlink - Logs calls to vfs_unlink(). (*) cachefiles_rename - Logs calls to vfs_rename(). (*) cachefiles_mark_active - Logs an object becoming active. (*) cachefiles_wait_active - Logs a wait for an old object to be destroyed. (*) cachefiles_mark_inactive - Logs an object becoming inactive. (*) cachefiles_mark_buried - Logs the burial of an object. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04fscache: Fix hanging wait on page discarded by writebackDavid Howells
If the fscache asynchronous write operation elects to discard a page that's pending storage to the cache because the page would be over the store limit then it needs to wake the page as someone may be waiting on completion of the write. The problem is that the store limit may be updated by a different asynchronous operation - and so may miss the write - and that the store limit may not even get updated until later by the netfs. Fix the kernel hang by making fscache_write_op() mark as written any pages that are over the limit. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04fscache: Detect multiple relinquishment of a cookieDavid Howells
Report if an fscache cookie is relinquished multiple times by the netfs. Signed-off-by: David <dhowells@redhat.com>
2018-04-04fscache: Pass the correct cancelled indications to fscache_op_complete()David Howells
The last parameter to fscache_op_complete() is a bool indicating whether or not the operation was cancelled. A lot of the time the inverse value is given or no differentiation is made. Fix this. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04fscache, cachefiles: Fix checker warningsDavid Howells
Fix a couple of checker warnings in fscache and cachefiles: (1) fscache_n_op_requeue is never used, so get rid of it. (2) cachefiles_uncache_page() is passed in a lock that it releases, so this needs annotating. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04afs: Be more aggressive in retiring cached vnodesDavid Howells
When relinquishing cookies, either due to iget failure or to inode eviction, retire a cookie if we think the corresponding vnode got deleted on the server rather than just letting it lie in the cache. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04afs: Use the vnode ID uniquifier in the cache key not the aux dataDavid Howells
AFS vnodes (files) are referenced by a triplet of { volume ID, vnode ID, uniquifier }. Currently, kafs is only using the vnode ID as the file key in the volume fscache index and checking the uniquifier on cookie acquisition against the contents of the auxiliary data stored in the cache. Unfortunately, this is subject to a race in which an FS.RemoveFile or FS.RemoveDir op is issued against the server but the local afs inode isn't torn down and disposed off before another thread issues something like FS.CreateFile. The latter then gets given the vnode ID that just got removed, but with a new uniquifier and a cookie collision occurs in the cache because the cookie is only keyed on the vnode ID whereas the inode is keyed on the vnode ID plus the uniquifier. Fix this by keying the cookie on the uniquifier in addition to the vnode ID and dropping the uniquifier from the auxiliary data supplied. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04afs: Invalidate cache on server data changeDavid Howells
Invalidate any data stored in fscache for a vnode that changes on the server so that we don't end up with the cache in a bad state locally. Signed-off-by: David Howells <dhowells@redhat.com>
2018-04-04cxl: Fix possible deadlock when processing page faults from cxllibFrederic Barrat
cxllib_handle_fault() is called by an external driver when it needs to have the host resolve page faults for a buffer. The buffer can cover several pages and VMAs. The function iterates over all the pages used by the buffer, based on the page size of the VMA. To ensure some stability while processing the faults, the thread T1 grabs the mm->mmap_sem semaphore with read access (R1). However, when processing a page fault for a single page, one of the underlying functions, copro_handle_mm_fault(), also grabs the same semaphore with read access (R2). So the thread T1 takes the semaphore twice. If another thread T2 tries to access the semaphore in write mode W1 (say, because it wants to allocate memory and calls 'brk'), then that thread T2 will have to wait because there's a reader (R1). If the thread T1 is processing a new page at that time, it won't get an automatic grant at R2, because there's now a writer thread waiting (T2). And we have a deadlock. The timeline is: 1. thread T1 owns the semaphore with read access R1 2. thread T2 requests write access W1 and waits 3. thread T1 requests read access R2 and waits The fix is for the thread T1 to release the semaphore R1 once it got the information it needs from the current VMA. The address space/VMAs could evolve while T1 iterates over the full buffer, but in the unlikely case where T1 misses a page, the external driver will raise a new page fault when retrying the memory access. Fixes: 3ced8d730063 ("cxl: Export library to support IBM XSL") Cc: stable@vger.kernel.org # 4.13+ Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-04media: extended-controls.rst: transmitter -> receiverHans Verkuil
V4L2_CID_DV_RX_POWER_PRESENT refers to a receiver, not a transmitter. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04powerpc/hw_breakpoint: Only disable hw breakpoint if cpu supports itNaveen N. Rao
We get the below warning if we try to use kexec on P9: kexec_core: Starting new kernel WARNING: CPU: 0 PID: 1223 at arch/powerpc/kernel/process.c:826 __set_breakpoint+0xb4/0x140 [snip] NIP __set_breakpoint+0xb4/0x140 LR kexec_prepare_cpus_wait+0x58/0x150 Call Trace: 0xc0000000ee70fb20 (unreliable) 0xc0000000ee70fb20 default_machine_kexec+0x234/0x2c0 machine_kexec+0x84/0x90 kernel_kexec+0xd8/0xe0 SyS_reboot+0x214/0x2c0 system_call+0x58/0x6c This happens since we are trying to clear hw breakpoint on POWER9, though we don't have CPU_FTR_DAWR enabled. Guard __set_breakpoint() within hw_breakpoint_disable() with ppc_breakpoint_available() to address this. Fixes: 9654153158d3 ("powerpc: Disable DAWR in the base POWER9 CPU features") Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-04media: staging: atomisp: stop duplicating input format typesMauro Carvalho Chehab
The same formats are defined twice with different names, as warned: drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: warning: incorrect type in argument 2 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: expected void const [noderef] <asn:1>*from drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: got unsigned short [usertype] *<noident> Stop this enum abuse. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: get rid of an unused varMauro Carvalho Chehab
As warned: drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c:8085 create_host_regular_capture_pipeline() error: uninitialized symbol 'frm'. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: stop mixing enum typesMauro Carvalho Chehab
This driver abuses on enum types: drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1027:37: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1027:37: int enum ia_css_csi2_port versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1027:37: int enum mipi_port_ID_t drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1037:39: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1037:39: int enum ia_css_csi2_port versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:1037:39: int enum mipi_port_ID_t drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:2147:62: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:2147:62: int enum mipi_port_ID_t versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:2147:62: int enum ia_css_csi2_port Doing some "implicit" typecast. Fix it by using just one enum everywhere, and stopping using typedef to refer to it. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: get rid of some static warningsMauro Carvalho Chehab
Get rid of those warnings: drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/tdf/tdf_1.0/ia_css_tdf.host.c:18:15: warning: symbol 'g_pyramid' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/mmu/sh_mmu_mrfld.c:66:23: warning: symbol 'sh_mmu_mrfld' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/gc0310.h:381:26: warning: symbol 'gc0310_res_preview' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/atomisp-gc0310.c:622:25: warning: symbol 'gc0310_controls' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/ov2722.h:1099:26: warning: symbol 'ov2722_res_preview' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:574:25: warning: symbol 'ov2722_controls' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:727:25: warning: symbol 'ov2680_controls' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/ov5693/ov5693.h:1090:26: warning: symbol 'ov5693_res_preview' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:958:5: warning: symbol 'ad5823_t_focus_abs' was not declared. Should it be static? drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:1139:25: warning: symbol 'ov5693_controls' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:91:6: warning: symbol 'atomisp_css2_hw_store_8' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:129:10: warning: symbol 'atomisp_css2_hw_load_16' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:139:10: warning: symbol 'atomisp_css2_hw_load_32' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c:2868:14: warning: symbol 'atomisp_get_pipe_index' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5165:5: warning: symbol 'configure_pp_input_nop' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5171:5: warning: symbol 'configure_output_nop' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5179:5: warning: symbol 'get_frame_info_nop' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6630:5: warning: symbol 'atomisp_get_pipe_id' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/input_formatter.c:48:12: warning: symbol 'HIVE_IF_BIN_COPY' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c:1610:6: warning: symbol '__wdt_on_master_slave_sensor' was not declared. Should it be static? Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: use %p to print pointersMauro Carvalho Chehab
Instead of a converting pointers to unsigned long, just print them as-is, using %p. Fixes this warning: drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c:3012 ia_css_debug_pipe_graph_dump_sp_raw_copy() warn: argument 4 to %08lx specifier is cast from pointer Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: remove an useless checkMauro Carvalho Chehab
There's a check at ia_css_vf_configure() to verify if binary is not null. However, this is called too late: drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/vf/vf_1.0/ia_css_vf.host.c:133 ia_css_vf_configure() warn: variable dereferenced before check 'binary' (see line 129) This test is wrong, as this fuction is only called by ia_css_binary_fill_info(), in a place that already assumes that binary is not null, and checks with: assert(binary != NULL); So, remove the useless broken extra check. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: avoid a warning if 32 bits buildMauro Carvalho Chehab
Checking if a size_t value is bigger than ULONG_INT only makes sense if building on 64 bits, as warned by: drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:697 gmin_get_config_var() warn: impossible condition '(*out_len > (~0)) => (0-u32max > u32max)' Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: don't access a NULL varMauro Carvalho Chehab
Get rid of those warnings: drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:446 gmin_v1p2_ctrl() error: we previously assumed 'gs' could be null (see line 444) drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:480 gmin_v1p8_ctrl() error: we previously assumed 'gs' could be null (see line 478) drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:516 gmin_v2p8_ctrl() error: we previously assumed 'gs' could be null (see line 514) Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: Get rid of *default.host.[ch]Mauro Carvalho Chehab
There are a number of files at atomisp that aren't used anywhere, called as "*default.host.[ch]": css2400/isp/kernels/dpc2/ia_css_dpc2_default.host.[ch] css2400/isp/kernels/bnlm/ia_css_bnlm_default.host.[ch] css2400/isp/kernels/tdf/tdf_1.0/ia_css_tdf_default.host.[ch] css2400/isp/kernels/eed1_8/ia_css_eed1_8_default.host.[ch] Remove them. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: get rid of an unused functionMauro Carvalho Chehab
The function __need_realloc_mipi_buffer() is not used anywhere. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: remove unused set_pd_base()Mauro Carvalho Chehab
There's an implementation for set_pd_base at sh_mmu logic with is said to be mandatory. However, the implementation ends by calling a routine that does nothing. So get rid of this entire nonsense. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: fix endianess issuesMauro Carvalho Chehab
There are lots of be-related warnings there, as it doesn't properly mark what data uses bigendian. Warnings fixed: drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:134:15: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:134:15: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:134:15: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:140:26: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:140:26: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:140:26: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:140:26: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:144:26: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:256:27: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:256:27: expected unsigned short [unsigned] [usertype] addr drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:256:27: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:302:25: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:302:25: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:302:25: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:306:25: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:306:25: expected unsigned int [unsigned] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:306:25: got restricted __be32 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:97:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:97:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:97:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:97:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:99:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:134:15: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:134:15: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:134:15: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:141:24: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:141:24: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:141:24: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:177:27: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:177:27: expected unsigned short [unsigned] [usertype] addr drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:177:27: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:198:25: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:198:25: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:198:25: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:88:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:88:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:88:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:88:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:90:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:125:15: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:125:15: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:125:15: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:132:24: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:132:24: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:132:24: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:168:27: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:168:27: expected unsigned short [unsigned] [usertype] addr drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:168:27: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:189:25: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:189:25: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:189:25: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:176:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:176:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:176:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:176:24: warning: cast to restricted __be16 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:178:24: warning: cast to restricted __be32 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:205:13: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:205:13: expected unsigned short [unsigned] [usertype] val drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:205:13: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:276:15: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:276:15: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:276:15: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:283:24: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:283:24: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:283:24: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:319:27: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:319:27: expected unsigned short [unsigned] [usertype] addr drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:319:27: got restricted __be16 [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:340:25: warning: incorrect type in assignment (different base types) drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:340:25: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:340:25: got restricted __be16 [usertype] <noident> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: add a missing includeMauro Carvalho Chehab
atomisp_drvfs.c is not including its own header, causing those warnings: drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c:185:5: warning: symbol 'atomisp_drvfs_init' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c:201:6: warning: symbol 'atomisp_drvfs_exit' was not declared. Should it be static? Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: get rid of stupid statementsMauro Carvalho Chehab
It makes no sense to have a do nothing statement like: (void)stage; Fix those warnings: drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:3808 sh_css_param_update_isp_params() error: uninitialized symbol 'stage'. drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:1444 sh_css_update_host2sp_offline_frame() error: uninitialized symbol 'HIVE_ADDR_host_sp_com'. drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:1475 sh_css_update_host2sp_mipi_frame() error: uninitialized symbol 'HIVE_ADDR_host_sp_com'. drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:1502 sh_css_update_host2sp_mipi_metadata() error: uninitialized symbol 'HIVE_ADDR_host_sp_com'. drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:1522 sh_css_update_host2sp_num_mipi_frames() error: uninitialized symbol 'HIVE_ADDR_host_sp_com'. drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:1541 sh_css_update_host2sp_cont_num_raw_frames() error: uninitialized symbol 'HIVE_ADDR_host_sp_com'. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: declare static vars as suchMauro Carvalho Chehab
Fix a bunch of warnings: drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c:93:23: warning: symbol 'css_queues' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c:27:32: warning: symbol 'handle_table' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c:32:30: warning: symbol 'refpool' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c:43:30: warning: symbol 'writepool' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c:54:30: warning: symbol 'hmmbufferpool' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/input_formatter.c:48:12: warning: symbol 'HIVE_IF_BIN_COPY' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/gp_timer.c:33:1: warning: symbol 'gp_timer_reg_load' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c:74:33: warning: symbol 'sh_css_sp_output' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/debug.c:32:25: warning: symbol 'debug_data' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/input_system.c:32:21: warning: symbol 'IB_BUFFER_NULL' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/input_system.c:647:24: warning: symbol 'config' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:2894:10: warning: symbol 'g_param_buffer_dequeue_count' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:2895:10: warning: symbol 'g_param_buffer_enqueue_count' was not declared. Should it be static? Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: ia_css_output.host: don't use var before checkMauro Carvalho Chehab
Fix this warning: drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/output/output_1.0/ia_css_output.host.c:64 ia_css_output_config() warn: variable dereferenced before check 'from->info' (see line 63) Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-04-04media: staging: atomisp: do some coding style improvementsMauro Carvalho Chehab
Use make coccicheck in patch mode to do some coding style improvements. Adjust the results manually. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
generated by cgit (git 2.34.1) at 2025-09-12 00:07:49 +0000