- 07 May, 2022 21 commits
-
-
Arnd Bergmann authored
get_clk_frequency_khz() is not a proper name for a global function, and there is only one caller. Convert viper to use the properly namespaced pxa25x_get_clk_frequency_khz() and remove the other references. Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Cc: linux-pm@vger.kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Rather than poking at the smemc registers directly from the pcmcia/pxa2xx_base driver, move those bits into machine file to have a cleaner interface. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Link: https://lore.kernel.org/lkml/87d0egjzxk.fsf@belgarion.home/Signed-off-by:
-
Arnd Bergmann authored
To avoid dereferencing hardwired constant pointers from a global header file, change the driver to use devm_platform_ioremap_resource for getting an __iomem pointer, and then using readl/writel on that. Each pointer dereference gets changed by a search&replace, which leads to a few overlong lines, but seems less risky than trying to clean up the code at the same time. Acked-by:
Mark Brown <broonie@kernel.org> Acked-by:
-
Arnd Bergmann authored
To avoid dereferencing hardwired constant pointers from a global header file, change the driver to use devm_platform_ioremap_resource for getting an __iomem pointer, and then using readl/writel on that. Each pointer dereference gets changed by a search&replace, which leads to a few overlong lines, but seems less risky than trying to clean up the code at the same time. Cc: alsa-devel@alsa-project.org Acked-by:
-
Arnd Bergmann authored
The driver currently takes the hardwired FIFO address from a header file that we want to eliminate. Change it to use the mmio resource instead and stop including the here. Acked-by:
-
Dmitry Torokhov authored
Now that we are using oneshot threaded IRQ this method is not used anymore. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> [arnd: add the db1300 change as well] Cc: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
Instead of manually disabling and enabling interrupts and scheduling work to access the device, let's use threaded oneshot interrupt handler. It simplifies things. Signed-off-by:
-
Arnd Bergmann authored
To avoid a dependency on the pxa platform header files with hardcoded registers, change the driver to call a wrapper in the pxa2xx-ac97-lib that encapsulates all the other ac97 stuff. Acked-by:
-
Arnd Bergmann authored
The two drivers are almost identical and can work on a variety of hardware in principle. The mainstone driver supports additional hardware, and the zylonite driver has a few cleanup patches. Sync the two by adding the zylonite changes into the mainstone one, and checking for the zylonite board to order to keep the default behavior (interrupt enabled) there. Acked-by:
-
Arnd Bergmann authored
There are two different ways of flushing the ac97 queue in this driver, selected by a compile time option. Change this to a runtime selection to make it work when both are enabled. Acked-by:
-
Arnd Bergmann authored
The mach/mfp.h header is only used by this one driver for hardcoded gpio numbers. Change that to use a lookup table instead. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: linux-input@vger.kernel.org Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
This driver hardcodes gpio numbers without a header file. Use lookup tables instead. Cc: Marek Vasut <marek.vasut@gmail.com> Acked-by:
-
Arnd Bergmann authored
The magician audio driver creates a codec device and gets data from a board specific header file, both of which is a bit suspicious. Move these into the board file itself, using a gpio lookup table. Acked-by:
-
Arnd Bergmann authored
The audio device is allocated by the audio driver, and it uses a gpio number from the mach/z2.h header file. Change it to use a gpio lookup table for the device allocated by the driver to keep the header file local to the machine. Acked-by:
-
Arnd Bergmann authored
The three eseries machines have very similar drivers for audio, all using the mach/eseries-gpio.h header for finding the gpio numbers. Change these to use gpio descriptors to avoid the header file dependency. I convert the _OFF gpio numbers into GPIO_ACTIVE_LOW ones for consistency here. Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Acked-by:
-
Arnd Bergmann authored
Lubbock is the only machine that has three IRQs for the UDC. These are currently hardcoded in the driver based on a machine header file. Change this to use platform device resources as we use for the generic IRQ anyway. Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Paul Parsons <lost.distance@yahoo.com> Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Acked-by:
-
Arnd Bergmann authored
The poodle audio driver shows its age by using a custom gpio api for the "locomo" support chip. In a perfect world, this would get converted to use gpiolib and a gpio lookup table. As the world is not perfect, just pass all the required data in a custom platform_data structure. to avoid the globally visible mach/poodle.h header. Acked-by:
-
Linus Walleij authored
The Tosa device (Sharp SL-6000) has a mishmash driver set-up for the Toshiba TC6393xb MFD that includes a battery charger and touchscreen and has some kind of relationship to the SoC sound driver for the AC97 codec. Other devices define a chip like this but seem only half-implemented, not really handling battery charging etc. This patch switches the Toshiba MFD device to provide GPIO descriptors to the battery charger and SoC codec. As a result some descriptors need to be moved out of the Tosa boardfile and new one added: all SoC GPIO resources to these drivers now comes from the main boardfile, while the MFD provide GPIOs for its portions. As a result we can request one GPIO from our own GPIO chip and drop two hairy callbacks into the board file. This platform badly needs to have its drivers split up and converted to device tree probing to handle this quite complex relationship in an orderly manner. I just do my best in solving the GPIO descriptor part of the puzzle. Please don't ask me to fix everything that is wrong with these driver to todays standards, I am just trying to fix one aspect. I do try to use modern devres resource management and handle deferred probe using new functions where appropriate. Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Dirk Opfer <dirk@opfer-online.de> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Daniel Mack <daniel@zonque.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Reviewed-by:
Dmitry Baryshkov <dbaryshkov@gmail.com> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
- 20 Apr, 2022 2 commits
-
-
Arnd Bergmann authored
From inspection I found a couple of GPIO lookups that are listed with device "gpio-pxa", but actually have a number from a different gpio controller. Try to rectify that here, with a guess of what the actual device name is. Acked-by:
-
Arnd Bergmann authored
The palmld header is almost unused in drivers, the only remaining thing now is the PATA device address, which should really be passed as a resource. Cc: linux-ide@vger.kernel.org Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by:
-
- 19 Apr, 2022 12 commits
-
-
Arnd Bergmann authored
Drivers should not rely on the contents of this file, so move it into the platform directory directly. Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Paul Parsons <lost.distance@yahoo.com> Signed-off-by:
-
Arnd Bergmann authored
The drivers/pcmcia/pxa2xx_*.c are essentially part of the board files, but for historic reasons located in drivers/pcmcia. Move them into the same place as the actual board file to avoid lots of machine header inclusions. Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: -
Arnd Bergmann authored
The pxa2xx-ac97-lib code is the last driver to use mach/irqs.h for PXA. Almost everything already passes the interrupt as a resource, so use it from there. The one exception is the mxm8x10 machine, which apparently has a resource-less device. Replacing it with the correct one enables the driver here as well. Cc: alsa-devel@alsa-project.org Acked-by:
-
Arnd Bergmann authored
Rather than relying on machine specific headers to pass down the reboot status and the register locations, use resources and platform_data. Aside from this, keep the changes to a minimum. Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: linux-watchdog@vger.kernel.org Acked-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
Only the pxafb driver uses this header, so move it into the same directory. The SMART_* macros are required by some platform data definitions and can go into the linux/platform_data/video-pxafb.h header. Acked-by:
-
Arnd Bergmann authored
This is a basically a platform_data file, so move it out of the mach/* header directory. Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Tomas Cech <sleep_walker@suse.com> Cc: Sergey Lapin <slapin@ossfans.org> Acked-by:
-
Arnd Bergmann authored
There are two identical copies of mach/bitfield.h, one for mach-sa1100 and one for mach-pxa. The pxafb driver only makes use of two macros, which can be trivially open-coded in the header. Cc: dri-devel@lists.freedesktop.org Acked-by:
-
Arnd Bergmann authored
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 <linux/soc/pxa/cpu.h> 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 <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Acked-by:
-
Arnd Bergmann authored
The file no longer contains anything useful, so remove it. Acked-by:
-
Arnd Bergmann authored
This is not used by any drivers, so make it private to the platform. Acked-by:
-
Arnd Bergmann authored
No driver includes this any more, so don't expose it globally. Acked-by:
-
Arnd Bergmann authored
Only one declaration from this header is actually used in drivers, so move that one into the global location and leave everything else private. Acked-by:
-
- 03 Apr, 2022 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull more tracing updates from Steven Rostedt: - Rename the staging files to give them some meaning. Just stage1,stag2,etc, does not show what they are for - Check for NULL from allocation in bootconfig - Hold event mutex for dyn_event call in user events - Mark user events to broken (to work on the API) - Remove eBPF updates from user events - Remove user events from uapi header to keep it from being installed. - Move ftrace_graph_is_dead() into inline as it is called from hot paths and also convert it into a static branch. * tag 'trace-v5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Move user_events.h temporarily out of include/uapi ftrace: Make ftrace_graph_is_dead() a static branch tracing: Set user_events to BROKEN tracing/user_events: Remove eBPF interfaces tracing/user_events: Hold event_mutex during dyn_event_add proc: bootconfig: Add null pointer check tracing: Rename the staging files for trace_events
-
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linuxLinus Torvalds authored
Pull clk fix from Stephen Boyd: "A single revert to fix a boot regression seen when clk_put() started dropping rate range requests. It's best to keep various systems booting so we'll kick this out and try again next time" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: Revert "clk: Drop the rate range on clk_put()"
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A set of x86 fixes and updates: - Make the prctl() for enabling dynamic XSTATE components correct so it adds the newly requested feature to the permission bitmap instead of overwriting it. Add a selftest which validates that. - Unroll string MMIO for encrypted SEV guests as the hypervisor cannot emulate it. - Handle supervisor states correctly in the FPU/XSTATE code so it takes the feature set of the fpstate buffer into account. The feature sets can differ between host and guest buffers. Guest buffers do not contain supervisor states. So far this was not an issue, but with enabling PASID it needs to be handled in the buffer offset calculation and in the permission bitmaps. - Avoid a gazillion of repeated CPUID invocations in by caching the values early in the FPU/XSTATE code. - Enable CONFIG_WERROR in x86 defconfig. - Make the X86 defconfigs more useful by adapting them to Y2022 reality" * tag 'x86-urgent-2022-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu/xstate: Consolidate size calculations x86/fpu/xstate: Handle supervisor states in XSTATE permissions x86/fpu/xsave: Handle compacted offsets correctly with supervisor states x86/fpu: Cache xfeature flags from CPUID x86/fpu/xsave: Initialize offset/size cache early x86/fpu: Remove unused supervisor only offsets x86/fpu: Remove redundant XCOMP_BV initialization x86/sev: Unroll string mmio with CC_ATTR_GUEST_UNROLL_STRING_IO x86/config: Make the x86 defconfigs a bit more usable x86/defconfig: Enable WERROR selftests/x86/amx: Update the ARCH_REQ_XCOMP_PERM test x86/fpu/xstate: Fix the ARCH_REQ_XCOMP_PERM implementation -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull RT signal fix from Thomas Gleixner: "Revert the RT related signal changes. They need to be reworked and generalized" * tag 'core-urgent-2022-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "signal, x86: Delay calling signals in atomic on RT enabled kernels"
-
