Re: [PATCH] ASoC: do not include pm_runtime.h if not used

On 10.03.2023 09:29, Srinivas Kandagatla wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 07/03/2023 10:30, Claudiu Beznea wrote: >> diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c >> index 41db6617e2ed..dc892fa

Re: [PATCH v2] hvc/xen: prevent concurrent accesses to the shared ring

On Fri, Mar 10, 2023 at 10:01:39AM +1100, Michael Ellerman wrote: > Roger Pau Monné writes: > > On Mon, Dec 12, 2022 at 01:36:48PM +0100, Roger Pau Monné wrote: > >> On Fri, Dec 02, 2022 at 12:40:05PM +0100, Roger Pau Monné wrote: > >> > On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini

Re: [PATCH] KVM: PPC: Mark three local functions "static"

Sean Christopherson writes: > Tag a few functions that are local and don't have a previous prototype as > "static". > > No functional change intended. > > Reported-by: kernel test robot > Link: > https://lore.kernel.org/oe-kbuild-all/202303031630.ntviuyqo-...@intel.com > Signed-off-by: Sean Chri

Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml

On Mon, 6 Mar 2023 at 22:27, Sean Anderson wrote: > > On 3/6/23 15:51, Jonas Gorski wrote: > > Hi, > > > > On Mon, 6 Mar 2023 at 20:16, Sean Anderson wrote: > >> > >> This is a generic binding for simple MMIO GPIO controllers. Although we > >> have a single driver for these controllers, they were

Re: [PATCH v2] vdso: Improve cmd_vdso_check to check all dynamic relocations

Hi Fangrui, Apologize for the delay, I totally missed that you had a new version of your patch since it was threaded with the old one. On 12/21/22 23:51, Fangrui Song wrote: > The actual intention is that no dynamic relocation exists. However, some > GNU ld ports produce unneeded R_*_NONE. (If a

[PATCH] powerpc: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when

[PATCH] powerpc: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- arch/powerpc/kernel/

[PATCH] cpufreq: pmac32: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- drivers/cpufreq/pmac

[PATCH] hwmon: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when

[PATCH] ASoC: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- sound/soc/codecs/sta

[PATCH] soc: fsl: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when

[PATCH] PCI: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when

[PATCH] serial: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- drivers/tty/serial/i

[PATCH] macintosh: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when

[PATCH] net: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- drivers/net/can/cc77

Re: [PATCH] serial: Use of_property_read_bool() for boolean properties

On Fri, Mar 10, 2023 at 08:47:27AM -0600, Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. > Convert reading boolean properties to to of_propert

Re: [PATCH] hwmon: Use of_property_present() for testing DT property presence

On Fri, Mar 10, 2023 at 08:47:06AM -0600, Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. As > part of this, convert of_get_property/of_find_pr

[PATCH v4 2/4] PCI: Split pci_bus_for_each_resource_p() out of pci_bus_for_each_resource()

Refactor pci_bus_for_each_resource() in the same way as it's done in pci_dev_for_each_resource() case. This will allow to hide iterator inside the loop, where it's not used otherwise. No functional changes intended. Signed-off-by: Andy Shevchenko Reviewed-by: Krzysztof Wilczyński --- .clang-fo

[PATCH v4 0/4] PCI: Add pci_dev_for_each_resource() helper and update users

Provide two new helper macros to iterate over PCI device resources and convert users. Looking at it, refactor existing pci_bus_for_each_resource() and convert users accordingly. Changelog v4: - rebased on top of v6.3-rc1 - added tag (Krzysztof) Changelog v3: - rebased on top of v2 by Mika, see a

[PATCH v4 3/4] EISA: Convert to use pci_bus_for_each_resource_p()

The pci_bus_for_each_resource_p() hides the iterator loop since it may be not used otherwise. With this, we may drop that iterator variable definition. Signed-off-by: Andy Shevchenko Reviewed-by: Krzysztof Wilczyński --- drivers/eisa/pci_eisa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 delet

[PATCH v4 4/4] pcmcia: Convert to use pci_bus_for_each_resource_p()

The pci_bus_for_each_resource_p() hides the iterator loop since it may be not used otherwise. With this, we may drop that iterator variable definition. Signed-off-by: Andy Shevchenko Reviewed-by: Krzysztof Wilczyński Acked-by: Dominik Brodowski --- drivers/pcmcia/rsrc_nonstatic.c | 9 +++--

[PATCH v4 1/4] PCI: Introduce pci_dev_for_each_resource()

From: Mika Westerberg Instead of open-coding it everywhere introduce a tiny helper that can be used to iterate over each resource of a PCI device, and convert the most obvious users into it. While at it drop doubled empty line before pdev_sort_resources(). No functional changes intended. Sugge

Re: [PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()

Le 09/03/2023 à 19:02, Hari Bathini a écrit : > patch_instruction() entails setting up pte, patching the instruction, > clearing the pte and flushing the tlb. If multiple instructions need > to be patched, every instruction would have to go through the above > drill unnecessarily. Instead, introd

[PATCH v3] vdso: Improve cmd_vdso_check to check all dynamic relocations

The actual intention is that no dynamic relocation exists. However, some GNU ld ports produce unneeded R_*_NONE. (If a port fails to determine the exact .rel[a].dyn size, the trailing zeros become R_*_NONE relocations. E.g. ld's powerpc port recently fixed https://sourceware.org/bugzilla/show_bug.c

Re: [PATCH v2] vdso: Improve cmd_vdso_check to check all dynamic relocations

On 2023-03-10, Vincenzo Frascino wrote: Hi Fangrui, Apologize for the delay, I totally missed that you had a new version of your patch since it was threaded with the old one. Thank you! No worries. On 12/21/22 23:51, Fangrui Song wrote: The actual intention is that no dynamic relocation e

Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures

On 3/10/23 02:45, Baoquan He wrote: On 03/09/23 at 03:36pm, Thomas Bogendoerfer wrote: On Wed, Mar 08, 2023 at 09:07:09PM +0800, Baoquan He wrote: ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior. So re

Re: [PATCH v4 1/4] PCI: Introduce pci_dev_for_each_resource()

Hi Andy, I love your patch! Yet something to improve: [auto build test ERROR on pci/next] [also build test ERROR on pci/for-linus powerpc/next powerpc/fixes linus/master v6.3-rc1 next-20230310] [cannot apply to soc/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note

[PATCH V6 00/15] Add support for stacked/parallel memories

This patch is in the continuation to the discussions which happened on 'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for adding dt-binding support for stacked/parallel memories. This patch series updated the spi-nor, spi core and the spi drivers to add stacked and parallel memo

[PATCH V6 01/15] spi: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 02/15] net: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 03/15] iio: imu: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 04/15] mtd: devices: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 05/15] staging: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 06/15] platform/x86: serial-multi-instantiate: Replace all spi->chip_select and spi->cs_gpiod references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 07/15] powerpc/83xx/mpc832x_rdb: Replace all spi->chip_select references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 08/15] ALSA: hda: cs35l41: Replace all spi->chip_select references with function call

Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select

[PATCH V6 09/15] spi: Add stacked and parallel memories support in SPI core

For supporting multiple CS the SPI device need to be aware of all the CS values. So, the "chip_select" member in the spi_device structure is now an array that holds all the CS values. spi_device structure now has a "cs_index_mask" member. This acts as an index to the chip_select array. If nth bit

[PATCH V6 10/15] mtd: spi-nor: Convert macros with inline functions

In further patches the nor->params references in spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros will be replaced with spi_nor_get_params() API. To make the transition smoother, first converting the macros into static inline functions. Suggested-by: Michal Simek Signed-off-by: Ami

[PATCH V6 11/15] mtd: spi-nor: Add APIs to set/get nor->params

Supporting multi-cs in spi-nor would require the *params member of struct spi_nor to be an array. To make the transition smoother introduced spi_nor_get_params() & spi_nor_set_params() APIs to get & set nor->params, added a new local variable (struct spi_nor_flash_parameter *params) to hold the ret

[PATCH V6 12/15] mtd: spi-nor: Add stacked memories support in spi-nor

Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked configuration. The current imp

[PATCH V6 13/15] spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver

GQSPI supports two chip select CS0 & CS1. Update the driver to assert/de-assert the appropriate chip select as per the bits set in qspi->cs_index_mask. Signed-off-by: Amit Kumar Mahapatra --- drivers/spi/spi-zynqmp-gqspi.c | 21 + 1 file changed, 13 insertions(+), 8 deletions

