Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

[Michal Suchanek]

On 27 May 2016 at 05:41, Peter Chen <hzpeterc...@gmail.com> wrote:
> On Thu, May 26, 2016 at 07:25:23PM -0000, Michal Suchanek wrote:
>> Hello,
>>
>> I was updating my config by make oldconfig for a while and noticed that my 
>> USB
>> OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
>> over time.
>>
>> Looking through defconfigs some have it included and some which seem in need 
>> of
>> it don't.
>>
>> Since the dependency is not obvious I think it would be better to select it
>> where possible.
>
> From Documentation/kbuild/kconfig-language.txt
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
>
> But NOP_USB_XCEIV is a visible symbol and can be chosen, besides,
> NOP_USB_XCEIV has already selected USB_PHY. Using select may cause
> dependency problem in future, so unless it is necessary, use it
> as least as possible.
>
> If you are using new code, and it adds new dependency code, it is
> reasonable you may need to update your defconfig.

If the driver gets split into multiple parts that need to be
configured separately that's reasonable.

If the newly required option is some obscure feature internal to the
Linux implementation like NOP_USB_XCEIV it's not reasonable in my
book.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: select NOP_USB_XCEIV by drivers that require it

[Michal Suchanek]

Hello,

I was updating my config by make oldconfig for a while and noticed that my USB
OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
over time.

Looking through defconfigs some have it included and some which seem in need of
it don't.

Since the dependency is not obvious I think it would be better to select it
where possible.

Attaching a patch.

Thanks

Michal

8<--
NOP_USB_XCEIV is non-obvious dependency for MUSB and other drivers.

This is a virtual driver in the sense that there is no actual piece of
hardware you can point at and say you did not include driver for this so
it won't work.

So just change all depends on it to select.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/usb/chipidea/Kconfig |  3 ++-
 drivers/usb/musb/Kconfig | 19 +--
 drivers/usb/phy/Kconfig  |  2 ++
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 3644a35..8d08ebd 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -19,7 +19,8 @@ config USB_CHIPIDEA_OF
 config USB_CHIPIDEA_PCI
tristate
depends on PCI
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
default USB_CHIPIDEA
 
 config USB_CHIPIDEA_UDC
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 886526b..91717b9 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -66,7 +66,8 @@ comment "Platform Glue Layer"
 config USB_MUSB_SUNXI
tristate "Allwinner (sunxi)"
depends on ARCH_SUNXI
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on PHY_SUN4I_USB
depends on EXTCON
depends on GENERIC_PHY
@@ -75,13 +76,15 @@ config USB_MUSB_SUNXI
 config USB_MUSB_DAVINCI
tristate "DaVinci"
depends on ARCH_DAVINCI_DMx
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on BROKEN
 
 config USB_MUSB_DA8XX
tristate "DA8xx/OMAP-L1x"
depends on ARCH_DAVINCI_DA8XX
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on BROKEN
 
 config USB_MUSB_TUSB6010
@@ -89,6 +92,7 @@ config USB_MUSB_TUSB6010
depends on HAS_IOMEM
depends on ARCH_OMAP2PLUS || COMPILE_TEST
depends on NOP_USB_XCEIV = USB_MUSB_HDRC # both built-in or both modules
+   # cannot select NOP_USB_XCEIV because of the dependency above
 
 config USB_MUSB_OMAP2PLUS
tristate "OMAP2430 and onwards"
@@ -99,7 +103,8 @@ config USB_MUSB_OMAP2PLUS
 config USB_MUSB_AM35X
tristate "AM35x"
depends on ARCH_OMAP
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
 
 config USB_MUSB_DSPS
tristate "TI DSPS platforms"
@@ -110,7 +115,8 @@ config USB_MUSB_DSPS
 config USB_MUSB_BLACKFIN
tristate "Blackfin"
depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523)
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
 
 config USB_MUSB_UX500
tristate "Ux500 platforms"
@@ -118,7 +124,8 @@ config USB_MUSB_UX500
 
 config USB_MUSB_JZ4740
