Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:35 AM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:35 AM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

Hello. On 5/13/2016 8:56 AM, Ethan Zhao wrote: Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less Performance. CPUs were assigned. especially when DCB is enabled, so we should take num_online_cpus() as top limit, and aslo to make sure every TC has Also. at least

Re: [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

Hello. On 5/13/2016 8:56 AM, Ethan Zhao wrote: Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less Performance. CPUs were assigned. especially when DCB is enabled, so we should take num_online_cpus() as top limit, and aslo to make sure every TC has Also. at least

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Linus Walleij to Cc, there is a question for you/him below] On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: --- net-next.orig/Documentation/devicetree/bindings/net/phy.txt +++ net-next/Documentation/devicetree/bindings/net/phy.txt @@ -35,6 +35,8 @@ Optional Properties: - broken-turn

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Linus Walleij to Cc, there is a question for you/him below] On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: --- net-next.orig/Documentation/devicetree/bindings/net/phy.txt +++ net-next/Documentation/devicetree/bindings/net/phy.txt @@ -35,6 +35,8 @@ Optional Properties: - broken-turn

Re: [PATCH 04/36] usb: serial: ti_usb_3410_5052: Use inline functions rather than macro

Hello. On 5/12/2016 11:48 AM, Mathieu OTHACEHE wrote: Inline functions are preferable to macros resembling functions. Signed-off-by: Mathieu OTHACEHE --- drivers/usb/serial/ti_usb_3410_5052.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff

Re: [PATCH 04/36] usb: serial: ti_usb_3410_5052: Use inline functions rather than macro

Hello. On 5/12/2016 11:48 AM, Mathieu OTHACEHE wrote: Inline functions are preferable to macros resembling functions. Signed-off-by: Mathieu OTHACEHE --- drivers/usb/serial/ti_usb_3410_5052.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

reset GPIO for its own purposes... Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> This looks good to me: Acked-by: Florian Fainelli <f.faine...@gmail.com> Thank you! I'll send v3 without [RFT] then. Can you follow up with changes in phy_{suspend,resume}

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

reset GPIO for its own purposes... Signed-off-by: Sergei Shtylyov This looks good to me: Acked-by: Florian Fainelli Thank you! I'll send v3 without [RFT] then. Can you follow up with changes in phy_{suspend,resume} I'm not sure what changes you mean -- powering dow

Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

On 5/10/2016 2:46 AM, David Lechner wrote: The CFGCHIP registers are used by a number of devices, so using a syscon device to share them. The first consumer of this will by the phy-da8xx-usb driver. Signed-off-by: David Lechner [...] diff --git

Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

On 5/10/2016 2:46 AM, David Lechner wrote: The CFGCHIP registers are used by a number of devices, so using a syscon device to share them. The first consumer of this will by the phy-da8xx-usb driver. Signed-off-by: David Lechner [...] diff --git a/arch/arm/mach-davinci/devices-da8xx.c

Re: [PATCH v5 3/5] ARM: davinci: da8xx: Add USB PHY platform declaration

Hello. On 5/10/2016 2:46 AM, David Lechner wrote: There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the platform device declarations needed to use it. Signed-off-by: David Lechner [...] diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h

Re: [PATCH v5 3/5] ARM: davinci: da8xx: Add USB PHY platform declaration

Hello. On 5/10/2016 2:46 AM, David Lechner wrote: There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the platform device declarations needed to use it. Signed-off-by: David Lechner [...] diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

On 5/5/2016 4:31 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10 @@ void

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

On 5/5/2016 4:31 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10 @@ void

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hello. On 5/4/2016 10:17 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10 @@

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hello. On 5/4/2016 10:17 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10 @@

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hello. On 05/04/2016 09:56 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hello. On 05/04/2016 09:56 PM, Bin Liu wrote: yes, it also works with that reset and go to finish: diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index c3d5fc9..8cd98e7 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1599,6 +1599,10

[PATCH RFT v2 2/2] macb: kill PHY reset code

With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> --- drivers/net/ethernet/cadence/macb.c | 17 --

[PATCH RFT v2 2/2] macb: kill PHY reset code

With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov --- drivers/net/ethernet/cadence/macb.c | 17 - drivers/net/ethernet/cadence/macb.h |

[PATCH RFT 1/2] phylib: add device reset GPIO support

he 'phylib' to get the MDIO device reset GPIO from the device tree node corresponding to this device -- which this patch is doing... Note that I had to modify the AT803x PHY driver as it would stop working otherwise as it made use of the reset GPIO for its own purposes... Signed-off-by: Serge

