Re: [PATCH v4 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

no-map; > > + }; > > + > > + dsp_vdev0buffer: vdev0buffer@9430 { > > + compatible = "shared-dma-pool"; > > + reg = <0 0x9430 0 0x10>; > > + no-map; > > + }; &g

Re: [PATCH v3 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

Hi Iuliana, Am Freitag, 13. Oktober 2023, 10:35:17 CEST schrieb Iuliana Prodan: > Hi Alexander, > > On 10/11/2023 8:37 AM, Alexander Stein wrote: > > Hi Iuliana, > > > > Am Dienstag, 10. Oktober 2023, 11:09:29 CEST schrieb Iuliana Prodan (OSS): > >>

Re: [PATCH v3 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

Hi Iuliana, Am Dienstag, 10. Oktober 2023, 11:09:29 CEST schrieb Iuliana Prodan (OSS): > From: Iuliana Prodan > > Add the reserve-memory nodes used by DSP when the rpmsg > feature is enabled. > > Signed-off-by: Iuliana Prodan > --- > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16

Re: [PATCH] clk: bcm2835: Fix memory leak in bcm2835_register_pll

Hello, On Thursday, October 10, 2019, 3:30:58 AM CEST Navid Emamdoost wrote: > In the implementation of bcm2835_register_pll(), the allocated memory > for pll should be released if devm_clk_hw_register() fails. > > Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and >

[PATCH v2 1/1] iio: core: Fix fractional format generation

In case the result is -0.3252 tmp0 is 0 after the div_s64_rem, so tmp0 is non-negative which results in an output of 0.3252. Fix this by explicitly handling the negative sign ourselves. Signed-off-by: Alexander Stein --- Changes in v2: * Support vals[0] >= and vals[1] < 0 in IIO_VAL_FRAC

[PATCH 1/1] iio: core: Fix fractional format generation

In case the result is -0.3252 tmp0 is 0 after the div_s64_rem, so tmp0 is non-negative which results in an output of 0.3252. Fix this by explicitly handling the negative sign ourselves. Signed-off-by: Alexander Stein --- drivers/iio/industrialio-core.c | 5 +++-- 1 file changed, 3 insertions

Re: [PATCH] i2c: imx: Allow the driver to be built for ARM64 SoCs such as i.MX8M

On Wednesday, August 7, 2019, 1:44:06 PM CEST Schrempf Frieder wrote: > From: Frieder Schrempf > > The imx I2C controller is used in some ARM64 SoCs such as i.MX8M. > To make use of it, append ARM64 to the list of dependencies. > > Signed-off-by: Frieder Schrempf > --- >

Re: [PATCH v1] gpio: mpc8xxx: Add new platforms GPIO DT node description

On Monday, August 5, 2019, 11:14:32 AM CEST Hui Song wrote: > From: Song Hui > > Update the NXP GPIO node dt-binding file for QorIQ and > Layerscape platforms, and add one more example with > ls1028a GPIO node. > > Signed-off-by: Song Hui > --- >

Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset

On Tuesday, October 16, 2018, 3:30:24 PM CEST claudiu.bez...@microchip.com wrote: > Hi Jonas, > > On 07.10.2018 15:57, Jonas Danielsson wrote: > > From: Jonas Danielsson > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > hang at reboot. At the most we managed 16

Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset

On Tuesday, October 16, 2018, 3:30:24 PM CEST claudiu.bez...@microchip.com wrote: > Hi Jonas, > > On 07.10.2018 15:57, Jonas Danielsson wrote: > > From: Jonas Danielsson > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > hang at reboot. At the most we managed 16

Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset

Do you have CONFIG_CPU_ICACHE_DISABLE enabled? I wonder why I-cache is disabled. I know about this errata, AT91SAM9G20 is affected as well. Best regards, Alexander On Sunday, October 7, 2018, 2:57:45 PM CEST Jonas Danielsson wrote: > From: Jonas Danielsson > > This fixes a bug where our

Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset

Do you have CONFIG_CPU_ICACHE_DISABLE enabled? I wonder why I-cache is disabled. I know about this errata, AT91SAM9G20 is affected as well. Best regards, Alexander On Sunday, October 7, 2018, 2:57:45 PM CEST Jonas Danielsson wrote: > From: Jonas Danielsson > > This fixes a bug where our

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

Hello Arnd, On Tuesday, September 25, 2018, 2:06:38 PM CEST Arnd Bergmann wrote: > We don't really want an empty macro any more, this was used in > the past, but causes compile-time warnings and undefined behavior > for no good reason. Can you elaborate or point me to some other discussion about

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

Hello Arnd, On Tuesday, September 25, 2018, 2:06:38 PM CEST Arnd Bergmann wrote: > We don't really want an empty macro any more, this was used in > the past, but causes compile-time warnings and undefined behavior > for no good reason. Can you elaborate or point me to some other discussion about

Re: [PATCH] staging: most: video: fix registration of an empty comp core_component

On Wednesday, September 5, 2018, 11:46:05 AM CEST Colin King wrote: > From: Colin Ian King > > Currently we have structrues comp (which is empty) and comp_info being > used to register and deregister the component. This mismatch in naming > occurred from a previous commit that renamed aim_info

Re: [PATCH] staging: most: video: fix registration of an empty comp core_component

On Wednesday, September 5, 2018, 11:46:05 AM CEST Colin King wrote: > From: Colin Ian King > > Currently we have structrues comp (which is empty) and comp_info being > used to register and deregister the component. This mismatch in naming > occurred from a previous commit that renamed aim_info

Re: [PATCH] gpio: aspeed: fix compile testing warning

On Monday, July 9, 2018, 4:56:03 PM CEST Arnd Bergmann wrote: > Gcc cannot always see that BUG_ON(1) is guaranteed to not > return, so we get a warning message in some configurations: > > drivers/gpio/gpio-aspeed.c: In function 'bank_reg': > drivers/gpio/gpio-aspeed.c:244:1: error: control

Re: [PATCH] gpio: aspeed: fix compile testing warning

On Monday, July 9, 2018, 4:56:03 PM CEST Arnd Bergmann wrote: > Gcc cannot always see that BUG_ON(1) is guaranteed to not > return, so we get a warning message in some configurations: > > drivers/gpio/gpio-aspeed.c: In function 'bank_reg': > drivers/gpio/gpio-aspeed.c:244:1: error: control

Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe

On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote: > This is needed in case of PROBE_DEFER if IRQ resource is not yet ready. > > Signed-off-by: Keerthy > --- > [...] > --- a/drivers/gpio/gpio-davinci.c > +++ b/drivers/gpio/gpio-davinci.c > [...] > @@ -168,7 +168,7 @@ static int

Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe

On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote: > This is needed in case of PROBE_DEFER if IRQ resource is not yet ready. > > Signed-off-by: Keerthy > --- > [...] > --- a/drivers/gpio/gpio-davinci.c > +++ b/drivers/gpio/gpio-davinci.c > [...] > @@ -168,7 +168,7 @@ static int

Re: [bug, bisected] pfifo_fast causes packet reordering

On Friday, March 16, 2018, 11:26:47 AM CET Jakob Unterwurzacher wrote: > On 15.03.18 23:30, John Fastabend wrote: > >> I have reproduced it using two USB network cards connected to each other. > >> The test tool sends UDP packets containing a counter and listens on the > >> other interface, it

Re: [bug, bisected] pfifo_fast causes packet reordering

On Friday, March 16, 2018, 11:26:47 AM CET Jakob Unterwurzacher wrote: > On 15.03.18 23:30, John Fastabend wrote: > >> I have reproduced it using two USB network cards connected to each other. > >> The test tool sends UDP packets containing a counter and listens on the > >> other interface, it

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 3:06:52 PM CET Rasmus Villemoes wrote: > On 2017-12-11 14:45, Rasmus Villemoes wrote: > > On 2017-12-11 11:02, Alexander Stein wrote: > > > >> Oh, and what is the content of register SCFG_SCFGREVCR? > > > > Good point. On my boar

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 3:06:52 PM CET Rasmus Villemoes wrote: > On 2017-12-11 14:45, Rasmus Villemoes wrote: > > On 2017-12-11 11:02, Alexander Stein wrote: > > > >> Oh, and what is the content of register SCFG_SCFGREVCR? > > > > Good point. On my boar

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 10:45:09 AM CET Alexander Stein wrote: > On Monday, December 11, 2017, 10:08:20 AM CET Rasmus Villemoes wrote: > > >>> +static int > > >>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type) > > >>> +{ >

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 10:45:09 AM CET Alexander Stein wrote: > On Monday, December 11, 2017, 10:08:20 AM CET Rasmus Villemoes wrote: > > >>> +static int > > >>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type) > > >>> +{ >

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 10:08:20 AM CET Rasmus Villemoes wrote: > >>> +static int > >>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type) > >>> +{ > >>> + irq_hw_number_t hwirq = data->hwirq; > >>> + struct extirq_chip_data *chip_data = data->chip_data; > >>> + u32 value,

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On Monday, December 11, 2017, 10:08:20 AM CET Rasmus Villemoes wrote: > >>> +static int > >>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type) > >>> +{ > >>> + irq_hw_number_t hwirq = data->hwirq; > >>> + struct extirq_chip_data *chip_data = data->chip_data; > >>> + u32 value,

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

Hi Rasmus, thanks for your effort. unfortunatly I won't be able to test it currently :( But some comments below. On Friday, December 8, 2017, 3:33:00 PM CET Rasmus Villemoes wrote: > The LS1021A allows inverting the polarity of six interrupt lines > IRQ[0:5] via the scfg_intpcr register,

Re: [RFC] irqchip: add support for LS1021A external interrupt lines

Hi Rasmus, thanks for your effort. unfortunatly I won't be able to test it currently :( But some comments below. On Friday, December 8, 2017, 3:33:00 PM CET Rasmus Villemoes wrote: > The LS1021A allows inverting the polarity of six interrupt lines > IRQ[0:5] via the scfg_intpcr register,

Re: polarity inversion on LS1021a

On Monday, December 4, 2017, 4:37:20 PM CET Marc Zyngier wrote: > On 04/12/17 15:31, Alexander Stein wrote: > > On Monday, December 4, 2017, 4:11:06 PM CET Rasmus Villemoes wrote: > >> The LS1021A has a standard GIC-400, but allows inverting the polarity of > >> six e

Re: polarity inversion on LS1021a

On Monday, December 4, 2017, 4:37:20 PM CET Marc Zyngier wrote: > On 04/12/17 15:31, Alexander Stein wrote: > > On Monday, December 4, 2017, 4:11:06 PM CET Rasmus Villemoes wrote: > >> The LS1021A has a standard GIC-400, but allows inverting the polarity of > >> six e

Re: polarity inversion on LS1021a

Hi Rasmus, On Monday, December 4, 2017, 4:11:06 PM CET Rasmus Villemoes wrote: > The LS1021A has a standard GIC-400, but allows inverting the polarity of > six external interrupt lines via a certain register, effectively > supporting IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. > >

Re: polarity inversion on LS1021a

Hi Rasmus, On Monday, December 4, 2017, 4:11:06 PM CET Rasmus Villemoes wrote: > The LS1021A has a standard GIC-400, but allows inverting the polarity of > six external interrupt lines via a certain register, effectively > supporting IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. > >

tools/iio: build race condition

Hi, I tried to compile the new v4.14 kernel and hit a race condition in the build system of tools/iio. Here is my output (sorry for German strings, I wasn't able to reproduce with LANG=C): > {master linux} % make O=build_x86/ -j9 tools/iio > make[1]: Verzeichnis

tools/iio: build race condition

Hi, I tried to compile the new v4.14 kernel and hit a race condition in the build system of tools/iio. Here is my output (sorry for German strings, I wasn't able to reproduce with LANG=C): > {master linux} % make O=build_x86/ -j9 tools/iio > make[1]: Verzeichnis

Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s

On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote: > On 8/15/2017 4:13 PM, Haris Okanovic wrote: > > ioread8() operations to TPM MMIO addresses can stall the cpu when > > immediately following a sequence of iowrite*()'s to the same region. > > > > For example, cyclitest measures ~400us

Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s

On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote: > On 8/15/2017 4:13 PM, Haris Okanovic wrote: > > ioread8() operations to TPM MMIO addresses can stall the cpu when > > immediately following a sequence of iowrite*()'s to the same region. > > > > For example, cyclitest measures ~400us

Re: [PATCH] tpm_tis: fix stall after iowrite*()s

On Monday 14 August 2017 17:53:47, Haris Okanovic wrote: > --- a/drivers/char/tpm/tpm_tis.c > +++ b/drivers/char/tpm/tpm_tis.c > @@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy > *to_tpm_tis_tcg_phy(struct tpm_tis_data *da return container_of(data, > struct tpm_tis_tcg_phy, priv); > } >

Re: [PATCH] tpm_tis: fix stall after iowrite*()s

On Monday 14 August 2017 17:53:47, Haris Okanovic wrote: > --- a/drivers/char/tpm/tpm_tis.c > +++ b/drivers/char/tpm/tpm_tis.c > @@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy > *to_tpm_tis_tcg_phy(struct tpm_tis_data *da return container_of(data, > struct tpm_tis_tcg_phy, priv); > } >

Re: [PATCH 4/6] gpio: mxc: use devres for irq generic chip

Hi, On Wednesday 02 August 2017 09:51:24, Bartosz Golaszewski wrote: > Use resource managed variants of irq_alloc_generic_chip() and > irq_setup_generic_chip(). Is this really useful for drivers which can only be built-in? This is probably valid for the other drives as well. Best regards,

Re: [PATCH 4/6] gpio: mxc: use devres for irq generic chip

Hi, On Wednesday 02 August 2017 09:51:24, Bartosz Golaszewski wrote: > Use resource managed variants of irq_alloc_generic_chip() and > irq_setup_generic_chip(). Is this really useful for drivers which can only be built-in? This is probably valid for the other drives as well. Best regards,

Re: [PATCH V2 2/2] timer: imx-tpm: add imx tpm timer support

On Tuesday 13 June 2017 15:58:45, Dong Aisheng wrote: > diff --git a/drivers/clocksource/timer-imx-tpm.c > b/drivers/clocksource/timer-imx-tpm.c new file mode 100644 > index 000..940a4f75 > --- /dev/null > +++ b/drivers/clocksource/timer-imx-tpm.c > @@ -0,0 +1,227 @@ > [...] > +static int

Re: [PATCH V2 2/2] timer: imx-tpm: add imx tpm timer support

On Tuesday 13 June 2017 15:58:45, Dong Aisheng wrote: > diff --git a/drivers/clocksource/timer-imx-tpm.c > b/drivers/clocksource/timer-imx-tpm.c new file mode 100644 > index 000..940a4f75 > --- /dev/null > +++ b/drivers/clocksource/timer-imx-tpm.c > @@ -0,0 +1,227 @@ > [...] > +static int

Re: [PATCH 1/2] clk: bcm2835: Add AUX interrupt controller

On Wednesday, June 7, 2017, 2:37:41 PM CEST Phil Elwell wrote: > On 07/06/2017 13:07, Alexander Stein wrote: > > On Wednesday 07 June 2017 12:11:45, Phil Elwell wrote: > >> Devices in the AUX block share a common interrupt line, with a register > >> indicating whi

Re: [PATCH 1/2] clk: bcm2835: Add AUX interrupt controller

On Wednesday, June 7, 2017, 2:37:41 PM CEST Phil Elwell wrote: > On 07/06/2017 13:07, Alexander Stein wrote: > > On Wednesday 07 June 2017 12:11:45, Phil Elwell wrote: > >> Devices in the AUX block share a common interrupt line, with a register > >> indicating whi

Re: [PATCH 1/2] clk: bcm2835: Add AUX interrupt controller

On Wednesday 07 June 2017 12:11:45, Phil Elwell wrote: > Devices in the AUX block share a common interrupt line, with a register > indicating which devices have active IRQs. Expose this as a nested > interrupt controller to avoid IRQ sharing problems (easily observed if > UART1 and SPI1/2 are

Re: [PATCH 1/2] clk: bcm2835: Add AUX interrupt controller

On Wednesday 07 June 2017 12:11:45, Phil Elwell wrote: > Devices in the AUX block share a common interrupt line, with a register > indicating which devices have active IRQs. Expose this as a nested > interrupt controller to avoid IRQ sharing problems (easily observed if > UART1 and SPI1/2 are

[PATCH 1/1] ARM: imx: Enable REGMAP_MMIO per default

If unset, the gpc drivers fails to link with this error: drivers/built-in.o: In function `imx_gpc_probe': core.c:(.text+0x1e16c): undefined reference to `__devm_regmap_init_mmio_clk' As the gpc driver is built when ARCH_MXC is set, enable REGMAP_MMIO in this case too. Signed-off-by: Alexander

[PATCH 1/1] ARM: imx: Enable REGMAP_MMIO per default

If unset, the gpc drivers fails to link with this error: drivers/built-in.o: In function `imx_gpc_probe': core.c:(.text+0x1e16c): undefined reference to `__devm_regmap_init_mmio_clk' As the gpc driver is built when ARCH_MXC is set, enable REGMAP_MMIO in this case too. Signed-off-by: Alexander

Re: [PATCH v2 1/1] xhci: add USB2 test mode support

On Wednesday 08 February 2017 16:17:45, Mathias Nyman wrote: > On 08.02.2017 15:44, Alexander Stein wrote: > > This patch adds support for USB2 test mode (Test_J, Test_K, > > Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. > > > > USB2 test mode is a required

Re: [PATCH v2 1/1] xhci: add USB2 test mode support

On Wednesday 08 February 2017 16:17:45, Mathias Nyman wrote: > On 08.02.2017 15:44, Alexander Stein wrote: > > This patch adds support for USB2 test mode (Test_J, Test_K, > > Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. > > > > USB2 test mode is a required

[PATCH v2 1/1] xhci: add USB2 test mode support

;Wang, Yu" <yu.y.w...@intel.com> Signed-off-by: "Li, Guanglei" <guangleix...@intel.com> Signed-off-by: "Wu, Hao" <hao...@intel.com> Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- Changes in v2: * Added additional info abou

[PATCH v2 1/1] xhci: add USB2 test mode support

;Wang, Yu" Signed-off-by: "Li, Guanglei" Signed-off-by: "Wu, Hao" Signed-off-by: Alexander Stein --- Changes in v2: * Added additional info about USB2 test modes itself into commit message * Add URL for same test mode feature on ehci hosts. dr

Re: [PATCH 1/1] xhci: add USB2 test mode support

On Wednesday 08 February 2017 13:53:30, Greg Kroah-Hartman wrote: > On Wed, Feb 08, 2017 at 11:26:35AM +0100, Alexander Stein wrote: > > This patch adds support for USB2 test mode (Test_J, Test_K, > > Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. > > What does

Re: [PATCH 1/1] xhci: add USB2 test mode support

On Wednesday 08 February 2017 13:53:30, Greg Kroah-Hartman wrote: > On Wed, Feb 08, 2017 at 11:26:35AM +0100, Alexander Stein wrote: > > This patch adds support for USB2 test mode (Test_J, Test_K, > > Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. > > What does

[PATCH 1/1] xhci: add USB2 test mode support

This patch adds support for USB2 test mode (Test_J, Test_K, Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. Signed-off-by: "Wang, Yu" <yu.y.w...@intel.com> Signed-off-by: "Li, Guanglei" <guangleix...@intel.com> Signed-off-by: "Wu, Hao" <hao

[PATCH 1/1] xhci: add USB2 test mode support

This patch adds support for USB2 test mode (Test_J, Test_K, Test_SE0_NAK and Test_Packet) per XHCI spec 4.19.6. Signed-off-by: "Wang, Yu" Signed-off-by: "Li, Guanglei" Signed-off-by: "Wu, Hao" Signed-off-by: Alexander Stein --- This patch was taken

Re: [PATCH v2 2/2] arm: perf: Mark as non-removable

Hi, On Thursday 22 December 2016 22:48:32, Mark Rutland wrote: > On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote: > > This driver can only built into the kernel. So disallow driver bind/unbind > > and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE

Re: [PATCH v2 2/2] arm: perf: Mark as non-removable

Hi, On Thursday 22 December 2016 22:48:32, Mark Rutland wrote: > On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote: > > This driver can only built into the kernel. So disallow driver bind/unbind > > and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE

[PATCH v2 2/2] arm: perf: Mark as non-removable

This driver can only built into the kernel. So disallow driver bind/unbind and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is enabled. Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- arch/arm/kernel/perf_event_v7.c | 1 + 1 file changed, 1 ins

[PATCH v2 1/2] drivers/perf: arm_pmu: Use devm_ allocators

This eliminates several calls to kfree. Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- drivers/perf/arm_pmu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index b37b572..a

[PATCH v2 0/2] mark driver as non-removable

806febcc>] (kernel_init+0x10/0x11c) r10: r9: r8: r7: r6: r5:806febbc r4: [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c) r5:806febbc r4: ---[ end trace 9d251d389382804f ]--- This patchset marks the driver as ex

[PATCH v2 2/2] arm: perf: Mark as non-removable

This driver can only built into the kernel. So disallow driver bind/unbind and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is enabled. Signed-off-by: Alexander Stein --- arch/arm/kernel/perf_event_v7.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/kernel

[PATCH v2 1/2] drivers/perf: arm_pmu: Use devm_ allocators

This eliminates several calls to kfree. Signed-off-by: Alexander Stein --- drivers/perf/arm_pmu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index b37b572..a9bbdbf 100644 --- a/drivers/perf/arm_pmu.c +++ b

[PATCH v2 0/2] mark driver as non-removable

806febcc>] (kernel_init+0x10/0x11c) r10: r9: r8: r7: r6: r5:806febbc r4: [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c) r5:806febbc r4: ---[ end trace 9d251d389382804f ]--- This patchset marks the driver as ex

Re: [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove

On Wednesday 21 December 2016 14:38:54, Peter Zijlstra wrote: > On Wed, Dec 21, 2016 at 11:19:34AM +0100, Alexander Stein wrote: > > Add ARM PMU removal function. This will be required by perf event drivers > > when option DEBUG_TEST_DRIVER_REMOVE is enabled. > > > &g

Re: [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove

On Wednesday 21 December 2016 14:38:54, Peter Zijlstra wrote: > On Wed, Dec 21, 2016 at 11:19:34AM +0100, Alexander Stein wrote: > > Add ARM PMU removal function. This will be required by perf event drivers > > when option DEBUG_TEST_DRIVER_REMOVE is enabled. > > > &g

[PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove

Add ARM PMU removal function. This will be required by perf event drivers when option DEBUG_TEST_DRIVER_REMOVE is enabled. Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- drivers/perf/arm_pmu.c | 14 ++ include/linux/perf/arm_pmu.h | 2 ++ 2

[PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove

Add ARM PMU removal function. This will be required by perf event drivers when option DEBUG_TEST_DRIVER_REMOVE is enabled. Signed-off-by: Alexander Stein --- drivers/perf/arm_pmu.c | 14 ++ include/linux/perf/arm_pmu.h | 2 ++ 2 files changed, 16 insertions(+) diff --git

[PATCH 0/3] arm perf: Support DEBUG_TEST_DRIVER_REMOVE

00 [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c) r5:806febbc r4: ---[ end trace 9d251d389382804f ]--- This patchset add a removal support for arm_pmu and perf_events_v7 and while at it, use devm_ allocators in arm_pmu. Alexander Stein (3): dri

[PATCH 0/3] arm perf: Support DEBUG_TEST_DRIVER_REMOVE

00 [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c) r5:806febbc r4: ---[ end trace 9d251d389382804f ]--- This patchset add a removal support for arm_pmu and perf_events_v7 and while at it, use devm_ allocators in arm_pmu. Alexander Stein (3): dri

[PATCH 1/3] drivers/perf: arm_pmu: Use devm_ allocators

This eliminates several calls to kfree. Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- drivers/perf/arm_pmu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index b37b572..a

[PATCH 1/3] drivers/perf: arm_pmu: Use devm_ allocators

This eliminates several calls to kfree. Signed-off-by: Alexander Stein --- drivers/perf/arm_pmu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index b37b572..a9bbdbf 100644 --- a/drivers/perf/arm_pmu.c +++ b

[PATCH 3/3] arm: perf: Add platform driver removal function

Despite the driver cannot be built as a module using the option DEBUG_TEST_DRIVER_REMOVE requires the drivers to actually remove the device. Signed-off-by: Alexander Stein <alexander.st...@systec-electronic.com> --- arch/arm/kernel/perf_event_v7.c | 6 ++ 1 file changed, 6 inse

[PATCH 3/3] arm: perf: Add platform driver removal function

Despite the driver cannot be built as a module using the option DEBUG_TEST_DRIVER_REMOVE requires the drivers to actually remove the device. Signed-off-by: Alexander Stein --- arch/arm/kernel/perf_event_v7.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/kernel/perf_event_v7

Re: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

On Monday 14 November 2016 16:12:27, Michael Walle wrote: > Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy > cards in __mmc_switch()") the ESDHC driver is broken: > mmc0: Card stuck in programming state! __mmc_switch > mmc0: error -110 whilst initialising MMC card > >

Re: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

On Monday 14 November 2016 16:12:27, Michael Walle wrote: > Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy > cards in __mmc_switch()") the ESDHC driver is broken: > mmc0: Card stuck in programming state! __mmc_switch > mmc0: error -110 whilst initialising MMC card > >

Re: [PATCH v4] i2c: designware: Implement support for SMBus block read and write

MBUS_BYTE_DATA | > I2C_FUNC_SMBUS_WORD_DATA | > + I2C_FUNC_SMBUS_BLOCK_DATA | > I2C_FUNC_SMBUS_I2C_BLOCK; > > dev->master_cfg = DW_IC_CON_MASTER | DW_IC_CON_SLAVE_DISABLE | Shouldn't those functionality bits moved to a common place, like i2c- des

Re: [PATCH v4] i2c: designware: Implement support for SMBus block read and write

MBUS_BYTE_DATA | > I2C_FUNC_SMBUS_WORD_DATA | > + I2C_FUNC_SMBUS_BLOCK_DATA | > I2C_FUNC_SMBUS_I2C_BLOCK; > > dev->master_cfg = DW_IC_CON_MASTER | DW_IC_CON_SLAVE_DISABLE | Shouldn't those functionality bits moved to a common place, like i2c- des

Re: [PATCH] gpio: mcp23s08: Add option to configure pullups.

On Monday 24 October 2016 02:53:31, Linus Walleij wrote: > On Fri, Oct 21, 2016 at 5:00 PM, Enric Balletbo i Serra > > wrote: > > Default is without pullups, but if property is specified in DT and the bit > > is set, set a pullup on GPIO-n. > > > > Signed-off-by:

Re: [PATCH] gpio: mcp23s08: Add option to configure pullups.

On Monday 24 October 2016 02:53:31, Linus Walleij wrote: > On Fri, Oct 21, 2016 at 5:00 PM, Enric Balletbo i Serra > > wrote: > > Default is without pullups, but if property is specified in DT and the bit > > is set, set a pullup on GPIO-n. > > > > Signed-off-by: Enric Balletbo i Serra > > I

Re: [PATCH 0/2] ARM: at91: properly handle LPDDR poweroff

Hi Alexandre, On Friday 07 October 2016 18:34:25, Alexandre Belloni wrote: > Hi, > > This patch set improves LPDDR support on SoCs using the Atmel MPDDR > controller. > > LPDDR memoris can only handle up to 400 uncontrolled power offs in their > life. The proper power off sequence has to be

Re: [PATCH 0/2] ARM: at91: properly handle LPDDR poweroff

Hi Alexandre, On Friday 07 October 2016 18:34:25, Alexandre Belloni wrote: > Hi, > > This patch set improves LPDDR support on SoCs using the Atmel MPDDR > controller. > > LPDDR memoris can only handle up to 400 uncontrolled power offs in their > life. The proper power off sequence has to be

Re: [PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

On Thursday 08 September 2016 10:04:55, Meng Yi wrote: > If the FTM counter reaches the FTM_MOD value between the reading of the > TOF bit and the writing of 0 to the TOF bit, the process of clearing the > TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the > current TOF count is

Re: [PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

On Thursday 08 September 2016 10:04:55, Meng Yi wrote: > If the FTM counter reaches the FTM_MOD value between the reading of the > TOF bit and the writing of 0 to the TOF bit, the process of clearing the > TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the > current TOF count is

Re: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

On Thursday 18 August 2016 14:38:47, Yuan Yao wrote: > From: Yuan Yao > > Add the QDMA node for ls1043a platform to > support QDMA driver. > > Signed-off-by: Yuan Yao > --- > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++ > 1 file changed,

Re: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

On Thursday 18 August 2016 14:38:47, Yuan Yao wrote: > From: Yuan Yao > > Add the QDMA node for ls1043a platform to > support QDMA driver. > > Signed-off-by: Yuan Yao > --- > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git

Re: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

On Thursday 18 August 2016 14:38:47, Yuan Yao wrote: > From: Yuan Yao > > Add the QDMA node for ls1043a platform to > support QDMA driver. > > Signed-off-by: Yuan Yao > --- > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++ > 1 file changed,

Re: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

On Thursday 18 August 2016 14:38:47, Yuan Yao wrote: > From: Yuan Yao > > Add the QDMA node for ls1043a platform to > support QDMA driver. > > Signed-off-by: Yuan Yao > --- > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On Thursday 04 August 2016 15:58:35, York Sun wrote: > Add DDR EDAC for ARM-based compatible controllers. Both big-endian > and little-endian are supported. > > Signed-off-by: York Sun > > --- > Change log > v3: no change > v2: Create new driver using shared DDR object >

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On Thursday 04 August 2016 15:58:35, York Sun wrote: > Add DDR EDAC for ARM-based compatible controllers. Both big-endian > and little-endian are supported. > > Signed-off-by: York Sun > > --- > Change log > v3: no change > v2: Create new driver using shared DDR object > >

Re: [PATCH v4 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Thursday 04 August 2016 15:28:18, Ksenija Stanojevic wrote: > Add core files for mxs-lradc MFD driver. > > Note: this patch won't compile in iio/testing without this patch: > a8f447be8056 ("mfd: Add resource managed APIs for mfd_add_devices") > > Signed-off-by: Ksenija Stanojevic

Re: [PATCH v4 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Thursday 04 August 2016 15:28:18, Ksenija Stanojevic wrote: > Add core files for mxs-lradc MFD driver. > > Note: this patch won't compile in iio/testing without this patch: > a8f447be8056 ("mfd: Add resource managed APIs for mfd_add_devices") > > Signed-off-by: Ksenija Stanojevic > --- >

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote: > On 26/07/2016 11:05, Alexander Stein wrote: > > On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > >> On 26/07/2016 10:21, Alexander Stein wrote: > >>> On Tuesday 26 July 2016

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote: > On 26/07/2016 11:05, Alexander Stein wrote: > > On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > >> On 26/07/2016 10:21, Alexander Stein wrote: > >>> On Tuesday 26 July 2016

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > On 26/07/2016 10:21, Alexander Stein wrote: > > On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote: > >> iio_channel_get_all returns -ENODEV when it cannot find either phandles > >> and > >> prope

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > On 26/07/2016 10:21, Alexander Stein wrote: > > On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote: > >> iio_channel_get_all returns -ENODEV when it cannot find either phandles > >> and > >> prope

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote: > iio_channel_get_all returns -ENODEV when it cannot find either phandles and > properties in the Device Tree or channels whose consumer_dev_name matches > iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers > which might

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote: > iio_channel_get_all returns -ENODEV when it cannot find either phandles and > properties in the Device Tree or channels whose consumer_dev_name matches > iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers > which might

  1   2   3   >