From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-25 17:34:56
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(-)
--
2.30.2
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-25 17:34:56
If GPIO controller is not available yet we need to defer
the probe of GBE until provider will become available.
While here, drop GPIOF_EXPORT because it's deprecated and
may not be available.
Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
@@ -2627,26 +2627,45 @@ static int pch_gbe_probe(struct pci_dev *pdev,returnret;}+staticvoidpch_gbe_gpio_remove_table(void*table)+{+gpiod_remove_lookup_table(table);+}++staticintpch_gbe_gpio_add_table(structdevice*dev,void*table)+{+gpiod_add_lookup_table(table);+returndevm_add_action_or_reset(dev,pch_gbe_gpio_remove_table,table);+}++staticstructgpiod_lookup_tablepch_gbe_minnow_gpio_table={+.dev_id="0000:02:00.1",+.table={+GPIO_LOOKUP("sch_gpio.33158",13,NULL,GPIO_ACTIVE_LOW),+{}+},+};+/* The AR803X PHY on the MinnowBoard requires a physical pin to be toggled to*ensureitisawakeforprobeandinit.RequestthelineandresetthePHY.*/staticintpch_gbe_minnow_platform_init(structpci_dev*pdev){-unsignedlongflags=GPIOF_OUT_INIT_HIGH;-unsignedgpio=MINNOW_PHY_RESET_GPIO;+structgpio_desc*gpiod;intret;-ret=devm_gpio_request_one(&pdev->dev,gpio,flags,-"minnow_phy_reset");-if(ret){-dev_err(&pdev->dev,-"ERR: Can't request PHY reset GPIO line '%d'\n",gpio);+ret=pch_gbe_gpio_add_table(&pdev->dev,&pch_gbe_minnow_gpio_table);+if(ret)returnret;-}-gpio_set_value(gpio,0);+gpiod=devm_gpiod_get(&pdev->dev,NULL,GPIOD_OUT_HIGH);+if(IS_ERR(gpiod))+returndev_err_probe(&pdev->dev,PTR_ERR(gpiod),+"Can't request PHY reset GPIO line\n");++gpiod_set_value(gpiod,1);usleep_range(1250,1500);-gpio_set_value(gpio,1);+gpiod_set_value(gpiod,0);usleep_range(1250,1500);returnret;
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-25 17:34:58
Use readx_poll_timeout_atomic() instead of open coded variants.
While at it, add __iomem attribute to the parameter of pch_gbe_wait_clr_bit().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 27 ++++++-------------
1 file changed, 8 insertions(+), 19 deletions(-)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-25 17:34:58
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-tree drivers, the kernel version matters. The code received lots of
changes, but module version remained constant, since the driver landed in
mainline. So, this version doesn't seem have any practical meaning anymore.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2 --
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 2 ++
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 4 ----
3 files changed, 2 insertions(+), 6 deletions(-)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-25 17:34:58
Sparse is not happy about handling of strict types in pch_ptp_match():
.../pch_gbe_main.c:158:33: warning: incorrect type in argument 2 (different base types)
.../pch_gbe_main.c:158:33: expected unsigned short [usertype] uid_hi
.../pch_gbe_main.c:158:33: got restricted __be16 [usertype]
.../pch_gbe_main.c:158:45: warning: incorrect type in argument 3 (different base types)
.../pch_gbe_main.c:158:45: expected unsigned int [usertype] uid_lo
.../pch_gbe_main.c:158:45: got restricted __be32 [usertype]
.../pch_gbe_main.c:158:56: warning: incorrect type in argument 4 (different base types)
.../pch_gbe_main.c:158:56: expected unsigned short [usertype] seqid
.../pch_gbe_main.c:158:56: got restricted __be16 [usertype]
Fix that by switching to use proper accessors to BE data.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-03-29 15:13:53
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?
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
quoted
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).
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-04-06 10:36:59
On Tue, Mar 30, 2021 at 07:46:58AM +0000, Flavio Suligoi wrote:
Hi Andy,
...
quoted
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
quoted
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?
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
quoted
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.
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-04-08 13:25:59
On Thu, Apr 08, 2021 at 09:57:12AM +0000, Flavio Suligoi wrote:
quoted
quoted
quoted
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
quoted
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?
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2021-04-14 15:10:36
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