Michael Grzeschik writes:
> @@ -1263,6 +1271,10 @@ int register_c_can_dev(struct net_device *dev)
>*/
> pinctrl_pm_select_sleep_state(dev->dev.parent);
>
> + priv->reg_xceiver = devm_regulator_get(priv->device, "xceiver");
> + if (IS_ERR(priv->reg_xceiver))
> +
Joe Perches writes:
> On Thu, 2016-01-07 at 00:26 +0100, Bjørn Mork wrote:
>> Joe Perches writes:
>> > On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:
>> > > A repeating pattern in drivers has become to use OF node information
>> > > and, if not
Joe Perches writes:
> On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:
>> A repeating pattern in drivers has become to use OF node information
>> and, if not found, platform specific host information to extract the
>> ethernet address for a given device.
> []
>> diff --git a/include/linux/et
Kristian Evensen writes:
> The WeTelecom-WPD600N is an LTE module that, in addition to supporting most
> "normal" bands, also supports LTE over 450MHz. Manual testing showed that
> only interface number three replies to QMI messages.
>
> Cc: Bjørn Mork
> Signed-off-
Dan Carpenter writes:
> Please stop sending cleanup patches, Markus. Just send fixes.
Thanks for your continued but unwarranted belief in AI.
Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ?
I am sure there are lots and lots of other examples. There is no reason
to believe
This adds support for the new "random" addrgenmode in net-next
and improves the support for the "stable_secret" mode.
Bjørn Mork (4):
include: update kernel headers
iplink: support setting addrgenmode stable_secret
iplink: support show and set of "addrgenmode random
0:21:86:a3:25:7d brd ff:ff:ff:ff:ff:ff promiscuity 0
addrgenmode random
Cc: Hannes Frederic Sowa
Signed-off-by: Bjørn Mork
---
ip/ipaddress.c | 3 +++
ip/iplink.c| 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index a495a391a0ec..9d254d27
Import current if_link.h from net-next
Signed-off-by: Bjørn Mork
---
include/linux/if_link.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index c9ad487d04f0..d91f2c97d946 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
Cc: Hannes Frederic Sowa
Signed-off-by: Bjørn Mork
---
man/man8/ip-link.8.in | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index ac6f4813a329..189a8f15fa03 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8
It is possible to switch to another addrgenmode after setting a
valid secret. Allow switching back without reconfiguring the
secret for completeness.
Cc: Hannes Frederic Sowa
Signed-off-by: Bjørn Mork
---
ip/iplink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ip
SF Markus Elfring writes:
> From: Markus Elfring
> Date: Fri, 1 Jan 2016 17:32:07 +0100
>
> Reduce the scope for the local variable "desc" to one branch
> of an if statement.
This patch is harmless. But is also pointless.
You could at least try to explain why this must be changed. I'm not
in
SF Markus Elfring writes:
> From: Markus Elfring
> Date: Fri, 1 Jan 2016 17:35:03 +0100
>
> Omit explicit initialisation at the beginning for one local variable
> that is redefined before its first use.
This patch is unnecessary. The variable initialisation is redundant.
See the difference? S
where dwNtbInMaxSize and dwNtbOutMaxSize happens
to be equal.
Fix by implementing an NCM specific change_mtu ndo, modifying the
netdev MTU without touching the buffer size settings.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_mbim.c | 2 +-
drivers/net/usb/cdc_ncm.c | 31
Stephen Hemminger writes:
> On Wed, 16 Dec 2015 16:15:14 +0100
> Bjørn Mork wrote:
>
>> Signed-off-by: Bjørn Mork
>
> Does not apply to current code base. Probably because of Hannes recent
> changes.
Yes, I saw that you applied Hannes' ipaddress.c patch, whic
Dan Williams writes:
> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>> This patch series add support in the cdc_ncm driver for two devices
>> based on the same platform, that are different only for carrier
>> customization.
>>
>> The devices do not have ARP capabilities.
>>
>> Daniel
it fail probing even if the
device id was dynamically added. The report was not complete enough
to allow adding a device entry for this modem. But this should at
least fix the dynamic id probing problem.
Reported-by: Kanerva Topi
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 5
On December 16, 2015 12:30:08 PM CET, Hannes Frederic Sowa
wrote:
>Signed-off-by: Hannes Frederic Sowa
>---
> ip/iplink.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/ip/iplink.c b/ip/iplink.c
>index f30de86d1858a0..e824082f7d8149 100644
>--- a/ip/iplink.c
>+++ b/i
then the mode
will default to 'stable-privacy' as before. The mode can be manually
set to 'random' but it will behave exactly like 'stable-privacy' in
this case. The secret will not change.
Cc: Hannes Frederic Sowa
Cc: 吉藤英明
Signed-off-by: Bjørn Mork
---
Changes since
Signed-off-by: Bjørn Mork
---
ip/ipaddress.c| 3 +++
ip/iplink.c | 4 +++-
man/man8/ip-link.8.in | 4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index bc8359eb9fad..07d5eee2b078 100644
--- a/ip/ipaddress.c
+++ b/ip
Hannes Frederic Sowa writes:
> Sorry for answering so late...
No problem. There is no rush here AFAICS. Thanks for taking the time
to look at this.
> What do you think about simply using IN6_ADDR_GEN_MODE_RANDOM?
Yes, that's fine with me (actually what I first used :)
>> I guess we should c
Hannes Frederic Sowa writes:
> On 05.12.2015 20:02, Bjørn Mork wrote:
>> Hannes Frederic Sowa writes:
>>> On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote:
>>>
>>>> After looking more at addrconf, I started wondering if we couldn't abuse
>>>&
Adding a writable sysfs attribute for the "NDP to end"
quirk flag.
This makes it easier for end users to test new devices for
this firmware bug. We've been lucky so far, but we should
not depend on reporters capable of rebuilding the driver.
Cc: Enrico Mioso
Signed-off
_read+0x53/0x7f
[] ? __sb_start_write+0x5f/0xb0
[] ? __sb_start_write+0x5f/0xb0
[] vfs_write+0xa3/0xe7
[] SyS_write+0x50/0x7e
[] entry_SYSCALL_64_fastpath+0x12/0x6f
Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Signed-off-by: Bjørn Mork
---
d
Hannes Frederic Sowa writes:
> On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote:
>
>> After looking more at addrconf, I started wondering if we couldn't abuse
>> ipv6_generate_stable_address() for this purpose? We could add a new
>> addr_gen_mode which would trig
be based on the same firmware and will need this quirk
too. If not, it will still not harm normal usage, although
multiplexing performance could be impacted.
Cc: Enrico Mioso
Reported-by: Sami Farin
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_mbim.c | 26
Cc: Hannes Frederic Sowa
Fixes: 64236f3f3d74 ("ipv6: introduce IFA_F_STABLE_PRIVACY flag")
Signed-off-by: Bjørn Mork
---
net/ipv6/addrconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index b5cc81a18521..b3465bbbcd82 1
Hannes Frederic Sowa writes:
> I see no problem with the patch as it eases operating those devices. I
> would also suggest storing the ifid in the inet6_dev so it does only
> change during device creation and destruction. Otherwise I would
> recommend to use stable privacy addresses to generate t
open. This patch set presents the solutions I currently prefer,
considering the above.
All comments are appreciated, even simple '+1' ones.
Bjørn
[1] http://www.spinics.net/lists/linux-usb/msg57056.html
Bjørn Mork (6):
net: qmi_wwan: MDM9x30 specific power management
net: qmi
Signed-off-by: Bjørn Mork
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea1751283b49..e9d444a88e48 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11159,6 +11159,13 @@ L: linux-...@vger.kernel.org
S: Supported
F: drivers
Assume the minidriver has taken care of all L2 header parsing
if it sets skb->protocol. This allows the minidriver to
support non-ethernet L2 headers, and even operate without
any L2 header at all.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/usbnet.c | 5 -
1 file changed, 4 inserti
This turned out to be a bootloader device ID. No need for
that in this driver. It will only provide a single serial
function.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
erefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware
Signed-off-by: Bjørn Mork
---
Documentation/ABI/testing/sysfs-class-net-qmi | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi
diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi
b/Documentation/ABI/testing
mote wakeup support to
be auto-suspended.
To make sure the MDM9x30 keeps firmware state, we need to
keep "needs_remote_wakeup" always set. We also need to
issue a "set DTR" request to enable the QMI interface.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 38
吉藤英明 writes:
>>> +static int addrconf_ifid_random(u8 *eui, struct net_device *dev)
>> +{
>> + get_random_bytes(eui, 8);
>> + eui[0] |= 0x02;
>> + return 0;
>> +}
>> +
>
> Since random identifier is locally assigned, drop the global bit
> instead if setting it.
Yes, definitely.
qlen
500
inet6 fe80::eec0:48d0:6b52:8835/64 scope link
valid_lft forever preferred_lft forever
Signed-off-by: Bjørn Mork
---
I'm planning raw-ip support for the qmi_wwan driver. And
the feedback from primary users (ModemManager++) is that
a headerless netdev is preferred over a
Anup Limbu writes:
> replace kmalloc + memset with kmemdup
>
> Signed-off-by: Anup Limbu
> ---
> drivers/net/usb/ch9200.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/ch9200.c b/drivers/net/usb/ch9200.c
> index 5e151e6..8a40202 100644
> --- a/driver
round code to be applied
to all devices with an IAD descriptor, which was never intended. Finish
the conversion by testing for hdr.usb_cdc_union_desc instead.
Cc: Oliver Neukum
Fixes: 77b0a099674a ("cdc-ncm: use common parser")
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c
Eric Dumazet writes:
> How many times should we crash before napi_frags_skb() returns NULL ?
..
> return NULL;
Huh? Now I'm lost here, too.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
for at.
The device works well with qmi and ModemManager-NetworkManager.
"
Reported-by: Thomas Schäfer
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 34799eaace41..9a5
e cases to assist further
debugging.
This is mostly similar to how __netdev_printk() handles orphan
devices.
Signed-off-by: Bjørn Mork
---
net/core/dev.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index ab9b8d0d115e..4dbf7ae6f
faces 5
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 500mA
>
> Signed-off-by: Petr Štetiar
This looks goo
: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G
Modem")
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c2e7222f2556..43
Messages like "icmp6_send: no reply to icmp error" are close
to useless. Adding source and destination addresses to provide
some more clue.
Signed-off-by: Bjørn Mork
---
I've had this laying around for much too long because I haven't been
convinced it's a good idea.
New device IDs shamelessly lifted from the vendor driver.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 355842b85ee9..2a7c1be23c4f 100644
--- a/drivers/net/usb
Oliver Neukum writes:
> On Tue, 2015-10-20 at 10:43 +0200, Bjørn Mork wrote:
>
>> So we might need to move cdc_parse_cdc_header() out of usbnet.c after
>> all. Keeping it there creates an unnecessary "select" mess. But I don't
>> know where to put it... E
Oliver Neukum writes:
> On Mon, 2015-10-19 at 21:16 +0200, Bjørn Mork wrote:
>
>> This looks incomplete.
>
> Yes, it is against the earlier patch set which introduces the CDC
> parser in cdc-acm and cdc-wdm. In hindsight I should have reversed
> the order of patches.
Ah,
Oliver Neukum writes:
> usbnet drives no devices of its own. It makes more sense to
> select it whenever a driver for actual hardware that needs
> it is chosen rather than offer it as an option of its own.
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/net/usb/Kconfig | 75
> +++-
Linus Torvalds writes:
> The PPRO_FENCE_BUG thing is rather questionable. I'm not sure it's
> even documented, but I can't find the official PPro errata now. I
> think I discussed it with Andy Glew back when Intel was starting to
> document the memory ordering rules.
>
> I'd be willing to get rid
for me to ack this, but I can add
my
Reviewed-by: Bjørn Mork
if that helps.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Eugene Shatokhin writes:
> 28.08.2015 11:55, Bjørn Mork пишет:
>
>> I guess you are right. At least I cannot prove that you are not :)
>>
>> There is a bit too much complexity involved here for me...
>
> :-)
>
> Yes, it is quite complex.
>
> I admit,
Eugene Shatokhin writes:
> 25.08.2015 00:01, Bjørn Mork пишет:
>> Eugene Shatokhin writes:
>>
>>> The race may happen when a device (e.g. YOTA 4G LTE Modem) is
>>> unplugged while the system is downloading a large file from the Net.
>>>
>>> Har
Oliver Neukum writes:
> On Mon, 2015-08-24 at 23:13 +0300, Eugene Shatokhin wrote:
>> It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
>> usbnet_stop(), but its value should be read before it is cleared
>> when dev->flags is set to 0.
>
> Can we agree that this at least is good and
Eugene Shatokhin writes:
> The race may happen when a device (e.g. YOTA 4G LTE Modem) is
> unplugged while the system is downloading a large file from the Net.
>
> Hardware breakpoints and Kprobes with delays were used to confirm that
> the race does actually happen.
>
> The race is on skb_queue
Eugene Shatokhin writes:
> 19.08.2015 15:31, Bjørn Mork пишет:
>> Eugene Shatokhin writes:
>>
>>> The problem is not in the reordering but rather in the fact that
>>> "dev->flags = 0" is not necessarily atomic
>>> w.r.t. "clear_bit(
Vivek Kumar Bhagat writes:
> Dear Bjorn,
>
>>>This is wrong. There are usbnet minidrivers depending on info->tx_fixup
>>> being called with a NULL skb.
> Also, if dev_hard_start_xmit() ensures that skb can not be NULL in
> usbnet_start_xmit()
> then we should remove below check.
> if (skb)
Vivek Kumar Bhagat writes:
> Dear Bjorn,
>
>>> This is wrong. There are usbnet minidrivers depending on info->tx_fixup
>>> being called with a NULL skb.
> I am using ax88179_178a driver and not familiar with usbnet minidrivers.
> When ax88179_tx_fixup() is called with NULL skb from
> usbnet_star
Eugene Shatokhin writes:
> The problem is not in the reordering but rather in the fact that
> "dev->flags = 0" is not necessarily atomic
> w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
>
> So the following might be possible, although unlikely:
>
> CPU0 CPU1
>
Bjørn Mork writes:
> Vivek Kumar Bhagat writes:
>
>> @@ -1906,7 +1908,8 @@ static int __usbnet_read_cmd(struct usbnet *dev, u8
>> cmd, u8 reqtype,
>> buf = kmalloc(size, GFP_KERNEL);
>> if (!buf)
>>
Vivek Kumar Bhagat writes:
> usbnet_start_xmit() - If info->tx_fixup is not defined by class driver,
> NULL check does not happen for skb pointer and leads to NULL dereference.
> __usbnet_read_cmd() - if data pointer is passed as NULL, memcpy will
> dereference NULL pointer.
That's two completel
Eugene Shatokhin writes:
> 19.08.2015 04:54, David Miller пишет:
>> From: Eugene Shatokhin
>> Date: Fri, 14 Aug 2015 19:58:36 +0300
>>
>>> 2. The second race is on dev->flags.
>>>
>>> dev->flags is set to 0 here:
>>> *0 usbnet_stop (usbnet.c:816)
>>> /* deferred work (task, timer, softirq)
I'm on vacation without any usable Internet or other code access, so you'll
have to excuse me if I'm missing something. But this seems to leave union_desc
uninitialized, doesn't it?
Bjørn
On July 16, 2015 9:24:34 PM CEST, Oliver Neukum wrote:
>Switch to the common parser
>
>Signed-off-by: Oli
"Chenqi (jakio)" writes:
> Hi, All,
>
> I'm from Huawei Technologies Co., Ltd, working in mobile broadband
> devices department.
>
> Huawei's broadband card don't support wwan in linux OS, there are
> several historical reasons:
>
> 1. Huawei produced dozens of broadband card types in past years
Marcel Holtmann writes:
> we introduced DEVTYPE in uevent a long time ago. That is what
> userspace should be using and not second guessing on interface names.
Yes, sorry for confusing this by mentioning the device name. This is
really about DEVTYPE.
usbnet minidrivers use FLAG_WWAN to set bot
Linus Torvalds writes:
> Hmm. Oliver is marked as the maintainer of the USB CDC code, but
> others have touched it more recently. So I'm just wildly adding people
> to the cc to comment on this patch and maybe apply it.
> Oliver/David/Ben/Bjørn?
Adding Aleksander and Dan, too. The 'wwanX' vs 'u
Andrew Lunn writes:
> So the ports look like normal ports, and you configure then using the
> normal mechanisms.
>
> DSA does not use vlans. It uses an additional protocol header which
> the switch supports, to allow the CPU to direct packets out a specific
> port. Similarly, packets coming to th
Andrew Lunn writes:
> Some boards have two CPU interfaces connected to the switch, e.g. WiFi
> access points, with 1 port labeled WAN, 4 ports labeled lan1-lan4, and
> two port connected to the SoC.
>
> This patch extends DSA to allows both CPU ports to be used. The "cpu"
> node in the DSA tree c
On 22 May 2015 19:22:47 CEST, Ben Hutchings
wrote:
>On Fri, 2015-05-22 at 13:15 +0200, Bjørn Mork wrote:
>> The tx_curr_frame_payload field is u32. When we try to calculate a
>> small negative delta based on it, we end up with a positive integer
>> close to 2^32 inst
Hutchings
Reported-by: Florian Bruhin
Fixes: 7a1e890e2168 ("usbnet: Fix tx_bytes statistic running backward in
cdc_ncm")
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb
Jan Kaisrlik writes:
> From: Jan Kaisrlik
>
> This patch adds a possibility to use the RMII interface of the ax88772b
> instead of the Ethernet PHY which is used now.
>
> Binding DSA to a USB device is done via sysfs.
>
> ---
> drivers/net/usb/asix.h | 7 ++
> drivers/net/usb/asix_dev
David Miller <[EMAIL PROTECTED]> writes:
> Please clear up all of the inline mime tag stuff in your
> outgoing emails. Your description and patch is very difficult
> to read because of this.
Ouch, sorry. I wish I could blame my user agent, but this was mostly my
sausage fingers..
New attempt:
<#part type=text/plain nofile=yes>
Any comments on this? Apparently introduced in 2.1.68, so there's not
much hurry. But I'd still like to hear whether that analysis is correct
or not...
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==-=-="
The bug did bite at least one user, who di
>> Latest working kernel version: none
>> Earliest failing kernel version: 2.6.18 (verified, but most likely "any")
Looks like this was introduced in 2.1.68, which makes it a 10 year old
bug :-)
http://www.linuxhq.com/kernel/v2.1/68/net/ipv4/devinet.c
Bjørn
--
You sound like a real wimp
--
Hello
Gary < gary.manchon (at) gmail.com > found a problem where he was unable
to recover from a bad network interface configuration
(ifconfig eth0 127.0.0.1), ref
http://www.uwsg.iu.edu/hypermail/linux/net/0801.2/0009.html
This was confirmed by several people.
I suspect that the problem might
[previously posted to [EMAIL PROTECTED], but resent here after a
helpful hint that this is the proper list for such messages. Thanks]
I don't know if this is the correct place for 3c59x bugs. Couldn't find
a maintainer entry for it. Please redirect as appropriate.
pci_set_power_state() is a bi
201 - 275 of 275 matches
Mail list logo
