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:     "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        Peter Chen <peter.chen@nxp.com>
CC:     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: AQHWS3YSDa4tJNrkMUOR89XcmNbpYKjqdbIAgAABeQCABIBZgIAADfQAgABtpzA=
Date:   Mon, 29 Jun 2020 11:20:00 +0000
Message-ID: <DM6PR07MB552969E5B50BF3B29547DAEADD6E0@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>
In-Reply-To: <20200629043146.GA323164@kroah.com>
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: e959c437-d236-493b-0907-08d81c1e5d0b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 11:20:00.6597
 (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: rxXGq74zoiWUT0zrdqchMqP5WkbikDy4xmta+cw2xzp8CD6Go02iI4Nlng5nz6Uz2LnWLzq/aACOvu+xMBtr0Izv58tMQ0JfSa3vxxM7awc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR07MB7097
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687
 definitions=2020-06-29_11:2020-06-29,2020-06-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_check_notspam policy=outbound_check score=0 clxscore=1015
 impostorscore=0 priorityscore=1501 malwarescore=0 phishscore=0
 cotscore=-2147483648 mlxlogscore=890 bulkscore=0 suspectscore=0
 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000
 definitions=main-2006290081
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


>> > Hi Felipe,
>> >
>> > >
>> > >Hi,
>> > >
>> > >Pawel Laszczak <pawell@cadence.com> writes:
>> > >> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>> > >>
>> > >> The Cadence USBSS DRD Controller is a highly configurable IP Core w=
hich
>> > >> 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 sup=
port
>> > >> 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 sid=
e,
>> > >> 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 drive=
r.
>> > >> The last letter of this acronym means PLUS. The formal name of cont=
roller
>> > >> 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 intention=
ally
>> > >>              split into 3 part. In my opinion such division should =
not
>> > >>              affect understanding and reviewing the driver, and cau=
se that
>> > >>              main patch (4/5) is little smaller. Patch 3 introduces=
 main
>> > >>              header file for driver, 4 is the main part that implem=
ents 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 c=
ompletely 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) ar=
e
>> 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.
>

Ok,=20
I try to reuse the code from cdns3. Where  such common code should be
placed ? Should I move it to e.g. drivers/usb/common/cdns or it should rema=
in in=20
cdns3 directory.

thanks,

pawel