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-next>] [day] [month] [year] [list]
Date:   Wed, 11 Dec 2019 13:17:24 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Chng, Jack Ping" <jack.ping.chng@...ux.intel.com>
Cc:     devel@...verdev.osuosl.org, cheol.yong.kim@...el.com,
        andriy.shevchenko@...el.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, mallikarjunax.reddy@...ux.intel.com,
        davem@...emloft.net
Subject: Re: FW: [PATCH v2] staging: intel-gwdpa: gswip: Introduce Gigabit
 Ethernet Switch (GSWIP) device driver

On Wed, Dec 11, 2019 at 06:37:42PM +0800, Chng, Jack Ping wrote:
> Hi Greg,
> 
> > -----Original Message-----
> > From: Greg KH <gregkh@...uxfoundation.org>
> > Sent: Wednesday, December 11, 2019 5:28 PM
> > To: Chng, Jack Ping <jack.ping.chng@...el.com>
> > Cc: devel@...verdev.osuosl.org; Kim, Cheol Yong <cheol.yong.kim@...el.com>; Shevchenko, Andriy <andriy.shevchenko@...el.com>; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Amireddy Mallikarjuna reddy <mallikarjunax.reddy@...ux.intel.com>; davem@...emloft.net
> > Subject: Re: [PATCH v2] staging: intel-gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver
> > 
> > On Wed, Dec 11, 2019 at 04:57:28PM +0800, Jack Ping CHNG wrote:
> > > This driver enables the Intel's LGM SoC GSWIP block.
> > > GSWIP is a core module tailored for L2/L3/L4+ data plane and QoS functions.
> > > It allows CPUs and other accelerators connected to the SoC datapath to
> > > enqueue and dequeue packets through DMAs.
> > > Most configuration values are stored in tables such as Parsing and
> > > Classification Engine tables, Buffer Manager tables and Pseudo MAC
> > > tables.
> > Odd line wrapping :(
> > 
> > > Signed-off-by: Jack Ping CHNG <jack.ping.chng@...el.com>
> > > Signed-off-by: Amireddy Mallikarjuna reddy
> > > <mallikarjunax.reddy@...ux.intel.com>
> > > ---
> > > Changes on v2:
> > > - Renamed intel-dpa to intel-gwdpa
> > > - Added intel-gwdpa.txt(Intel Gateway Datapath Architecture)
> > > - Added TODO (upstream plan)
> > 
> > > +Upstream plan
> > > +--------------
> > > +
> > > +      GSWIP  CQM  PP  DPM     DCDP
> > > +        |     |    |   |        |
> > > +        |     |    |   |        |
> > > +        V     V    V   V        V
> > > +        -------------------------------------( drivers/staging/intel-gwdpa/* )
> > > +                            |  (move to soc folder)
> > > +                            V
> > > +                    -------------------------(
> > > + drivers/soc/intel/gwdpa-*/* )
> > > +
> > > +                            Eth driver  Wireless/
> > > +                                |       WAN driver
> > > +                                |         |
> > > +                                V         V
> > > +                             ----------------( drivers/net/ethernet/intel )
> > > +                                             ( drivers/net/wireless )
> > > +                                             ( drivers/net/wan)
> > > +
> > > +* Each driver will have a TODO list.
> > Again, what kind of plan is this?  It's just a "these files need to be moved to this location" plan?
> > 
> > Why not do that today?
> > 
> > What is keeping this code from being accepted in the "correct" place today?  And why do you want it in staging?  You know it takes even more work to do things here, right?  Are you ready to sign up for that work (hint, you didn't add your names to the MAINTAINER file, so I worry about that...)
> 
> Thanks for the reply.
> 
> We are trying to upstream the datapath code for Intel new NoC gateway
> (please refer to intel-gwdpa.txt at the end of the patch). It consists of
> ethernet, WIFI and passive optics handling. Since the code is quite huge, we
> have broken it into parts for internal review.
> 
> As we have seen past upstream example such as fsl/dpaa, we thought that it
> is better for us to start the upstreaming of the driver into staging folder
> to get feedback from the community.
> 
> Is this the right approach? Or do we upstream all the drivers into
> drivers/soc folder when we have all the drivers ready?

Why is drivers/soc/ the place to put networking drivers?

Please please please work with the Intel Linux kernel developers who
know how to do this type of thing and do not require the kernel
community to teach you all the proper development model and methods
here.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