Re: [PATCH v5 20/22] sh: IO-DATA HDL-U (a.k.a landisk) DeviceTree

Hello. On 07/03/2016 07:46 PM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato [...] diff --git a/arch/sh/boot/dts/landisk.dts b/arch/sh/boot/dts/landisk.dts new file mode 100644 index 000..3745ae0 --- /dev/null +++ b/arch/sh/boot/dts/landisk.dts @@

Re: [PATCH v5 20/22] sh: IO-DATA HDL-U (a.k.a landisk) DeviceTree

Hello. On 07/03/2016 07:46 PM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato [...] diff --git a/arch/sh/boot/dts/landisk.dts b/arch/sh/boot/dts/landisk.dts new file mode 100644 index 000..3745ae0 --- /dev/null +++ b/arch/sh/boot/dts/landisk.dts @@ -0,0 +1,61 @@ [...] + { +

Re: [PATCH v4 22/22] sh: Renesas RTS7751R2Dplus (a,k.a R2Dplus) DeviceTree

On 06/29/2016 04:41 PM, Yoshinori Sato wrote: Changes v4 - split patch Signed-off-by: Yoshinori Sato [...] diff --git a/arch/sh/boot/dts/r2dplus.dts b/arch/sh/boot/dts/r2dplus.dts new file mode 100644 index 000..a1a0745 --- /dev/null +++

Re: [PATCH v4 22/22] sh: Renesas RTS7751R2Dplus (a,k.a R2Dplus) DeviceTree

On 06/29/2016 04:41 PM, Yoshinori Sato wrote: Changes v4 - split patch Signed-off-by: Yoshinori Sato [...] diff --git a/arch/sh/boot/dts/r2dplus.dts b/arch/sh/boot/dts/r2dplus.dts new file mode 100644 index 000..a1a0745 --- /dev/null +++ b/arch/sh/boot/dts/r2dplus.dts @@ -0,0 +1,83 @@

Re: [RFC 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac

Hello. On 06/28/2016 10:34 PM, Jon Mason wrote: Signed-off-by: Jon Mason --- .../devicetree/bindings/net/brcm,bgmac-enet.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt

Re: [RFC 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac

Hello. On 06/28/2016 10:34 PM, Jon Mason wrote: Signed-off-by: Jon Mason --- .../devicetree/bindings/net/brcm,bgmac-enet.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt diff --git

Re: [PATCH net-next 6/6] r8152: add byte_enable for ocp_read_word function

Hello. On 6/27/2016 8:07 AM, Hayes Wang wrote: Add byte_enable for ocp_read_word() to replace reading 4 bytes data with reading the desired 2 bytes data. This is used to avoid the issue which is described in commit:b4d99def. scripts/checkpatch.pl now enforces certain commit citing style,

Re: [PATCH net-next 6/6] r8152: add byte_enable for ocp_read_word function

Hello. On 6/27/2016 8:07 AM, Hayes Wang wrote: Add byte_enable for ocp_read_word() to replace reading 4 bytes data with reading the desired 2 bytes data. This is used to avoid the issue which is described in commit:b4d99def. scripts/checkpatch.pl now enforces certain commit citing style,

Re: [PATCH net-next 16/19] net: hns: fix bug that alloc skb fail lead to port unavailable

Hello. On 6/21/2016 6:56 AM, Yisen Zhuang wrote: From: Jun He When hns_nic_poll_rx_skb alloc skb fail, it will break receive cycle and read new fbd_num to start new receive cycle. It recomputes cycle num is fbd_num minus clean_count, actually this cycle num is too big

Re: [PATCH net-next 16/19] net: hns: fix bug that alloc skb fail lead to port unavailable

Hello. On 6/21/2016 6:56 AM, Yisen Zhuang wrote: From: Jun He When hns_nic_poll_rx_skb alloc skb fail, it will break receive cycle and read new fbd_num to start new receive cycle. It recomputes cycle num is fbd_num minus clean_count, actually this cycle num is too big because it drop out

Re: [PATCH] clk: renesas: build clk-rcar-gen2.o for R8A7792

Hello. On 06/20/2016 06:43 PM, Arnd Bergmann wrote: The newly added support for R8A7792 causes build failures because we try to call rcar_gen2_clocks_init but that is not built into the kernel: arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init': :(.init.text+0x3b0):

Re: [PATCH] clk: renesas: build clk-rcar-gen2.o for R8A7792

Hello. On 06/20/2016 06:43 PM, Arnd Bergmann wrote: The newly added support for R8A7792 causes build failures because we try to call rcar_gen2_clocks_init but that is not built into the kernel: arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init': :(.init.text+0x3b0):

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

Hello. On 06/16/2016 04:52 PM, Arnd Bergmann wrote: Modern C standards expect the '__inline__' keyword to come before the return type in a declaration, and we get a warning for this with "make W=1": drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is not at beginning of

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

Hello. On 06/16/2016 04:52 PM, Arnd Bergmann wrote: Modern C standards expect the '__inline__' keyword to come before the return type in a declaration, and we get a warning for this with "make W=1": drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is not at beginning of

Re: [PATCH resend] libata:fix kernel panic when hotplug

On 6/15/2016 12:15 PM, DingXiang wrote: From: Miao Xie In normal condition,if we use sas protocol and hotplug a sata disk on a port, the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug

Re: [PATCH resend] libata:fix kernel panic when hotplug

On 6/15/2016 12:15 PM, DingXiang wrote: From: Miao Xie In normal condition,if we use sas protocol and hotplug a sata disk on a port, the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata

Re: [PATCH resend] libata:fix kernel panic when hotplug

On 6/15/2016 12:15 PM, DingXiang wrote: From: Miao Xie In normal condition,if we use sas protocol and hotplug a sata disk on a port, the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug

Re: [PATCH resend] libata:fix kernel panic when hotplug

On 6/15/2016 12:15 PM, DingXiang wrote: From: Miao Xie In normal condition,if we use sas protocol and hotplug a sata disk on a port, the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata

Re: [PATCH v2 net-next v2 10/12] net: dsa: mv88e6xxx: iterate on compatible info

On 06/14/2016 09:31 PM, Vivien Didelot wrote: With legacy probing, we cannot have a compatible info structure. We have to guess it. Instead of using only the first info structure of the info table, iterate over the compatible data. That way, the legacy code will support new compatible chips

Re: [PATCH v2 net-next v2 10/12] net: dsa: mv88e6xxx: iterate on compatible info

On 06/14/2016 09:31 PM, Vivien Didelot wrote: With legacy probing, we cannot have a compatible info structure. We have to guess it. Instead of using only the first info structure of the info table, iterate over the compatible data. That way, the legacy code will support new compatible chips

Re: [PATCH v2 net-next v2 08/12] net: dsa: mv88e6xxx: read switch ID from info

Hello. On 06/14/2016 09:31 PM, Vivien Didelot wrote: Retrieve the info structure of the compatible of device in the new probe function, in order to know how to access the switch ID register. That way, a compatible info can be used to describe how to access the switch registers on models with

Re: [PATCH v2 net-next v2 08/12] net: dsa: mv88e6xxx: read switch ID from info

Hello. On 06/14/2016 09:31 PM, Vivien Didelot wrote: Retrieve the info structure of the compatible of device in the new probe function, in order to know how to access the switch ID register. That way, a compatible info can be used to describe how to access the switch registers on models with

Re: [PATCH v2 07/17] sh: Passing FDT address on zImage

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato --- arch/sh/boot/compressed/head_32.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/sh/boot/compressed/head_32.S b/arch/sh/boot/compressed/head_32.S index

Re: [PATCH v2 07/17] sh: Passing FDT address on zImage

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato --- arch/sh/boot/compressed/head_32.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/sh/boot/compressed/head_32.S b/arch/sh/boot/compressed/head_32.S index 3e15032..ef70454 100644 ---

Re: [PATCH v2 05/17] sh: command line passing chosen/bootargs in devicetree

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato --- arch/sh/kernel/setup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c index 8e3b099..d97de16 100644 ---

Re: [PATCH v2 05/17] sh: command line passing chosen/bootargs in devicetree

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: Signed-off-by: Yoshinori Sato --- arch/sh/kernel/setup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c index 8e3b099..d97de16 100644 --- a/arch/sh/kernel/setup.c +++

Re: [PATCH v2 01/17] sh: Add sh-specific early_init_dt_reserve_memory_arch

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: sh used P1 address space in early device tree. So need convert P1 to physical address before reserve memory. Signed-off-by: Yoshinori Sato --- arch/sh/boards/of-generic.c | 12 1 file changed, 12

Re: [PATCH v2 01/17] sh: Add sh-specific early_init_dt_reserve_memory_arch

On 6/12/2016 9:54 AM, Yoshinori Sato wrote: sh used P1 address space in early device tree. So need convert P1 to physical address before reserve memory. Signed-off-by: Yoshinori Sato --- arch/sh/boards/of-generic.c | 12 1 file changed, 12 insertions(+) diff --git

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

On 6/10/2016 2:46 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following are the interrupt names Peripheral Interrupt - peripheral HOST Interrupt - host Maintain backward

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

On 6/10/2016 2:46 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following are the interrupt names Peripheral Interrupt - peripheral HOST Interrupt - host Maintain backward

Re: [PATCH] of: irq: don't return 0 from of_irq_get()

-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> So I think this is done this way because of the variation in NO_IRQ definition across architectures. I remember that NO_IRQ is "considered harmful" by Linus. Actually, I'm nit sure what you mean, cou

Re: [PATCH] of: irq: don't return 0 from of_irq_get()

-off-by: Sergei Shtylyov So I think this is done this way because of the variation in NO_IRQ definition across architectures. I remember that NO_IRQ is "considered harmful" by Linus. Actually, I'm nit sure what you mean, could you elaborate on that? But then again, of_irq_get is

Re: [PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

Hello. On 5/28/2016 11:51 PM, Sergei Shtylyov wrote: of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API. We should rely on the platform IRQ resource in this case, not return 0, especially as 0 can

Re: [PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

Hello. On 5/28/2016 11:51 PM, Sergei Shtylyov wrote: of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API. We should rely on the platform IRQ resource in this case, not return 0, especially as 0 can

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

On 6/10/2016 2:35 PM, Roger Quadros wrote: On 10/06/16 13:39, Sergei Shtylyov wrote: Hello. On 6/10/2016 12:56 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

On 6/10/2016 2:35 PM, Roger Quadros wrote: On 10/06/16 13:39, Sergei Shtylyov wrote: Hello. On 6/10/2016 12:56 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following

Re: [PATCH v10 08/14] usb: otg: add OTG/dual-role core

On 6/10/2016 1:19 PM, Roger Quadros wrote: It provides APIs for the following tasks - Registering an OTG/dual-role capable controller - Registering Host and Gadget controllers to OTG core - Providing inputs to and kicking the OTG state machine Provide a dual-role device (DRD) state machine.

Re: [PATCH v10 08/14] usb: otg: add OTG/dual-role core

On 6/10/2016 1:19 PM, Roger Quadros wrote: It provides APIs for the following tasks - Registering an OTG/dual-role capable controller - Registering Host and Gadget controllers to OTG core - Providing inputs to and kicking the OTG state machine Provide a dual-role device (DRD) state machine.

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

Hello. On 6/10/2016 12:56 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following are the interrupt names Peripheral Interrupt - peripheral HOST Interrupt - host Maintain

Re: [PATCH v10 5/5] usb: dwc3: core: cleanup IRQ resources

Hello. On 6/10/2016 12:56 PM, Roger Quadros wrote: Implementations might use different IRQs for host, gadget so use named interrupt resources to allow device tree to specify the interrupts. Following are the interrupt names Peripheral Interrupt - peripheral HOST Interrupt - host Maintain

Re: [PATCH v10 08/14] usb: otg: add OTG/dual-role core

On 6/9/2016 10:53 AM, Roger Quadros wrote: It provides APIs for the following tasks - Registering an OTG/dual-role capable controller - Registering Host and Gadget controllers to OTG core - Providing inputs to and kicking the OTG state machine Provide a dual-role device (DRD) state machine.

Re: [PATCH v10 08/14] usb: otg: add OTG/dual-role core

On 6/9/2016 10:53 AM, Roger Quadros wrote: It provides APIs for the following tasks - Registering an OTG/dual-role capable controller - Registering Host and Gadget controllers to OTG core - Providing inputs to and kicking the OTG state machine Provide a dual-role device (DRD) state machine.

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

Hello. On 6/9/2016 10:31 AM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) OK. OTOH, my googling has shown that HCD may stand for both HC driver and HC device... The

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

Hello. On 6/9/2016 10:31 AM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) OK. OTOH, my googling has shown that HCD may stand for both HC driver and HC device... The

Re: Nokia N900: musb is in wrong state after boot

On 6/8/2016 3:18 PM, joerg Reisenweber wrote: Tony, what do you think about that patch? Tony, PING Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY

Re: Nokia N900: musb is in wrong state after boot

On 6/8/2016 3:18 PM, joerg Reisenweber wrote: Tony, what do you think about that patch? Tony, PING Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY

Re: [PATCH v9 12/14] usb: hcd: Adapt to OTG core

On 6/8/2016 3:06 PM, Roger Quadros wrote: Introduce usb_otg_add/remove_hcd() for use by host controllers that are part of OTG/dual-role port. Non Device tree platforms can use the otg_dev argument to specify the OTG controller device. If otg_dev is NULL then the device tree node's

Re: [PATCH v9 12/14] usb: hcd: Adapt to OTG core

On 6/8/2016 3:06 PM, Roger Quadros wrote: Introduce usb_otg_add/remove_hcd() for use by host controllers that are part of OTG/dual-role port. Non Device tree platforms can use the otg_dev argument to specify the OTG controller device. If otg_dev is NULL then the device tree node's

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

On 6/8/2016 3:04 PM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) OK. OTOH, my googling has shown that HCD may stand for both HC driver and HC device... The host

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

On 6/8/2016 3:04 PM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) OK. OTOH, my googling has shown that HCD may stand for both HC driver and HC device... The host

Re: Nokia N900: musb is in wrong state after boot

On 6/8/2016 1:02 PM, Felipe Balbi wrote: * Pali Rohár [160607 05:53]: Tony, what do you think about that patch? Tony, PING Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for

Re: Nokia N900: musb is in wrong state after boot

On 6/8/2016 1:02 PM, Felipe Balbi wrote: * Pali Rohár [160607 05:53]: Tony, what do you think about that patch? Tony, PING Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not

Re: [PATCH v9 12/14] usb: hcd: Adapt to OTG core

On 6/8/2016 12:03 PM, Roger Quadros wrote: Introduce usb_otg_add/remove_hcd() for use by host controllers that are part of OTG/dual-role port. Non Device tree platforms can use the otg_dev argument to specify the OTG controller device. If otg_dev is NULL then the device tree node's

Re: [PATCH v9 12/14] usb: hcd: Adapt to OTG core

On 6/8/2016 12:03 PM, Roger Quadros wrote: Introduce usb_otg_add/remove_hcd() for use by host controllers that are part of OTG/dual-role port. Non Device tree platforms can use the otg_dev argument to specify the OTG controller device. If otg_dev is NULL then the device tree node's

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

Hello. On 6/8/2016 12:03 PM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) The main purpose of this interface is to avoid directly calling HCD APIs from the OTG core as they

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

