kernel/linux.git/drivers/ata/libahci_platform.c, branch v6.1.168

ata: libahci_platform: ahci_platform_find_clk: oops, NULL pointer

2022-12-06T23:36:37+00:00

When booting a arm 32-bit kernel with config CONFIG_AHCI_DWC enabled on a am57xx-evm board. This happens when the clock references are unnamed in DT, the strcmp() produces a NULL pointer dereference, see the following oops, NULL pointer dereference: [ 4.673950] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.682098] [00000000] *pgd=00000000 [ 4.685699] Internal error: Oops: 5 [#1] SMP ARM [ 4.690338] Modules linked in: [ 4.693420] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc7 #1 [ 4.699615] Hardware name: Generic DRA74X (Flattened Device Tree) [ 4.705749] PC is at strcmp+0x0/0x34 [ 4.709350] LR is at ahci_platform_find_clk+0x3c/0x5c [ 4.714416] pc : [] lr : [] psr: 20000013 [ 4.720703] sp : f000dda8 ip : 00000001 fp : c29b1840 [ 4.725952] r10: 00000020 r9 : c1b23380 r8 : c1b23368 [ 4.731201] r7 : c1ab4cc4 r6 : 00000001 r5 : c3c66040 r4 : 00000000 [ 4.737762] r3 : 00000080 r2 : 00000080 r1 : c1ab4cc4 r0 : 00000000 [...] [ 4.998870] strcmp from ahci_platform_find_clk+0x3c/0x5c [ 5.004302] ahci_platform_find_clk from ahci_dwc_probe+0x1f0/0x54c [ 5.010589] ahci_dwc_probe from platform_probe+0x64/0xc0 [ 5.016021] platform_probe from really_probe+0xe8/0x41c [ 5.021362] really_probe from __driver_probe_device+0xa4/0x204 [ 5.027313] __driver_probe_device from driver_probe_device+0x38/0xc8 [ 5.033782] driver_probe_device from __driver_attach+0xb4/0x1ec [ 5.039825] __driver_attach from bus_for_each_dev+0x78/0xb8 [ 5.045532] bus_for_each_dev from bus_add_driver+0x17c/0x220 [ 5.051300] bus_add_driver from driver_register+0x90/0x124 [ 5.056915] driver_register from do_one_initcall+0x48/0x1e8 [ 5.062591] do_one_initcall from kernel_init_freeable+0x1cc/0x234 [ 5.068817] kernel_init_freeable from kernel_init+0x20/0x13c [ 5.074584] kernel_init from ret_from_fork+0x14/0x2c [ 5.079681] Exception stack(0xf000dfb0 to 0xf000dff8) [ 5.084747] dfa0: 00000000 00000000 00000000 00000000 [ 5.092956] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 5.101165] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 5.107818] Code: e5e32001 e3520000 1afffffb e12fff1e (e4d03001) [ 5.114013] ---[ end trace 0000000000000000 ]--- Add an extra check in the if-statement if hpriv-clks[i].id. Fixes: 6ce73f3a6fc0 ("ata: libahci_platform: Add function returning a clock-handle by id") Suggested-by: Arnd Bergmann Signed-off-by: Anders Roxell Reviewed-by: Serge Semin Signed-off-by: Damien Le Moal

ata: libahci_platform: Add function returning a clock-handle by id

2022-09-16T16:40:11+00:00

Since all the clocks are retrieved by the method ahci_platform_get_resources() there is no need for the LLD (glue) drivers to be looking for some particular of them in the kernel clocks table again. Instead we suggest to add a simple method returning a device-specific clock with passed connection ID if it is managed to be found. Otherwise the function will return NULL. Thus the glue-drivers won't need to either manually touching the hpriv->clks array or calling clk_get()-friends. The AHCI platform drivers will be able to use the new function right after the ahci_platform_get_resources() method invocation and up to the device removal. Note the method is left unused here, but will be utilized in the framework of the DWC AHCI SATA driver being added in the next commit. Signed-off-by: Serge Semin Signed-off-by: Damien Le Moal

ata: ahci: Introduce firmware-specific caps initialization

2022-09-16T16:40:02+00:00

There are systems with no BIOS or comprehensive embedded firmware which could be able to properly initialize the SATA AHCI controller platform-specific capabilities. In that case a good alternative to having a clever bootloader is to create a device tree node with the properties well describing all the AHCI-related platform specifics. All the settings which are normally detected and marked as available in the HBA and its ports capabilities fields [1] could be defined in the platform DTB by means of a set of the dedicated properties. Such approach perfectly fits to the DTB-philosophy - to provide hardware/platform description. So here we suggest to extend the SATA AHCI device tree bindings with two additional DT-properties: 1) "hba-cap" - HBA platform generic capabilities like: - SSS - Staggered Spin-up support. - SMPS - Mechanical Presence Switch support. 2) "hba-port-cap" - HBA platform port capabilities like: - HPCP - Hot Plug Capable Port. - MPSP - Mechanical Presence Switch Attached to Port. - CPD - Cold Presence Detection. - ESP - External SATA Port. - FBSCP - FIS-based Switching Capable Port. All of these capabilities require to have a corresponding hardware configuration. Thus it's ok to have them defined in DTB. Even though the driver currently takes into account the state of the ESP and FBSCP flags state only, there is nothing wrong with having all of them supported by the generic AHCI library in order to have a complete OF-based platform-capabilities initialization procedure. These properties will be parsed in the ahci_platform_get_resources() method and their values will be stored in the saved_* fields of the ahci_host_priv structure, which in its turn then will be used to restore the H.CAP, H.PI and P#.CMD capability fields on device init and after HBA reset. Please note this modification concerns the HW-init HBA and its ports flags only, which are by specification [1] are supposed to be initialized by the BIOS/platform firmware/expansion ROM and which are normally declared in the one-time-writable-after-reset register fields. Even though these flags aren't supposed to be cleared after HBA reset some AHCI instances may violate that rule so we still need to perform the fields resetting after each reset. Luckily the corresponding functionality has already been partly implemented in the framework of the ahci_save_initial_config() and ahci_restore_initial_config() methods. [1] Serial ATA AHCI 1.3.1 Specification, p. 103 Signed-off-by: Serge Semin Signed-off-by: Damien Le Moal