tristate "JZ4740"
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on MACH_JZ4740 || COMPILE_TEST
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c690474..a0bdfd3 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -57,6 +57,8 @@ config NOP_USB_XCEIV
  built-in with usb ip or which are autonomous and doesn't require any
  phy programming such as ISP1x04 etc.
 
+ Should be automatically selected by the relevant driver.
+
 config AM335X_CONTROL_USB
tristate
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Michal Suchanek]

On 14 September 2015 at 22:25, Maxime Ripard
 wrote:
> On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10-09-15 20:30, Maxime Ripard wrote:
>> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
>> >>Hi,
>> >>
>> >>On 04-09-15 08:43, Olliver Schinagl wrote:
>> >>>Hey Hans,
>> >>>
>> >>>On 07-08-15 10:45, Olliver Schinagl wrote:
>> 
>> >If you change the dr_mode to host then you _must_ also remove any 
>> >id_det and vbus_det
>> >gpio settings from the usb_phy node in the dts, as the sun4i phy code 
>> >detects
>> >host vs otg mode by checking for the presence of these.
>> Yes, this fixes it and makes it work. Thanks.
>> 
>> >>>I've been going back to this and am wondering if this is something I can 
>> >>>look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
>> >>>simply ignore the pins and treat them as unset?
>> >>
>> >>AFAIK you cannot unset something in dts. The only solution I
>> >>can comeup with is to add a dr_mode argument to the phy like
>> >>we already have for the otg controller itself.
>> >>
>> >>This is something which we likely need to do anyways to add
>> >>support for peripheral only mode, which we seem to need for
>> >>some "hdmi sticks".
>> >
>> >I haven't really followed the rest of the discussion, so sorry if you
>> >already talked about that, but why can't you just set the dr_mode to
>> >peripheral in such a case?
>>
>> This is about the usbphy code not the musb-controller code, which are
>> 2 different dts nodes, atm only the musb-controller node has a
>> dr_mode property, and the phy code decides between host-only
>> and otg mode based on whether an id pin is assigned or not.
>>
>> My proposal is to get rid of the id-pin hack to determine the mode
>> and add a dr_mode property to the usbphy dts node.
>
> I agree that we should get rid of that hack, especially since a lack
> of an ID pin might also be used on a peripheral-only device.
>
> However, we already have that information in the musb node, and
> duplicating the info seems error prone. We already have a custom
> function, maybe that's a case for another one, and that would allow to
> handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected,
> with the otg node set to otg).
>

Hello,

was this solved somehow?

What problem is there with referencing the phy node?

Just like pinmux setting nodes and whatnot it can be named and
referenced by name.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Michal Suchanek]

On 4 January 2016 at 21:39, Philipp Zabel  wrote:
> Am Samstag, den 19.12.2015, 11:55 +0100 schrieb Hans de Goede:
>> On 18-12-15 12:08, Maxime Ripard wrote:

>> >  - If the reset line is in a !exclusive use with more than 1 user,
>> >the refcount is modified and an error is returned to notify that
>> >it didn't happen.
>>
>> Also ack, except for returning the error, if a driver has used
>> reset_control_get_shared, it should simply be aware that doing an assert
>> might not necessarily actually assert the line, just like doing a clk-disable
>> does not really necessary disable the clock, etc. If a driver is not prepared
>> to deal with this, it should simply not use reset_control_get_shared.
>>
>> I see returning an error if the assert did not happen due to other users /
>> deassert_count != 0 as inconsistent compared to how clks, regulators and phys
>> handle this, these all simply return success in this case.
>
> I wouldn't want drivers to have to differentiate between relevant and
> irrelevant error codes, so in the clock-like refcounting use case
> reset_assert should not return an error if it just correctly decremented
> the refcount. I'd still prefer to have separate API for the counted
> must_deassert/may_assert vs the exclusive must_assert/must_deassert use
> cases, but I just can't think of a good name.
>

Maybe something along the lines of assert_now or assert_sync. It
should be possible to call on shared line and then get an error when
the operation is blocked by other user.

The driver may not really care. Depending on the hardware the line can
be shared on one device and exclusive on another. The driver may just
let the line go when the device is powered off. And it may require a
reset cycle when it detects the device is hosed and return an error
when the reset fails for whatever reason.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html