[PATCH V6 14/15] mtd: spi-nor: Add parallel memories support in spi-nor

The current implementation assumes that a maximum of two flashes are connected in parallel mode. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st

[PATCH V6 15/15] spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver

During GQSPI driver probe set ctlr->multi-cs-cap for enabling multi CS capability of the controller. In parallel mode the controller can either split the data between both the flash or can send the same data to both the flashes, this is determined by the STRIPE bit. While sending commands to the fl

Re: [PATCH v2 2/4] powerpc/bpf: implement bpf_arch_text_copy

On Thu, Mar 9, 2023 at 10:02 AM Hari Bathini wrote: > > bpf_arch_text_copy is used to dump JITed binary to RX page, allowing > multiple BPF programs to share the same page. Use the newly introduced > patch_instructions() to implement it. Around 5X improvement in speed > of execution observed, usin

Re: [PATCH v2 3/4] powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack

On Thu, Mar 9, 2023 at 10:02 AM Hari Bathini wrote: > > Implement bpf_arch_text_invalidate and use it to fill unused part of > the bpf_prog_pack with trap instructions when a BPF program is freed. > > Signed-off-by: Hari Bathini > --- > arch/powerpc/net/bpf_jit_comp.c | 15 +++ > 1 f

Re: [PATCH v4 1/4] PCI: Introduce pci_dev_for_each_resource()

On Fri, Mar 10, 2023 at 07:14:13PM +0200, Andy Shevchenko wrote: > +#define __pci_dev_for_each_resource(dev, res, __i, vartype) \ > + for (vartype __i = 0; \ > + res = &(dev)->resource[__i], __i < PCI_NUM_RESOURCES; \ > +

Re: [PATCH v2 4/4] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]

On Thu, Mar 9, 2023 at 10:03 AM Hari Bathini wrote: > > Use bpf_jit_binary_pack_alloc in powerpc jit. The jit engine first > writes the program to the rw buffer. When the jit is done, the program > is copied to the final location with bpf_jit_binary_pack_finalize. > With multiple jit_subprogs, bpf

[PATCH 5/6] soc: fsl: dpio: Suppress duplicated error reporting on device remove

Returning an error code from a fsl_mc_driver's remove callback results in a generic error message, otherwise the value is ignored and the device gets unbound. As the only error path in dpaa2_dpio_remove() already emits an error message, return zero unconditionally to suppress another (less helpful

[PATCH 0/6] bus: fsl-mc: Make remove function return void

Hello, many bus remove functions return an integer which is a historic misdesign that makes driver authors assume that there is some kind of error handling in the upper layers. This is wrong however and returning and error code only yields an error message. This series improves the fsl-mc bus by

[PATCH 6/6] bus: fsl-mc: Make remove function return void

From: Uwe Kleine-König The value returned by an fsl-mc driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero and then device removal continues unconditionally.) So change the prototype of the remove function to return no value. This way driver au

[PATCH 1/2] ppc: simplify one-level sysctl registration for powersave_nap_ctl_table

There is no need to declare an extra tables to just create directory, this can be easily be done with a prefix path with register_sysctl(). Simplify this registration. Signed-off-by: Luis Chamberlain --- arch/powerpc/kernel/idle.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-)

[PATCH 2/2] ppc: simplify one-level sysctl registration for nmi_wd_lpm_factor_ctl_table

There is no need to declare an extra tables to just create directory, this can be easily be done with a prefix path with register_sysctl(). Simplify this registration. Signed-off-by: Luis Chamberlain --- arch/powerpc/platforms/pseries/mobility.c | 10 +- 1 file changed, 1 insertion(+),

[PATCH 0/2] ppc: simplify sysctl registration

We can simplify the way we do sysctl registration both by reducing the number of lines and also avoiding calllers which could do recursion. The docs are being updated to help reflect this better [0]. [0] https://lore.kernel.org/all/20230310223947.3917711-1-mcg...@kernel.org/T/#u Luis Chambe

Re: [PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()

Le 10/03/2023 à 19:26, Christophe Leroy a écrit : > > > Le 09/03/2023 à 19:02, Hari Bathini a écrit : >> patch_instruction() entails setting up pte, patching the instruction, >> clearing the pte and flushing the tlb. If multiple instructions need >> to be patched, every instruction would have t