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
next prev parent 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