* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Arnd Bergmann @ 2018-09-24 21:17 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-pci,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Platform Driver,
sparclinux, driverdevel, linux-scsi,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, linux-rdma,
qat-linux-ral2JQCrhuEAvxtiuMwx3w,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
open list:HID CORE LAYER, Darren Hart, Linux Media Mailing List,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, dri-devel, ceph-devel,
gregkh, USB list, linux-wireless, Linux Kernel Mailing List <l
In-Reply-To: <20180924203505.GC6008-uk2M96/98Pc@public.gmane.org>
On Mon, Sep 24, 2018 at 10:35 PM Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
> On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote:
> > On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
> > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> > We already do this inside of some subsystems, notably drivers/media/,
> > and it simplifies the implementation of the ioctl handler function
> > significantly. We obviously cannot do this in general, both because of
> > traditional drivers that have 16-bit command codes (drivers/tty and others)
> > and also because of drivers that by accident defined the commands
> > incorrectly and use the wrong type or the wrong direction in the
> > definition.
>
> That could work well, but the first idea could be done globally and
> mechanically, while this would require very careful per-driver
> investigation.
>
> Particularly if the core code has worse performance.. ie due to
> kmalloc calls or something.
>
> I think it would make more sense to start by having the core do the
> case to __user and then add another entry point to have the core do
> the copy_from_user, and so on.
Having six separate callback pointers to implement a single
system call seems a bit excessive though.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: mediatek: Add binding document for MediaTek GMAC
From: Rob Herring @ 2018-09-24 21:07 UTC (permalink / raw)
To: Biao Huang
Cc: mark.rutland, devicetree, nelson.chang, netdev, sean.wang,
liguo.zhang, linux-kernel, matthias.bgg, linux-mediatek,
honghui.zhang, yt.shen, davem, linux-arm-kernel
In-Reply-To: <1537165763-13112-2-git-send-email-biao.huang@mediatek.com>
On Mon, Sep 17, 2018 at 02:29:22PM +0800, Biao Huang wrote:
> The commit adds the device tree binding documentation for the MediaTek
> GMAC found on Mediatek MT2712.
>
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> ---
> .../devicetree/bindings/net/mediatek-gmac.txt | 45 ++++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/mediatek-gmac.txt
>
> diff --git a/Documentation/devicetree/bindings/net/mediatek-gmac.txt b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
> new file mode 100644
> index 0000000..14876ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
> @@ -0,0 +1,45 @@
> +MediaTek Gigabit Ethernet controller
> +=========================================
> +
> +The gigabit ethernet controller can be found on MediaTek SoCs.
> +
> +* Ethernet controller node
> +
> +Required properties:
> +- compatible: Should be
> + "mediatek,mt2712-eth": for MT2712 SoC
> +- reg: Address and length of the register set for the device
> +- interrupts: Should contain the MAC interrupts
> +- interrupt-names: the name of interrupt in the interrupts property. These are
> + "macirq": For MT2712 SoC
Not really necessary to have interrupt-names when there is only 1 irq.
> +- clocks: the clock used by the controller
> +- clock-names: the names of the clock listed in the clocks property. These are
> + "axi", "apb", "mac_ext", "ptp", "ptp_parent", "ptp_top": For MT2712 SoC
> +- mac-address: See ethernet.txt in the same directory
> +- power-domains: phandle to the power domain that the ethernet is part of
> +- phy-mode: See ethernet.txt file in the same directory.
> +- reset-gpio: gpio number for phy reset.
reset-gpios
> +
> +Example:
> +
> +eth: eth@1101c000 {
> + compatible = "mediatek,mt2712-eth";
> + reg = <0 0x1101c000 0 0x1200>;
> + interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "macirq";
> + phy-mode ="rgmii";
> + mac-address = [00 55 7b b5 7d f7];
> + clock-names = "axi",
> + "apb",
> + "mac_ext",
> + "ptp",
> + "ptp_parent",
> + "ptp_top";
> + clocks = <&pericfg CLK_PERI_GMAC>,
> + <&pericfg CLK_PERI_GMAC_PCLK>,
> + <&topckgen CLK_TOP_ETHER_125M_SEL>,
> + <&topckgen CLK_TOP_ETHER_50M_SEL>,
> + <&topckgen CLK_TOP_APLL1_D3>,
> + <&topckgen CLK_TOP_APLL1>;
> + reset-gpio = <&pio 87 GPIO_ACTIVE_HIGH>;
> + };
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] qed: Fix mask parameter in qed_vf_prep_tunn_req_tlv
From: Nathan Chancellor @ 2018-09-24 21:05 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S. Miller
Cc: netdev, linux-kernel, Nathan Chancellor
Clang complains when one enumerated type is implicitly converted to
another.
drivers/net/ethernet/qlogic/qed/qed_vf.c:686:6: warning: implicit
conversion from enumeration type 'enum qed_tunn_mode' to different
enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
QED_MODE_L2GENEVE_TUNN,
^~~~~~~~~~~~~~~~~~~~~~
Update mask's parameter to expect qed_tunn_mode, which is what was
intended.
Link: https://github.com/ClangBuiltLinux/linux/issues/125
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 3d4269659820..fcd8da08274f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -572,7 +572,7 @@ int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn)
static void
__qed_vf_prep_tunn_req_tlv(struct vfpf_update_tunn_param_tlv *p_req,
struct qed_tunn_update_type *p_src,
- enum qed_tunn_clss mask, u8 *p_cls)
+ enum qed_tunn_mode mask, u8 *p_cls)
{
if (p_src->b_update_mode) {
p_req->tun_mode_update_mask |= BIT(mask);
@@ -587,7 +587,7 @@ __qed_vf_prep_tunn_req_tlv(struct vfpf_update_tunn_param_tlv *p_req,
static void
qed_vf_prep_tunn_req_tlv(struct vfpf_update_tunn_param_tlv *p_req,
struct qed_tunn_update_type *p_src,
- enum qed_tunn_clss mask,
+ enum qed_tunn_mode mask,
u8 *p_cls, struct qed_tunn_update_udp_port *p_port,
u8 *p_update_port, u16 *p_udp_port)
{
--
2.19.0
^ permalink raw reply related
* [PATCH net 7/7] smsc95xx: Check for Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: e0e474a83c18 ("smsc95xx: add wol magic packet support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/smsc95xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 06b4d290784d..262e7a3c23cb 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -774,6 +774,9 @@ static int smsc95xx_ethtool_set_wol(struct net_device *net,
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
int ret;
+ if (wolinfo->wolopts & ~SUPPORTED_WAKE)
+ return -EINVAL;
+
pdata->wolopts = wolinfo->wolopts & SUPPORTED_WAKE;
ret = device_set_wakeup_enable(&dev->udev->dev, pdata->wolopts);
--
2.17.1
^ permalink raw reply related
* [PATCH net 6/7] smsc75xx: Check for Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: 6c636503260d ("smsc75xx: add wol magic packet support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/smsc75xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 05553d252446..e5a4cbb366dc 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -731,6 +731,9 @@ static int smsc75xx_ethtool_set_wol(struct net_device *net,
struct smsc75xx_priv *pdata = (struct smsc75xx_priv *)(dev->data[0]);
int ret;
+ if (wolinfo->wolopts & ~SUPPORTED_WAKE)
+ return -EINVAL;
+
pdata->wolopts = wolinfo->wolopts & SUPPORTED_WAKE;
ret = device_set_wakeup_enable(&dev->udev->dev, pdata->wolopts);
--
2.17.1
^ permalink raw reply related
* [PATCH net 5/7] r8152: Check for supported Wake-on-LAN Modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: 21ff2e8976b1 ("r8152: support WOL")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/r8152.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2cd71bdb6484..f1b5201cc320 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4506,6 +4506,9 @@ static int rtl8152_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
if (!rtl_can_wakeup(tp))
return -EOPNOTSUPP;
+ if (wol->wolopts & ~WAKE_ANY)
+ return -EINVAL;
+
ret = usb_autopm_get_interface(tp->intf);
if (ret < 0)
goto out_set_wol;
--
2.17.1
^ permalink raw reply related
* [PATCH net 4/7] sr9800: Check for supported Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/sr9800.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
index 9277a0f228df..35f39f23d881 100644
--- a/drivers/net/usb/sr9800.c
+++ b/drivers/net/usb/sr9800.c
@@ -421,6 +421,9 @@ sr_set_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
+ if (wolinfo->wolopts & ~(WAKE_PHY | WAKE_MAGIC))
+ return -EINVAL;
+
if (wolinfo->wolopts & WAKE_PHY)
opt |= SR_MONITOR_LINK;
if (wolinfo->wolopts & WAKE_MAGIC)
--
2.17.1
^ permalink raw reply related
* [PATCH net 3/7] lan78xx: Check for supported Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver supports a fair amount of Wake-on-LAN modes, but is not
checking that the user specified one that is supported.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/lan78xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a9991c5f4736..e0a588d1b8e6 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1415,6 +1415,9 @@ static int lan78xx_set_wol(struct net_device *netdev,
if (wol->wolopts & WAKE_ARP)
pdata->wol |= WAKE_ARP;
+ if (pdata->wol == 0)
+ return -EINVAL;
+
device_set_wakeup_enable(&dev->udev->dev, (bool)wol->wolopts);
phy_ethtool_set_wol(netdev->phydev, wol);
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/7] ax88179_178a: Check for supported Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/ax88179_178a.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 9e8ad372f419..2207f7a7d1ff 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -566,6 +566,9 @@ ax88179_set_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
+ if (wolinfo->wolopts & ~(WAKE_PHY | WAKE_MAGIC))
+ return -EINVAL;
+
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_MODE_RWLC;
if (wolinfo->wolopts & WAKE_MAGIC)
--
2.17.1
^ permalink raw reply related
* [PATCH net 1/7] asix: Check for supported Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180924205420.31309-1-f.fainelli@gmail.com>
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/asix_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index e95dd12edec4..023b8d0bf175 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -607,6 +607,9 @@ int asix_set_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
+ if (wolinfo->wolopts & ~(WAKE_PHY | WAKE_MAGIC))
+ return -EINVAL;
+
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_LINK;
if (wolinfo->wolopts & WAKE_MAGIC)
--
2.17.1
^ permalink raw reply related
* [PATCH net 0/7] net: usb: Check for Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-24 20:54 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
Hi all,
Most of our USB Ethernet drivers don't seem to be checking properly
whether the user is supplying a correct Wake-on-LAN mode to enter, so
the experience as an user could be confusing, since it would generally
lead to either no wake-up, or the device not being marked for wake-up.
Please review!
Florian Fainelli (7):
asix: Check for supported Wake-on-LAN modes
ax88179_178a: Check for supported Wake-on-LAN modes
lan78xx: Check for supported Wake-on-LAN modes
sr9800: Check for supported Wake-on-LAN modes
r8152: Check for supported Wake-on-LAN Modes
smsc75xx: Check for Wake-on-LAN modes
smsc95xx: Check for Wake-on-LAN modes
drivers/net/usb/asix_common.c | 3 +++
drivers/net/usb/ax88179_178a.c | 3 +++
drivers/net/usb/lan78xx.c | 3 +++
drivers/net/usb/r8152.c | 3 +++
drivers/net/usb/smsc75xx.c | 3 +++
drivers/net/usb/smsc95xx.c | 3 +++
drivers/net/usb/sr9800.c | 3 +++
7 files changed, 21 insertions(+)
--
2.17.1
^ permalink raw reply
* [PATCH] qed: Avoid implicit enum conversion in qed_set_tunn_cls_info
From: Nathan Chancellor @ 2018-09-24 20:53 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S. Miller
Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:163:25: warning:
implicit conversion from enumeration type 'enum tunnel_clss' to
different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
p_tun->vxlan.tun_cls = type;
~ ^~~~
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:165:26: warning:
implicit conversion from enumeration type 'enum tunnel_clss' to
different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
p_tun->l2_gre.tun_cls = type;
~ ^~~~
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:167:26: warning:
implicit conversion from enumeration type 'enum tunnel_clss' to
different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
p_tun->ip_gre.tun_cls = type;
~ ^~~~
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:169:29: warning:
implicit conversion from enumeration type 'enum tunnel_clss' to
different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
p_tun->l2_geneve.tun_cls = type;
~ ^~~~
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:171:29: warning:
implicit conversion from enumeration type 'enum tunnel_clss' to
different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
p_tun->ip_geneve.tun_cls = type;
~ ^~~~
5 warnings generated.
Avoid this by changing type to an int.
Link: https://github.com/ClangBuiltLinux/linux/issues/125
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
index 8de644b4721e..77b6248ad3b9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
@@ -154,7 +154,7 @@ qed_set_pf_update_tunn_mode(struct qed_tunnel_info *p_tun,
static void qed_set_tunn_cls_info(struct qed_tunnel_info *p_tun,
struct qed_tunnel_info *p_src)
{
- enum tunnel_clss type;
+ int type;
p_tun->b_update_rx_cls = p_src->b_update_rx_cls;
p_tun->b_update_tx_cls = p_src->b_update_tx_cls;
--
2.19.0
^ permalink raw reply related
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Jason Gunthorpe @ 2018-09-24 20:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Darren Hart, Al Viro, Linux FS-devel Mailing List, gregkh,
David Miller, driverdevel, Linux Kernel Mailing List, qat-linux,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
Linux Media Mailing List, dri-devel, linaro-mm-sig, amd-gfx,
open list:HID CORE LAYER, linux-iio, linux-rdma, linux-nvdimm,
linux-nvme, linux-pci
In-Reply-To: <CAK8P3a17GY89in7PeLk1F2T-0Xq=sCrwwntM+Y4BCpXheUC+qQ@mail.gmail.com>
On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> > > >
> > > > > Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
> > > > >
> > > > > As for a longer term solution, would it be possible to init fops in such
> > > > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> > > > > so we don't have to duplicate this boilerplate for every ioctl fops
> > > > > structure?
> > > >
> > > > Bad idea, that... Because several years down the road somebody will add
> > > > an ioctl that takes an unsigned int for argument. Without so much as looking
> > > > at your magical mystery macro being used to initialize file_operations.
> > >
> > > Fair, being explicit in the declaration as it is currently may be
> > > preferable then.
> >
> > It would be much cleaner and safer if you could arrange things to add
> > something like this to struct file_operations:
> >
> > long (*ptr_ioctl) (struct file *, unsigned int, void __user *);
> >
> > Where the core code automatically converts the unsigned long to the
> > void __user * as appropriate.
> >
> > Then it just works right always and the compiler will help address
> > Al's concern down the road.
>
> I think if we wanted to do this with a new file operation, the best
> way would be to do the copy_from_user()/copy_to_user() in the caller
> as well.
>
> We already do this inside of some subsystems, notably drivers/media/,
> and it simplifies the implementation of the ioctl handler function
> significantly. We obviously cannot do this in general, both because of
> traditional drivers that have 16-bit command codes (drivers/tty and others)
> and also because of drivers that by accident defined the commands
> incorrectly and use the wrong type or the wrong direction in the
> definition.
That could work well, but the first idea could be done globally and
mechanically, while this would require very careful per-driver
investigation.
Particularly if the core code has worse performance.. ie due to
kmalloc calls or something.
I think it would make more sense to start by having the core do the
case to __user and then add another entry point to have the core do
the copy_from_user, and so on.
Jason
^ permalink raw reply
* Re: vlan missing with AF_PACKET and auxdata
From: Michael Walle @ 2018-09-24 14:25 UTC (permalink / raw)
To: Jan Grashöfer
Cc: netdev, David S. Miller, Eric Dumazet, Steinar H. Gunderson,
heiko.thiery
In-Reply-To: <29cdf22a-eceb-eab9-979d-049e261a6064@gmail.com>
Am 2018-09-24 14:22, schrieb Jan Grashöfer:
> Hi Michael,
>
> On 24/09/2018 14:01, Michael Walle wrote:
>> I'm using the AF_PACKET socket with setsockopt(PACKET_AUXDATA) to get
>> the incoming VLAN tag. Correct me if I'm wrong, but as far as I see
>> the first VLAN tag is always stripped - either in hardware or in
>> net/core/dev.c in __netif_receive_skb_core() - and stored in
>> skb->vlan_tci. Therefore, it won't be in the packet data anymore.
>
> although the documentation says "SOCK_RAW packets are passed to and
> from the device driver without any changes in the packet data." [1]
> that's correct and was discussed here:
> https://www.spinics.net/lists/netdev/msg440313.html
>
> Result of the discussion: Won't fix, too complicated.
Hi Jan,
thanks for the pointer. I'm fine with this decision, because the VLAN
tag should be available through metadata. And this was my original
question, because the metadata is only available in case of proto ==
ETH_P_ALL, but not for proto != ETH_P_ALL because of the commit in
question.
-michael
^ permalink raw reply
* Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Janusz Krzysztofik @ 2018-09-24 14:18 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <20180924113859eucas1p160322f5844c771bc9c680d35de4877a3~XUxM0smXV0334103341eucas1p1s@eucas1p1.samsung.com>
Hi Marek,
2018-09-24 13:38 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> Hi Janusz,
>
> On 2018-09-24 13:08, Janusz Krzysztofik wrote:
>> 2018-09-24 11:43 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
>>> On 2018-09-24 01:53, Janusz Krzysztofik wrote:
>>>> While investigating possible reasons of GPIO fast bitmap processing
>>>> related boot hang on Samsung Snow Chromebook, reported by Marek
>>>> Szyprowski (thanks!), I've discovered one coding bug, addressed by
>>>> PATCH 1/2 of this series, and one potential regression introduced at
>>>> design level of the solution, hopefully fixed by PATCH 2/2. See
>>>> commit messages for details.
>>>>
>>>> Janusz Krzysztofik (2):
>>>> gpiolib: Fix missing updates of bitmap index
>>>> gpiolib: Fix array members of same chip processed separately
>>>>
>>>> The fixes should resolve the boot hang observed by Marek, however the
>>>> second change excludes that particular case from fast bitmap processing
>>>> and restores the old behaviour.
>>> I confirm, that the above 2 patches fixes boot issue on Samsung Snow
>>> Chromebook with next-20180920.
>>>
>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>>> Hence, it is possible still another
>>>> issue which have had an influence on that boot hang exists in the code.
>>>> In order to fully verify the fix, it would have to be tested on a
>>>> platform where an array of GPIO descriptors is used which starts from
>>>> at least two consecutive pins of one GPIO chip in hardware order,
>>>> starting ftom 0, followed by one or more pins belonging to other
>>>> chip(s).
>>>>
>>>> In order to verify if separate calls to .set() chip callback for each
>>>> pin instead of one call to .set_multiple() is actually the reason of
>>>> boot hang on Samsung Snow Chromebook, the affected driver -
>>>> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
>>>> modified for testing purposes so it calls gpiod_set_value() for each
>>>> pin instead of gpiod_set_array_value() for all of them. If that would
>>>> also result in boot hang, we could be sure the issue was really the
>>>> one addressed by the second fix. Marek, could you please try to
>>>> perform such test?
>>> Yes, I've just tested next-20180920 only with the first patch from this
>>> patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c.
>>> It boots fine, so indeed the issue is in handling of arrays of gpios.
>>>
>>> Just to be sure I did it right, this is my change to the mentioned file:
>> Yeah, that's what I had on mind. However, I'd be more lucky if it didn't
>> work
>> for you. Setting the pins sequentially, not simultaneously as before,
>> was
>> exactly what I hoped was the reason of the hang.
>>
>>> diff --git a/drivers/mmc/core/pwrseq_simple.c
>>> b/drivers/mmc/core/pwrseq_simple.c
>>> index 7f882a2bb872..9397dc1f2e38 100644
>>> --- a/drivers/mmc/core/pwrseq_simple.c
>>> +++ b/drivers/mmc/core/pwrseq_simple.c
>>> @@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
>>> mmc_pwrseq_simple *pwrseq,
>>> int value)
>>> {
>>> struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
>>> + int i;
>>>
>>> - if (!IS_ERR(reset_gpios)) {
>>> - DECLARE_BITMAP(values, BITS_PER_TYPE(value));
>>> - int nvalues = reset_gpios->ndescs;
>>> -
>>> - values[0] = value;
>>> -
>>> - gpiod_set_array_value_cansleep(nvalues,
>>> reset_gpios->desc,
>>> - reset_gpios->info,
>>> values);
>>> - }
>>> + if (!IS_ERR(reset_gpios))
>>> + for (i = 0; i < reset_gpios->ndescs; i++)
>> The only difference from the behaviour when the hang was occurring is now
>> the order the pins are manipulated. Maybe that matters?
>> Could you please retry the same with the order of pins reversed, either
>> in
>> the .dts file or here inside this for loop?
>
> I've switched the order of pins in dts and next-20180920 + first patch +
> above
> change also boots fine.
Thanks for performing those tests.
Since we are not able to reproduce the issue by any means other than
using the original code introduced by fast bitmap processing changes,
regardless of the first fix being applied or not, and we are only able to
resolve the hangup by excluding affected use case from the fast path,
we have to assume one or more bugs which affect mixed arrays, i.e.,
those which apply for fast bitmap processing only in part, may still exist
in the code introduced by the fast bitmap processing series. I hope we
are able to resolve it soon, before the changes reach mainline.
Thanks,
Janusz
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Arnd Bergmann @ 2018-09-24 20:18 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-pci,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Platform Driver,
sparclinux, driverdevel, linux-scsi,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, linux-rdma,
qat-linux-ral2JQCrhuEAvxtiuMwx3w,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
open list:HID CORE LAYER, Darren Hart, Linux Media Mailing List,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, dri-devel, ceph-devel,
gregkh, USB list, linux-wireless, Linux Kernel Mailing List <l
In-Reply-To: <20180918175952.GJ11367-uk2M96/98Pc@public.gmane.org>
On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
>
> On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> > >
> > > > Acked-by: Darren Hart (VMware) <dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > > >
> > > > As for a longer term solution, would it be possible to init fops in such
> > > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> > > > so we don't have to duplicate this boilerplate for every ioctl fops
> > > > structure?
> > >
> > > Bad idea, that... Because several years down the road somebody will add
> > > an ioctl that takes an unsigned int for argument. Without so much as looking
> > > at your magical mystery macro being used to initialize file_operations.
> >
> > Fair, being explicit in the declaration as it is currently may be
> > preferable then.
>
> It would be much cleaner and safer if you could arrange things to add
> something like this to struct file_operations:
>
> long (*ptr_ioctl) (struct file *, unsigned int, void __user *);
>
> Where the core code automatically converts the unsigned long to the
> void __user * as appropriate.
>
> Then it just works right always and the compiler will help address
> Al's concern down the road.
I think if we wanted to do this with a new file operation, the best
way would be to do the copy_from_user()/copy_to_user() in the caller
as well.
We already do this inside of some subsystems, notably drivers/media/,
and it simplifies the implementation of the ioctl handler function
significantly. We obviously cannot do this in general, both because of
traditional drivers that have 16-bit command codes (drivers/tty and others)
and also because of drivers that by accident defined the commands
incorrectly and use the wrong type or the wrong direction in the
definition.
Arnd
^ permalink raw reply
* [PATCH net] ip_tunnel: be careful when accessing the inner header
From: Paolo Abeni @ 2018-09-24 13:48 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Cong Wang, Pravin B Shelar
Cong noted that we need the same checks introduced by commit 76c0ddd8c3a6
("ip6_tunnel: be careful when accessing the inner header")
even for ipv4 tunnels.
Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
Note: the bug is probably present even before the commit mentioned in
the fixes tag, but porting this change on older kernel is likely worthless
---
net/ipv4/ip_tunnel.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index c4f5602308ed..284a22154b4e 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -627,6 +627,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
const struct iphdr *tnl_params, u8 protocol)
{
struct ip_tunnel *tunnel = netdev_priv(dev);
+ unsigned int inner_nhdr_len = 0;
const struct iphdr *inner_iph;
struct flowi4 fl4;
u8 tos, ttl;
@@ -636,6 +637,14 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
__be32 dst;
bool connected;
+ /* ensure we can access the inner net header, for several users below */
+ if (skb->protocol == htons(ETH_P_IP))
+ inner_nhdr_len = sizeof(struct iphdr);
+ else if (skb->protocol == htons(ETH_P_IPV6))
+ inner_nhdr_len = sizeof(struct ipv6hdr);
+ if (unlikely(!pskb_may_pull(skb, inner_nhdr_len)))
+ goto tx_error;
+
inner_iph = (const struct iphdr *)skb_inner_network_header(skb);
connected = (tunnel->parms.iph.daddr != 0);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: qca_spi: Introduce write register verification
From: David Miller @ 2018-09-24 19:26 UTC (permalink / raw)
To: stefan.wahren; +Cc: netdev, linux-kernel, michael.heimpold
In-Reply-To: <1537788010-6766-1-git-send-email-stefan.wahren@i2se.com>
From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Mon, 24 Sep 2018 13:20:10 +0200
> The SPI protocol for the QCA7000 doesn't have any fault detection.
> In order to increase the drivers reliability in noisy environments,
> we could implement a write verification inspired by the enc28j60.
> This should avoid situations were the driver wrongly assumes the
> receive interrupt is enabled and miss all incoming packets.
>
> This function is disabled per default and can be controlled via module
> parameter wr_verify.
>
> Signed-off-by: Michael Heimpold <michael.heimpold@i2se.com>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
From: Florian Fainelli @ 2018-09-24 19:17 UTC (permalink / raw)
To: Corentin Labbe, Gilles.Muller, Julia.Lawall, agust, airlied,
alexandre.torgue, alistair, benh, carlo, davem, galak, joabreu,
khilman, maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <1537815856-31728-8-git-send-email-clabbe@baylibre.com>
On 09/24/2018 12:04 PM, Corentin Labbe wrote:
> This patch convert meson stmmac glue driver to use all xxxsetbits32 functions.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +++++++++-------------
> 1 file changed, 22 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> index c5979569fd60..abcf65588576 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> @@ -23,6 +23,7 @@
> #include <linux/mfd/syscon.h>
> #include <linux/platform_device.h>
> #include <linux/stmmac.h>
> +#include <linux/setbits.h>
>
> #include "stmmac_platform.h"
>
> @@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
> struct clk_gate rgmii_tx_en;
> };
>
> -static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
> - u32 mask, u32 value)
> -{
> - u32 data;
> -
> - data = readl(dwmac->regs + reg);
> - data &= ~mask;
> - data |= (value & mask);
> -
> - writel(data, dwmac->regs + reg);
> -}
Why not make mseon8b_dwmac_mask_bits() a wrapper around
clrsetbits_le32() whose purpose is only to dereference dwmac->regs and
pass it to clrsetbits_le32()? That would be far less changes to review
and audit for correctness, same goes with every other patch in this
series touching the meson drivers.
--
Florian
^ permalink raw reply
* Re: [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
From: Neil Armstrong @ 2018-09-24 19:08 UTC (permalink / raw)
To: Corentin Labbe, Gilles.Muller, Julia.Lawall, agust, airlied,
alexandre.torgue, alistair, benh, carlo, davem, galak, joabreu,
khilman, maxime.ripard, michal.lkml, mpe, mporter, nicolas.palix,
oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, dri-devel, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev
In-Reply-To: <1537815856-31728-8-git-send-email-clabbe@baylibre.com>
On 24/09/2018 21:04, Corentin Labbe wrote:
> This patch convert meson stmmac glue driver to use all xxxsetbits32 functions.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +++++++++-------------
> 1 file changed, 22 insertions(+), 34 deletions(-)
>
[...]
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
From: Corentin Labbe @ 2018-09-24 19:04 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, dri-devel, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev, Corentin Labbe
In-Reply-To: <1537815856-31728-1-git-send-email-clabbe@baylibre.com>
This patch convert meson stmmac glue driver to use all xxxsetbits32 functions.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +++++++++-------------
1 file changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index c5979569fd60..abcf65588576 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -23,6 +23,7 @@
#include <linux/mfd/syscon.h>
#include <linux/platform_device.h>
#include <linux/stmmac.h>
+#include <linux/setbits.h>
#include "stmmac_platform.h"
@@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
struct clk_gate rgmii_tx_en;
};
-static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
- u32 mask, u32 value)
-{
- u32 data;
-
- data = readl(dwmac->regs + reg);
- data &= ~mask;
- data |= (value & mask);
-
- writel(data, dwmac->regs + reg);
-}
-
static struct clk *meson8b_dwmac_register_clk(struct meson8b_dwmac *dwmac,
const char *name_suffix,
const char **parent_names,
@@ -192,14 +181,13 @@ static int meson8b_set_phy_mode(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE,
- PRG_ETH0_RGMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE,
+ PRG_ETH0_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE, 0);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE,
+ 0);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -218,15 +206,15 @@ static int meson_axg_set_phy_mode(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RGMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RMII_MODE);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -255,11 +243,11 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* only relevant for RMII mode -> disable in RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK, 0);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK, 0);
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_TXDLY_MASK,
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
/* Configure the 125MHz RGMII TX clock, the IP block changes
* the output automatically (= without us having to configure
@@ -287,13 +275,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RMII:
/* invert internal clk_rmii_i to generate 25/2.5 tx_rx_clk */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK,
- PRG_ETH0_INVERTED_RMII_CLK);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK,
+ PRG_ETH0_INVERTED_RMII_CLK);
/* TX clock delay cannot be configured in RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- 0);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_TXDLY_MASK,
+ 0);
break;
@@ -304,8 +292,8 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
}
/* enable TX_CLK and PHY_REF_CLK generator */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TX_AND_PHY_REF_CLK,
- PRG_ETH0_TX_AND_PHY_REF_CLK);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_TX_AND_PHY_REF_CLK,
+ PRG_ETH0_TX_AND_PHY_REF_CLK);
return 0;
}
--
2.16.4
^ permalink raw reply related
* [PATCH v2 5/7] net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits32
From: Corentin Labbe @ 2018-09-24 19:04 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, dri-devel, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev, Corentin Labbe
In-Reply-To: <1537815856-31728-1-git-send-email-clabbe@baylibre.com>
This patch convert dwmac-sun8i driver to use all xxxsetbits32 functions.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 ++++++-----------------
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index f9a61f90cfbc..74067a59af50 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -28,6 +28,7 @@
#include <linux/regulator/consumer.h>
#include <linux/regmap.h>
#include <linux/stmmac.h>
+#include <linux/setbits.h>
#include "stmmac.h"
#include "stmmac_platform.h"
@@ -342,50 +343,30 @@ static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits_le32(ioaddr + EMAC_TX_CTL1,
+ EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits_le32(ioaddr + EMAC_TX_CTL1,
+ EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v &= ~EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ clrbits_le32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v |= EMAC_RX_DMA_START;
- v |= EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ setbits_le32(ioaddr + EMAC_RX_CTL1,
+ EMAC_RX_DMA_START | EMAC_RX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v &= ~EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ clrbits_le32(ioaddr + EMAC_RX_CTL1, EMAC_RX_DMA_EN);
}
static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
@@ -578,7 +559,6 @@ static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
unsigned int reg_n)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
if (!addr) {
writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
@@ -588,9 +568,8 @@ static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
EMAC_MACADDR_LO(reg_n));
if (reg_n > 0) {
- v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
- v |= MAC_ADDR_TYPE_DST;
- writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ setbits_le32(ioaddr + EMAC_MACADDR_HI(reg_n),
+ MAC_ADDR_TYPE_DST);
}
}
@@ -608,11 +587,8 @@ static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
- v |= EMAC_RX_DO_CRC;
- writel(v, ioaddr + EMAC_RX_CTL0);
+ setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_DO_CRC);
return 1;
}
@@ -662,21 +638,15 @@ static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
unsigned int pause_time, u32 tx_cnt)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
if (fc == FLOW_AUTO)
- v |= EMAC_RX_FLOW_CTL_EN;
+ setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
else
- v &= ~EMAC_RX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_RX_CTL0);
-
- v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ clrbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
if (fc == FLOW_AUTO)
- v |= EMAC_TX_FLOW_CTL_EN;
+ setbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
else
- v &= ~EMAC_TX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+ clrbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
}
static int sun8i_dwmac_reset(struct stmmac_priv *priv)
--
2.16.4
^ permalink raw reply related
* [PATCH v2 2/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: Corentin Labbe @ 2018-09-24 19:04 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, dri-devel, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev, Corentin Labbe
In-Reply-To: <1537815856-31728-1-git-send-email-clabbe@baylibre.com>
This patch adds setbits32/clrbits32/clrsetbits32 and
setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
include/linux/setbits.h | 88 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 include/linux/setbits.h
diff --git a/include/linux/setbits.h b/include/linux/setbits.h
new file mode 100644
index 000000000000..6e7e257134ae
--- /dev/null
+++ b/include/linux/setbits.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_SETBITS_H
+#define __LINUX_SETBITS_H
+
+#include <linux/io.h>
+
+#define __setbits(readfunction, writefunction, addr, set) \
+ writefunction((readfunction(addr) | (set)), addr)
+#define __clrbits(readfunction, writefunction, addr, mask) \
+ writefunction((readfunction(addr) & ~(mask)), addr)
+#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
+ writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
+#define __setclrbits(readfunction, writefunction, addr, mask, set) \
+ writefunction(((readfunction(addr) | (set)) & ~(mask)), addr)
+
+#ifndef setbits_le32
+#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
+#endif
+#ifndef setbits_le32_relaxed
+#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
+ addr, set)
+#endif
+
+#ifndef clrbits_le32
+#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
+#endif
+#ifndef clrbits_le32_relaxed
+#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
+ addr, mask)
+#endif
+
+#ifndef clrsetbits_le32
+#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
+#endif
+#ifndef clrsetbits_le32_relaxed
+#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
+ writel_relaxed, \
+ addr, mask, set)
+#endif
+
+#ifndef setclrbits_le32
+#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
+#endif
+#ifndef setclrbits_le32_relaxed
+#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
+ writel_relaxed, \
+ addr, mask, set)
+#endif
+
+/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
+#if defined(writeq) && defined(readq)
+#ifndef setbits_le64
+#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set)
+#endif
+#ifndef setbits_le64_relaxed
+#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \
+ addr, set)
+#endif
+
+#ifndef clrbits_le64
+#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask)
+#endif
+#ifndef clrbits_le64_relaxed
+#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \
+ addr, mask)
+#endif
+
+#ifndef clrsetbits_le64
+#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set)
+#endif
+#ifndef clrsetbits_le64_relaxed
+#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
+ writeq_relaxed, \
+ addr, mask, set)
+#endif
+
+#ifndef setclrbits_le64
+#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set)
+#endif
+#ifndef setclrbits_le64_relaxed
+#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
+ writeq_relaxed, \
+ addr, mask, set)
+#endif
+
+#endif /* writeq/readq */
+
+#endif /* __LINUX_SETBITS_H */
--
2.16.4
^ permalink raw reply related
* [PATCH v2 0/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64
From: Corentin Labbe @ 2018-09-24 19:04 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, dri-devel, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev, Corentin Labbe
Hello
This patchset adds a new set of functions which are open-coded in lot of
place.
Basicly the pattern is always the same, "read, modify a bit, write"
some driver and the powerpc arch already have thoses pattern them as functions. (like ahci_sunxi.c or dwmac-meson8b)
The first patch rename some powerpc funtions for being consistent with
the new name convention.
The second patch adds the header with all setbits functions.
The third patch is a try to implement a coccinelle semantic patch to
find all place where xxxbits function could be used.
It should not be merged since it is un-finalized.
For the moment, the "add setbits.h header" is not working and need a future
coccinelle version.
The four last patch are example of some drivers convertion.
Thoses patchs give an example of the reduction of code won by using xxxbits32.
I would like to thanks Julia Lawall for her help on the coccinelle
patch.
Regards
Changes since v1:
- renamed LE functions to _leXX
- updated coccinnelle patch with JLawall's comments
Corentin Labbe (7):
powerpc: rename setbits32/clrbits32 to setbits32_be/clrbits32_be
include: add
setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in
linux/setbits.h
coccinelle: add xxxsetbitsXX converting spatch
ata: ahci_sunxi: use xxxsetbits32 functions
net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits32
drm: meson: use xxxsetbits32
net: stmmac: dwmac-meson8b: use xxxsetbits32
arch/powerpc/include/asm/fsl_lbc.h | 2 +-
arch/powerpc/include/asm/io.h | 5 +-
arch/powerpc/platforms/44x/canyonlands.c | 4 +-
arch/powerpc/platforms/4xx/gpio.c | 28 +-
arch/powerpc/platforms/512x/pdm360ng.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 10 +-
arch/powerpc/platforms/82xx/ep8248e.c | 2 +-
arch/powerpc/platforms/82xx/km82xx.c | 6 +-
arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 +-
arch/powerpc/platforms/82xx/pq2.c | 2 +-
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 4 +-
arch/powerpc/platforms/82xx/pq2fads.c | 10 +-
arch/powerpc/platforms/83xx/km83xx.c | 6 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 4 +-
arch/powerpc/platforms/85xx/p1022_rdk.c | 4 +-
arch/powerpc/platforms/85xx/t1042rdb_diu.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c | 2 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4 +-
arch/powerpc/platforms/8xx/adder875.c | 2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 28 +-
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 6 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 +-
arch/powerpc/platforms/embedded6xx/wii.c | 10 +-
arch/powerpc/sysdev/cpm1.c | 26 +-
arch/powerpc/sysdev/cpm2.c | 16 +-
arch/powerpc/sysdev/cpm_common.c | 4 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 8 +-
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 8 +-
arch/powerpc/sysdev/fsl_pmc.c | 2 +-
arch/powerpc/sysdev/fsl_rcpm.c | 74 ++--
arch/powerpc/sysdev/fsl_rio.c | 4 +-
arch/powerpc/sysdev/fsl_rmu.c | 8 +-
arch/powerpc/sysdev/mpic_timer.c | 12 +-
drivers/ata/ahci_sunxi.c | 51 +--
drivers/gpu/drm/meson/meson_crtc.c | 14 +-
drivers/gpu/drm/meson/meson_dw_hdmi.c | 33 +-
drivers/gpu/drm/meson/meson_plane.c | 13 +-
drivers/gpu/drm/meson/meson_registers.h | 3 -
drivers/gpu/drm/meson/meson_venc.c | 13 +-
drivers/gpu/drm/meson/meson_venc_cvbs.c | 4 +-
drivers/gpu/drm/meson/meson_viu.c | 65 +--
drivers/gpu/drm/meson/meson_vpp.c | 22 +-
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +--
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 +--
include/linux/setbits.h | 88 ++++
scripts/add_new_include_in_source.py | 61 +++
scripts/coccinelle/misc/setbits32.cocci | 487 +++++++++++++++++++++
scripts/coccinelle/misc/setbits32_relaxed.cocci | 487 +++++++++++++++++++++
scripts/coccinelle/misc/setbits64.cocci | 487 +++++++++++++++++++++
scripts/coccinelle/misc/setbits_dev.cocci | 235 ++++++++++
58 files changed, 2159 insertions(+), 377 deletions(-)
create mode 100644 include/linux/setbits.h
create mode 100755 scripts/add_new_include_in_source.py
create mode 100644 scripts/coccinelle/misc/setbits32.cocci
create mode 100644 scripts/coccinelle/misc/setbits32_relaxed.cocci
create mode 100644 scripts/coccinelle/misc/setbits64.cocci
create mode 100644 scripts/coccinelle/misc/setbits_dev.cocci
--
2.16.4
^ permalink raw reply
* [PATCH v2 net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Yafang Shao @ 2018-09-24 12:57 UTC (permalink / raw)
To: edumazet, davem; +Cc: netdev, linux-kernel, Yafang Shao
After sk_state exposed, we can get in which state this retransmission
occurs. That could give us more detail for dignostic.
For example, if this retransmission occurs in SYN_SENT state, it may
also indicates that the syn packet may be dropped on the remote peer due
to syn backlog queue full and then we could check the remote peer.
BTW,SYNACK retransmission is traced in tcp_retransmit_synack tracepoint.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/trace/events/tcp.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index ac55b32..2bc9960 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -56,6 +56,7 @@
TP_STRUCT__entry(
__field(const void *, skbaddr)
__field(const void *, skaddr)
+ __field(int, state)
__field(__u16, sport)
__field(__u16, dport)
__array(__u8, saddr, 4)
@@ -70,6 +71,7 @@
__entry->skbaddr = skb;
__entry->skaddr = sk;
+ __entry->state = sk->sk_state;
__entry->sport = ntohs(inet->inet_sport);
__entry->dport = ntohs(inet->inet_dport);
@@ -84,9 +86,10 @@
sk->sk_v6_rcv_saddr, sk->sk_v6_daddr);
),
- TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c",
+ TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c state=%s\n",
__entry->sport, __entry->dport, __entry->saddr, __entry->daddr,
- __entry->saddr_v6, __entry->daddr_v6)
+ __entry->saddr_v6, __entry->daddr_v6,
+ show_tcp_state_name(__entry->state))
);
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox