Ilya Lipnitskiy writes:
> Add missing binding documentation for SoC support that has been in place
> since v5.1
>
> Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet
> hardware")
> Cc: Bjørn Mork
> Signed-off-by: Ilya Lipnitskiy
&g
Paul Cercueil writes:
> Commit 6654111c893f ("MIPS: vmlinux.lds.S: align raw appended dtb to 8
> bytes") changed the alignment from STRUCT_ALIGNMENT bytes to 8 bytes.
Ouch. That was not my intention. I see that there was a mixup with my
initial patch. My last version used STRUCT_ALIGNMENT, but
me to fixup this
rather messy piece of code.
Reviewed-by: Bjørn Mork
05c6, 0x9026, 3)},
> {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
> {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
Acked-by: Bjørn Mork
This fix should probably go to net+stable.
Thanks,
Bjørn
Jakub Kicinski writes:
> I'm guessing that I'm supposed to take this patch into the networking
> tree, correct?
Correct.
> Is this net or net-next candidate? Bjørn?
Sorry, should have made that explicit. This is for net + stable
Thanks.
Bjørn
MI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
Thanks. Looks nice now.
Acked-by: Bjørn Mork
Wilken Gottwalt writes:
> Oh sorry, looks like I got it mixed up a bit. It was my first attempt to
> submit
> a patch set. Which is the best way to resubmit an update if the other part of
> the patch set gets accepted? The documentation about re-/submitting patch sets
> is a bit thin.
I see tha
Wilken Gottwalt writes:
> Add usb ids of the Cellient MPL200 card.
>
> Signed-off-by: Wilken Gottwalt
> ---
> 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 07c42c0719f5..0bf2b19d5d54 100644
> -
Kristian Evensen writes:
> Hi all,
>
> I was able to trigger the same issue as reported by Paul, and came
> across this patch (+ Daniele's other patch and thread on the libqmi
> mailing list). Applying Paul's fix solved the problem for me, changing
> the MTU of the QMI interface now works fine. T
YueHaibing writes:
> If USB_NET_CDC_NCM is y and USB_NET_CDCETHER is m, build fails:
>
> drivers/net/usb/cdc_ncm.o:(.rodata+0x1d8): undefined reference to
> `usbnet_cdc_update_filter'
>
> Select USB_NET_CDCETHER for USB_NET_CDC_NCM to fix this.
Ouch. For some reason I assumed that was always s
TF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
> {QMI_QUIRK_SET_DTR(0x2cb7, 0x0104, 4)}, /* Fibocom NL678 series */
> {QMI_FIXED_INTF(0x0489, 0xe0b4, 0)},/* Foxconn T77W968 LTE */
Acked-by: Bjørn Mork
Adding Fixes for documentation only, not as a stable hint. This is
cleanup only and not suitable for stable IMHO.
Acked-by: Bjørn Mork
Fixes: 8492ed45aa5d ("qmi-wwan: use common parser")
,/* Dell Wireless 5821e */
> {QMI_FIXED_INTF(0x413c, 0x81d7, 1)},/* Dell Wireless 5821e
> preproduction config */
> {QMI_FIXED_INTF(0x413c, 0x81e0, 0)},/* Dell Wireless 5821e with
> eSIM support*/
Looks fine to me. Please add to the stable queue as well, Thanks.
Acked-by: Bjørn Mork
syzbot writes:
> syzbot has tested the proposed patch but the reproducer still
> triggered crash:
> divide error in usbnet_update_max_qlen
>
> cdc_ncm 5-1:1.0: setting tx_max = 16384
> divide error: [#1] SMP KASAN
> CPU: 1 PID: 1737 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0
> Hardware name
nel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace ab75cc10e099d8e9 ]---
Reported-by: syzbot+ce366e2b8296e25d8...@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c
Hillf Danton writes:
> and wonder if the following works.
>
> - info = (void *)&id->driver_info;
> + info = (void *)id->driver_info;
Doh! Right you are. Thanks to both you and Andrey for quick and good
help.
We obviously have some bad code patterns here, since this apparently
worked f
syzbot writes:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:9939f56e usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1615a669a0
> kernel config: htt
like it's time to consider applying this unconditionally
to all devices. Feel free to propose something like that the next time
this issue comes up.
Acked-by: Bjørn Mork
Johan Hovold writes:
> Note that the stable tag above lacks a version comment (e.g. "# 4.19"),
> but I can see how that may be too subtle to convey this (and not all
> maintainers use those). Perhaps an explicit comment should just be added
> in such cases.
I have always thought that the inclusi
Josh Hill writes:
> Add support for Netgear Aircard 779S
>
> Signed-off-by: Josh Hill
Acked-by: Bjørn Mork
Please queue this for stable too. Thanks.
Bjørn
Johan Hovold writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module su
"SZ Lin (林上智)" writes:
> This patch adds support for PID 0x90b2 of ublox R410M.
Acked-by: Bjørn Mork
one)
> E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
>
> Tested on openwrt distribution
>
> Signed-off-by: Pawel Dembicki
Acked-by: Bjørn Mork
Bassem Boubaker writes:
> +#define GEMALTO_VENDOR_ID0x1e2d
This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c.
I have no idea which defintion is most correct, but I believe the macros
should be kept identical whatever you decide. Anything else is just
unnecessarily confus
c6, 0x920d, 5)},
> + {QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
> {QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
> {QMI_FIXED_INTF(0x12d1, 0x140c, 1)},/* Huawei E173 */
> {QMI_FIXED_INTF(0x12d1, 0x14ac, 1)},/* Huawei E1820 */
Perfect. Thanks
Acked-by: Bjørn Mork
"SZ Lin (林上智)" writes:
>> Johan Hovold writes:
>>
>> >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = {
>> >> + .reserved = BIT(0) | BIT(1) | BIT(4), };
>> >
>> > Do you really need to blacklist the first interface?
>>
>> Good question. Interface #0 does look a lot like
Johan Hovold writes:
>> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = {
>> +.reserved = BIT(0) | BIT(1) | BIT(4),
>> +};
>
> Do you really need to blacklist the first interface?
Good question. Interface #0 does look a lot like a Qualcomm DM/DIAG
function, based on tw
100V LTE) */
> {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
> {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
Looks good except for the duplicate 'From' line. Drop that and you can
add
Acked-by: Bjørn Mork
Joe Perches writes:
> On Sat, 2017-11-25 at 21:29 +0200, Jarkko Sakkinen wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> @@ -14932,6 +14932,11 @@ L: linux...@kvack.org
>> S: Maintained
>> F: mm/zswap.c
>>
>> +INTEL SGX
>> +M: Jarkko Sakkinen
>> +L: intel-sgx-kernel-...@lists.01.
-off-by: Sebastian Sjoholm
Perfect. Thanks.
Acked-by: Bjørn Mork
Shrirang Bagul writes:
> Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> series modems which will by default boot with vid 0x413c and pid's
> 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> qmi_wwan on the usb interface #12.
NAK,
Interace #12 is
On November 20, 2017 5:19:21 AM GMT+01:00, ssjoh...@mac.com wrote:
>From: ssjoholm
>
>Signed-off-by: ssjoholm
>
>Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
>CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
>development board (EVB).
>The USB id is added to q
Marcel Holtmann writes:
>> +{ USB_DEVICE(0x0b05, 0x1185c), .driver_info = BTUSB_REALTEK },
>> +
>
> I prefer to have /sys/kernel/debug/usb/devices for the device included in the
> commit message.
...and 0x1185c is a typp
Bjørn
erface is configured as-such, it seems certain
> parts of the network stack expects a "good" value in skb->mac_header.
Thanks. Yes, I see that the tun driver also does this.
Acked-by: Bjørn Mork
And his should probably go to stable as well? with a
Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Andrey Konovalov writes:
> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.
Thanks. It would have helped a lot of you said *what* you were fuzzing,
though But based on where the bug is, I assume it is USB
descriptors?
> On commit 39dae59d66acd86d1de24294bd2f3
"Gustavo A. R. Silva" writes:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case I replaced "...drop on through"
> comments with a proper "fall through" comment on its own line, which
> is what G
Did you read drivers/staging/irda/TODO ?
There is no need to answer that. You already have. Thanks a lot for
your ever lasting invaluable contributions to /dev/null. Please
continue.
Bjørn
Shrirang Bagul writes:
> On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
>
>> Don't you want to add these to qmi_wwan as well?
>
> I haven't tested these devices with qmi_wwan. Perhaps a separate patch once
> it's
> verified.
Please do, if you can. I realize that QMI isn't a default conf
Douglas Anderson writes:
> Every once in a while when my system is under a bit of stress I see
> some spammy messages show up in my logs that say:
>
> kevent X may have been dropped
>
> As far as I can tell these messages aren't terribly useful.
I agree, FWIW. These messages just confuse users
Douglas Anderson writes:
> If rx_submit() returns an error code then nobody calls usb_free_urb().
> That means it's leaked.
Nope. rx_submit() will call usb_free_urb() before returning an error:
static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
..
if (!skb) {
Allen Pais writes:
> Signed-off-by: Allen Pais
> ---
> drivers/platform/x86/intel_telemetry_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index d4fc42b..6b63
Anna-Maria Gleixner writes:
> From: Thomas Gleixner
>
> The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
> softirq context. This can be also achieved without the tasklet but with
> CLOCK_MONOTONIC_SOFT as hrtimer base.
>
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Ann
=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Bjørn Mork
---
Johan Hovold writes:
> Do you want to submit a patch or should I do it?
Well, I can save you that job if this is fine with you. Feel
free to add a stable cc if you think it is appropriate. I am not
sure...
Bj
Johan Hovold writes:
> On Mon, Aug 28, 2017 at 04:32:53PM +0200, Maciej S. Szmigiero wrote:
>
>> Also, three other D-Link modems few lines above are using the same
>> USB_DEVICE_AND_INTERFACE_INFO() selectors.
>
> Yeah, I noticed those, and I'm not sure why they're not using
> class-matching only
Bjorn Andersson writes:
> This series starts by moving the common definitions of the QMUX protocol to
> the
> uapi header, as they are shared with clients - both in kernel and userspace.
>
> This series then introduces in-kernel helper functions for aiding the handling
> of QMI encoded messages
Johan Hovold writes:
> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
Johan Hovold writes:
> On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
>
>> For devices with connected EEPROM some modes (including UART) are
>> configurable in the EEPROM. For devices without EEPROM the default
>> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
[adding Johan on the CC list]
Anatolij Gustschin writes:
> +static struct usb_device_id ftdi_mfd_table[] = {
> + { USB_DEVICE(0x0403, 0x6014) },
> + {}
> +};
> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
This device ID is currently handled by the ftdi_sio driver, so I believe
you at leas
"Baxter, Jim" writes:
> I tested this with printk's to show when the low memory code was triggered
> and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt.
> I created a workqueue that slowly used up the atomic memory until the
> code is triggered.
>
> I could add debug prints, though
er
allocation has failed. Maybe add some sort of debug helper(s) in a
followup patch? How did you verify the patch operation while testing it?
Anyway, that's no show stopper of course. So FWIW:
Reviewed-by: Bjørn Mork
Jay Vosburgh writes:
> Michael J Dilmore wrote:
>
>>if (WARN_ON(!new_active_slave) {
>>netdev_dbg("Can't add new active slave - pointer null");
>>return ERROR_CODE
>>}
>
> In general, yes, but in this case, the condition should be
> impossible to hit, so BUG_ON seems appropriate.
I
David Laight writes:
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Jim Baxter
>> Sent: 16 May 2017 18:41
>>
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented
Jim Baxter writes:
> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
>
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NT
"Baxter, Jim" writes:
> Bjørn Mork writes:
>>
>> Ouch! Thanks for finding this. This should go to the stable queue as
>> well.
>>
>> Reviewed-by: Bjørn Mork
>>
>
> Do I need to submit this to the stable queue myself?
No, davem will h
Geliang Tang writes:
> Use memdup_user() helper instead of open-coding to simplify the code.
>
> Signed-off-by: Geliang Tang
> ---
> drivers/usb/class/cdc-wdm.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/cl
t;len) == 0.
>
> I have resolved this by storing the size of
> the memory to be zeroed before the skb_put
> and using this in the memset call.
>
> Signed-off-by: Jim Baxter
Ouch! Thanks for finding this. This should go to the stable queue as
well.
Reviewed-by: Bjørn Mork
Bjørn Mork writes:
> "Brown, Aaron F" writes:
>>> From: Bjørn Mork [mailto:bj...@mork.no]
>>>
>>> Already did that a week ago:
>>> https://www.spinics.net/lists/netdev/msg423379.html
>>>
>>> Haven't heard anything bac
"Brown, Aaron F" writes:
>> From: Bjørn Mork [mailto:bj...@mork.no]
>>
>> Already did that a week ago:
>> https://www.spinics.net/lists/netdev/msg423379.html
>>
>> Haven't heard anything back yet. Wondering if they are waiting for
>>
Borislav Petkov writes:
> On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote:
>
>> The only change that IMHO matters happened between v4.10 and v4.11-rc1 is
>> this:
>>
>> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device *dev)
>> /* Quiesce the device
n this makes sense. But I think it might be worth a note
about what we replace here and why, in case you happen to know that...
I realise that this is inherited from the original driver.
Just minor nits. Overall this looks very good to me, FWIW.
Reviewed-by: Bjørn Mork
Bjørn
Greg KH writes:
> Please take some time, and go read Documentation/SubmittingPatches.
That's quickly done nowadays:
bjorn@miraculix:/usr/local/src/git/linux$ cat Documentation/SubmittingPatches
This file has moved to process/submitting-patches.rst
I don't know why it was necessary to move t
Joe Perches writes:
> On Mon, 2016-12-12 at 23:22 +0100, Pavel Machek wrote:
>> On Mon 2016-12-12 10:39:15, Joe Perches wrote:
>> > On Mon, 2016-12-12 at 09:56 -0800, Nick Desaulniers wrote:
>> > > A quick cleanup that passes scripts/checkpatch.pl -f .
> []
>> > > diff --git a/arch/x86/kernel/acpi
Kristian Evensen writes:
> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
> +{
> + struct usb_cdc_notification *event;
> +
> + if (urb->actual_length < sizeof(*event))
> + return;
> +
> + event = urb->transfer_buffer;
> +
> + if (event->bNotificationT
On November 23, 2016 1:54:57 AM CET, Wim Osterholt wrote:
>On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
>> > On kernel 4.8.8 this crashes hard and produces over a serial link:
>>
>> Huh? That device shouldn't ever enter that code path AFAICS.
>
Wim Osterholt writes:
> On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
>
>> I don't understand it, bit please test the attached patch
>> with dynamic debugging for cdc-acm and the kernel log level
>> at maximum.
>
>> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc
Wim Osterholt writes:
> On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
>> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
>>
>> > Nov 17 15:07:51 localhost kernel: Check point 10
>> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL
>> > pointer deref
Alan Stern writes:
> On Thu, 10 Nov 2016, Kai-Heng Feng wrote:
>
>> Is there a way to force XHCI run at HighSpeed?
>
> Yes, like I said above: Use a USB-2 cable instead of a USB-3 cable.
It's an m.2 form factor modem, so there most likely isn't any cable
involved. But the principle is the same:
Kai-Heng Feng writes:
> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote:
>> Oliver Neukum writes:
>>
>>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>>
>>>> These problems could very well be caused by running at SuperSpeed
>>>
Oliver Neukum writes:
> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>>
>> Is there any way to test what happens when the device is attached to
>> the computer by a USB-2 cab
Alan Stern writes:
> On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
>
>> Hi,
>>
>> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote:
>> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote:
>> >> Sometimes cdc_mbim failed to probe if runtime pm is enabled:
>> >> [9.305626] cdc_mbim: probe
Dan Carpenter writes:
> I am ignoring Markus patches and have told him that he should focus on
> bug fixes. These patches don't add any value and regularly introduce
> bugs.
I think there should be a big fat warning in CodingStyle:
THIS DOCUMENT DOES NOT APPLY TO ANY EXISTING KERNEL CODE.
P
SF Markus Elfring writes:
>> When someone tells you that you are wasting their time,
>
> This information can be useful to some degree
Yes. If you continue discussing after that point, then you make a clear
statement that it isn't an accident. You are deliberately wasting their
time.
A lot of
SF Markus Elfring writes:
>> go around bothering everyone with waste of time cleanup patches.
>
> I find it still debatable if the shown software development efforts
> are really "wasted".
When someone tells you that you are wasting their time, then that is not
a subject for further discussion.
Hayes Wang writes:
> Bjørn Mork [mailto:bj...@mork.no]
>> Sent: Thursday, September 08, 2016 3:55 PM
> [...]
>> Yes, I see that. But is that strictly necessary? Couldn't you just say:
>> "CDC ECM is supported by cdc_ether and therefore limited to the feature
Hayes Wang writes:
> Bjørn Mork [mailto:bj...@mork.no]
>> Sent: Wednesday, September 07, 2016 9:51 PM
> [...]
>> So this adds a lot of code to work around the issues you introduced by
>> unnecessarily blacklisting the CDC ECM configuration earlier, and still
>> mak
[ CCing Oliver, who AFAIK still is the cdc_ether maintainer and should
have the final word on this ]
Hayes Wang writes:
> Some people prefer to use ECM mode rather than vendor mode. Therefore, I add
> CONFIG_RTL8152_CONFIG_VALUE in Kconfig. Then, the users could choose the USB
> configuration
Julian Calaby writes:
> Otherwise this change is useless churn - you're making the code more
> complicated, longer and harder to read for practically no benefit.
He has been doing that for years now. And wasted maintainer resources
along the way, discussing all the pointless churn. There are ze
lerometer as /devices/virtual/input/input16
With patch:
acer_wmi: Acer Laptop ACPI-WMI Extras
acer_wmi: Unsupported machine has AMW0_GUID1, unable to load
So if you want it:
Tested-by: Bjørn Mork
Greg KH writes:
> On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote:
>>
>> Good question. I would like to extend this USB port trigger in the
>> future by reacting to USB activity. This involves playing with URBs
>> and I believe that at that point it'd be getting too much USB specific
Rafał Miłecki writes:
> The last big missing thing is Documentation update (this is why I'm
> sending RFC). Greg pointed out we should have some entries in
> Documentation/ABI, but it seems none of triggers have it.
There's a lot missing, but there is at least one exception:
The "inverted" attri
Dan Carpenter writes:
> Hike up the mountain, then if you get stuck hike back down using the
> exact same path.
OK, I understand what you say. I just can't resist objecting to that
example ;)
In my experience, finding the exact same path back after hiking up a
mountain is really hard. Especial
"Michael S. Tsirkin" writes:
> foo = kmalloc(SIZE, GFP_KERNEL);
> if (!foo)
> goto err_foo;
>
> foo->bar = kmalloc(SIZE, GFP_KERNEL);
> if (!foo->bar)
> goto err_bar;
>
Alan Stern writes:
> On Mon, 22 Aug 2016, Bjørn Mork wrote:
>
>> Alan Stern writes:
>>
>> > On Sun, 21 Aug 2016, Jiri Slaby wrote:
>> >
>> >> Cc: proper lists.
>> >>
>> >> ep->desc.bInterval seems to be 0 her
Alan Stern writes:
> On Sun, 21 Aug 2016, Jiri Slaby wrote:
>
>> Cc: proper lists.
>>
>> ep->desc.bInterval seems to be 0 here.
>>
>> On 08/21/2016, 12:42 PM, Vittorio Zecca wrote:
>> > I am not sure this is the right place so please bear with me...
>> > From Vittorio Zecca
>> >
>> > After com
Oliver Neukum writes:
> But why fix similar issues at two different places? And what about
> PCI or other cards that show the same problem?
I guess some sort of common helper would be nice to avoid open coding
this fix everywhere. But you would still have to modify every driver
where it is appl
Oliver Neukum writes:
> On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote:
>> On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote:
>> > No, you misunderstand me. I don't want quirks if we can avoid it.
>> > But if you need to do this for rndis_host and cdc_ether and maybe other
>> > driv
David Laight writes:
> From: Bjørn Mork
>> Sent: 13 July 2016 23:23
> ...
>> Or how about the more generic?:
>>
>> if (bp[0] & 0x02)
>> eth_hw_addr_random(net);
>> else
>> ether_addr_copy(net->dev_a
Kristian Evensen writes:
> From: Kristian Evensen
>
> All ZTE MF910 mifis, at least on some revisions, export the same MAC
> address (36:4b:50:b7:ef:da). Check for this MAC address and set a random
> MAC if detected.
>
> Also, changed the memcpy() to ether_addr_copy(), as pointed out by
> checkp
Wilfried Klaebe writes:
> On May 4th, Bjørn Mork provided patch
> 697bbc7b832048d3a679cd55caf2268a325efbe0 to include objtool binaries in
> the headers package. However, that one only works if $srctree=$objtree,
> because the objtool binaries are not written to the srctree, but
>
writes:
>> > 2) Track whether this is the first or second USB NIC plugged in. Only
>> > offer it
>> on the first NIC detected by r8152. When the second NIC is plugged in don't
>> match from ACPI.
>> > There would be a question of what to do if the first NIC is removed and
>> added back if it s
writes:
>> > +static u8 amac_ascii_to_hex(int c)
>> > +{
>> > + if (c <= 0x39)
>> > + return (u8)(c - 0x30);
>> > + else if (c <= 0x46)
>> > + return (u8)(c - 0x37);
>> > + return (u8)(c - 0x57);
>> > +}
>>
>
> Sorry forgot to address this.
>
>> We really don't have such a
Greg KH writes:
> And finally, this seems odd overall given that a MAC address should be
> associated with the specific network device, not the overall system.
Definitely.
I wonder if this isn't a perfect candidate for an x86
arch_get_platform_mac_address() implementation? Then you could just
ext/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Use '+ 0' and '+ 1' as offsets, like they were intended, instead
of adding to the result.
Fixes: 2b1b0d66704a ("lib/uuid.c: introduce a few more generic helpers")
Signed-off-by: Bjørn Mork
---
lib/uuid.c | 4 +
make it do anything useful
with my current test device. I am a bit curious about what your device
descriptor looks like if you actually hit this problem...
But your patch is a nice improvement in any case, so FWIW:
Revieved-by: Bjørn Mork
tl;dr
My quick test was done with an MBIM device hav
target 'tools/objtool/objtool', needed by
'foo.o'. Stop.
Makefile:1598: recipe for target 'foo.ko' failed
make[1]: *** [foo.ko] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.6.0-rc6'
Signed-off-by: Bjørn Mork
---
scripts/package/builddeb
Ingo Molnar writes:
> static int parse_proc_cmdline_item(const char *key, const char *value) {
>
> /*
> * The systemd.log_xyz= settings are parsed by all tools, and
> * so is "debug".
> *
> * However, "quiet" is only parsed by PID 1, and only turns of
Vaishali Thakkar writes:
> When sizeof is applied to a pointer typed expression, it gives
> the size of the pointer. So, do not use sizeof on pointer type.
What if the intended result was the size of the pointer?
> Problem found using Coccinelle.
Yes, sure. But you cannot just blindly apply t
Sasha Levin writes:
> On 04/21/2016 02:43 AM, Jiri Slaby wrote:
>
>> Input: powermate - fix oops with malicious USB descriptors
>
> This requires physical access to the machine.
You wish.
Say you have some internal USB connected device with replacable
firmware. LTE modem, fingerprint reader, we
Valdis Kletnieks writes:
> I'll say up front - no, I do *not* have a clue why this commit causes this
> problem - it makes exactly zero fsking sense.
>
> Scenario: $WORK is blessed with a Juniper VPN system. I've been
> seeing for a while now (since Dec-ish) an issue where at startup,
> the tun
Timur Tabi writes:
> Shanker Donthineni wrote:
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function
>> 'emac_mac_up':
>>drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:9: warning:
>>large integer implicitly truncated to unsigned type [-Woverf
1 - 100 of 338 matches
Mail list logo