ata: libahci: Discard redundant force_port_map parameter

2022-09-16T16:39:46+00:00

Currently there are four port-map-related fields declared in the ahci_host_priv structure and used to setup the HBA ports mapping. First the ports-mapping is read from the PI register and immediately stored in the saved_port_map field. If forced_port_map is initialized with non-zero value then its value will have greater priority over the value read from PI, thus it will override the saved_port_map field. That value will be then masked by a non-zero mask_port_map field and after some sanity checks it will be stored in the ahci_host_priv.port_map field as a final port mapping. As you can see the logic is a bit too complicated for such a simple task. We can freely get rid from at least one of the fields with no change to the implemented semantic. The force_port_map field can be replaced with taking non-zero saved_port_map value into account. So if saved_port_map is pre-initialized by the low level drivers (platform drivers) then it will have greater priority over the value read from PI register and will be used as actual HBA ports mapping later on. Thus the ports map forcing task will be just transferred from force_port_map to the saved_port_map field. This modification will perfectly fit into the feature of having OF-based initialization of the HW-init HBA CSR fields we are about to introduce in the next commit. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: libahci_platform: Introduce reset assertion/deassertion methods

2022-09-16T16:39:34+00:00

Currently the ACHI-platform library supports only the assert and deassert reset signals and ignores the platforms with self-deasserting reset lines. That prone to having the platforms with self-deasserting reset method misbehaviour when it comes to resuming from sleep state after the clocks have been fully disabled. For such cases the controller needs to be fully reset all over after the reference clocks are enabled and stable, otherwise the controller state machine might be in an undetermined state. The best solution would be to auto-detect which reset method is supported by the particular platform and use it implicitly in the framework of the ahci_platform_enable_resources()/ahci_platform_disable_resources() methods. Alas it can't be implemented due to the AHCI-platform library already supporting the shared reset control lines. As [1] says in such case we have to use only one of the next methods: + reset_control_assert()/reset_control_deassert(); + reset_control_reset()/reset_control_rearm(). If the driver had an exclusive control over the reset lines we could have been able to manipulate the lines with no much limitation and just used the combination of the methods above to cover all the possible reset-control cases. Since the shared reset control has already been advertised and couldn't be changed with no risk to breaking the platforms relying on it, we have no choice but to make the platform drivers to determine which reset methods the platform reset system supports. In order to implement both types of reset control support we suggest to introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which when passed to the ahci_platform_get_resources() method together with the AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are self-deasserting thus the reset_control_reset()/reset_control_rearm() will be used to control the reset state. Otherwise the reset_control_deassert()/reset_control_assert() methods will be utilized. [1] Documentation/driver-api/reset.rst Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: libahci_platform: Parse ports-implemented property in resources getter

2022-09-16T16:39:30+00:00

The ports-implemented property is mainly used on the OF-based platforms with no ports mapping initialized by a bootloader/BIOS firmware. Seeing the same of_property_read_u32()-based pattern has already been implemented in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI drivers let's move the property read procedure to the generic ahci_platform_get_resources() method. Thus we'll have the forced ports mapping feature supported for each OF-based platform which requires that, and stop re-implementing the same pattern in there a bit simplifying the code. Signed-off-by: Serge Semin Signed-off-by: Damien Le Moal

ata: libahci_platform: Sanity check the DT child nodes number