[PATCH RFT 1/2] phylib: add device reset GPIO support

he 'phylib' to get the MDIO device reset GPIO from the device tree node corresponding to this device -- which this patch is doing... Note that I had to modify the AT803x PHY driver as it would stop working otherwise as it made use of the reset GPIO for its own purposes... Signed-off-by: Serge

[PATCH RFT v2 0/2] Teach phylib hard-resetting devices

Hello. Here's the set of 2 patches against DaveM's 'net-next.git' repo. They add to the 'phylib' support for resetting devices via GPIO and do some clean up after doing that... [1/2] phylib: add device reset GPIO support [2/2] macb: kill PHY reset code MBR, Sergei

[PATCH RFT v2 0/2] Teach phylib hard-resetting devices

Hello. Here's the set of 2 patches against DaveM's 'net-next.git' repo. They add to the 'phylib' support for resetting devices via GPIO and do some clean up after doing that... [1/2] phylib: add device reset GPIO support [2/2] macb: kill PHY reset code MBR, Sergei

Re: [PATCH] pinctrl: ish-pfc: avoid unused variable warning

Hello. s/ish-/sh-/ in the subject. On 4/27/2016 12:56 PM, Arnd Bergmann wrote: After the conversion to devm_pinctrl_register, we get a warning in sh_pfc_remove when CONFIG_PINCTRL_SH_PFC_GPIO is disabled: drivers/pinctrl/sh-pfc/core.c: In function 'sh_pfc_remove':

Re: [PATCH] pinctrl: ish-pfc: avoid unused variable warning

Hello. s/ish-/sh-/ in the subject. On 4/27/2016 12:56 PM, Arnd Bergmann wrote: After the conversion to devm_pinctrl_register, we get a warning in sh_pfc_remove when CONFIG_PINCTRL_SH_PFC_GPIO is disabled: drivers/pinctrl/sh-pfc/core.c: In function 'sh_pfc_remove':

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

Hello. On 4/27/2016 11:29 AM, changbin...@intel.com wrote: From: "Du, Changbin" The dwc3 controller can't generate a disconnect event after it is stopped. Thus gadget dissconnect callback is not invoked when do soft dissconnect. Call dissconnect here to workaround this

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

Hello. On 4/27/2016 11:29 AM, changbin...@intel.com wrote: From: "Du, Changbin" The dwc3 controller can't generate a disconnect event after it is stopped. Thus gadget dissconnect callback is not invoked when do soft dissconnect. Call dissconnect here to workaround this issue.

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

On 04/26/2016 08:17 PM, David Miller wrote: I plan to queue this patch through arm-soc for 4.7. Ok. How about this patch going thru your net-next repo instead? I'd like to keep the kernel bisectable... if my phylib/macb patches get merged earlier than this one, that board would be

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

On 04/26/2016 08:17 PM, David Miller wrote: I plan to queue this patch through arm-soc for 4.7. Ok. How about this patch going thru your net-next repo instead? I'd like to keep the kernel bisectable... if my phylib/macb patches get merged earlier than this one, that board would be

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

Hello. On 04/26/2016 01:24 PM, Nicolas Ferre wrote: Fix gpio active flag for the phy reset-gpios property. The line is active low instead of active high. Actually, this flags was never used by the macb driver. Reported-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> Cc: Andre

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

Hello. On 04/26/2016 01:24 PM, Nicolas Ferre wrote: Fix gpio active flag for the phy reset-gpios property. The line is active low instead of active high. Actually, this flags was never used by the macb driver. Reported-by: Sergei Shtylyov Cc: Andrew Lunn Cc: David Miller Signed-off

Re: [PATCH] musb_host: fix lockup on rxcsr_h_error

Hello. On 4/26/2016 9:45 AM, Max Uvarov wrote: Fix soft lockup when resetting remote device attached to usb host. Configuration: pppd -> musb hub -> usb-serial -> gms modem When gsm modem resets, musb rolls in incoming rx interrupts which does not give any time to other application as result

Re: [PATCH] musb_host: fix lockup on rxcsr_h_error

Hello. On 4/26/2016 9:45 AM, Max Uvarov wrote: Fix soft lockup when resetting remote device attached to usb host. Configuration: pppd -> musb hub -> usb-serial -> gms modem When gsm modem resets, musb rolls in incoming rx interrupts which does not give any time to other application as result

Re: [PATCH RESEND 2/5] USB: serial: cp210x: Made sure SERIAL_XOFF_CONTINUE flag is clear.

Hello. On 4/24/2016 8:09 PM, Konstantin Shkolnyy wrote: The CRTCTS flag code intended to clear the SERIAL_XOFF_CONTINUE flag, but CRTSCTS? Also, "is" missing before "intended"? did it inconsistently. This change is non-functional for existing chips because the driver never set the flag

Re: [PATCH RESEND 2/5] USB: serial: cp210x: Made sure SERIAL_XOFF_CONTINUE flag is clear.

Hello. On 4/24/2016 8:09 PM, Konstantin Shkolnyy wrote: The CRTCTS flag code intended to clear the SERIAL_XOFF_CONTINUE flag, but CRTSCTS? Also, "is" missing before "intended"? did it inconsistently. This change is non-functional for existing chips because the driver never set the flag

Re: [PATCH RESEND 1/5] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

Hello. On 4/24/2016 8:08 PM, Konstantin Shkolnyy wrote: A bug in the CRTSCT handling caused RTS to alternate between CRTSCTS? CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS

Re: [PATCH RESEND 1/5] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

Hello. On 4/24/2016 8:08 PM, Konstantin Shkolnyy wrote: A bug in the CRTSCT handling caused RTS to alternate between CRTSCTS? CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS

Re: [PATCH v1 03/23] ata: sata_dwc_460ex: set dma_boundary to 0x1fff

Hello. On 04/21/2016 09:15 PM, Andy Shevchenko wrote: The original code states: Make sure a LLI block is not created that will span 8K max FIS boundary. If the block spans such a FIS boundary, there is a chance that a DMA burst will cross that boundary -- this results

Re: [PATCH v1 03/23] ata: sata_dwc_460ex: set dma_boundary to 0x1fff

Hello. On 04/21/2016 09:15 PM, Andy Shevchenko wrote: The original code states: Make sure a LLI block is not created that will span 8K max FIS boundary. If the block spans such a FIS boundary, there is a chance that a DMA burst will cross that boundary -- this results

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

On 4/19/2016 3:21 PM, Olliver Schinagl wrote: In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc scripts/checkpatch.pl now enforces certain commit citing style, the commit summary should be specified too. I used checkpatch from 4.6.0-rc2(or3) and did not notice it.

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

On 4/19/2016 3:21 PM, Olliver Schinagl wrote: In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc scripts/checkpatch.pl now enforces certain commit citing style, the commit summary should be specified too. I used checkpatch from 4.6.0-rc2(or3) and did not notice it.

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

Hello. On 4/19/2016 10:12 AM, Olliver Schinagl wrote: In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc scripts/checkpatch.pl now enforces certain commit citing style, the commit summary should be specified too. device as to having an broken HPI implementation.

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

Hello. On 4/19/2016 10:12 AM, Olliver Schinagl wrote: In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc scripts/checkpatch.pl now enforces certain commit citing style, the commit summary should be specified too. device as to having an broken HPI implementation.

Re: [PATCH] mips: pistachio: Determine SoC revision during boot

Hello. On 04/18/2016 05:24 PM, James Hartley wrote: Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley

Re: [PATCH] mips: pistachio: Determine SoC revision during boot

Hello. On 04/18/2016 05:24 PM, James Hartley wrote: Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley Signed-off-by: Ionela Voinescu

Re: [PATCH v2 03/13] MIPS: Remove redundant asm/pgtable-bits.h inclusions

Hello. On 4/18/2016 12:35 PM, Paul Burton wrote: asm/pgtable-bits.h is included in 2 assembly files and thus has to in either of the assembly files that include it. > Missed a line again? :-) Remove the redundant inclusions such that asm/pgtable-bits.h doesn't need to #ifdef around C

Re: [PATCH v2 03/13] MIPS: Remove redundant asm/pgtable-bits.h inclusions

Hello. On 4/18/2016 12:35 PM, Paul Burton wrote: asm/pgtable-bits.h is included in 2 assembly files and thus has to in either of the assembly files that include it. > Missed a line again? :-) Remove the redundant inclusions such that asm/pgtable-bits.h doesn't need to #ifdef around C

Re: [PATCH v4 2/7] dt-bindings: Add bindings for phy-da8xx-usb

On 04/15/2016 07:13 PM, David Lechner wrote: Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring --- v4 changes: * swapped order of usb20 and usb11 to be in logical order of reg address.

Re: [PATCH v4 2/7] dt-bindings: Add bindings for phy-da8xx-usb

On 04/15/2016 07:13 PM, David Lechner wrote: Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring --- v4 changes: * swapped order of usb20 and usb11 to be in logical order of reg address. .../devicetree/bindings/phy/phy-da8xx-usb.txt

Re: [PATCH v4 2/7] dt-bindings: Add bindings for phy-da8xx-usb

Hello. On 4/14/2016 9:35 PM, David Lechner wrote: Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring --- v4 changes: * swapped order of usb20 and usb11 to be in logical order of reg address.

Re: [PATCH v4 2/7] dt-bindings: Add bindings for phy-da8xx-usb

Hello. On 4/14/2016 9:35 PM, David Lechner wrote: Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring --- v4 changes: * swapped order of usb20 and usb11 to be in logical order of reg address. .../devicetree/bindings/phy/phy-da8xx-usb.txt

Re: [PATCH v4 5/5] ARM: DTS: da850: Add usb phy node

Hello. On 04/14/2016 10:44 PM, David Lechner wrote: Add a node for the new usb phy driver. Signed-off-by: David Lechner --- v4 changes: none arch/arm/boot/dts/da850.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi

Re: [PATCH v4 5/5] ARM: DTS: da850: Add usb phy node

Hello. On 04/14/2016 10:44 PM, David Lechner wrote: Add a node for the new usb phy driver. Signed-off-by: David Lechner --- v4 changes: none arch/arm/boot/dts/da850.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi

Re: [RESEND PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode

Hello. On 4/13/2016 2:59 PM, Weidong Wang wrote: When tested the PHY SGMII Loopback,: 1.set the LOOPBACK bit, 2.set the autoneg to AUTONEG_DISABLE, it calls the genphy_setup_forced which will clear the bit. So just keep the LOOPBACK bit while setup forced mode. Signed-off-by: Weidong Wang

Re: [RESEND PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode

Hello. On 4/13/2016 2:59 PM, Weidong Wang wrote: When tested the PHY SGMII Loopback,: 1.set the LOOPBACK bit, 2.set the autoneg to AUTONEG_DISABLE, it calls the genphy_setup_forced which will clear the bit. So just keep the LOOPBACK bit while setup forced mode. Signed-off-by: Weidong Wang

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 4/12/2016 12:22 PM, Nicolas Ferre wrote: With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> -

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 4/12/2016 12:22 PM, Nicolas Ferre wrote: With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov --- drivers/net/ethernet/cadence/mac

Re: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space

Hello. On 4/12/2016 2:10 PM, changbin...@intel.com wrote: From: "Du, Changbin" For DWC3 USB controller, the Global Debug Queue/FIFO Space Available Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available space. Space needed before (. This can be used to

Re: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space

Hello. On 4/12/2016 2:10 PM, changbin...@intel.com wrote: From: "Du, Changbin" For DWC3 USB controller, the Global Debug Queue/FIFO Space Available Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available space. Space needed before (. This can be used to check some special

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

IO for its own purposes... Lots of double spaces in here. Please fix. Oh, it's you again! :-D Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> --- Documentation/devicetree/bindings/net/phy.txt |2 + drivers/net/phy/at803x.c

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

IO for its own purposes... Lots of double spaces in here. Please fix. Oh, it's you again! :-D Signed-off-by: Sergei Shtylyov --- Documentation/devicetree/bindings/net/phy.txt |2 + drivers/net/phy/at803x.c | 19 ++ drivers/net/phy/

Re: [PATCH RFT 2/2] macb: kill PHY reset code

On 04/11/2016 09:51 PM, Andrew Lunn wrote: The code you are deleting would of ignored the flags in the gpio property, i.e. active low. Hm, you're right -- I forgot about that... :-/ The new code in the previous patch does however take the flags into account. Did you check if there are

Re: [PATCH RFT 2/2] macb: kill PHY reset code

On 04/11/2016 09:51 PM, Andrew Lunn wrote: The code you are deleting would of ignored the flags in the gpio property, i.e. active low. Hm, you're right -- I forgot about that... :-/ The new code in the previous patch does however take the flags into account. Did you check if there are

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 04/11/2016 09:19 PM, Andrew Lunn wrote: The code you are deleting would of ignored the flags in the gpio property, i.e. active low. Hm, you're right -- I forgot about that... :-/ The new code in the previous patch does however take the flags into account. Did you check if

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 04/11/2016 09:19 PM, Andrew Lunn wrote: The code you are deleting would of ignored the flags in the gpio property, i.e. active low. Hm, you're right -- I forgot about that... :-/ The new code in the previous patch does however take the flags into account. Did you check if

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 04/11/2016 05:28 AM, Andrew Lunn wrote: With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> -

Re: [PATCH RFT 2/2] macb: kill PHY reset code

Hello. On 04/11/2016 05:28 AM, Andrew Lunn wrote: With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov --- drivers/net/ethernet/cadence/mac

[PATCH RFT 2/2] macb: kill PHY reset code

With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> --- drivers/net/ethernet/cadence/macb.c | 17 --

[PATCH RFT 2/2] macb: kill PHY reset code

With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov --- drivers/net/ethernet/cadence/macb.c | 17 - drivers/net/ethernet/cadence/macb.h |

[PATCH RFT 1/2] phylib: add device reset GPIO support

s to teach the 'phylib' to get the MDIO device reset GPIO from the device tree node corresponding to this device -- which this patch is doing... Note that I had to modify the AT803x PHY driver as it would stop working otherwise as it made use of the reset GPIO for its own purposes... Signed-off-

[PATCH RFT 1/2] phylib: add device reset GPIO support

s to teach the 'phylib' to get the MDIO device reset GPIO from the device tree node corresponding to this device -- which this patch is doing... Note that I had to modify the AT803x PHY driver as it would stop working otherwise as it made use of the reset GPIO for its own purposes... Signed-off-

[PATCH RFT 0/2] Teach phylib hard-resetting devices

Hello. Here's the set of 2 patches against DaveM's 'net-next.git' repo. They add to 'phylib' support for resetting devices via GPIO and do some clean up after doing that... [1/2] phylib: add device reset GPIO support [2/2] macb: kill PHY reset code MBR, Sergei

[PATCH RFT 0/2] Teach phylib hard-resetting devices

Hello. Here's the set of 2 patches against DaveM's 'net-next.git' repo. They add to 'phylib' support for resetting devices via GPIO and do some clean up after doing that... [1/2] phylib: add device reset GPIO support [2/2] macb: kill PHY reset code MBR, Sergei

Re: [PATCH V2 6/8] net: mediatek: fix TX locking

Hello. On 04/07/2016 10:26 PM, John Crispin wrote: Inside the TX path there is a lock inside the tx_map function. This is however too late. The patch moves the lock to the start of the xmit function right before the free count check of the DMA ring happens. If we do not do this, the code

Re: [PATCH V2 6/8] net: mediatek: fix TX locking

Hello. On 04/07/2016 10:26 PM, John Crispin wrote: Inside the TX path there is a lock inside the tx_map function. This is however too late. The patch moves the lock to the start of the xmit function right before the free count check of the DMA ring happens. If we do not do this, the code

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

Hello. On 04/07/2016 10:00 AM, Sjoerd Simons wrote: Hey Sergei, Thanks for your review. You're welcome. :-) On Thu, 2016-04-07 at 02:15 +0300, Sergei Shtylyov wrote: On 04/06/2016 03:52 PM, Sjoerd Simons wrote: clk_get on a disabled clock node will return EPROBE_DEFER, which can

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

Hello. On 04/07/2016 10:00 AM, Sjoerd Simons wrote: Hey Sergei, Thanks for your review. You're welcome. :-) On Thu, 2016-04-07 at 02:15 +0300, Sergei Shtylyov wrote: On 04/06/2016 03:52 PM, Sjoerd Simons wrote: clk_get on a disabled clock node will return EPROBE_DEFER, which can

Re: [PATCH 08/11] ia64, rwsem: provide __down_write_killable

Hello. On 04/07/2016 06:12 PM, Michal Hocko wrote: From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp.

Re: [PATCH 08/11] ia64, rwsem: provide __down_write_killable

Hello. On 04/07/2016 06:12 PM, Michal Hocko wrote: From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable).

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 4:24 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. ack. and USB Phy found on Microchip PIC32 class devices. PHY. ack. Signed-off-by: Purna Chandra Mandal ---

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 4:24 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. ack. and USB Phy found on Microchip PIC32 class devices. PHY. ack. Signed-off-by: Purna Chandra Mandal --- .../bindings/usb/microchip,pic32-musb.txt

Re: [PATCH v2 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 3:32 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller and USB Phy found on Microchip PIC32 class devices. Signed-off-by: Purna Chandra Mandal --- Changes in v2: None .../bindings/usb/microchip,pic32-musb.txt

Re: [PATCH v2 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 3:32 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller and USB Phy found on Microchip PIC32 class devices. Signed-off-by: Purna Chandra Mandal --- Changes in v2: None .../bindings/usb/microchip,pic32-musb.txt | 67

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 4:02 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. ack. and USB Phy found on Microchip PIC32 class devices. PHY. ack. Signed-off-by: Purna Chandra Mandal ---

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

On 4/7/2016 4:02 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. ack. and USB Phy found on Microchip PIC32 class devices. PHY. ack. Signed-off-by: Purna Chandra Mandal --- .../bindings/usb/microchip,pic32-musb.txt

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

Hello. On 4/7/2016 2:16 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. and USB Phy found on Microchip PIC32 class devices. PHY. Signed-off-by: Purna Chandra Mandal ---

Re: [PATCH v1 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.

Hello. On 4/7/2016 2:16 PM, Purna Chandra Mandal wrote: Document devicetree binding for the USB controller Device tree. and USB Phy found on Microchip PIC32 class devices. PHY. Signed-off-by: Purna Chandra Mandal --- .../bindings/usb/microchip,pic32-musb.txt | 67

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On 04/06/2016 03:52 PM, Sjoerd Simons wrote: clk_get on a disabled clock node will return EPROBE_DEFER, which can cause drivers to be deferred forever if such clocks are referenced in their clocks property. Update the various disabled external clock nodes to default to a frequency of 0, but

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On 04/06/2016 03:52 PM, Sjoerd Simons wrote: clk_get on a disabled clock node will return EPROBE_DEFER, which can cause drivers to be deferred forever if such clocks are referenced in their clocks property. Update the various disabled external clock nodes to default to a frequency of 0, but

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hello. On 4/6/2016 9:44 AM, Lu Baolu wrote: +struct intel_mux_dev { + struct device *dev; + char*extcon_name; + char*cable_name; + int (*cable_set_cb)(struct intel_mux_dev *mux); + int (*cable_unset_cb)(struct

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hello. On 4/6/2016 9:44 AM, Lu Baolu wrote: +struct intel_mux_dev { + struct device *dev; + char*extcon_name; + char*cable_name; + int (*cable_set_cb)(struct intel_mux_dev *mux); + int (*cable_unset_cb)(struct

Re: [PATCH] arm64/debug: Remove superfluous SMP function call

Hello. On 4/4/2016 1:42 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 "cpu/hotplug: Move online calls to hotplugged cpu" it is ensured that callbacks of CPU_ONLINE and scripts/checkpatch.pl now enforces commit citing certain style, yours doesn't quite match it, also need

Re: [PATCH] arm64/debug: Remove superfluous SMP function call

Hello. On 4/4/2016 1:42 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 "cpu/hotplug: Move online calls to hotplugged cpu" it is ensured that callbacks of CPU_ONLINE and scripts/checkpatch.pl now enforces commit citing certain style, yours doesn't quite match it, also need

Re: [PATCH] arm, hw-breakpoint: Remove superfluous SMP function call

On 4/4/2016 1:32 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu") it is ensured that callbacks of CPU_ONLINE and CPU_DOWN_PREPARE are processed on the hotplugged cpu. Due to this SMP function calls are no longer required. Replace

Re: [PATCH] arm, hw-breakpoint: Remove superfluous SMP function call

On 4/4/2016 1:32 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu") it is ensured that callbacks of CPU_ONLINE and CPU_DOWN_PREPARE are processed on the hotplugged cpu. Due to this SMP function calls are no longer required. Replace

Re: [PATCH] arm64: hw-breakpoint: Remove superfluous SMP function call

On 4/4/2016 1:42 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu") it is ensured that callbacks of CPU_ONLINE and CPU_DOWN_PREPARE are processed on the hotplugged cpu. Due to this SMP CPU. My spell checker also trips over

Re: [PATCH] arm64: hw-breakpoint: Remove superfluous SMP function call

On 4/4/2016 1:42 PM, Anna-Maria Gleixner wrote: Since commit 1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu") it is ensured that callbacks of CPU_ONLINE and CPU_DOWN_PREPARE are processed on the hotplugged cpu. Due to this SMP CPU. My spell checker also trips over

<    8   9   10   11   12   13   14   15   16   17   >