[PATCH net-next 0/4] net: stmmac: new features

[PATCH net-next 0/4] net: stmmac: new features

[Konrad Leszczynski]

This series adds four new patches which introduce features such as ARP
Offload support, VLAN protocol detection and TC flower filter support.

Patchset has been created as a result of discussion at [1].

[1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/

v1 -> v2:
- add missing SoB lines
- place ifa_list under RCU protection

Karol Jurczenia (3):
  net: stmmac: enable ARP Offload on mac_link_up()
  net: stmmac: set TE/RE bits for ARP Offload when interface down
  net: stmmac: add TC flower filter support for IP EtherType

Piotr Warpechowski (1):
  net: stmmac: enhance VLAN protocol detection for GRO

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
 .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++++++-
 include/linux/stmmac.h                        |  1 +
 4 files changed, 50 insertions(+), 6 deletions(-)

-- 
2.34.1

[PATCH net-next 1/4] net: stmmac: enable ARP Offload on mac_link_up()

[Konrad Leszczynski]

From: Karol Jurczenia <karol.jurczenia@intel.com>

Add Address Resolution Protocol (ARP) Offload support in
stmmac_mac_link_up() to enable ARP Offload beside the selftests.

Introduce STMMAC_FLAG_ARP_OFFLOAD_EN flag, which is used to enable the
feature with the stmmac_set_arp_offload().

Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c  | 18 ++++++++++++++++++
 include/linux/stmmac.h                         |  1 +
 2 files changed, 19 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fa3d26c28502..244ef484bb88 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -40,6 +40,7 @@
 #include <linux/phylink.h>
 #include <linux/udp.h>
 #include <linux/bpf_trace.h>
+#include <linux/inetdevice.h>
 #include <net/page_pool/helpers.h>
 #include <net/pkt_cls.h>
 #include <net/xdp_sock_drv.h>
@@ -964,6 +965,8 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 			       bool tx_pause, bool rx_pause)
 {
 	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
+	struct in_device *in_dev;
+	struct in_ifaddr *ifa;
 	unsigned int flow_ctrl;
 	u32 old_ctrl, ctrl;
 	int ret;
@@ -1076,6 +1079,21 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 
 	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
 		stmmac_hwtstamp_correct_latency(priv, priv);
+
+	if (priv->plat->flags & STMMAC_FLAG_ARP_OFFLOAD_EN) {
+		in_dev = in_dev_get(priv->dev);
+		if (!in_dev)
+			return;
+
+		rcu_read_lock();
+		ifa = rcu_dereference(in_dev->ifa_list);
+		if (ifa)
+			stmmac_set_arp_offload(priv, priv->hw, true,
+					       ntohl(ifa->ifa_address));
+		rcu_read_unlock();
+
+		__in_dev_put(in_dev);
+	}
 }
 
 static void stmmac_mac_disable_tx_lpi(struct phylink_config *config)
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e284f04964bf..afb45d8eb840 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -185,6 +185,7 @@ struct dwmac4_addrs {
 #define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
 #define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(12)
 #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
+#define STMMAC_FLAG_ARP_OFFLOAD_EN		BIT(14)
 
 struct plat_stmmacenet_data {
 	int bus_id;
-- 
2.34.1

[PATCH net-next 2/4] net: stmmac: set TE/RE bits for ARP Offload when interface down

[Konrad Leszczynski]

From: Karol Jurczenia <karol.jurczenia@intel.com>

When the network interface is brought down and ARP Offload is enabled,
set the TE (Transmitter Enable) and RE (Receiver Enable) bits.

Ensure that the Network Interface Card (NIC) can continue handling ARP
responses in hardware even when the interface is down.

Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 244ef484bb88..8977e5aebc71 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -950,7 +950,9 @@ static void stmmac_mac_link_down(struct phylink_config *config,
 {
 	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
 
-	stmmac_mac_set(priv, priv->ioaddr, false);
+	if (!(priv->plat->flags & STMMAC_FLAG_ARP_OFFLOAD_EN))
+		stmmac_mac_set(priv, priv->ioaddr, false);
+
 	if (priv->dma_cap.eee)
 		stmmac_set_eee_pls(priv, priv->hw, false);
 
@@ -4183,6 +4185,10 @@ static int stmmac_release(struct net_device *dev)
 	/* Release and free the Rx/Tx resources */
 	free_dma_desc_resources(priv, &priv->dma_conf);
 
+	/* Disable MAC Rx/Tx */
+	stmmac_mac_set(priv, priv->ioaddr, priv->plat->flags &
+					   STMMAC_FLAG_ARP_OFFLOAD_EN);
+
 	/* Powerdown Serdes if there is */
 	if (priv->plat->serdes_powerdown)
 		priv->plat->serdes_powerdown(dev, priv->plat->bsp_priv);
-- 
2.34.1

[PATCH net-next 3/4] net: stmmac: enhance VLAN protocol detection for GRO

[Konrad Leszczynski]

From: Piotr Warpechowski <piotr.warpechowski@intel.com>

Enhance protocol extraction in stmmac_has_ip_ethertype() by introducing
MAC offset parameter and changing:

__vlan_get_protocol() ->  __vlan_get_protocol_offset()

Add correct header length for VLAN tags, which enable Generic Receive
Offload (GRO) in VLAN.

Co-developed-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Piotr Warpechowski <piotr.warpechowski@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8977e5aebc71..630ffb8dd0c3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4590,13 +4590,14 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
  */
 static bool stmmac_has_ip_ethertype(struct sk_buff *skb)
 {
-	int depth = 0;
+	int depth = 0, hlen;
 	__be16 proto;
 
-	proto = __vlan_get_protocol(skb, eth_header_parse_protocol(skb),
-				    &depth);
+	proto = __vlan_get_protocol_offset(skb, skb->protocol,
+					   skb_mac_offset(skb), &depth);
+	hlen = eth_type_vlan(skb->protocol) ? VLAN_ETH_HLEN : ETH_HLEN;
 
-	return (depth <= ETH_HLEN) &&
+	return (depth <= hlen) &&
 		(proto == htons(ETH_P_IP) || proto == htons(ETH_P_IPV6));
 }
 
-- 
2.34.1

[PATCH net-next 4/4] net: stmmac: add TC flower filter support for IP EtherType

[Konrad Leszczynski]

From: Karol Jurczenia <karol.jurczenia@intel.com>

Add missing Traffic Control (TC) offload for flower filters matching the
IP EtherType (ETH_P_IP).

Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 ++++++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 78d6b3737a26..77f900a328aa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -206,6 +206,7 @@ enum stmmac_rfs_type {
 	STMMAC_RFS_T_VLAN,
 	STMMAC_RFS_T_LLDP,
 	STMMAC_RFS_T_1588,
+	STMMAC_RFS_T_IP,
 	STMMAC_RFS_T_MAX,
 };
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
index 694d6ee14381..c5577652d6ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
@@ -239,6 +239,7 @@ static int tc_rfs_init(struct stmmac_priv *priv)
 	priv->rfs_entries_max[STMMAC_RFS_T_VLAN] = 8;
 	priv->rfs_entries_max[STMMAC_RFS_T_LLDP] = 1;
 	priv->rfs_entries_max[STMMAC_RFS_T_1588] = 1;
+	priv->rfs_entries_max[STMMAC_RFS_T_IP] = 32;
 
 	for (i = 0; i < STMMAC_RFS_T_MAX; i++)
 		priv->rfs_entries_total += priv->rfs_entries_max[i];
@@ -777,6 +778,17 @@ static int tc_add_ethtype_flow(struct stmmac_priv *priv,
 			stmmac_rx_queue_routing(priv, priv->hw,
 						PACKET_PTPQ, tc);
 			break;
+		case ETH_P_IP:
+			if (priv->rfs_entries_cnt[STMMAC_RFS_T_IP] >=
+			    priv->rfs_entries_max[STMMAC_RFS_T_IP])
+				return -ENOENT;
+
+			entry->type = STMMAC_RFS_T_IP;
+			priv->rfs_entries_cnt[STMMAC_RFS_T_IP]++;
+
+			stmmac_rx_queue_routing(priv, priv->hw,
+						PACKET_UPQ, tc);
+			break;
 		default:
 			netdev_err(priv->dev, "EthType(0x%x) is not supported", etype);
 			return -EINVAL;
@@ -800,7 +812,7 @@ static int tc_del_ethtype_flow(struct stmmac_priv *priv,
 
 	if (!entry || !entry->in_use ||
 	    entry->type < STMMAC_RFS_T_LLDP ||
-	    entry->type > STMMAC_RFS_T_1588)
+	    entry->type > STMMAC_RFS_T_IP)
 		return -ENOENT;
 
 	switch (entry->etype) {
@@ -814,6 +826,11 @@ static int tc_del_ethtype_flow(struct stmmac_priv *priv,
 					PACKET_PTPQ, 0);
 		priv->rfs_entries_cnt[STMMAC_RFS_T_1588]--;
 		break;
+	case ETH_P_IP:
+		stmmac_rx_queue_routing(priv, priv->hw,
+					PACKET_UPQ, 0);
+		priv->rfs_entries_cnt[STMMAC_RFS_T_IP]--;
+		break;
 	default:
 		netdev_err(priv->dev, "EthType(0x%x) is not supported",
 			   entry->etype);
-- 
2.34.1

Re: [PATCH net-next 0/4] net: stmmac: new features

[Jacob Keller]

[-- Attachment #1.1: Type: text/plain, Size: 1159 bytes --]



On 8/28/2025 7:45 AM, Konrad Leszczynski wrote:
> This series adds four new patches which introduce features such as ARP
> Offload support, VLAN protocol detection and TC flower filter support.
> 
> Patchset has been created as a result of discussion at [1].
> 
> [1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/
> 
> v1 -> v2:
> - add missing SoB lines
> - place ifa_list under RCU protection
> 
> Karol Jurczenia (3):
>   net: stmmac: enable ARP Offload on mac_link_up()
>   net: stmmac: set TE/RE bits for ARP Offload when interface down
>   net: stmmac: add TC flower filter support for IP EtherType
> 
> Piotr Warpechowski (1):
>   net: stmmac: enhance VLAN protocol detection for GRO
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
>  .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++++++-
>  include/linux/stmmac.h                        |  1 +
>  4 files changed, 50 insertions(+), 6 deletions(-)
> 

The series looks good to me.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH net-next 0/4] net: stmmac: new features

[Joseph Steel]

On Fri, Aug 29, 2025 at 02:23:24PM -0700, Jacob Keller wrote:
> 
> 
> On 8/28/2025 7:45 AM, Konrad Leszczynski wrote:
> > This series adds four new patches which introduce features such as ARP
> > Offload support, VLAN protocol detection and TC flower filter support.
> > 
> > Patchset has been created as a result of discussion at [1].
> > 
> > [1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/
> > 
> > v1 -> v2:
> > - add missing SoB lines
> > - place ifa_list under RCU protection
> > 
> > Karol Jurczenia (3):
> >   net: stmmac: enable ARP Offload on mac_link_up()
> >   net: stmmac: set TE/RE bits for ARP Offload when interface down
> >   net: stmmac: add TC flower filter support for IP EtherType
> > 
> > Piotr Warpechowski (1):
> >   net: stmmac: enhance VLAN protocol detection for GRO
> > 
> >  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
> >  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
> >  .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++++++-
> >  include/linux/stmmac.h                        |  1 +
> >  4 files changed, 50 insertions(+), 6 deletions(-)
> > 
> 
> The series looks good to me.
> 
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Not a single comment? Really? Three Rb and three Sb tags from Intel
staff and nobody found even a tiny problem? Sigh...

Let's start with an easiest one. What about introducing an unused
platform flag for ARP-offload?

Next is more serious one. What about considering a case that
IP-address can be changed or removed while MAC link is being up?

Why does Intel want to have ARP requests being silently handled even
when a link is completely set down by the host, when PHY-link is
stopped and PHY is disconnected, after net_device::ndo_stop() is
called? 

Finally did anyone test out the functionality of the patches 1 and
2? What does arping show for instance for just three ARP requests?
Nothing strange?

So to speak at this stage I'd give NAK at least for the patches 1 and
2.

BTW I've been working with the driver for quite some time and AFAICS
Intel contributed if not half but at least quarter of it' mess.

Joseph

Re: [PATCH net-next 0/4] net: stmmac: new features

[Jacob Keller]

[-- Attachment #1.1: Type: text/plain, Size: 2304 bytes --]



On 8/29/2025 7:46 PM, Joseph Steel wrote:
> On Fri, Aug 29, 2025 at 02:23:24PM -0700, Jacob Keller wrote:
>>
>>
>> On 8/28/2025 7:45 AM, Konrad Leszczynski wrote:
>>> This series adds four new patches which introduce features such as ARP
>>> Offload support, VLAN protocol detection and TC flower filter support.
>>>
>>> Patchset has been created as a result of discussion at [1].
>>>
>>> [1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/
>>>
>>> v1 -> v2:
>>> - add missing SoB lines
>>> - place ifa_list under RCU protection
>>>
>>> Karol Jurczenia (3):
>>>   net: stmmac: enable ARP Offload on mac_link_up()
>>>   net: stmmac: set TE/RE bits for ARP Offload when interface down
>>>   net: stmmac: add TC flower filter support for IP EtherType
>>>
>>> Piotr Warpechowski (1):
>>>   net: stmmac: enhance VLAN protocol detection for GRO
>>>
>>>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
>>>  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
>>>  .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++++++-
>>>  include/linux/stmmac.h                        |  1 +
>>>  4 files changed, 50 insertions(+), 6 deletions(-)
>>>
>>
>> The series looks good to me.
>>
>> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> 
> Not a single comment? Really? Three Rb and three Sb tags from Intel
> staff and nobody found even a tiny problem? Sigh...
> 

Not everyone will find every issue. I'm certainly no expert in this
driver. This is why it is good to have many reviewers.
> Let's start with an easiest one. What about introducing an unused
> platform flag for ARP-offload?
> 
> Next is more serious one. What about considering a case that
> IP-address can be changed or removed while MAC link is being up?
> 
> Why does Intel want to have ARP requests being silently handled even
> when a link is completely set down by the host, when PHY-link is
> stopped and PHY is disconnected, after net_device::ndo_stop() is
> called? 
> 
> Finally did anyone test out the functionality of the patches 1 and
> 2? What does arping show for instance for just three ARP requests?
> Nothing strange?
> 
> So to speak at this stage I'd give NAK at least for the patches 1 and
> 2.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH net-next 0/4] net: stmmac: new features

[Andrew Lunn]

> >> The series looks good to me.
> >>
> >> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> > 
> > Not a single comment? Really? Three Rb and three Sb tags from Intel
> > staff and nobody found even a tiny problem? Sigh...
> > 
> 
> Not everyone will find every issue. I'm certainly no expert in this
> driver. This is why it is good to have many reviewers.

As a rule of thumb, Maintainers ignore multiple Reviewed-by when then
call come from the same company. At least if they don't actually point
out issues.

There is a nice quote from a bootlin/free-electrons developer. It is
something like: In order to get my patches merged faster, i review
other peoples patches, so freeing up Maintainer time to look at my
patches.

Jacob is a good example of that, he looks at patches from many
developers. Maybe more Intel people can help out reviewing patches,
particularly other stmmac patches, in order to get their own merged?

	Andrew

Re: [PATCH net-next 0/4] net: stmmac: new features

[Cezary Rojewski]

On 2025-08-30 4:46 AM, Joseph Steel wrote:
> On Fri, Aug 29, 2025 at 02:23:24PM -0700, Jacob Keller wrote:
>> On 8/28/2025 7:45 AM, Konrad Leszczynski wrote:
>>> This series adds four new patches which introduce features such as ARP
>>> Offload support, VLAN protocol detection and TC flower filter support.
>>>
>>> Patchset has been created as a result of discussion at [1].
>>>
>>> [1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/
>>>
>>> v1 -> v2:
>>> - add missing SoB lines
>>> - place ifa_list under RCU protection
>>>
>>> Karol Jurczenia (3):
>>>    net: stmmac: enable ARP Offload on mac_link_up()
>>>    net: stmmac: set TE/RE bits for ARP Offload when interface down
>>>    net: stmmac: add TC flower filter support for IP EtherType
>>>
>>> Piotr Warpechowski (1):
>>>    net: stmmac: enhance VLAN protocol detection for GRO
>>>
>>>   drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
>>>   .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
>>>   .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++++++-
>>>   include/linux/stmmac.h                        |  1 +
>>>   4 files changed, 50 insertions(+), 6 deletions(-)
>>>
>>
>> The series looks good to me.
>>
>> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> 
> Not a single comment? Really? Three Rb and three Sb tags from Intel
> staff and nobody found even a tiny problem? Sigh...

Hi Joseph,

Given how things look on the list (just v1, no comments), it's 
understandable to think that folks just appended their Reviewed-by and 
Signed-off-by tags without actually paying attention.

While I'm not part of the stmmac team directly - I do maintain the 
sound/soc/intel drivers - I did participate in shaping the patchset - 
titles, messages, division and such. What you see here has been 
rewritten a number of times before being sent.
  > Let's start with an easiest one. What about introducing an unused
> platform flag for ARP-offload?

That's a good point. No change in this patchset shall be tied to a 
specific platform that does not exist in the upstream kernel and thus 
simply has no users. The team will revisit for v2 and drop the patch if 
true.

> Next is more serious one. What about considering a case that
> IP-address can be changed or removed while MAC link is being up?
> 
> Why does Intel want to have ARP requests being silently handled even
> when a link is completely set down by the host, when PHY-link is
> stopped and PHY is disconnected, after net_device::ndo_stop() is
> called?
> 
> Finally did anyone test out the functionality of the patches 1 and
> 2? What does arping show for instance for just three ARP requests?
> Nothing strange?

I'll let Sebastian or Konrad comment on that as they are experienced 
with the IP.
> So to speak at this stage I'd give NAK at least for the patches 1 and
> 2.
> 
> BTW I've been working with the driver for quite some time and AFAICS
> Intel contributed if not half but at least quarter of it' mess.

Not sure whether this bit helps anyone. The new faces are here to help, 
not to repeat the mistakes of the past.

Kind regards,
Czarek