Re: [RESEND PATCH v8 net-next 03/15] net: mvpp2: add CM3 SRAM memory map

Hi Stefan, On Sun, Feb 07 2021, stef...@marvell.com wrote: > From: Stefan Chulski > > This patch adds CM3 memory map and CM3 read/write callbacks. > No functionality changes. > > Signed-off-by: Stefan Chulski > --- > drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 7 +++ >

Re: [PATCH 03/11] dts: mvebu: Add pin control definitions for SDIO interafce

Hi Konstantin, On Wed, Feb 03 2021, kos...@marvell.com wrote: > From: Konstantin Porotchkin > > Add SDIO mode pin control configration for CP0 on A8K DB. This patch does not touch the A8K DB device-tree file. baruch > > Signed-off-by: Konstantin Porotchkin > --- >

Re: [PATCH 02/11] dts: mvebu: Update A8K AP806 SDHCI settings

Hi Konstantin, On Wed, Feb 03 2021, kos...@marvell.com wrote: > From: Konstantin Porotchkin > > Update the settings for AP806 SDHCI interface according to > latest Xenon drivers changes. > - no need to select the PHY slow mode anymore Why? Has anything changed since the introduction of

Re: [PATCH 05/21] rtc: digicolor: quiet maybe-unused variable warning

Hi Alex, On Tue, Feb 02 2021, Alexandre Belloni wrote: > When CONFIG_OF is disabled then the matching table is not referenced. > > Signed-off-by: Alexandre Belloni Acked-by: Baruch Siach Thanks, baruch > --- > drivers/rtc/rtc-digicolor.c | 2 +- > 1 file changed, 1 insert

Re: Old platforms: bring out your dead

Hi Arnd, On Sat, Jan 09 2021, Arnd Bergmann wrote: > * digicolor -- added in 2014, no notable changes after 2015 I have access to the hardware and I'm still interested in maintaining mainline kernel support for it. baruch -- ~. .~ Tk Open

Re: [PATCH] ARM: dts: mvebu: Add device tree for ATL-x530 Board

Hi Aryan, [ Dropped Jason's bouncing address from Cc ] On Mon, Nov 30 2020, Aryan Srivastava wrote: > Add device tree file for x530 board. This has an Armada 385 SoC. Has > NAND-flash for user storage and SPI for booting. Covers majority of x530 > and GS980MX variants. > > Signed-off-by: Aryan

Re: Reusing DTS from arm64 to arm

Hi Vinod, On Tue, Nov 24 2020, Vinod Koul wrote: > We have Qualcomm arm platform which uses PMIC PM8150B. This PMIC was > also used in SM8150 board and is already upstream [1] but in arm64. > > So, what is the guidance to share DTS files between 32 and 64 variants? > Does a solution already exist

Re: [PATCH 2/2] ARM: dts: imx6qdl-cubox-i: enable DSM for the RTC

Hi Miguel, On Sun, Jul 19 2020, miguelborgesdefrei...@gmail.com wrote: > From: Miguel Borges de Freitas > > Signed-off-by: Miguel Borges de Freitas > --- The commit log should explain why you enable this for Cubox-i. The information is in your cover letter. But the cover letter is not

Re: [PATCH][next] i2c: digicolor: Use fallthrough pseudo-keyword

ght=fallthrough#implicit-switch-case-fall-through This URL is likely to break at some point as documentation contest changes. Just refer to in kernel Documentation/process/deprecated.rst file. Other than that: Acked-by: Baruch Siach Thanks, baruch > Signed-off-by: Gustavo A. R. Silva &g

Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed

Hi Andrew, On Tue, Sep 10 2019, Andrew Lunn wrote: > On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote: >> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the >> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device. >> >> Since commit 5502b218e001 ("net:

Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed

Hi tinywrkb, On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote: > Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the > Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device. According to the hardware designer, Rabeeh Khoury, there is not such limitation

Re: [PATCH] watchdog: digicolor_wdt: remove unused variable 'ret'

Hi YueHaibing, On Thu, Jul 11 2019, YueHaibing wrote: > commit cdad26977e3f ("watchdog: digicolor_wdt: drop > warning after registering device") left this unused > variable, it can be removed. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Third time's a charm:

Re: [PATCH] watchdog: digicolor_wdt: drop unused variable

ble] > > Fixes: cdad26977e3f ("watchdog: digicolor_wdt: drop warning after registering > device") > Signed-off-by: Arnd Bergmann Acked-by: Baruch Siach Thanks, baruch > drivers/watchdog/digicolor_wdt.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drive

Re: [PATCH] tty/serial: digicolor: Fix digicolor-usart already registered warning

ter+0x19d/0x270 > > Fix this by adding uart_unregister_driver() when platform_driver_register() > fails. > > Reported-by: Hulk Robot > Signed-off-by: Kefeng Wang Acked-by: Baruch Siach Thanks, baruch > --- > drivers/tty/serial/digicolor-usart.c | 6 +- > 1

Re: [PATCH 2/4] rtc: digicolor: set range

Hi Alexandre, On Tue, Apr 30 2019, Alexandre Belloni wrote: > On 30/04/2019 15:20:08+0300, Baruch Siach wrote: >> On Tue, Apr 30 2019, Alexandre Belloni wrote: >> > On 30/04/2019 14:36:24+0300, Baruch Siach wrote: >> >> Hi Alexandre, >> >> >>

Re: [PATCH 4/4] rtc: digicolor: convert to SPDX identifier

Hi Alexandre, On Tue, Apr 30 2019, Alexandre Belloni wrote: > Use SPDX-License-Identifier instead of a verbose license text. > > Signed-off-by: Alexandre Belloni Acked-by: Baruch Siach baruch > --- > drivers/rtc/rtc-digicolor.c | 6 +- > 1 file changed, 1 inserti

Re: [PATCH 3/4] rtc: digicolor: use .set_time

Hi Alexandre, On Tue, Apr 30 2019, Alexandre Belloni wrote: > Use .set_time instead of the deprecated .set_mmss. > > Signed-off-by: Alexandre Belloni Acked-by: Baruch Siach baruch > --- > drivers/rtc/rtc-digicolor.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 del

Re: [PATCH 2/4] rtc: digicolor: set range

Hi Alexandre, On Tue, Apr 30 2019, Alexandre Belloni wrote: > On 30/04/2019 14:36:24+0300, Baruch Siach wrote: >> Hi Alexandre, >> >> On Tue, Apr 30 2019, Alexandre Belloni wrote: >> >> > While the range of REFERENCE + TIME is actually 33 bits, the counter >

Re: [PATCH 2/4] rtc: digicolor: set range

Hi Alexandre, On Tue, Apr 30 2019, Alexandre Belloni wrote: > While the range of REFERENCE + TIME is actually 33 bits, the counter > itself (TIME) is a 32-bits seconds counter. > > Signed-off-by: Alexandre Belloni > --- > drivers/rtc/rtc-digicolor.c | 1 + > 1 file changed, 1 insertion(+) > >

Re: [PATCH 1/4] rtc: digicolor: fix possible race condition

ice to allocate the rtc > struct before requesting the IRQ. > > Signed-off-by: Alexandre Belloni Acked-by: Baruch Siach baruch > --- > drivers/rtc/rtc-digicolor.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-di

Re: [PATCH v3] ARM: debug-ll: add default address for digicolor

stuck in a loop > waiting for the user to input the number. As we already know > the physical address, this patch provides that number as > default, along with a reasonable default value for the virtual > address. > > Cc: Baruch Siach > Signed-off-by: Arnd Bergmann Review

Re: [PATCH v2] ARM: debug-ll: add default address for digicolor

stuck in a loop > waiting for the user to input the number. As we already know > the physical address, this patch provides that number as > default, along with a reasonable default value for the virtual > address. > > Cc: Baruch Siach > Signed-off-by: Arnd Bergmann > --- &

Re: [PATCH] ARM: debug-ll: add default address for digicolor

ated randconfig build stuck in a loop > waiting for the user to input the number. As we already know > the physical address, this patch provides that number as > default, along with a reasonable default value for the virtual > address. > > Cc: Baruch Siach > Signed-off-

Re: [PATCH v1 2/3] dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding

Hi Marek, Marek Behun writes: >> > +- compatible :must be "marvell,armada-37xx-rwtm-mailbox" >> >> Don't use wildcards in compatible strings. > > You mean that "mailbox" shouldn't be there? You should use '3700' instead of '37xx'. baruch -- http://baruch.siach.name/blog/

Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support

Hi Miquel, Miquel Raynal writes: > Marek Behun wrote on Fri, 14 Dec 2018 01:57:12 > +0100: > >> On Fri, 14 Dec 2018 01:47:01 +0100 >> Marek Behun wrote: >> >> > are there already patches for the A37xx comphy driver? > > Please try the latest patches on top of phy -next (with PHY interface >

Re: [PATCH v3 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs

Hi Andrey, Andrey Smirnov writes: > The driver now supports i.MX8MQ, so update bindings accordingly. > > Cc: p.za...@pengutronix.de > Cc: Fabio Estevam > Cc: cphe...@gmail.com > Cc: l.st...@pengutronix.de > Cc: Leonard Crestez > Cc: "A.s. Dong" > Cc: Richard Zhu > Cc: Rob Herring > Cc:

Re: [v2] PCI: imx: make msi work without pcieportbus

Hi Richard, Richard Zhu writes: >> -Original Message- >> From: Baruch Siach [mailto:bar...@tkos.co.il] >> Sent: 2018年12月13日 16:13 >> To: Richard Zhu >> Cc: bhelg...@google.com; lorenzo.pieral...@arm.com; >> l.st...@pengutronix.de; andrew.smir...@gma

Re: [v2] PCI: imx: make msi work without pcieportbus

Hi Richard, One more comment that occurred to me only now. Richard Zhu writes: > MSI_EN of iMX PCIe RC would be asserted when > PCIEPORTBUS driver is selected. > Thus, the MSI works fine on iMX PCIe before. > Assert it unconditionally when MSI is supported. > Otherwise, the MSI wouldn't be

Re: [PATCH] PCI: imx: make msi work without pcieportbus

Hi Richard, Thanks for debugging this issue. One question below. Richard Zhu writes: > MSI_EN of iMX PCIe RC would be asserted when > PCIEPORTBUS driver is selected. > Thus, the MSI works fine on iMX PCIe before. > Make a double check on this bit, and assert it > when it is not set and MSI is

Re: [PATCH net] net: mvpp2: 10G modes aren't supported on all ports

Hi Antoine, On Wed, Dec 12, 2018 at 03:14:51PM +0100, Antoine Tenart wrote: > On Wed, Dec 12, 2018 at 10:30:33AM +0100, Antoine Tenart wrote: > > On Tue, Dec 11, 2018 at 06:51:56PM +, Russell King - ARM Linux wrote: > > > On Tue, Dec 11, 2018 at 07:53:42PM +0200,

Re: [PATCH net] net: mvpp2: 10G modes aren't supported on all ports

hey support 10G modes in certain cases. This is not true, >> as only the port #0 can do so. This patch fixes it. >> >> Fixes: 01b3fd5ac97c ("net: mvpp2: fix detection of 10G SFP modules") >> Cc: Baruch Siach >> Signed-off-by: Antoine Tenart >> --- >>

Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS

Hi Andrey, Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6. Andrey Smirnov writes: > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n > produces a system where built-in PCIE bridge (16c3:abcd) isn't bound > to pcieport driver. This, in turn, results in a

Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS

Hi Andrey, Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6. Andrey Smirnov writes: > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n > produces a system where built-in PCIE bridge (16c3:abcd) isn't bound > to pcieport driver. This, in turn, results in a

[PATCH] psi: fix reference to kernel commandline enable

The kernel commandline parameter named in CONFIG_PSI_DEFAULT_DISABLED help text contradicts the documentation in kernel-parameters.txt, and the code. Fix that. Fixes: e0c274472d ("psi: make disabling/enabling easier for vendor kernels") Signed-off-by: Baruch Siach --- init/Kconfig |

[PATCH] psi: fix reference to kernel commandline enable

The kernel commandline parameter named in CONFIG_PSI_DEFAULT_DISABLED help text contradicts the documentation in kernel-parameters.txt, and the code. Fix that. Fixes: e0c274472d ("psi: make disabling/enabling easier for vendor kernels") Signed-off-by: Baruch Siach --- init/Kconfig |

Re: [bug report] armada-8040-mcbin: 4.20-rc1 boot failure

Hi Sergey, Gregory, Sergey Matyukevich writes: > MacchiatoBin board fails to boot v4.20-rc1 kernel built using arm64 > defconfig. According to quick bisection of the board dts file, the > root cause is in dts patch enabling CPU deep idle states: > see 8ed46368776b3bc. Is there any pending fix

Re: [bug report] armada-8040-mcbin: 4.20-rc1 boot failure

Hi Sergey, Gregory, Sergey Matyukevich writes: > MacchiatoBin board fails to boot v4.20-rc1 kernel built using arm64 > defconfig. According to quick bisection of the board dts file, the > root cause is in dts patch enabling CPU deep idle states: > see 8ed46368776b3bc. Is there any pending fix

Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"

Hi Russell, Russell King - ARM Linux writes: > On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote: >> I reproduced the same Oops on Clearfog Base without any taint: >> >> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > ... >>

Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"

Hi Russell, Russell King - ARM Linux writes: > On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote: >> I reproduced the same Oops on Clearfog Base without any taint: >> >> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > ... >>

Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"

Hi Jan, Jan Kundrát writes: > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't > finish booting with 4.18-rc3 won't boot: You mean '4.19-rc3', right? >> [1.741458] Internal error: Oops -

Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"

Hi Jan, Jan Kundrát writes: > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't > finish booting with 4.18-rc3 won't boot: You mean '4.19-rc3', right? >> [1.741458] Internal error: Oops -

[PATCH] MAINTAINERS: libata pata: fix Jens Axboe's email address

Commit 7634ccd2da (libata: maintainership update) added an invalid email address. Fix that. Signed-off-by: Baruch Siach --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..9ae5cdef37a1 100644 --- a/MAINTAINERS +++ b

[PATCH] MAINTAINERS: libata pata: fix Jens Axboe's email address

Commit 7634ccd2da (libata: maintainership update) added an invalid email address. Fix that. Signed-off-by: Baruch Siach --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..9ae5cdef37a1 100644 --- a/MAINTAINERS +++ b

Re: [PATCH 2/2] rtc:rtc-ds1347: Use PTR_ERR_OR_ZERO to replace the open code

Hi zhong, On Mon, Aug 13, 2018 at 07:31:25PM +0800, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Baruch Siach Thanks, baruch > --- >

Re: [PATCH 2/2] rtc:rtc-ds1347: Use PTR_ERR_OR_ZERO to replace the open code

Hi zhong, On Mon, Aug 13, 2018 at 07:31:25PM +0800, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Baruch Siach Thanks, baruch > --- >

Re: [PATCH 1/2] rtc:rtc-digicolor: Use PTR_ERR_OR_ZERO to replace the open code

Hi zhong, On Mon, Aug 13, 2018 at 07:31:24PM +0800, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Baruch Siach Thanks, baruch > --- >

Re: [PATCH 1/2] rtc:rtc-digicolor: Use PTR_ERR_OR_ZERO to replace the open code

Hi zhong, On Mon, Aug 13, 2018 at 07:31:24PM +0800, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Baruch Siach Thanks, baruch > --- >

Re: [PATCH] ARM: dts: armada388-helios4

Hi Dennis, On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote: > The helios4 is a Armada388 based nas board designed by SolidRun and > based on their SOM. It is sold by kobol.io the dts file came from >

Re: [PATCH] ARM: dts: armada388-helios4

Hi Dennis, On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote: > The helios4 is a Armada388 based nas board designed by SolidRun and > based on their SOM. It is sold by kobol.io the dts file came from >

Re: [PATCH] ARM: debug: Add Iproc UART3 debug addresses

Hi Clément, On Wed, May 30, 2018 at 02:55:28PM +0200, Clément Péron wrote: > On Wed, 30 May 2018 at 14:47, Baruch Siach wrote: > > On Wed, May 30, 2018 at 02:29:22PM +0200, Clément Péron wrote: > > > From: Clément Peron > > > > > > Broadcom Iproc SoCs typ

Re: [PATCH] ARM: debug: Add Iproc UART3 debug addresses

Hi Clément, On Wed, May 30, 2018 at 02:55:28PM +0200, Clément Péron wrote: > On Wed, 30 May 2018 at 14:47, Baruch Siach wrote: > > On Wed, May 30, 2018 at 02:29:22PM +0200, Clément Péron wrote: > > > From: Clément Peron > > > > > > Broadcom Iproc SoCs typ

Re: [PATCH] ARM: debug: Add Iproc UART3 debug addresses

Hi Clément, On Wed, May 30, 2018 at 02:29:22PM +0200, Clément Péron wrote: > From: Clément Peron > > Broadcom Iproc SoCs typically use the UART3 for > debug/console, provide a known good location for that. > > Signed-off-by: Clément Peron > --- > arch/arm/Kconfig.debug | 12 +++- > 1

Re: [PATCH] ARM: debug: Add Iproc UART3 debug addresses

Hi Clément, On Wed, May 30, 2018 at 02:29:22PM +0200, Clément Péron wrote: > From: Clément Peron > > Broadcom Iproc SoCs typically use the UART3 for > debug/console, provide a known good location for that. > > Signed-off-by: Clément Peron > --- > arch/arm/Kconfig.debug | 12 +++- > 1

Re: uImage target support on arm64

Hi Ramon, On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: > I've noticed that it's not supported. > Is it on purpose ? Yes. The 32bit load address in the uImage header in pretty limited when applied to 64bit ARM64. Even for ARM zImage is the preferred kernel format for quite some

Re: uImage target support on arm64

Hi Ramon, On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: > I've noticed that it's not supported. > Is it on purpose ? Yes. The 32bit load address in the uImage header in pretty limited when applied to 64bit ARM64. Even for ARM zImage is the preferred kernel format for quite some

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Tomasz, On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote: > On Mon, May 7, 2018 at 3:38 PM Baruch Siach <bar...@tkos.co.il> wrote: > > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote: > > > On Thu, May 3, 2018 at 6:09 PM Baruch Siach &

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Tomasz, On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote: > On Mon, May 7, 2018 at 3:38 PM Baruch Siach wrote: > > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote: > > > On Thu, May 3, 2018 at 6:09 PM Baruch Siach wrote: > > > > On Thu, Ma

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Tomasz, On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote: > On Thu, May 3, 2018 at 6:09 PM Baruch Siach <bar...@tkos.co.il> wrote: > > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote: > > > +static int rkisp1_isp_sd_s_power(str

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Tomasz, On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote: > On Thu, May 3, 2018 at 6:09 PM Baruch Siach wrote: > > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote: > > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on) > >

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote: > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on) > +{ > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd); > + int ret; > + > + v4l2_dbg(1, rkisp1_debug, _dev->v4l2_dev, "s_power: %d\n", on); >

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote: > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on) > +{ > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd); > + int ret; > + > + v4l2_dbg(1, rkisp1_debug, _dev->v4l2_dev, "s_power: %d\n", on); >

Re: [PATCH V4] ZBOOT: fix stack protector in compressed boot phase

Hi Huacai, On Wed, Mar 28, 2018 at 04:38:16PM +0800, Huacai Chen wrote: > Call __stack_chk_guard_setup() in decompress_kernel() is too late that > stack checking always fails for decompress_kernel() itself. So remove > __stack_chk_guard_setup() and initialize __stack_chk_guard before we > call

Re: [PATCH V4] ZBOOT: fix stack protector in compressed boot phase

Hi Huacai, On Wed, Mar 28, 2018 at 04:38:16PM +0800, Huacai Chen wrote: > Call __stack_chk_guard_setup() in decompress_kernel() is too late that > stack checking always fails for decompress_kernel() itself. So remove > __stack_chk_guard_setup() and initialize __stack_chk_guard before we > call

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

Hi Ji Zhang, On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote: > When we dump the backtrace of some specific task, there is a potential race > condition due to the task may be running on other cores if SMP enabled. > That is because for current implementation, if the task is not the

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

Hi Ji Zhang, On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote: > When we dump the backtrace of some specific task, there is a potential race > condition due to the task may be running on other cores if SMP enabled. > That is because for current implementation, if the task is not the

Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

Hi Antoine, On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote: > This patch allow the CP100 comphy to configure some lanes in the Should be 'CP110'. > 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the > same code path. > > Signed-off-by: Antoine Tenart

Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

Hi Antoine, On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote: > This patch allow the CP100 comphy to configure some lanes in the Should be 'CP110'. > 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the > same code path. > > Signed-off-by: Antoine Tenart

Re: [PATCH v6 09/17] media: rkisp1: add rockchip isp1 core driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:59PM +0800, Jacob Chen wrote: > +config VIDEO_ROCKCHIP_ISP1 > + tristate "Rockchip Image Signal Processing v1 Unit driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + select

Re: [PATCH v6 09/17] media: rkisp1: add rockchip isp1 core driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:59PM +0800, Jacob Chen wrote: > +config VIDEO_ROCKCHIP_ISP1 > + tristate "Rockchip Image Signal Processing v1 Unit driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + select

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Fri, Mar 09, 2018 at 01:05:28PM +0800, Jacob Chen wrote: > 2018-03-09 12:09 GMT+08:00 Baruch Siach <bar...@tkos.co.il>: > > On Fri, Mar 09, 2018 at 08:53:57AM +0800, Jacob Chen wrote: > >> 2018-03-08 20:02 GMT+08:00 Baruch Siach <bar...@tkos.co.il>: >

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Fri, Mar 09, 2018 at 01:05:28PM +0800, Jacob Chen wrote: > 2018-03-09 12:09 GMT+08:00 Baruch Siach : > > On Fri, Mar 09, 2018 at 08:53:57AM +0800, Jacob Chen wrote: > >> 2018-03-08 20:02 GMT+08:00 Baruch Siach : > >> > On Thu, Mar 08, 2018 at 05:4

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Fri, Mar 09, 2018 at 08:53:57AM +0800, Jacob Chen wrote: > 2018-03-08 20:02 GMT+08:00 Baruch Siach <bar...@tkos.co.il>: > > On Thu, Mar 08, 2018 at 05:47:50PM +0800, Jacob Chen wrote: > >> This patch series add a ISP(Camera) v4l2 driver for rockchi

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Fri, Mar 09, 2018 at 08:53:57AM +0800, Jacob Chen wrote: > 2018-03-08 20:02 GMT+08:00 Baruch Siach : > > On Thu, Mar 08, 2018 at 05:47:50PM +0800, Jacob Chen wrote: > >> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 > >>

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:50PM +0800, Jacob Chen wrote: > This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 > SoC. > > Wiki Pages: > http://opensource.rock-chips.com/wiki_Rockchip-isp1 > > The deprecated g_mbus_config op is not dropped in V6 because i am

Re: [PATCH v6 00/17] Rockchip ISP1 Driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:50PM +0800, Jacob Chen wrote: > This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 > SoC. > > Wiki Pages: > http://opensource.rock-chips.com/wiki_Rockchip-isp1 > > The deprecated g_mbus_config op is not dropped in V6 because i am

[PATCH] gpio: raspberrypi-exp: explain Kconfig dependency

<a...@arndb.de> Signed-off-by: Baruch Siach <bar...@tkos.co.il> --- drivers/gpio/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 52a8b0a6f4e1..1bb25c1ff2d8 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -

[PATCH] gpio: raspberrypi-exp: explain Kconfig dependency

Signed-off-by: Baruch Siach --- drivers/gpio/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 52a8b0a6f4e1..1bb25c1ff2d8 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -126,6 +126,8 @@ config GPIO_RASPBERRYPI_EXP

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Linus, On Thu, Mar 01, 2018 at 10:28:52AM +0100, Linus Walleij wrote: > On Wed, Feb 28, 2018 at 2:48 PM, Arnd Bergmann wrote: > > When the firmware driver is a loadable module, the gpio driver cannot be > > built-in: > > > > drivers/gpio/gpio-raspberrypi-exp.o: In function

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Linus, On Thu, Mar 01, 2018 at 10:28:52AM +0100, Linus Walleij wrote: > On Wed, Feb 28, 2018 at 2:48 PM, Arnd Bergmann wrote: > > When the firmware driver is a loadable module, the gpio driver cannot be > > built-in: > > > > drivers/gpio/gpio-raspberrypi-exp.o: In function

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Arnd, On Wed, Feb 28, 2018 at 11:08:54PM +0100, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 10:47 PM, Baruch Siach <bar...@tkos.co.il> wrote: > > Thanks for the fix. > > > > On Wed, Feb 28, 2018 at 02:48:08PM +0100, Arnd Bergmann wrote: > >> When the

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Arnd, On Wed, Feb 28, 2018 at 11:08:54PM +0100, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 10:47 PM, Baruch Siach wrote: > > Thanks for the fix. > > > > On Wed, Feb 28, 2018 at 02:48:08PM +0100, Arnd Bergmann wrote: > >> When the firmware driver is a lo

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Arnd, Thanks for the fix. On Wed, Feb 28, 2018 at 02:48:08PM +0100, Arnd Bergmann wrote: > When the firmware driver is a loadable module, the gpio driver cannot be > built-in: > > drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_set': > gpio-raspberrypi-exp.c:(.text+0xb4):

Re: [PATCH] gpio: raspberrypi-ext: fix firmware dependency

Hi Arnd, Thanks for the fix. On Wed, Feb 28, 2018 at 02:48:08PM +0100, Arnd Bergmann wrote: > When the firmware driver is a loadable module, the gpio driver cannot be > built-in: > > drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_set': > gpio-raspberrypi-exp.c:(.text+0xb4):

Re: [BUG] arm64: Build error with gcc 6

Hi Masami Hiramatsu, On Sun, Feb 25, 2018 at 11:50:37AM +0900, Masami Hiramatsu wrote: > commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings") > introduces "UL" suffix to a hex number, but it causes a build error with > gcc-6 series. > I've hit below error with 6.2.1 and 6.4.1. Of

Re: [BUG] arm64: Build error with gcc 6

Hi Masami Hiramatsu, On Sun, Feb 25, 2018 at 11:50:37AM +0900, Masami Hiramatsu wrote: > commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings") > introduces "UL" suffix to a hex number, but it causes a build error with > gcc-6 series. > I've hit below error with 6.2.1 and 6.4.1. Of

[PATCH] uapi: remove telephony headers

ixjuser.h includes the telephony.h header. Other than that no kernel code uses any of these headers. The last user of the ixjuser.h header has been removed in commit 7326446c728 (Staging: remove telephony drivers), more than 5 years ago. Signed-off-by: Baruch Siach <bar...@tkos.co

[PATCH] uapi: remove telephony headers

ixjuser.h includes the telephony.h header. Other than that no kernel code uses any of these headers. The last user of the ixjuser.h header has been removed in commit 7326446c728 (Staging: remove telephony drivers), more than 5 years ago. Signed-off-by: Baruch Siach --- include/uapi/linux

Re: [PATCH] MAINTAINERS: add Freescale pin controllers

Hi Lucas, On Mon, Feb 12, 2018 at 11:48:22AM +0100, Lucas Stach wrote: > Am Samstag, den 10.02.2018, 16:32 +0100 schrieb Stefan Agner: > > Add Dong Aisheng, Fabio Estevam, Shawn Guo and myself as maintainer > > and Sascha as reviewer. > > > > Signed-off-by: Stefan Agner > > ---

Re: [PATCH] MAINTAINERS: add Freescale pin controllers

Hi Lucas, On Mon, Feb 12, 2018 at 11:48:22AM +0100, Lucas Stach wrote: > Am Samstag, den 10.02.2018, 16:32 +0100 schrieb Stefan Agner: > > Add Dong Aisheng, Fabio Estevam, Shawn Guo and myself as maintainer > > and Sascha as reviewer. > > > > Signed-off-by: Stefan Agner > > --- > >  MAINTAINERS

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

Hi Paul, On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > does so after RCU has stopped watching the outgoing CPU, which results > in lockdep complaints because complete() invokes functions containing RCU

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

Hi Paul, On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > does so after RCU has stopped watching the outgoing CPU, which results > in lockdep complaints because complete() invokes functions containing RCU

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

Hi Ludovic, On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote: > Add the official SAMA5D2 Peripheral Touch Controller Evaluation > Kit board. > > Signed-off-by: Ludovic Desroches > --- [...] > + memory { > + reg = <0x2000

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

Hi Ludovic, On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote: > Add the official SAMA5D2 Peripheral Touch Controller Evaluation > Kit board. > > Signed-off-by: Ludovic Desroches > --- [...] > + memory { > + reg = <0x2000 0x8>; > + }; The size

Re: [RFC] Improving udelay/ndelay on platforms where that is possible

Hi Marc, On Wed, Nov 01, 2017 at 08:03:20PM +0100, Marc Gonzalez wrote: > On 01/11/2017 18:53, Alan Cox wrote: > > For that matter given the bad blocks don't randomly change why not cache > > them ? > > That's a good question, I'll ask the NAND framework maintainer. > Store them where, by the

Re: [RFC] Improving udelay/ndelay on platforms where that is possible

Hi Marc, On Wed, Nov 01, 2017 at 08:03:20PM +0100, Marc Gonzalez wrote: > On 01/11/2017 18:53, Alan Cox wrote: > > For that matter given the bad blocks don't randomly change why not cache > > them ? > > That's a good question, I'll ask the NAND framework maintainer. > Store them where, by the

[PATCH] dt-binding: phy: don't confuse with Ethernet phy properties

The generic PHY 'phys' property sometime appears in the same node with the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in phy-bindings.txt to reduce confusion. Signed-off-by: Baruch Siach <bar...@tkos.co.il> --- Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 +

[PATCH] dt-binding: phy: don't confuse with Ethernet phy properties

The generic PHY 'phys' property sometime appears in the same node with the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in phy-bindings.txt to reduce confusion. Signed-off-by: Baruch Siach --- Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 +++- 1 file changed, 3

Re: [RESEND PATCH 1/1] arm64: dts: Add Variscite DART-SD410 Evaluation board dts

Hi Leonid, On Wed, Aug 23, 2017 at 08:44:56PM +0300, Leonid Segal wrote: > Thank you very much for the tips. > I have updated the documentation and schematics of our web site. > I also tried to implement all other fixes, but seems that I cannot file the > git > you are talking about. > The

Re: [RESEND PATCH 1/1] arm64: dts: Add Variscite DART-SD410 Evaluation board dts

Hi Leonid, On Wed, Aug 23, 2017 at 08:44:56PM +0300, Leonid Segal wrote: > Thank you very much for the tips. > I have updated the documentation and schematics of our web site. > I also tried to implement all other fixes, but seems that I cannot file the > git > you are talking about. > The

Re: [PATCH 07/17] pinctrl: digicolor: constify pinconf_ops, pinctrl_ops, and pinmux_ops structures

-off-by: Julia Lawall <julia.law...@lip6.fr> Acked-by: Baruch Siach <bar...@tkos.co.il> Thanks, baruch > --- > drivers/pinctrl/pinctrl-digicolor.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/pinctrl/pinctrl-digicolor.c > b/

  1   2   3   4   5   >