linux-kernel - Re: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200629114333.GB121549@kroah.com>
Date:   Mon, 29 Jun 2020 13:43:33 +0200
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Pawel Laszczak <pawell@...ence.com>
Cc:     Peter Chen <peter.chen@....com>, Felipe Balbi <balbi@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
        "ben.dooks@...ethink.co.uk" <ben.dooks@...ethink.co.uk>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        "rogerq@...com" <rogerq@...com>,
        "weiyongjun1@...wei.com" <weiyongjun1@...wei.com>,
        Jayshri Dajiram Pawar <jpawar@...ence.com>,
        Rahul Kumar <kurahul@...ence.com>,
        Sanket Parmar <sparmar@...ence.com>
Subject: Re: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.

On Mon, Jun 29, 2020 at 11:20:00AM +0000, Pawel Laszczak wrote:
> 
> >> > Hi Felipe,
> >> >
> >> > >
> >> > >Hi,
> >> > >
> >> > >Pawel Laszczak <pawell@...ence.com> 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.
> >
> 
> Ok, 
> 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 remain in 
> cdns3 directory.

In the cdns3 directory makes the most sense.

thanks,

greg k-h