On 20-09-22 13:06:26, Pawel Laszczak wrote: > Hi, > > > > >On Mon, Jun 29, 2020 at 03:41:49AM +0000, Peter Chen wrote: > >> On 20-06-26 07:19:56, Pawel Laszczak wrote: > >> > Hi Felipe, > >> > > >> > > > >> > >Hi, > >> > > > >> > >Pawel Laszczak <pawell@xxxxxxxxxxx> writes: > >> > >> This patch introduce new Cadence USBSS DRD driver to linux kernel. > >> > >> > >> > >> The Cadence USBSS DRD Controller is a highly configurable IP Core which > >> > >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and > >> > >> Host Only (XHCI)configurations. > >> > >> > >> > >> The current driver has been validated with FPGA burned. We have support > >> > >> for PCIe bus, which is used on FPGA prototyping. > >> > >> > >> > >> The host side of USBSS-DRD controller is compliance with XHCI > >> > >> specification, so it works with standard XHCI Linux driver. > >> > >> > >> > >> The host side of USBSS DRD controller is compliant with XHCI. > >> > >> The architecture for device side is almost the same as for host side, > >> > >> and most of the XHCI specification can be used to understand how > >> > >> this controller operates. > >> > >> > >> > >> This controller and driver support Full Speed, Hight Speed, Supper Speed > >> > >> and Supper Speed Plus USB protocol. > >> > >> > >> > >> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. > >> > >> The last letter of this acronym means PLUS. The formal name of controller > >> > >> is USBSSP but it's to generic so I've decided to use CDNSP. > >> > >> > >> > >> The patch 1: adds DT binding. > >> > >> The patch 2: adds PCI to platform wrapper used on Cadnece testing > >> > >> platform. It is FPGA based on platform. > >> > >> The patches 3-5: add the main part of driver and has been intentionally > >> > >> split into 3 part. In my opinion such division should not > >> > >> affect understanding and reviewing the driver, and cause that > >> > >> main patch (4/5) is little smaller. Patch 3 introduces main > >> > >> header file for driver, 4 is the main part that implements all > >> > >> functionality of driver and 5 introduces tracepoints. > >> > > > >> > >I'm more interested in how is this different from CDNS3. Aren't they SW compatible? > >> > > >> > In general, the controller can be split into 2 part- DRD part and the rest UDC. > >> > > >> > The second part UDC which consist gadget.c, ring.c and mem.c file is completely different. > >> > > >> > The DRD part contains drd.c and core.c. > >> > cdnsp drd.c is similar to cdns3 drd.c but it's little different. CDNSP has similar, but has different register space. > >> > Some register was moved, some was removed and some was added. > >> > > >> > core.c is very similar and eventually could be common for both drivers. I thought about this but > >> > I wanted to avoid interfering with cdns3 driver at this point CDNSP is still under testing and > >> > CDNS3 is used by some products on the market. > >> > >> Pawel, I suggest adding CDNSP at driver/staging first since it is still > >> under testing. When you are thinking the driver (as well as hardware) are > >> mature, you could try to add gadget part (eg, gadget-v2) and make > >> necessary changes for core.c. > > > >I only take code for drivers/staging/ that for some reason is not > >meeting the normal coding style/rules/whatever. For stuff that is an > >obvious duplicate of existing code like this, and needs to be > >rearchitected. It is much more work to try to convert code once it is > >in the tree than to just do it out of the tree on your own and resubmit > >it, as you don't have to follow the in-kernel rules of "one patch does > >one thing" that you would if it was in staging. > > > >So don't think that staging is the right place for this, just spend a > >few weeks to get it right and then resubmit it. > > > > I had idea to reuse indirect the core.c and drd.c in cdnsp driver. Of course, I've made > the necessary changes to make possible reuse this code. > My approach was to add this file in Makefile in cdnsp but this concept failed. > It even worked until I started testing cdns3 and cdnsp as build in kernel :) > > With this approach I have issue with " multiple definition of .. " > > How should it look like such reusable code ? > > After my experience with above concept I think that only way is to move common code > to separate module, similar as it is in drivers/usb/common directory or libcomposite.ko module. > Could you use compatible string or IP revision number to dynamic judge which part of code you should use? That is to say there is only one Cadence 3 USB driver folder -- cdns3, you only add one gadget file for cdnsp revision? -- Thanks, Peter Chen
