kernel/linux.git/arch/arm/common, branch v6.1.168

ARM/dma-mapping: remove dmabounce

2022-07-07T16:18:56+00:00

Remove the now unused dmabounce code. Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann

ARM: sa1100/assabet: move dmabounce hack to ohci driver

2022-07-07T16:18:47+00:00

The sa1111 platform is one of the two remaining users of the old Arm specific "dmabounce" code, which is an earlier implementation of the generic swiotlb. Linus Walleij submitted a patch that removes dmabounce support from the ixp4xx, and I had a look at the other user, which is the sa1111 companion chip. Looking at how dmabounce is used, I could narrow it down to one driver one three machines: - dmabounce is only initialized on assabet/neponset, jornada720 and badge4, which are the platforms that have an sa1111 and support DMA on it. - All three of these suffer from "erratum #7" that requires only doing DMA to half the memory sections based on one of the address lines, in addition, the neponset also can't DMA to the RAM that is connected to sa1111 itself. - the pxa lubbock machine also has sa1111, but does not support DMA on it and does not set dmabounce. - only the OHCI and audio devices on sa1111 support DMA, but as there is no audio driver for this hardware, only OHCI remains. In the OHCI code, I noticed that two other platforms already have a local bounce buffer support in the form of the "local_mem" allocator. Specifically, TMIO and SM501 use this on a few other ARM boards with 16KB or 128KB of local SRAM that can be accessed from the OHCI and from the CPU. While this is not the same problem as on sa1111, I could not find a reason why we can't re-use the existing implementation but replace the physical SRAM address mapping with a locally allocated DMA buffer. There are two main downsides: - rather than using a dynamically sized pool, this buffer needs to be allocated at probe time using a fixed size. Without having any idea of what it should be, I picked a size of 64KB, which is between what the other two OHCI front-ends use in their SRAM. If anyone has a better idea what that size is reasonable, this can be trivially changed. - Previously, only USB transfers to unaddressable memory needed to go through the bounce buffer, now all of them do, which may impact runtime performance for USB endpoints that do a lot of transfers. On the upside, the local_mem support uses write-combining buffers, which should be a bit faster for transfers to the device compared to normal uncached coherent memory as used in dmabounce. Cc: Linus Walleij Cc: Russell King Cc: Christoph Hellwig Cc: Laurentiu Tudor Cc: linux-usb@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Greg Kroah-Hartman Acked-by: Alan Stern Signed-off-by: Christoph Hellwig

ARM: pxa: split up mach/hardware.h

2022-04-19T14:27:05+00:00

The mach/hardware.h is included in lots of places, and it provides three different things on pxa: - the cpu_is_pxa* macros - an indirect inclusion of mach/addr-map.h - the __REG() and io_pv2() helper macros Split it up into separate and mach/pxa-regs.h headers, then change all the files that use mach/hardware.h to include the exact set of those three headers that they actually need, allowing for further more targeted cleanup. linux/soc/pxa/cpu.h can remain permanently exported and is now in a global location along with similar headers. pxa-regs.h and addr-map.h are only used in a very small number of drivers now and can be moved to arch/arm/mach-pxa/ directly when those drivers are to pass the necessary data as resources. Cc: Michael Turquette Cc: Stephen Boyd Acked-by: Viresh Kumar Acked-by: Dmitry Torokhov Cc: Jacek Anaszewski Cc: Pavel Machek Acked-by: Ulf Hansson Cc: Dominik Brodowski Acked-by: Alexandre Belloni Cc: Greg Kroah-Hartman Cc: Guenter Roeck Acked-by: Mark Brown Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: linux-leds@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-mtd@lists.infradead.org Cc: linux-rtc@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Signed-off-by: Arnd Bergmann

Merge branches 'devel-stable' and 'misc' into for-linus

2021-11-02T09:04:22+00:00

ARM: 9123/1: scoop: Drop if with an always false condition

2021-10-19T09:30:54+00:00

The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so !sdev is never true. The motivation for this change is to get rid of non-zero return values for remove callbacks as their only effect is to trigger a runtime warning. See commit e5e1c2097881 ("driver core: platform: Emit a warning if a remove callback returned non-zero") for further details. Link: https://lore.kernel.org/linux-arm-kernel/20210721205450.2173923-1-u.kleine-koenig@pengutronix.de Reviewed-by: Greg Kroah-Hartman Signed-off-by: Uwe Kleine-König Signed-off-by: Russell King (Oracle)

ARM: sharpsl_param: work around -Wstringop-overread warning

2021-10-05T13:44:56+00:00

