RE: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.

[Pawel Laszczak]

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

I'm able to recognize in dynamic way which part of code is used, and it works correct.
The problem is when I want to build both driver in kernel at the same time. 

I have two separate directory cdnsp and cdns3 and both has separate Makefile.

In cdns3 Makefile there is 
...
cdns3-y					:= cdns3-plat.o core.o drd.o
..

In cdnsp Makefile there is: 
..
cdnsp-pci-y				:= cdnsp-pci.o ../cdns3/core.o \
					   ../cdns3/drd.o
...

During compiling kernel, the compilator compile twice core.c and drd.c. 
At this moment all is ok, but during preparing the kernel image the 
compiler complains that he sees duplicated all non-static function from 
core.c drd.c.  It's looks like he tries to add twice the same function. 

Moving common code (most of core core.c and drd.c) to separate module,
this non static reusable function will be compiled in kernel only once and both
driver can reuse it.  The only inconvenience is that, we need load one additional 
module to use driver.
--
Thanks  
Pawel Laszczak