2022-09-16T16:39:26+00:00

Having greater than AHCI_MAX_PORTS (32) ports detected isn't that critical from the further AHCI-platform initialization point of view since exceeding the ports upper limit will cause allocating more resources than will be used afterwards. But detecting too many child DT-nodes doesn't seem right since it's very unlikely to have it on an ordinary platform. In accordance with the AHCI specification there can't be more than 32 ports implemented at least due to having the CAP.NP field of 5 bits wide and the PI register of dword size. Thus if such situation is found the DTB must have been corrupted and the data read from it shouldn't be reliable. Let's consider that as an erroneous situation and halt further resources allocation. Note it's logically more correct to have the nports set only after the initialization value is checked for being sane. So while at it let's make sure nports is assigned with a correct value. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: libahci_platform: Convert to using devm bulk clocks API

2022-09-16T16:39:22+00:00

In order to simplify the clock-related code there is a way to convert the current fixed clocks array into using the common bulk clocks kernel API with dynamic set of the clock handlers and device-managed clock-resource tracking. It's a bit tricky due to the complication coming from the requirement to support the platforms (da850, spear13xx) with the non-OF-based clock source, but still doable. Before this modification there are two methods have been used to get the clocks connected to an AHCI device: clk_get() - to get the very first clock in the list and of_clk_get() - to get the rest of them. Basically the platforms with non-OF-based clocks definition could specify only a single reference clock source. The platforms with OF-hw clocks have been luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be retained with using devm_clk_bulk_get_all() to retrieve the clocks defined via the DT firmware and devm_clk_get_optional() otherwise. In both cases using the device-managed version of the methods will cause the automatic resources deallocation on the AHCI device removal event. The only complicated part in the suggested approach is the explicit allocation and initialization of the clk_bulk_data structure instance for the non-OF reference clocks. It's required in order to use the Bulk Clocks API for the both denoted cases of the clocks definition. Note aside with the clock-related code reduction and natural simplification, there are several bonuses the suggested modification provides. First of all the limitation of having no greater than AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all() method will allocate as many reference clocks data descriptors as there are clocks specified for the device. Secondly the clock names are auto-detected. So the LLDD (glue) drivers can make sure that the required clocks are specified just by checking the clock IDs in the clk_bulk_data array. Thirdly using the handy Bulk Clocks kernel API improves the clocks-handling code readability. And the last but not least this modification implements a true optional clocks support to the ahci_platform_get_resources() method. Indeed the previous clocks getting procedure just stopped getting the clocks on any errors (aside from non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed about abnormal loop termination. The new implementation lacks of such problem. The ahci_platform_get_resources() will return an error code if the corresponding clocks getting method ends execution abnormally. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: libahci_platform: Convert to using platform devm-ioremap methods

2022-09-16T16:39:18+00:00

Currently the IOMEM AHCI registers space is mapped by means of the two functions invocation: platform_get_resource() is used to get the very first memory resource and devm_ioremap_resource() is called to remap that resource. Device-managed kernel API provides a handy wrapper to perform the same in single function call: devm_platform_ioremap_resource(). While at it seeing many AHCI platform drivers rely on having the AHCI CSR space marked with "ahci" name let's first try to find and remap the CSR IO-mem with that name and only if it fails fallback to getting the very first registers space platform resource. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

Merge tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2022-03-28T19:27:35+00:00

Pull char/misc and other driver updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem updates for 5.18-rc1. Included in here are merges from driver subsystems which contain: - iio driver updates and new drivers - fsi driver updates - fpga driver updates - habanalabs driver updates and support for new hardware - soundwire driver updates and new drivers - phy driver updates and new drivers - coresight driver updates - icc driver updates Individual changes include: - mei driver updates - interconnect driver updates - new PECI driver subsystem added - vmci driver updates - lots of tiny misc/char driver updates All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits) firmware: google: Properly state IOMEM dependency kgdbts: fix return value of __setup handler firmware: sysfb: fix platform-device leak in error path firmware: stratix10-svc: add missing callback parameter on RSU arm64: dts: qcom: add non-secure domain property to fastrpc nodes misc: fastrpc: Add dma handle implementation misc: fastrpc: Add fdlist implementation misc: fastrpc: Add helper function to get list and page misc: fastrpc: Add support to secure memory map dt-bindings: misc: add fastrpc domain vmid property misc: fastrpc: check before loading process to the DSP misc: fastrpc: add secure domain support dt-bindings: misc: add property to support non-secure DSP misc: fastrpc: Add support to get DSP capabilities misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP misc: fastrpc: separate fastrpc device from channel context dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells dt-bindings: nvmem: make "reg" property optional nvmem: brcm_nvram: parse NVRAM content into NVMEM cells nvmem: dt-bindings: Fix the error of dt-bindings check ...