mbox series

[net-next,v2,0/5] net: pch: fix and a few cleanups

Message ID 20210325173412.82911-1-andriy.shevchenko@linux.intel.com (mailing list archive)
Headers show
Series net: pch: fix and a few cleanups | expand

Message

Andy Shevchenko March 25, 2021, 5:34 p.m. UTC
The series provides one fix (patch 1) for GPIO to be able to wait for
the GPIO driver to appear. This is separated from the conversion to
the GPIO descriptors (patch 2) in order to have a possibility for
backporting. Patches 3 and 4 fix a minor warnings from Sparse while
moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.

Tested on Intel Minnowboard (v1).

Since v2:
- added a few cleanups on top of the fix

Andy Shevchenko (5):
  net: pch_gbe: Propagate error from devm_gpio_request_one()
  net: pch_gbe: Convert to use GPIO descriptors
  net: pch_gbe: use readx_poll_timeout_atomic() variant
  net: pch_gbe: Use proper accessors to BE data in pch_ptp_match()
  net: pch_gbe: remove unneeded MODULE_VERSION() call

 .../net/ethernet/oki-semi/pch_gbe/pch_gbe.h   |   2 -
 .../oki-semi/pch_gbe/pch_gbe_ethtool.c        |   2 +
 .../ethernet/oki-semi/pch_gbe/pch_gbe_main.c  | 103 +++++++++---------
 3 files changed, 54 insertions(+), 53 deletions(-)

Comments

Andy Shevchenko March 29, 2021, 3:13 p.m. UTC | #1
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> The series provides one fix (patch 1) for GPIO to be able to wait for
> the GPIO driver to appear. This is separated from the conversion to
> the GPIO descriptors (patch 2) in order to have a possibility for
> backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> 
> Tested on Intel Minnowboard (v1).

Anything should I do here?
Flavio Suligoi March 30, 2021, 7:46 a.m. UTC | #2
Hi Andy,
...
> On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > The series provides one fix (patch 1) for GPIO to be able to wait for
> > the GPIO driver to appear. This is separated from the conversion to
> > the GPIO descriptors (patch 2) in order to have a possibility for
> > backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> > moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> >
> > Tested on Intel Minnowboard (v1).
> 
> Anything should I do here?

it's ok for me

> --
> With Best Regards,
> Andy Shevchenko
> 

Best regards,
Flavio Suligoi
Andy Shevchenko April 6, 2021, 10:36 a.m. UTC | #3
On Tue, Mar 30, 2021 at 07:46:58AM +0000, Flavio Suligoi wrote:
> Hi Andy,
> ...
> > On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > > The series provides one fix (patch 1) for GPIO to be able to wait for
> > > the GPIO driver to appear. This is separated from the conversion to
> > > the GPIO descriptors (patch 2) in order to have a possibility for
> > > backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> > > moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> > >
> > > Tested on Intel Minnowboard (v1).
> > 
> > Anything should I do here?
> 
> it's ok for me

Thanks!
Who may apply them?
Flavio Suligoi April 8, 2021, 9:57 a.m. UTC | #4
Hi Andy,

> > > On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > > > The series provides one fix (patch 1) for GPIO to be able to wait for
> > > > the GPIO driver to appear. This is separated from the conversion to
> > > > the GPIO descriptors (patch 2) in order to have a possibility for
> > > > backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> > > > moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> > > >
> > > > Tested on Intel Minnowboard (v1).
> > >
> > > Anything should I do here?
> >
> > it's ok for me
> 
> Thanks!
> Who may apply them?

I used your patches on kernel net-next 5.12.0-rc2, on a board with an
Intel(R) Atom(TM) CPU E640   @ 1.00GHz and an EG20T PCH.
I used the built-in OKI gigabit ethernet controller:

02:00.1 Ethernet controller: Intel Corporation Platform Controller Hub EG20T Gigabit Ethernet Controller (rev 02)
	Kernel driver in use: pch_gbe

with a simple iperf test and all works fine:

