Message ID | 20231007154806.605-1-quic_kriskura@quicinc.com |
---|---|
Headers | show |
Series | Add multiport support for DWC3 controllers | expand |
On 10/8/2023 4:13 PM, Krzysztof Kozlowski wrote: > On 07/10/2023 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). >> > > I think I said it few times on the lists to Qualcomm folks, although I > cannot remember whether exactly in this patchset. Please split DTS from > USB, because Greg prefers to grab everything and DTS *should go* via > Qualcomm SoC. > Hi Krzyztof, Apologies ! Do you mean to send the DTS just to linux-arm-msm list and not linux-usb list ? I don't think it was posted on this series and I am not on linux-arm-msm mailing list, so missed that comment. Sorry for that. I saw some series where DT, Driver and bindings were sent as one set to linux-usb list as well and so wanted to follow suite. Will make sure to send DT just to linux-arm-msm list from now on. Thanks for the comments :-) Regards, Krishna,
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 Konrad
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 Konrad