Messages in this thread | | | Date | Thu, 12 Oct 2023 11:47:37 +0530 | Subject | Re: [PATCH v13 00/10] Add multiport support for DWC3 controllers | From | Krishna Kurapati PSSNV <> |
| |
On 10/11/2023 3:04 PM, Konrad Dybcio wrote: > > > On 10/11/23 07:11, Krishna Kurapati PSSNV wrote: >> >> >> On 10/11/2023 2:21 AM, Konrad Dybcio wrote: >>> >>> >>> On 10/7/23 17:47, Krishna Kurapati wrote: >>>> Currently the DWC3 driver supports only single port controller which >>>> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has >>>> DWC3 controller with multiple ports that can operate in host mode. >>>> Some of the port supports both SS+HS and other port supports only HS >>>> mode. >>>> >>>> This change primarily refactors the Phy logic in core driver to allow >>>> multiport support with Generic Phy's. >>>> >>>> Changes have been tested on QCOM SoC SA8295P which has 4 ports (2 >>>> are HS+SS capable and 2 are HS only capable). >>>> >>>> Changes in v13: >>>> This series is a subset of patches in v11 as the first 3 patches in v11 >>>> have been mereged into usb-next. >>>> Moved dr_mode property from platform specific files to common >>>> sc8280xp DT. >>>> Fixed function call wrapping, added comments and replaced #defines with >>>> enum in dwc3-qcom for identifying IRQ index appropriately. >>>> Fixed nitpicks pointed out in v11 for suspend-resume handling. >>>> Added reported-by tag for phy refactoring patch as a compile error was >>>> found by kernel test bot [1]. >>> "If you fix the issue in a separate patch/commit (i.e. not just a new >>> version of >>> the same patch/commit), kindly add following tags" >>> >>> the issue your patch resolves is not one that was reported by the >>> kernel testing robot, it just pointed out that you need to fix up the >>> next revision >>> >> >> I Agree. It sounds wrong to add a reproted-by tag making it seem like >> a bug instead of a feature we have written. But if we fix the compile >> error mentioned and not add the "reported-by", its like not giving >> credit for the reporter. So I put in the reproted by and closes tag to >> give a view of what was reported and the feature implemented. > This is a normal thing in review, people spot mistakes, null ptrs, etc.. > > If I had a reported-by for each review where I pointed out e.g. device > tree changes that don't compile i'd be topping lwn charts >
Sure. Will keep this in mind for future patches. And if revising this again, will remove the above two tags.
Regards, Krishna,
| |