gcc warns that accessing a pointer based on a numeric constant may be an offset into a NULL pointer, and would therefore has zero accessible bytes: arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’: arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy’ reading 64 bytes from a region of size 0 [-Werror=stringop-overread] 43 | memcpy(&sharpsl_param, param_start(PARAM_BASE), sizeof(struct sharpsl_param_info)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this particular case, the warning is bogus since this is the actual pointer, not an offset on a NULL pointer. Add a local variable to shut up the warning and hope it doesn't come back. Signed-off-by: Arnd Bergmann Acked-by: Daniel Mack Cc: Daniel Mack Cc: Haojian Zhuang Cc: Robert Jarzmik Cc: Russell King Cc: Linus Walleij Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Link: https://lore.kernel.org/r/20210927145332.2784005-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann

Merge tag 'driver-core-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2021-09-01T15:44:42+00:00

Pull driver core updates from Greg KH: "Here is the big set of driver core patches for 5.15-rc1. These do change a number of different things across different subsystems, and because of that, there were 2 stable tags created that might have already come into your tree from different pulls that did the following - changed the bus remove callback to return void - sysfs iomem_get_mapping rework Other than those two things, there's only a few small things in here: - kernfs performance improvements for huge numbers of sysfs users at once - tiny api cleanups - other minor changes All of these have been in linux-next for a while with no reported problems, other than the before-mentioned merge issue" * tag 'driver-core-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (33 commits) MAINTAINERS: Add dri-devel for component.[hc] driver core: platform: Remove platform_device_add_properties() ARM: tegra: paz00: Handle device properties with software node API bitmap: extend comment to bitmap_print_bitmask/list_to_buf drivers/base/node.c: use bin_attribute to break the size limitation of cpumap ABI topology: use bin_attribute to break the size limitation of cpumap ABI lib: test_bitmap: add bitmap_print_bitmask/list_to_buf test cases cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list sysfs: Rename struct bin_attribute member to f_mapping sysfs: Invoke iomem_get_mapping() from the sysfs open callback debugfs: Return error during {full/open}_proxy_open() on rmmod zorro: Drop useless (and hardly used) .driver member in struct zorro_dev zorro: Simplify remove callback sh: superhyway: Simplify check in remove callback nubus: Simplify check in remove callback nubus: Make struct nubus_driver::remove return void kernfs: dont call d_splice_alias() under kernfs node lock kernfs: use i_lock to protect concurrent inode updates kernfs: switch kernfs to use an rwsem kernfs: use VFS negative dentry caching ...

ARM: Bulk conversion to generic_handle_domain_irq()

2021-08-12T10:39:39+00:00

Wherever possible, replace constructs that match either generic_handle_irq(irq_find_mapping()) or generic_handle_irq(irq_linear_revmap()) to a single call to generic_handle_domain_irq(). Acked-by: Krzysztof Kozlowski Signed-off-by: Marc Zyngier

bus: Make remove callback return void

2021-07-21T09:53:42+00:00

The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Reviewed-by: Tom Rix (For fpga) Reviewed-by: Mathieu Poirier Reviewed-by: Cornelia Huck (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) (For ARM, Amba and related parts) Acked-by: Mark Brown Acked-by: Chen-Yu Tsai (for sunxi-rsb) Acked-by: Pali Rohár Acked-by: Mauro Carvalho Chehab (for media) Acked-by: Hans de Goede (For drivers/platform) Acked-by: Alexandre Belloni Acked-By: Vinod Koul Acked-by: Juergen Gross (For xen) Acked-by: Lee Jones (For mfd) Acked-by: Johannes Thumshirn (For mcb) Acked-by: Johan Hovold Acked-by: Srinivas Kandagatla (For slimbus) Acked-by: Kirti Wankhede (For vfio) Acked-by: Maximilian Luz Acked-by: Heikki Krogerus (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez (For ipack) Acked-by: Geoff Levand (For ps3) Acked-by: Yehezkel Bernat (For thunderbolt) Acked-by: Alexander Shishkin (For intel_th) Acked-by: Dominik Brodowski (For pcmcia) Acked-by: Rafael J. Wysocki (For ACPI) Acked-by: Bjorn Andersson (rpmsg and apr) Acked-by: Srinivas Pandruvada (For intel-ish-hid) Acked-by: Dan Williams (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray (For isa) Acked-by: Stefan Richter (For firewire) Acked-by: Benjamin Tissoires (For hid) Acked-by: Thorsten Scherer (For siox) Acked-by: Sven Van Asbroeck (For anybuss) Acked-by: Ulf Hansson (For MMC) Acked-by: Wolfram Sang # for I2C Acked-by: Sudeep Holla Acked-by: Geert Uytterhoeven Acked-by: Dmitry Torokhov Acked-by: Finn Thain Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

ARM: 9049/1: locomo: make locomo bus's remove callback return void

2021-02-01T19:44:30+00:00

The driver core ignores the return value of struct bus_type::remove because there is only little that can be done. To simplify the quest to make this function return void, let struct locomo_driver::remove return void, too. All users already unconditionally return 0, this commit makes it obvious that returning an error code is a bad idea and ensures future users behave accordingly. Link: https://lore.kernel.org/r/20201126110140.2021758-1-u.kleine-koenig@pengutronix.de Acked-by: Dmitry Torokhov Acked-by: Lee Jones Signed-off-by: Uwe Kleine-König Signed-off-by: Russell King