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: Wed, 4 Dec 2024 16:36:53 +0200	[thread overview]
Message-ID: <97c32006-1607-45f8-a51b-a67892742f55@kernel.org> (raw)
In-Reply-To: <ftdjegd5mctcn3ndvgrl4apyxkzms7hxivxlyjcrk4qrmvsx7r@og3t7eyyhmkt>



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.

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".

> 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.

> 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?

> 
>>
>> Another alternative could be to override dr_mode to "peripheral" if
>> it was "otg" in dwc3_generic_probe before calling dwc3_init() but
>> I don't prefer that as we are loosing platform information here
>> and it will have to be reverted when dual-role support is added in core.c.
>>
>> So better to deal with this in core.c and add a note why we are doing it.
>>
> 
> [...]
> 
> Regards,
> Siddharth.

-- 
cheers,
-roger


  reply	other threads:[~2024-12-04 14:37 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 [this message]
2024-12-04 15:00                     ` Siddharth Vadapalli
2024-12-04 22:16                       ` Roger Quadros
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=97c32006-1607-45f8-a51b-a67892742f55@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