ht-700 ~ # iperf -c 192.168.200.1
------------------------------------------------------------
Client connecting to 192.168.200.1, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.159 port 38638 connected with 192.168.200.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   178 MBytes   149 Mbits/sec
ht-700 ~ # iperf -c 192.168.200.1
------------------------------------------------------------
Client connecting to 192.168.200.1, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.159 port 38640 connected with 192.168.200.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   178 MBytes   149 Mbits/sec
ht-700 ~ # iperf -c 192.168.200.1 -u
------------------------------------------------------------
Client connecting to 192.168.200.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.159 port 58364 connected with 192.168.200.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
ht-700 ~ # iperf -c 192.168.200.1 -u
------------------------------------------------------------
Client connecting to 192.168.200.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.159 port 32778 connected with 192.168.200.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
ht-700 ~ # uname -a
Linux ht-700 5.12.0-rc2-watchdog+ #12 SMP Thu Apr 8 11:08:49 CEST 2021 x86_64 x86_64 x86_64 GNU/Linux
ht-700 ~ # 

I hope this can help you.

> 

Tested-by: Flavio Suligoi <f.suligoi@asem.it>

> --
> With Best Regards,
> Andy Shevchenko
> 
Best regards,
Flavio Suligoi
Andy Shevchenko April 8, 2021, 1:25 p.m. UTC | #5
On Thu, Apr 08, 2021 at 09:57:12AM +0000, Flavio Suligoi wrote:
> > > > On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > > > > The series provides one fix (patch 1) for GPIO to be able to wait for
> > > > > the GPIO driver to appear. This is separated from the conversion to
> > > > > the GPIO descriptors (patch 2) in order to have a possibility for
> > > > > backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> > > > > moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> > > > >
> > > > > Tested on Intel Minnowboard (v1).
> > > >
> > > > Anything should I do here?
> > >
> > > it's ok for me
> > 
> > Thanks!
> > Who may apply them?
> 
> I used your patches on kernel net-next 5.12.0-rc2, on a board with an
> Intel(R) Atom(TM) CPU E640   @ 1.00GHz and an EG20T PCH.
> I used the built-in OKI gigabit ethernet controller:
> 
> 02:00.1 Ethernet controller: Intel Corporation Platform Controller Hub EG20T Gigabit Ethernet Controller (rev 02)
> 	Kernel driver in use: pch_gbe
> 
> with a simple iperf test and all works fine:

> I hope this can help you.

> Tested-by: Flavio Suligoi <f.suligoi@asem.it>

Thank you, Flavio, very much!

Jesse, Jakub, David. can this be applied, please?
Andy Shevchenko April 14, 2021, 3:10 p.m. UTC | #6
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> The series provides one fix (patch 1) for GPIO to be able to wait for
> the GPIO driver to appear. This is separated from the conversion to
> the GPIO descriptors (patch 2) in order to have a possibility for
> backporting. Patches 3 and 4 fix a minor warnings from Sparse while
> moving to a new APIs. Patch 5 is MODULE_VERSION() clean up.
> 
> Tested on Intel Minnowboard (v1).

Guys, it has been already the report from kbuild bot (sparse warnings), which
should be fixed by this series (at least partially if not completely).

Please, apply this as soon as it's possible.
Or tell me what's wrong with the series.

Thanks!

> Since v2:
> - added a few cleanups on top of the fix
> 
> Andy Shevchenko (5):
>   net: pch_gbe: Propagate error from devm_gpio_request_one()
>   net: pch_gbe: Convert to use GPIO descriptors
>   net: pch_gbe: use readx_poll_timeout_atomic() variant
>   net: pch_gbe: Use proper accessors to BE data in pch_ptp_match()
>   net: pch_gbe: remove unneeded MODULE_VERSION() call
> 
>  .../net/ethernet/oki-semi/pch_gbe/pch_gbe.h   |   2 -
>  .../oki-semi/pch_gbe/pch_gbe_ethtool.c        |   2 +
>  .../ethernet/oki-semi/pch_gbe/pch_gbe_main.c  | 103 +++++++++---------
>  3 files changed, 54 insertions(+), 53 deletions(-)
> 
> -- 
> 2.30.2
>