* Re: [PATCH net-next] net/sched: pkt_cls: change tc actions order to be as the user sets
From: Cong Wang @ 2016-09-26 20:34 UTC (permalink / raw)
To: Hadar Hen Zion
Cc: Jamal Hadi Salim, Hadar Hen Zion, David S. Miller,
Linux Kernel Network Developers, Or Gerlitz
In-Reply-To: <CAJL1qvGnPsjbzp9Z_6GkXzJqrxAAgYY6uE_0mCWb=H-EhcB8-A@mail.gmail.com>
On Sun, Sep 25, 2016 at 11:02 PM, Hadar Hen Zion
<hadarh@dev.mellanox.co.il> wrote:
> On Mon, Sep 26, 2016 at 7:31 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Sun, Sep 25, 2016 at 7:39 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>>> On 16-09-25 10:08 AM, Hadar Hen Zion wrote:
>>>>
>>>> Currently the created tc actions list is reversed against the order
>>>> set by the user.
>>>> Change the actions list order to be the same as was set by the user.
>>>>
>>>
>>>
>>> Did something break? It seems to matter most for dumping. But even that
>>> didnt breaking. Looking at the latest net tree, i tried:
>>>
>>
>> The reason is we use action->order as an nested attribute, so
>> the order in the list doesn't matter, only action->order itself matters.
>
> The order in the list matters for offload drivers who use the
> "tcf_exts_to_list" function and action->order parameter isn't usable
> for them.
> Why not keeping the actions in the same order as the user? isn't it
> more elegant?
I don't object this patch since it affects offloading, I just explained
why it doesn't affect dumping.
Please add this to your changelog, to make it obvious.
Thanks!
^ permalink raw reply
* Re: [PATCH 0/5] ISDN-Gigaset: Fine-tuning for three function implementations
From: Paul Bolle @ 2016-09-26 20:38 UTC (permalink / raw)
To: SF Markus Elfring, gigaset307x-common, netdev, Karsten Keil
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <6d4bbb77-914f-19b8-a1a9-2731d1158612@users.sourceforge.net>
On Mon, 2016-09-26 at 17:37 +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 26 Sep 2016 17:27:17 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5):
> Use kmalloc_array() in two functions
> Improve another size determination in gigaset_initcs()
> Delete an error message for a failed memory allocation
> Release memory in gigaset_initcs() after an allocation failure
Which "static source code analysis" was used for that discovery?
> Enclose two expressions for the sizeof operator by parentheses
>
> drivers/isdn/gigaset/common.c | 31 ++++++++++++++++---------------
> 1 file changed, 16 insertions(+), 15 deletions(-)
Paul Bolle
^ permalink raw reply
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Adit Ranadive @ 2016-09-26 20:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, dledford, linux-rdma, pv-drivers, netdev,
linux-pci, jhansen, asarwade, georgezhang, bryantan
In-Reply-To: <20160926165104.GA12011@obsidianresearch.com>
On Mon, Sep 26, 2016 at 10:51:04AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 25, 2016 at 10:25:12PM -0700, Adit Ranadive wrote:
> > > As Jason said, you need a very good reason to split and create number of
> > > files per-driver in UAPI folder.
> >
> > I can move the pvrdma-uapi.h back to the pvrdma driver folder.
>
> Just don't copy any of the content into your user space provider.
Thanks. I wanted to clarify regarding device specific structures since that
is what our pvrdma-uapi.h file has.
Wouldnt they be some overlap between the user-space and kernel driver? Or is
it expected that the common structures (even device specific ones) be moved to
the ABI file?
For the mlx4 driver I see that the structures in include/linux/mlx4/qp.h
and in libmlx4/src/wqe.h are similar.
Thanks,
Adit
^ permalink raw reply
* Re: 答复: [PATCH] sunrpc: queue work on system_power_efficient_wq
From: Anna Schumaker @ 2016-09-26 20:56 UTC (permalink / raw)
To: Ke Wang (王科), Chunyan Zhang,
trond.myklebust@primarydata.com, davem@davemloft.net
Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <d72ce63e4a054c8797c9ba92cdad3b5d@SHMBX03.spreadtrum.com>
Hi,
I took a second look at the patch and it still looks okay to me. It's in my git tree for 4.9.
Thanks,
Anna
On 09/19/2016 10:33 PM, Ke Wang (王科) wrote:
> May I have any comments for this patch?
> or
> This patch can be merged directly into next release?
>
> Thanks,
> Ke
> ________________________________________
> 发件人: Anna Schumaker <Anna.Schumaker@netapp.com>
> 发送时间: 2016年9月2日 2:46
> 收件人: Chunyan Zhang; trond.myklebust@primarydata.com; anna.schumaker@netapp.com; davem@davemloft.net
> 抄送: linux-nfs@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Ke Wang (王科)
> 主题: Re: [PATCH] sunrpc: queue work on system_power_efficient_wq
>
> On 09/01/2016 03:30 AM, Chunyan Zhang wrote:
>> From: Ke Wang <ke.wang@spreadtrum.com>
>>
>> sunrpc uses workqueue to clean cache regulary. There is no real dependency
>> of executing work on the cpu which queueing it.
>>
>> On a idle system, especially for a heterogeneous systems like big.LITTLE,
>> it is observed that the big idle cpu was woke up many times just to service
>> this work, which against the principle of power saving. It would be better
>> if we can schedule it on a cpu which the scheduler believes to be the most
>> appropriate one.
>>
>> After apply this patch, system_wq will be replaced by
>> system_power_efficient_wq for sunrpc. This functionality is enabled when
>> CONFIG_WQ_POWER_EFFICIENT is selected.
>
> Makes sense to me, but I'm a little surprised that there isn't a "schedule_delayed_power_efficient_work()" function to match how the normal workqueue is used.
>
> Thanks,
> Anna
>
>>
>> Signed-off-by: Ke Wang <ke.wang@spreadtrum.com>
>> ---
>> net/sunrpc/cache.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
>> index 4d8e11f..8aabe12 100644
>> --- a/net/sunrpc/cache.c
>> +++ b/net/sunrpc/cache.c
>> @@ -353,7 +353,7 @@ void sunrpc_init_cache_detail(struct cache_detail *cd)
>> spin_unlock(&cache_list_lock);
>>
>> /* start the cleaning process */
>> - schedule_delayed_work(&cache_cleaner, 0);
>> + queue_delayed_work(system_power_efficient_wq, &cache_cleaner, 0);
>> }
>> EXPORT_SYMBOL_GPL(sunrpc_init_cache_detail);
>>
>> @@ -476,7 +476,8 @@ static void do_cache_clean(struct work_struct *work)
>> delay = 0;
>>
>> if (delay)
>> - schedule_delayed_work(&cache_cleaner, delay);
>> + queue_delayed_work(system_power_efficient_wq,
>> + &cache_cleaner, delay);
>> }
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] net: trivial: fix fsl fec_main mdio write return value
From: Fabio Estevam @ 2016-09-26 21:00 UTC (permalink / raw)
To: Albert ARIBAUD (3ADEV); +Cc: netdev@vger.kernel.org, Jiri Kosina, Fugang Duan
In-Reply-To: <20160926191140.12107-1-albert.aribaud@3adev.fr>
Hi Albert,
On Mon, Sep 26, 2016 at 4:11 PM, Albert ARIBAUD (3ADEV)
<albert.aribaud@3adev.fr> wrote:
> If the MDIO enf-of-transfer wait loop does not time out,
> 0 should be returned to the caller through ret, but ret
> was not reset to 0 after receiving the return value of
> pm_runtime_get_sync(). Reset ret when no time out occurred.Is this really needed?
Commit 42ea4457 ("net: fec: normalize return value of
pm_runtime_get_sync() in MDIO write") does the following:
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 91925e3..6cc3340 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1816,11 +1816,13 @@ static int fec_enet_mdio_write(struct mii_bus
*bus, int mii_id, int regnum,
struct fec_enet_private *fep = bus->priv;
struct device *dev = &fep->pdev->dev;
unsigned long time_left;
- int ret = 0;
+ int ret;
ret = pm_runtime_get_sync(dev);
if (ret < 0)
return ret;
+ else
+ ret = 0;
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 01f7e81..0413c05 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1818,6 +1818,8 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> netdev_err(fep->netdev, "MDIO write timeout\n");
> ret = -ETIMEDOUT;
> }
> + else
> + ret = 0;
, so is this really needed? ret should be 0 at this point.
^ permalink raw reply related
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Jason Gunthorpe @ 2016-09-26 21:07 UTC (permalink / raw)
To: Adit Ranadive
Cc: Leon Romanovsky, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <b4e0acd9-e1a2-f6ac-0afa-c0fd62dd62f0-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
On Mon, Sep 26, 2016 at 01:40:10PM -0700, Adit Ranadive wrote:
> Wouldnt they be some overlap between the user-space and kernel driver? Or is
> it expected that the common structures (even device specific ones) be moved to
> the ABI file?
Yes, even device specific structures must be in the abi file. Anything
that is used with copy_to_user/copy_from_user/etc.
> For the mlx4 driver I see that the structures in include/linux/mlx4/qp.h
> and in libmlx4/src/wqe.h are similar.
We are trying to clean exactly that sort of stuff up, please try not
to add more.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: trivial: fix fsl fec_main mdio write return value
From: Albert ARIBAUD @ 2016-09-26 21:10 UTC (permalink / raw)
To: Fabio Estevam; +Cc: netdev@vger.kernel.org, Jiri Kosina, Fugang Duan
In-Reply-To: <CAOMZO5BikGA9e6goMs0wqNVHvWW9Mf3SpykA=DWfD4Q2gBbkag@mail.gmail.com>
Hi Fabio,
You are correct -- I'd rebased my patch as part of a series, and I did
not notice that the fix was already there. Apologies and thanks for
pointing it out.
Le Mon, 26 Sep 2016 18:00:32 -0300, Fabio Estevam <festevam@gmail.com>
a écrit :
> Hi Albert,
>
> On Mon, Sep 26, 2016 at 4:11 PM, Albert ARIBAUD (3ADEV)
> <albert.aribaud@3adev.fr> wrote:
> > If the MDIO enf-of-transfer wait loop does not time out,
> > 0 should be returned to the caller through ret, but ret
> > was not reset to 0 after receiving the return value of
> > pm_runtime_get_sync(). Reset ret when no time out occurred.Is this really needed?
>
> Commit 42ea4457 ("net: fec: normalize return value of
> pm_runtime_get_sync() in MDIO write") does the following:
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 91925e3..6cc3340 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1816,11 +1816,13 @@ static int fec_enet_mdio_write(struct mii_bus
> *bus, int mii_id, int regnum,
> struct fec_enet_private *fep = bus->priv;
> struct device *dev = &fep->pdev->dev;
> unsigned long time_left;
> - int ret = 0;
> + int ret;
>
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> return ret;
> + else
> + ret = 0;
>
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > b/drivers/net/ethernet/freescale/fec_main.c index 01f7e81..0413c05
> > 100644 --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -1818,6 +1818,8 @@ static int fec_enet_mdio_write(struct mii_bus
> > *bus, int mii_id, int regnum, netdev_err(fep->netdev, "MDIO write
> > timeout\n"); ret = -ETIMEDOUT;
> > }
> > + else
> > + ret = 0;
>
> , so is this really needed? ret should be 0 at this point.
Cordialement,
Albert ARIBAUD
3ADEV
^ permalink raw reply
* Re: [PATCH 4/5] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure
From: Paul Bolle @ 2016-09-26 21:13 UTC (permalink / raw)
To: SF Markus Elfring
Cc: gigaset307x-common, netdev, Karsten Keil, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <6409b3b0-3b7a-1139-f040-7b1a61611187@users.sourceforge.net>
Markus,
On Mon, 2016-09-26 at 17:43 +0200, SF Markus Elfring wrote:
> Memory was not released (as it would be expected) when one call
> of further resource reservations failed.
This was the only thing in this series that triggered more than a, very
uninspired, "meh" on first read.
> * Split a condition check for memory allocation failures so that
> each pointer from these function calls will be checked immediately.
>
> See also background information:
> Topic "CWE-754: Improper check for unusual or exceptional conditions"
> Link: https://cwe.mitre.org/data/definitions/754.html
A quick scan of that link suggests we can do without the above
"background information" in the commit explanation.
> * Adjust jump targets according to the Linux coding style convention.
Another "meh".
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/isdn/gigaset/common.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/isdn/gigaset/common.c
> b/drivers/isdn/gigaset/common.c
> index c05a2a4..2e9382f 100644
> --- a/drivers/isdn/gigaset/common.c
> +++ b/drivers/isdn/gigaset/common.c
> @@ -710,10 +710,13 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
> cs->mode = M_UNKNOWN;
> cs->mstate = MS_UNINITIALIZED;
> cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
> + if (!cs->bcs)
> + goto report_failure;
> +
> cs->inbuf = kmalloc(sizeof(*cs->inbuf), GFP_KERNEL);
> - if (!cs->bcs || !cs->inbuf) {
> - goto error;
> - }
> + if (!cs->inbuf)
> + goto free_bcs;
> +
> ++cs->cs_init;
>
> gig_dbg(DEBUG_INIT, "setting up at_state");
> @@ -737,14 +740,14 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
> gig_dbg(DEBUG_INIT, "setting up iif");
> if (gigaset_isdn_regdev(cs, modulename) < 0) {
> pr_err("error registering ISDN device\n");
> - goto error;
> + goto free_bcs;
> }
>
> make_valid(cs, VALID_ID);
> ++cs->cs_init;
> gig_dbg(DEBUG_INIT, "setting up hw");
> if (cs->ops->initcshw(cs) < 0)
> - goto error;
> + goto free_bcs;
>
> ++cs->cs_init;
>
> @@ -759,7 +762,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
> gig_dbg(DEBUG_INIT, "setting up bcs[%d]", i);
> if (gigaset_initbcs(cs->bcs + i, cs, i) < 0) {
> pr_err("could not allocate channel %d data\n", i);
> - goto error;
> + goto free_bcs;
> }
> }
>
> @@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
>
> gig_dbg(DEBUG_INIT, "cs initialized");
> return cs;
> -
> -error:
> +free_bcs:
> + kfree(cs->bcs);
> +report_failure:
> gig_dbg(DEBUG_INIT, "failed");
> gigaset_freecs(cs);
gigaset_freecs() is not a function I look at for the fun of it. But
still, in it we find:
case 0: /* error in basic setup */
[...]
kfree(cs->inbuf);
kfree(cs->bcs);
As far as I can tell we will call those two kfree()'s if we jump to
"error". So, contrary to your analysis, I don't think we leak cs->bcs.
> return NULL;
Paul Bolle
^ permalink raw reply
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Adit Ranadive @ 2016-09-26 21:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, dledford, linux-rdma, pv-drivers, netdev,
linux-pci, jhansen, asarwade, georgezhang, bryantan
In-Reply-To: <20160926210724.GA16413@obsidianresearch.com>
On Mon, Sep 26, 2016 at 14:07:24PM -0700, Jason Gunthorpe wrote:
> On Mon, Sep 26, 2016 at 01:40:10PM -0700, Adit Ranadive wrote:
>
> > Wouldnt they be some overlap between the user-space and kernel driver? Or is
> > it expected that the common structures (even device specific ones) be moved to
> > the ABI file?
>
> Yes, even device specific structures must be in the abi file. Anything
> that is used with copy_to_user/copy_from_user/etc.
>
Ok. Will make sure we consolidate the common stuff in the ABI file in the
next version.
Thanks,
Adit
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] net: bcmgenet: only use new api ethtool_{get|set}_link_ksettings
From: Florian Fainelli @ 2016-09-26 21:18 UTC (permalink / raw)
To: Philippe Reynes, jaedon.shin, davem; +Cc: netdev, linux-kernel
In-Reply-To: <1474921917-4773-1-git-send-email-tremyfr@gmail.com>
On 09/26/2016 01:31 PM, Philippe Reynes wrote:
> Some times ago, a serie of patches were committed :
> - commit 62469c76007e ("net: ethernet: bcmgenet: use phydev from struct net_device")
> - commit 6b352ebccbcf ("net: ethernet: broadcom: bcmgenet: use new api ethtool_{get|set}_link_ksettings")
> The first patch add a regression on this driver, so it should be reverted.
> As the second patch depend on the former, it should be reverted too.
>
> The first patch is buggy because there is a "trick" in this driver.
> The structure phydev is kept in the private data when the interface
> go down, and used when the interface go up to enable the phy before
> the function phy_connect is called.
>
> I don't have this hardware, neither the datasheet. So I won't
> update the driver to avoid this trick.
>
> But the real goal of the first serie was to move to the new api
> ethtool_{get|set}_link_ksettings. So I provide a new version of
> the patch without the "cleaning" of driver to use the phydev
> store in the net_device structure.
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
--
Florian
^ permalink raw reply
* [PATCH v2] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: Allan Chou @ 2016-09-26 21:48 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Allan Chou, Chris Roth
From: Chris Roth <chris.roth-/KKvz3x1pcI@public.gmane.org>
Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610).
Patch verified on x64 linux kernel 4.7.4 system with the
Kensington SD4600P USB-C Universal Dock with Power, which uses the
Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
A similar patch was signed-off and tested-by Allan Chou
<allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org> on 2015-12-01.
Allan verified his similar patch on x86 Linux kernel 4.1.6 system
with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
Tested-by: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
Tested-by: Chris Roth <chris.roth-/KKvz3x1pcI@public.gmane.org>
Signed-off-by: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
Signed-off-by: Chris Roth <chris.roth-/KKvz3x1pcI@public.gmane.org>
---
drivers/net/usb/ax88179_178a.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..8a6675d 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1656,6 +1656,19 @@ static const struct driver_info ax88178a_info = {
.tx_fixup = ax88179_tx_fixup,
};
+static const struct driver_info cypress_GX3_info = {
+ .description = "Cypress GX3 SuperSpeed to Gigabit Ethernet Controller",
+ .bind = ax88179_bind,
+ .unbind = ax88179_unbind,
+ .status = ax88179_status,
+ .link_reset = ax88179_link_reset,
+ .reset = ax88179_reset,
+ .stop = ax88179_stop,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .rx_fixup = ax88179_rx_fixup,
+ .tx_fixup = ax88179_tx_fixup,
+};
+
static const struct driver_info dlink_dub1312_info = {
.description = "D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter",
.bind = ax88179_bind,
@@ -1718,6 +1731,10 @@ static const struct usb_device_id products[] = {
USB_DEVICE(0x0b95, 0x178a),
.driver_info = (unsigned long)&ax88178a_info,
}, {
+ /* Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller */
+ USB_DEVICE(0x04b4, 0x3610),
+ .driver_info = (unsigned long)&cypress_GX3_info,
+}, {
/* D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter */
USB_DEVICE(0x2001, 0x4a00),
.driver_info = (unsigned long)&dlink_dub1312_info,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] brcmfmac: proto: add callback for queuing TX data
From: Rafał Miłecki @ 2016-09-26 21:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
So far our core code was calling brcmf_fws_process_skb which wasn't
a proper thing to do. If case of devices using msgbuf protocol fwsignal
shouldn't be used. It was an unnecessary extra layer simply calling
a protocol specifix txdata function.
Please note we already have txdata callback, but it's used for calls
between bcdc and fwsignal so it couldn't be simply used there.
This makes core code more generic (instead of bcdc/fwsignal specific).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
There is one 1 CHECK report from checkpatch.pl in this patch:
CHECK: Comparison to NULL could be written "!proto->hdrpull"
#157: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c:54:
+ if (!proto->tx_queue_data || (proto->hdrpull == NULL) ||
It's caused by a code that was already there and that should be fixed
in a separated patch. This shouldn't stop this patch from being applied.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 12 ++++++++++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 8 +++++++-
.../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 15 +++++----------
.../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 6 +++---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h | 9 +++++++++
7 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 038a960..384b187 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -326,6 +326,17 @@ brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
return 0;
}
+static int brcmf_proto_bcdc_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
+{
+ struct brcmf_if *ifp = brcmf_get_ifp(drvr, ifidx);
+
+ if (!brcmf_fws_queue_skbs(drvr->fws))
+ return brcmf_proto_txdata(drvr, ifidx, 0, skb);
+
+ return brcmf_fws_process_skb(ifp, skb);
+}
+
static int
brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, u8 offset,
struct sk_buff *pktbuf)
@@ -375,6 +386,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
drvr->proto->hdrpull = brcmf_proto_bcdc_hdrpull;
drvr->proto->query_dcmd = brcmf_proto_bcdc_query_dcmd;
drvr->proto->set_dcmd = brcmf_proto_bcdc_set_dcmd;
+ drvr->proto->tx_queue_data = brcmf_proto_bcdc_tx_queue_data;
drvr->proto->txdata = brcmf_proto_bcdc_txdata;
drvr->proto->configure_addr_mode = brcmf_proto_bcdc_configure_addr_mode;
drvr->proto->delete_peer = brcmf_proto_bcdc_delete_peer;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 1715280..6d046ba 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -239,7 +239,13 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
if (eh->h_proto == htons(ETH_P_PAE))
atomic_inc(&ifp->pend_8021x_cnt);
- ret = brcmf_fws_process_skb(ifp, skb);
+ /* determine the priority */
+ if ((skb->priority == 0) || (skb->priority > 7))
+ skb->priority = cfg80211_classify8021d(skb, NULL);
+
+ ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);
+ if (ret < 0)
+ brcmf_txfinalize(ifp, skb, false);
done:
if (ret) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index a190f53..5f1a592 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2100,16 +2100,6 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
int rc = 0;
brcmf_dbg(DATA, "tx proto=0x%X\n", ntohs(eh->h_proto));
- /* determine the priority */
- if ((skb->priority == 0) || (skb->priority > 7))
- skb->priority = cfg80211_classify8021d(skb, NULL);
-
- if (fws->avoid_queueing) {
- rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
- if (rc < 0)
- brcmf_txfinalize(ifp, skb, false);
- return rc;
- }
/* set control buffer information */
skcb->if_flags = 0;
@@ -2442,6 +2432,11 @@ void brcmf_fws_deinit(struct brcmf_pub *drvr)
kfree(fws);
}
+bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws)
+{
+ return !fws->avoid_queueing;
+}
+
bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
{
if (!fws->creditmap_received)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index ef0ad85..96df660 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
@@ -20,6 +20,7 @@
int brcmf_fws_init(struct brcmf_pub *drvr);
void brcmf_fws_deinit(struct brcmf_pub *drvr);
+bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws);
bool brcmf_fws_fc_active(struct brcmf_fws_info *fws);
void brcmf_fws_hdrpull(struct brcmf_if *ifp, s16 siglen, struct sk_buff *skb);
int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 2b9a2bc..7cc8851 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -782,8 +782,8 @@ static int brcmf_msgbuf_schedule_txdata(struct brcmf_msgbuf *msgbuf, u32 flowid,
}
-static int brcmf_msgbuf_txdata(struct brcmf_pub *drvr, int ifidx,
- u8 offset, struct sk_buff *skb)
+static int brcmf_msgbuf_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
{
struct brcmf_msgbuf *msgbuf = (struct brcmf_msgbuf *)drvr->proto->pd;
struct brcmf_flowring *flow = msgbuf->flow;
@@ -1467,7 +1467,7 @@ int brcmf_proto_msgbuf_attach(struct brcmf_pub *drvr)
drvr->proto->hdrpull = brcmf_msgbuf_hdrpull;
drvr->proto->query_dcmd = brcmf_msgbuf_query_dcmd;
drvr->proto->set_dcmd = brcmf_msgbuf_set_dcmd;
- drvr->proto->txdata = brcmf_msgbuf_txdata;
+ drvr->proto->tx_queue_data = brcmf_msgbuf_tx_queue_data;
drvr->proto->configure_addr_mode = brcmf_msgbuf_configure_addr_mode;
drvr->proto->delete_peer = brcmf_msgbuf_delete_peer;
drvr->proto->add_tdls_peer = brcmf_msgbuf_add_tdls_peer;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
index 26b68c3..d26ff21 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c
@@ -51,7 +51,7 @@ int brcmf_proto_attach(struct brcmf_pub *drvr)
drvr->bus_if->proto_type);
goto fail;
}
- if ((proto->txdata == NULL) || (proto->hdrpull == NULL) ||
+ if (!proto->tx_queue_data || (proto->hdrpull == NULL) ||
(proto->query_dcmd == NULL) || (proto->set_dcmd == NULL) ||
(proto->configure_addr_mode == NULL) ||
(proto->delete_peer == NULL) || (proto->add_tdls_peer == NULL)) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
index 57531f4..34b59fe 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
@@ -33,6 +33,8 @@ struct brcmf_proto {
void *buf, uint len);
int (*set_dcmd)(struct brcmf_pub *drvr, int ifidx, uint cmd, void *buf,
uint len);
+ int (*tx_queue_data)(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb);
int (*txdata)(struct brcmf_pub *drvr, int ifidx, u8 offset,
struct sk_buff *skb);
void (*configure_addr_mode)(struct brcmf_pub *drvr, int ifidx,
@@ -74,6 +76,13 @@ static inline int brcmf_proto_set_dcmd(struct brcmf_pub *drvr, int ifidx,
{
return drvr->proto->set_dcmd(drvr, ifidx, cmd, buf, len);
}
+
+static inline int brcmf_proto_tx_queue_data(struct brcmf_pub *drvr, int ifidx,
+ struct sk_buff *skb)
+{
+ return drvr->proto->tx_queue_data(drvr, ifidx, skb);
+}
+
static inline int brcmf_proto_txdata(struct brcmf_pub *drvr, int ifidx,
u8 offset, struct sk_buff *skb)
{
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: Chris Roth @ 2016-09-26 21:56 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel
In-Reply-To: <271e26e7350f418bad08761cab439005@Mail06.usask.ca>
I'm not sure what I'm doing wrong:
I'm trying to get the from statement to read original author (Allan
Chou) first, and then me (Chris Roth) second. I've used the following
two commands:
git format-patch -o /tmp/ --subject-prefix="PATCH v2" --from="Allan
Chou <allan@asix.com.tw>" HEAD^
and
git send-email --to linux-usb@vger.kernel.org --to
netdev@vger.kernel.org --to linux-kernel@vger.kernel.org --from="Allan
Chou <allan@asix.com.tw>"
/tmp/0001-Net-Driver-Add-Cypress-GX3-VID-04b4-PID-3610.patch
I thought that adding the --from portions to the git format-patch and
git send-email commands would force the addition of Allan to the top
of the patch, but it hasn't. Can anyone tell me specifically how I
need to change these commands in order to get the desired result? Then
I'll submit a PATCH v3.
Regards,
Chris
On Mon, Sep 26, 2016 at 3:48 PM, Allan Chou <allan@asix.com.tw> wrote:
> From: Chris Roth <chris.roth@usask.ca>
>
> Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
> Bridge Controller (Vendor=04b4 ProdID=3610).
>
> Patch verified on x64 linux kernel 4.7.4 system with the
> Kensington SD4600P USB-C Universal Dock with Power, which uses the
> Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
>
> A similar patch was signed-off and tested-by Allan Chou
> <allan@asix.com.tw> on 2015-12-01.
>
> Allan verified his similar patch on x86 Linux kernel 4.1.6 system
> with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
>
> Tested-by: Allan Chou <allan@asix.com.tw>
> Tested-by: Chris Roth <chris.roth@usask.ca>
>
> Signed-off-by: Allan Chou <allan@asix.com.tw>
> Signed-off-by: Chris Roth <chris.roth@usask.ca>
> ---
> drivers/net/usb/ax88179_178a.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
> index e6338c1..8a6675d 100644
> --- a/drivers/net/usb/ax88179_178a.c
> +++ b/drivers/net/usb/ax88179_178a.c
> @@ -1656,6 +1656,19 @@ static const struct driver_info ax88178a_info = {
> .tx_fixup = ax88179_tx_fixup,
> };
>
> +static const struct driver_info cypress_GX3_info = {
> + .description = "Cypress GX3 SuperSpeed to Gigabit Ethernet Controller",
> + .bind = ax88179_bind,
> + .unbind = ax88179_unbind,
> + .status = ax88179_status,
> + .link_reset = ax88179_link_reset,
> + .reset = ax88179_reset,
> + .stop = ax88179_stop,
> + .flags = FLAG_ETHER | FLAG_FRAMING_AX,
> + .rx_fixup = ax88179_rx_fixup,
> + .tx_fixup = ax88179_tx_fixup,
> +};
> +
> static const struct driver_info dlink_dub1312_info = {
> .description = "D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter",
> .bind = ax88179_bind,
> @@ -1718,6 +1731,10 @@ static const struct usb_device_id products[] = {
> USB_DEVICE(0x0b95, 0x178a),
> .driver_info = (unsigned long)&ax88178a_info,
> }, {
> + /* Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller */
> + USB_DEVICE(0x04b4, 0x3610),
> + .driver_info = (unsigned long)&cypress_GX3_info,
> +}, {
> /* D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter */
> USB_DEVICE(0x2001, 0x4a00),
> .driver_info = (unsigned long)&dlink_dub1312_info,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] sh_eth: add R8A7743/5 support
From: Sergei Shtylyov @ 2016-09-26 22:07 UTC (permalink / raw)
To: netdev, linux-renesas-soc
Add support for the first two members of the Renesas RZ/G family, RZ/G1M/E
(also known as R8A7743/5). The Ether core is the same as in the R-Car gen2
SoCs, so will share the code/data with them...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the DaveM's 'net-next.git' repo.
Documentation/devicetree/bindings/net/sh_eth.txt | 2 ++
drivers/net/ethernet/renesas/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/sh_eth.txt
+++ net-next/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -5,6 +5,8 @@ interface contains.
Required properties:
- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
+ "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC.
+ "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC.
"renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
"renesas,ether-r8a7779" if the device is a part of R8A7779 SoC.
"renesas,ether-r8a7790" if the device is a part of R8A7790 SoC.
Index: net-next/drivers/net/ethernet/renesas/Kconfig
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/Kconfig
+++ net-next/drivers/net/ethernet/renesas/Kconfig
@@ -27,7 +27,7 @@ config SH_ETH
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
- R8A7740, R8A777x and R8A779x.
+ R8A7740, R8A774x, R8A777x and R8A779x.
config RAVB
tristate "Renesas Ethernet AVB support"
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2959,6 +2959,8 @@ static struct sh_eth_plat_data *sh_eth_p
static const struct of_device_id sh_eth_match_table[] = {
{ .compatible = "renesas,gether-r8a7740", .data = &r8a7740_data },
+ { .compatible = "renesas,ether-r8a7743", .data = &r8a779x_data },
+ { .compatible = "renesas,ether-r8a7745", .data = &r8a779x_data },
{ .compatible = "renesas,ether-r8a7778", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7779", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7790", .data = &r8a779x_data },
^ permalink raw reply
* Re: [PATCH] net: trivial: fix fsl fec_main mdio write return value
From: Sergei Shtylyov @ 2016-09-26 22:10 UTC (permalink / raw)
To: Albert ARIBAUD (3ADEV), netdev; +Cc: Jiri Kosina, Fugang Duan
In-Reply-To: <20160926191140.12107-1-albert.aribaud@3adev.fr>
Hello.
On 09/26/2016 10:11 PM, Albert ARIBAUD (3ADEV) wrote:
> If the MDIO enf-of-transfer wait loop does not time out,
> 0 should be returned to the caller through ret, but ret
> was not reset to 0 after receiving the return value of
> pm_runtime_get_sync(). Reset ret when no time out occurred.
>
> Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 01f7e81..0413c05 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1818,6 +1818,8 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> netdev_err(fep->netdev, "MDIO write timeout\n");
> ret = -ETIMEDOUT;
> }
> + else
} else {
> + ret = 0;
}
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH resend] sh_eth: add R8A7743/5 support
From: Sergei Shtylyov @ 2016-09-26 22:23 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Add support for the first two members of the Renesas RZ/G family, RZ/G1M/E
(also known as R8A7743/5). The Ether core is the same as in the R-Car gen2
SoCs, so will share the code/data with them...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
---
The patch is against the DaveM's 'net-next.git' repo.
Re-sending with the DT maintainers/list included this time...
Documentation/devicetree/bindings/net/sh_eth.txt | 2 ++
drivers/net/ethernet/renesas/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/sh_eth.txt
+++ net-next/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -5,6 +5,8 @@ interface contains.
Required properties:
- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
+ "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC.
+ "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC.
"renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
"renesas,ether-r8a7779" if the device is a part of R8A7779 SoC.
"renesas,ether-r8a7790" if the device is a part of R8A7790 SoC.
Index: net-next/drivers/net/ethernet/renesas/Kconfig
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/Kconfig
+++ net-next/drivers/net/ethernet/renesas/Kconfig
@@ -27,7 +27,7 @@ config SH_ETH
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
- R8A7740, R8A777x and R8A779x.
+ R8A7740, R8A774x, R8A777x and R8A779x.
config RAVB
tristate "Renesas Ethernet AVB support"
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2959,6 +2959,8 @@ static struct sh_eth_plat_data *sh_eth_p
static const struct of_device_id sh_eth_match_table[] = {
{ .compatible = "renesas,gether-r8a7740", .data = &r8a7740_data },
+ { .compatible = "renesas,ether-r8a7743", .data = &r8a779x_data },
+ { .compatible = "renesas,ether-r8a7745", .data = &r8a779x_data },
{ .compatible = "renesas,ether-r8a7778", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7779", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7790", .data = &r8a779x_data },
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets
From: Cyrill Gorcunov @ 2016-09-26 22:38 UTC (permalink / raw)
To: David Ahern, Eric Dumazet
Cc: netdev, linux-kernel, David Miller, kuznet, jmorris, yoshfuji,
kaber, avagin, stephen
In-Reply-To: <20160920211343.GI26044@uranus.lan>
On Wed, Sep 21, 2016 at 12:13:43AM +0300, Cyrill Gorcunov wrote:
> On Fri, Sep 16, 2016 at 11:07:22PM +0300, Cyrill Gorcunov wrote:
> > > It may well be a ss bug / problem. As I mentioned I am always seeing 255 for the protocol which
> >
> > It is rather not addressed in ss. I mean, look, when we send out a diag packet
> > the kernel look ups for a handler, which for raw protocol we register as
> >
> > static const struct inet_diag_handler raw_diag_handler = {
> > .dump= raw_diag_dump,
> > .dump_one= raw_diag_dump_one,
> > .idiag_get_info= raw_diag_get_info,
> > .idiag_type= IPPROTO_RAW,
> > .idiag_info_size= 0,
> > #ifdef CONFIG_INET_DIAG_DESTROY
> > .destroy= raw_diag_destroy,
> > #endif
> > };
> >
> > so if we patch ss and ask for IPPROTO_ICMP in netlink packet the
> > kernel simply won't find anything. Thus I think we need (well, I need)
> > to extend the patch and register IPPROTO_ICMP diag type, then
> > extend ss as well. (If only I didn't miss somethin obvious).
> >
> > > is odd since ss does a dump and takes the matches and invokes the kill.
> > > Thanks for taking the time to do the kill piece.
>
> Sorry for delay in reply (I got flu unexpectedly). You know, it eventually
> become uneasy to implement handling for sock-raw because they are special.
> They described as ipproto-ip in net/ipv4/af_inet.c, so it matches any
> protocol specified with the socket call. In turn inet-diag module handled
> predefined protocols only, in particular IPPROTO_RAW in our case. Thus
> to fecth some real protocol sitting in raw sockets hashes we need some
> kind of additional argument passed in the request. I guess we may
> use @idiag_ext field for this sake? Or require @idiag_ext to have
> INET_DIAG_PROTOCOL bit set and then fetch real protocol from
> additional attribute? Sounds ok?
Something like
Index: linux-ml.git/include/uapi/linux/inet_diag.h
===================================================================
--- linux-ml.git.orig/include/uapi/linux/inet_diag.h 2016-09-11 20:56:18.191584145 +0300
+++ linux-ml.git/include/uapi/linux/inet_diag.h 2016-09-27 01:34:08.413172394 +0300
@@ -38,7 +38,7 @@ struct inet_diag_req_v2 {
__u8 sdiag_family;
__u8 sdiag_protocol;
__u8 idiag_ext;
- __u8 pad;
+ __u8 sdiag_raw_protocol; /* SOCK_RAW only, @pad for others */
__u32 idiag_states;
struct inet_diag_sockid id;
};
and in raw-diag module we will use @sdiag_raw_protocol instead of
@sdiag_protocol field. Didn't cover ss tool source code yet but
I think the idea is seen. Still not sure if start using @pad here
is a good idea (it's uapi), maybe beter to ask nla attribute which would
come right afterh the inet_diag_req_v2 message?
Cyrill
^ permalink raw reply
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Bjorn Helgaas @ 2016-09-26 22:42 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <cover.1474759181.git.aditr@vmware.com>
On Sat, Sep 24, 2016 at 04:21:24PM -0700, Adit Ranadive wrote:
> MAINTAINERS | 9 +
> drivers/infiniband/Kconfig | 1 +
> drivers/infiniband/hw/Makefile | 1 +
> drivers/infiniband/hw/pvrdma/Kconfig | 7 +
> drivers/infiniband/hw/pvrdma/Makefile | 3 +
> drivers/infiniband/hw/pvrdma/pvrdma.h | 473 +++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_cmd.c | 117 +++
> drivers/infiniband/hw/pvrdma/pvrdma_cq.c | 426 +++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_defs.h | 301 ++++++
> drivers/infiniband/hw/pvrdma/pvrdma_dev_api.h | 342 +++++++
> drivers/infiniband/hw/pvrdma/pvrdma_doorbell.c | 127 +++
> drivers/infiniband/hw/pvrdma/pvrdma_ib_verbs.h | 444 +++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_main.c | 1220 ++++++++++++++++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_misc.c | 304 ++++++
> drivers/infiniband/hw/pvrdma/pvrdma_mr.c | 334 +++++++
> drivers/infiniband/hw/pvrdma/pvrdma_qp.c | 973 +++++++++++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_verbs.c | 577 +++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_verbs.h | 108 +++
> drivers/net/vmxnet3/vmxnet3_int.h | 3 +-
> include/linux/pci_ids.h | 1 +
> include/uapi/rdma/Kbuild | 2 +
> include/uapi/rdma/pvrdma-abi.h | 99 ++
> include/uapi/rdma/pvrdma-uapi.h | 255 +++++
Hi Adit,
You don't need to cc linux-pci just because of the one-line change to
pci_ids.h. I've already acked that, and the rest is just noise to the
main linux-pci audience.
Bjorn
^ permalink raw reply
* Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)
From: Andrew Morton @ 2016-09-27 0:01 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Alexander Viro, linux-fsdevel, linux-kernel, linux-mm,
Michal Hocko, netdev, Eric Dumazet
In-Reply-To: <20160922164359.9035-1-vbabka@suse.cz>
On Thu, 22 Sep 2016 18:43:59 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
> with the number of fds passed. We had a customer report page allocation
> failures of order-4 for this allocation. This is a costly order, so it might
> easily fail, as the VM expects such allocation to have a lower-order fallback.
>
> Such trivial fallback is vmalloc(), as the memory doesn't have to be
> physically contiguous. Also the allocation is temporary for the duration of the
> syscall, so it's unlikely to stress vmalloc too much.
>
> Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
> it doesn't need this kind of fallback.
>
> ...
>
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -29,6 +29,7 @@
> #include <linux/sched/rt.h>
> #include <linux/freezer.h>
> #include <net/busy_poll.h>
> +#include <linux/vmalloc.h>
>
> #include <asm/uaccess.h>
>
> @@ -558,6 +559,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp,
> struct fdtable *fdt;
> /* Allocate small arguments on the stack to save memory and be faster */
> long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
> + unsigned long alloc_size;
>
> ret = -EINVAL;
> if (n < 0)
> @@ -580,8 +582,12 @@ int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp,
> bits = stack_fds;
> if (size > sizeof(stack_fds) / 6) {
> /* Not enough space in on-stack array; must use kmalloc */
> + alloc_size = 6 * size;
Well. `size' is `unsigned'. The multiplication will be done as 32-bit
so there was no point in making `alloc_size' unsigned long.
So can we tighten up the types in this function? size_t might make
sense, but vmalloc() takes a ulong.
> ret = -ENOMEM;
> - bits = kmalloc(6 * size, GFP_KERNEL);
> + bits = kmalloc(alloc_size, GFP_KERNEL|__GFP_NOWARN);
> + if (!bits && alloc_size > PAGE_SIZE)
> + bits = vmalloc(alloc_size);
I don't share Eric's concerns about performance here. If the vmalloc()
is called, we're about to write to that quite large amount of memory
which we just allocated, and the vmalloc() overhead will be relatively
low.
> if (!bits)
> goto out_nofds;
> }
> @@ -618,7 +624,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp,
>
> out:
> if (bits != stack_fds)
> - kfree(bits);
> + kvfree(bits);
> out_nofds:
> return ret;
It otherwise looks OK to me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses
From: David Miller @ 2016-09-27 0:10 UTC (permalink / raw)
To: elfring
Cc: joe, David.Laight, gigaset307x-common, netdev, isdn, pebolle,
linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <f9dd122f-b0ed-0398-2a13-4d31693356fa@users.sourceforge.net>
When you need to make changes to patches that are part of a series,
you must resubmit the entire series, not just the things that
are changes.
^ permalink raw reply
* Re: [PATCH] net: tg3: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-09-27 0:17 UTC (permalink / raw)
To: tremyfr; +Cc: siva.kallam, prashant, mchan, f.fainelli, netdev, linux-kernel
In-Reply-To: <1474839084-10883-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 25 Sep 2016 23:31:24 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)
From: Eric Dumazet @ 2016-09-27 1:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Vlastimil Babka, Alexander Viro, linux-fsdevel, linux-kernel,
linux-mm, Michal Hocko, netdev
In-Reply-To: <20160926170105.517f74cd67ecdd5ef73e1865@linux-foundation.org>
On Mon, 2016-09-26 at 17:01 -0700, Andrew Morton wrote:
> I don't share Eric's concerns about performance here. If the vmalloc()
> is called, we're about to write to that quite large amount of memory
> which we just allocated, and the vmalloc() overhead will be relatively
> low.
I did not care of the performance of this particular select() system
call really, but other cpus because of more TLB invalidations.
At least CONFIG_DEBUG_PAGEALLOC=y builds should be impacted, but maybe
we do not care.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets
From: David Ahern @ 2016-09-27 1:54 UTC (permalink / raw)
To: Cyrill Gorcunov, Eric Dumazet
Cc: netdev, linux-kernel, David Miller, kuznet, jmorris, yoshfuji,
kaber, avagin, stephen
In-Reply-To: <20160926223828.GL1876@uranus.lan>
On 9/26/16 4:38 PM, Cyrill Gorcunov wrote:
> Something like
>
> Index: linux-ml.git/include/uapi/linux/inet_diag.h
> ===================================================================
> --- linux-ml.git.orig/include/uapi/linux/inet_diag.h 2016-09-11 20:56:18.191584145 +0300
> +++ linux-ml.git/include/uapi/linux/inet_diag.h 2016-09-27 01:34:08.413172394 +0300
> @@ -38,7 +38,7 @@ struct inet_diag_req_v2 {
> __u8 sdiag_family;
> __u8 sdiag_protocol;
> __u8 idiag_ext;
> - __u8 pad;
> + __u8 sdiag_raw_protocol; /* SOCK_RAW only, @pad for others */
Seems like that should be a union to keep the API.
> __u32 idiag_states;
> struct inet_diag_sockid id;
> };
>
> and in raw-diag module we will use @sdiag_raw_protocol instead of
> @sdiag_protocol field. Didn't cover ss tool source code yet but
> I think the idea is seen. Still not sure if start using @pad here
> is a good idea (it's uapi), maybe beter to ask nla attribute which would
> come right afterh the inet_diag_req_v2 message?
>
seems reasonable to me since 2 protocols need to be sent to the kernel.
Alternatively, sdiag_protocol could be the actual protocol and the pad union be a flag field with say bit 0 = INET_DIAG_FLAG_SOCK_RAW. Allows other overrides in the future if needed.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO
From: David Ahern @ 2016-09-27 2:04 UTC (permalink / raw)
To: Jiri Benc
Cc: pravin shelar, Simon Horman, Pravin B Shelar,
Linux Kernel Network Developers, David S. Miller, buytenh,
Eric W. Biederman, rshearma, tom, Thomas Graf, olivier.dugeon,
Alexander Duyck, roopa
In-Reply-To: <20160926190259.3b878aa5@griffin>
On 9/26/16 11:02 AM, Jiri Benc wrote:
> On Mon, 26 Sep 2016 17:56:22 +0200, Jiri Benc wrote:
>> After push_mpls, network_header points to the start of MPLS headers.
>> Which I understand was the point of this patch. However, push_mpls also
>> calls invalidate_flow_key. Meaning that, depending on actions, we may
>> end up calling key_extract soon after. And key_extract sets the network
>> header *after* the MPLS headers.
you know this code better than me, but key_extract pulls the eth header and then sets network header. If MPLS labels are present then it is the labels that the network_header now points to. How did come to the conclusion it is after the labels?
>>
>> That means that on output, for otherwise identical packet,
>> network_header can point before or after MPLS headers based on what
>> actions happened to be executed (recirculation, mainly).
>>
>> If I'm not misreading the code or missing something, this can't be
>> right.
>>
>> mpls_gso_segment does not care, it resets the network_header anyway.
>> What about drivers? What is the correct behavior?
>
> Answering to myself: it breaks skb_mac_gso_segment. Seems we need to
> fix key_extract to set network_header to the beginning of MPLS headers.
> I'll prepare a patch.
>
> Jiri
>
^ permalink raw reply
* Re: [PATCH v2 3/7] ipv6 addrconf: rtr_solicits == -1 means unlimited
From: Maciej Żenczykowski @ 2016-09-27 2:23 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: David S . Miller, netdev@vger.kernel.org, Erik Kline
In-Reply-To: <CAKD1Yr2MHqFMmJyf89pWzopcr07ziVcHqUB+oNWdphKx95nGDg@mail.gmail.com>
> Given that some of this patch checks for == -1, and some of it checks
> for != 0... is it possible that setting the value to something
> unexpected like -3 will cause any issues to the stack? (Other than
> just rendering IPv6 unusable on this interface, which seems like a
> given.)
You shouldn't be able to set it to -3, that's what the extra1 is for...
^ permalink raw reply
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