Hello. On 6/8/2016 12:03 PM, Roger Quadros wrote: The OTG core will use struct otg_hcd_ops to interface with the HCD controller. Host controller driver (HCD) controller? Maybe just HC? :-) The main purpose of this interface is to avoid directly calling HCD APIs from the OTG core as they

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Hello. On 6/7/2016 6:39 AM, Magnus Damm wrote: From: Magnus Damm Bump up the maximum numbers of micro-TLBS to 48. Each IPMMU device instance get micro-TLB assignment via the "iommus" property in DT. Older SoCs tend to use a maximum number of 32 micro-TLBd per

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Hello. On 6/7/2016 6:39 AM, Magnus Damm wrote: From: Magnus Damm Bump up the maximum numbers of micro-TLBS to 48. Each IPMMU device instance get micro-TLB assignment via the "iommus" property in DT. Older SoCs tend to use a maximum number of 32 micro-TLBd per IPMMU instance however

Re: [PATCH v3 11/11] serial: sh-sci: Add DT support for dedicated RTS/CTS

Hello. On 6/3/2016 1:00 PM, Geert Uytterhoeven wrote: Add support for indicating the availability of dedicated lines for RTS/CTS hardware flow control, using the standard "uart-has-rtscts" DT property. Signed-off-by: Geert Uytterhoeven --- v3: - No changes, v2:

Re: [PATCH v3 11/11] serial: sh-sci: Add DT support for dedicated RTS/CTS

Hello. On 6/3/2016 1:00 PM, Geert Uytterhoeven wrote: Add support for indicating the availability of dedicated lines for RTS/CTS hardware flow control, using the standard "uart-has-rtscts" DT property. Signed-off-by: Geert Uytterhoeven --- v3: - No changes, v2: - New. ---

Re: [PATCH v2,1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

Hello. On 5/31/2016 8:52 AM, Chunfeng Yun wrote: Some resources, such as IPPC register etc, shared with device driver are moved into common glue layer when xHCI driver is the host side of dual-role mode and they should be changed as optional properties if they are required ones before. For

Re: [PATCH v2,1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

Hello. On 5/31/2016 8:52 AM, Chunfeng Yun wrote: Some resources, such as IPPC register etc, shared with device driver are moved into common glue layer when xHCI driver is the host side of dual-role mode and they should be changed as optional properties if they are required ones before. For

[PATCH] of: irq: don't return 0 from of_irq_get()

of_irq_get() returns 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API. Return -ENXIO instead like one of the callers, platform_get_irq(), does; fix up the kernel-doc as well... Signed-off-by: Sergei Shtylyov <sergei.sh

[PATCH] of: irq: don't return 0 from of_irq_get()

of_irq_get() returns 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API. Return -ENXIO instead like one of the callers, platform_get_irq(), does; fix up the kernel-doc as well... Signed-off-by: Sergei Shtylyov --- The patch

[PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

("platform_get_irq: Revert to platform_get_resource if of_irq_get fails") Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> CC: sta...@vger.kernel.org --- The patch is against the 'driver-core-linus' branch of Greg KH's 'driver-core.git' repo. drivers/base/platform.

[PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

("platform_get_irq: Revert to platform_get_resource if of_irq_get fails") Signed-off-by: Sergei Shtylyov CC: sta...@vger.kernel.org --- The patch is against the 'driver-core-linus' branch of Greg KH's 'driver-core.git' repo. drivers/base/platform.c |4 ++-- 1 file changed, 2 insert

[PATCH] of: irq: fix of_irq_get[_byname]() kernel-doc

). Document all possible return value variants, making the writing of the word "IRQ" consistent, while at it... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()") Signed-off-by:

[PATCH] of: irq: fix of_irq_get[_byname]() kernel-doc

). Document all possible return value variants, making the writing of the word "IRQ" consistent, while at it... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()") Signed-of

Re: [PATCH v3 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Hello. On 5/27/2016 2:31 PM, William Wu wrote: This patch documents the device tree documentation required for Documents the documentation? :-) Rockchip USB3.0 core wrapper consist of USB3.0 IP from Synopsys. Consisting? It could operate in device mode (SS, HS, FS) and host mode

Re: [PATCH v3 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Hello. On 5/27/2016 2:31 PM, William Wu wrote: This patch documents the device tree documentation required for Documents the documentation? :-) Rockchip USB3.0 core wrapper consist of USB3.0 IP from Synopsys. Consisting? It could operate in device mode (SS, HS, FS) and host mode

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/23/2016 06:19 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/23/2016 06:19 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/23/2016 04:40 PM, Sergei Shtylyov wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/23/2016 04:40 PM, Sergei Shtylyov wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 5/23/2016 4:26 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 5/23/2016 4:26 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

Hello. On 5/23/2016 3:00 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated

Hello. On 5/23/2016 3:00 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/20/2016 08:06 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/20/2016 08:06 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/20/2016 05:51 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated

On 05/20/2016 05:51 PM, Andrew Goodbody wrote: Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was

Re: [PATCH 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints

Hello. On 05/20/2016 05:51 PM, Andrew Goodbody wrote: shared_fifo endpoints would only get a previous tx state cleared out, the rx state was only cleared for non shared_fifo endpoints Change this so that the rx state is cleared for all endpoints. This addresses an issue that resulted in rx

Re: [PATCH 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints

Hello. On 05/20/2016 05:51 PM, Andrew Goodbody wrote: shared_fifo endpoints would only get a previous tx state cleared out, the rx state was only cleared for non shared_fifo endpoints Change this so that the rx state is cleared for all endpoints. This addresses an issue that resulted in rx

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

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

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

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

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

Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

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

Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

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

Hello. On 05/13/2016 10:18 PM, 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 10:18 PM, 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/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the

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

Hello. On 05/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the

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

Hello. On 05/13/2016 10:06 AM, Uwe Kleine-König wrote: [...] Index: net-next/drivers/of/of_mdio.c === --- net-next.orig/drivers/of/of_mdio.c +++ net-next/drivers/of/of_mdio.c @@ -44,6 +44,7 @@ static int of_get_phy_id(struct

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

Hello. On 05/13/2016 10:06 AM, Uwe Kleine-König wrote: [...] Index: net-next/drivers/of/of_mdio.c === --- net-next.orig/drivers/of/of_mdio.c +++ net-next/drivers/of/of_mdio.c @@ -44,6 +44,7 @@ static int of_get_phy_id(struct

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

Hello. On 05/13/2016 07:06 AM, Andrew Lunn wrote: + gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); + /* Deassert the reset signal */ + if (!IS_ERR(gpiod)) + gpiod_direction_output(gpiod, 0); This is wrong I think. You must only ignore -ENODEV, all

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

Hello. On 05/13/2016 07:06 AM, Andrew Lunn wrote: + gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); + /* Deassert the reset signal */ + if (!IS_ERR(gpiod)) + gpiod_direction_output(gpiod, 0); This is wrong I think. You must only ignore -ENODEV, all

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

On 05/13/2016 11:44 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

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

On 05/13/2016 11:44 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

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

Hello. On 05/13/2016 12:07 PM, Roger Quadros wrote: [...] +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev struct mdio_driver *mdiodrv = to_mdio_driver(drv);

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

Hello. On 05/13/2016 12:07 PM, Roger Quadros wrote: [...] +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev struct mdio_driver *mdiodrv = to_mdio_driver(drv);

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