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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180910182104.GD6019@kroah.com>
Date:   Mon, 10 Sep 2018 20:21:04 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Pawel Laszczak <pawell@...ence.com>
Cc:     Roger Quadros <rogerq@...com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Felipe Balbi <balbi@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Lukasz Tyrala <ltyrala@...ence.com>,
        Alan Douglas <adouglas@...ence.com>
Subject: Re: [PATCH 00/31] Introduced new Cadence USBSSP DRD Driver

On Thu, Aug 02, 2018 at 04:26:45AM +0000, Pawel Laszczak wrote:
> > > This patch set introduce new Cadence USBSSP DRD driver to linux
> > > kernel.
> > >
> > > The Cadence USBSSP DRD Driver s 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 site of USBSSP controller is compliance with XHCI
> > > specification, so it works with standard XHCI linux driver.
> > >
> > > Also, device side of USBSSP controller was designed in such way to
> > > looks like XHCI. It means that most of logic of USBSSP controller is
> > > also compliance with XHCI specification.
> > >
> > > Consequently, the USBSSP driver for peripheral mode is very similar to
> > > XHCI driver.
> > >
> > > This version of driver supports only Device mode but DRD and Host mode
> > > will be added in the future.
> > >
> > 
> > Based on the posting date this series looks like v3.
> > 
> > You should add the version prefix to the patches next time.
> > e.g. [PATCH v4 ...]
> >
> I wanted to start versioning driver after this set patch will be approved. 

What does that mean?  No one "approves" a patch series and then you
start numbering it.

Have you read the kernel documentation for how to properly create and
submit a kernel patch series and write a good changelog?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