* Re: [PATCH 0/9 net-next-2.6] qlcnic: Code cleanup and fixes
From: Anirban Chakraborty @ 2011-04-01 22:03 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev@vger.kernel.org, Dept_NX_Linux_NIC_Driver
In-Reply-To: <alpine.OSX.2.00.1103312119400.47460@n5102mn2hhgf91.qlogic.org>
On Mar 31, 2011, at 9:31 PM, Anirban Chakraborty wrote:
> Please apply.
>
> thanks,
> Anirban
>
It turned out that patch no. 8 has a conflict with the following patch:
commit 673e63c688f43104c73aad8ea4237f7ad41fa14d
net: fix ethtool->set_flags not intended -EINVAL return value
Please do not apply the current series as I'm resending it.
thanks,
Anirban
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: Driver for Asix AX88172A only?
From: David Miller @ 2011-04-01 19:54 UTC (permalink / raw)
To: michael; +Cc: netdev
In-Reply-To: <20110401165328.20091msct39m3en4@webmail.df.eu>
From: Michael Riesch <michael@riesch.at>
Date: Fri, 01 Apr 2011 16:53:28 +0200
> What do you think: should the mainline driver be adapted to support
> the AX88172A (with all his features) or a new driver for the AX88172A
> only should be created (probably based on the existing mainline
> driver).
I think the mainline driver should be adapted to support the new
chips with external PHYs etc.
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-01 18:26 UTC (permalink / raw)
To: Andres Salomon
Cc: Grant Likely, linux-kernel, Mark Brown, khali, ben-linux,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell, linux-i2c,
linux-media, netdev, spi-devel-general, Mocean Laboratories
In-Reply-To: <20110401104756.2f5c6f7a@debxo>
On Fri, Apr 01, 2011 at 10:47:56AM -0700, Andres Salomon wrote:
> On Fri, 1 Apr 2011 13:20:31 +0200
> Samuel Ortiz <sameo@linux.intel.com> wrote:
>
> > Hi Grant,
> >
> > On Thu, Mar 31, 2011 at 05:05:22PM -0600, Grant Likely wrote:
> [...]
> > > Gah. Not all devices instantiated via mfd will be an mfd device,
> > > which means that the driver may very well expect an *entirely
> > > different* platform_device pointer; which further means a very high
> > > potential of incorrectly dereferenced structures (as evidenced by a
> > > patch series that is not bisectable). For instance, the xilinx ip
> > > cores are used by more than just mfd.
> > I agree. Since the vast majority of the MFD subdevices are MFD
> > specific IPs, I overlooked that part. The impacted drivers are the
> > timberdale and the DaVinci voice codec ones.
>
> Can you please provide pointers to what you're referring to? The only
> code that I could find that created platform devices prefixed with
> 'timb-' or named 'xilinx_spi' was drivers/mfd/timberdale.c.
The xilinx-spi, ocores-i2c, i2c-xiic drivers and to some extend the
ks8842 ethernet driver are generic IPs that the timberdale SOC happens to
use. So I agree it's extremely unlikely that anyone could come up with a
platform that would be re-using e.g. the timb-radio IP, but I think it's less
unikely for more generic IPs such as the xilinx-spi one.
> > To fix that problem I propose 2 alternatives:
> >
> > 1) When declaring the sub devices cells, the MFD driver should
> > specify an mfd_data_size value for sub devices that are not MFD
> > specific. It's the MFD driver responsibility to set the cell
> > properly, and the non MFD specific drivers are kept MFD agnostic.
> > See my patch below for the timberdale case.
> >
> > 2) Revert the mfd_get_data() call for getting sub devices platform
> > data pointers. That was introduced to ease the MFD cell sharing work,
> > so if we take this route we'll need the cs5535 MFD driver to pass its
> > cells as platform_data pointer. Andres, can you confirm that this
> > would be fine for the mfd_clone_cell() routine to keep working ?
>
> It would break mfd_clone_cell, as it uses mfd_get_cell to grab the one
> to clone. We could change it to accept the cell as an argument. It
> would also break mfd_cell_enable/disable, of course.
I'm talking about reverting the default behaviour of passing the MFD cell as
the platform data, and going back to the cell definitions setting their
platform_data pointer explicitely. In that case, the cs5535 driver would have
to do something like:
diff --git a/drivers/mfd/cs5535-mfd.c b/drivers/mfd/cs5535-mfd.c
index 155fa04..3e3841d 100644
--- a/drivers/mfd/cs5535-mfd.c
+++ b/drivers/mfd/cs5535-mfd.c
@@ -106,6 +106,7 @@ static __devinitdata struct mfd_cell cs5535_mfd_cells[] =
{
.name = "cs5535-acpi",
.num_resources = 1,
.resources = &cs5535_mfd_resources[ACPI_BAR],
+ .platform_data = &cs5535_mfd_cells[ACPI_BAR],
.enable = cs5535_mfd_res_enable,
.disable = cs5535_mfd_res_disable,
mfd_get_cell would then return &cs5535_mfd_cells[ACPI_BAR].
This fix would put all sub devices drivers back to an MFD agnostic state,
although the vast majority of them will certainly never be found anywhere else
than in their current MFD SoC. That's why I'm still not sure which way to go
to fix that problem.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply related
* [PATCH] e1000e: fix stats locking in e1000_watchdog_task
From: Flavio Leitner @ 2011-04-01 18:16 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel
Just move the unlock down a bit because it unlocks too
early leaving a chance for get_stats64() run in parallel
while it is still accessing the stats.
Signed-off-by: Flavio Leitner <fleitner@redhat.com>
---
drivers/net/e1000e/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index a39d4a4..c19e4f0 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4328,7 +4328,6 @@ static void e1000_watchdog_task(struct work_struct *work)
link_up:
spin_lock(&adapter->stats64_lock);
e1000e_update_stats(adapter);
- spin_unlock(&adapter->stats64_lock);
mac->tx_packet_delta = adapter->stats.tpt - adapter->tpt_old;
adapter->tpt_old = adapter->stats.tpt;
@@ -4339,6 +4338,7 @@ link_up:
adapter->gorc_old = adapter->stats.gorc;
adapter->gotc = adapter->stats.gotc - adapter->gotc_old;
adapter->gotc_old = adapter->stats.gotc;
+ spin_unlock(&adapter->stats64_lock);
e1000e_update_adaptive(&adapter->hw);
--
1.7.3.1
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [Bridge] [PATCH] net/bridge: Fix wrong return-no-vaule
From: Sasikanth V @ 2011-04-01 18:11 UTC (permalink / raw)
To: namei.unix
Cc: shemminger, davem, open list:ETHERNET BRIDGE, Liu Yuan,
open list:ETHERNET BRIDGE, open list
In-Reply-To: <1301631861-12470-1-git-send-email-namei.unix@gmail.com>
It is already fixed and applied
On 4/1/11, namei.unix@gmail.com <namei.unix@gmail.com> wrote:
> From: Liu Yuan <tailai.ly@taobao.com>
>
> In br_stp_if.c/br_stp_recalculate_bridge_id, it should return
> false, which indicates that there is no change when we find
> that user has chosen a value.
>
> Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
> ---
> net/bridge/br_stp_if.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
> index 5593f5a..9b61d09 100644
> --- a/net/bridge/br_stp_if.c
> +++ b/net/bridge/br_stp_if.c
> @@ -213,7 +213,7 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
>
> /* user has chosen a value so keep it */
> if (br->flags & BR_SET_MAC_ADDR)
> - return;
> + return false;
>
> list_for_each_entry(p, &br->port_list, list) {
> if (addr == br_mac_zero ||
> --
> 1.7.1
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Grant Likely @ 2011-04-01 18:00 UTC (permalink / raw)
To: Andres Salomon
Cc: Samuel Ortiz, linux-kernel, Mark Brown, khali, ben-linux,
Peter Korsgaard, Mauro Carvalho Chehab, linux-i2c, linux-media,
netdev, spi-devel-general, Mocean Laboratories
In-Reply-To: <BANLkTi=bCd_+f=EG-O=U5VH_ZNjFhxkziQ@mail.gmail.com>
On Fri, Apr 1, 2011 at 11:56 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Apr 1, 2011 at 11:47 AM, Andres Salomon <dilinger@queued.net> wrote:
>> On Fri, 1 Apr 2011 13:20:31 +0200
>> Samuel Ortiz <sameo@linux.intel.com> wrote:
>>
>>> Hi Grant,
>>>
>>> On Thu, Mar 31, 2011 at 05:05:22PM -0600, Grant Likely wrote:
>> [...]
>>> > Gah. Not all devices instantiated via mfd will be an mfd device,
>>> > which means that the driver may very well expect an *entirely
>>> > different* platform_device pointer; which further means a very high
>>> > potential of incorrectly dereferenced structures (as evidenced by a
>>> > patch series that is not bisectable). For instance, the xilinx ip
>>> > cores are used by more than just mfd.
>>> I agree. Since the vast majority of the MFD subdevices are MFD
>>> specific IPs, I overlooked that part. The impacted drivers are the
>>> timberdale and the DaVinci voice codec ones.
>
> Another option is you could do this for MFD devices:
>
> struct mfd_device {
> struct platform_devce pdev;
> struct mfd_cell *cell;
> };
>
> However, that requires that drivers using the mfd_cell will *never*
> get instantiated outside of the mfd infrastructure, and there is no
> way to protect against this so it is probably a bad idea.
>
> Or, mfd_cell could be added to platform_device directly which would
> *by far* be the safest option at the cost of every platform_device
> having a mostly unused mfd_cell pointer. Not a significant cost in my
> opinion.
>
> One last option is I'm prototyping a way to add type-safe structure
> pointers to a device, but that requires nasty CPP tricks and it's not
> complete yet. The cure might be worse than the disease here.
And yet another option is to create a mfd_bus_type, but that probably
isn't helpful since the one of the purposes of MFDs is that it is a
collection of non-detectable memory mapped devices that
platform_bus_type is intended to handle.
g.
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Grant Likely @ 2011-04-01 17:56 UTC (permalink / raw)
To: Andres Salomon
Cc: Samuel Ortiz, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110401104756.2f5c6f7a@debxo>
On Fri, Apr 1, 2011 at 11:47 AM, Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org> wrote:
> On Fri, 1 Apr 2011 13:20:31 +0200
> Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
>> Hi Grant,
>>
>> On Thu, Mar 31, 2011 at 05:05:22PM -0600, Grant Likely wrote:
> [...]
>> > Gah. Not all devices instantiated via mfd will be an mfd device,
>> > which means that the driver may very well expect an *entirely
>> > different* platform_device pointer; which further means a very high
>> > potential of incorrectly dereferenced structures (as evidenced by a
>> > patch series that is not bisectable). For instance, the xilinx ip
>> > cores are used by more than just mfd.
>> I agree. Since the vast majority of the MFD subdevices are MFD
>> specific IPs, I overlooked that part. The impacted drivers are the
>> timberdale and the DaVinci voice codec ones.
Another option is you could do this for MFD devices:
struct mfd_device {
struct platform_devce pdev;
struct mfd_cell *cell;
};
However, that requires that drivers using the mfd_cell will *never*
get instantiated outside of the mfd infrastructure, and there is no
way to protect against this so it is probably a bad idea.
Or, mfd_cell could be added to platform_device directly which would
*by far* be the safest option at the cost of every platform_device
having a mostly unused mfd_cell pointer. Not a significant cost in my
opinion.
One last option is I'm prototyping a way to add type-safe structure
pointers to a device, but that requires nasty CPP tricks and it's not
complete yet. The cure might be worse than the disease here.
g.
>
> Can you please provide pointers to what you're referring to? The only
> code that I could find that created platform devices prefixed with
> 'timb-' or named 'xilinx_spi' was drivers/mfd/timberdale.c.
>
>
>
>> To fix that problem I propose 2 alternatives:
>>
>> 1) When declaring the sub devices cells, the MFD driver should
>> specify an mfd_data_size value for sub devices that are not MFD
>> specific. It's the MFD driver responsibility to set the cell
>> properly, and the non MFD specific drivers are kept MFD agnostic.
>> See my patch below for the timberdale case.
This approach worries me because it changes the behaviour on a
per-device basis. That could be difficult to maintain a mental model
for. I'd rather see consistent behaviour.
>>
>> 2) Revert the mfd_get_data() call for getting sub devices platform
>> data pointers. That was introduced to ease the MFD cell sharing work,
>> so if we take this route we'll need the cs5535 MFD driver to pass its
>> cells as platform_data pointer. Andres, can you confirm that this
>> would be fine for the mfd_clone_cell() routine to keep working ?
>
> It would break mfd_clone_cell, as it uses mfd_get_cell to grab the one
> to clone. We could change it to accept the cell as an argument. It
> would also break mfd_cell_enable/disable, of course.
>
>
>
>>
>> Patch for solution 1:
>>
>>
>> drivers/mfd/mfd-core.c | 13 ++++++++++---
>> drivers/mfd/timberdale.c | 11 +++++++++++
>> include/linux/mfd/core.h | 1 +
>> drivers/i2c/busses/i2c-ocores.c | 3 +--
>> drivers/i2c/busses/i2c-xiic.c | 3 +--
>> drivers/net/ks8842.c | 3 +--
>> drivers/spi/xilinx_spi.c | 3 +--
>> 7 files changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
>> index d01574d..8abe510 100644
>> --- a/drivers/mfd/mfd-core.c
>> +++ b/drivers/mfd/mfd-core.c
>> @@ -75,9 +75,16 @@ static int mfd_add_device(struct device *parent,
>> int id,
>> pdev->dev.parent = parent;
>>
>> - ret = platform_device_add_data(pdev, cell, sizeof(*cell));
>> - if (ret)
>> - goto fail_res;
>> + if (cell->mfd_data_size > 0) {
>> + ret = platform_device_add_data(pdev,
>> + cell->mfd_data,
>> cell->mfd_data_size);
>> + if (ret)
>> + goto fail_res;
>> + } else {
>> + ret = platform_device_add_data(pdev, cell,
>> sizeof(*cell));
>> + if (ret)
>> + goto fail_res;
>> + }
>>
>> for (r = 0; r < cell->num_resources; r++) {
>> res[r].name = cell->resources[r].name;
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Andres Salomon @ 2011-04-01 17:47 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Grant Likely, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110401112030.GA3447@sortiz-mobl>
On Fri, 1 Apr 2011 13:20:31 +0200
Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> Hi Grant,
>
> On Thu, Mar 31, 2011 at 05:05:22PM -0600, Grant Likely wrote:
[...]
> > Gah. Not all devices instantiated via mfd will be an mfd device,
> > which means that the driver may very well expect an *entirely
> > different* platform_device pointer; which further means a very high
> > potential of incorrectly dereferenced structures (as evidenced by a
> > patch series that is not bisectable). For instance, the xilinx ip
> > cores are used by more than just mfd.
> I agree. Since the vast majority of the MFD subdevices are MFD
> specific IPs, I overlooked that part. The impacted drivers are the
> timberdale and the DaVinci voice codec ones.
Can you please provide pointers to what you're referring to? The only
code that I could find that created platform devices prefixed with
'timb-' or named 'xilinx_spi' was drivers/mfd/timberdale.c.
> To fix that problem I propose 2 alternatives:
>
> 1) When declaring the sub devices cells, the MFD driver should
> specify an mfd_data_size value for sub devices that are not MFD
> specific. It's the MFD driver responsibility to set the cell
> properly, and the non MFD specific drivers are kept MFD agnostic.
> See my patch below for the timberdale case.
>
> 2) Revert the mfd_get_data() call for getting sub devices platform
> data pointers. That was introduced to ease the MFD cell sharing work,
> so if we take this route we'll need the cs5535 MFD driver to pass its
> cells as platform_data pointer. Andres, can you confirm that this
> would be fine for the mfd_clone_cell() routine to keep working ?
It would break mfd_clone_cell, as it uses mfd_get_cell to grab the one
to clone. We could change it to accept the cell as an argument. It
would also break mfd_cell_enable/disable, of course.
>
> Patch for solution 1:
>
>
> drivers/mfd/mfd-core.c | 13 ++++++++++---
> drivers/mfd/timberdale.c | 11 +++++++++++
> include/linux/mfd/core.h | 1 +
> drivers/i2c/busses/i2c-ocores.c | 3 +--
> drivers/i2c/busses/i2c-xiic.c | 3 +--
> drivers/net/ks8842.c | 3 +--
> drivers/spi/xilinx_spi.c | 3 +--
> 7 files changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index d01574d..8abe510 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -75,9 +75,16 @@ static int mfd_add_device(struct device *parent,
> int id,
> pdev->dev.parent = parent;
>
> - ret = platform_device_add_data(pdev, cell, sizeof(*cell));
> - if (ret)
> - goto fail_res;
> + if (cell->mfd_data_size > 0) {
> + ret = platform_device_add_data(pdev,
> + cell->mfd_data,
> cell->mfd_data_size);
> + if (ret)
> + goto fail_res;
> + } else {
> + ret = platform_device_add_data(pdev, cell,
> sizeof(*cell));
> + if (ret)
> + goto fail_res;
> + }
>
> for (r = 0; r < cell->num_resources; r++) {
> res[r].name = cell->resources[r].name;
^ permalink raw reply
* Re: [PATCH] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-01 17:10 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, sucheta.chakraborty,
anirban.chakraborty
In-Reply-To: <1301652075-382-1-git-send-email-amit.salecha@qlogic.com>
On Fri, 2011-04-01 at 03:01 -0700, Amit Kumar Salecha wrote:
> o Instead of cluttering struct ethtool_channels, defined channel type in
> struct ethtool_channels, making it scalable for addition future channels.
> Application needs to send different ioctl for each channel type.
> o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o New channel id can be added in ethtool_channel_id to make it configurable.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Since you have modified this, you must not use my Signed-off-by without
explaining that you have done so.
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> ---
> include/linux/ethtool.h | 27 +++++++++++++++++++++++++++
> net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 68 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c8fcbdd..cdb69d6 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -229,6 +229,28 @@ struct ethtool_ringparam {
> __u32 tx_pending;
> };
>
> +/* for configuring number of network channel */
> +struct ethtool_channels {
> + __u32 cmd; /* ETHTOOL_{G,S}CHANNELS */
> + __u32 type; /* Channel type defined in ethtool_channel_id */
> +
> + /* Read only attributes. These indicate the maximum number
> + * of channel the driver will allow the user to set.
> + */
> + __u32 max;
This is a single read-only attribute, not 'attributes'.
> + /* Values changeable by the user. The valid values are
> + * in the range 1 to the "*_max" counterpart above.
> + */
> + __u32 pending;
> +};
Please could you use a kernel-doc comment to describe the structure. I
know my earlier patch (and most of the existing structures in ethtool.h)
didn't, but I have been gradually changing that.
I'm not sure why you reduced this to a single count. If if the driver
or hardware doesn't allow certain combinations of counts, it might be
necessary to configure several types at the same time
> +/* Channel ID is made up of a type */
> +enum ethtool_channel_id {
> + ETH_CHAN_TYPE_RX = 0x1,
> + ETH_CHAN_TYPE_TX = 0x2
> +};
[...]
enum ethtool_channel_id was meant to be an identifier of a specific
channel. An enumeration of channel types should be named differently.
This also omits the 'combined' and 'other' types. Most multiqueue
drivers pair up RX and TX queues so that most channels combine RX and TX
work.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] starfire: clean up dma_addr_t size test
From: FUJITA Tomonori @ 2011-04-01 15:27 UTC (permalink / raw)
To: netdev; +Cc: davem
Only compile tested.
=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] starfire: clean up dma_addr_t size test
Now we have CONFIG_ARCH_DMA_ADDR_T_64BIT. We can fix the hacky
dma_addr_t size test cleanly.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
drivers/net/starfire.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/net/starfire.c b/drivers/net/starfire.c
index a4f2bd5..36045f3 100644
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -144,11 +144,7 @@ static int full_duplex[MAX_UNITS] = {0, };
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (2 * HZ)
-/*
- * This SUCKS.
- * We need a much better method to determine if dma_addr_t is 64-bit.
- */
-#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__) || defined (__ia64__) || defined(__alpha__) || (defined(CONFIG_MIPS) && ((defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR)) || defined(CONFIG_64BIT))) || (defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT))
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
/* 64-bit dma_addr_t */
#define ADDR_64BITS /* This chip uses 64 bit addresses. */
#define netdrv_addr_t __le64
--
1.7.2.3
^ permalink raw reply related
* [PATCH v3] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-04-01 15:06 UTC (permalink / raw)
To: Linux USB list
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Brownell, Linux USB list,
patches-QSEj5FYQhm4dnm+yROfE0A, Greg KH, Nicolas Pitre, lkml
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Tested-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
---
drivers/net/usb/cdc_eem.c | 2 +-
drivers/net/usb/cdc_ether.c | 2 +-
drivers/net/usb/cdc_ncm.c | 2 +-
drivers/net/usb/cdc_subset.c | 8 ++++++++
drivers/net/usb/gl620a.c | 2 +-
drivers/net/usb/net1080.c | 2 +-
drivers/net/usb/plusb.c | 2 +-
drivers/net/usb/rndis_host.c | 2 +-
drivers/net/usb/usbnet.c | 3 ++-
drivers/net/usb/zaurus.c | 8 ++++----
include/linux/usb/usbnet.h | 2 ++
11 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index 5f3b976..8f12854 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -340,7 +340,7 @@ next:
static const struct driver_info eem_info = {
.description = "CDC EEM Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT,
.bind = eem_bind,
.rx_fixup = eem_rx_fixup,
.tx_fixup = eem_tx_fixup,
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 9a60e41..98b2bbd 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -450,7 +450,7 @@ static int cdc_manage_power(struct usbnet *dev, int on)
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT,
// .check_connect = cdc_check_connect,
.bind = cdc_bind,
.unbind = usbnet_cdc_unbind,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 7113168..967371f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1237,7 +1237,7 @@ static int cdc_ncm_manage_power(struct usbnet *dev, int status)
static const struct driver_info cdc_ncm_info = {
.description = "CDC NCM",
- .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET,
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET,
.bind = cdc_ncm_bind,
.unbind = cdc_ncm_unbind,
.check_connect = cdc_ncm_check_connect,
diff --git a/drivers/net/usb/cdc_subset.c b/drivers/net/usb/cdc_subset.c
index ca39ace..fc5f13d 100644
--- a/drivers/net/usb/cdc_subset.c
+++ b/drivers/net/usb/cdc_subset.c
@@ -89,6 +89,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info ali_m5632_info = {
.description = "ALi M5632",
+ .flags = FLAG_POINTTOPOINT,
};
#endif
@@ -110,6 +111,7 @@ static const struct driver_info ali_m5632_info = {
static const struct driver_info an2720_info = {
.description = "AnchorChips/Cypress 2720",
+ .flags = FLAG_POINTTOPOINT,
// no reset available!
// no check_connect available!
@@ -132,6 +134,7 @@ static const struct driver_info an2720_info = {
static const struct driver_info belkin_info = {
.description = "Belkin, eTEK, or compatible",
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_BELKIN */
@@ -157,6 +160,7 @@ static const struct driver_info belkin_info = {
static const struct driver_info epson2888_info = {
.description = "Epson USB Device",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
.in = 4, .out = 3,
};
@@ -173,6 +177,7 @@ static const struct driver_info epson2888_info = {
#define HAVE_HARDWARE
static const struct driver_info kc2190_info = {
.description = "KC Technology KC-190",
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_KC2190 */
@@ -200,16 +205,19 @@ static const struct driver_info kc2190_info = {
static const struct driver_info linuxdev_info = {
.description = "Linux Device",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
static const struct driver_info yopy_info = {
.description = "Yopy",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
static const struct driver_info blob_info = {
.description = "Boot Loader OBject",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_ARMLINUX */
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index dcd57c3..c4cfd1d 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -193,7 +193,7 @@ static int genelink_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info genelink_info = {
.description = "Genesys GeneLink",
- .flags = FLAG_FRAMING_GL | FLAG_NO_SETINT,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_GL | FLAG_NO_SETINT,
.bind = genelink_bind,
.rx_fixup = genelink_rx_fixup,
.tx_fixup = genelink_tx_fixup,
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index ba72a72..01db460 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -560,7 +560,7 @@ static int net1080_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info net1080_info = {
.description = "NetChip TurboCONNECT",
- .flags = FLAG_FRAMING_NC,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_NC,
.bind = net1080_bind,
.reset = net1080_reset,
.check_connect = net1080_check_connect,
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 08ad269..823c537 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -96,7 +96,7 @@ static int pl_reset(struct usbnet *dev)
static const struct driver_info prolific_info = {
.description = "Prolific PL-2301/PL-2302",
- .flags = FLAG_NO_SETINT,
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
};
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index dd8a4ad..5994a25 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(rndis_tx_fixup);
static const struct driver_info rndis_info = {
.description = "RNDIS device",
- .flags = FLAG_ETHER | FLAG_FRAMING_RN | FLAG_NO_SETINT,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT | FLAG_FRAMING_RN | FLAG_NO_SETINT,
.bind = rndis_bind,
.unbind = rndis_unbind,
.status = rndis_status,
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 95c41d5..c5b6cfb 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1376,7 +1376,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
// else "eth%d" when there's reasonable doubt. userspace
// can rename the link if it knows better.
if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
- (net->dev_addr [0] & 0x02) == 0)
+ ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
+ (net->dev_addr [0] & 0x02) == 0))
strcpy (net->name, "eth%d");
/* WLAN devices should always be named "wlan%d" */
if ((dev->driver_info->flags & FLAG_WLAN) != 0)
diff --git a/drivers/net/usb/zaurus.c b/drivers/net/usb/zaurus.c
index 3eb0b16..241756e 100644
--- a/drivers/net/usb/zaurus.c
+++ b/drivers/net/usb/zaurus.c
@@ -102,7 +102,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info zaurus_sl5x00_info = {
.description = "Sharp Zaurus SL-5x00",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -112,7 +112,7 @@ static const struct driver_info zaurus_sl5x00_info = {
static const struct driver_info zaurus_pxa_info = {
.description = "Sharp Zaurus, PXA-2xx based",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -122,7 +122,7 @@ static const struct driver_info zaurus_pxa_info = {
static const struct driver_info olympus_mxl_info = {
.description = "Olympus R1000",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -258,7 +258,7 @@ bad_desc:
static const struct driver_info bogus_mdlm_info = {
.description = "pseudo-MDLM (BLAN) device",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.tx_fixup = zaurus_tx_fixup,
.bind = blan_mdlm_bind,
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 44842c8..1ef9aa0 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -97,6 +97,8 @@ struct driver_info {
#define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
+#define FLAG_POINTTOPOINT 0x1000 /* possibly use "usb%d" names */
+
/*
* Indicates to usbnet, that USB driver accumulates multiple IP packets.
* Affects statistic (counters) and short packet handling.
--
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
* Driver for Asix AX88172A only?
From: Michael Riesch @ 2011-04-01 14:53 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Habidere,
I'm currently working on a driver for the Asix AX88172A
USB-to-Ethernet chip[1]. It has an Ethernet PHY on-chip, but can work
with an external PHY as well. Also, the chip provides various
interfaces (SPI or I2C/UART) and GPIOs.
I have already tried out the asix.c mainline driver, which works with
the evaluation board. As soon as you add the device-IDs, the driver
works with the AX88172A's internal PHY. Because I would like to get it
run with an external PHY (and use the SPI feature), I have also tried
out the Asix vendor driver. It didn't like my 2.6.38-rc7+ kernel
(2.6.35 worked), it does not have any "external PHY mode" and it
supports SPI, I2C.. via ioctls.
Long story short, I want a nice mainline driver. I have heard there is
some thinking about feeding the vendor code into the kernel[2], I
would like to support that.
My TODO includes:
* support of an external PHY connected via MII
* support of the SPI interface via the SPI subsystem
* GPIO control via sysfs (is that a nice way?!)
* use of phylib
What do you think: should the mainline driver be adapted to support
the AX88172A (with all his features) or a new driver for the AX88172A
only should be created (probably based on the existing mainline driver).
Looking forward to your comments,
Michael
[1] http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=97;71;101
[2] http://marc.info/?t=130013910200004&r=1&w=2
^ permalink raw reply
* Re: appletalk oops.
From: Arnd Bergmann @ 2011-04-01 14:26 UTC (permalink / raw)
To: David Miller; +Cc: davej, netdev
In-Reply-To: <20110331.185823.232755679.davem@davemloft.net>
On Friday 01 April 2011, David Miller wrote:
> appletalk: Fix OOPS in atalk_release().
>
> Commit 60d9f461a20ba59219fdcdc30cbf8e3a4ad3f625 ("appletalk: remove
> the BKL") added a dereference of "sk" before checking for NULL in
> atalk_release().
>
> Guard the code block completely, rather than partially, with the
> NULL check.
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Oops indeed.
The best excuse I have is that nobody who has access to a real
appletalk network stepped up to test it when I submitted the patches
and that I first suggested deleting the protocol instead because
I had no idea if my patch made any sense.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* pull request: wireless-2.6 2011-04-01
From: John W. Linville @ 2011-04-01 14:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here is another batch of fixes intended for 2.6.39. This round includes
a number of Bluetooth fixes.
On the Bluetooth front, we have a WARNING fix related to debugobjects, a
fix for L2CAP channel hang, a fix for an unlock without a lock, a fix to
check for LE connections before discarding data, a fix for
synchronization after HCI_RESET, an accounting fix for unacked frames,
and a device ID addition.
For wireless LANs, an iwlegacy fix to prevent a possible crash during a
firmware restart, a carl9170 fix to generate BlockAckReq if the
transmission of an AMPDU subframe fails (i.e. an interop fix), an
iwl3945 change to disable hw scan by default due to a number of related
problems, a related debug message change to avoid some confusion, a fix
for aggregation frame reordering, a cfg80211 fix to avoid
double-unlinking a BSS entry, a trio of NULL pointer deref fixes, an
ath9k fix to avoid a bus error during restart, a minstrel_ht fix to
avoid a crash when no supported MCS rates are found, and some new device
IDs for rt2x00.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit c100c8f4c3c6f2a407bdbaaad2c4f1062e6a473a:
appletalk: Fix OOPS in atalk_release(). (2011-03-31 18:59:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: delete hanging L2CAP channel
Christian Lamparter (1):
carl9170: Fix tx aggregation problems with some clients
Daniel Halperin (1):
mac80211: fix aggregation frame release during timeout
Felix Fietkau (2):
mac80211: fix a crash in minstrel_ht in HT mode with no supported MCS rates
ath9k: fix a chip wakeup related crash in ath9k_start
Gustavo F. Padovan (1):
Bluetooth: Fix HCI_RESET command synchronization
Johan Hedberg (1):
Bluetooth: Fix missing hci_dev_lock_bh in user_confirm_reply
Johannes Berg (1):
iwlegacy: fix bugs in change_interface
Juuso Oikarinen (1):
cfg80211: fix BSS double-unlinking (continued)
Marc-Antoine Perennou (1):
Bluetooth: add support for Apple MacBook Pro 8,2
Mariusz Kozlowski (2):
mac80211: fix possible NULL pointer dereference
cfg80211:: fix possible NULL pointer dereference
Petr Štetiar (1):
mac80211: fix NULL pointer dereference in ieee80211_key_alloc()
Stanislaw Gruszka (2):
iwl3945: do not deprecate software scan
iwl3945: disable hw scan by default
Suraj Sumangala (1):
Bluetooth: Increment unacked_frames count only the first transmit
Thomas Gleixner (1):
Bluetooth: Fix warning with hci_cmd_timer
Vinicius Costa Gomes (1):
Bluetooth: Fix sending LE data over USB
Xose Vazquez Perez (1):
wireless: rt2x00: rt2800usb.c add and identify ids
drivers/bluetooth/btusb.c | 6 ++++-
drivers/net/wireless/ath/ath9k/main.c | 4 +++
drivers/net/wireless/ath/carl9170/carl9170.h | 1 +
drivers/net/wireless/ath/carl9170/main.c | 1 +
drivers/net/wireless/ath/carl9170/tx.c | 7 ++++++
drivers/net/wireless/iwlegacy/iwl-core.c | 10 ++++++++
drivers/net/wireless/iwlegacy/iwl3945-base.c | 7 ++---
drivers/net/wireless/rt2x00/rt2800usb.c | 10 ++++++--
include/net/bluetooth/hci.h | 2 +
net/bluetooth/hci_core.c | 10 ++++++-
net/bluetooth/hci_event.c | 4 ++-
net/bluetooth/l2cap_core.c | 4 ++-
net/bluetooth/l2cap_sock.c | 5 ++-
net/bluetooth/mgmt.c | 2 +
net/mac80211/key.c | 7 +++--
net/mac80211/rc80211_minstrel_ht.c | 25 +++++++++++++++------
net/mac80211/rx.c | 3 +-
net/wireless/scan.c | 31 +++++++++++++++++--------
18 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8668114..762a510 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -71,6 +71,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple MacBookAir3,1, MacBookAir3,2 */
{ USB_DEVICE(0x05ac, 0x821b) },
+ /* Apple MacBookPro8,2 */
+ { USB_DEVICE(0x05ac, 0x821a) },
+
/* AVM BlueFRITZ! USB v2.0 */
{ USB_DEVICE(0x057c, 0x3800) },
@@ -690,7 +693,8 @@ static int btusb_send_frame(struct sk_buff *skb)
break;
case HCI_ACLDATA_PKT:
- if (!data->bulk_tx_ep || hdev->conn_hash.acl_num < 1)
+ if (!data->bulk_tx_ep || (hdev->conn_hash.acl_num < 1 &&
+ hdev->conn_hash.le_num < 1))
return -ENODEV;
urb = usb_alloc_urb(0, GFP_ATOMIC);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5248257..dddb85d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1048,6 +1048,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
"Starting driver with initial channel: %d MHz\n",
curchan->center_freq);
+ ath9k_ps_wakeup(sc);
+
mutex_lock(&sc->mutex);
/* setup initial channel */
@@ -1143,6 +1145,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
mutex_unlock:
mutex_unlock(&sc->mutex);
+ ath9k_ps_restore(sc);
+
return r;
}
diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
index c6a5fae..9cad061 100644
--- a/drivers/net/wireless/ath/carl9170/carl9170.h
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
@@ -443,6 +443,7 @@ struct carl9170_ba_stats {
u8 ampdu_len;
u8 ampdu_ack_len;
bool clear;
+ bool req;
};
struct carl9170_sta_info {
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index ede3d7e..89fe60a 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1355,6 +1355,7 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw *hw,
tid_info = rcu_dereference(sta_info->agg[tid]);
sta_info->stats[tid].clear = true;
+ sta_info->stats[tid].req = false;
if (tid_info) {
bitmap_zero(tid_info->bitmap, CARL9170_BAW_SIZE);
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index 0ef70b6..cb70ed7 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -383,6 +383,7 @@ static void carl9170_tx_status_process_ampdu(struct ar9170 *ar,
if (sta_info->stats[tid].clear) {
sta_info->stats[tid].clear = false;
+ sta_info->stats[tid].req = false;
sta_info->stats[tid].ampdu_len = 0;
sta_info->stats[tid].ampdu_ack_len = 0;
}
@@ -391,10 +392,16 @@ static void carl9170_tx_status_process_ampdu(struct ar9170 *ar,
if (txinfo->status.rates[0].count == 1)
sta_info->stats[tid].ampdu_ack_len++;
+ if (!(txinfo->flags & IEEE80211_TX_STAT_ACK))
+ sta_info->stats[tid].req = true;
+
if (super->f.mac_control & cpu_to_le16(AR9170_TX_MAC_IMM_BA)) {
super->s.rix = sta_info->stats[tid].ampdu_len;
super->s.cnt = sta_info->stats[tid].ampdu_ack_len;
txinfo->flags |= IEEE80211_TX_STAT_AMPDU;
+ if (sta_info->stats[tid].req)
+ txinfo->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
+
sta_info->stats[tid].clear = true;
}
spin_unlock_bh(&tid_info->lock);
diff --git a/drivers/net/wireless/iwlegacy/iwl-core.c b/drivers/net/wireless/iwlegacy/iwl-core.c
index d418b64..a209a0e 100644
--- a/drivers/net/wireless/iwlegacy/iwl-core.c
+++ b/drivers/net/wireless/iwlegacy/iwl-core.c
@@ -1805,6 +1805,15 @@ iwl_legacy_mac_change_interface(struct ieee80211_hw *hw,
mutex_lock(&priv->mutex);
+ if (!ctx->vif || !iwl_legacy_is_ready_rf(priv)) {
+ /*
+ * Huh? But wait ... this can maybe happen when
+ * we're in the middle of a firmware restart!
+ */
+ err = -EBUSY;
+ goto out;
+ }
+
interface_modes = ctx->interface_modes | ctx->exclusive_interface_modes;
if (!(interface_modes & BIT(newtype))) {
@@ -1832,6 +1841,7 @@ iwl_legacy_mac_change_interface(struct ieee80211_hw *hw,
/* success */
iwl_legacy_teardown_interface(priv, vif, true);
vif->type = newtype;
+ vif->p2p = newp2p;
err = iwl_legacy_setup_interface(priv, ctx);
WARN_ON(err);
/*
diff --git a/drivers/net/wireless/iwlegacy/iwl3945-base.c b/drivers/net/wireless/iwlegacy/iwl3945-base.c
index ab87e1b..28eb3d8 100644
--- a/drivers/net/wireless/iwlegacy/iwl3945-base.c
+++ b/drivers/net/wireless/iwlegacy/iwl3945-base.c
@@ -93,6 +93,7 @@ MODULE_LICENSE("GPL");
struct iwl_mod_params iwl3945_mod_params = {
.sw_crypto = 1,
.restart_fw = 1,
+ .disable_hw_scan = 1,
/* the rest are 0 by default */
};
@@ -3960,8 +3961,7 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
* "the hard way", rather than using device's scan.
*/
if (iwl3945_mod_params.disable_hw_scan) {
- dev_printk(KERN_DEBUG, &(pdev->dev),
- "sw scan support is deprecated\n");
+ IWL_DEBUG_INFO(priv, "Disabling hw_scan\n");
iwl3945_hw_ops.hw_scan = NULL;
}
@@ -4280,8 +4280,7 @@ MODULE_PARM_DESC(swcrypto,
"using software crypto (default 1 [software])");
module_param_named(disable_hw_scan, iwl3945_mod_params.disable_hw_scan,
int, S_IRUGO);
-MODULE_PARM_DESC(disable_hw_scan,
- "disable hardware scanning (default 0) (deprecated)");
+MODULE_PARM_DESC(disable_hw_scan, "disable hardware scanning (default 1)");
#ifdef CONFIG_IWLWIFI_LEGACY_DEBUG
module_param_named(debug, iwlegacy_debug_level, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "debug output mask");
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 4e36865..37509d0 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -730,8 +730,12 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x050d, 0x8053), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x050d, 0x805c), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x050d, 0x815c), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x050d, 0x825b), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x050d, 0x935a), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x050d, 0x935b), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Buffalo */
{ USB_DEVICE(0x0411, 0x00e8), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x0411, 0x016f), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Conceptronic */
{ USB_DEVICE(0x14b2, 0x3c06), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x14b2, 0x3c07), USB_DEVICE_DATA(&rt2800usb_ops) },
@@ -818,6 +822,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Pegatron */
{ USB_DEVICE(0x1d4d, 0x000c), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1d4d, 0x000e), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x1d4d, 0x0011), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Philips */
{ USB_DEVICE(0x0471, 0x200f), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Planex */
@@ -899,6 +904,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x148f, 0x3572), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Sitecom */
{ USB_DEVICE(0x0df6, 0x0041), USB_DEVICE_DATA(&rt2800usb_ops) },
+ /* Toshiba */
+ { USB_DEVICE(0x0930, 0x0a07), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Zinwell */
{ USB_DEVICE(0x5a57, 0x0284), USB_DEVICE_DATA(&rt2800usb_ops) },
#endif
@@ -961,7 +968,6 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x05a6, 0x0101), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1d4d, 0x0002), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1d4d, 0x0010), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x1d4d, 0x0011), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Planex */
{ USB_DEVICE(0x2019, 0x5201), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x2019, 0xab24), USB_DEVICE_DATA(&rt2800usb_ops) },
@@ -975,8 +981,6 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Sweex */
{ USB_DEVICE(0x177f, 0x0153), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x177f, 0x0313), USB_DEVICE_DATA(&rt2800usb_ops) },
- /* Toshiba */
- { USB_DEVICE(0x0930, 0x0a07), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Zyxel */
{ USB_DEVICE(0x0586, 0x341a), USB_DEVICE_DATA(&rt2800usb_ops) },
#endif
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ec6acf2..2c0d309 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -84,6 +84,8 @@ enum {
HCI_SERVICE_CACHE,
HCI_LINK_KEYS,
HCI_DEBUG_KEYS,
+
+ HCI_RESET,
};
/* HCI ioctl defines */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index b372fb8..2216620 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -186,6 +186,7 @@ static void hci_reset_req(struct hci_dev *hdev, unsigned long opt)
BT_DBG("%s %ld", hdev->name, opt);
/* Reset device */
+ set_bit(HCI_RESET, &hdev->flags);
hci_send_cmd(hdev, HCI_OP_RESET, 0, NULL);
}
@@ -213,8 +214,10 @@ static void hci_init_req(struct hci_dev *hdev, unsigned long opt)
/* Mandatory initialization */
/* Reset */
- if (!test_bit(HCI_QUIRK_NO_RESET, &hdev->quirks))
+ if (!test_bit(HCI_QUIRK_NO_RESET, &hdev->quirks)) {
+ set_bit(HCI_RESET, &hdev->flags);
hci_send_cmd(hdev, HCI_OP_RESET, 0, NULL);
+ }
/* Read Local Supported Features */
hci_send_cmd(hdev, HCI_OP_READ_LOCAL_FEATURES, 0, NULL);
@@ -584,6 +587,9 @@ static int hci_dev_do_close(struct hci_dev *hdev)
hci_req_cancel(hdev, ENODEV);
hci_req_lock(hdev);
+ /* Stop timer, it might be running */
+ del_timer_sync(&hdev->cmd_timer);
+
if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
hci_req_unlock(hdev);
return 0;
@@ -623,7 +629,6 @@ static int hci_dev_do_close(struct hci_dev *hdev)
/* Drop last sent command */
if (hdev->sent_cmd) {
- del_timer_sync(&hdev->cmd_timer);
kfree_skb(hdev->sent_cmd);
hdev->sent_cmd = NULL;
}
@@ -1074,6 +1079,7 @@ static void hci_cmd_timer(unsigned long arg)
BT_ERR("%s command tx timeout", hdev->name);
atomic_set(&hdev->cmd_cnt, 1);
+ clear_bit(HCI_RESET, &hdev->flags);
tasklet_schedule(&hdev->cmd_task);
}
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 3fbfa50..cebe7588 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -183,6 +183,8 @@ static void hci_cc_reset(struct hci_dev *hdev, struct sk_buff *skb)
BT_DBG("%s status 0x%x", hdev->name, status);
+ clear_bit(HCI_RESET, &hdev->flags);
+
hci_req_complete(hdev, HCI_OP_RESET, status);
}
@@ -1847,7 +1849,7 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
if (ev->opcode != HCI_OP_NOP)
del_timer(&hdev->cmd_timer);
- if (ev->ncmd) {
+ if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
tasklet_schedule(&hdev->cmd_task);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index c9f9cec..ca27f3a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1116,7 +1116,9 @@ int l2cap_ertm_send(struct sock *sk)
bt_cb(skb)->tx_seq = pi->next_tx_seq;
pi->next_tx_seq = (pi->next_tx_seq + 1) % 64;
- pi->unacked_frames++;
+ if (bt_cb(skb)->retries == 1)
+ pi->unacked_frames++;
+
pi->frames_sent++;
if (skb_queue_is_last(TX_QUEUE(sk), skb))
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index fc85e7a..f77308e 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -923,8 +923,9 @@ void __l2cap_sock_close(struct sock *sk, int reason)
rsp.status = cpu_to_le16(L2CAP_CS_NO_INFO);
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_RSP, sizeof(rsp), &rsp);
- } else
- l2cap_chan_del(sk, reason);
+ }
+
+ l2cap_chan_del(sk, reason);
break;
case BT_CONNECT:
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 0054c74..4476d8e 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1230,6 +1230,8 @@ static int user_confirm_reply(struct sock *sk, u16 index, unsigned char *data,
if (!hdev)
return cmd_status(sk, index, mgmt_op, ENODEV);
+ hci_dev_lock_bh(hdev);
+
if (!test_bit(HCI_UP, &hdev->flags)) {
err = cmd_status(sk, index, mgmt_op, ENETDOWN);
goto failed;
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 8c02469..af3c564 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -342,7 +342,7 @@ struct ieee80211_key *ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
if (IS_ERR(key->u.ccmp.tfm)) {
err = PTR_ERR(key->u.ccmp.tfm);
kfree(key);
- key = ERR_PTR(err);
+ return ERR_PTR(err);
}
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
@@ -360,7 +360,7 @@ struct ieee80211_key *ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
if (IS_ERR(key->u.aes_cmac.tfm)) {
err = PTR_ERR(key->u.aes_cmac.tfm);
kfree(key);
- key = ERR_PTR(err);
+ return ERR_PTR(err);
}
break;
}
@@ -400,11 +400,12 @@ int ieee80211_key_link(struct ieee80211_key *key,
{
struct ieee80211_key *old_key;
int idx, ret;
- bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+ bool pairwise;
BUG_ON(!sdata);
BUG_ON(!key);
+ pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
key->local = sdata->local;
key->sdata = sdata;
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 8212a8b..dbdebed 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -659,18 +659,14 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
struct ieee80211_local *local = hw_to_local(mp->hw);
u16 sta_cap = sta->ht_cap.cap;
+ int n_supported = 0;
int ack_dur;
int stbc;
int i;
/* fall back to the old minstrel for legacy stations */
- if (!sta->ht_cap.ht_supported) {
- msp->is_ht = false;
- memset(&msp->legacy, 0, sizeof(msp->legacy));
- msp->legacy.r = msp->ratelist;
- msp->legacy.sample_table = msp->sample_table;
- return mac80211_minstrel.rate_init(priv, sband, sta, &msp->legacy);
- }
+ if (!sta->ht_cap.ht_supported)
+ goto use_legacy;
BUILD_BUG_ON(ARRAY_SIZE(minstrel_mcs_groups) !=
MINSTREL_MAX_STREAMS * MINSTREL_STREAM_GROUPS);
@@ -725,7 +721,22 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
mi->groups[i].supported =
mcs->rx_mask[minstrel_mcs_groups[i].streams - 1];
+
+ if (mi->groups[i].supported)
+ n_supported++;
}
+
+ if (!n_supported)
+ goto use_legacy;
+
+ return;
+
+use_legacy:
+ msp->is_ht = false;
+ memset(&msp->legacy, 0, sizeof(msp->legacy));
+ msp->legacy.r = msp->ratelist;
+ msp->legacy.sample_table = msp->sample_table;
+ return mac80211_minstrel.rate_init(priv, sband, sta, &msp->legacy);
}
static void
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 5c1930b..aa5cc37 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -612,7 +612,8 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
skipped++;
continue;
}
- if (!time_after(jiffies, tid_agg_rx->reorder_time[j] +
+ if (skipped &&
+ !time_after(jiffies, tid_agg_rx->reorder_time[j] +
HT_RX_REORDER_BUF_TIMEOUT))
goto set_release_timer;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index ea427f4..fbf6f33 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -124,6 +124,15 @@ void cfg80211_bss_age(struct cfg80211_registered_device *dev,
}
/* must hold dev->bss_lock! */
+static void __cfg80211_unlink_bss(struct cfg80211_registered_device *dev,
+ struct cfg80211_internal_bss *bss)
+{
+ list_del_init(&bss->list);
+ rb_erase(&bss->rbn, &dev->bss_tree);
+ kref_put(&bss->ref, bss_release);
+}
+
+/* must hold dev->bss_lock! */
void cfg80211_bss_expire(struct cfg80211_registered_device *dev)
{
struct cfg80211_internal_bss *bss, *tmp;
@@ -134,9 +143,7 @@ void cfg80211_bss_expire(struct cfg80211_registered_device *dev)
continue;
if (!time_after(jiffies, bss->ts + IEEE80211_SCAN_RESULT_EXPIRE))
continue;
- list_del(&bss->list);
- rb_erase(&bss->rbn, &dev->bss_tree);
- kref_put(&bss->ref, bss_release);
+ __cfg80211_unlink_bss(dev, bss);
expired = true;
}
@@ -585,16 +592,23 @@ cfg80211_inform_bss_frame(struct wiphy *wiphy,
struct cfg80211_internal_bss *res;
size_t ielen = len - offsetof(struct ieee80211_mgmt,
u.probe_resp.variable);
- size_t privsz = wiphy->bss_priv_size;
+ size_t privsz;
+
+ if (WARN_ON(!mgmt))
+ return NULL;
+
+ if (WARN_ON(!wiphy))
+ return NULL;
if (WARN_ON(wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
(signal < 0 || signal > 100)))
return NULL;
- if (WARN_ON(!mgmt || !wiphy ||
- len < offsetof(struct ieee80211_mgmt, u.probe_resp.variable)))
+ if (WARN_ON(len < offsetof(struct ieee80211_mgmt, u.probe_resp.variable)))
return NULL;
+ privsz = wiphy->bss_priv_size;
+
res = kzalloc(sizeof(*res) + privsz + ielen, gfp);
if (!res)
return NULL;
@@ -662,11 +676,8 @@ void cfg80211_unlink_bss(struct wiphy *wiphy, struct cfg80211_bss *pub)
spin_lock_bh(&dev->bss_lock);
if (!list_empty(&bss->list)) {
- list_del_init(&bss->list);
+ __cfg80211_unlink_bss(dev, bss);
dev->bss_generation++;
- rb_erase(&bss->rbn, &dev->bss_tree);
-
- kref_put(&bss->ref, bss_release);
}
spin_unlock_bh(&dev->bss_lock);
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH v2] ROSE: prevent heap corruption with bad facilities
From: Jiri Bohac @ 2011-04-01 12:29 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Ben Hutchings, Dan Rosenberg, ralf, davem, netdev, security
In-Reply-To: <20110331180225.GA6677@midget.suse.cz>
On Thu, Mar 31, 2011 at 08:02:25PM +0200, Jiri Bohac wrote:
> However, I wonder how much sense it makes to continue parsing the
> facilities if an unknown facility family appears. We don't know
> the length of its data, so we will interpret each 16 bytes a new
oops, typo:
s/16 bytes a new/16 bits as a new/
> facilities header, hopefully soon bailing out on *p != 0x00.
>
> In case of a long packet where every other byte is zero, the loop
> will spam the kernel log with the printk ... which could probably
> be classified as a security problem on its own. So how about the
> following instead? I have no idea if this breaks some rose
> specification, though.
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-01 11:20 UTC (permalink / raw)
To: Grant Likely, Andres Salomon
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110331230522.GI437-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
Hi Grant,
On Thu, Mar 31, 2011 at 05:05:22PM -0600, Grant Likely wrote:
> On Wed, Feb 02, 2011 at 08:08:12PM -0800, Andres Salomon wrote:
> >
> > No need to explicitly set the cell's platform_data/data_size.
> >
> > In this case, move the various platform_data pointers
> > to driver_data. All of the clients which make use of it
> > are also changed.
> >
> > Signed-off-by: Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>
> > ---
> > drivers/dma/timb_dma.c | 2 +-
> > drivers/gpio/timbgpio.c | 5 +-
> > drivers/i2c/busses/i2c-ocores.c | 2 +-
> > drivers/i2c/busses/i2c-xiic.c | 2 +-
> > drivers/media/radio/radio-timb.c | 2 +-
> > drivers/media/video/timblogiw.c | 2 +-
> > drivers/mfd/timberdale.c | 81 +++++++++++++-------------------------
> > drivers/net/ks8842.c | 2 +-
> > drivers/spi/xilinx_spi.c | 2 +-
> > 9 files changed, 36 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> > index 3b88a4e..aa06ca4 100644
> > --- a/drivers/dma/timb_dma.c
> > +++ b/drivers/dma/timb_dma.c
> > @@ -684,7 +684,7 @@ static irqreturn_t td_irq(int irq, void *devid)
> >
> > static int __devinit td_probe(struct platform_device *pdev)
> > {
> > - struct timb_dma_platform_data *pdata = pdev->dev.platform_data;
> > + struct timb_dma_platform_data *pdata = platform_get_drvdata(pdev);
>
> Hold the phone. I know this has already been merged, but this isn't correct.
>
> drvdata is under the ownership of the driver, which means it should
> *not* be set when .probe() gets called. It is for driver private data
> to do with as it needs, usually for internal state.
We didn't merge that version of the patchset, but one getting the
platform_data pointer from mfd_get_data(). That introduces the issue you're
talking about below.
> Gah. Not all devices instantiated via mfd will be an mfd device,
> which means that the driver may very well expect an *entirely
> different* platform_device pointer; which further means a very high
> potential of incorrectly dereferenced structures (as evidenced by a
> patch series that is not bisectable). For instance, the xilinx ip
> cores are used by more than just mfd.
I agree. Since the vast majority of the MFD subdevices are MFD specific IPs, I
overlooked that part. The impacted drivers are the timberdale and the DaVinci
voice codec ones.
To fix that problem I propose 2 alternatives:
1) When declaring the sub devices cells, the MFD driver should specify an
mfd_data_size value for sub devices that are not MFD specific. It's the MFD
driver responsibility to set the cell properly, and the non MFD specific
drivers are kept MFD agnostic.
See my patch below for the timberdale case.
2) Revert the mfd_get_data() call for getting sub devices platform data
pointers. That was introduced to ease the MFD cell sharing work, so if we take
this route we'll need the cs5535 MFD driver to pass its cells as platform_data
pointer. Andres, can you confirm that this would be fine for the
mfd_clone_cell() routine to keep working ?
Patch for solution 1:
drivers/mfd/mfd-core.c | 13 ++++++++++---
drivers/mfd/timberdale.c | 11 +++++++++++
include/linux/mfd/core.h | 1 +
drivers/i2c/busses/i2c-ocores.c | 3 +--
drivers/i2c/busses/i2c-xiic.c | 3 +--
drivers/net/ks8842.c | 3 +--
drivers/spi/xilinx_spi.c | 3 +--
7 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index d01574d..8abe510 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -75,9 +75,16 @@ static int mfd_add_device(struct device *parent, int id,
pdev->dev.parent = parent;
- ret = platform_device_add_data(pdev, cell, sizeof(*cell));
- if (ret)
- goto fail_res;
+ if (cell->mfd_data_size > 0) {
+ ret = platform_device_add_data(pdev,
+ cell->mfd_data, cell->mfd_data_size);
+ if (ret)
+ goto fail_res;
+ } else {
+ ret = platform_device_add_data(pdev, cell, sizeof(*cell));
+ if (ret)
+ goto fail_res;
+ }
for (r = 0; r < cell->num_resources; r++) {
res[r].name = cell->resources[r].name;
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 94c6c8a..b4d2d09 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -396,6 +396,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
.num_resources = ARRAY_SIZE(timberdale_xiic_resources),
.resources = timberdale_xiic_resources,
.mfd_data = &timberdale_xiic_platform_data,
+ .mfd_data_size = sizeof(timberdale_xiic_platform_data)
},
{
.name = "timb-gpio",
@@ -420,12 +421,14 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = &timberdale_xspi_platform_data,
+ .mfd_data_size = sizeof(timberdale_xspi_platform_data)
},
{
.name = "ks8842",
.num_resources = ARRAY_SIZE(timberdale_eth_resources),
.resources = timberdale_eth_resources,
.mfd_data = &timberdale_ks8842_platform_data,
+ .mfd_data_size = sizeof(timberdale_ks8842_platform_data)
},
};
@@ -451,6 +454,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
.num_resources = ARRAY_SIZE(timberdale_xiic_resources),
.resources = timberdale_xiic_resources,
.mfd_data = &timberdale_xiic_platform_data,
+ .mfd_data_size = sizeof(timberdale_xiic_platform_data)
},
{
.name = "timb-gpio",
@@ -480,12 +484,14 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = &timberdale_xspi_platform_data,
+ .mfd_data_size = sizeof(timberdale_xspi_platform_data)
},
{
.name = "ks8842",
.num_resources = ARRAY_SIZE(timberdale_eth_resources),
.resources = timberdale_eth_resources,
.mfd_data = &timberdale_ks8842_platform_data,
+ .mfd_data_size = sizeof(timberdale_ks8842_platform_data)
},
};
@@ -506,6 +512,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
.num_resources = ARRAY_SIZE(timberdale_xiic_resources),
.resources = timberdale_xiic_resources,
.mfd_data = &timberdale_xiic_platform_data,
+ .mfd_data_size = sizeof(timberdale_xiic_platform_data)
},
{
.name = "timb-gpio",
@@ -530,6 +537,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = &timberdale_xspi_platform_data,
+ .mfd_data_size = sizeof(timberdale_xspi_platform_data)
},
};
@@ -550,6 +558,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
.num_resources = ARRAY_SIZE(timberdale_ocores_resources),
.resources = timberdale_ocores_resources,
.mfd_data = &timberdale_ocores_platform_data,
+ .mfd_data_size = sizeof(timberdale_ocores_platform_data)
},
{
.name = "timb-gpio",
@@ -574,12 +583,14 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = &timberdale_xspi_platform_data,
+ .mfd_data_size = sizeof(timberdale_xspi_platform_data)
},
{
.name = "ks8842",
.num_resources = ARRAY_SIZE(timberdale_eth_resources),
.resources = timberdale_eth_resources,
.mfd_data = &timberdale_ks8842_platform_data,
+ .mfd_data_size = sizeof(timberdale_ks8842_platform_data)
},
};
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index ad1b19a..3687e10 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -35,6 +35,7 @@ struct mfd_cell {
/* mfd_data can be used to pass data to client drivers */
void *mfd_data;
+ size_t mfd_data_size;
/*
* These resources can be specified relative to the parent device.
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fee1a26..1b46a9d 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -49,7 +49,6 @@
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/platform_device.h>
-#include <linux/mfd/core.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/wait.h>
@@ -306,7 +305,7 @@ static int __devinit ocores_i2c_probe(struct platform_device *pdev)
return -EIO;
}
- pdata = mfd_get_data(pdev);
+ pdata = pdev->dev.platform_data;
if (pdata) {
i2c->regstep = pdata->regstep;
i2c->clock_khz = pdata->clock_khz;
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index 9fbd7e6..a9c419e 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -34,7 +34,6 @@
#include <linux/errno.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
-#include <linux/mfd/core.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/wait.h>
@@ -705,7 +704,7 @@ static int __devinit xiic_i2c_probe(struct platform_device *pdev)
if (irq < 0)
goto resource_missing;
- pdata = mfd_get_data(pdev);
+ pdata = (struct xiic_i2c_platform_data *) pdev->dev.platform_data;
if (!pdata)
return -EINVAL;
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index efd44af..928b2b8 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -26,7 +26,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <linux/mfd/core.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -1146,7 +1145,7 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
struct resource *iomem;
struct net_device *netdev;
struct ks8842_adapter *adapter;
- struct ks8842_platform_data *pdata = mfd_get_data(pdev);
+ struct ks8842_platform_data *pdata = pdev->dev.platform_data;
u16 id;
unsigned i;
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index c69c6f2..4d2c75d 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -18,7 +18,6 @@
#include <linux/interrupt.h>
#include <linux/of.h>
#include <linux/platform_device.h>
-#include <linux/mfd/core.h>
#include <linux/spi/spi.h>
#include <linux/spi/spi_bitbang.h>
#include <linux/spi/xilinx_spi.h>
@@ -471,7 +470,7 @@ static int __devinit xilinx_spi_probe(struct platform_device *dev)
struct spi_master *master;
u8 i;
- pdata = mfd_get_data(dev);
+ pdata = dev->dev.platform_data;
if (pdata) {
num_cs = pdata->num_chipselect;
little_endian = pdata->little_endian;
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply related
* [PATCH] net: ethtool support to configure number of channels
From: Amit Kumar Salecha @ 2011-04-01 10:01 UTC (permalink / raw)
To: davem
Cc: netdev, ameen.rahman, sucheta.chakraborty, anirban.chakraborty,
Ben Hutchings
o Instead of cluttering struct ethtool_channels, defined channel type in
struct ethtool_channels, making it scalable for addition future channels.
Application needs to send different ioctl for each channel type.
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
but it is tigtly coupled with RX flow hash configuration.
o New channel id can be added in ethtool_channel_id to make it configurable.
o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
soon.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
include/linux/ethtool.h | 27 +++++++++++++++++++++++++++
net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c8fcbdd..cdb69d6 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -229,6 +229,28 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/* for configuring number of network channel */
+struct ethtool_channels {
+ __u32 cmd; /* ETHTOOL_{G,S}CHANNELS */
+ __u32 type; /* Channel type defined in ethtool_channel_id */
+
+ /* Read only attributes. These indicate the maximum number
+ * of channel the driver will allow the user to set.
+ */
+ __u32 max;
+
+ /* Values changeable by the user. The valid values are
+ * in the range 1 to the "*_max" counterpart above.
+ */
+ __u32 pending;
+};
+
+/* Channel ID is made up of a type */
+enum ethtool_channel_id {
+ ETH_CHAN_TYPE_RX = 0x1,
+ ETH_CHAN_TYPE_TX = 0x2
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd; /* ETHTOOL_{G,S}PAUSEPARAM */
@@ -802,6 +824,9 @@ struct ethtool_ops {
struct ethtool_rxfh_indir *);
int (*set_rxfh_indir)(struct net_device *,
const struct ethtool_rxfh_indir *);
+ int (*get_channels)(struct net_device *, struct ethtool_channels *);
+ int (*set_channels)(struct net_device *, struct ethtool_channels *);
+
};
#endif /* __KERNEL__ */
@@ -870,6 +895,8 @@ struct ethtool_ops {
#define ETHTOOL_GFEATURES 0x0000003a /* Get device offload settings */
#define ETHTOOL_SFEATURES 0x0000003b /* Change device offload settings */
+#define ETHTOOL_GCHANNELS 0x0000003c /* Get no of channels */
+#define ETHTOOL_SCHANNELS 0x0000003d /* Set no of channels */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 74ead9e..91c3c6d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1441,6 +1441,41 @@ static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->set_ringparam(dev, &ringparam);
}
+static noinline_for_stack int ethtool_get_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+ int rc;
+
+ if (!dev->ethtool_ops->get_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ rc = dev->ethtool_ops->get_channels(dev, &channels);
+ if (rc)
+ return rc;
+
+ if (copy_to_user(useraddr, &channels, sizeof(channels)))
+ return -EFAULT;
+ return 0;
+}
+
+static noinline_for_stack int ethtool_set_channels(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_channels channels;
+
+ if (!dev->ethtool_ops->set_channels)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&channels, useraddr, sizeof(channels)))
+ return -EFAULT;
+
+ return dev->ethtool_ops->set_channels(dev, &channels);
+}
+
static int ethtool_get_pauseparam(struct net_device *dev, void __user *useraddr)
{
struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM };
@@ -1953,6 +1988,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_one_feature(dev, useraddr, ethcmd);
break;
+ case ETHTOOL_GCHANNELS:
+ rc = ethtool_get_channels(dev, useraddr);
+ break;
+ case ETHTOOL_SCHANNELS:
+ rc = ethtool_set_channels(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/2] sctp: malloc enough room for asconf-ack chunk
From: Wei Yongjun @ 2011-04-01 9:42 UTC (permalink / raw)
To: David Miller, Vlad Yasevich; +Cc: lksctp, netdev@vger.kernel.org
In-Reply-To: <4D959D2E.40605@cn.fujitsu.com>
Sometime the ASCONF_ACK parameters can equal to the fourfold of
ASCONF parameters, this only happend in some special case:
ASCONF parameter is :
Unrecognized Parameter (4 bytes)
ASCONF_ACK parameter should be:
Error Cause Indication parameter (8 bytes header)
+ Error Cause (4 bytes header)
+ Unrecognized Parameter (4bytes)
Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic.
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs
EIP: 0060:[<c0717eae>] EFLAGS: 00010246 CPU: 0
EIP is at skb_put+0x60/0x70
EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0
ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000)
Stack:
c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40
c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004
00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960
Call Trace:
[<e1894fa4>] ? sctp_addto_chunk+0x4e/0x89 [sctp]
[<e1894fa4>] sctp_addto_chunk+0x4e/0x89 [sctp]
[<e1895a2b>] sctp_process_asconf+0x32f/0x3d1 [sctp]
[<e188d554>] sctp_sf_do_asconf+0xf8/0x173 [sctp]
[<e1890b02>] sctp_do_sm+0xb8/0x159 [sctp]
[<e18a2248>] ? sctp_cname+0x0/0x52 [sctp]
[<e189392d>] sctp_assoc_bh_rcv+0xac/0xe3 [sctp]
[<e1897d76>] sctp_inq_push+0x2d/0x30 [sctp]
[<e18a21b2>] sctp_rcv+0x7a7/0x83d [sctp]
[<c077a95c>] ? ipv4_confirm+0x118/0x125
[<c073a970>] ? nf_iterate+0x34/0x62
[<c074789d>] ? ip_local_deliver_finish+0x0/0x194
[<c074789d>] ? ip_local_deliver_finish+0x0/0x194
[<c0747992>] ip_local_deliver_finish+0xf5/0x194
[<c074789d>] ? ip_local_deliver_finish+0x0/0x194
[<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
[<c0747ab3>] ip_local_deliver+0x3e/0x44
[<c074789d>] ? ip_local_deliver_finish+0x0/0x194
[<c074775c>] ip_rcv_finish+0x29f/0x2c7
[<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
[<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
[<c0747cae>] ip_rcv+0x1f5/0x233
[<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
[<c071dce3>] __netif_receive_skb+0x310/0x336
[<c07221f3>] netif_receive_skb+0x4b/0x51
[<e0a4ed3d>] cp_rx_poll+0x1e7/0x29c [8139cp]
[<c072275e>] net_rx_action+0x65/0x13a
[<c0445a54>] __do_softirq+0xa1/0x149
[<c04459b3>] ? __do_softirq+0x0/0x149
<IRQ>
[<c0445891>] ? irq_exit+0x37/0x72
[<c040a7e9>] ? do_IRQ+0x81/0x95
[<c07b3670>] ? common_interrupt+0x30/0x38
[<c0428058>] ? native_safe_halt+0xa/0xc
[<c040f5d7>] ? default_idle+0x58/0x92
[<c0408fb0>] ? cpu_idle+0x96/0xb2
[<c0797989>] ? rest_init+0x5d/0x5f
[<c09fd90c>] ? start_kernel+0x34b/0x350
[<c09fd0cb>] ? i386_start_kernel+0xba/0xc1
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/sm_make_chunk.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index de98665..b3434cc 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3106,10 +3106,10 @@ struct sctp_chunk *sctp_process_asconf(struct sctp_association *asoc,
/* create an ASCONF_ACK chunk.
* Based on the definitions of parameters, we know that the size of
- * ASCONF_ACK parameters are less than or equal to the twice of ASCONF
+ * ASCONF_ACK parameters are less than or equal to the fourfold of ASCONF
* parameters.
*/
- asconf_ack = sctp_make_asconf_ack(asoc, serial, chunk_len * 2);
+ asconf_ack = sctp_make_asconf_ack(asoc, serial, chunk_len * 4);
if (!asconf_ack)
goto done;
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/2] sctp: fix auth_hmacs field's length of struct sctp_cookie
From: Wei Yongjun @ 2011-04-01 9:38 UTC (permalink / raw)
To: David Miller, Vlad Yasevich; +Cc: lksctp, netdev@vger.kernel.org
auth_hmacs field of struct sctp_cookie is used for store
Requested HMAC Algorithm Parameter, and each HMAC Identifier
is 2 bytes, so the length should be:
SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
include/net/sctp/structs.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index cc9185c..0f6e60a 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -422,7 +422,7 @@ struct sctp_cookie {
__u32 adaptation_ind;
__u8 auth_random[sizeof(sctp_paramhdr_t) + SCTP_AUTH_RANDOM_LENGTH];
- __u8 auth_hmacs[SCTP_AUTH_NUM_HMACS + 2];
+ __u8 auth_hmacs[SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2];
__u8 auth_chunks[sizeof(sctp_paramhdr_t) + SCTP_AUTH_MAX_CHUNKS];
/* This is a shim for my peer's INIT packet, followed by
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] net: ethtool support to configure number of RX rings
From: David Miller @ 2011-04-01 9:19 UTC (permalink / raw)
To: amit.salecha; +Cc: bhutchings, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FD10E8D0D@MNEXMB2.qlogic.org>
From: Amit Salecha <amit.salecha@qlogic.com>
Date: Fri, 1 Apr 2011 04:16:09 -0500
> Please discard this patch, I will resubmit patch based on Ben patch.
Ok.
^ permalink raw reply
* RE: [PATCH] net: ethtool support to configure number of RX rings
From: Amit Salecha @ 2011-04-01 9:16 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ameen Rahman,
Anirban Chakraborty
In-Reply-To: <1301576720.10056.112.camel@localhost>
>
> You could take this patch: http://patchwork.ozlabs.org/patch/65202/
> but drop the affinity control from it.
>
> Your implementation of set_channels() would then refuse all changes to
> the numbers of TX/other/combined channels.
>
> Ben.
>
Thanks Ben for sharing this.
David,
Please discard this patch, I will resubmit patch based on Ben patch.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* [PATCH] net: Order ports in same order as addresses in flow objects.
From: David Miller @ 2011-04-01 6:35 UTC (permalink / raw)
To: netdev
For consistency.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/flow.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index 37e77d6..c6d5fe5 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -26,8 +26,8 @@ struct flowi_common {
union flowi_uli {
struct {
- __be16 sport;
__be16 dport;
+ __be16 sport;
} ports;
struct {
@@ -36,8 +36,8 @@ union flowi_uli {
} icmpt;
struct {
- __le16 sport;
__le16 dport;
+ __le16 sport;
} dnports;
__be32 spi;
@@ -86,8 +86,8 @@ static inline void flowi4_init_output(struct flowi4 *fl4, int oif,
fl4->flowi4_secid = 0;
fl4->daddr = daddr;
fl4->saddr = saddr;
- fl4->fl4_sport = sport;
fl4->fl4_dport = dport;
+ fl4->fl4_sport = sport;
}
--
1.7.4.2
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2011-04-01 6:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Regression, GRE tunnels stopped working properly with multicast.
Fix from Timo Teräs.
2) Fix DMA mapping bugs in via-ircc IRDA driver, from Ben Hutchings.
3) Header length calc wrong in br_multicast_ipv6_rcv(), from Linus
Lüssing.
4) phy_init_hw() failures not handled, from Marc Kleine-Budde.
5) Support LG-VL600 4G modems properly, from Andrzej Zaborowski.
6) dev_forward_skb() needs to take TSO into account, from Daniel
Lezcano and Eric W. Biederman.
7) Memory leaks in atl2 driver, from Jesper Juhl.
8) Solos-PCI ATM driver fixes from Philip A. Prindeville
9) Missing RTNL locking in ip_fib_net_exit(), from Eric Dumazet.
10) Regression in connector, all netlink requests must be processed
synchronously now. From Patrick McHardy.
11) Fix erroneous memory failure kernel messages in SCTP hash table
allocation, reported by Dave Jones.
12) MLX4 driver use-after-free and event queue sizing fix from
Yevgeny Petrilin.
13) Fix another regression in atalk_release() added by the kernel
lock removal. Reported by Dave Jones.
The following changes since commit ecb78ab6f30106ab72a575a25b1cdfd1633b7ca2:
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 (2011-03-30 12:22:15 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Andrzej Zaborowski (1):
net/usb: Ethernet quirks for the LG-VL600 4G modem
Balaji G (1):
bridge: Fix compilation warning in function br_stp_recalculate_bridge_id()
Ben Hutchings (2):
via-ircc: Use pci_{get, set}_drvdata() instead of static pointer variable
via-ircc: Pass PCI device pointer to dma_{alloc, free}_coherent()
Daniel Lezcano (1):
netdev: fix mtu check when TSO is enabled
David S. Miller (3):
net: Fix warnings caused by MAX_SKB_FRAGS change.
sctp: Pass __GFP_NOWARN to hash table allocation attempts.
appletalk: Fix OOPS in atalk_release().
Eric Dumazet (1):
fib: add rtnl locking in ip_fib_net_exit
Jesper Juhl (1):
Atheros, atl2: Fix mem leaks in error paths of atl2_set_eeprom
Linus Lüssing (1):
bridge: mcast snooping, fix length check of snooped MLDv1/2
Marc Kleine-Budde (1):
phylib: phy_attach_direct: phy_init_hw can fail, add cleanup
Patrick McHardy (1):
connector: convert to synchronous netlink message processing
Peter Pan(潘卫平) (1):
bonding:typo in comment
Philip A. Prindeville (3):
atm/solos-pci: Use VPI.VCI notation uniformly.
atm/solos-pci: Don't include frame pseudo-header on transmit hex-dump
atm/solos-pci: Don't flap VCs when carrier state changes
Timo Teräs (1):
net: gre: provide multicast mappings for ipv4 and ipv6
Yevgeny Petrilin (2):
mlx4: Fixing use after free
mlx4: Fixing bad size of event queue buffer
drivers/atm/solos-pci.c | 39 ++----
drivers/connector/cn_queue.c | 58 ++-----
drivers/connector/connector.c | 47 ++----
drivers/net/atlx/atl2.c | 22 ++-
drivers/net/bonding/bond_alb.h | 2 +-
drivers/net/irda/via-ircc.c | 94 +++---------
drivers/net/mlx4/eq.c | 4 +-
drivers/net/mlx4/mcg.c | 3 +-
drivers/net/phy/phy_device.c | 8 +-
drivers/net/usb/Kconfig | 15 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/cdc_ether.c | 21 ++-
drivers/net/usb/lg-vl600.c | 346 ++++++++++++++++++++++++++++++++++++++++
drivers/net/usb/usbnet.c | 10 +-
include/linux/atmdev.h | 1 +
include/linux/connector.h | 16 +--
include/linux/skbuff.h | 2 +-
include/linux/usb/usbnet.h | 3 +
include/net/if_inet6.h | 16 ++
include/net/ip.h | 8 +
net/appletalk/ddp.c | 11 +-
net/atm/common.c | 1 +
net/bridge/br_multicast.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
net/core/dev.c | 24 +++-
net/ipv4/arp.c | 3 +
net/ipv4/fib_frontend.c | 2 +
net/ipv6/ndisc.c | 2 +
net/sctp/protocol.c | 4 +-
29 files changed, 543 insertions(+), 224 deletions(-)
create mode 100644 drivers/net/usb/lg-vl600.c
^ permalink raw reply
* Duplicated Acknowledgments
From: Florian Adamsky @ 2011-04-01 6:20 UTC (permalink / raw)
To: Netdev
Dear Kernel-Hackers,
I'm a security researcher and want to try out the opt-ack and lazy
opt-ack attack with different congestion avoidance systems and under
different environments. At first I want to dedicate myself to the lazy
opt-ack attack. For those of you how are not familiar with it: the
attacker has an modified TCP/IP stack which doesn't send any duplicated
acknowledgements. If the receiver is in slow start and doesn't get any
duplicated ack, he will introduce more and more packets into the
network. [1]
I'm not a kernel hacker but I know a litte bit of C. So I found the
function "tcp_send_dupack()". Additionally I wrote a sysctl for it to
activate and deactivate this behaviour. After trying this out I don't
get the expected results. I start to analyze my pcap file with tcptrace
and it says the attacker sends 22 duplicated acks. Attached you'll find
my changes on the code I made. I want to be absolutely sure that I
don't miss anything, so is there any other place in the source I have
to modify?
Thank you very much in advance. Btw I know that window updates are
looking like duplicated acks, I only want to be sure that the kernel is
not sending any duplicated acks.
Best wishes,
Florian
[1] http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf
--- /home/cit/linux-source-2.6.35/include/net/tcp.h 2011-03-01
15:40:39.000000000 +0100 +++ include/net/tcp.h 2011-03-25
22:57:08.403570245 +0100 @@ -205,6 +205,7 @@
extern int sysctl_tcp_timestamps;
extern int sysctl_tcp_window_scaling;
extern int sysctl_tcp_sack;
+extern int sysctl_tcp_send_dupack;
extern int sysctl_tcp_fin_timeout;
extern int sysctl_tcp_keepalive_time;
extern int sysctl_tcp_keepalive_probes;
--- /home/cit/linux-source-2.6.35/net/ipv4/sysctl_net_ipv4.c
2010-08-02 00:11:14.000000000 +0200 +++
net/ipv4/sysctl_net_ipv4.c 2011-03-25 22:44:32.687914571 +0100
@@ -141,6 +141,13 @@ .mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "tcp_send_dupack",
+ .data = &sysctl_tcp_send_dupack,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{
.procname = "tcp_retrans_collapse",
.data = &sysctl_tcp_retrans_collapse,
--- /home/cit/linux-source-2.6.35/net/ipv4/tcp_input.c
2011-03-01 15:40:39.000000000 +0100 +++ net/ipv4/tcp_input.c
2011-03-25 22:16:21.045352995 +0100 @@ -76,6 +76,7 @@
int sysctl_tcp_timestamps __read_mostly = 1;
int sysctl_tcp_window_scaling __read_mostly = 1;
int sysctl_tcp_sack __read_mostly = 1;
+int sysctl_tcp_send_dupack __read_mostly = 1;
int sysctl_tcp_fack __read_mostly = 1;
int sysctl_tcp_reordering __read_mostly = TCP_FASTRETRANS_THRESH;
int sysctl_tcp_ecn __read_mostly = 2;
@@ -5154,7 +5155,8 @@
tcp_paws_discard(sk, skb)) {
if (!th->rst) {
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_PAWSESTABREJECTED);
- tcp_send_dupack(sk, skb);
+ if (sysctl_tcp_send_dupack)
+ tcp_send_dupack(sk, skb);
goto discard;
}
/* Reset is accepted even if it did not pass PAWS. */
@@ -5169,7 +5171,8 @@
* bit is set, if so drop the segment and return)".
*/
if (!th->rst)
- tcp_send_dupack(sk, skb);
+ if (sysctl_tcp_send_dupack)
+ tcp_send_dupack(sk, skb);
goto discard;
}
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Eric Dumazet @ 2011-04-01 5:30 UTC (permalink / raw)
To: Changli Gao
Cc: "Oleg A. Arkhangelsky", Patrick McHardy, netfilter-devel,
netdev, Paul E McKenney
In-Reply-To: <AANLkTinBn+dKCaHN2Hq7kOocfMsvCO8wBpOgWd3VBV3g@mail.gmail.com>
Le vendredi 01 avril 2011 à 10:02 +0800, Changli Gao a écrit :
> On Thu, Mar 31, 2011 at 10:47 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I wonder if this is not hiding another bug.
> >
> > Adding an RCU grace period might reduce the probability window.
>
> What bug? This one?
>
Yes. I am saying your patch is a brown paper bag.
Real bug is elsewhere, and we must find it, not make it happen less
frequently.
Maybe its a missing barrier, and adding a full RCU grace period is a
waste (of cpu caches space, since call_rcu() fill a potential big list)
> >
> > By the time nf_conntrack_free(ct) is called, no other cpu/thread
> > could/should use ct, or ct->ext ?
>
> nat->ct may refer it.
>
conntrack must have a real problem of refcounting then.
Each time an object A has a reference to object B, we should increase B
refcount, so B cannot disappear.
nat->ct _cannot_ refer ct if we are freeing ct. Thats quite simple rule.
> >
> > Sure, another thread can find/pass_on ct in a lookup but should not use
> > it, since its refcount (ct_general.use) should be 0.
> >
> >
>
> As SLAB_DESTROY_BY_RCU is used, we should validate ct->orig_tuple too.
>
> There is another minor problem.
>
minor or serious ?
> nf_nat_core.c:
>
> 133 rcu_read_lock();
> 134 hlist_for_each_entry_rcu(nat, n,
> &net->ipv4.nat_bysource[h], bysourc e) {
> 135 ct = nat->ct;
> 136 if (same_src(ct, tuple) && nf_ct_zone(ct) == zone) {
> 137 /* Copy source part from reply tuple. */
> 138 nf_ct_invert_tuplepr(result,
> 139
> &ct->tuplehash[IP_CT_DIR_REPLY].tuple );
> 140 result->dst = tuple->dst;
> 141
> 142 if (in_range(result, range)) {
> 143 rcu_read_unlock();
> 144 return 1;
> 145 }
> 146 }
> 147 }
> 148 rcu_read_unlock();
>
> If the ct is reused, NAT mapping will be wrong. It isn't a serious
> problem, and can't be fixed, even though we check the reference
> counter before using it, but we can't validate it with the original
> tuple.
>
I call this a serious problem. netfilter is not a fuzzy logic.
> Maybe we can do it in this way
>
> ct = nat->ct;
> if (!nf_ct_is_dying(ct) &&
> atomic_inc_not_zero(&ct->ct_general.use))) {
> if (nf_ct_ext_find(ct, NF_CT_EXT_NAT) == nat) {
> /* ct is valid, do sth... */
> }
> nf_ct_put(ct);
> }
>
> I think two additional atomic operations are expensive. It isn't a good idea.
>
It depends. This is better than taking the conntrack lock.
SLAB_DESTROY_BY_RCU is not allowing for fuzzy logic. Rules are we _must_
take a reference on object after finding it, and _recheck_ validity of
the object before using it.
Another way to avoid atomic operations in find_appropriate_src() is to
use a seqcount (or seqlock), and change the seqcount every time
something is changed in ct.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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