* Re: [PATCH net-next 2/2] vxlan: Eliminate dependency on UDP socket in transmit path
From: Thomas Graf @ 2015-01-19 8:59 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1421518700-22460-3-git-send-email-therbert@google.com>
On 01/17/15 at 10:18am, Tom Herbert wrote:
> diff --git a/include/net/vxlan.h b/include/net/vxlan.h
> index 7be8c34..2927d62 100644
> --- a/include/net/vxlan.h
> +++ b/include/net/vxlan.h
> @@ -129,8 +129,12 @@ struct vxlan_sock {
> #define VXLAN_F_REMCSUM_RX 0x400
> #define VXLAN_F_GBP 0x800
>
> -/* These flags must match in order for a socket to be shareable */
> -#define VXLAN_F_UNSHAREABLE VXLAN_F_GBP
> +/* Flags that are used in the receive patch. These flags must match in
^^^^^
> + * order for a socket to be shareable
> + */
> +#define VXLAN_F_RCV_FLAGS (VXLAN_F_GBP | \
> + VXLAN_F_UDP_ZERO_CSUM6_RX | \
> + VXLAN_F_REMCSUM_RX)
I'm fine with this. It is slightly odd that we will be transmitting
RCO and other extensions on UDP ports which cannot accept the same
frames. I assume you have specific use cases for this scenario.
^ permalink raw reply
* Re: [PATCH 2/2] net wireless wcn36xx adapt wcnss platform to select module by DT
From: Andy Green @ 2015-01-19 9:00 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAFSJ42b2WaYcbvaW1RmBLdfU9t4C0ALXM_n_T=VXygpYNPPp9w@mail.gmail.com>
On 19 January 2015 at 16:49, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
> Have you tested this code on any device other than wcn3620?
No... the only hardware I have is 3620. But the only code we're
adding to mainline is the patch with the ops to get the chip type.
The two-patch series just shows one way to set that (which will
certainly work for all three defined compatible types, if it works for
one). And this code cannot go upstream.
So the only decision to make is around whether adding the platform op
is a good way (or, eg, directly add DT support to wcn36xx and
eliminate the 'device regeneration' part of the OOT -msm code).
At the moment the detect code does not work for 3620, so something
needs to be done.
-Andy
> 2015-01-19 8:44 GMT+00:00 Andy Green <andy.green@linaro.org>:
>> On 19 January 2015 at 16:34, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>>
>>> So how do we insmod wcn36xx_msm with a parameter specifying what type
>>> of hardware do we use?
>>
>> The type of chip is defined in the DT "compatible" which also delivers
>> the resource information.
>>
>> qcom,wcn36xx@0a000000 {
>> compatible = "qcom,wcn3620";
>> reg = <0x0a000000 0x280000>;
>> reg-names = "wcnss_mmio";
>>
>> interrupts = <0 145 0 0 146 0>;
>> interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq";
>> ...
>>
>> This bit based on your code can't go in mainline until there's some
>> kind of PIL support.
>>
>> So the only things we can discuss about it for mainline purpose is
>> whether using a platform ops is a good way to interface to the
>> mainline driver.
>>
>> If you're OK with that and you want a module parameter then this can
>> grow a module parameter and prefer to deliver the chip type from that
>> if given, without modifying the platform op interface.
>>
>> But with or without a module parameter this can't be upstreamed right
>> now due to PIL.
>>
>> -Andy
>>
>>> 2015-01-18 5:16 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>>> Simplify the resource handling and use DT to indicate which chip type
>>>> we are dealing with
>>>>
>>>> Signed-off-by: Andy Green <andy.green@linaro.org>
>>>> ---
>>>> drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c | 101 ++++++++++++------------
>>>> 1 file changed, 52 insertions(+), 49 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>> index f6f6c83..c9250e0 100644
>>>> --- a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>> +++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>> @@ -42,7 +42,10 @@ struct wcn36xx_msm {
>>>> struct completion smd_compl;
>>>> smd_channel_t *smd_ch;
>>>> struct pinctrl *pinctrl;
>>>> -} wmsm;
>>>> + enum wcn36xx_chip_type chip_type;
>>>> +};
>>>> +
>>>> +static struct wcn36xx_msm wmsm;
>>>>
>>>> static int wcn36xx_msm_smsm_change_state(u32 clear_mask, u32 set_mask)
>>>> {
>>>> @@ -217,14 +220,47 @@ int wcn36xx_msm_powerup(const struct subsys_desc *desc)
>>>> return 0;
>>>> }
>>>>
>>>> +static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>> + { .compatible = "qcom,wcn3660", .data = (void *)WCN36XX_CHIP_3660 },
>>>> + { .compatible = "qcom,wcn3680", .data = (void *)WCN36XX_CHIP_3680 },
>>>> + { .compatible = "qcom,wcn3620", .data = (void *)WCN36XX_CHIP_3620 },
>>>> + { }
>>>> +};
>>>> +
>>>> +static int wcn36xx_msm_get_chip_type(void)
>>>> +{
>>>> + return wmsm.chip_type;
>>>> +}
>>>> +
>>>> +static struct wcn36xx_msm wmsm = {
>>>> + .ctrl_ops = {
>>>> + .open = wcn36xx_msm_smd_open,
>>>> + .close = wcn36xx_msm_smd_close,
>>>> + .tx = wcn36xx_msm_smd_send_and_wait,
>>>> + .get_hw_mac = wcn36xx_msm_get_hw_mac,
>>>> + .smsm_change_state = wcn36xx_msm_smsm_change_state,
>>>> + .get_chip_type = wcn36xx_msm_get_chip_type,
>>>> + },
>>>> +};
>>>> +
>>>> static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>> {
>>>> int ret;
>>>> - struct resource *wcnss_memory;
>>>> - struct resource *tx_irq;
>>>> - struct resource *rx_irq;
>>>> + const struct of_device_id *of_id;
>>>> + struct resource *r;
>>>> struct resource res[3];
>>>> struct pinctrl_state *ps;
>>>> + static const char const *rnames[] = {
>>>> + "wcnss_mmio", "wcnss_wlantx_irq", "wcnss_wlanrx_irq" };
>>>> + static const int rtype[] = {
>>>> + IORESOURCE_MEM, IORESOURCE_IRQ, IORESOURCE_IRQ };
>>>> + int n;
>>>> +
>>>> + of_id = of_match_node(wcn36xx_msm_match_table, pdev->dev.of_node);
>>>> + if (!of_id)
>>>> + return -EINVAL;
>>>> +
>>>> + wmsm.chip_type = (enum wcn36xx_chip_type)of_id->data;
>>>>
>>>> wmsm.pinctrl = devm_pinctrl_get(&pdev->dev);
>>>> if (IS_ERR_OR_NULL(wmsm.pinctrl))
>>>> @@ -240,52 +276,23 @@ static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>
>>>> if (IS_ERR_OR_NULL(pil))
>>>> pil = subsystem_get("wcnss");
>>>> - if (IS_ERR_OR_NULL(pil))
>>>> - return PTR_ERR(pil);
>>>> + if (IS_ERR_OR_NULL(pil))
>>>> + return PTR_ERR(pil);
>>>>
>>>> wmsm.core = platform_device_alloc("wcn36xx", -1);
>>>>
>>>> - //dev_err(&pdev->dev, "%s starting\n", __func__);
>>>> -
>>>> - memset(res, 0x00, sizeof(res));
>>>> - wmsm.ctrl_ops.open = wcn36xx_msm_smd_open;
>>>> - wmsm.ctrl_ops.close = wcn36xx_msm_smd_close;
>>>> - wmsm.ctrl_ops.tx = wcn36xx_msm_smd_send_and_wait;
>>>> - wmsm.ctrl_ops.get_hw_mac = wcn36xx_msm_get_hw_mac;
>>>> - wmsm.ctrl_ops.smsm_change_state = wcn36xx_msm_smsm_change_state;
>>>> - wcnss_memory =
>>>> - platform_get_resource_byname(pdev,
>>>> - IORESOURCE_MEM,
>>>> - "wcnss_mmio");
>>>> - if (wcnss_memory == NULL) {
>>>> - dev_err(&wmsm.core->dev,
>>>> - "Failed to get wcnss wlan memory map.\n");
>>>> - ret = -ENOMEM;
>>>> - return ret;
>>>> - }
>>>> - memcpy(&res[0], wcnss_memory, sizeof(*wcnss_memory));
>>>> -
>>>> - tx_irq = platform_get_resource_byname(pdev,
>>>> - IORESOURCE_IRQ,
>>>> - "wcnss_wlantx_irq");
>>>> - if (tx_irq == NULL) {
>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss tx_irq");
>>>> - ret = -ENOMEM;
>>>> - return ret;
>>>> - }
>>>> - memcpy(&res[1], tx_irq, sizeof(*tx_irq));
>>>> -
>>>> - rx_irq = platform_get_resource_byname(pdev,
>>>> - IORESOURCE_IRQ,
>>>> - "wcnss_wlanrx_irq");
>>>> - if (rx_irq == NULL) {
>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss rx_irq");
>>>> - ret = -ENOMEM;
>>>> - return ret;
>>>> + for (n = 0; n < ARRAY_SIZE(rnames); n++) {
>>>> + r = platform_get_resource_byname(pdev, rtype[n], rnames[n]);
>>>> + if (!r) {
>>>> + dev_err(&wmsm.core->dev,
>>>> + "Missing resource %s'\n", rnames[n]);
>>>> + ret = -ENOMEM;
>>>> + return ret;
>>>> + }
>>>> + res[n] = *r;
>>>> }
>>>> - memcpy(&res[2], rx_irq, sizeof(*rx_irq));
>>>>
>>>> - platform_device_add_resources(wmsm.core, res, ARRAY_SIZE(res));
>>>> + platform_device_add_resources(wmsm.core, res, n);
>>>>
>>>> ret = platform_device_add_data(wmsm.core, &wmsm.ctrl_ops,
>>>> sizeof(wmsm.ctrl_ops));
>>>> @@ -319,10 +326,6 @@ static int wcn36xx_msm_remove(struct platform_device *pdev)
>>>> return 0;
>>>> }
>>>>
>>>> -static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>> - { .compatible = "qcom,wcn36xx" },
>>>> - { }
>>>> -};
>>>> MODULE_DEVICE_TABLE(of, wcn36xx_msm_match_table);
>>>>
>>>> static struct platform_driver wcn36xx_msm_driver = {
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Eugene
>
>
>
> --
> Best regards,
> Eugene
^ permalink raw reply
* Re: [PATCH 7/9] rhashtable: Per bucket locks & deferred expansion/shrinking
From: Paul E. McKenney @ 2015-01-19 9:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Patrick McHardy, Thomas Graf, David Laight, davem@davemloft.net,
netdev@vger.kernel.org, herbert@gondor.apana.org.au,
edumazet@google.com, john.r.fastabend@intel.com,
josh@joshtriplett.org, netfilter-devel@vger.kernel.org
In-Reply-To: <20150116204644.GA2232@salvia>
On Fri, Jan 16, 2015 at 09:46:44PM +0100, Pablo Neira Ayuso wrote:
> On Fri, Jan 16, 2015 at 07:35:57PM +0000, Patrick McHardy wrote:
> > On 16.01, Thomas Graf wrote:
> > > On 01/16/15 at 06:36pm, Patrick McHardy wrote:
> > > > On 16.01, Thomas Graf wrote:
> > > > > On 01/16/15 at 04:43pm, David Laight wrote:
> > > > > > The walker is unlikely to see items that get inserted early in the hash
> > > > > > table even without a resize.
> > > > >
> > > > > I don't follow, you have to explain this statement.
> > > > >
> > > > > Walkers which don't want to see duplicates or miss entries should
> > > > > just take the mutex.
> > > >
> > > > Well, we do have a problem with interrupted dumps. As you know once
> > > > the netlink message buffer is full, we return to userspace and
> > > > continue dumping during the next read. Expanding obviously changes
> > > > the order since we rehash from bucket N to N and 2N, so this will
> > > > indeed cause duplicate (doesn't matter) and missed entries.
> > >
> > > Right,but that's a Netlink dump issue and not specific to rhashtable.
> >
> > Well, rhashtable (or generally resizing) will make it a lot worse.
> > Usually we at worst miss entries which were added during the dump,
> > which is made up by the notifications.
> >
> > With resizing we might miss anything, its completely undeterministic.
> >
> > > Putting the sequence number check in place should be sufficient
> > > for sets, right?
> >
> > I don't see how. The problem is that the ordering of the hash changes
> > and it will skip different entries than those that have already been
> > dumped.
>
> I think the generation counter should catch up this sort of problems.
> The resizing is triggered by a new/deletion element, which bumps it
> once the transaction is handled.
One unconventional way of handling this is to associate the scan with
a one-to-one resize operation. This can be implemented to have the
effect of taking a snapshot of the table.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 2/2] net wireless wcn36xx adapt wcnss platform to select module by DT
From: Eugene Krasnikov @ 2015-01-19 9:02 UTC (permalink / raw)
To: Andy Green; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAAfg0W4uPeSUxngVB5nU3y66JNDUA4TrZ_J2eALwcpKryKiMQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
The idea is definitely better than just checking for AC support. But
the question is whether platform/hardware/firmware support that?
2015-01-19 9:00 GMT+00:00 Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On 19 January 2015 at 16:49, Eugene Krasnikov <k.eugene.e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Have you tested this code on any device other than wcn3620?
>
> No... the only hardware I have is 3620. But the only code we're
> adding to mainline is the patch with the ops to get the chip type.
>
> The two-patch series just shows one way to set that (which will
> certainly work for all three defined compatible types, if it works for
> one). And this code cannot go upstream.
>
> So the only decision to make is around whether adding the platform op
> is a good way (or, eg, directly add DT support to wcn36xx and
> eliminate the 'device regeneration' part of the OOT -msm code).
>
> At the moment the detect code does not work for 3620, so something
> needs to be done.
>
> -Andy
>
>> 2015-01-19 8:44 GMT+00:00 Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>> On 19 January 2015 at 16:34, Eugene Krasnikov <k.eugene.e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> So how do we insmod wcn36xx_msm with a parameter specifying what type
>>>> of hardware do we use?
>>>
>>> The type of chip is defined in the DT "compatible" which also delivers
>>> the resource information.
>>>
>>> qcom,wcn36xx@0a000000 {
>>> compatible = "qcom,wcn3620";
>>> reg = <0x0a000000 0x280000>;
>>> reg-names = "wcnss_mmio";
>>>
>>> interrupts = <0 145 0 0 146 0>;
>>> interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq";
>>> ...
>>>
>>> This bit based on your code can't go in mainline until there's some
>>> kind of PIL support.
>>>
>>> So the only things we can discuss about it for mainline purpose is
>>> whether using a platform ops is a good way to interface to the
>>> mainline driver.
>>>
>>> If you're OK with that and you want a module parameter then this can
>>> grow a module parameter and prefer to deliver the chip type from that
>>> if given, without modifying the platform op interface.
>>>
>>> But with or without a module parameter this can't be upstreamed right
>>> now due to PIL.
>>>
>>> -Andy
>>>
>>>> 2015-01-18 5:16 GMT+00:00 Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>>>> Simplify the resource handling and use DT to indicate which chip type
>>>>> we are dealing with
>>>>>
>>>>> Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>> ---
>>>>> drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c | 101 ++++++++++++------------
>>>>> 1 file changed, 52 insertions(+), 49 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>> index f6f6c83..c9250e0 100644
>>>>> --- a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>> +++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>> @@ -42,7 +42,10 @@ struct wcn36xx_msm {
>>>>> struct completion smd_compl;
>>>>> smd_channel_t *smd_ch;
>>>>> struct pinctrl *pinctrl;
>>>>> -} wmsm;
>>>>> + enum wcn36xx_chip_type chip_type;
>>>>> +};
>>>>> +
>>>>> +static struct wcn36xx_msm wmsm;
>>>>>
>>>>> static int wcn36xx_msm_smsm_change_state(u32 clear_mask, u32 set_mask)
>>>>> {
>>>>> @@ -217,14 +220,47 @@ int wcn36xx_msm_powerup(const struct subsys_desc *desc)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>> + { .compatible = "qcom,wcn3660", .data = (void *)WCN36XX_CHIP_3660 },
>>>>> + { .compatible = "qcom,wcn3680", .data = (void *)WCN36XX_CHIP_3680 },
>>>>> + { .compatible = "qcom,wcn3620", .data = (void *)WCN36XX_CHIP_3620 },
>>>>> + { }
>>>>> +};
>>>>> +
>>>>> +static int wcn36xx_msm_get_chip_type(void)
>>>>> +{
>>>>> + return wmsm.chip_type;
>>>>> +}
>>>>> +
>>>>> +static struct wcn36xx_msm wmsm = {
>>>>> + .ctrl_ops = {
>>>>> + .open = wcn36xx_msm_smd_open,
>>>>> + .close = wcn36xx_msm_smd_close,
>>>>> + .tx = wcn36xx_msm_smd_send_and_wait,
>>>>> + .get_hw_mac = wcn36xx_msm_get_hw_mac,
>>>>> + .smsm_change_state = wcn36xx_msm_smsm_change_state,
>>>>> + .get_chip_type = wcn36xx_msm_get_chip_type,
>>>>> + },
>>>>> +};
>>>>> +
>>>>> static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>> {
>>>>> int ret;
>>>>> - struct resource *wcnss_memory;
>>>>> - struct resource *tx_irq;
>>>>> - struct resource *rx_irq;
>>>>> + const struct of_device_id *of_id;
>>>>> + struct resource *r;
>>>>> struct resource res[3];
>>>>> struct pinctrl_state *ps;
>>>>> + static const char const *rnames[] = {
>>>>> + "wcnss_mmio", "wcnss_wlantx_irq", "wcnss_wlanrx_irq" };
>>>>> + static const int rtype[] = {
>>>>> + IORESOURCE_MEM, IORESOURCE_IRQ, IORESOURCE_IRQ };
>>>>> + int n;
>>>>> +
>>>>> + of_id = of_match_node(wcn36xx_msm_match_table, pdev->dev.of_node);
>>>>> + if (!of_id)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + wmsm.chip_type = (enum wcn36xx_chip_type)of_id->data;
>>>>>
>>>>> wmsm.pinctrl = devm_pinctrl_get(&pdev->dev);
>>>>> if (IS_ERR_OR_NULL(wmsm.pinctrl))
>>>>> @@ -240,52 +276,23 @@ static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>>
>>>>> if (IS_ERR_OR_NULL(pil))
>>>>> pil = subsystem_get("wcnss");
>>>>> - if (IS_ERR_OR_NULL(pil))
>>>>> - return PTR_ERR(pil);
>>>>> + if (IS_ERR_OR_NULL(pil))
>>>>> + return PTR_ERR(pil);
>>>>>
>>>>> wmsm.core = platform_device_alloc("wcn36xx", -1);
>>>>>
>>>>> - //dev_err(&pdev->dev, "%s starting\n", __func__);
>>>>> -
>>>>> - memset(res, 0x00, sizeof(res));
>>>>> - wmsm.ctrl_ops.open = wcn36xx_msm_smd_open;
>>>>> - wmsm.ctrl_ops.close = wcn36xx_msm_smd_close;
>>>>> - wmsm.ctrl_ops.tx = wcn36xx_msm_smd_send_and_wait;
>>>>> - wmsm.ctrl_ops.get_hw_mac = wcn36xx_msm_get_hw_mac;
>>>>> - wmsm.ctrl_ops.smsm_change_state = wcn36xx_msm_smsm_change_state;
>>>>> - wcnss_memory =
>>>>> - platform_get_resource_byname(pdev,
>>>>> - IORESOURCE_MEM,
>>>>> - "wcnss_mmio");
>>>>> - if (wcnss_memory == NULL) {
>>>>> - dev_err(&wmsm.core->dev,
>>>>> - "Failed to get wcnss wlan memory map.\n");
>>>>> - ret = -ENOMEM;
>>>>> - return ret;
>>>>> - }
>>>>> - memcpy(&res[0], wcnss_memory, sizeof(*wcnss_memory));
>>>>> -
>>>>> - tx_irq = platform_get_resource_byname(pdev,
>>>>> - IORESOURCE_IRQ,
>>>>> - "wcnss_wlantx_irq");
>>>>> - if (tx_irq == NULL) {
>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss tx_irq");
>>>>> - ret = -ENOMEM;
>>>>> - return ret;
>>>>> - }
>>>>> - memcpy(&res[1], tx_irq, sizeof(*tx_irq));
>>>>> -
>>>>> - rx_irq = platform_get_resource_byname(pdev,
>>>>> - IORESOURCE_IRQ,
>>>>> - "wcnss_wlanrx_irq");
>>>>> - if (rx_irq == NULL) {
>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss rx_irq");
>>>>> - ret = -ENOMEM;
>>>>> - return ret;
>>>>> + for (n = 0; n < ARRAY_SIZE(rnames); n++) {
>>>>> + r = platform_get_resource_byname(pdev, rtype[n], rnames[n]);
>>>>> + if (!r) {
>>>>> + dev_err(&wmsm.core->dev,
>>>>> + "Missing resource %s'\n", rnames[n]);
>>>>> + ret = -ENOMEM;
>>>>> + return ret;
>>>>> + }
>>>>> + res[n] = *r;
>>>>> }
>>>>> - memcpy(&res[2], rx_irq, sizeof(*rx_irq));
>>>>>
>>>>> - platform_device_add_resources(wmsm.core, res, ARRAY_SIZE(res));
>>>>> + platform_device_add_resources(wmsm.core, res, n);
>>>>>
>>>>> ret = platform_device_add_data(wmsm.core, &wmsm.ctrl_ops,
>>>>> sizeof(wmsm.ctrl_ops));
>>>>> @@ -319,10 +326,6 @@ static int wcn36xx_msm_remove(struct platform_device *pdev)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> -static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>> - { .compatible = "qcom,wcn36xx" },
>>>>> - { }
>>>>> -};
>>>>> MODULE_DEVICE_TABLE(of, wcn36xx_msm_match_table);
>>>>>
>>>>> static struct platform_driver wcn36xx_msm_driver = {
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Eugene
>>
>>
>>
>> --
>> Best regards,
>> Eugene
--
Best regards,
Eugene
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH net 0/2] r8152: couldn't read OCP_SRAM_DATA
From: Hayes Wang @ 2015-01-19 9:02 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Read OCP_SRAM_DATA would read additional bytes and may let
the hw abnormal.
Hayes Wang (2):
r8152: remove generic_ocp_read before writing
r8152: remove sram_read
drivers/net/usb/r8152.c | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net-next] tipc: ratelimit network event traces
From: erik.hugne @ 2015-01-19 9:02 UTC (permalink / raw)
To: richard.alpe, ying.xue, jon.maloy, netdev; +Cc: tipc-discussion
From: Erik Hugne <erik.hugne@ericsson.com>
If a large number of namespaces is spawned on a node and TIPC is
enabled in each of these, the excessive printk tracing of network
events will cause the system to grind down to a near halt.
We fix this by adding ratelimiting to the info/warning logs
regarding link state and node availability.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/link.c | 21 +++++++++++----------
net/tipc/node.c | 24 +++++++++++++-----------
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 193bc15..bedb590 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -538,8 +538,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv / 4);
break;
case RESET_MSG:
- pr_info("%s<%s>, requested by peer\n", link_rst_msg,
- l_ptr->name);
+ pr_info_ratelimited("%s<%s>, requested by peer\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_RESET;
l_ptr->fsm_msg_cnt = 0;
@@ -549,7 +549,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv);
break;
default:
- pr_err("%s%u in WW state\n", link_unk_evt, event);
+ pr_err_ratelimited("%s%u in WW state\n", link_unk_evt,
+ event);
}
break;
case WORKING_UNKNOWN:
@@ -561,8 +562,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
link_set_timer(l_ptr, cont_intv);
break;
case RESET_MSG:
- pr_info("%s<%s>, requested by peer while probing\n",
- link_rst_msg, l_ptr->name);
+ pr_info_ratelimited("%s<%s>, requested by peer while probing\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_RESET;
l_ptr->fsm_msg_cnt = 0;
@@ -588,8 +589,8 @@ static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
l_ptr->fsm_msg_cnt++;
link_set_timer(l_ptr, cont_intv / 4);
} else { /* Link has failed */
- pr_warn("%s<%s>, peer not responding\n",
- link_rst_msg, l_ptr->name);
+ pr_warn_ratelimited("%s<%s>, peer not responding\n",
+ link_rst_msg, l_ptr->name);
tipc_link_reset(l_ptr);
l_ptr->state = RESET_UNKNOWN;
l_ptr->fsm_msg_cnt = 0;
@@ -1568,9 +1569,9 @@ static void tipc_link_proto_rcv(struct net *net, struct tipc_link *l_ptr,
if (msg_linkprio(msg) &&
(msg_linkprio(msg) != l_ptr->priority)) {
- pr_warn("%s<%s>, priority change %u->%u\n",
- link_rst_msg, l_ptr->name, l_ptr->priority,
- msg_linkprio(msg));
+ pr_warn_ratelimited("%s<%s>, priority change %u->%u\n",
+ link_rst_msg, l_ptr->name,
+ l_ptr->priority, msg_linkprio(msg));
l_ptr->priority = msg_linkprio(msg);
tipc_link_reset(l_ptr); /* Enforce change to take effect */
break;
diff --git a/net/tipc/node.c b/net/tipc/node.c
index b1eb092..01a03a7 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -230,8 +230,8 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
n_ptr->action_flags |= TIPC_NOTIFY_LINK_UP;
n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
- pr_info("Established link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_info_ratelimited("Established link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
if (!active[0]) {
active[0] = active[1] = l_ptr;
@@ -239,7 +239,8 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
goto exit;
}
if (l_ptr->priority < active[0]->priority) {
- pr_info("New link <%s> becomes standby\n", l_ptr->name);
+ pr_info_ratelimited("New link <%s> becomes standby\n",
+ l_ptr->name);
goto exit;
}
tipc_link_dup_queue_xmit(active[0], l_ptr);
@@ -247,9 +248,10 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
active[0] = l_ptr;
goto exit;
}
- pr_info("Old link <%s> becomes standby\n", active[0]->name);
+ pr_info_ratelimited("Old link <%s> becomes standby\n", active[0]->name);
if (active[1] != active[0])
- pr_info("Old link <%s> becomes standby\n", active[1]->name);
+ pr_info_ratelimited("Old link <%s> becomes standby\n",
+ active[1]->name);
active[0] = active[1] = l_ptr;
exit:
/* Leave room for changeover header when returning 'mtu' to users: */
@@ -297,12 +299,12 @@ void tipc_node_link_down(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
if (!tipc_link_is_active(l_ptr)) {
- pr_info("Lost standby link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_info_ratelimited("Lost standby link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
return;
}
- pr_info("Lost link <%s> on network plane %c\n",
- l_ptr->name, l_ptr->net_plane);
+ pr_info_ratelimited("Lost link <%s> on network plane %c\n",
+ l_ptr->name, l_ptr->net_plane);
active = &n_ptr->active_links[0];
if (active[0] == l_ptr)
@@ -380,8 +382,8 @@ static void node_lost_contact(struct tipc_node *n_ptr)
char addr_string[16];
u32 i;
- pr_info("Lost contact with %s\n",
- tipc_addr_string_fill(addr_string, n_ptr->addr));
+ pr_info_ratelimited("Lost contact with %s\n",
+ tipc_addr_string_fill(addr_string, n_ptr->addr));
/* Flush broadcast link info associated with lost node */
if (n_ptr->bclink.recv_permitted) {
--
2.1.3
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
^ permalink raw reply related
* [PATCH net 1/2] r8152: remove generic_ocp_read before writing
From: Hayes Wang @ 2015-01-19 9:02 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-126-Taiwan-albertk@realtek.com>
For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read()
which is used to read the whole 4 byte data, keep the unchanged bytes,
and modify the expected bytes. However, the "byen" could be used to
determine which bytes of the 4 bytes to write, so the action could be
removed.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 57ec23e..0aa83fb 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -833,9 +833,6 @@ static void ocp_write_word(struct r8152 *tp, u16 type, u16 index, u32 data)
index &= ~3;
}
- generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
-
- data |= __le32_to_cpu(tmp) & ~mask;
tmp = __cpu_to_le32(data);
generic_ocp_write(tp, index, byen, sizeof(tmp), &tmp, type);
@@ -874,9 +871,6 @@ static void ocp_write_byte(struct r8152 *tp, u16 type, u16 index, u32 data)
index &= ~3;
}
- generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
-
- data |= __le32_to_cpu(tmp) & ~mask;
tmp = __cpu_to_le32(data);
generic_ocp_write(tp, index, byen, sizeof(tmp), &tmp, type);
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/2] r8152: remove sram_read
From: Hayes Wang @ 2015-01-19 9:02 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-126-Taiwan-albertk@realtek.com>
Read OCP register 0xa43a~0xa43b would clear some flags which the hw
would use, and it may let the device lost. However, the unit of
reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling
sram_read() to read OCP_SRAM_DATA.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0aa83fb..bf405f1 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -920,12 +920,6 @@ static void sram_write(struct r8152 *tp, u16 addr, u16 data)
ocp_reg_write(tp, OCP_SRAM_DATA, data);
}
-static u16 sram_read(struct r8152 *tp, u16 addr)
-{
- ocp_reg_write(tp, OCP_SRAM_ADDR, addr);
- return ocp_reg_read(tp, OCP_SRAM_DATA);
-}
-
static int read_mii_word(struct net_device *netdev, int phy_id, int reg)
{
struct r8152 *tp = netdev_priv(netdev);
@@ -2512,24 +2506,18 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
data = ocp_reg_read(tp, OCP_POWER_CFG);
data |= EN_10M_PLLOFF;
ocp_reg_write(tp, OCP_POWER_CFG, data);
- data = sram_read(tp, SRAM_IMPEDANCE);
- data &= ~RX_DRIVING_MASK;
- sram_write(tp, SRAM_IMPEDANCE, data);
+ sram_write(tp, SRAM_IMPEDANCE, 0x0b13);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR);
ocp_data |= PFM_PWM_SWITCH;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR, ocp_data);
- data = sram_read(tp, SRAM_LPF_CFG);
- data |= LPF_AUTO_TUNE;
- sram_write(tp, SRAM_LPF_CFG, data);
+ /* Enable LPF corner auto tune */
+ sram_write(tp, SRAM_LPF_CFG, 0xf70f);
- data = sram_read(tp, SRAM_10M_AMP1);
- data |= GDAC_IB_UPALL;
- sram_write(tp, SRAM_10M_AMP1, data);
- data = sram_read(tp, SRAM_10M_AMP2);
- data |= AMP_DN;
- sram_write(tp, SRAM_10M_AMP2, data);
+ /* Adjust 10M Amplitude */
+ sram_write(tp, SRAM_10M_AMP1, 0x00af);
+ sram_write(tp, SRAM_10M_AMP2, 0x0208);
set_bit(PHY_RESET, &tp->flags);
}
--
2.1.0
^ permalink raw reply related
* Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: Scott Feldman @ 2015-01-19 9:31 UTC (permalink / raw)
To: David Miller; +Cc: Marcel Holtmann, Netdev, Johannes Berg, Tom Gundersen
In-Reply-To: <20150118.233722.226468667930444145.davem@davemloft.net>
On Sun, Jan 18, 2015 at 8:37 PM, David Miller <davem@davemloft.net> wrote:
>
> ====================
> [PATCH] netlink: Fix bugs in nlmsg_end() conversions.
>
> Commit 053c095a82cf ("netlink: make nlmsg_end() and genlmsg_end()
> void") didn't catch all of the cases where callers were breaking out
> on the return value being equal to zero, which they no longer should
> when zero means success.
>
> Fix all such cases.
>
> Reported-by: Marcel Holtmann <marcel@holtmann.org>
> Reported-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes my tests, so I'm happy. Thank you.
Acked-by: Scott Feldman <sfeldma@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] net wireless wcn36xx adapt wcnss platform to select module by DT
From: Andy Green @ 2015-01-19 9:34 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAFSJ42bK1WbCCBhsuKbOjh0TR7y3GwMibwkRKgiPRY=PW519Cw@mail.gmail.com>
On 19 January 2015 at 17:02, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
> The idea is definitely better than just checking for AC support. But
> the question is whether platform/hardware/firmware support that?
Sorry I don't understand what might be unsupported.
- We don't ask the firmware, we tell the driver what chip it is from
the outside. There's nothing for the firmware to support.
- Platform supports a set of ops via platform_data already. This
just adds one op to get the chip type from the platform code.
- What can't the hardware support? The hardware physically is a
3620, 3660 or 3680. We just tell the driver what it is when we
instantiate the device. We don't ask anything of the hardware.
I expected to have a debate about whether to move the dt support to
wcn36xx directly which is also reasonable... there's no question
adding an op will work or not, it will work for all cases like this.
But it also implies there must be the "device faking" business in -msm
code, one day that will also go upstream and then it might be
considered a bit strange.
I did it like this now because it's the minimum change from the
current situation.
-Andy
> 2015-01-19 9:00 GMT+00:00 Andy Green <andy.green@linaro.org>:
>> On 19 January 2015 at 16:49, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>>> Have you tested this code on any device other than wcn3620?
>>
>> No... the only hardware I have is 3620. But the only code we're
>> adding to mainline is the patch with the ops to get the chip type.
>>
>> The two-patch series just shows one way to set that (which will
>> certainly work for all three defined compatible types, if it works for
>> one). And this code cannot go upstream.
>>
>> So the only decision to make is around whether adding the platform op
>> is a good way (or, eg, directly add DT support to wcn36xx and
>> eliminate the 'device regeneration' part of the OOT -msm code).
>>
>> At the moment the detect code does not work for 3620, so something
>> needs to be done.
>>
>> -Andy
>>
>>> 2015-01-19 8:44 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>>> On 19 January 2015 at 16:34, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
>>>>
>>>>> So how do we insmod wcn36xx_msm with a parameter specifying what type
>>>>> of hardware do we use?
>>>>
>>>> The type of chip is defined in the DT "compatible" which also delivers
>>>> the resource information.
>>>>
>>>> qcom,wcn36xx@0a000000 {
>>>> compatible = "qcom,wcn3620";
>>>> reg = <0x0a000000 0x280000>;
>>>> reg-names = "wcnss_mmio";
>>>>
>>>> interrupts = <0 145 0 0 146 0>;
>>>> interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq";
>>>> ...
>>>>
>>>> This bit based on your code can't go in mainline until there's some
>>>> kind of PIL support.
>>>>
>>>> So the only things we can discuss about it for mainline purpose is
>>>> whether using a platform ops is a good way to interface to the
>>>> mainline driver.
>>>>
>>>> If you're OK with that and you want a module parameter then this can
>>>> grow a module parameter and prefer to deliver the chip type from that
>>>> if given, without modifying the platform op interface.
>>>>
>>>> But with or without a module parameter this can't be upstreamed right
>>>> now due to PIL.
>>>>
>>>> -Andy
>>>>
>>>>> 2015-01-18 5:16 GMT+00:00 Andy Green <andy.green@linaro.org>:
>>>>>> Simplify the resource handling and use DT to indicate which chip type
>>>>>> we are dealing with
>>>>>>
>>>>>> Signed-off-by: Andy Green <andy.green@linaro.org>
>>>>>> ---
>>>>>> drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c | 101 ++++++++++++------------
>>>>>> 1 file changed, 52 insertions(+), 49 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>> index f6f6c83..c9250e0 100644
>>>>>> --- a/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>> +++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx-msm.c
>>>>>> @@ -42,7 +42,10 @@ struct wcn36xx_msm {
>>>>>> struct completion smd_compl;
>>>>>> smd_channel_t *smd_ch;
>>>>>> struct pinctrl *pinctrl;
>>>>>> -} wmsm;
>>>>>> + enum wcn36xx_chip_type chip_type;
>>>>>> +};
>>>>>> +
>>>>>> +static struct wcn36xx_msm wmsm;
>>>>>>
>>>>>> static int wcn36xx_msm_smsm_change_state(u32 clear_mask, u32 set_mask)
>>>>>> {
>>>>>> @@ -217,14 +220,47 @@ int wcn36xx_msm_powerup(const struct subsys_desc *desc)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>>> + { .compatible = "qcom,wcn3660", .data = (void *)WCN36XX_CHIP_3660 },
>>>>>> + { .compatible = "qcom,wcn3680", .data = (void *)WCN36XX_CHIP_3680 },
>>>>>> + { .compatible = "qcom,wcn3620", .data = (void *)WCN36XX_CHIP_3620 },
>>>>>> + { }
>>>>>> +};
>>>>>> +
>>>>>> +static int wcn36xx_msm_get_chip_type(void)
>>>>>> +{
>>>>>> + return wmsm.chip_type;
>>>>>> +}
>>>>>> +
>>>>>> +static struct wcn36xx_msm wmsm = {
>>>>>> + .ctrl_ops = {
>>>>>> + .open = wcn36xx_msm_smd_open,
>>>>>> + .close = wcn36xx_msm_smd_close,
>>>>>> + .tx = wcn36xx_msm_smd_send_and_wait,
>>>>>> + .get_hw_mac = wcn36xx_msm_get_hw_mac,
>>>>>> + .smsm_change_state = wcn36xx_msm_smsm_change_state,
>>>>>> + .get_chip_type = wcn36xx_msm_get_chip_type,
>>>>>> + },
>>>>>> +};
>>>>>> +
>>>>>> static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>>> {
>>>>>> int ret;
>>>>>> - struct resource *wcnss_memory;
>>>>>> - struct resource *tx_irq;
>>>>>> - struct resource *rx_irq;
>>>>>> + const struct of_device_id *of_id;
>>>>>> + struct resource *r;
>>>>>> struct resource res[3];
>>>>>> struct pinctrl_state *ps;
>>>>>> + static const char const *rnames[] = {
>>>>>> + "wcnss_mmio", "wcnss_wlantx_irq", "wcnss_wlanrx_irq" };
>>>>>> + static const int rtype[] = {
>>>>>> + IORESOURCE_MEM, IORESOURCE_IRQ, IORESOURCE_IRQ };
>>>>>> + int n;
>>>>>> +
>>>>>> + of_id = of_match_node(wcn36xx_msm_match_table, pdev->dev.of_node);
>>>>>> + if (!of_id)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + wmsm.chip_type = (enum wcn36xx_chip_type)of_id->data;
>>>>>>
>>>>>> wmsm.pinctrl = devm_pinctrl_get(&pdev->dev);
>>>>>> if (IS_ERR_OR_NULL(wmsm.pinctrl))
>>>>>> @@ -240,52 +276,23 @@ static int wcn36xx_msm_probe(struct platform_device *pdev)
>>>>>>
>>>>>> if (IS_ERR_OR_NULL(pil))
>>>>>> pil = subsystem_get("wcnss");
>>>>>> - if (IS_ERR_OR_NULL(pil))
>>>>>> - return PTR_ERR(pil);
>>>>>> + if (IS_ERR_OR_NULL(pil))
>>>>>> + return PTR_ERR(pil);
>>>>>>
>>>>>> wmsm.core = platform_device_alloc("wcn36xx", -1);
>>>>>>
>>>>>> - //dev_err(&pdev->dev, "%s starting\n", __func__);
>>>>>> -
>>>>>> - memset(res, 0x00, sizeof(res));
>>>>>> - wmsm.ctrl_ops.open = wcn36xx_msm_smd_open;
>>>>>> - wmsm.ctrl_ops.close = wcn36xx_msm_smd_close;
>>>>>> - wmsm.ctrl_ops.tx = wcn36xx_msm_smd_send_and_wait;
>>>>>> - wmsm.ctrl_ops.get_hw_mac = wcn36xx_msm_get_hw_mac;
>>>>>> - wmsm.ctrl_ops.smsm_change_state = wcn36xx_msm_smsm_change_state;
>>>>>> - wcnss_memory =
>>>>>> - platform_get_resource_byname(pdev,
>>>>>> - IORESOURCE_MEM,
>>>>>> - "wcnss_mmio");
>>>>>> - if (wcnss_memory == NULL) {
>>>>>> - dev_err(&wmsm.core->dev,
>>>>>> - "Failed to get wcnss wlan memory map.\n");
>>>>>> - ret = -ENOMEM;
>>>>>> - return ret;
>>>>>> - }
>>>>>> - memcpy(&res[0], wcnss_memory, sizeof(*wcnss_memory));
>>>>>> -
>>>>>> - tx_irq = platform_get_resource_byname(pdev,
>>>>>> - IORESOURCE_IRQ,
>>>>>> - "wcnss_wlantx_irq");
>>>>>> - if (tx_irq == NULL) {
>>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss tx_irq");
>>>>>> - ret = -ENOMEM;
>>>>>> - return ret;
>>>>>> - }
>>>>>> - memcpy(&res[1], tx_irq, sizeof(*tx_irq));
>>>>>> -
>>>>>> - rx_irq = platform_get_resource_byname(pdev,
>>>>>> - IORESOURCE_IRQ,
>>>>>> - "wcnss_wlanrx_irq");
>>>>>> - if (rx_irq == NULL) {
>>>>>> - dev_err(&wmsm.core->dev, "Failed to get wcnss rx_irq");
>>>>>> - ret = -ENOMEM;
>>>>>> - return ret;
>>>>>> + for (n = 0; n < ARRAY_SIZE(rnames); n++) {
>>>>>> + r = platform_get_resource_byname(pdev, rtype[n], rnames[n]);
>>>>>> + if (!r) {
>>>>>> + dev_err(&wmsm.core->dev,
>>>>>> + "Missing resource %s'\n", rnames[n]);
>>>>>> + ret = -ENOMEM;
>>>>>> + return ret;
>>>>>> + }
>>>>>> + res[n] = *r;
>>>>>> }
>>>>>> - memcpy(&res[2], rx_irq, sizeof(*rx_irq));
>>>>>>
>>>>>> - platform_device_add_resources(wmsm.core, res, ARRAY_SIZE(res));
>>>>>> + platform_device_add_resources(wmsm.core, res, n);
>>>>>>
>>>>>> ret = platform_device_add_data(wmsm.core, &wmsm.ctrl_ops,
>>>>>> sizeof(wmsm.ctrl_ops));
>>>>>> @@ -319,10 +326,6 @@ static int wcn36xx_msm_remove(struct platform_device *pdev)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> -static const struct of_device_id wcn36xx_msm_match_table[] = {
>>>>>> - { .compatible = "qcom,wcn36xx" },
>>>>>> - { }
>>>>>> -};
>>>>>> MODULE_DEVICE_TABLE(of, wcn36xx_msm_match_table);
>>>>>>
>>>>>> static struct platform_driver wcn36xx_msm_driver = {
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Eugene
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Eugene
>
>
>
> --
> Best regards,
> Eugene
^ permalink raw reply
* [PATCH net-next 1/1] ARM: dts: imx6sx: correct i.MX6sx sdb board enet phy address
From: Fugang Duan @ 2015-01-19 9:38 UTC (permalink / raw)
To: shawn.guo, davem; +Cc: netdev, s.hauer, b38611, stefan, linux-arm-kernel
The commit (3d125f9c91c5) cause i.MX6SX sdb enet cannot work. The cause is
the commit add mdio node with un-correct phy address.
The patch just correct i.MX6sx sdb board enet phy address.
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
arch/arm/boot/dts/imx6sx-sdb.dts | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 8c1febd..9db123f 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -167,11 +167,11 @@
#size-cells = <0>;
ethphy1: ethernet-phy@0 {
- reg = <0>;
+ reg = <1>;
};
ethphy2: ethernet-phy@1 {
- reg = <1>;
+ reg = <2>;
};
};
};
--
1.7.8
^ permalink raw reply related
* RE: [PATCH 7/9] rhashtable: Per bucket locks & deferred expansion/shrinking
From: David Laight @ 2015-01-19 9:45 UTC (permalink / raw)
To: 'Thomas Graf', Patrick McHardy
Cc: davem@davemloft.net, netdev@vger.kernel.org,
herbert@gondor.apana.org.au, paulmck@linux.vnet.ibm.com,
edumazet@google.com, john.r.fastabend@intel.com,
josh@joshtriplett.org, netfilter-devel@vger.kernel.org
In-Reply-To: <20150116213605.GE20315@casper.infradead.org>
From: Thomas Graf
> On 01/16/15 at 07:35pm, Patrick McHardy wrote:
> > On 16.01, Thomas Graf wrote:
> > > Right,but that's a Netlink dump issue and not specific to rhashtable.
> >
> > Well, rhashtable (or generally resizing) will make it a lot worse.
> > Usually we at worst miss entries which were added during the dump,
> > which is made up by the notifications.
> >
> > With resizing we might miss anything, its completely undeterministic.
> >
> > > Putting the sequence number check in place should be sufficient
> > > for sets, right?
> >
> > I don't see how. The problem is that the ordering of the hash changes
> > and it will skip different entries than those that have already been
> > dumped.
>
> Since an resize can only be triggered through insert/remove you
> simply bump a sequence number when you insert/remove and have
> userspace restart the dump when NLM_F_DUMP_INTR is set.
You could suppress 'shrink' while a userspace dump is in progress
and force userspace to restart on 'grow'.
The suppress does rather require that you know when any userspace 'walk'
gives up. OTOH it should be possible to defer the 'shrink' everytime
a walk reads some more of the data.
David
^ permalink raw reply
* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Masami Hiramatsu @ 2015-01-19 9:52 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Daniel Borkmann, Hannes Frederic Sowa, Brendan Gregg,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1421381770-4866-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
(2015/01/16 13:16), Alexei Starovoitov wrote:
> Hi Ingo, Steven,
>
> This patch set is based on tip/master.
> It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
>
> Mechanism of attaching:
> - load program via bpf() syscall and receive program_fd
> - event_fd = open("/sys/kernel/debug/tracing/events/.../filter")
> - write 'bpf-123' to event_fd where 123 is program_fd
> - program will be attached to particular event and event automatically enabled
> - close(event_fd) will detach bpf program from event and event disabled
>
> Program attach point and input arguments:
> - programs attached to kprobes receive 'struct pt_regs *' as an input.
> See tracex4_kern.c that demonstrates how users can write a C program like:
> SEC("events/kprobes/sys_write")
> int bpf_prog4(struct pt_regs *regs)
> {
> long write_size = regs->dx;
> // here user need to know the proto of sys_write() from kernel
> // sources and x64 calling convention to know that register $rdx
> // contains 3rd argument to sys_write() which is 'size_t count'
>
> it's obviously architecture dependent, but allows building sophisticated
> user tools on top, that can see from debug info of vmlinux which variables
> are in which registers or stack locations and fetch it from there.
> 'perf probe' can potentialy use this hook to generate programs in user space
> and insert them instead of letting kernel parse string during kprobe creation.
Actually, this program just shows raw pt_regs for handlers, but I guess it is also
possible to pass event arguments from perf probe which given by user and perf-probe.
If we can write the script as
int bpf_prog4(s64 write_size)
{
...
}
This will be much easier to play with.
> - programs attached to tracepoints and syscalls receive 'struct bpf_context *':
> u64 arg1, arg2, ..., arg6;
> for syscalls they match syscall arguments.
> for tracepoints these args match arguments passed to tracepoint.
> For example:
> trace_sched_migrate_task(p, new_cpu); from sched/core.c
> arg1 <- p which is 'struct task_struct *'
> arg2 <- new_cpu which is 'unsigned int'
> arg3..arg6 = 0
> the program can use bpf_fetch_u8/16/32/64/ptr() helpers to walk 'task_struct'
> or any other kernel data structures.
> These helpers are using probe_kernel_read() similar to 'perf probe' which is
> not 100% safe in both cases, but good enough.
> To access task_struct's pid inside 'sched_migrate_task' tracepoint
> the program can do:
> struct task_struct *task = (struct task_struct *)ctx->arg1;
> u32 pid = bpf_fetch_u32(&task->pid);
> Since struct layout is kernel configuration specific such programs are not
> portable and require access to kernel headers to be compiled,
> but in this case we don't need debug info.
> llvm with bpf backend will statically compute task->pid offset as a constant
> based on kernel headers only.
> The example of this arbitrary pointer walking is tracex1_kern.c
> which does skb->dev->name == "lo" filtering.
At least I would like to see this way on kprobes event too, since it should be
treated as a traceevent.
> In all cases the programs are called before trace buffer is allocated to
> minimize the overhead, since we want to filter huge number of events, but
> buffer alloc/free and argument copy for every event is too costly.
> Theoretically we can invoke programs after buffer is allocated, but it
> doesn't seem needed, since above approach is faster and achieves the same.
>
> Note, tracepoint/syscall and kprobe programs are two different types:
> BPF_PROG_TYPE_TRACING_FILTER and BPF_PROG_TYPE_KPROBE_FILTER,
> since they expect different input.
> Both use the same set of helper functions:
> - map access (lookup/update/delete)
> - fetch (probe_kernel_read wrappers)
> - memcmp (probe_kernel_read + memcmp)
> - dump_stack
> - trace_printk
> The last two are mainly to debug the programs and to print data for user
> space consumptions.
>
> Portability:
> - kprobe programs are architecture dependent and need user scripting
> language like ktap/stap/dtrace/perf that will dynamically generate
> them based on debug info in vmlinux
If we can use kprobe event as a normal traceevent, user scripting can be
architecture independent too. Only perf-probe fills the gap. All other
userspace tools can collaborate with perf-probe to setup the events.
If so, we can avoid redundant works on debuginfo. That is my point.
Thank you,
> - tracepoint programs are architecture independent, but if arbitrary pointer
> walking (with fetch() helpers) is used, they need data struct layout to match.
> Debug info is not necessary
> - for networking use case we need to access 'struct sk_buff' fields in portable
> way (user space needs to fetch packet length without knowing skb->len offset),
> so for some frequently used data structures we will add helper functions
> or pseudo instructions to access them. I've hacked few ways specifically
> for skb, but abandoned them in favor of more generic type/field infra.
> That work is still wip. Not part of this set.
> Once it's ready tracepoint programs that access common data structs
> will be kernel independent.
>
> Program return value:
> - programs return 0 to discard an event
> - and return non-zero to proceed with event (allocate trace buffer, copy
> arguments there and print it eventually in trace_pipe in traditional way)
>
> Examples:
> - dropmon.c - simple kfree_skb() accounting in eBPF assembler, similar
> to dropmon tool
> - tracex1_kern.c - does net/netif_receive_skb event filtering
> for dev->skb->name == "lo" condition
> - tracex2_kern.c - same kfree_skb() accounting like dropmon, but now in C
> plus computes histogram of all write sizes from sys_write syscall
> and prints the histogram in userspace
> - tracex3_kern.c - most sophisticated example that computes IO latency
> between block/block_rq_issue and block/block_rq_complete events
> and prints 'heatmap' using gray shades of text terminal.
> Useful to analyze disk performance.
> - tracex4_kern.c - computes histogram of write sizes from sys_write syscall
> using kprobe mechanism instead of syscall. Since kprobe is optimized into
> ftrace the overhead of instrumentation is smaller than in example 2.
>
> The user space tools like ktap/dtrace/systemptap/perf that has access
> to debug info would probably want to use kprobe attachment point, since kprobe
> can be inserted anywhere and all registers are avaiable in the program.
> tracepoint attachments are useful without debug info, so standalone tools
> like iosnoop will use them.
>
> The main difference vs existing perf_probe/ftrace infra is in kernel aggregation
> and conditional walking of arbitrary data structures.
>
> Thanks!
>
> Alexei Starovoitov (9):
> tracing: attach eBPF programs to tracepoints and syscalls
> tracing: allow eBPF programs to call bpf_printk()
> tracing: allow eBPF programs to call ktime_get_ns()
> samples: bpf: simple tracing example in eBPF assembler
> samples: bpf: simple tracing example in C
> samples: bpf: counting example for kfree_skb tracepoint and write
> syscall
> samples: bpf: IO latency analysis (iosnoop/heatmap)
> tracing: attach eBPF programs to kprobe/kretprobe
> samples: bpf: simple kprobe example
>
> include/linux/ftrace_event.h | 6 +
> include/trace/bpf_trace.h | 25 ++++
> include/trace/ftrace.h | 30 +++++
> include/uapi/linux/bpf.h | 11 ++
> kernel/trace/Kconfig | 1 +
> kernel/trace/Makefile | 1 +
> kernel/trace/bpf_trace.c | 250 ++++++++++++++++++++++++++++++++++++
> kernel/trace/trace.h | 3 +
> kernel/trace/trace_events.c | 41 +++++-
> kernel/trace/trace_events_filter.c | 80 +++++++++++-
> kernel/trace/trace_kprobe.c | 11 +-
> kernel/trace/trace_syscalls.c | 31 +++++
> samples/bpf/Makefile | 18 +++
> samples/bpf/bpf_helpers.h | 18 +++
> samples/bpf/bpf_load.c | 62 ++++++++-
> samples/bpf/bpf_load.h | 3 +
> samples/bpf/dropmon.c | 129 +++++++++++++++++++
> samples/bpf/tracex1_kern.c | 28 ++++
> samples/bpf/tracex1_user.c | 24 ++++
> samples/bpf/tracex2_kern.c | 71 ++++++++++
> samples/bpf/tracex2_user.c | 95 ++++++++++++++
> samples/bpf/tracex3_kern.c | 96 ++++++++++++++
> samples/bpf/tracex3_user.c | 146 +++++++++++++++++++++
> samples/bpf/tracex4_kern.c | 36 ++++++
> samples/bpf/tracex4_user.c | 83 ++++++++++++
> 25 files changed, 1290 insertions(+), 9 deletions(-)
> create mode 100644 include/trace/bpf_trace.h
> create mode 100644 kernel/trace/bpf_trace.c
> create mode 100644 samples/bpf/dropmon.c
> create mode 100644 samples/bpf/tracex1_kern.c
> create mode 100644 samples/bpf/tracex1_user.c
> create mode 100644 samples/bpf/tracex2_kern.c
> create mode 100644 samples/bpf/tracex2_user.c
> create mode 100644 samples/bpf/tracex3_kern.c
> create mode 100644 samples/bpf/tracex3_user.c
> create mode 100644 samples/bpf/tracex4_kern.c
> create mode 100644 samples/bpf/tracex4_user.c
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH net-next 1/1] ARM: dts: imx6sx: correct i.MX6sx sdb board enet phy address
From: Stefan Agner @ 2015-01-19 10:04 UTC (permalink / raw)
To: Fugang Duan; +Cc: shawn.guo, davem, netdev, linux-arm-kernel, s.hauer
In-Reply-To: <1421660282-29494-1-git-send-email-b38611@freescale.com>
On 2015-01-19 10:38, Fugang Duan wrote:
> The commit (3d125f9c91c5) cause i.MX6SX sdb enet cannot work. The cause is
> the commit add mdio node with un-correct phy address.
Sorry about that, somehow I did not take in consideration that that
could be different on the SoloX board.. Just checked again on Vybrid, it
is correct there, the dual PHY DP83849I addresses the two ports with 0
and 1 respectively.
>
> The patch just correct i.MX6sx sdb board enet phy address.
Acked-by: Stefan Agner <stefan@agner.ch>
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
> ---
> arch/arm/boot/dts/imx6sx-sdb.dts | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
> index 8c1febd..9db123f 100644
> --- a/arch/arm/boot/dts/imx6sx-sdb.dts
> +++ b/arch/arm/boot/dts/imx6sx-sdb.dts
> @@ -167,11 +167,11 @@
> #size-cells = <0>;
>
> ethphy1: ethernet-phy@0 {
> - reg = <0>;
> + reg = <1>;
> };
>
> ethphy2: ethernet-phy@1 {
> - reg = <1>;
> + reg = <2>;
> };
> };
> };
^ permalink raw reply
* Re: [PATCH net 2/2] sh_eth: Fix ethtool operation crash when net device is down
From: Ben Hutchings @ 2015-01-19 10:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: ct178-internal, David S. Miller, netdev, linux-kernel,
Nobuhiro Iwamatsu, Mitsuhiro Kimura, Hisashi Nakamura,
Yoshihiro Kaneko
In-Reply-To: <CAGVrzcbj2JANTECtxgDUrb7c_20nyoW4n5ARndHGKYuQu-0kQg@mail.gmail.com>
On Fri, 2015-01-16 at 10:45 -0800, Florian Fainelli wrote:
> 2015-01-16 9:51 GMT-08:00 Ben Hutchings <ben.hutchings@codethink.co.uk>:
[...]
> > --- a/drivers/net/ethernet/renesas/sh_eth.c
> > +++ b/drivers/net/ethernet/renesas/sh_eth.c
> > @@ -1827,6 +1827,9 @@ static int sh_eth_get_settings(struct net_device *ndev,
> > unsigned long flags;
> > int ret;
> >
> > + if (!mdp->phydev)
> > + return -ENODEV;
>
> Since the PHY is disconnected, would not checking for netif_running()
> make sense here, unless there is a good reason to still allow
> phy_ethtool_gset() to be called?
[...]
I think those two conditions will be equivalent, won't they? Writing
the condition like this will also work if the driver later supports
PHY-less configurations.
Ben.
^ permalink raw reply
* Re: [PATCH net 1/2] sh_eth: Fix promiscuous mode on chips without TSU
From: Ben Hutchings @ 2015-01-19 10:45 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: ct178-internal, David S. Miller, netdev, linux-kernel,
Nobuhiro Iwamatsu, Mitsuhiro Kimura, Hisashi Nakamura,
Yoshihiro Kaneko
In-Reply-To: <54B9663D.2040008@cogentembedded.com>
On Fri, 2015-01-16 at 22:27 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/16/2015 08:51 PM, Ben Hutchings wrote:
>
> > Currently net_device_ops::set_rx_mode is only implemented for
> > chips with a TSU (multiple address table). However we do need
> > to turn the PRM (promiscuous) flag on and off for other chips.
>
> > - Remove the unlikely() from the TSU functions that we may safely
> > call for chips without a TSU
>
> This is just optimization, worth pushing thru net-next instead.
This patch introduces calls to those functions for chips without a TSU,
and that makes the branch hint no longer correct. (Not that these
functions are speed-critical, so it doesn't matter that much.)
> > - Make setting of the MCT flag conditional on the tsu capability flag
> > - Rename sh_eth_set_multicast_list() to sh_eth_set_rx_mode() and plumb
> > it into both net_device_ops structures
> > - Remove the previously-unreachable branch in sh_eth_rx_mode() that
> > would otherwise reset the flags to defaults for non-TSU chips
>
> It couldn't be default for non-TSU chips, they don't seem to have
> ECMR.MCT. So it was just wrong.
>
> It would have been better if you did one thing per patch or at least
> didn't mix fixes with clean-ups...
[...]
I think this is one logical change.
Ben.
^ permalink raw reply
* [PATCH] phonet netlink: allow multiple messages per skb in route dump
From: Johannes Berg @ 2015-01-19 11:15 UTC (permalink / raw)
To: netdev; +Cc: Sakari Ailus, Remi Denis-Courmont, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
My previous patch to this file changed the code to be bug-compatible
towards userspace. Unless userspace (which I wasn't able to find)
implements the dump reader by hand in a wrong way, this isn't needed.
If it uses libnl or similar code putting multiple messages into a
single SKB is far more efficient.
Change the code to do this. While at it, also clean it up and don't
use so many variables - just store the address in the callback args
directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/phonet/pn_netlink.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
index 54d766842c2b..bc5ee5fbe6ae 100644
--- a/net/phonet/pn_netlink.c
+++ b/net/phonet/pn_netlink.c
@@ -272,31 +272,23 @@ static int route_doit(struct sk_buff *skb, struct nlmsghdr *nlh)
static int route_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
{
struct net *net = sock_net(skb->sk);
- u8 addr, addr_idx = 0, addr_start_idx = cb->args[0];
+ u8 addr;
rcu_read_lock();
- for (addr = 0; addr < 64; addr++) {
- struct net_device *dev;
+ for (addr = cb->args[0]; addr < 64; addr++) {
+ struct net_device *dev = phonet_route_get_rcu(net, addr << 2);
- dev = phonet_route_get_rcu(net, addr << 2);
if (!dev)
continue;
- if (addr_idx++ < addr_start_idx)
- continue;
- fill_route(skb, dev, addr << 2, NETLINK_CB(cb->skb).portid,
- cb->nlh->nlmsg_seq, RTM_NEWROUTE);
- /* fill_route() used to return > 0 (or negative errors) but
- * never 0 - ignore the return value and just go out to
- * call dumpit again from outside to preserve the behavior
- */
- goto out;
+ if (fill_route(skb, dev, addr << 2, NETLINK_CB(cb->skb).portid,
+ cb->nlh->nlmsg_seq, RTM_NEWROUTE) < 0)
+ goto out;
}
out:
rcu_read_unlock();
- cb->args[0] = addr_idx;
- cb->args[1] = 0;
+ cb->args[0] = addr;
return skb->len;
}
--
2.1.4
^ permalink raw reply related
* GOOD DAY
From: John Watson @ 2015-01-19 11:53 UTC (permalink / raw)
Watson Investment Group.
22 Pasteur Drive,Leegomery Telford
United Kingdom ,TF1 6PQ
Tel: 447053834136
Fax: +44 8435 622250
E-mail:jw25743@gmail.com
We are a private financial company based in the united Kingdom. We
offer funding for investments across the world. We have funded and
invested in businesses and given personal,multi-purpose loans to
individuals and groups. We have transformed DREAMS into REALITIES.
We will like to invest in your company or project using our
BG/Monetization Program, please send more details about your company
to provide you with our procedure for the loan.
John Watson
CEO Watson Investment Group
^ permalink raw reply
* Re: [PATCH 7/9] rhashtable: Per bucket locks & deferred expansion/shrinking
From: Thomas Graf @ 2015-01-19 12:58 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Laight, davem@davemloft.net, netdev@vger.kernel.org,
herbert@gondor.apana.org.au, paulmck@linux.vnet.ibm.com,
edumazet@google.com, john.r.fastabend@intel.com,
josh@joshtriplett.org, netfilter-devel@vger.kernel.org
In-Reply-To: <20150117080255.GA3968@acer.localdomain>
On 01/17/15 at 08:02am, Patrick McHardy wrote:
> On 16.01, Thomas Graf wrote:
> > Resize operations should be *really* rare as well unless you start
> > with really small hash table sizes and constantly add/remove at the
> > watermark.
>
> Which are far enough from each other that this should only happen
> in really unlucky cases.
>
> > Re-dumping on insert/remove is a different story of course. Do you
> > care about missed insert/removals for dumps? If not we can do the
> > sequence number consistency checking for resizing only.
>
> No, that has always been undeterministic with netlink. We want to
> dump everything that was present when the dump was started and is
> still present when it finishes. Anything else can be handled using
> notifications.
It looks like we want to provide two ways to resolve this:
1) Walker holds ht->mutex the entire time to block out resizes.
Optionally the walker can acquire all bucket locks. Such
scenarios would seem to benefit from either a single or a very
small number of bucket locks.
2) Walker holds ht->mutex during individual Netlink message
construction periods and relases it while user space reads the
message. rhashtable provides a hook which is called when a
resize operation is scheduled allowing for the walker code to
bump a sequence number and notify user space that the dump is
inconsistent, causing it to request a new dump.
I'll provide an API to achieve (2). (1) is already achieveable with
the current API.
^ permalink raw reply
* Re: [3.19.0-rc4+] rhashtable: BUG kmalloc-2048 (Not tainted): Poison overwritten
From: Thomas Graf @ 2015-01-19 12:59 UTC (permalink / raw)
To: Ying Xue
Cc: richard.alpe@ericsson.com >> Richard Alpe, Netdev,
tipc-discussion
In-Reply-To: <54BCBA35.2080103@windriver.com>
On 01/19/15 at 04:03pm, Ying Xue wrote:
> On 3.19.0-rc4+, I encountered below error with attached test
> case(bind_netlink.c). Please execute the following commands to reproduce
> the error:
>
> gcc -Wall -o bind_netlink bind_netlink.c
> ./bind_netlink 1000
>
> By the way, if we run another test case(bind_tipc.c), the similar issue
> will happen on TIPC socket.
>
> Therefore, it seems that the issue is closely associated with rhashtable
> instead of specific stacks like netlink or tipc.
Looks like a RCU read side critical section was missed. Does the TIPC
poision warning look the same? offset 2048?
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Thomas Jarosch @ 2015-01-19 13:39 UTC (permalink / raw)
To: Herbert Xu
Cc: netdev, edumazet, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <20141231133923.GA30248@gondor.apana.org.au>
Hi Herbert,
On Thursday, 1. January 2015 00:39:23 Herbert Xu wrote:
> The problem is that when the MSS goes down, existing queued packet
> on the TX queue that have not been transmitted yet all look like
> TSO packets and get treated as such.
>
> This then triggers a bug where tcp_mss_split_point tells us to
> generate a zero-sized packet on the TX queue. Once that happens
> we're screwed because the zero-sized packet can never be removed
> by ACKs.
picking up this one again: Is there any valid use case to have
zero-sized packets in the TX queue? If not, may be a WARN_ON() could
be added to the processing of the TX queue. That would help to
prevent future issues like this.
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: Hannes Frederic Sowa @ 2015-01-19 13:55 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev, stable, Fernando Gont
In-Reply-To: <1421357665-2804-1-git-send-email-hagen@jauu.net>
On Do, 2015-01-15 at 22:34 +0100, Hagen Paul Pfeifer wrote:
> Reduce the attack vector and stop generating IPv6 Fragment Header for
> paths with an MTU smaller than the minimum required IPv6 MTU
> size (1280 byte) - called atomic fragments.
>
> See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
> for more information and how this "feature" can be misused.
>
> [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Fernando Gont <fgont@si6networks.com>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
I think this is the correct way forward on how to deal with atomic
fragments.
Hagen, do you submit patches to remove dst_allfrag/RTAX_FEATURE_ALLFRAG,
IPCORK_ALLFRAG, etc. for net-next, too?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ss: Unify tcp stats output
From: Hagen Paul Pfeifer @ 2015-01-19 13:57 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1421613815-6635-4-git-send-email-vadim4j@gmail.com>
On 18 January 2015 at 21:43, Vadim Kochan <vadim4j@gmail.com> wrote:
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> ---
> misc/ss.c | 362 +++++++++++++++++++++++++++++++++++++++-----------------------
> 1 file changed, 231 insertions(+), 131 deletions(-)
Hey Vadin,
your patch do *not* change the output format, right? ss output is
parsed by scripts and tools.
hgn
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: Hagen Paul Pfeifer @ 2015-01-19 14:00 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, stable, Fernando Gont
In-Reply-To: <1421675722.32277.3.camel@stressinduktion.org>
On 19 January 2015 at 14:55, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
> I think this is the correct way forward on how to deal with atomic
> fragments.
>
> Hagen, do you submit patches to remove dst_allfrag/RTAX_FEATURE_ALLFRAG,
> IPCORK_ALLFRAG, etc. for net-next, too?
Yes, patch sits already in the pipe. I wanted to wait for davem's pull.
Hagen
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ss: Unify tcp stats output
From: Vadim Kochan @ 2015-01-19 14:04 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Vadim Kochan, netdev
In-Reply-To: <CAPh34mdJ7mjzueaX2qakoT=ODbHDLm4k-K_3Eg__6+s7ydf4Gg@mail.gmail.com>
On Mon, Jan 19, 2015 at 02:57:50PM +0100, Hagen Paul Pfeifer wrote:
> On 18 January 2015 at 21:43, Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > ---
> > misc/ss.c | 362 +++++++++++++++++++++++++++++++++++++++-----------------------
> > 1 file changed, 231 insertions(+), 131 deletions(-)
>
> Hey Vadin,
>
> your patch do *not* change the output format, right? ss output is
> parsed by scripts and tools.
>
> hgn
Hi,
It should not for tcp but does for memory info in the 1st patch where
the memeinfo param names were changed.
Regarding parsing of ss by scripts and tools, thats really painful
for me to see how ss outputs additional info, it is not human readable,
actually I'd like to change the output layout in the future, and add
something like online output option '-O'.
May be you can test these patches if they breaks output parsing ?
Anyway I will give up with ss output changes if we really carrying about
to keep the same output for scripts/tools.
Here are some comments from Stephen:
http://marc.info/?l=linux-netdev&m=142129033800881&w=2
Regards,
^ 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