* [PATCH for-net 2/2] net/mlx4_core: Call synchronize_irq() before freeing EQ buffer
From: Eli Cohen @ 2014-10-23 12:57 UTC (permalink / raw)
To: davem; +Cc: netdev, ogerlitz, Eli Cohen
In-Reply-To: <1414069047-30865-1-git-send-email-eli@mellanox.com>
After moving the EQ ownership to software effectively destroying it, call
synchronize_irq() to ensure that any handler routines running on other CPU
cores finish execution. Only then free the EQ buffer.
The same thing is done when we destroy a CQ which is one of the sources
generating interrupts. In the case of CQ we want to avoid completion handlers
on a CQ that was destroyed. In the case we do the same to avoid receiving
asynchronous events after the EQ has been destroyed and its buffers freed.
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/eq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index a49c9d11d8a5..49290a405903 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -1026,6 +1026,7 @@ static void mlx4_free_eq(struct mlx4_dev *dev,
pr_cont("\n");
}
}
+ synchronize_irq(eq->irq);
mlx4_mtt_cleanup(dev, &eq->mtt);
for (i = 0; i < npages; ++i)
--
2.1.2
^ permalink raw reply related
* Re: [RFC] tcp md5 use of alloc_percpu
From: Crestez Dan Leonard @ 2014-10-23 13:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Ahern, netdev
In-Reply-To: <1414042688.2094.30.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/23/2014 08:38 AM, Eric Dumazet wrote:
> On Wed, 2014-10-22 at 22:23 -0700, Eric Dumazet wrote:
> My updated patch would be :
>
> net/ipv4/tcp.c | 66 +++++++++++++++++++----------------------------
> 1 file changed, 28 insertions(+), 38 deletions(-)
>
I can confirm that this patch fixes my original issue.
I am working with a kernel based on 3.10 so I had to integrate 71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b as well.
Regards,
Leonard
^ permalink raw reply
* Re: [PATCH 02/14] net: dsa: Report known silicon revisions for Marvell 88E6060
From: Guenter Roeck @ 2014-10-23 13:20 UTC (permalink / raw)
To: Sergei Shtylyov, netdev
Cc: David S. Miller, Florian Fainelli, Andrew Lunn, linux-kernel
In-Reply-To: <5448F9B4.9010209@cogentembedded.com>
On 10/23/2014 05:51 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 10/23/2014 8:03 AM, Guenter Roeck wrote:
>
>> Report known silicon revisions when probing Marvell 88E6060 switches.
>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> drivers/net/dsa/mv88e6060.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>> diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
>> index 05b0ca3..c29aebe 100644
>> --- a/drivers/net/dsa/mv88e6060.c
>> +++ b/drivers/net/dsa/mv88e6060.c
>> @@ -69,8 +69,11 @@ static char *mv88e6060_probe(struct device *host_dev, int sw_addr)
>>
>> ret = mdiobus_read(bus, sw_addr + REG_PORT(0), 0x03);
>> if (ret >= 0) {
>> - ret &= 0xfff0;
>> if (ret == 0x0600)
>> + return "Marvell 88E6060 (A0)";
>> + if (ret == 0x0601 || ret == 0x0602)
>
> *else* *if*.
>
>> + return "Marvell 88E6060 (B0)";
>> + if ((ret & 0xfff0) == 0x0600)
>
> Likewise?
>
The if case returns, so the else would just introduce an unnecessary
additional level of indentation. I think nowadays even checkpatch
complains about an unnecessary else after return.
Thanks,
Guenter
^ permalink raw reply
* Re: [RFC] tcp md5 use of alloc_percpu
From: Eric Dumazet @ 2014-10-23 13:21 UTC (permalink / raw)
To: Jonathan Toppins; +Cc: David Ahern, Crestez Dan Leonard, netdev
In-Reply-To: <5448A72D.1050806@cumulusnetworks.com>
On Thu, 2014-10-23 at 02:58 -0400, Jonathan Toppins wrote:
> > + if (!pool) {
> > + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL,
> GFP_DMA | GFP_KERNEL
> This memory will possibly be used in a DMA correct? (thinking crypto
> hardware offload)
I am not sure this is the case, but this certainly can be added.
^ permalink raw reply
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck @ 2014-10-23 13:27 UTC (permalink / raw)
To: Richard Cochran
Cc: Florian Fainelli, netdev, David S. Miller, Andrew Lunn,
linux-kernel@vger.kernel.org
In-Reply-To: <20141023082444.GA4122@localhost.localdomain>
On 10/23/2014 01:24 AM, Richard Cochran wrote:
> On Wed, Oct 22, 2014 at 10:06:41PM -0700, Guenter Roeck wrote:
>> On 10/22/2014 09:37 PM, Florian Fainelli wrote:
>>> You probably want the number of temperature sensors to come from the
>>> switch driver, and support arbitrary number of temperature sensors?
>>
>> In that case we would need the number of sensors, pass a sensor index,
>> and create a dynamic number of attributes. The code would get much more
>> complex without real benefit unless there is such a chip - and if there is,
>> we can still change the code at that time. I would prefer to keep it simple
>> for now.
>
> Better to do it correctly, right from the start. There *will* be such
> a chip one day, and the person wanting to add it will appreciate the
> solid foundation (even if that person ends up being you ;).
>
That is really a matter of opinion; others say one should only introduce
complex infrastructure into the kernel if and when needed. I don't mind
changing the code to anticipate multiple sensors, but as I said it would
be more complex, obviously I would only have limited means to test it,
and, yes, by nature I tend to be one of the people who prefer to keep
things simple. Before I jump into doing this, I would prefer to get
guidance from the maintainer. David ?
Thanks,
Guenter
^ permalink raw reply
* [PATHC] net: napi_reuse_skb() should check pfmemalloc
From: Eric Dumazet @ 2014-10-23 13:30 UTC (permalink / raw)
To: Roman Gushchin
Cc: jeffrey.t.kirsher@intel.com, jesse.brandeburg@intel.com,
bruce.w.allan@intel.com, carolyn.wyborny@intel.com,
donald.c.skidmore@intel.com, gregory.v.rose@intel.com,
peter.p.waskiewicz.jr@intel.com, alexander.h.duyck@intel.com,
john.ronciak@intel.com, tushar.n.dave@intel.com,
davem@davemloft.net, sassmann@kpanic.de,
gregkh@linuxfoundation.org, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, "linux-kernel@vger.kernel.or
In-Reply-To: <1811414063272@webcorp02e.yandex-team.ru>
From: Eric Dumazet <edumazet@google.com>
Do not reuse skb if it was pfmemalloc tainted, otherwise
future frame might be dropped anyway.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index b793e3521a36..945bbd001359 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4157,6 +4157,10 @@ EXPORT_SYMBOL(napi_gro_receive);
static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
{
+ if (unlikely(skb->pfmemalloc)) {
+ consume_skb(skb);
+ return;
+ }
__skb_pull(skb, skb_headlen(skb));
/* restore the reserve we had after netdev_alloc_skb_ip_align() */
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN - skb_headroom(skb));
^ permalink raw reply related
* Re: [PATCH 1/2] net: dsa: Error out on tagging protocol mismatches
From: Andrew Lunn @ 2014-10-23 13:32 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, davem, netdev, alexander.h.duyck
In-Reply-To: <544841EC.4070103@gmail.com>
On Wed, Oct 22, 2014 at 04:46:52PM -0700, Florian Fainelli wrote:
> On 10/22/2014 04:35 PM, Andrew Lunn wrote:
> > If there is a mismatch between enabled tagging protocols and the
> > protocol the switch supports, error out, rather than continue with a
> > situation which is unlikely to work.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > cc: alexander.h.duyck@intel.com
> > ---
> > net/dsa/dsa.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> > index 22f34cf4cb27..8a31bd81a315 100644
> > --- a/net/dsa/dsa.c
> > +++ b/net/dsa/dsa.c
> > @@ -175,7 +175,8 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
> > break;
> > #endif
> > default:
> > - break;
> > + ret = -ENOPROTOOPT;
> > + goto out;
> > }
>
> This prevents using a switch driver without tagging, which is something
> that you might want to do (link setup, ethtool stats, EEE etc...).
Hi Florian
I didn't know that was a use case.
So i assume such a driver would use DSA_TAG_PROTO_NONE? So all i need
to do is add that as a case value to the switch statement, and we
should cover that use case, and still be able to detect a mismatch.
v2 patch soon.
Andrew
^ permalink raw reply
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Andrew Lunn @ 2014-10-23 13:47 UTC (permalink / raw)
To: Guenter Roeck
Cc: Florian Fainelli, netdev, David S. Miller, Andrew Lunn,
linux-kernel@vger.kernel.org
In-Reply-To: <54488CE1.2000106@roeck-us.net>
> >>+static DEVICE_ATTR_RO(temp1_input);
> >
> >You probably want the number of temperature sensors to come from the
> >switch driver, and support arbitrary number of temperature sensors?
>
> In that case we would need the number of sensors, pass a sensor index,
> and create a dynamic number of attributes. The code would get much more
> complex without real benefit unless there is such a chip
We are two different use cases here:
One switch chip with multiple temperature sensors
Multiple switch chips, each with its own temperature sensor.
I don't know of any hardware using either of these uses cases, but
they could appear in the future.
If we are not doing the generic implementation now, how about avoiding
an ABI break in the future, by hard coding the sensors with .0.0 on
the end?
Andrew
^ permalink raw reply
* Re: [PATHC] net: napi_reuse_skb() should check pfmemalloc
From: Roman Gushchin @ 2014-10-23 13:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: alexander.h.duyck@intel.com, netdev@vger.kernel.org,
sassmann@kpanic.de, e1000-devel@lists.sourceforge.net,
peter.p.waskiewicz.jr@intel.com, bruce.w.allan@intel.com,
jesse.brandeburg@intel.com, davem@davemloft.net,
john.ronciak@intel.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1414071030.2094.46.camel@edumazet-glaptop2.roam.corp.google.com>
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
--
@klamm
23.10.2014, 17:30, "Eric Dumazet" <eric.dumazet@gmail.com>:
> From: Eric Dumazet <edumazet@google.com>
>
> Do not reuse skb if it was pfmemalloc tainted, otherwise
> future frame might be dropped anyway.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/core/dev.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b793e3521a36..945bbd001359 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4157,6 +4157,10 @@ EXPORT_SYMBOL(napi_gro_receive);
>
> static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
> {
> + if (unlikely(skb->pfmemalloc)) {
> + consume_skb(skb);
> + return;
> + }
> __skb_pull(skb, skb_headlen(skb));
> /* restore the reserve we had after netdev_alloc_skb_ip_align() */
> skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN - skb_headroom(skb));
------------------------------------------------------------------------------
_______________________________________________
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
* Re: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM access functions
From: Andrew Lunn @ 2014-10-23 13:54 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Florian Fainelli, Andrew Lunn,
linux-kernel
In-Reply-To: <1414037002-25528-11-git-send-email-linux@roeck-us.net>
On Wed, Oct 22, 2014 at 09:03:18PM -0700, Guenter Roeck wrote:
> MV88E6352 supports read and write access to its configuration eeprom.
Hi Guenter
I don't have the datasheet for the MV88E6352. Is the EEPROM built in,
or external on an i2c bus?
> +static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
> +{
> + return 0x200;
> +}
How do you handle the case of it being external and not populated.
Would it not be better to try to detect it here, and return 0 if it
does not exist?
Andrew
^ permalink raw reply
* ixgbe driver fails occasionally since ee98b577e7711d5890ded2c7b05578a29512bd39
From: Scott Harrison @ 2014-10-23 14:06 UTC (permalink / raw)
To: netdev
Hi,
I was asked to raise this issue here.
https://bugzilla.kernel.org/show_bug.cgi?id=86591
lspci ->
03:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
With the fibre 10Gbs SFP occasionally on reboot we get
[ 15.104726] ixgbe 0000:03:00.0 eth0: detected SFP+: 5
[ 19.735155] ixgbe 0000:03:00.0 eth0: setup link failed with code -14
Probably about 1 in 10 boots. With the 1Gbs Copper SFP it works fine.
kernel 3.14.8 worked fine, but on upgrading to 3.16.1 it fails in this way.
I have narrowed it down to the commit
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=ee98b577e7711d5890ded2c7b05578a29512bd39
I don't know enough about the hardware to understand why the change
sometimes causes the failure, and was hoping someone else would. Reverting
this commit on 3.16.1 fixes the issue.
If you need any more information please ask.
Scott.
--
Software Engineer
Cisco.com - http://www.cisco.com
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorised to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply
* Re: [RFC] tcp md5 use of alloc_percpu
From: Eric Dumazet @ 2014-10-23 14:43 UTC (permalink / raw)
To: Jonathan Toppins; +Cc: David Ahern, Crestez Dan Leonard, netdev
In-Reply-To: <1414070490.2094.39.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-10-23 at 06:21 -0700, Eric Dumazet wrote:
> On Thu, 2014-10-23 at 02:58 -0400, Jonathan Toppins wrote:
>
> > > + if (!pool) {
> > > + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL,
> > GFP_DMA | GFP_KERNEL
> > This memory will possibly be used in a DMA correct? (thinking crypto
> > hardware offload)
>
> I am not sure this is the case, but this certainly can be added.
>
Yes, this is not the case.
The real problem is because sg_set_buf() does the following :
sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
So it assumes a memory range is not spanning multiple pages.
So maybe a simpler patch would be :
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1bec4e76d88c5852d8ba3392b22aa58d6453ab4d..53e355199437b00836635c5919f2f1a1ae237271 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2886,10 +2886,17 @@ static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool __percpu *pool)
static void __tcp_alloc_md5sig_pool(void)
{
- int cpu;
struct tcp_md5sig_pool __percpu *pool;
+ size_t sz;
+ int cpu;
- pool = alloc_percpu(struct tcp_md5sig_pool);
+ /* sg_set_buf() assumes a contiguous memory area, but alloc_percpu()
+ * can use vmalloc(). So make sure we ask an alignment so that
+ * tcp_md5sig_pool is located in a single page.
+ */
+ BUILD_BUG_ON(sizeof(struct tcp_md5sig_pool) > PAGE_SIZE);
+ sz = roundup_pow_of_two(sizeof(struct tcp_md5sig_pool));
+ pool = __alloc_percpu(sz, sz);
if (!pool)
return;
^ permalink raw reply related
* Re: [RFC] tcp md5 use of alloc_percpu
From: Crestez Dan Leonard @ 2014-10-23 14:46 UTC (permalink / raw)
To: Eric Dumazet, Jonathan Toppins; +Cc: David Ahern, netdev
In-Reply-To: <1414070490.2094.39.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Oct 23, 2014 at 4:21 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-23 at 02:58 -0400, Jonathan Toppins wrote:
>
>> > + if (!pool) {
>> > + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL,
>> GFP_DMA | GFP_KERNEL
>> This memory will possibly be used in a DMA correct? (thinking crypto
>> hardware offload)
>
> I am not sure this is the case, but this certainly can be added.
As far as I know what GFP_DMA actually does is restrict allocation to
low memory addresses under 24 bits for very old devices. There is also
GFP_DMA32 which restricts to addresses under 32 bytes (for device
which don't support 64 bit addresses).
This kind of stuff only belongs in device drivers where the exact
hardware limitations are known. I don't think crypto devices with this
kind of limitations can be exposed through the crypto API that the
md5sig feature uses.
--
Regards,
Leonard
^ permalink raw reply
* Re: [RFC PATCH v3 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Nicolas Dichtel @ 2014-10-23 15:12 UTC (permalink / raw)
To: Erik Kline, netdev; +Cc: ben, lorenzo, hannes
In-Reply-To: <1414058399-19695-1-git-send-email-ek@google.com>
Le 23/10/2014 11:59, Erik Kline a écrit :
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
>
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
>
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
>
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
>
> Also, because optimistic nodes can receive frames, issue
> an RTM_NEWADDR as soon as DAD starts. If DAD fails, a separate
> RTM_DELADDR is always sent.
>
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
>
> Signed-off-by: Erik Kline <ek@google.com>
I agree with the principle of the patch. This option is useful.
Thank you,
Nicolas
^ permalink raw reply
* Re: Possible wireless issue introduced in next-20140930
From: Murilo Opsfelder Araujo @ 2014-10-23 15:26 UTC (permalink / raw)
To: Mike Galbraith
Cc: linux-kernel, netdev, linux-wireless, Larry Finger,
John W. Linville, Thadeu Cascardo
In-Reply-To: <1414041815.5228.37.camel@marge.simpson.net>
On 10/23/2014 03:23 AM, Mike Galbraith wrote:
> On Thu, 2014-10-23 at 01:17 -0200, Murilo Opsfelder Araujo wrote:
>> Hello, everyone.
>>
>> With next-20140930 my laptop does not work, i.e. after I enter my login
>> and password in KDM, the entire system becomes unresponsive and I need
>> to reset it in order to reboot (it does not even show the KDE splash
>> screen).
>>
>> It was working pretty fine with next-20140926.
>>
>> I've also tested with next-20141022 and v3.18-rc1 and no luck.
>>
>> git bisect pointed me to the commit below [1]. My wireless card is a
>> RTL8191SEvA [2].
>
> Mine is RTL8191SEvB.
>
> I was going to bisect RTL8191SE regression when I got a chance, but you
> beat me to it.
>
>> commit 38506ecefab911785d5e1aa5889f6eeb462e0954
>> Author: Larry Finger <Larry.Finger@lwfinger.net>
>> Date: Mon Sep 22 09:39:19 2014 -0500
>>
>> rtlwifi: rtl_pci: Start modification for new drivers
>
> Did you confirm that bisection result, ie revert it at HEAD of whichever
> tree you bisected?
>
> The revert (master) removed some warnings on the way to kaboom here, but
> the drivers is still toxic. My log follows in case it's the same thing.
> I can't go hunting atm, maybe during the weekend if the problem hasn't
> evaporate by then.
next-20141023 does not work as well.
With commit 38506ecefab911785d5e1aa5889f6eeb462e0954 reverted, kernel
blows up very early in boot.
Cascardo (CC:) helped me to investigate and it seems that when
rtlpriv->cfg->ops->get_btc_status() is called, it is pointing to a NULL
function.
With the changes below, written by Cascardo, I could get rid of
oops/panic and system booted normally. But there was no wifi network
available (like if wifi card was disabled).
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index 1bff2a0..807f0f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -253,6 +253,11 @@ static void rtl92s_deinit_sw_vars(struct
ieee80211_hw *hw)
}
}
+static bool rtl92s_get_btc_status(void)
+{
+ return false;
+}
+
static struct rtl_hal_ops rtl8192se_hal_ops = {
.init_sw_vars = rtl92s_init_sw_vars,
.deinit_sw_vars = rtl92s_deinit_sw_vars,
@@ -294,6 +299,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
.set_bbreg = rtl92s_phy_set_bb_reg,
.get_rfreg = rtl92s_phy_query_rf_reg,
.set_rfreg = rtl92s_phy_set_rf_reg,
+ .get_btc_status = rtl92s_get_btc_status,
};
static struct rtl_mod_params rtl92se_mod_params = {
--
Murilo
^ permalink raw reply related
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-23 15:33 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <20141023122750.GP4977@linux.vnet.ibm.com>
On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote:
> > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote:
> > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote:
> > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney
> > > > > <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > [ . . . ]
> > >
> > > > > > Don't get me wrong -- the fact that this kthread appears to
> > > > > > have
> > > > > > blocked within rcu_barrier() for 120 seconds means that
> > > > > > something is
> > > > > > most definitely wrong here. I am surprised that there are no
> > > > > > RCU CPU
> > > > > > stall warnings, but perhaps the blockage is in the callback
> > > > > > execution
> > > > > > rather than grace-period completion. Or something is
> > > > > > preventing this
> > > > > > kthread from starting up after the wake-up callback executes.
> > > > > > Or...
> > > > > >
> > > > > > Is this thing reproducible?
> > > > >
> > > > > I've added Yanko on CC, who reported the backtrace above and can
> > > > > recreate it reliably. Apparently reverting the RCU merge commit
> > > > > (d6dd50e) and rebuilding the latest after that does not show the
> > > > > issue. I'll let Yanko explain more and answer any questions you
> > > > > have.
> > > >
> > > > - It is reproducible
> > > > - I've done another build here to double check and its definitely
> > > > the rcu merge
> > > > that's causing it.
> > > >
> > > > Don't think I'll be able to dig deeper, but I can do testing if
> > > > needed.
> > >
> > > Please! Does the following patch help?
> >
> > Nope, doesn't seem to make a difference to the modprobe ppp_generic
> > test
>
> Well, I was hoping. I will take a closer look at the RCU merge commit
> and see what suggests itself. I am likely to ask you to revert specific
> commits, if that works for you.
Well, rather than reverting commits, could you please try testing the
following commits?
11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks after spawning)
73a860cd58a1 (rcu: Replace flush_signals() with WARN_ON(signal_pending()))
c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())
For whatever it is worth, I am guessing this one.
a53dd6a65668 (rcutorture: Add RCU-tasks tests to default rcutorture list)
If any of the above fail, this one should also fail.
Also, could you please send along your .config?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 02/14] net: dsa: Report known silicon revisions for Marvell 88E6060
From: Sergei Shtylyov @ 2014-10-23 16:00 UTC (permalink / raw)
To: Guenter Roeck, netdev
Cc: David S. Miller, Florian Fainelli, Andrew Lunn, linux-kernel
In-Reply-To: <5449008C.4050505@roeck-us.net>
On 10/23/2014 05:20 PM, Guenter Roeck wrote:
>>> Report known silicon revisions when probing Marvell 88E6060 switches.
>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>> ---
>>> drivers/net/dsa/mv88e6060.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>> diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
>>> index 05b0ca3..c29aebe 100644
>>> --- a/drivers/net/dsa/mv88e6060.c
>>> +++ b/drivers/net/dsa/mv88e6060.c
>>> @@ -69,8 +69,11 @@ static char *mv88e6060_probe(struct device *host_dev,
>>> int sw_addr)
>>>
>>> ret = mdiobus_read(bus, sw_addr + REG_PORT(0), 0x03);
>>> if (ret >= 0) {
>>> - ret &= 0xfff0;
>>> if (ret == 0x0600)
>>> + return "Marvell 88E6060 (A0)";
>>> + if (ret == 0x0601 || ret == 0x0602)
>> *else* *if*.
>>> + return "Marvell 88E6060 (B0)";
>>> + if ((ret & 0xfff0) == 0x0600)
>> Likewise?
> The if case returns, so the else would just introduce an unnecessary
> additional level of indentation.
Not really.
> I think nowadays even checkpatch
> complains about an unnecessary else after return.
You're right about the *return* though. I should have stayed silent.
> Thanks,
> Guenter
WBR, Sergei
^ permalink raw reply
* [PATCH 1/1 net-next] libceph: remove unused variable in handle_reply()
From: Fabian Frederick @ 2014-10-23 16:15 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Sage Weil, David S. Miller, ceph-devel, netdev
osdmap_epoch is redundant with reassert_epoch and unused.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ceph/osd_client.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
index f3fc54e..432bd75 100644
--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -1700,7 +1700,6 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
int err;
u32 reassert_epoch;
u64 reassert_version;
- u32 osdmap_epoch;
int already_completed;
u32 bytes;
unsigned int i;
@@ -1725,7 +1724,6 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
result = ceph_decode_32(&p);
reassert_epoch = ceph_decode_32(&p);
reassert_version = ceph_decode_64(&p);
- osdmap_epoch = ceph_decode_32(&p);
/* lookup */
down_read(&osdc->map_sem);
--
1.9.3
^ permalink raw reply related
* Re: [RFC] tcp md5 use of alloc_percpu
From: Crestez Dan Leonard @ 2014-10-23 16:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jonathan Toppins, David Ahern, netdev
In-Reply-To: <1414075405.20845.6.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/23/2014 05:43 PM, Eric Dumazet wrote:
> On Thu, 2014-10-23 at 06:21 -0700, Eric Dumazet wrote:
>> On Thu, 2014-10-23 at 02:58 -0400, Jonathan Toppins wrote:
>>
>>>> + if (!pool) {
>>>> + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL,
>>> GFP_DMA | GFP_KERNEL
>>> This memory will possibly be used in a DMA correct? (thinking crypto
>>> hardware offload)
>>
>> I am not sure this is the case, but this certainly can be added.
>>
>
> Yes, this is not the case.
>
>
> The real problem is because sg_set_buf() does the following :
> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
>
> So it assumes a memory range is not spanning multiple pages.
Doesn't virt_to_page also assume that the memory is not from vmalloc?
Making this portable would require checking if is_vmalloc_addr and doing
vmalloc_to_page instead. Easier to just kmalloc instead.
Regards,
Leonard
^ permalink raw reply
* [PATCH 1/1 net-next] 9P: remove unused variable in p9_fd_create()
From: Fabian Frederick @ 2014-10-23 16:19 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, v9fs-developer, netdev
p is initialized but unused.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/9p/trans_fd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 80d08f6..c73b894 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -1013,7 +1013,6 @@ p9_fd_create(struct p9_client *client, const char *addr, char *args)
{
int err;
struct p9_fd_opts opts;
- struct p9_trans_fd *p;
parse_opts(args, &opts);
@@ -1026,7 +1025,6 @@ p9_fd_create(struct p9_client *client, const char *addr, char *args)
if (err < 0)
return err;
- p = (struct p9_trans_fd *) client->trans;
p9_conn_create(client);
return 0;
--
1.9.3
^ permalink raw reply related
* [PATCH 1/1 net-next] Bluetooth: fix shadow warning in hci_disconnect()
From: Fabian Frederick @ 2014-10-23 16:22 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
David S. Miller, linux-bluetooth, netdev
use cpr for hci_cp_read_clock_offset instead of cp
(already defined above).
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/bluetooth/hci_conn.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b9517bd..6151e09 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -141,10 +141,10 @@ int hci_disconnect(struct hci_conn *conn, __u8 reason)
*/
if (conn->type == ACL_LINK && conn->role == HCI_ROLE_MASTER) {
struct hci_dev *hdev = conn->hdev;
- struct hci_cp_read_clock_offset cp;
+ struct hci_cp_read_clock_offset cpr;
- cp.handle = cpu_to_le16(conn->handle);
- hci_send_cmd(hdev, HCI_OP_READ_CLOCK_OFFSET, sizeof(cp), &cp);
+ cpr.handle = cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_READ_CLOCK_OFFSET, sizeof(cpr), &cpr);
}
conn->state = BT_DISCONN;
--
1.9.3
^ permalink raw reply related
* [PATCH RFC v4 12/17] virtio_net: v1.0 support
From: Michael S. Tsirkin @ 2014-10-23 16:24 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Cornelia Huck, virtualization, netdev, linux-api
In-Reply-To: <1414081380-14623-1-git-send-email-mst@redhat.com>
Based on patches by Rusty Russell, Cornelia Huck.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/uapi/linux/virtio_net.h | 15 ++++++++-------
drivers/net/virtio_net.c | 34 +++++++++++++++++++++-------------
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 172a7f0..b5f1677 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -28,6 +28,7 @@
#include <linux/types.h>
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
+#include <linux/virtio_types.h>
#include <linux/if_ether.h>
/* The feature bitmap for virtio net */
@@ -84,17 +85,17 @@ struct virtio_net_hdr {
#define VIRTIO_NET_HDR_GSO_TCPV6 4 // GSO frame, IPv6 TCP
#define VIRTIO_NET_HDR_GSO_ECN 0x80 // TCP has ECN set
__u8 gso_type;
- __u16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
- __u16 gso_size; /* Bytes to append to hdr_len per frame */
- __u16 csum_start; /* Position to start checksumming from */
- __u16 csum_offset; /* Offset after that to place checksum */
+ __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
+ __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
+ __virtio16 csum_start; /* Position to start checksumming from */
+ __virtio16 csum_offset; /* Offset after that to place checksum */
};
/* This is the version of the header to use when the MRG_RXBUF
* feature has been negotiated. */
struct virtio_net_hdr_mrg_rxbuf {
struct virtio_net_hdr hdr;
- __u16 num_buffers; /* Number of merged rx buffers */
+ __virtio16 num_buffers; /* Number of merged rx buffers */
};
/*
@@ -149,7 +150,7 @@ typedef __u8 virtio_net_ctrl_ack;
* VIRTIO_NET_F_CTRL_MAC_ADDR feature is available.
*/
struct virtio_net_ctrl_mac {
- __u32 entries;
+ __virtio32 entries;
__u8 macs[][ETH_ALEN];
} __attribute__((packed));
@@ -193,7 +194,7 @@ struct virtio_net_ctrl_mac {
* specified.
*/
struct virtio_net_ctrl_mq {
- __u16 virtqueue_pairs;
+ __virtio16 virtqueue_pairs;
};
#define VIRTIO_NET_CTRL_MQ 4
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d75256bd..57cbc7d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -347,13 +347,14 @@ err:
}
static struct sk_buff *receive_mergeable(struct net_device *dev,
+ struct virtnet_info *vi,
struct receive_queue *rq,
unsigned long ctx,
unsigned int len)
{
void *buf = mergeable_ctx_to_buf_address(ctx);
struct skb_vnet_hdr *hdr = buf;
- int num_buf = hdr->mhdr.num_buffers;
+ u16 num_buf = virtio16_to_cpu(rq->vq->vdev, hdr->mhdr.num_buffers);
struct page *page = virt_to_head_page(buf);
int offset = buf - page_address(page);
unsigned int truesize = max(len, mergeable_ctx_to_buf_truesize(ctx));
@@ -369,7 +370,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
ctx = (unsigned long)virtqueue_get_buf(rq->vq, &len);
if (unlikely(!ctx)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
- dev->name, num_buf, hdr->mhdr.num_buffers);
+ dev->name, num_buf,
+ virtio16_to_cpu(rq->vq->vdev,
+ hdr->mhdr.num_buffers));
dev->stats.rx_length_errors++;
goto err_buf;
}
@@ -454,7 +457,7 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
}
if (vi->mergeable_rx_bufs)
- skb = receive_mergeable(dev, rq, (unsigned long)buf, len);
+ skb = receive_mergeable(dev, vi, rq, (unsigned long)buf, len);
else if (vi->big_packets)
skb = receive_big(dev, rq, buf, len);
else
@@ -473,8 +476,8 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
pr_debug("Needs csum!\n");
if (!skb_partial_csum_set(skb,
- hdr->hdr.csum_start,
- hdr->hdr.csum_offset))
+ virtio16_to_cpu(vi->vdev, hdr->hdr.csum_start),
+ virtio16_to_cpu(vi->vdev, hdr->hdr.csum_offset)))
goto frame_err;
} else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -505,7 +508,8 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (hdr->hdr.gso_type & VIRTIO_NET_HDR_GSO_ECN)
skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ECN;
- skb_shinfo(skb)->gso_size = hdr->hdr.gso_size;
+ skb_shinfo(skb)->gso_size = virtio16_to_cpu(vi->vdev,
+ hdr->hdr.gso_size);
if (skb_shinfo(skb)->gso_size == 0) {
net_warn_ratelimited("%s: zero gso size.\n", dev->name);
goto frame_err;
@@ -867,16 +871,19 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
if (skb->ip_summed == CHECKSUM_PARTIAL) {
hdr->hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
- hdr->hdr.csum_start = skb_checksum_start_offset(skb);
- hdr->hdr.csum_offset = skb->csum_offset;
+ hdr->hdr.csum_start = cpu_to_virtio16(vi->vdev,
+ skb_checksum_start_offset(skb));
+ hdr->hdr.csum_offset = cpu_to_virtio16(vi->vdev,
+ skb->csum_offset);
} else {
hdr->hdr.flags = 0;
hdr->hdr.csum_offset = hdr->hdr.csum_start = 0;
}
if (skb_is_gso(skb)) {
- hdr->hdr.hdr_len = skb_headlen(skb);
- hdr->hdr.gso_size = skb_shinfo(skb)->gso_size;
+ hdr->hdr.hdr_len = cpu_to_virtio16(vi->vdev, skb_headlen(skb));
+ hdr->hdr.gso_size = cpu_to_virtio16(vi->vdev,
+ skb_shinfo(skb)->gso_size);
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
@@ -1105,7 +1112,7 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs)
if (!vi->has_cvq || !virtio_has_feature(vi->vdev, VIRTIO_NET_F_MQ))
return 0;
- s.virtqueue_pairs = queue_pairs;
+ s.virtqueue_pairs = cpu_to_virtio16(vi->vdev, queue_pairs);
sg_init_one(&sg, &s, sizeof(s));
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MQ,
@@ -1182,7 +1189,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
sg_init_table(sg, 2);
/* Store the unicast list and count in the front of the buffer */
- mac_data->entries = uc_count;
+ mac_data->entries = cpu_to_virtio32(vi->vdev, uc_count);
i = 0;
netdev_for_each_uc_addr(ha, dev)
memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
@@ -1193,7 +1200,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
/* multicast list and count fill the end */
mac_data = (void *)&mac_data->macs[uc_count][0];
- mac_data->entries = mc_count;
+ mac_data->entries = cpu_to_virtio32(vi->vdev, mc_count);
i = 0;
netdev_for_each_mc_addr(ha, dev)
memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
@@ -1960,6 +1967,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
VIRTIO_NET_F_CTRL_MAC_ADDR,
VIRTIO_F_ANY_LAYOUT,
+ VIRTIO_F_VERSION_1,
};
static struct virtio_driver virtio_net_driver = {
--
MST
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] libceph: remove unused variable in handle_reply()
From: Ilya Dryomov @ 2014-10-23 16:25 UTC (permalink / raw)
To: Fabian Frederick
Cc: Linux Kernel Mailing List, Sage Weil, David S. Miller,
Ceph Development, netdev
In-Reply-To: <1414080959-6053-1-git-send-email-fabf@skynet.be>
On Thu, Oct 23, 2014 at 8:15 PM, Fabian Frederick <fabf@skynet.be> wrote:
> osdmap_epoch is redundant with reassert_epoch and unused.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> net/ceph/osd_client.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index f3fc54e..432bd75 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -1700,7 +1700,6 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
> int err;
> u32 reassert_epoch;
> u64 reassert_version;
> - u32 osdmap_epoch;
> int already_completed;
> u32 bytes;
> unsigned int i;
> @@ -1725,7 +1724,6 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
> result = ceph_decode_32(&p);
> reassert_epoch = ceph_decode_32(&p);
> reassert_version = ceph_decode_64(&p);
> - osdmap_epoch = ceph_decode_32(&p);
>
> /* lookup */
> down_read(&osdc->map_sem);
Hi Fabian,
osdmap_epoch is useful for debugging, but this is wrong anyway -
ceph_decode_32() has side effects. Removing it and not adjusting *p
would make the whole thing blow up pretty fast..
Thanks,
Ilya
^ permalink raw reply
* [PATCH V3.18] rtlwifi: Add check for get_btc_status callback
From: Larry Finger @ 2014-10-23 16:27 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
troy_tan-kXabqFNEczNtrwSWzY7KCg, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Murilo Opsfelder Araujo,
Mike Galbraith, Thadeu Cascardo
Drivers that do not use the get_btc_status() callback may not define a
dummy routine. The caller needs to check before making the call.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Murilo Opsfelder Araujo <mopsfelder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Thadeu Cascardo <cascardo-s4Flwc3xefXVny7hquFfmQ@public.gmane.org>
---
John,
This missing statement is causing kernel crashes for several of the drivers.
This patch should be applied ASAP.
Larry
---
drivers/net/wireless/rtlwifi/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 667aba8..25daa87 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -1796,7 +1796,8 @@ static int rtl_pci_start(struct ieee80211_hw *hw)
rtl_pci_reset_trx_ring(hw);
rtlpci->driver_is_goingto_unload = false;
- if (rtlpriv->cfg->ops->get_btc_status()) {
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status()) {
rtlpriv->btcoexist.btc_ops->btc_init_variables(rtlpriv);
rtlpriv->btcoexist.btc_ops->btc_init_hal_vars(rtlpriv);
}
--
1.8.4.5
--
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 related
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck @ 2014-10-23 16:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20141023134706.GB25190@lunn.ch>
On Thu, Oct 23, 2014 at 03:47:06PM +0200, Andrew Lunn wrote:
> > >>+static DEVICE_ATTR_RO(temp1_input);
> > >
> > >You probably want the number of temperature sensors to come from the
> > >switch driver, and support arbitrary number of temperature sensors?
> >
> > In that case we would need the number of sensors, pass a sensor index,
> > and create a dynamic number of attributes. The code would get much more
> > complex without real benefit unless there is such a chip
>
> We are two different use cases here:
>
> One switch chip with multiple temperature sensors
I understand this case. However, quite frankly, I consider this quite
unlikely to happen.
> Multiple switch chips, each with its own temperature sensor.
>
I don't really see the problem. My understanding is that each of those
switch chips will instantiate itself, dsa_switch_setup will be called,
which will create a new hwmon device with its own sensors. That is
how all other hwmon devices do it, and it works just fine.
Why would that approach not work for switches in the dsa infrastructure ?
Am I missing something ?
If the concern or assumption is that there can not be more than one
"temp1_input" attribute, here is an example from a system with a large
number of chips with temperature sensors.
root@evo-xb49:/sys/class/hwmon# ls hwmon*/temp1_input
hwmon1/temp1_input hwmon22/temp1_input hwmon35/temp1_input
hwmon10/temp1_input hwmon23/temp1_input hwmon36/temp1_input
hwmon11/temp1_input hwmon24/temp1_input hwmon37/temp1_input
hwmon12/temp1_input hwmon25/temp1_input hwmon38/temp1_input
hwmon13/temp1_input hwmon26/temp1_input hwmon39/temp1_input
hwmon14/temp1_input hwmon27/temp1_input hwmon4/temp1_input
hwmon15/temp1_input hwmon28/temp1_input hwmon40/temp1_input
hwmon16/temp1_input hwmon29/temp1_input hwmon5/temp1_input
hwmon17/temp1_input hwmon3/temp1_input hwmon6/temp1_input
hwmon18/temp1_input hwmon30/temp1_input hwmon7/temp1_input
hwmon19/temp1_input hwmon31/temp1_input hwmon8/temp1_input
hwmon2/temp1_input hwmon32/temp1_input hwmon9/temp1_input
hwmon20/temp1_input hwmon33/temp1_input
hwmon21/temp1_input hwmon34/temp1_input
There are 6xDS1625, 11xDS1721, 1xLM95234, 4xMAX6697, and 17xLTC2978
in this system if I counted correctly. That doesn't mean that the
drivers need to do anything special for their multiple instances.
Also, the "name" of each instance does not have to be unique.
The "name" reflects the driver name, not its instance.
root@evo-xb49:/sys/class/hwmon# grep . */name | grep max
hwmon20/name:max6697
hwmon21/name:max6697
hwmon22/name:max6697
hwmon23/name:max6697
> I don't know of any hardware using either of these uses cases, but
> they could appear in the future.
>
> If we are not doing the generic implementation now, how about avoiding
> an ABI break in the future, by hard coding the sensors with .0.0 on
> the end?
I am a little lost. What would that be for, and what would the ABI breakage
be ?
Thanks,
Guenter
^ 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