Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Pawel Laszczak <pawell@cadence.com>
To:     Peter Chen <peter.chen@nxp.com>
CC:     "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        Felipe Balbi <balbi@kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
        "ben.dooks@codethink.co.uk" <ben.dooks@codethink.co.uk>,
        "colin.king@canonical.com" <colin.king@canonical.com>,
        "rogerq@ti.com" <rogerq@ti.com>,
        "weiyongjun1@huawei.com" <weiyongjun1@huawei.com>,
        Jayshri Dajiram Pawar <jpawar@cadence.com>,
        Rahul Kumar <kurahul@cadence.com>,
        Sanket Parmar <sparmar@cadence.com>
Subject: RE: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
Thread-Topic: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
Thread-Index: AQHWS3YSDa4tJNrkMUOR89XcmNbpYKjqdbIAgAABeQCABIBZgIAADfQAgIYgtQCAAO0xAIAABQBA
Date:   Wed, 23 Sep 2020 03:37:42 +0000
Message-ID: <DM6PR07MB5529164EFCDF36CE75E8AF3DDD380@DM6PR07MB5529.namprd07.prod.outlook.com>
References: <20200626045450.10205-1-pawell@cadence.com>
 <878sga5nfr.fsf@kernel.org>
 <BL0PR07MB5522A8796EE7BFB5062A8E76DD930@BL0PR07MB5522.namprd07.prod.outlook.com>
 <20200629034213.GB30684@b29397-desktop> <20200629043146.GA323164@kroah.com>
 <DM6PR07MB5529B75D3CF135D540749C1DDD3B0@DM6PR07MB5529.namprd07.prod.outlook.com>
 <20200923025540.GA31183@b29397-desktop>
In-Reply-To: <20200923025540.GA31183@b29397-desktop>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b67dce4b-75da-438d-6d68-08d85f72077a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 03:37:42.6531
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d36035c5-6ce6-4662-a3dc-e762e61ae4c9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FFb8RG9WbSYf7vVQjHtOy8z9EVjEXNyQh+yYXsPLA5SwXdjkT9qbYD3BPPcw9b2mQbpkGD9QL+zEhb6EmxzFHw+H2twD+b/nQWDcxbHS6l0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR07MB6667
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687
 definitions=2020-09-23_02:2020-09-21,2020-09-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_check_notspam policy=outbound_check score=0 mlxscore=0
 impostorscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 phishscore=0
 bulkscore=0 adultscore=0 mlxlogscore=883 clxscore=1011 priorityscore=1501
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2006250000 definitions=main-2009230024
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>
>
>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@cadence.com> writes:
>> >> > >> This patch introduce new Cadence USBSS DRD driver to linux kerne=
l.
>> >> > >>
>> >> > >> The Cadence USBSS DRD Controller is a highly configurable IP Cor=
e which
>> >> > >> can be instantiated as Dual-Role Device (DRD), Peripheral Only a=
nd
>> >> > >> 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, Supp=
er Speed
>> >> > >> and Supper Speed Plus USB protocol.
>> >> > >>
>> >> > >> The prefix cdnsp used in driver has chosen by analogy to cdn3 dr=
iver.
>> >> > >> The last letter of this acronym means PLUS. The formal name of c=
ontroller
>> >> > >> 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 testin=
g
>> >> > >>              platform. It is FPGA based on platform.
>> >> > >> The patches 3-5: add the main part of driver and has been intent=
ionally
>> >> > >>              split into 3 part. In my opinion such division shou=
ld not
>> >> > >>              affect understanding and reviewing the driver, and =
cause that
>> >> > >>              main patch (4/5) is little smaller. Patch 3 introdu=
ces main
>> >> > >>              header file for driver, 4 is the main part that imp=
lements all
>> >> > >>              functionality of driver and 5 introduces tracepoint=
s.
>> >> > >
>> >> > >I'm more interested in how is this different from CDNS3. Aren't th=
ey SW compatible?
>> >> >
>> >> > In general, the controller can be split into 2 part- DRD part and t=
he rest UDC.
>> >> >
>> >> > The second part UDC which consist gadget.c, ring.c and mem.c file i=
s 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. CD=
NSP 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 driv=
ers.  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 sti=
ll
>> >> 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 co=
urse, 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 f=
ailed.
>> It even worked until I started testing cdns3 and cdnsp as build in kerne=
l :)
>>
>> 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 wor=
ks correct.
The problem is when I want to build both driver in kernel at the same time.=
=20

I have two separate directory cdnsp and cdns3 and both has separate Makefil=
e.

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

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

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

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 addi=
tional=20
module to use driver.
--
Thanks =20
Pawel Laszczak