- 27 5月, 2018 1 次提交
-
-
由 Linus Walleij 提交于
I used bad names in my clumsiness when rewriting many board files to use GPIO descriptors instead of platform data. A few had the platform_device ID set to -1 which would indeed give the device name "i2c-gpio". But several had it set to >=0 which gives the names "i2c-gpio.0", "i2c-gpio.1" ... Fix the offending instances in the ARM tree. Sorry for the mess. Fixes: b2e63555 ("i2c: gpio: Convert to use descriptors") Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Simon Guinot <simon.guinot@sequanux.org> Reported-by: NSimon Guinot <simon.guinot@sequanux.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 07 3月, 2018 4 次提交
-
-
由 Andy Shevchenko 提交于
Instead of using PROPERTY_ENTRY_INTEGER() with explicitly supplied type, use PROPERTY_ENTRY_U32() dedicated macro. It will help modify internals of built-in device properties API. No functional change intended. Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Igor Grinberg 提交于
Both cm-x300 and pxa3xx-ulpi use the plain clk_{en,dis}able() API. With the new clocking framework this results in warnings of type: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:714 clk_core_enable+0x90/0x9c Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc5-cm-x300+ #15 Hardware name: CM-X300 module [<c001007c>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14) [<c000df94>] (show_stack) from [<c00199a8>] (__warn+0xd8/0x100) [<c00199a8>] (__warn) from [<c0019a0c>] (warn_slowpath_null+0x3c/0x48) [<c0019a0c>] (warn_slowpath_null) from [<c024e8c0>] (clk_core_enable+0x90/0x9c) [<c024e8c0>] (clk_core_enable) from [<c024ea54>] (clk_core_enable_lock+0x18/0x2c) [<c024ea54>] (clk_core_enable_lock) from [<c0016994>] (cm_x300_u2d_init+0x4c/0xe8) [<c0016994>] (cm_x300_u2d_init) from [<c00163e0>] (pxa3xx_u2d_probe+0xe0/0x244) [<c00163e0>] (pxa3xx_u2d_probe) from [<c0283de0>] (platform_drv_probe+0x38/0x88) ... ------------[ cut here ]------------ and alike... And finally, it results in: ------------[ cut here ]------------ pxa310_ulpi_poll: ULPI access timed out! OTG transceiver init failed ------------[ cut here ]------------ It might be that disabling the warning in kernel config would also do the job, but IMO a better solution would be to switch to clk_prepare_enable() and clk_disable_unprepare() APIs. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Igor Grinberg 提交于
cm_x300_u2d_init() function is only used through its function pointer that is passed through platform_data structure to the driver. Therefore it can never be inlined. Remove the inline directive. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Igor Grinberg 提交于
Static checker reports the following warning: arch/arm/mach-pxa/pxa3xx-ulpi.c:336 pxa3xx_u2d_probe() warn: did you mean to pass the address of 'u2d' Fix it by passing the correct pointer. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
- 03 3月, 2018 1 次提交
-
-
由 Miquel Raynal 提交于
The "enable arbiter" bit is available only for pxa3xx based platforms but it was experimentally shown that even if this bit is reserved, some Marvell platforms (64-bit) actually need it to be set. The driver always set this bit regardless of this property, which is harmless. Then this property is not needed. The "num_cs" field is always 1 and for a good reason, the old driver (pxa3xx_nand.c) could only handle one. The new driver that replaces it (marvell_nand.c) can handle more, but better use device tree for such description. As there is only one available chip select, there is no need for an array of partitions neither an array of partition numbers. Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
-
- 24 2月, 2018 1 次提交
-
-
由 Miquel Raynal 提交于
Compile marvell_nand.c instead of pxa3xx_nand.c with all PXA based SoCs. Convert all board files and defconfigs so that the new driver is used everywhere instead of the old one. Board files using CONFIG_MTD_NAND_PXA3xx now use CONFIG_MTD_NAND_MARVELL instead. Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
-
- 15 2月, 2018 1 次提交
-
-
由 Linus Walleij 提交于
This converts the bit-banged GPIO SPI driver to looking up and using GPIO descriptors to get a handle on GPIO lines for SCK, MOSI, MISO and all CS lines. All existing board files are converted in one go to keep it all consistent. With these conversions I rarely find any interrim steps that makes any sense. Device tree probing and GPIO handling should work like before also after this patch. For board files, we stop using controller data to pass the GPIO line for chip select, instead we pass this as a GPIO descriptor lookup like everything else. In some s3c24xx machines the names of the SPI devices were set to "spi-gpio" rather than "spi_gpio" which can never have worked, I fixed it working (I guess) as part of this patch set. Sometimes I wonder how this code got upstream in the first place, it obviously is not tested. mach-s3c64xx/mach-smartq.c has the same problem and additionally defines the *same* GPIO line for MOSI and MISO which is not going to be accepted by gpiolib. As the lines were number 1,2,2 I assumed it was a typo and use lines 1,2,3. A comment gives awat that line 0 is chip select though no actual SPI device is provided for the LCD supposed to be on this bit-banged SPI bus. I left it intact instead of just deleting the bus though. Kill off board file code that try to initialize the SPI lines to the same values that they will later be set by the spi_gpio driver anyways. Given the huge number of weird things in these board files I do not think this code is very tested or put in with much afterthought anyways. In order to assert that we do not get performance regressions on this crucial bing-banged driver, a ran a script like this dumping the Ilitek ILI9322 regmap 10000 times (it has no caching obviously) on an otherwise idle system in two iterations before and after the patches: #!/bin/sh for run in `seq 10000` do cat /debug/regmap/spi0.0/registers > /dev/null done Before the patch: time test.sh real 3m 41.03s user 0m 29.41s sys 3m 7.22s time test.sh real 3m 44.24s user 0m 32.31s sys 3m 7.60s After the patch: time test.sh real 3m 41.32s user 0m 28.92s sys 3m 8.08s time test.sh real 3m 39.92s user 0m 30.20s sys 3m 5.56s So any performance differences seems to be in the error margin. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NOlof Johansson <olof@lixom.net> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 22 1月, 2018 1 次提交
-
-
由 Arnd Bergmann 提交于
Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 09 1月, 2018 1 次提交
-
-
由 Joe Perches 提交于
Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible. Done with perl script: $ git grep -w --name-only DEVICE_ATTR | \ xargs perl -i -e 'local $/; while (<>) { s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g; print;}' Signed-off-by: NJoe Perches <joe@perches.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Acked-by: NSagi Grimberg <sagi@grimberg.me> Acked-by: NZhang Rui <rui.zhang@intel.com> Acked-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Acked-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 12月, 2017 1 次提交
-
-
由 Russell King 提交于
Add a gpio driver for the lubbock miscellaneous write IO register so we can take advantage of subsystems modelled around gpiolib, rather than having to provide platform specific callbacks. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
- 08 12月, 2017 1 次提交
-
-
由 Linus Walleij 提交于
The w1 master driver includes a complete open drain emulation reimplementation among other things. This converts the driver and all board files using it to use GPIO descriptors associated with the device to look up the GPIO wire, as well ass the optional pull-up GPIO line. When probed from the device tree, the driver will just pick descriptors and use them right off. For the two board files in the kernel, we add descriptor lookups so we do not need to keep any old platform data handling around for the GPIO lines. As the platform data is also a state container for this driver, we augment it to contain the GPIO descriptors. w1_gpio_write_bit_dir() and w1_gpio_write_bit_val() are gone since this pair was a reimplementation of open drain emulation which is now handled by gpiolib. The special "linux,open-drain" flag is a bit of mishap here: it has the same semantic as the same flags in I2C: it means that something in the platform is setting up the line as open drain behind our back. We handle this the same way as in I2C. To drive the pull-up, we need to bypass open drain emulation in gpiolib for the line, and this is done by driving it high using gpiod_set_raw_value() which has been augmented to have the semantic of overriding the open drain emulation. We also augment the documentation to reflect the way to pass GPIO descriptors from the machine. Acked-by: NEvgeniy Polyakov <zbr@ioremap.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 29 11月, 2017 6 次提交
-
-
由 Andrea Adami 提交于
With the introduction of sharpslpart partition parser we can now read the offsets from NAND: we specify the list of the parsers as platform data, with cmdlinepart and ofpart parsers first allowing to override the part. table written in NAND. This is done here in the board file. Emulators like qemu will need to pass the mtdparts in the cmdline. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Andrea Adami 提交于
With the introduction of sharpslpart partition parser we can now read the offsets from NAND: we specify the list of the parsers as platform data, with cmdlinepart and ofpart parsers first allowing to override the part. table written in NAND. This is done here in the board file. Emulators like qemu will need to pass the mtdparts in the cmdline. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Andrea Adami 提交于
With the introduction of sharpslpart partition parser we can now read the offsets from NAND: we specify the list of the parsers as platform data, with cmdlinepart and ofpart parsers first allowing to override the part. table written in NAND. This is done here in the board file. Emulators like qemu will need to pass the mtdparts in the cmdline. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Andrea Adami 提交于
With the introduction of sharpslpart partition parser we can now read the offsets from NAND: we specify the list of the parsers as platform data, with cmdlinepart and ofpart parsers first allowing to override the part. table written in NAND. This is done here in the board file. Emulators like qemu will need to pass the mtdparts in the cmdline. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Wolfram Sang 提交于
include/linux/i2c is to be deprecated. Move this platform_data to the proper platform_data dir. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Wolfram Sang 提交于
Platform data is not the right place for such declarations, use devices.h in the mach-directory where the rest is located. Note that the some board files needed an additional include for this to work. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
- 03 11月, 2017 1 次提交
-
-
由 Kees Cook 提交于
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Adds a static variable to hold the interrupt private data pointer. Cc: Daniel Mack <daniel@zonque.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: NKees Cook <keescook@chromium.org>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 30 10月, 2017 3 次提交
-
-
由 Linus Walleij 提交于
We now handle the open drain mode internally in the I2C GPIO driver, but we will get warnings from the gpiolib that we override the default mode of the line so it becomes open drain. We can fix all in-kernel users by simply passing the right flag along in the descriptor table, and we already touched all of these files in the series so let's just tidy it up. Cc: Steven Miao <realmz6@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Acked-by: NOlof Johansson <olof@lixom.net> Acked-by: NLee Jones <lee.jones@linaro.org> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Acked-by: NRalf Baechle <ralf@linux-mips.org> Acked-by: NWu, Aaron <Aaron.Wu@analog.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This converts the GPIO-based I2C-driver to using GPIO descriptors instead of the old global numberspace-based GPIO interface. We: - Convert the driver to unconditionally grab two GPIOs from the device by index 0 (SDA) and 1 (SCL) which will work fine with device tree and descriptor tables. The existing device trees will continue to work just like before, but without any roundtrip through the global numberspace. - Brutally convert all boardfiles still passing global GPIOs by registering descriptor tables associated with the devices instead so this driver does not need to keep supporting passing any GPIO numbers as platform data. There is no stepwise approach as elegant as this, I strongly prefer this big hammer over any antsteps for this conversion. This way the old GPIO numbers go away and NEVER COME BACK. Special conversion for the different boards utilizing I2C-GPIO: - EP93xx (arch/arm/mach-ep93xx): pretty straight forward as all boards were using the same two GPIO lines, just define these two in a lookup table for "i2c-gpio" and register these along with the device. None of them define any other platform data so just pass NULL as platform data. This platform selects GPIOLIB so all should be smooth. The pins appear on a gpiochip for bank "G" as pins 1 (SDA) and 0 (SCL). - IXP4 (arch/arm/mach-ixp4): descriptor tables have to be registered for each board separately. They all use "IXP4XX_GPIO_CHIP" so it is pretty straight forward. Most board define no other platform data than SCL/SDA so they can drop the #include of <linux/i2c-gpio.h> and assign NULL to platform data. The "goramo_mlr" (Goramo Multilink Router) board is a bit worrisome: it implements its own I2C bit-banging in the board file, and optionally registers an I2C serial port, but claims the same GPIO lines for itself in the board file. This is not going to work: there will be competition for the GPIO lines, so delete the optional extra I2C bus instead, no I2C devices are registered on it anyway, there are just hints that it may contain an EEPROM that may be accessed from userspace. This needs to be fixed up properly by the serial clock using I2C emulation so drop a note in the code. - KS8695 board acs5k (arch/arm/mach-ks8695/board-acs5.c) has some platform data in addition to the pins so it needs to be kept around sans GPIO lines. Its GPIO chip is named "KS8695" and the arch selects GPIOLIB. - PXA boards (arch/arm/mach-pxa/*) use some of the platform data so it needs to be preserved here. The viper board even registers two GPIO I2Cs. The gpiochip is named "gpio-pxa" and the arch selects GPIOLIB. - SA1100 Simpad (arch/arm/mach-sa1100/simpad.c) defines a GPIO I2C bus, and the arch selects GPIOLIB. - Blackfin boards (arch/blackfin/bf533 etc) for these I assume their I2C GPIOs refer to the local gpiochip defined in arch/blackfin/kernel/bfin_gpio.c names "BFIN-GPIO". The arch selects GPIOLIB. The boards get spiked with IF_ENABLED(I2C_GPIO) but that is a side effect of it being like that already (I would just have Kconfig select I2C_GPIO and get rid of them all.) I also delete any platform data set to 0 as it will get that value anyway from static declartions of platform data. - The MIPS selects GPIOLIB and the Alchemy machine is using two local GPIO chips, one of them has a GPIO I2C. We need to adjust the local offset from the global number space here. The ATH79 has a proper GPIO driver in drivers/gpio/gpio-ath79.c and AFAICT the chip is named "ath79-gpio" and the PB44 PCF857x expander spawns from this on GPIO 1 and 0. The latter board only use the platform data to specify pins so it can be cut altogether after this. - The MFD Silicon Motion SM501 is a special case. It dynamically spawns an I2C bus off the MFD using sm501_create_subdev(). We use an approach to dynamically create a machine descriptor table and attach this to the "SM501-LOW" or "SM501-HIGH" gpiochip. We use chip-local offsets to grab the right lines. We can get rid of two local static inline helpers as part of this refactoring. Cc: Steven Miao <realmz6@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Heiko Schocher <hs@denx.de> Acked-by: NWu, Aaron <Aaron.Wu@analog.com> Acked-by: NOlof Johansson <olof@lixom.net> Acked-by: NLee Jones <lee.jones@linaro.org> Acked-by: NRalf Baechle <ralf@linux-mips.org> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
After finding out there are active users of this sensor I noticed: - It has a single PXA27x board file using the platform data - The platform data is only used to carry two GPIO pins, all other fields are unused - The driver does not use GPIO descriptors but the legacy GPIO API I saw we can swiftly fix this by: - Killing off the platform data entirely - Define a GPIO descriptor lookup table in the board file - Use the standard devm_gpiod_get() to grab the GPIO descriptors from either the device tree or the board file table. This compiles, but needs testing. Cc: arm@kernel.org Cc: Marco Franchi <marco.franchi@nxp.com> Cc: Davide Hug <d@videhug.ch> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Tested-by: NMarco Franchi <marco.franchi@nxp.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 07 10月, 2017 1 次提交
-
-
由 Linus Walleij 提交于
There is exactly one board in the kernel that defines platform data for the GPIO NAND driver. Use the feature to provide a lookup table for the GPIOs in the board file so we can convert the driver as a whole to just use GPIO descriptors. After this we can cut the use of <linux/of_gpio.h> and use the GPIO descriptor management from <linux/gpio/consumer.h> alone to grab and use the GPIOs used in the driver. I also created a local struct device *dev in the probe() function because I was getting annoyed with all the &pdev->dev dereferencing. Cc: arm@kernel.org Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Frans Klaver <fransklaver@gmail.com> Cc: Gerhard Sittig <gsi@denx.de> Cc: Jamie Iles <jamie.iles@oracle.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NMarek Vasut <marek.vasut@gmail.com> Acked-by: NJamie Iles <jamie.iles@oracle.com> Acked-by: NOlof Johansson <olof@lixom.net> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 14 8月, 2017 1 次提交
-
-
由 Russell King 提交于
Robert Jarzmik reports that his PXA25x system fails to boot with 4.12, failing at __flush_whole_cache in arch/arm/mm/proc-xscale.S:215: 0xc0019e20 <+0>: ldr r1, [pc, #788] 0xc0019e24 <+4>: ldr r0, [r1] <== here with r1 containing 0xc06f82cd, which is the address of "clean_addr". Examination of the System.map shows: c06f22c8 D user_pmd_table c06f22cc d __warned.19178 c06f22cd d clean_addr indicating that a .data.unlikely section has appeared just before the .data section from proc-xscale.S. According to objdump -h, it appears that our assembly files default their .data alignment to 2**0, which is bad news if the preceding .data section size is not power-of-2 aligned at link time. Add the appropriate .align directives to all assembly files in arch/arm that are missing them where we require an appropriate alignment. Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr> Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 13 8月, 2017 1 次提交
-
-
由 Boris Brezillon 提交于
We are planning to share more code between different NAND based devices (SPI NAND, OneNAND and raw NANDs), but before doing that we need to move the existing include/linux/mtd/nand.h file into include/linux/mtd/rawnand.h so we can later create a nand.h header containing all common structure and function prototypes. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NPeter Pan <peterpandong@micron.com> Acked-by: NVladimir Zapolskiy <vz@mleia.com> Acked-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com> Acked-by: NWenyou Yang <wenyou.yang@microchip.com> Acked-by: NKrzysztof Kozlowski <krzk@kernel.org> Acked-by: NHan Xu <han.xu@nxp.com> Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-By: NHarvey Hunt <harveyhuntnexus@gmail.com> Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
-
- 28 7月, 2017 1 次提交
-
-
由 Arnd Bergmann 提交于
We get a link error trying to access the w100fb_gpio_read/write functions from the platform when the driver is a loadable module or not built-in, so the platform already uses 'select' to hard-enable the driver. However, that fails if the framebuffer subsystem is disabled altogether. I've considered various ways to fix this properly, but they all seem like too much work or too risky, so this simply adds another 'select' to force the subsystem on as well. Fixes: 82427de2 ("ARM: pxa: PXA_ESERIES depends on FB_W100.") Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 27 7月, 2017 1 次提交
-
-
由 Arnd Bergmann 提交于
In commit 3169663a "ARM: sa11x0/pxa: convert OS timer registers to IOMEM", the definition of the OSCR macro was changed to be an __iomem pointer, but the same register is also used by the XIP code. This patch does the corresponding change here as well. On PXA, the IRQ register definitions were removed even earlier, in commit 5d284e35 ("ARM: pxa: avoid accessing interrupt registers directly"). This patch unfortunately brings some of that back. An earlier version of my patch moved the code into an external function, which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this restores something close to the original code. Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.htmlAcked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 26 7月, 2017 1 次提交
-
-
由 Dmitry Torokhov 提交于
device_add_properties() performs deep copy of supplied array of properties, which means that we can discard the original array. Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 14 6月, 2017 4 次提交
-
-
由 Markus Elfring 提交于
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Markus Elfring 提交于
Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Markus Elfring 提交于
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
由 Petr Cvek 提交于
This patch adds a support for ADS7846 touchscreen driver. The basic functionality was tested, x_plate_ohms and y_plate_ohms were physically measured. The value pressure_max was empirically set to match the measured range, which is affected by x_plate_ohms and ADS samples. The value of keep_vref_on should be set. A tested model (T-Mobile MDA Compact PM10A) doesn't seem to use Vref pin as the input from an external source. On this model the unset keep_vref_on cause high jitter of measured values. SPI framing pin (gpio_cs) must be used in GPIO mode due to an incompatible autoframing of PXA27x controller and ADS7846 device. Signed-off-by: NPetr Cvek <petr.cvek@tul.cz> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
-
- 23 5月, 2017 2 次提交
-
-
由 Wolfram Sang 提交于
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Wolfram Sang 提交于
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 19 4月, 2017 1 次提交
-
-
由 Dmitry Torokhov 提交于
When switching rotary controlelr from plain IRQ number to IRQ resource, I messed up the syntax. Fixes: d422be5f ("Input: eeti_ts - expect platform code to set ... ") Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 05 4月, 2017 2 次提交
-
-
由 Dmitry Torokhov 提交于
gpiod API allows standard way of specifying GPIO polarity and takes it into account when reading or setting GPIO state. It also allows us to switch to common way of obtaining GPIO descriptor and away form legacy platform data. Reviewed-by: NDaniel Mack <daniel@zonque.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
Instead of keying interrupt trigger off GPIO polarity, let's rely on platform code to set it up properly for us. Reviewed-by: NDaniel Mack <daniel@zonque.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 04 4月, 2017 1 次提交
-
-
由 Dmitry Torokhov 提交于
Instead of expecting that GPIO is always interrupt source, let's use interrupt specified in I2C client. Reviewed-by: NDaniel Mack <daniel@zonque.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 28 2月, 2017 1 次提交
-
-
由 Florian Fainelli 提交于
All low-level PM/SMP code using virt_to_phys() should actually use __pa_symbol() against kernel symbols. Update code where relevant to move away from virt_to_phys(). Acked-by: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NLaura Abbott <labbott@redhat.com> Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-