aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-01-23iio:proximity:vl53l0x: Tidy up white space around {} in id tablesJonathan Cameron1-1/+1
Previously inconsistent with a space after { but not before }. Tidy that up to avoid providing a bad example that might get copied into other drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Ivan Drobyshevskyi <drobyshevskyi@gmail.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-16-jic23@kernel.org
2022-01-23iio:light:tsl2722: Fix inconsistent spacing before } in id tableJonathan Cameron1-1/+1
The final entry was missing a space. Tidy that up. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-15-jic23@kernel.org
2022-01-23iio:adc:ti-adc084s021: Tidy up white space around {}Jonathan Cameron1-1/+1
Previously inconsistent with a space after { but not before }. Tidy that up to avoid providing an example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-14-jic23@kernel.org
2022-01-23iio:adc:hi8435: Tidy up white space around {} in id tablesJonathan Cameron1-1/+1
Previously inconsistent with space after { but not before }. Tidy that up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-13-jic23@kernel.org
2022-01-23iio:adc:mt6577_auxadc: Tidy up white space around {} in id tablesJonathan Cameron1-5/+5
Previously inconsistent with space after { and not before }. Tidy that up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Zhiyong Tao <zhiyong.tao@mediatek.com> Cc: Hui Liu <hui.liu@mediatek.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-12-jic23@kernel.org
2022-01-23iio:frequency:admv1013: White space cleanup of spacing around {} in id tablesJonathan Cameron1-1/+1
The spacing was inconsistent with a space after the { but not before the }. Tidy this up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-11-jic23@kernel.org
2022-01-23iio:proximity:srf08: White space cleanup of spacing around {} in id tablesJonathan Cameron1-3/+3
The spacing in this driver was inconsistent with a space after the { but not before the }. Tidy this up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-10-jic23@kernel.org
2022-01-23iio:proximity:srf04: White space cleanup of spacing around {} in id tablesJonathan Cameron1-6/+6
The spacing in this driver was inconsistent with a space after the { but not before the }. Tidy this up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-9-jic23@kernel.org
2022-01-23iio:proximity:rfd77402: White space cleanup of spacing around {} in id tablesJonathan Cameron1-1/+1
The spacing in this driver was inconsistent with a space after the { but not before the }. Tidy this up to avoid providing a bad example to copy into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-8-jic23@kernel.org
2022-01-23iio:proximity:ping: White space cleanup of spacing around {} in id tablesJonathan Cameron1-2/+2
The spacing in this driver was inconsistent so make sure we have a space after { and before } for the two id tables. Avoid providing examples of this inconsistency that get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-7-jic23@kernel.org
2022-01-23iio:light:ltr501: White space cleanup of spacing around {} in id tablesJonathan Cameron1-7/+7
The spacing in this driver was inconsistent so make sure we have a space after { and before } for the two id tables. Part of aim is to avoid providing examples of this inconsistency that get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nikita Travkin <nikita@trvn.ru> Cc: Maslov Dmitry <maslovdmitry@seeed.cc> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-6-jic23@kernel.org
2022-01-23iio:light:us5182: White space cleanup of spacing around {} in id tablesJonathan Cameron1-3/+3
The spacing in this driver was inconsistent so make sure we have a space after { and before } for the two id tables. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-5-jic23@kernel.org
2022-01-23iio:light:vcnl4035: Trivial whitespace cleanup to add space before }Jonathan Cameron1-1/+1
Having a space after the { and not one before the } is inconsistent and I'd rather not have examples of this that get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Parthiban Nallathambi <pn@denx.de> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-4-jic23@kernel.org
2022-01-23iio:light:pa12203001: Tidy up white space change to add spaces after { and before }Jonathan Cameron1-2/+2
One case in here was inconsistent and was main focus of this patch. In that case there was a space after the { and none before the }. The second case was then inconsistent in having now spaces. Change makes sure there are spaces. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-3-jic23@kernel.org
2022-01-23iio:chemical:atlas: Trivial white space cleanup to add space before }Jonathan Cameron1-5/+5
Having a space after the { and not one before the } is inconsistent and good to remove examples that might get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211230174911.78291-2-jic23@kernel.org
2022-01-23iio:proximity:sx9360: Add dt-binding supportGwendal Grignou1-0/+84
Add support to configure sx9360 from dt-binding, to match device hardware setup. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203800.290387-4-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio:proximity:sx9360: Add sx9360 supportGwendal Grignou3-0/+824
A simplified version of SX9324, it only have one pin and 2 phases (aka channels). Only one event is presented. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203800.290387-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio:proximity:sx9324: Add dt_binding supportGwendal Grignou1-0/+164
Based on bindings/iio/proximity/semtech,sx9324.yaml, implement retrieving sensor hardware property and alter default values. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203817.290512-6-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio:proximity:sx9324: Add SX9324 supportGwendal Grignou3-0/+919
Semtech SAR sensor SX9324 is an evolution of the SX9310: It has 4 phases that can be configured to capture and process data from any of 3 CS pins and provide independent detection: proximity, table proximity or body proximity. Gather antenna data: echo sx9324-dev3 > trigger/current_trigger echo 1 > scan_elements/in_proximity0_en echo 1 > buffer/enable od -v -An --endian=big -t d2 -w2 /dev/iio\:device3 (at 10Hz, the default). Trigger events: Setting: thresh_falling_period: 2 (events) thresh_rising_period: 2 (events) in_proximity0_thresh_either_value: 300 in_proximity0_thresh_either_hysteresis: 72 using iio_event_monitor /dev/iio\:deviceX, approaching my hand to the antenna pad, I see: ... Event: time: 1634763907532035297, type: proximity, channel: 0, evtype: thresh, direction: falling Event: time: 1634763910138104640, type: proximity, channel: 0, evtype: thresh, direction: rising ... Datasheet: https://edit.wpgdadawant.com/uploads/news_file/program/2019/30184/tech_files/program_30184_suggest_other_file.pdf Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203817.290512-4-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio:proximity:sx9310: Extract common Semtech sensor logicGwendal Grignou5-604/+842
Before adding new Semtech sensors, move common logic to all Semtech SAR sensor in its own file: - interface with IIO subsystem, - interrupt management, - channel access conrol, - event processing. The change adds a bidirectional interface between sx93xx and sx_common. The change is quite mechanical, as the impacted functions are moved and renamed. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203817.290512-3-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio:proximity:sx9310: Add frequency in read_availGwendal Grignou1-26/+7
Instead of using IIO_DEV_ATTR_SAMP_FREQ_AVAIL sysfs attribute, add a _FREQ case in read_avail() to display the frequency table. No change to |sampling_frequency_available| was observed. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220101203817.290512-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23soc: samsung: Fix typo in CONFIG_EXYNOS_USI descriptionSam Protsenko1-1/+1
The proper name is Exynos Auto V9, not V0. It was the typo slipped in unnoticed, fix it. Fixes: b603377e408f ("soc: samsung: Add USI driver") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20220114144606.24358-1-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2022-01-23mtd: rawnand: omap_elm: remove redundant variable 'errors'Colin Ian King1-3/+1
The variable 'errors' is being used to sum the number of errors but it is never used afterwards. This can be considered a redundant set of operations and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211221181340.524639-1-colin.i.king@gmail.com
2022-01-23Merge tag 'irq_urgent_for_v5.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds2-3/+2
Pull irq fix from Borislav Petkov: "A single use-after-free fix in the PCI MSI irq domain allocation path" * tag 'irq_urgent_for_v5.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI/MSI: Prevent UAF in error path
2022-01-23mtd: rawnand: gpmi: support fast edo timings for mx28Dario Binacchi1-2/+2
In the i.MX28 manual (MCIMX28RM, Rev. 1, 2010) you can find an example (15.2.4 High-Speed NAND Timing) of how to configure the GPMI controller to manage High-Speed ​​NAND devices, so it was wrong to assume that only i.MX6 can achieve EDO timings. This patch has been tested on a 2048/64 byte NAND (Micron MT29F2G08ABAEAH4). Kernel mtd tests: - mtd_nandbiterrs - mtd_nandecctest - mtd_oobtest - mtd_pagetest - mtd_readtest - mtd_speedtest - mtd_stresstest - mtd_subpagetest - mtd_torturetest [cycles_count = 10000000] run without errors. Before this patch (mode 0): --------------------------- eraseblock write speed is 2098 KiB/s eraseblock read speed is 2680 KiB/s page write speed is 1689 KiB/s page read speed is 2522 KiB/s 2 page write speed is 1899 KiB/s 2 page read speed is 2579 KiB/s erase speed is 128000 KiB/s 2x multi-block erase speed is 73142 KiB/s 4x multi-block erase speed is 204800 KiB/s 8x multi-block erase speed is 256000 KiB/s 16x multi-block erase speed is 256000 KiB/s 32x multi-block erase speed is 256000 KiB/s 64x multi-block erase speed is 256000 KiB/s After this patch (mode 5): ------------------------- eraseblock write speed is 3390 KiB/s eraseblock read speed is 5688 KiB/s page write speed is 2680 KiB/s page read speed is 4876 KiB/s 2 page write speed is 2909 KiB/s 2 page read speed is 5224 KiB/s erase speed is 170666 KiB/s 2x multi-block erase speed is 204800 KiB/s 4x multi-block erase speed is 256000 KiB/s 8x multi-block erase speed is 256000 KiB/s 16x multi-block erase speed is 256000 KiB/s 32x multi-block erase speed is 256000 KiB/s 64x multi-block erase speed is 256000 KiB/s Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220118095434.35081-5-dario.binacchi@amarulasolutions.com
2022-01-23mtd: rawnand: gpmi: validate controller clock rateDario Binacchi1-4/+18
What to do when the real rate of the gpmi clock is not equal to the required one? The solutions proposed in [1] did not lead to a conclusion on how to validate the clock rate, so, inspired by the document [2], I consider the rate correct only if not lower or equal to the rate of the previous edo mode. In fact, in chapter 4.16.2 (NV-DDR) of the document [2], it is written that "If the host selects timing mode n, then its clock period shall be faster than the clock period of timing mode n-1 and slower than or equal to the clock period of timing mode n.". I thought that it could therefore also be used in this case, without therefore having to define the valid rate ranges empirically. For example, suppose that gpmi_nfc_compute_timings() is called to set edo mode 5 (100MHz) but the rate returned by clk_round_rate() is 80MHz (edo mode 4). In this case gpmi_nfc_compute_timings() will return error, and will be called again to set edo mode 4, which this time will be successful. [1] https://lore.kernel.org/r/20210702065350.209646-5-ebiggers@kernel.org [2] http://www.onfi.org/-/media/client/onfi/specs/onfi_3_0_gold.pdf?la=en Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220118095434.35081-4-dario.binacchi@amarulasolutions.com
2022-01-23mtd: rawnand: gpmi: fix controller timings settingDario Binacchi1-0/+3
Set the controller registers according to the real clock rate. The controller registers configuration (setup, hold, timeout, ... cycles) depends on the clock rate of the GPMI. Using the real rate instead of the ideal one, avoids that this inaccuracy (required_rate - real_rate) affects the registers setting. This patch has been tested on two custom boards with i.MX28 and i.MX6 SOCs: - i.MX28: required rate 100MHz, real rate 99.3MHz - i.MX6 required rate 100MHz, real rate 99MHz Fixes: b1206122069a ("mtd: rawnand: gpmi: use core timings instead of an empirical derivation") Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220118095434.35081-3-dario.binacchi@amarulasolutions.com
2022-01-23mtd: aspeed-smc: improve probe resiliencePatrick Williams1-2/+13
The aspeed-smc can have multiple SPI devices attached to it in the device tree. If one of the devices is missing or failing the entire probe will fail and all MTD devices under the controller will be removed. On OpenBMC this results in a kernel panic due to missing rootfs: [ 0.538774] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency [ 0.540471] aspeed-smc 1e620000.spi: w25q01jv-iq (131072 Kbytes) [ 0.540750] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x28000000 ] 128MB [ 0.540943] aspeed-smc 1e620000.spi: CE1 window [ 0x28000000 - 0x2c000000 ] 64MB [ 0.541143] aspeed-smc 1e620000.spi: read control register: 203b0041 [ 0.581442] 5 fixed-partitions partitions found on MTD device bmc [ 0.581625] Creating 5 MTD partitions on "bmc": [ 0.581854] 0x000000000000-0x0000000e0000 : "u-boot" [ 0.584472] 0x0000000e0000-0x000000100000 : "u-boot-env" [ 0.586468] 0x000000100000-0x000000a00000 : "kernel" [ 0.588465] 0x000000a00000-0x000006000000 : "rofs" [ 0.590552] 0x000006000000-0x000008000000 : "rwfs" [ 0.592605] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency [ 0.592801] aspeed-smc 1e620000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00 [ 0.593039] Deleting MTD partitions on "bmc": [ 0.593175] Deleting u-boot MTD partition [ 0.637929] Deleting u-boot-env MTD partition [ 0.829527] Deleting kernel MTD partition [ 0.856902] Freeing initrd memory: 1032K [ 0.866428] Deleting rofs MTD partition [ 0.906264] Deleting rwfs MTD partition [ 0.986628] aspeed-smc 1e620000.spi: Aspeed SMC probe failed -2 [ 0.986929] aspeed-smc: probe of 1e620000.spi failed with error -2 ... [ 2.936719] /dev/mtdblock: Can't open blockdev mount: mounting /dev/mtdblock on run/initramfs/ro failed: No such file or directory [ 2.963030] MTD: Couldn't look up '/dev/mtdblock': -2 mount: mounting /dev/mtdblock on run/initramfs/rw failed: No such file or directory Mounting read-write /dev/mtdblock filesystem failed. Please fix and run mount /dev/mtdblock run/initramfs/rw -t jffs2 -o rw or perform a factory reset with the clean-rwfs-filesystem option. Fatal error, triggering kernel panic! [ 3.013047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 Many BMC designs have two flash chips so that they can handle a hardware failure of one of them. If one chip failed, it doesn't do any good to have redundancy if they all get removed anyhow. Improve the resilience of the probe function to handle one of the children being missing or failed. Only in the case where all children fail to probe should the controller be failed out. Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211229143334.297305-1-patrick@stwcx.xyz
2022-01-23mtd: rawnand: brcmnand: Add BCMA shimFlorian Fainelli4-0/+151
Add a BCMA shim to allow us to register the brcmnand driver using the BCMA bus which provides indirect memory mapped access to SoC registers. There are a number of registers that need to be byte swapped because they are natively big endian, coming directly from the NAND chip, and there is no bus interface unlike the iProc or STB platforms that performs the byte swapping for us. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-10-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: BCMA controller uses command shift of 0Florian Fainelli1-0/+6
For some odd and unexplained reason the BCMA NAND controller, albeit revision 3.4 uses a command shift of 0 instead of 24 as it should be, quirk that. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-9-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Allow platform data instantationFlorian Fainelli1-10/+35
Make use of the recently refactored code in brcmnand_init_cs() and derive the chip-select from the platform data that is supplied. Update the various code paths to avoid relying on possibly non-existent resources, too. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-8-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Add platform data structure for BCMAFlorian Fainelli1-1/+19
Update the BCMA's chipcommon nand flash driver to detect which chip-select is used and pass that information via platform data to the brcmnand driver. Make sure that the brcmnand platform data structure is always at the beginning of the platform data of the "nflash" device created by BCMA to allow brcmnand to safely de-reference it. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-7-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Allow working without interruptsFlorian Fainelli1-28/+24
The BCMA devices include the brcmnand controller but they do not wire up any interrupt line, allow the main interrupt to be optional and update the completion path to also check for the lack of an interrupt line. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-6-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Move OF operations out of brcmnand_init_cs()Florian Fainelli1-9/+11
In order to initialize a given chip select object for use by the brcmnand driver, move all of the Device Tree specific routines outside of brcmnand_init_cs() in order to make it usable in a platform data configuration which will be necessary for supporting BCMA chips. No functional changes introduced. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-5-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Avoid pdev in brcmnand_init_cs()Florian Fainelli1-4/+4
In preparation for encapsulating more of what the loop calling brcmnand_init_cs() does, avoid using platform_device when it is the device behind platform_device that we are using for printing errors. No functional changes introduced. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-4-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Allow SoC to provide I/O operationsFlorian Fainelli2-2/+55
Allow a brcmnand_soc instance to provide a custom set of I/O operations which we will require when using this driver on a BCMA bus which is not directly memory mapped I/O. Update the nand_{read,write}_reg accordingly to use the SoC operations if provided. To minimize the penalty on other SoCs which do support standard MMIO accesses, we use a static key which is disabled by default and gets enabled if a soc implementation does provide I/O operations. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-3-f.fainelli@gmail.com
2022-01-23mtd: rawnand: brcmnand: Assign soc as early as possibleFlorian Fainelli1-2/+1
In order to key off the brcmnand_probe() code in subsequent changes depending upon ctrl->soc, assign that variable as early as possible, instead of much later when we have checked that it is non-NULL. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220107184614.2670254-2-f.fainelli@gmail.com
2022-01-23mtd: rawnand: Rework of_get_nand_bus_width()Tudor Ambarus1-12/+18
of_get_nand_bus_width() had a wrong behavior because: 1/ it ignored the -ENODATA and -EOVERFLOW return values of of_property_read_u32(). "nand-bus-width" without value was tolerated while it shouldn't have been according to the devicetree bindings. 2/ returned -EIO when the nand-bus-width was neither 8 nor 16, when it should have returned -EINVAL instead. 3/ returned the 8 or 16 bus-width integer, but it was never used it its caller. A simply return 0 on success is enough. Rework of_get_nand_bus_width() and address all the above. The execution is now stopped in case of errors. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220106131610.225661-2-tudor.ambarus@microchip.com
2022-01-23mtd: rawnand: Remove of_get_nand_on_flash_bbt() wrapperTudor Ambarus1-6/+1
Remove the wrapper as it hides for no reason what we really want: find an of_property. Removing the wrapper makes the code easier to read. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220106131610.225661-1-tudor.ambarus@microchip.com
2022-01-23mtd: onenand: Check for error irqJiasheng Jiang1-1/+6
For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq(). Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now. Fixes: 2c22120fbd01 ("MTD: OneNAND: interrupt based wait support") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220104162658.1988142-1-jiasheng@iscas.ac.cn
2022-01-23mtd: rawnand: nandsim: Add NS_PAGE_BYTE_SHIFT macro to replace the repeat patternRinHizakura1-8/+11
The (ns->regs.column + ns->regs.off) pattern repeats a lot which represents the byte shift in next page to access. We can replace it with a macro to improve the readability. Signed-off-by: RinHizakura <s921975628@gmail.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211225100713.119089-1-s921975628@gmail.com
2022-01-23mtd: rawnand: nandsim: Merge repeat codes in ns_switch_stateRinHizakura1-13/+6
The moving block of codes is shared between both 'if' and 'else' condition, we can move it out to reduce the duplication. Signed-off-by: RinHizakura <s921975628@gmail.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211225100648.119011-1-s921975628@gmail.com
2022-01-23mtd: rawnand: nandsim: Replace overflow check with kzalloc to single kcallocRinHizakura1-8/+1
Instead of self-checking overflow and allocating an array of specific size by counting the total required space handy, we already have existed kernel API which responses for all these works. Signed-off-by: RinHizakura <s921975628@gmail.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211225100607.118932-1-s921975628@gmail.com
2022-01-23phy: broadcom: Kconfig: Fix PHY_BRCM_USB config optionAl Cooper1-2/+1
The previous commit 4b402fa8e0b7 ("phy: phy-brcm-usb: support PHY on the BCM4908") added a second "default" line for ARCH_BCM_4908 above the original "default" line for ARCH_BRCMSTB. When two "default" lines are used, only the first is used and this change stopped the PHY_BRCM_USB option for being enabled for ARCH_BRCMSTB. The fix is to use one "default line with "||". Fixes: 4b402fa8e0b7 ("phy: phy-brcm-usb: support PHY on the BCM4908") Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211201180653.35097-4-alcooperx@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-01-23phy: usb: Leave some clocks running during suspendAl Cooper1-0/+38
The PHY client driver does a phy_exit() call on suspend or rmmod and the PHY driver needs to know the difference because some clocks need to be kept running for suspend but can be shutdown on unbind/rmmod (or if there are no PHY clients at all). The fix is to use a PM notifier so the driver can tell if a PHY client is calling exit() because of a system suspend or a driver unbind/rmmod. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211201180653.35097-2-alcooperx@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-01-23mtd: nand: ecc: Add infrastructure to support hardware enginesMiquel Raynal2-3/+95
Add the necessary helpers to register/unregister hardware ECC engines that will be called from ECC engine drivers. Also add helpers to get the right engine from the user perspective. Keep a reference of the in use ECC engine in order to prevent modules to be unloaded. Put the reference when the engine gets retired. A static list of hardware (only) ECC engines is setup to keep track of the registered engines. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-13-miquel.raynal@bootlin.com
2022-01-23mtd: spinand: macronix: Use random program loadMason Yang1-1/+1
Macronix SPI-NAND chips might benefit from an external ECC engine. Such an engine might need to access random columns, thus needing to use random commands (0x84 instead of 0x02). Signed-off-by: Mason Yang <masonccyang@mxic.com.tw> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-12-miquel.raynal@bootlin.com
2022-01-23mei: me: Use dma_set_mask_and_coherent() and simplify codeChristophe JAILLET1-8/+2
Use dma_set_mask_and_coherent() instead of unrolling it with some dma_set_mask()+dma_set_coherent_mask(). Moreover, as stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. While at it, include directly <linux/dma-mapping.h> instead on relying on indirect inclusion. [1]: https://lkml.org/lkml/2021/6/7/398 Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/67ddcec656194153830684e6ff4513114e8859d6.1641624544.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-23pinctrl: samsung: add support for Exynos850 and ExynosAutov9 wake-upsKrzysztof Kozlowski1-0/+4
It seems that newer ARMv8 Exynos SoC like Exynos850 and ExynosAutov9 have differences of their pin controller node capable of external wake-up interrupts: 1. No multiplexed external wake-up interrupt, only direct, 2. More than one pin controller capable of external wake-up interrupts. Add support for dedicated Exynos850 and ExynosAutov9 compatibles. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Tested-by: Chanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20220111201722.327219-20-krzysztof.kozlowski@canonical.com
2022-01-23pinctrl: samsung: accept GPIO bank nodes with a suffixKrzysztof Kozlowski1-12/+45
Existing dt-bindings expected that each GPIO/pin bank within pin controller has its own node with name matching the bank (e.g. gpa0, gpx2) and "gpio-controller" property. The node name is then used for matching between driver data and DTS. Newly introduced dtschema expects to have nodes ending with "-gpio-bank" suffix, so rewrite bank-devicetree matching to look for old and new style of naming. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20220111201426.326777-3-krzysztof.kozlowski@canonical.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.