summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-20swiotlb: Omit total_used and used_hiwater if !CONFIG_DEBUG_FSPetr Tesarik
The tracking of used_hiwater adds an atomic operation to the hot path. This is acceptable only when debugging the kernel. To make sure that the fields can never be used by mistake, do not even include them in struct io_tlb_mem if CONFIG_DEBUG_FS is not set. The build fails after doing that. To fix it, it is necessary to remove all code specific to debugfs and instead provide a stub implementation of swiotlb_create_debugfs_files(). As a bonus, this change allows to remove one __maybe_unused attribute. Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-04-20wifi: rtw88: Update spelling in main.hSimon Horman
Update spelling in comments in main.h Found by inspection. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418-rtw88-starspell-v1-1-70e52a23979b@kernel.org
2023-04-20wifi: airo: remove ISA_DMA_API dependencyArnd Bergmann
This driver does not actually use the ISA DMA API, it is purely PIO based, so remove the dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417205131.1560074-1-arnd@kernel.org
2023-04-20wifi: rtl8xxxu: Simplify setting the initial gainBitterblue Smith
The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1 appears to be setting the initial gain, which is stored in bits 0..6. Bits 7..31 are the same as what the phy init tables write. Modify only bits 0..6 so that we don't have to care about the values of the others. This way we don't have to add another "else if" for the RTL8192FU. Why we need to change the initial gain from the default 0x20 to 0x1e? Not sure. Some of the vendor drivers change it to 0x1e before scanning and then restore it to the original value after. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/cf91ca69-70e3-4c20-c0b1-e59d452356a1@gmail.com
2023-04-20wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}Bitterblue Smith
Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask. These helper functions make it easier to modify only parts of a register by eliminating the call to the register reading function and the bit manipulations. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/9430b841-1048-b27c-14ec-fca447dc32af@gmail.com
2023-04-20wifi: rtl8xxxu: Don't print the vendor/product/serialBitterblue Smith
Most devices have a vendor name, product name, and serial number in the efuse, but it's pretty useless. It duplicates the information already printed by the USB subsystem: usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial not available. usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 002E2DC0041F -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00E04C0001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial: 00E04C0001 Also, that data is not interpreted correctly in all cases: usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.2: Product: 802.11n NIC usb 3-1.1.2: Manufacturer: Realtek usb 3-1.1.2: Vendor: Realtek usb 3-1.1.2: Product: \x03802.11n NI usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/a2a7d9df-0529-7890-3522-48dce613753f@gmail.com
2023-04-20wifi: rtw88: Fix memory leak in rtw88_usbLarry Finger
Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit(). Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417160331.23071-1-Larry.Finger@lwfinger.net
2023-04-20wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variantSascha Hauer
We have to call rtw8821c_switch_rf_set() with SWITCH_TO_WLG or SWITCH_TO_BTG according to the chip variant as denoted in rfe_option. The information which argument to use for which variant has been taken from the vendor driver. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-5-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: set pkg_type correctly for specific rtw8821c variantsSascha Hauer
According to the vendor driver the pkg_type has to be set to '1' for some rtw8821c variants. As the pkg_type has been hardcoded to '0', add a field for it in struct rtw_hal and set this correctly in the rtw8821c part. With this parsing of a rtw_table is influenced and check_positive() in phy.c returns true for some cases here. The same is done in the vendor driver. However, this has no visible effect on the driver here. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-4-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: rtw8821c: Fix rfe_option field widthSascha Hauer
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the vendor driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f. Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work. rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed. Note that this might not be the whole truth. In the vendor driver there are indeed places where the unmasked rfe_option value is used. However, the driver has several places where rfe_option is tested with the pattern if (rfe_option == 2 || rfe_option == 0x22) or if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5) has no influence on the code path taken. We therefore mask BIT(5) out from rfe_option entirely until this assumption is proved wrong by some chip variant we do not know yet. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: ValdikSS <iam@valdikss.org.ru> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: usb: fix priority queue to endpoint mappingSascha Hauer
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated. This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver. Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: ValdikSS <iam@valdikss.org.ru> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-2-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: 8822c: add iface combinationPo-Hao Huang
Allow 8822c to operate two interface concurrently, only 1 AP mode plus 1 station mode under same frequency is supported. Combination of other types will not be added until requested. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121331.18062-1-pkshih@realtek.com
2023-04-20wifi: rtw88: handle station mode concurrent scan with AP modePo-Hao Huang
This patch allows vifs sharing same hardware with the AP mode vif to do scan, do note that this could lead to packet loss or disconnection of the AP's clients. Since we don't have chanctx, update scan info upon set channel so bandwidth changes won't go unnoticed and get misconfigured after scan. Download beacon just before scan starts to allow hardware to get proper content to do beaconing. Last, beacons should only be transmitted in AP's operating channel. Turn related beacon functions off while we're in other channels so the receiving stations won't get confused. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121323.18008-1-pkshih@realtek.com
2023-04-20wifi: rtw88: prevent scan abort with other VIFsPo-Hao Huang
Only abort scan with current scanning VIF. If we have more than one interface, we could call rtw_hw_scan_abort() with the wrong VIF as input. This avoids potential null pointer being accessed when actually the other VIF is scanning. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121312.17954-1-pkshih@realtek.com
2023-04-20wifi: rtw88: refine reserved page flow for AP modePo-Hao Huang
Only gather reserved pages from AP interface after it has started. Or else ieee80211_beacon_get_*() returns NULL and causes other VIFs' reserved pages fail to download. Update location of current reserved page after beacon renews so offsets changed by beacon can be recognized. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121300.17900-1-pkshih@realtek.com
2023-04-20wifi: rtw88: disallow PS during AP modePo-Hao Huang
Firmware can't support PS mode during AP mode, so disallow this case. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-5-pkshih@realtek.com
2023-04-20wifi: rtw88: 8822c: extend reserved page numberPo-Hao Huang
Extend 8822c's reserved page number to accommodate additional required pages. Reserved page is an area of memory in the FIFO dedicated for special purposes. Previously only one interface is supported so 8 pages should suffice, extend it so we can support 2 interfaces concurrently. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-4-pkshih@realtek.com
2023-04-20wifi: rtw88: add port switch for AP modePo-Hao Huang
Switch port settings if AP mode does not start on port 0 because of hardware limitation. For some ICs, beacons on ports other than zero could misbehave and do not issue properly, to fix this we change AP VIFs to port zero when multiple interfaces is active. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-3-pkshih@realtek.com
2023-04-20wifi: rtw88: add bitmap for dynamic port settingsPo-Hao Huang
In order to support multiple interfaces, multiple port settings will be required. Current code always uses port 0 and should be changed. Declare a bitmap with size equal to hardware port number to record the current usage. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-2-pkshih@realtek.com
2023-04-20wifi: rtw89: mac: use regular int as return type of DLE buffer requestPing-Ke Shih
The function to request DLE (data link engine) buffer uses 'u16' as return value that mixes error code, so change it to 'int' as regular error code. Also, treat invalid register value (0xfff) as an error. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414082228.30766-1-pkshih@realtek.com
2023-04-20device property: make device_property functions take const device *Guenter Roeck
device_property functions do not modify the device pointer passed to them. The underlying of_device and fwnode_ functions actually already take const * arguments. Mark the parameter constant to simplify conversion from of_property to device_property functions, and to let the calling code use const device pointers where possible. Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230419164127.3773278-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20mcb-lpc: Reallocate memory region to avoid memory overlappingRodríguez Barbarin, José Javier
mcb-lpc requests a fixed-size memory region to parse the chameleon table, however, if the chameleon table is smaller that the allocated region, it could overlap with the IP Cores' memory regions. After parsing the chameleon table, drop/reallocate the memory region with the actual chameleon table size. Co-developed-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Javier Rodriguez <josejavier.rodriguez@duagon.com> Signed-off-by: Johannes Thumshirn <jth@kernel.org> Link: https://lore.kernel.org/r/20230411083329.4506-4-jth@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20mcb-pci: Reallocate memory region to avoid memory overlappingRodríguez Barbarin, José Javier
mcb-pci requests a fixed-size memory region to parse the chameleon table, however, if the chameleon table is smaller that the allocated region, it could overlap with the IP Cores' memory regions. After parsing the chameleon table, drop/reallocate the memory region with the actual chameleon table size. Co-developed-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Javier Rodriguez <josejavier.rodriguez@duagon.com> Signed-off-by: Johannes Thumshirn <jth@kernel.org> Link: https://lore.kernel.org/r/20230411083329.4506-3-jth@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20mcb: Return actual parsed size when reading chameleon tableRodríguez Barbarin, José Javier
The function chameleon_parse_cells() returns the number of cells parsed which has an undetermined size. This return value is only used for error checking but the number of cells is never used. Change return value to be number of bytes parsed to allow for memory management improvements. Co-developed-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Signed-off-by: Javier Rodriguez <josejavier.rodriguez@duagon.com> Signed-off-by: Johannes Thumshirn <jth@kernel.org> Link: https://lore.kernel.org/r/20230411083329.4506-2-jth@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20kernel/configs: Drop Android config fragmentsJohn Stultz
In the old days where each device had a custom kernel, the android config fragments were useful to provide the required and reccomended options expected by userland. However, these days devices are expected to use the GKI kernel, so these config fragments no longer needed, and out of date, so they seem to only cause confusion. So lets drop them. If folks are curious what configs are expected by the Android environment, check out the gki_defconfig file in the latest android common kernel tree. Cc: Rob Herring <robh@kernel.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: <kernel-team@android.com> Signed-off-by: John Stultz <jstultz@google.com> Link: https://lore.kernel.org/r/20230411180409.1706067-1-jstultz@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20virt: acrn: Replace obsolete memalign() with posix_memalign()Deming Wang
memalign() is obsolete according to its manpage. Replace memalign() with posix_memalign() and remove malloc.h include that was there for memalign(). As a pointer is passed into posix_memalign(), initialize *p to NULL to silence a warning about the function's return value being used as uninitialized (which is not valid anyway because the error is properly checked before p is returned). Signed-off-by: Deming Wang <wangdeming@inspur.com> Link: https://lore.kernel.org/r/20230412073041.2168-1-wangdeming@inspur.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20driver core: update comments in device_rename()Wedson Almeida Filho
Document that some subsystems are still going to use device_rename for the time being, so it is not a good idea to assume it's not used. Also remove mentions of a plan to stop renaming net devices. Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com> Link: https://lore.kernel.org/r/20230406045435.19452-1-wedsonaf@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20driver core: Don't require dynamic_debug for initcall_debug probe timingStephen Boyd
Don't require the use of dynamic debug (or modification of the kernel to add a #define DEBUG to the top of this file) to get the printk message about driver probe timing. This printk is only emitted when initcall_debug is enabled on the kernel commandline, and it isn't immediately obvious that you have to do something else to debug boot timing issues related to driver probe. Add a comment too so it doesn't get converted back to pr_debug(). Fixes: eb7fbc9fb118 ("driver core: Add missing '\n' in log messages") Cc: stable <stable@kernel.org> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Brian Norris <briannorris@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230412225842.3196599-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: Add a check for remove callback when removing a SPMI driverJishnu Prakash
When removing a SPMI driver, there can be a crash due to NULL pointer dereference if it does not have a remove callback defined. This is one such call trace observed when removing the QCOM SPMI PMIC driver: dump_backtrace.cfi_jt+0x0/0x8 dump_stack_lvl+0xd8/0x16c panic+0x188/0x498 __cfi_slowpath+0x0/0x214 __cfi_slowpath+0x1dc/0x214 spmi_drv_remove+0x16c/0x1e0 device_release_driver_internal+0x468/0x79c driver_detach+0x11c/0x1a0 bus_remove_driver+0xc4/0x124 driver_unregister+0x58/0x84 cleanup_module+0x1c/0xc24 [qcom_spmi_pmic] __do_sys_delete_module+0x3ec/0x53c __arm64_sys_delete_module+0x18/0x28 el0_svc_common+0xdc/0x294 el0_svc+0x38/0x9c el0_sync_handler+0x8c/0xf0 el0_sync+0x1b4/0x1c0 If a driver has all its resources allocated through devm_() APIs and does not need any other explicit cleanup, it would not require a remove callback to be defined. Hence, add a check for remove callback presence before calling it when removing a SPMI driver. Link: https://lore.kernel.org/r/1671601032-18397-2-git-send-email-quic_jprakash@quicinc.com Fixes: 6f00f8c8635f ("mfd: qcom-spmi-pmic: Use devm_of_platform_populate()") Fixes: 5a86bf343976 ("spmi: Linux driver framework for SPMI") Signed-off-by: Jishnu Prakash <quic_jprakash@quicinc.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-7-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: fix W=1 kernel-doc warningsRandy Dunlap
Fix all W=1 kernel-doc warnings in drivers/spmi/: drivers/spmi/spmi.c:414: warning: expecting prototype for spmi_controller_alloc(). Prototype was for spmi_device_alloc() instead drivers/spmi/spmi.c:592: warning: expecting prototype for spmi_driver_register(). Prototype was for __spmi_driver_register() instead drivers/spmi/spmi.c:592: warning: Function parameter or member 'owner' not described in '__spmi_driver_register' drivers/spmi/spmi-pmic-arb.c:155: warning: cannot understand function prototype: 'struct spmi_pmic_arb ' drivers/spmi/spmi-pmic-arb.c:203: warning: cannot understand function prototype: 'struct pmic_arb_ver_ops ' drivers/spmi/spmi-pmic-arb.c:219: warning: expecting prototype for struct pmic_arb_ver. Prototype was for struct pmic_arb_ver_ops instead Link: https://lore.kernel.org/r/20230113064040.26801-1-rdunlap@infradead.org Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-6-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: mtk-pmif: Drop of_match_ptr for ID tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/spmi/spmi-mtk-pmif.c:517:34: error: ‘mtk_spmi_match_table’ defined but not used [-Werror=unused-const-variable=] Link: https://lore.kernel.org/r/20230310222857.315629-2-krzysztof.kozlowski@linaro.org Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-5-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: pmic-arb: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20230306073446.2194048-4-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-4-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: mtk-pmif: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20230306073446.2194048-3-u.kleine-koenig@pengutronix.de Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-3-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20spmi: hisi-spmi-controller: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20230306073446.2194048-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230413223834.4084793-2-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: gpio: remove unnecessary ENOMEM messagesKrzysztof Kozlowski
Core already prints detailed reports on out of memory: WARNING: Possible unnecessary 'out of memory' message Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-16-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: omap-hdq: remove unnecessary ENOMEM messagesKrzysztof Kozlowski
Core already prints detailed reports on out of memory: WARNING: Possible unnecessary 'out of memory' message Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-15-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: omap-hdq: add SPDX tagKrzysztof Kozlowski
Replace GPLv2 license text with SPDX and drop unnecessary file name in comment to fix checkpatch warnings: WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 WARNING: It's generally not useful to have the filename in the file Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-14-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: omap-hdq: allow compile testingKrzysztof Kozlowski
omap-hdq does not depend on anything from ARCH_OMAP for building. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-13-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: matrox: remove unnecessary ENOMEM messagesKrzysztof Kozlowski
Core already prints detailed reports on out of memory: WARNING: Possible unnecessary 'out of memory' message Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-12-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: matrox: use inline over __inline__Krzysztof Kozlowski
Switch to inline as preferred by coding style: WARNING: plain inline is preferred over __inline__ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-11-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: matrox: switch from asm to linux headerKrzysztof Kozlowski
linux/io.h is preferred over asm/io.h: WARNING: Use #include <linux/io.h> instead of <asm/io.h> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-10-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2482: do not use assignment in if conditionKrzysztof Kozlowski
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-9-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2482: drop unnecessary headerKrzysztof Kozlowski
linux/delay.h is already included, so drop asm header to also fix checkpatch: WARNING: Use #include <linux/delay.h> instead of <asm/delay.h> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-8-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2433: do not use assignment in if conditionKrzysztof Kozlowski
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-7-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: use octal for file permissionsKrzysztof Kozlowski
Improve code readability and checkpatch warnings: WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-6-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: minor white-space and code style fixesKrzysztof Kozlowski
Correct several coding convention violations around white-spaces: ERROR: spaces required around that '=' (ctx:VxV) WARNING: Missing a blank line after declarations ERROR: "foo* bar" should be "foo *bar" ERROR: "(foo*)" should be "(foo *)" WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line WARNING: please, no space before tabs WARNING: Missing a blank line after declarations ERROR: open brace '{' following struct go on the same line ERROR: that open brace { should be on the previous line Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-4-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds28e04: correct kerneldoc annotationKrzysztof Kozlowski
Correct kerneldoc comments (or drop annotation) to fix: w1_ds28e04.c:57: warning: This comment starts with '/**', but isn't a kernel-doc comment. w1_ds28e04.c:149: warning: This comment starts with '/**', but isn't a kernel-doc comment. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-3-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2433: correct kerneldoc annotationKrzysztof Kozlowski
Correct kerneldoc comments (or drop annotation) to fix: w1_ds2433.c:46: warning: This comment starts with '/**', but isn't a kernel-doc comment. w1_ds2433.c:141: warning: This comment starts with '/**', but isn't a kernel-doc comment. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2408: drop kerneldoc annotationKrzysztof Kozlowski
Drop kerneldoc annotation from comment which is not a kerneldoc to fix: w1_ds2408.c:210: warning: This comment starts with '/**', but isn't a kernel-doc comment Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230415104304.104134-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20w1: ds2482: add i2c id for DS2484Stefan Wahren
The DS2484 is compatible to the DS2482-100, but also supports a pin-controlled power-saving sleep mode. Link: https://www.analog.com/media/en/technical-documentation/data-sheets/DS2484.pdf Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com> Link: https://lore.kernel.org/r/20230406103137.6092-3-stefan.wahren@chargebyte.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-20 15:34:28 +0000