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