U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@kernel.org>
To: Siddharth Vadapalli <s-vadapalli@ti.com>
Cc: vigneshr@ti.com, bb@ti.com, trini@konsulko.com, marex@denx.de,
	hnagalla@ti.com, mkorpershoek@baylibre.com,
	caleb.connolly@linaro.org, neil.armstrong@linaro.org,
	jan.kiszka@siemens.com, j-humphreys@ti.com, nm@ti.com,
	u-boot@lists.denx.de, srk@ti.com
Subject: Re: [PATCH v2 1/2] usb: dwc3-generic: set "mode" based on caller of dwc3_generic_probe()
Date: Thu, 5 Dec 2024 00:16:16 +0200	[thread overview]
Message-ID: <62a6efb5-4837-482b-987b-7758a943ba7a@kernel.org> (raw)
In-Reply-To: <qf4urghmxyaxjzeurgtsiry625ibwcdspqx3v6fyfg6cek2cgo@txc6qzsw34pg>



On 04/12/2024 17:00, Siddharth Vadapalli wrote:
> On Wed, Dec 04, 2024 at 04:36:53PM +0200, Roger Quadros wrote:
>>
>>
>> On 04/12/2024 15:37, Siddharth Vadapalli wrote:
>>> On Wed, Dec 04, 2024 at 02:34:56PM +0200, Roger Quadros wrote:
>>>>
>>>>
>>>> On 04/12/2024 12:05, Siddharth Vadapalli wrote:
>>>
>>> [...]
>>>
>>>>> Why not do what this patch does? What is the issue with the current
>>>>> patch (apart from the checks, which I could retain as well if others
>>>>> wish so)? The caller clearly mentions the expected role, so why not use
>>>>> that?
>>>>
>>>> Because the patch is more complicated than it needs to be, now that we know:
>>>> 1) generic_host_probe() will only be called when dr_mode is "host",
>>>> 2) generic_peripheral_probe() will only be called when dr_mode is "peripheral"
>>>> or "otg".
>>>>
>>>> The problem case is generic_peripheral_probe() being called with when
>>>> dr_mode is "otg".
>>>
>>> We can also be sure that generic_periperhal_probe() expects dr_mode to
>>> be "peripheral" only and not "otg". So why not fix it at the root, which
>>
>> generic_peripheral_probe() expects nothing from dr_mode.
>> It just expects the USB controller to work in peripheral mode.
> 
> Yes. So configuring the USB controller for peripheral mode of operation
> should be fine, in which case, irrespective of what "dr_mode" says,
> using "peripheral" should enable the desired functionality.
> 
>>
>> dr_mode is just a reflection of platform/device-tree dr_mode. Let's keep it
>> that way and not abuse dr_mode to "peripheral" when it is actually "otg".
> 
> I am not asking to change what the device-tree has. I am asking the need
> to use "otg" as specified in the device-tree when in U-Boot, we cannot
> switch between Host and Peripheral dynamically using "otg". At the end
> of the day, there is no "generic_otg_probe()" which could enable such
> functionality. So I fail to understand why configuring the controller
> for "peripheral" mode as requested by "generic_peripheral_probe()" is
> equivalent to abusing the device-tree.
> 
>>
>>> is what this patch does? Independent of the issue, is the following a
>>> valid use-case?
>>>
>>> generic_peripheral_probe() with plat->dr_mode = "otg" and hence
>>> generic_probe() using "otg" rather than "peripheral"
>>
>> It is a valid use case. The Platform says that the port is "otg"
>> i.e. (plat->dr_mode ="otg")
>> and the user says he wants to use it as peripheral
>> i.e. (by invoking generic_peripheral_probe())
>> Don't you see this as valid.
> 
> Does peripheral mode work when user sets "otg" in the device-tree?
> Clearly it doesn't and hence this patch. Linux supports "otg" mode in
> the sense that we can switch between "host" and "peripheral". U-Boot on
> the other hand cannot even enable "peripheral" functionality when
> dr_mode is "otg" in the device-tree, let alone switching roles.
> 
>>
>>> as is the case now. Is this resulting in something functional for other
>>> users of the USB Designware Controller? If the user requests "peripheral"
>>> mode of operation, will "otg" meet the user's requirement? If yes, I have
>>> no further objections. Irrespective of this, if you believe that the fix
>>> should be in the core as you indicated below, please feel free to post
>>> the patch.
>>
>> Let's look at this from the other way around.
>> Why do you not agree that the fix should be in core.c and abusing dr_mode
>> is the correct way to go?
> 
> Isn't "otg" meant to convey that the role isn't fixed and can be
> switched? So how is hard-coding it to "peripheral", not considered as
> abusing the core? I don't intend to argue any further. I probably
> shouldn't have looked at other discussions on the mailing list regarding
> hard-coding "otg" as "peripheral" being incorrect. I should have simply
> posted the PRTCAPDIR fix in the core, instead of trying to come up with
> an acceptable fix. It is only because I felt that it didn't seem acceptable
> that I spent time finding out this inconsistency in "dwc3_generic_probe"
> where configuring the controller for "otg" mode as indicated by
> plat->dr_mode when the caller is "generic_peripheral_probe()" is somehow
> supposed to work in U-Boot where there is no OTG state machine.
> 
> If the fix in the core is the right way to go, please post the patch. I
> only wanted to make USB DFU boot functional on AM62A and didn't want to
> end up in an argument while doing so.

Sorry if you took this as an argument. I was only weighing in if there were
better alternatives.
If we have to go with your solution then your v1 series is better
than v2. I will give my Reviewed-by: there.

-- 
cheers,
-roger


  reply	other threads:[~2024-12-04 22:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-03  9:37 [PATCH v2 0/2] AM62A DWC3: Add support for USB DFU boot in OTG mode Siddharth Vadapalli
2024-12-03  9:37 ` [PATCH v2 1/2] usb: dwc3-generic: set "mode" based on caller of dwc3_generic_probe() Siddharth Vadapalli
2024-12-03 19:23   ` Roger Quadros
2024-12-04  5:16     ` Siddharth Vadapalli
2024-12-04  7:32       ` Roger Quadros
2024-12-04  7:47         ` Siddharth Vadapalli
2024-12-04  9:57           ` Roger Quadros
2024-12-04 10:05             ` Siddharth Vadapalli
2024-12-04 12:34               ` Roger Quadros
2024-12-04 13:37                 ` Siddharth Vadapalli
2024-12-04 14:36                   ` Roger Quadros
2024-12-04 15:00                     ` Siddharth Vadapalli
2024-12-04 22:16                       ` Roger Quadros [this message]
2024-12-03  9:37 ` [PATCH v2 2/2] board: ti: am62ax: env: include environment for DFU Siddharth Vadapalli

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=62a6efb5-4837-482b-987b-7758a943ba7a@kernel.org \
    --to=rogerq@kernel.org \
    --cc=bb@ti.com \
    --cc=caleb.connolly@linaro.org \
    --cc=hnagalla@ti.com \
    --cc=j-humphreys@ti.com \
    --cc=jan.kiszka@siemens.com \
    --cc=marex@denx.de \
    --cc=mkorpershoek@baylibre.com \
    --cc=neil.armstrong@linaro.org \
    --cc=nm@ti.com \
    --cc=s-vadapalli@ti.com \
    --cc=srk@ti.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox