All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-usb@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Markus Reichl <m.reichl@fivetechno.de>,
	Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH v2] usb: core: verify devicetree nodes for disabled interfaces
Date: Wed, 08 May 2019 16:27:37 +0100	[thread overview]
Message-ID: <yw1xpnotufti.fsf@mansr.com> (raw)
In-Reply-To: <e7f32280-57ec-6298-1a5d-8d2d4dc26667@samsung.com> (Marek Szyprowski's message of "Wed, 8 May 2019 15:49:22 +0200")

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> Hi
>
> On 2019-05-08 13:46, Måns Rullgård wrote:
>> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>>> Commit 01fdf179f4b0 ("usb: core: skip interfaces disabled in devicetree")
>>> add support for disabling given USB device interface by adding nodes to
>>> the USB host controller device. The mentioned commit however identifies
>>> the given USB interface node only by the 'reg' property in the host
>>> controller children nodes and then checks for their the 'status'. The USB
>>> device interface nodes however also has to have a 'compatible' property as
>>> described in Documentation/devicetree/bindings/usb/usb-device.txt. This is
>>> important, because USB host controller might have child-nodes for other
>>> purposes. For example, Exynos EHCI and OHCI drivers already define
>>> child-nodes for each physical root hub port and assigns respective PHY
>>> controller and parameters for them. This conflicts with the proposed
>>> approach and verifying for the presence of the compatible property fixes
>>> this issue without changing the bindings and the way the PHY controllers
>>> are handled by Exynos EHCI/OHCI drivers.
>>>
>>> Reported-by: Markus Reichl <m.reichl@fivetechno.de>
>>> Fixes: 01fdf179f4b0 ("usb: core: skip interfaces disabled in devicetree")
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> ---
>>>   drivers/usb/core/message.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
>>> index e844bb7b5676..6f7d047392bd 100644
>>> --- a/drivers/usb/core/message.c
>>> +++ b/drivers/usb/core/message.c
>>> @@ -2009,6 +2009,7 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
>>>   		struct usb_interface *intf = cp->interface[i];
>>>
>>>   		if (intf->dev.of_node &&
>>> +		    of_find_property(intf->dev.of_node, "compatible", NULL) &&
>>>   		    !of_device_is_available(intf->dev.of_node)) {
>>>   			dev_info(&dev->dev, "skipping disabled interface %d\n",
>>>   				 intf->cur_altsetting->desc.bInterfaceNumber);
>>> -- 
>> I don't think this is the right approach.  We don't want to be adding
>> such checks everywhere the of_node is used.  A better way might be to
>> not set of_node at all in the absence of a proper "compatible" string.
>
> Right, this will be a better approach. I've just checked the code and a 
> simple check for 'compatible' property presence can be easily added in 
> drivers/usb/core/of.c in usb_of_get_device_node() and 
> usb_of_get_interface_node() functions.
>
> The second check could be added in drivers/usb/core/hub.c in 
> usb_new_device() - to ensure that the device's vid/pid matches of_node 
> compatible string.
>
> Is this okay? Or just add a latter one?

I'm not sure where the best place to check is.  Someone else will have
to weigh in on that.

>> Then there's the problem of how to resolve the incompatibility between
>> the generic USB and Exynos bindings.  One possible fix could be to use
>> a child node of the controller node to represent the root hub.  Since
>> the driver currently doesn't work at all if a devicetree has nodes for
>> USB devices, there should be no compatibility concerns.
>
> So far we don't have any use case for adding devicetree nodes for usb 
> devices under Exynos EHCI/OHCI hcd, so this shouldn't be a problem for now.

None that you know of, that is.  Regardless, the bindings are
inconsistent, and that needs to be fixed.

-- 
Måns Rullgård

  reply	other threads:[~2019-05-08 15:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190507125630eucas1p1c5fd171a8dc2a6b8eb9dd317fe245f0c@eucas1p1.samsung.com>
2019-05-07 12:56 ` [PATCH] usb: core: verify devicetree nodes for disabled interfaces Marek Szyprowski
2019-05-07 13:24   ` Måns Rullgård
2019-05-08 10:14     ` Marek Szyprowski
2019-05-08 10:44       ` [PATCH v2] " Marek Szyprowski
2019-05-08 11:46         ` Måns Rullgård
2019-05-08 13:49           ` Marek Szyprowski
2019-05-08 15:27             ` Måns Rullgård [this message]
2019-05-09  8:47               ` [PATCH v3] usb: core: verify devicetree nodes for USB devices Marek Szyprowski
2019-05-09 18:55                 ` Måns Rullgård
2019-05-10  3:10                   ` Peter Chen
2019-05-10  9:43                     ` Marek Szyprowski
2019-05-13  9:00                       ` Peter Chen
2019-05-13  9:07                         ` Marek Szyprowski
2019-05-13  9:23                           ` Peter Chen
2019-05-13 10:03                             ` Marek Szyprowski
2019-05-13 10:06                               ` Måns Rullgård
2019-05-13 10:06                                 ` Måns Rullgård
2019-05-17 11:15                                 ` Marek Szyprowski
2019-05-13 10:03                       ` Måns Rullgård
2019-05-13 10:03                         ` Måns Rullgård
2019-05-17 11:18                         ` Marek Szyprowski
2019-05-09 19:04                 ` Tobias Jakobi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yw1xpnotufti.fsf@mansr.com \
    --to=mans@mansr.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.reichl@fivetechno.de \
    --cc=m.szyprowski@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.