Re: [Nbd] [PATCH v2 4/5]nbd: make nbd device wait for its users.
On Wed, Jun 15, 2016 at 08:30:45AM +0200, Markus Pargmann wrote: > Thanks for the explanations. I think my understanding was off by one ;).. > I didn't realize that the DO_IT thread from the userspace has the block > device open as well. Obviously, otherwise it couldn't do an ioctl() to it :-) > I thought a bit about this, does it make sense to delay the essential > cleanup steps until really all open file handles were closed? So that > even if the DO_IT thread exits, the block device is still there. Only if > the file is closed everything is cleaned up. Maybe this makes the code > simpler and we can directly use krefs without any strange constructs. > What do you think? > > This would also allow the client to setup a new socket as long as it > does not close the nbd file handle. That sounds like the behaviour that I described earlier about possible retries for userspace... > Could this behavior be potentially problematic for any client > implementation? I don't think it could, but I'm not sure I understand all the details. What would happen if: - nbd is connected from pid X, pid Y does NBD_DISCONNECT, pid X hangs and doesn't exit? - nbd is connected from pid X, server disconnects while pid Y is trying to access the device, pid X tries to reconnect but it takes a while? > Does it solve our other issue with setting up a new sockets for an > existing nbd blockdevice? It could, depending. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing
On Wed, 2016-06-15 at 06:42 +0800, Yuyang Du wrote: > I am entirely for giving it a "clear unadulterated reality", and even > more for it an option. > > Reviewed-by: Yuyang Du Thanks. I'll have a look at perhaps having wake_affine to the same, such that there is a clean separation of wake/LB paths. I suppose I should also try harder to sprinkle some 'pretty' on it, that's always the hardest part for a master of fugly :) -Mike
Re: [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Whereas I want to do > > aplay some_song.wav Can you please explain how your patches accomplish this? Thanks, Richard
Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
Am Dienstag, 14. Juni 2016, 10:22:15 schrieb Mat Martineau:
Hi Mat,
> Stephan,
>
> On Sat, 14 May 2016, Tadeusz Struk wrote:
> > From: Stephan Mueller
> >
> > This patch adds the user space interface for asymmetric ciphers. The
> > interface allows the use of sendmsg as well as vmsplice to provide data.
> >
> > This version has been rebased on top of 4.6 and a few chackpatch issues
> > have been fixed.
> >
> > Signed-off-by: Stephan Mueller
> > Signed-off-by: Tadeusz Struk
> > ---
> > crypto/algif_akcipher.c | 542
> > +++ 1 file changed, 542
> > insertions(+)
> > create mode 100644 crypto/algif_akcipher.c
> >
> > diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
> > new file mode 100644
> > index 000..6342b6e
> > --- /dev/null
> > +++ b/crypto/algif_akcipher.c
> > +
> > +static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg,
> > + size_t size)
> > +{
> > + struct sock *sk = sock->sk;
> > + struct alg_sock *ask = alg_sk(sk);
> > + struct akcipher_ctx *ctx = ask->private;
> > + struct akcipher_sg_list *sgl = &ctx->tsgl;
> > + struct af_alg_control con = {};
> > + long copied = 0;
> > + int op = 0;
> > + bool init = 0;
> > + int err;
> > +
> > + if (msg->msg_controllen) {
> > + err = af_alg_cmsg_send(msg, &con);
> > + if (err)
> > + return err;
> > +
> > + init = 1;
> > + switch (con.op) {
> > + case ALG_OP_VERIFY:
> > + case ALG_OP_SIGN:
> > + case ALG_OP_ENCRYPT:
> > + case ALG_OP_DECRYPT:
> > + op = con.op;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + lock_sock(sk);
> > + if (!ctx->more && ctx->used)
> > + goto unlock;
>
> err might be uninitialised at this goto. Should it be set to something
> like -EALREADY to indicate that data is already queued for a different
> crypto op?
Thanks for the hint. Tadeusz, I will provide you with an updated
algif_akcipher.c for your patchset.
I will also have a look at the comment from Andrew.
>
>
>
> > +unlock:
> > + akcipher_data_wakeup(sk);
> > + release_sock(sk);
> > +
> > + return err ?: copied;
> > +}
>
> Regards,
>
> --
> Mat Martineau
> Intel OTC
Ciao
Stephan
Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'
Paul, Am 15.06.2016 um 00:54 schrieb Paul E. McKenney: > On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote: >> tree: >> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git >> rcu/next >> head: 13ee0de9cd2444b57ce30c4f1607b49b90aa0c38 >> commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make >> call_rcu_tasks() tolerate first call with irqs disabled >> config: um-allmodconfig (attached as .config) >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 >> reproduce: >> git checkout f251ac814fc5787765009e60d54a2bd4277350c8 >> # save the attached .config to linux build tree >> make ARCH=um > > My kneejerk reaction would be to make CONFIG_TASKS_RCU depend on > !UML or something similar. > > Another approach would be create a arch_irqs_disabled_flags() for UML. > > Any preferences? Patches for arch_irqs_disabled_flags() support are already on LKML: https://lkml.org/lkml/2016/6/12/162 My plan was to merge them in the v4.8 merge window. So having CONFIG_TASKS_RCU depend on !UML for now should be fine. We can remove the dependency in v4.8 again. Thanks, //richard
Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7
On Tue, 14 Jun 2016, Wim Osterholt wrote: > Surprising or not, the thusly compiled kernel ran fine and I could > handle floppies like before! (open(/dev/fd0,O_ACCMODE) succeeds.) Thanks for testing. Now next question -- what do you actually want to achieve with passing O_ACCMODE to open()? O_ACCMODE should primarily be used as a mask to use when extracting access mode bits from fcntl(F_GETFL) call. -- Jiri Kosina SUSE Labs
Re: [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Where is your media-application in this? Um, that *is* a media application. It plays music on the sound card. > You only loop the audio from > network to the dsp, is the media-application attached to the dsp-device? Sorry, I thought the old OSS API would be familiar and easy to understand. The /dev/dsp is the sound card. Thanks, Richard
Re: [PATCH v10 03/14] usb: hcd.h: Add OTG to HCD interface
On 14/06/16 17:21, Alan Stern wrote:
> On Tue, 14 Jun 2016, Roger Quadros wrote:
>
>> +Alan
>>
>> On 10/06/16 16:07, Roger Quadros wrote:
>>> The OTG core will use struct otg_hcd_ops to interface
>>> with the HCD (Host Controller Driver).
>>>
>>> The main purpose of this interface is to avoid directly
>>> calling HCD APIs from the OTG core as they
>>> wouldn't be defined in the built-in symbol table if
>>> CONFIG_USB is m.
>>>
>>> Signed-off-by: Roger Quadros
>>> Acked-by: Peter Chen
>>> ---
>>> include/linux/usb/hcd.h | 24
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>>> index 66fc137..7729c1f 100644
>>> --- a/include/linux/usb/hcd.h
>>> +++ b/include/linux/usb/hcd.h
>>> @@ -400,6 +400,30 @@ struct hc_driver {
>>>
>>> };
>>>
>>> +/**
>>> + * struct otg_hcd_ops - Interface between OTG core and HCD
>>> + *
>>> + * Provided by the HCD core to allow the OTG core to interface with the HCD
>
> Add: * in case the OTG core is built-in and the HCD core is built as a
> module.
OK.
>
> Otherwise, for patches 1, 3, and 12:
>
> Acked-by: Alan Stern
>
Thanks.
cheers,
-roger
Re: [PATCH v2] HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
On Fri, 3 Jun 2016, Andrew Duggan wrote: > The Synaptics RMI4 driver provides support for RMI4 devices. Instead of > duplicating the RMI4 processing code, make hid-rmi a transport driver > and register it with the Synaptics RMI4 core. > > Signed-off-by: Andrew Duggan Is there any update on the Input series please? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH net-next v3 0/7] vmxnet3: upgrade to version 3
From: Shrikrishna Khare Date: Mon, 13 Jun 2016 18:50:00 -0700 > This patchset upgrades vmxnet3 to version 3. As stated by others, it is completely unacceptable to post so many patches with little or no commit log message. You must describe, in full detail, what each and every patch does, why it is doing so, and how it is doing it.
Re: [RFC][PATCH 8/8] rtmutex: Fix PI chain order integrity
On 14/06/16 21:44, Peter Zijlstra wrote: > On Tue, Jun 14, 2016 at 06:39:08PM +0100, Juri Lelli wrote: > > On 07/06/16 21:56, Peter Zijlstra wrote: > > > rt_mutex_waiter::prio is a copy of task_struct::prio which is updated > > > during the PI chain walk, such that the PI chain order isn't messed up > > > by (asynchronous) task state updates. > > > > > > Currently rt_mutex_waiter_less() uses task state for deadline tasks; > > > this is broken, since the task state can, as said above, change > > > asynchronously, causing the RB tree order to change without actual > > > tree update -> FAIL. > > > > > > Fix this by also copying the deadline into the rt_mutex_waiter state > > > and updating it along with its prio field. > > > > > > Ideally we would also force PI chain updates whenever DL tasks update > > > their deadline parameter, but for first approximation this is less > > > broken than it was. > > > > > > > The patch looks OK to me. However, I'm failing to see when we can update > > dl.deadline of a waiter asynchronously. Since a waiter is blocked, we > > can't really change his dl.deadline by calling setscheduler on him, as > > the update would operate on dl.dl_deadline. The new values will start to > > be used as soon as it gets unblocked. The situation seems different for > > RT tasks, for which priority change takes effect immediately. > > > > What am I missing? :-) > > Ah, I missed the dl_deadline vs deadline thing. Still, with optimistic > spinning the waiter could hit its throttle/refresh path, right? And then > that would update deadline. > I guess it's not that likely, but yes it could potentially happen that a waiter is optimistically spinning, depletes its runtime, gets throttled and then replenished when still spinning. Maybe it doesn't really make sense continuing spinning in this situation, but I guess things get really complicated. :-/ Anyway, as said, I think this patch is OK. Maybe we want to add a comment just to remember what situation can cause an issue if we don't do this? Patch changelog would be OK as well for such a comment IMHO. Thanks, - Juri
[PATCH] rcu: Fix soft lockup for rcu_nocb_kthread
I met this problem when using the Testgine to send package to ixgbevf nic by this steps: 1. Connect to ixgbevf, and set the speed to 10Gb/s, it could work fine. 2. Then use ifconfig to down the nic and up again, loop for several times. 3. The system panic by soft lockup. [ 317.005148] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready [ 368.106005] BUG: soft lockup - CPU#1 stuck for 22s! [rcuos/1:15] [ 368.106005] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 368.106005] task: 88057dd8a220 ti: 88057dd9c000 task.ti: 88057dd9c000 [ 368.106005] RIP: 0010:[] [] fib_table_lookup+0x14/0x390 [ 368.106005] RSP: 0018:88061fc83ce8 EFLAGS: 0286 [ 368.106005] RAX: 0001 RBX: 020155c0 RCX: 0001 [ 368.106005] RDX: 88061fc83d50 RSI: 88061fc83d70 RDI: 880036d11a00 [ 368.106005] RBP: 88061fc83d08 R08: 0001 R09: [ 368.106005] R10: 880036d11a00 R11: 819e0900 R12: 88061fc83c58 [ 368.106005] R13: 816154dd R14: 88061fc83d08 R15: 020155c0 [ 368.106005] FS: () GS:88061fc8() knlGS: [ 368.106005] CS: 0010 DS: ES: CR0: 80050033 [ 368.106005] CR2: 7f8c2aee9c40 CR3: 00057b222000 CR4: 000407e0 [ 368.106005] DR0: DR1: DR2: [ 368.106005] DR3: DR6: 0ff0 DR7: 0400 [ 368.106005] Stack: [ 368.106005] 01c0 88057b766000 8802e380b000 88057af03e00 [ 368.106005] 88061fc83dc0 815349a6 88061fc83d40 814ee146 [ 368.106005] 8802e380af00 e380af00 819e0900 020155c001c0 [ 368.106005] Call Trace: [ 368.106005] [ 368.106005] [ 368.106005] [] ip_route_input_noref+0x516/0xbd0 [ 368.106005] [] ? skb_release_data+0xd6/0x110 [ 368.106005] [] ? kfree_skb+0x3a/0xa0 [ 368.106005] [] ip_rcv_finish+0x29f/0x350 [ 368.106005] [] ip_rcv+0x234/0x380 [ 368.106005] [] __netif_receive_skb_core+0x676/0x870 [ 368.106005] [] __netif_receive_skb+0x18/0x60 [ 368.106005] [] process_backlog+0xae/0x180 [ 368.106005] [] net_rx_action+0x152/0x240 [ 368.106005] [] __do_softirq+0xef/0x280 [ 368.106005] [] call_softirq+0x1c/0x30 [ 368.106005] [ 368.106005] [ 368.106005] [] do_softirq+0x65/0xa0 [ 368.106005] [] local_bh_enable+0x94/0xa0 [ 368.106005] [] rcu_nocb_kthread+0x232/0x370 [ 368.106005] [] ? wake_up_bit+0x30/0x30 [ 368.106005] [] ? rcu_start_gp+0x40/0x40 [ 368.106005] [] kthread+0xcf/0xe0 [ 368.106005] [] ? kthread_create_on_node+0x140/0x140 [ 368.106005] [] ret_from_fork+0x58/0x90 [ 368.106005] [] ? kthread_create_on_node+0x140/0x140 ==cut here== Then I check the rcuos thread rcu_nocb_kthread, it will invokes callbacks queued by the corresponding no-CBs cpu, in the loops, it will disable the local irq and enable again, in the local_bh_enable() it will call do_softirq() to deal the package in the recv queue, it looks takes long time, so add cont_sched to feed the watchdog to fix the problem. Signed-off-by: Ding Tianhong --- kernel/rcu/tree_plugin.h | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index ff1cd4e..1bc729a 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2262,6 +2262,7 @@ static int rcu_nocb_kthread(void *arg) cl++; c++; local_bh_enable(); + cond_resched(); list = next; } trace_rcu_batch_end(rdp->rsp->name, c, !!list, 0, 0, 1); -- 1.9.0
[PATCH 3.12 00/56] 3.12.61-stable review
This is the start of the stable review cycle for the 3.12.61 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Jun 17 09:29:40 CEST 2016. Anything received after that time might be too late. The whole patch series can be found in one patch at: http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.61-rc1.xz and the diffstat can be found below. thanks, js === Adrian Hunter (1): mmc: mmc: Fix partition switch timeout for some eMMCs Alistair Leslie-Hughes (1): HID: microsoft: add support for 3 more devices Antti Palosaari (1): [media] af9035: correct eeprom offsets Benjamin Coddington (1): NFS: Don't attempt to decode missing directory entries Chanwoo Choi (1): serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios() Colin Ian King (1): pch_phub: return -ENODATA if ROM can't be mapped Cyan Ogilvie (1): HID: wiimote: Fix wiimote mp scale linearization Dan Bogdan Nechita (1): misc: ad525x_dpot: Fix the enabling of the "otpXen" attributes Daniel Bristot de Oliveira (1): HID: usbhid: enable NO_INIT_REPORTS quirk for Semico USB Keykoard2 Dave Chinner (3): xfs: xfs_iflush_cluster fails to abort on error xfs: fix inode validity check in xfs_iflush_cluster xfs: skip stale inodes in xfs_iflush_cluster Dave Gerlach (1): cpuidle: Indicate when a device has been unregistered Donavan Lance (1): HID: Add new Microsoft Type Cover 3 product ID Hari Bathini (1): powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel Itai Handler (1): drm/gma500: Fix possible out of bounds read James Hogan (1): MIPS: Fix siginfo.h to use strict posix types Jason Gunthorpe (1): IB/security: Restrict use of the write() interface Jiri Slaby (1): tty: vt, return error when con_startup fails Johan Hovold (4): USB: serial: keyspan: fix use-after-free in probe error path USB: serial: quatech2: fix use-after-free in probe error path USB: serial: io_edgeport: fix memory leaks in attach error path USB: serial: io_edgeport: fix memory leaks in probe error path Joseph Salisbury (1): ath5k: Change led pin configuration for compaq c700 laptop Loic Poulain (1): Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data Lv Zheng (1): ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings Lyude (1): drm/fb_helper: Fix references to dev->mode_config.num_connector Matt Gumbel (1): mmc: longer timeout for long read time quirk Matthias Schiffer (1): MIPS: ath79: make bootconsole wait for both THRE and TEMT Nazar Mokrynskyi (1): HID: Fix boot delay for Creative SB Omni Surround 5.1 with quirk Nicolai Stange (2): ext4: address UBSAN warning in mb_find_order_for_block() ext4: silence UBSAN in ext4_mb_init() Paul Burton (1): MIPS: math-emu: Fix jalr emulation when rd == $0 Prarit Bhargava (1): PCI: Disable all BAR sizing for devices with non-compliant BARs Raghava Aditya Renukunta (2): aacraid: Relinquish CPU during timeout wait aacraid: Fix for aac_command_thread hang Raimund Roth (1): HID: microsoft: Add Surface Power Cover Ricky Liang (1): Input: uinput - handle compat ioctl for UI_SET_PHYS Ross Lagerwall (1): xen/events: Don't move disabled irqs Schemmel Hans-Christoph (1): USB: serial: option: add support for Cinterion PH8 and AHxx Sean Young (1): HID: sjoy: support Super Joy Box 4 Slava Bacherikov (1): HID: microsoft: Add ID for MS Wireless Comfort Keyboard Stefan Metzmacher (1): fs/cifs: correctly to anonymous authentication via NTLMSSP Stephen Just (1): HID: microsoft: Add Surface 3 type cover Steve French (1): remove directory incorrectly tries to set delete on close on non-empty directories Steven Rostedt (Red Hat) (2): ring-buffer: Use long for nr_pages to avoid overflow failures ring-buffer: Prevent overflow of size in ring_buffer_resize() Theodore Ts'o (1): ext4: fix hang when processing corrupted orphaned inode list Tomáš Trnka (1): sunrpc: fix stripping of padded MIC tokens Trent Lloyd (1): HID: usbhid: quirks for Corsair RGB keyboard & mice (K70R, K95RGB, M65RGB, K70RGB, K65RGB) Ville Syrjälä (1): dma-debug: avoid spinlock recursion when disabling dma-debug Vineet Gupta (1): ARC: use ASL assembler mnemonic Vladis Dronov (1): [media] usbvision: revert commit 588afcc1 Wei-Ning Huang (1): Bluetooth: btmrvl_sdio: fix firmware activation failure wang yanqing (1): rtlwifi: Fix logic error in enter/exit power-save mode Николай Кудрявцев (1): HID: chicony: Add support for Acer Aspire Switch 12 arch/arc/mm/tlbex.S | 6 ++-- arch/mips/ath79/early_printk.c| 6 ++-- arch/mips/include/uapi/asm/siginfo.h | 18 +- arch/mips/math-emu/cp1emu.c
Re: [PATCH 02/48] ARM: at91: Document new TCB bindings
On Tue, 14 Jun 2016 16:47:37 -0500
Rob Herring wrote:
> On Sat, Jun 11, 2016 at 12:03:05AM +0200, Alexandre Belloni wrote:
> > The current binding for the TCB is not flexible enough for some use cases
> > and prevents proper utilization of all the channels.
> >
> > Cc: Daniel Lezcano
> > Cc: Thierry Reding
> > Cc: linux-...@vger.kernel.org
> > Cc: Rob Herring
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Alexandre Belloni
> > ---
> > .../devicetree/bindings/arm/atmel-at91.txt | 32 ---
> > .../devicetree/bindings/mfd/atmel-tcb.txt | 62
> > ++
> > .../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 12 +++--
> > 3 files changed, 69 insertions(+), 37 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
> > b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
> > new file mode 100644
> > index ..48196752c78f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt
> > @@ -0,0 +1,62 @@
> > +* Device tree bindings for Atmel Timer Counter Blocks
> > +- compatible: Should be "atmel,-tcb", "simple-mfd", "syscon".
> > + can be "at91rm9200" or "at91sam9x5"
> > +- reg: Should contain registers location and length
> > +- #address-cells: has to be 1
> > +- #size-cells: has to be 0
> > +- interrupts: Should contain all interrupts for the TC block
> > + Note that you can specify several interrupt cells if the TC
> > + block has one interrupt per channel.
> > +- clock-names: tuple listing input clock names.
> > + Required elements: "t0_clk", "slow_clk"
> > + Optional elements: "t1_clk", "t2_clk"
> > +- clocks: phandles to input clocks.
>
> What is the order of clocks?
>
> > +
> > +The TCB can expose multiple subdevices:
> > + * a clocksource and clockevent device
>
> No. These compatible names are linuxisms. Describe features of the
> timers to be able to select which timer to use if you need to pick
> certain timers. For example, interrupt capability could be used to
> select the clkevt.
Would 'atmel,tcb-free-running-timer' (to replace 'atmel,tcb-clksrc') and
'atmel,tcb-programmable-timer' (to replace 'atmel,tcb-clkevt') be
acceptable?
>
> > + - compatible: Should be "atmel,tcb-clksrc"
> > + - reg: Should contain the TCB channels to be used. If the
> > + counter width is 16 bits (at91rm9200-tcb), two consecutive
> > + channels are needed. Else, only one channel will be used.
> > +
> > + * a clockevent device
> > + - compatible: Should be "atmel,tcb-clkevt"
> > + - reg: Should contain the TCB channel to be used
> > +
> > + * a PWM chip: see ../pwm/atmel-tcb-pwm.txt
> > +
> > +Examples:
> > +
> > +One interrupt per TC block:
> > + tcb0: timer@fff7c000 {
> > + compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0xfff7c000 0x100>;
> > + interrupts = <18 4>;
> > + clocks = <&tcb0_clk>;
> > + clock-names = "t0_clk";
>
> Missing slow_clk
>
> > +
> > + timer@0 {
> > + compatible = "atmel,tcb-clksrc";
> > + reg = <0>, <1>;
> > + };
> > +
> > + timer@2 {
> > + compatible = "atmel,tcb-clkevt";
> > + reg = <2>;
> > + };
> > + };
> > +
> > +One interrupt per TC channel in a TC block:
> > + tcb1: timer@fffdc000 {
> > + compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0xfffdc000 0x100>;
> > + interrupts = <26 4>, <27 4>, <28 4>;
> > + clocks = <&tcb1_clk>;
> > + clock-names = "t0_clk";
> > + };
> > +
> > +
> > diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > index 8031148bcf85..ab8fbd5ba184 100644
> > --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > @@ -2,15 +2,17 @@ Atmel TCB PWM controller
> >
> > Required properties:
> > - compatible: should be "atmel,tcb-pwm"
> > +- reg: tcb channel to use. Each channel can export 2 PWMs
>
> Is there a difference in channels? If not, then this compatible should
> go.
This one I don't understand.
The TCB (Timer Counter Block) is an MFD containing 3 Timer Counter
devices. Each of these devices (also called channels) can be assigned a
specific mode:
- timer mode (free-running of programmable)
- waveform generator mode (IOW, a PWM)
- capture mode (an IIO device, but we don't have any driver for that
right now)
So each sub-device of the TCB is represented as a sub-node with its own
compatible. Is there a problem with that?
>
> > - #pwm-cells: should be 3. See
[PATCH 3.12 04/56] HID: Fix boot delay for Creative SB Omni Surround 5.1 with quirk
From: Nazar Mokrynskyi
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 567a44ecb44eb2584ddb93e962cfb133ce77e0bb upstream.
Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
Signed-off-by: Nazar Mokrynskyi
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1ffecd312bb8..fb200df1e78e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -247,6 +247,7 @@
#define USB_DEVICE_ID_CORSAIR_K65RGB0x1b17
#define USB_VENDOR_ID_CREATIVELABS 0x041e
+#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51 0x322c
#define USB_DEVICE_ID_PRODIKEYS_PCMIDI 0x2801
#define USB_VENDOR_ID_CVTOUCH 0x1ff7
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 5f808789f145..3771a7ef6395 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -75,6 +75,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K95RGB,
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_CREATIVELABS,
USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
HID_QUIRK_ALWAYS_POLL },
--
2.9.0
[PATCH 3.12 01/56] NFS: Don't attempt to decode missing directory entries
From: Benjamin Coddington
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ce85cfbed6fe3dbc01bd1976b23ac3e97878cde6 upstream.
If a READDIR reply comes back without any page data, avoid a NULL pointer
dereference in xdr_copy_to_scratch().
BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [] memcpy+0xd/0x110
...
Call Trace:
? xdr_inline_decode+0x7a/0xb0 [sunrpc]
nfs3_decode_dirent+0x73/0x320 [nfsv3]
nfs_readdir_page_filler+0xd5/0x4e0 [nfs]
? nfs3_rpc_wrapper.constprop.9+0x42/0xc0 [nfsv3]
nfs_readdir_xdr_to_array+0x1fa/0x330 [nfs]
? mem_cgroup_commit_charge+0xac/0x160
? nfs_readdir_xdr_to_array+0x330/0x330 [nfs]
nfs_readdir_filler+0x22/0x90 [nfs]
do_read_cache_page+0x7e/0x1a0
read_cache_page+0x1c/0x20
nfs_readdir+0x18e/0x660 [nfs]
? nfs3_xdr_dec_getattr3res+0x80/0x80 [nfsv3]
iterate_dir+0x97/0x130
SyS_getdents+0x94/0x120
? fillonedir+0xd0/0xd0
system_call_fastpath+0x12/0x17
Signed-off-by: Benjamin Coddington
Signed-off-by: Trond Myklebust
Cc: Neil Brown
Signed-off-by: Jiri Slaby
---
fs/nfs/dir.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 140280623348..cf6ede69a2e2 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -510,6 +510,9 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc,
struct nfs_entry *en
if (scratch == NULL)
return -ENOMEM;
+ if (buflen == 0)
+ goto out_nopages;
+
xdr_init_decode_pages(&stream, &buf, xdr_pages, buflen);
xdr_set_scratch_buffer(&stream, page_address(scratch), PAGE_SIZE);
@@ -531,6 +534,7 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc,
struct nfs_entry *en
break;
} while (!entry->eof);
+out_nopages:
if (count == 0 || (status == -EBADCOOKIE && entry->eof != 0)) {
array = nfs_readdir_get_array(page);
if (!IS_ERR(array)) {
--
2.9.0
[PATCH 3.12 03/56] HID: usbhid: quirks for Corsair RGB keyboard & mice (K70R, K95RGB, M65RGB, K70RGB, K65RGB)
From: Trent Lloyd
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 282bf1fe6dca4b768d6bedc14aea1b82c36241c1 upstream.
These devices feature multiple interfaces/endpoints: a legacy BIOS/boot
interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces
(endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint
0x84 IN/0x04 OUT)
Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT,
HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint
(30s per device) occurs initialising reports on boot. We configure
HID_QUIRK_NO_INIT_REPORTS for these devices.
Additionally the left-side G1-G18 macro keys on the K95RGB generate output on
the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding
waiting for this event to be collected. We enable HID_QUIRK_ALWAYS_POLL to
prevent this situation from occurring.
Signed-off-by: Trent Lloyd
Tested-by: SUGNIAUX Wilfried
Signed-off-by: Jiri Kosina
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-ids.h | 9 +
drivers/hid/usbhid/hid-quirks.c | 5 +
2 files changed, 14 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 50b25fad982d..1ffecd312bb8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -237,6 +237,15 @@
#define USB_DEVICE_ID_CODEMERCS_IOW_FIRST 0x1500
#define USB_DEVICE_ID_CODEMERCS_IOW_LAST 0x15ff
+#define USB_VENDOR_ID_CORSAIR 0x1b1c
+
+#define USB_VENDOR_ID_CORSAIR 0x1b1c
+#define USB_DEVICE_ID_CORSAIR_K70R 0x1b09
+#define USB_DEVICE_ID_CORSAIR_K95RGB0x1b11
+#define USB_DEVICE_ID_CORSAIR_M65RGB0x1b12
+#define USB_DEVICE_ID_CORSAIR_K70RGB0x1b13
+#define USB_DEVICE_ID_CORSAIR_K65RGB0x1b17
+
#define USB_VENDOR_ID_CREATIVELABS 0x041e
#define USB_DEVICE_ID_PRODIKEYS_PCMIDI 0x2801
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 7166d7fb43de..5f808789f145 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -70,6 +70,11 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70R,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_M65RGB,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K95RGB,
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
HID_QUIRK_ALWAYS_POLL },
--
2.9.0
[PATCH 3.12 43/56] drm/gma500: Fix possible out of bounds read
From: Itai Handler
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.
Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).
Signed-off-by: Itai Handler
Signed-off-by: Patrik Jakobsson
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 489ffd2c66e5..a3d37e4a84ae 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -85,7 +85,7 @@ static const char *const dsi_errors[] = {
"RX Prot Violation",
"HS Generic Write FIFO Full",
"LP Generic Write FIFO Full",
- "Generic Read Data Avail"
+ "Generic Read Data Avail",
"Special Packet Sent",
"Tearing Effect",
};
--
2.9.0
[PATCH 3.12 40/56] powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel
From: Hari Bathini
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream.
Some of the interrupt vectors on 64-bit POWER server processors are only
32 bytes long (8 instructions), which is not enough for the full
first-level interrupt handler. For these we need to branch to an
out-of-line (OOL) handler. But when we are running a relocatable kernel,
interrupt vectors till __end_interrupts marker are copied down to real
address 0x100. So, branching to labels (ie. OOL handlers) outside this
section must be handled differently (see LOAD_HANDLER()), considering
relocatable kernel, which would need at least 4 instructions.
However, branching from interrupt vector means that we corrupt the
CFAR (come-from address register) on POWER7 and later processors as
mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
that contains the part up to the point where the CFAR is saved in the
PACA should be part of the short interrupt vectors before we branch out
to OOL handlers.
But as mentioned already, there are interrupt vectors on 64-bit POWER
server processors that are only 32 bytes long (like vectors 0x4f00,
0x4f20, etc.), which cannot accomodate the above two cases at the same
time owing to space constraint. Currently, in these interrupt vectors,
we simply branch out to OOL handlers, without using LOAD_HANDLER(),
which leaves us vulnerable when running a relocatable kernel (eg. kdump
case). While this has been the case for sometime now and kdump is used
widely, we were fortunate not to see any problems so far, for three
reasons:
1. In almost all cases, production kernel (relocatable) is used for
kdump as well, which would mean that crashed kernel's OOL handler
would be at the same place where we end up branching to, from short
interrupt vector of kdump kernel.
2. Also, OOL handler was unlikely the reason for crash in almost all
the kdump scenarios, which meant we had a sane OOL handler from
crashed kernel that we branched to.
3. On most 64-bit POWER server processors, page size is large enough
that marking interrupt vector code as executable (see commit
429d2e83) leads to marking OOL handler code from crashed kernel,
that sits right below interrupt vector code from kdump kernel, as
executable as well.
Let us fix this by moving the __end_interrupts marker down past OOL
handlers to make sure that we also copy OOL handlers to real address
0x100 when running a relocatable kernel.
This fix has been tested successfully in kdump scenario, on an LPAR with
4K page size by using different default/production kernel and kdump
kernel.
Also tested by manually corrupting the OOL handlers in the first kernel
and then kdump'ing, and then causing the OOL handlers to fire - mpe.
Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers")
Signed-off-by: Hari Bathini
Signed-off-by: Mahesh Salgaonkar
Signed-off-by: Michael Ellerman
Signed-off-by: Jiri Slaby
---
arch/powerpc/kernel/exceptions-64s.S | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 3a9ed6ac224b..3aaf76fd7975 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -864,11 +864,6 @@ hv_facility_unavailable_relon_trampoline:
#endif
STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist)
- /* Other future vectors */
- .align 7
- .globl __end_interrupts
-__end_interrupts:
-
.align 7
system_call_entry_direct:
#if defined(CONFIG_RELOCATABLE)
@@ -1198,6 +1193,17 @@ __end_handlers:
STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
+ /*
+* The __end_interrupts marker must be past the out-of-line (OOL)
+* handlers, so that they are copied to real address 0x100 when running
+* a relocatable kernel. This ensures they can be reached from the short
+* trampoline handlers (like 0x4f00, 0x4f20, etc.) which branch
+* directly, without using LOAD_HANDLER().
+*/
+ .align 7
+ .globl __end_interrupts
+__end_interrupts:
+
#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
/*
* Data area reserved for FWNMI option.
--
2.9.0
[PATCH 3.12 54/56] pch_phub: return -ENODATA if ROM can't be mapped
From: Colin Ian King
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit a75fa128236bc2fdaa5e412145cbd577e42e14c2 upstream.
The error return err is not initialized for the case when pci_map_rom
fails and no ROM can me mapped. Fix this by setting ret to -ENODATA;
(this is the same error value that is returned if the ROM data is
successfully mapped but does not match the expected ROM signature.).
Issue found from static code analysis using CoverityScan.
Signed-off-by: Colin Ian King
Signed-off-by: Greg Kroah-Hartman
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/misc/pch_phub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index a5925f7f17f6..829ca77c143e 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -512,8 +512,10 @@ static ssize_t pch_phub_bin_read(struct file *filp, struct
kobject *kobj,
/* Get Rom signature */
chip->pch_phub_extrom_base_address = pci_map_rom(chip->pdev, &rom_size);
- if (!chip->pch_phub_extrom_base_address)
+ if (!chip->pch_phub_extrom_base_address) {
+ err = -ENODATA;
goto exrom_map_err;
+ }
pch_phub_read_serial_rom(chip, chip->pch_opt_rom_start_address,
(unsigned char *)&rom_signature);
--
2.9.0
[PATCH 3.12 12/56] HID: wiimote: Fix wiimote mp scale linearization
From: Cyan Ogilvie 3.12-stable review patch. If anyone has any objections, please let me know. === commit d30596737e8e7b2f1235d7ba20592b8309e3af04 upstream. The wiimote motion plus gyros use two scales to report fast and slow rotation - below 440 deg/s uses 8192/440 units / deg/s, and above uses 8192/2000 units / deg/s. Previously this driver attempted to linearize the two by scaling the fast rate by 18 and the slow by 9, but this results in a scale of 8192*9/440 = ~167.564 for slow and 8192*18/2000 = 73.728 for fast. Correct the fast motion scale factor so that both report ~167.564 units / deg/s Signed-off-by: Cyan Ogilvie Reviewed-by: David Herrmann Signed-off-by: Jiri Kosina Cc: Oliver Neukum Signed-off-by: Jiri Slaby --- drivers/hid/hid-wiimote-modules.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/hid/hid-wiimote-modules.c b/drivers/hid/hid-wiimote-modules.c index e30567af42ed..20e102866549 100644 --- a/drivers/hid/hid-wiimote-modules.c +++ b/drivers/hid/hid-wiimote-modules.c @@ -1951,9 +1951,11 @@ static void wiimod_mp_in_mp(struct wiimote_data *wdata, const __u8 *ext) * -+--+-+-+ * The single bits Yaw, Roll, Pitch in the lower right corner specify * whether the wiimote is rotating fast (0) or slow (1). Speed for slow -* roation is 440 deg/s and for fast rotation 2000 deg/s. To get a -* linear scale we multiply by 2000/440 = ~4.5454 which is 18 for fast -* and 9 for slow. +* roation is 8192/440 units / deg/s and for fast rotation 8192/2000 +* units / deg/s. To get a linear scale for fast rotation we multiply +* by 2000/440 = ~4.5454 and scale both fast and slow by 9 to match the +* previous scale reported by this driver. +* This leaves a linear scale with 8192*9/440 (~167.564) units / deg/s. * If the wiimote is not rotating the sensor reports 2^13 = 8192. * Ext specifies whether an extension is connected to the motionp. * which is parsed by wiimote-core. @@ -1972,15 +1974,15 @@ static void wiimod_mp_in_mp(struct wiimote_data *wdata, const __u8 *ext) z -= 8192; if (!(ext[3] & 0x02)) - x *= 18; + x = (x * 2000 * 9) / 440; else x *= 9; if (!(ext[4] & 0x02)) - y *= 18; + y = (y * 2000 * 9) / 440; else y *= 9; if (!(ext[3] & 0x01)) - z *= 18; + z = (z * 2000 * 9) / 440; else z *= 9; -- 2.9.0
[PATCH 3.12 47/56] ext4: silence UBSAN in ext4_mb_init()
From: Nicolai Stange
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.
Currently, in ext4_mb_init(), there's a loop like the following:
do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
} while (i <= sb->s_blocksize_bits + 1);
Note that the updated offset is used in the loop's next iteration only.
However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
shift exponent 4294967295 is too large for 32-bit type 'int'
[...]
Call Trace:
[] dump_stack+0xbc/0x117
[] ? _atomic_dec_and_lock+0x169/0x169
[] ubsan_epilogue+0xd/0x4e
[] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
[] ? __ubsan_handle_load_invalid_value+0x158/0x158
[] ? kmem_cache_alloc+0x101/0x390
[] ? ext4_mb_init+0x13b/0xfd0
[] ? create_cache+0x57/0x1f0
[] ? create_cache+0x11a/0x1f0
[] ? mutex_lock+0x38/0x60
[] ? mutex_unlock+0x1b/0x50
[] ? put_online_mems+0x5b/0xc0
[] ? kmem_cache_create+0x117/0x2c0
[] ext4_mb_init+0xc49/0xfd0
[...]
Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.
Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
Signed-off-by: Nicolai Stange
Signed-off-by: Theodore Ts'o
Signed-off-by: Jiri Slaby
---
fs/ext4/mballoc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 4d42e50ab0a0..4a79ce1ecaa1 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2537,7 +2537,7 @@ int ext4_mb_init(struct super_block *sb)
{
struct ext4_sb_info *sbi = EXT4_SB(sb);
unsigned i, j;
- unsigned offset;
+ unsigned offset, offset_incr;
unsigned max;
int ret;
@@ -2566,11 +2566,13 @@ int ext4_mb_init(struct super_block *sb)
i = 1;
offset = 0;
+ offset_incr = 1 << (sb->s_blocksize_bits - 1);
max = sb->s_blocksize << 2;
do {
sbi->s_mb_offsets[i] = offset;
sbi->s_mb_maxs[i] = max;
- offset += 1 << (sb->s_blocksize_bits - i);
+ offset += offset_incr;
+ offset_incr = offset_incr >> 1;
max = max >> 1;
i++;
} while (i <= sb->s_blocksize_bits + 1);
--
2.9.0
[PATCH 3.12 30/56] MIPS: math-emu: Fix jalr emulation when rd == $0
From: Paul Burton
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream.
When emulating a jalr instruction with rd == $0, the code in
isBranchInstr was incorrectly writing to GPR $0 which should actually
always remain zeroed. This would lead to any further instructions
emulated which use $0 operating on a bogus value until the task is next
context switched, at which point the value of $0 in the task context
would be restored to the correct zero by a store in SAVE_SOME. Fix this
by not writing to rd if it is $0.
Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
Signed-off-by: Paul Burton
Cc: Maciej W. Rozycki
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13160/
Signed-off-by: Ralf Baechle
Signed-off-by: Jiri Slaby
---
arch/mips/math-emu/cp1emu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index efe008846ed0..95745858a694 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -670,9 +670,11 @@ static int isBranchInstr(struct pt_regs *regs, struct
mm_decoded_insn dec_insn,
case spec_op:
switch (insn.r_format.func) {
case jalr_op:
- regs->regs[insn.r_format.rd] =
- regs->cp0_epc + dec_insn.pc_inc +
- dec_insn.next_pc_inc;
+ if (insn.r_format.rd != 0) {
+ regs->regs[insn.r_format.rd] =
+ regs->cp0_epc + dec_insn.pc_inc +
+ dec_insn.next_pc_inc;
+ }
/* Fall through */
case jr_op:
*contpc = regs->regs[insn.r_format.rs];
--
2.9.0
[PATCH 3.12 02/56] IB/security: Restrict use of the write() interface
From: Jason Gunthorpe
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 upstream.
The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl(). This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.
For the immediate repair, detect and deny suspicious accesses to
the write API.
For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).
The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.
[js] backport to 3.12: hfi1 is not there yet (exclude), ipath is still
there (include)
Reported-by: Jann Horn
Signed-off-by: Linus Torvalds
Signed-off-by: Jason Gunthorpe
[ Expanded check to all known write() entry points ]
Signed-off-by: Doug Ledford
Signed-off-by: Jiri Slaby
---
drivers/infiniband/core/ucm.c| 4
drivers/infiniband/core/ucma.c | 3 +++
drivers/infiniband/core/uverbs_main.c| 5 +
drivers/infiniband/hw/ipath/ipath_file_ops.c | 5 +
drivers/infiniband/hw/qib/qib_file_ops.c | 5 +
include/rdma/ib.h| 16
6 files changed, 38 insertions(+)
diff --git a/drivers/infiniband/core/ucm.c b/drivers/infiniband/core/ucm.c
index f2f63933e8a9..5befec118a18 100644
--- a/drivers/infiniband/core/ucm.c
+++ b/drivers/infiniband/core/ucm.c
@@ -48,6 +48,7 @@
#include
+#include
#include
#include
#include
@@ -1104,6 +1105,9 @@ static ssize_t ib_ucm_write(struct file *filp, const char
__user *buf,
struct ib_ucm_cmd_hdr hdr;
ssize_t result;
+ if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
+ return -EACCES;
+
if (len < sizeof(hdr))
return -EINVAL;
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index b0f189be543b..da67839fc451 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1494,6 +1494,9 @@ static ssize_t ucma_write(struct file *filp, const char
__user *buf,
struct rdma_ucm_cmd_hdr hdr;
ssize_t ret;
+ if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
+ return -EACCES;
+
if (len < sizeof(hdr))
return -EINVAL;
diff --git a/drivers/infiniband/core/uverbs_main.c
b/drivers/infiniband/core/uverbs_main.c
index 68e5496c5d58..ee5222168b68 100644
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -48,6 +48,8 @@
#include
+#include
+
#include "uverbs.h"
MODULE_AUTHOR("Roland Dreier");
@@ -601,6 +603,9 @@ static ssize_t ib_uverbs_write(struct file *filp, const
char __user *buf,
struct ib_uverbs_file *file = filp->private_data;
struct ib_uverbs_cmd_hdr hdr;
+ if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
+ return -EACCES;
+
if (count < sizeof hdr)
return -EINVAL;
diff --git a/drivers/infiniband/hw/ipath/ipath_file_ops.c
b/drivers/infiniband/hw/ipath/ipath_file_ops.c
index 6d7f453b4d05..a0626b8c61c5 100644
--- a/drivers/infiniband/hw/ipath/ipath_file_ops.c
+++ b/drivers/infiniband/hw/ipath/ipath_file_ops.c
@@ -45,6 +45,8 @@
#include
#include
+#include
+
#include "ipath_kernel.h"
#include "ipath_common.h"
#include "ipath_user_sdma.h"
@@ -2240,6 +2242,9 @@ static ssize_t ipath_write(struct file *fp, const char
__user *data,
ssize_t ret = 0;
void *dest;
+ if (WARN_ON_ONCE(!ib_safe_file_access(fp)))
+ return -EACCES;
+
if (count < sizeof(cmd.type)) {
ret = -EINVAL;
goto bail;
diff --git a/drivers/infiniband/hw/qib/qib_file_ops.c
b/drivers/infiniband/hw/qib/qib_file_ops.c
index 2023cd61b897..3c089ca85c64 100644
--- a/drivers/infiniband/hw/qib/qib_file_ops.c
+++ b/drivers/infiniband/hw/qib/qib_file_ops.c
@@ -45,6 +45,8 @@
#include
#include
+#include
+
#include "qib.h"
#include "qib_common.h"
#include "qib_user_sdma.h"
@@ -2058,6 +2060,9 @@ static ssize_t qib_write(struct file *fp, const char
__user *data,
ssize_t ret = 0;
void *dest;
+ if (WARN_ON_ONCE(!ib_safe_file_access(fp)))
+ return -EACCES;
+
if (count < sizeof(cmd.type)) {
ret = -EINVAL;
goto bail;
diff --git a/include/rdma/ib.h b/include/rdma/ib.h
index cf8f9e700e48..a6b93706b0fc 100644
--- a/include/rdma/ib.h
+++ b/include/rdma/ib.h
@@ -34,6 +34,7 @@
#define _RDMA_IB_H
#include
+#include
struct ib_addr {
union {
@@ -86,4 +87,19 @@ struct sockaddr_ib {
__u64 sib_scope_id;
};
+/*
+ * The IB interfaces th
[PATCH 3.12 52/56] [media] af9035: correct eeprom offsets
From: Antti Palosaari
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 9c574ad4d360353ec8dd6bc85e78d8b2d0f8e775 upstream.
Used memory mapped eeprom offsets were off-by 8 bytes.
Signed-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/media/usb/dvb-usb-v2/af9035.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h
b/drivers/media/usb/dvb-usb-v2/af9035.h
index a1c68d829b8c..39b0123fe36c 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.h
+++ b/drivers/media/usb/dvb-usb-v2/af9035.h
@@ -109,20 +109,20 @@ static const u32 clock_lut_it9135[] = {
* Values 0 and 3 are seen to this day. 0 for single TS and 3 for dual TS.
*/
-#define EEPROM_BASE_AF90350x42fd
-#define EEPROM_BASE_IT91350x499c
+#define EEPROM_BASE_AF90350x42f5
+#define EEPROM_BASE_IT91350x4994
#define EEPROM_SHIFT0x10
-#define EEPROM_IR_MODE 0x10
-#define EEPROM_TS_MODE 0x29
-#define EEPROM_2ND_DEMOD_ADDR 0x2a
-#define EEPROM_IR_TYPE 0x2c
-#define EEPROM_1_IF_L 0x30
-#define EEPROM_1_IF_H 0x31
-#define EEPROM_1_TUNER_ID 0x34
-#define EEPROM_2_IF_L 0x40
-#define EEPROM_2_IF_H 0x41
-#define EEPROM_2_TUNER_ID 0x44
+#define EEPROM_IR_MODE 0x18
+#define EEPROM_TS_MODE 0x31
+#define EEPROM_2ND_DEMOD_ADDR 0x32
+#define EEPROM_IR_TYPE 0x34
+#define EEPROM_1_IF_L 0x38
+#define EEPROM_1_IF_H 0x39
+#define EEPROM_1_TUNER_ID 0x3c
+#define EEPROM_2_IF_L 0x48
+#define EEPROM_2_IF_H 0x49
+#define EEPROM_2_TUNER_ID 0x4c
/* USB commands */
#define CMD_MEM_RD 0x00
--
2.9.0
[PATCH 3.12 50/56] xfs: fix inode validity check in xfs_iflush_cluster
From: Dave Chinner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 51b07f30a71c27405259a0248206ed4e22adbee2 upstream.
Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs:
convert inode cache lookups to use RCU locking") back in late 2010,
and so xfs_iflush_cluster checks the wrong inode for whether it is
still valid under RCU protection. Fix it to lock and check the
correct inode.
(*) Careless-idiot: Dave Chinner
Discovered-by: Brain Foster
Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
Signed-off-by: Dave Chinner
Signed-off-by: Jiri Slaby
---
fs/xfs/xfs_inode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 771f5359799c..363bcd8eabf6 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2900,13 +2900,13 @@ xfs_iflush_cluster(
* We need to check under the i_flags_lock for a valid inode
* here. Skip it if it is not valid or the wrong inode.
*/
- spin_lock(&ip->i_flags_lock);
- if (!ip->i_ino ||
+ spin_lock(&iq->i_flags_lock);
+ if (!iq->i_ino ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
- spin_unlock(&ip->i_flags_lock);
+ spin_unlock(&iq->i_flags_lock);
continue;
}
- spin_unlock(&ip->i_flags_lock);
+ spin_unlock(&iq->i_flags_lock);
/*
* Do an un-protected check to see if the inode is dirty and
--
2.9.0
[PATCH 3.12 42/56] sunrpc: fix stripping of padded MIC tokens
From: Tomáš Trnka
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream.
The length of the GSS MIC token need not be a multiple of four bytes.
It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
would previously only trim mic.len + 4 B. The remaining up to three
bytes would then trigger a check in nfs4svc_decode_compoundargs(),
leading to a "garbage args" error and mount failure:
nfs4svc_decode_compoundargs: compound not properly padded!
nfsd: failed to decode arguments!
This would prevent older clients using the pre-RFC 4121 MIC format
(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
servers using krb5i.
The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off
trailing checksum before returning decrypted or integrity authenticated
buffer").
Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..."
Signed-off-by: Tomáš Trnka
Acked-by: Jeff Layton
Signed-off-by: J. Bruce Fields
Signed-off-by: Jiri Slaby
---
net/sunrpc/auth_gss/svcauth_gss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c
b/net/sunrpc/auth_gss/svcauth_gss.c
index e18be86dc486..9d7e6097ef5b 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -855,8 +855,8 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf
*buf, u32 seq, struct g
goto out;
if (svc_getnl(&buf->head[0]) != seq)
goto out;
- /* trim off the mic at the end before returning */
- xdr_buf_trim(buf, mic.len + 4);
+ /* trim off the mic and padding at the end before returning */
+ xdr_buf_trim(buf, round_up_to_quad(mic.len) + 4);
stat = 0;
out:
kfree(mic.data);
--
2.9.0
[PATCH 3.12 53/56] misc: ad525x_dpot: Fix the enabling of the "otpXen" attributes
From: Dan Bogdan Nechita
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 1bb850a1b7f68b66361e658e334f9fdf8231f17d upstream.
Currently writing the attributes with "echo" will result in comparing:
"enabled\n" with "enabled\0" and attribute is always set to false.
Use the sysfs_streq() instead because it treats both NUL and
new-line-then-NUL as equivalent string terminations.
Signed-off-by: Dan Bogdan Nechita
Signed-off-by: Greg Kroah-Hartman
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/misc/ad525x_dpot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
index 65fb74402c37..49811a8a1b07 100644
--- a/drivers/misc/ad525x_dpot.c
+++ b/drivers/misc/ad525x_dpot.c
@@ -458,7 +458,7 @@ static ssize_t sysfs_set_reg(struct device *dev,
int err;
if (reg & DPOT_ADDR_OTP_EN) {
- if (!strncmp(buf, "enabled", sizeof("enabled")))
+ if (sysfs_streq(buf, "enabled"))
set_bit(DPOT_RDAC_MASK & reg, data->otp_en_mask);
else
clear_bit(DPOT_RDAC_MASK & reg, data->otp_en_mask);
--
2.9.0
[PATCH 3.12 49/56] xfs: xfs_iflush_cluster fails to abort on error
From: Dave Chinner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.
When a failure due to an inode buffer occurs, the error handling
fails to abort the inode writeback correctly. This can result in the
inode being reclaimed whilst still in the AIL, leading to
use-after-free situations as well as filesystems that cannot be
unmounted as the inode log items left in the AIL never get removed.
Fix this by ensuring fatal errors from xfs_imap_to_bp() result in
the inode flush being aborted correctly.
[js] 3.12 needs EAGAIN, not -EAGAIN
Reported-by: Shyam Kaushik
Diagnosed-by: Shyam Kaushik
Tested-by: Shyam Kaushik
Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
Signed-off-by: Dave Chinner
Signed-off-by: Jiri Slaby
---
fs/xfs/xfs_inode.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index e3606f26f82d..771f5359799c 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -3022,7 +3022,7 @@ xfs_iflush(
struct xfs_buf **bpp)
{
struct xfs_mount*mp = ip->i_mount;
- struct xfs_buf *bp;
+ struct xfs_buf *bp = NULL;
struct xfs_dinode *dip;
int error;
@@ -3064,14 +3064,22 @@ xfs_iflush(
}
/*
-* Get the buffer containing the on-disk inode.
+* Get the buffer containing the on-disk inode. We are doing a try-lock
+* operation here, so we may get an EAGAIN error. In that case, we
+* simply want to return with the inode still dirty.
+*
+* If we get any other error, we effectively have a corruption situation
+* and we cannot flush the inode, so we treat it the same as failing
+* xfs_iflush_int().
*/
error = xfs_imap_to_bp(mp, NULL, &ip->i_imap, &dip, &bp, XBF_TRYLOCK,
0);
- if (error || !bp) {
+ if (error == EAGAIN) {
xfs_ifunlock(ip);
return error;
}
+ if (error)
+ goto corrupt_out;
/*
* First flush out the inode that xfs_iflush was called with.
@@ -3099,7 +3107,8 @@ xfs_iflush(
return 0;
corrupt_out:
- xfs_buf_relse(bp);
+ if (bp)
+ xfs_buf_relse(bp);
xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
cluster_corrupt_out:
error = XFS_ERROR(EFSCORRUPTED);
--
2.9.0
[PATCH 3.12 41/56] xen/events: Don't move disabled irqs
From: Ross Lagerwall
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.
Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.
The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: 88003d75ee00 ti: 88003d7bc000 task.ti: 88003d7bc000
RIP: 0010:[] []
irq_move_masked_irq+0xd2/0xe0
RSP: 0018:88003d7bfc50 EFLAGS: 00010046
RAX: RBX: 88003d40ba00 RCX: 0001
RDX: 0001 RSI: 0100 RDI: 88003d40bad8
RBP: 88003d7bfc68 R08: R09: 88003d00
R10: R11: 023c R12: 88003d40bad0
R13: 81f3a4a0 R14: 0010 R15:
FS: () GS:88003da0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fd4264de624 CR3: 37922000 CR4: 003406f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Stack:
88003d40ba38 0024 88003d7bfca0
814c8d92 0010813ef89d 805ea732 0009
0024 88003cc39b80 88003d7bfce0 814c8f66
Call Trace:
[] eoi_pirq+0xb2/0xf0
[] __startup_pirq+0xe6/0x150
[] xen_irq_resume+0x319/0x360
[] xen_suspend+0xb5/0x180
[] multi_cpu_stop+0xb5/0xe0
[] ? cpu_stop_queue_work+0x80/0x80
[] cpu_stopper_thread+0xb0/0x140
[] ? finish_task_switch+0x76/0x220
[] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
[] smpboot_thread_fn+0x105/0x160
[] ? sort_range+0x30/0x30
[] kthread+0xd8/0xf0
[] ? kthread_create_on_node+0x1e0/0x1e0
[] ret_from_fork+0x3f/0x70
[] ? kthread_create_on_node+0x1e0/0x1e0
Signed-off-by: Ross Lagerwall
Reviewed-by: Boris Ostrovsky
Signed-off-by: David Vrabel
Signed-off-by: Jiri Slaby
---
drivers/xen/events.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 3715a54117bb..19bd74cf0aba 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -576,7 +576,8 @@ static void eoi_pirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
- if (unlikely(irqd_is_setaffinity_pending(data))) {
+ if (unlikely(irqd_is_setaffinity_pending(data)) &&
+ likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
clear_evtchn(evtchn);
@@ -1616,7 +1617,8 @@ static void ack_dynirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
- if (unlikely(irqd_is_setaffinity_pending(data))) {
+ if (unlikely(irqd_is_setaffinity_pending(data)) &&
+ likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
clear_evtchn(evtchn);
--
2.9.0
[PATCH 3.12 56/56] Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data
From: Loic Poulain
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 84cb3df02aea4b00405521e67c4c67c2d525c364 upstream.
HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we
receive data from tty layer during this procedure, proto pointer may
not be assigned yet, leading to null pointer dereference in rx method
hci_uart_tty_receive.
This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in
order to avoid any proto operation before proto opening and assignment.
Signed-off-by: Loic Poulain
Signed-off-by: Marcel Holtmann
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/bluetooth/hci_ldisc.c | 11 +++
drivers/bluetooth/hci_uart.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index c4d2f0e48685..3f6074f7d4bc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -225,7 +225,7 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
- if (test_bit(HCI_UART_PROTO_SET, &hu->flags))
+ if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
hu->proto->flush(hu);
return 0;
@@ -340,7 +340,7 @@ static void hci_uart_tty_close(struct tty_struct *tty)
cancel_work_sync(&hu->write_work);
- if (test_and_clear_bit(HCI_UART_PROTO_SET, &hu->flags)) {
+ if (test_and_clear_bit(HCI_UART_PROTO_READY, &hu->flags)) {
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, &hu->flags))
hci_unregister_dev(hdev);
@@ -348,6 +348,7 @@ static void hci_uart_tty_close(struct tty_struct *tty)
}
hu->proto->close(hu);
}
+ clear_bit(HCI_UART_PROTO_SET, &hu->flags);
kfree(hu);
}
@@ -374,7 +375,7 @@ static void hci_uart_tty_wakeup(struct tty_struct *tty)
if (tty != hu->tty)
return;
- if (test_bit(HCI_UART_PROTO_SET, &hu->flags))
+ if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
hci_uart_tx_wakeup(hu);
}
@@ -397,7 +398,7 @@ static void hci_uart_tty_receive(struct tty_struct *tty,
const u8 *data, char *f
if (!hu || tty != hu->tty)
return;
- if (!test_bit(HCI_UART_PROTO_SET, &hu->flags))
+ if (!test_bit(HCI_UART_PROTO_READY, &hu->flags))
return;
spin_lock(&hu->rx_lock);
@@ -474,9 +475,11 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
hu->proto = p;
+ set_bit(HCI_UART_PROTO_READY, &hu->flags);
err = hci_uart_register_dev(hu);
if (err) {
+ clear_bit(HCI_UART_PROTO_READY, &hu->flags);
p->close(hu);
return err;
}
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 12df101ca942..51ecb664d961 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -81,6 +81,7 @@ struct hci_uart {
/* HCI_UART proto flag bits */
#define HCI_UART_PROTO_SET 0
#define HCI_UART_REGISTERED1
+#define HCI_UART_PROTO_READY 2
/* TX states */
#define HCI_UART_SENDING 1
--
2.9.0
Re: [PATCH] net: hns: update the dependency
Hi David, I'm really sorry for this. Because i didn't receive the first two emails, i resented it a few times. I will pay more attention next time. Thanks, Yisen 在 2016/6/15 14:24, David Miller 写道: > From: Yisen Zhuang > Date: Wed, 15 Jun 2016 14:03:33 +0800 > >> Hi David, >> >> You mean that i send this patch 3 times? >> >> I am sorry for this. >> >> I don't know why you can receive 3 times. I can only receive an email for >> this patch. > > I got three copies, each with a different Date: field. > > patchwork saw all 3 copies as well: > > http://patchwork.ozlabs.org/patch/634452/ > http://patchwork.ozlabs.org/patch/634559/ > http://patchwork.ozlabs.org/patch/634586/ > > . >
Re: [PATCH v2 2/9] kexec_file: Generalize kexec_add_buffer.
Hi, Thiago
On 06/14/16 at 11:59am, Thiago Jung Bauermann wrote:
> Allow architectures to specify different memory walking functions for
> kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> but PowerPC uses the memblock subsystem.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
> Cc: Dave Young
> Cc: ke...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> include/linux/kexec.h | 3 +++
> kernel/kexec_file.c | 44
> 2 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..7321043aa65a 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -315,6 +315,9 @@ int __weak arch_kexec_apply_relocations_add(const
> Elf_Ehdr *ehdr,
> Elf_Shdr *sechdrs, unsigned int relsec);
> int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr
> *sechdrs,
> unsigned int relsec);
> +int __weak arch_kexec_walk_mem(unsigned int image_type, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *));
> void arch_kexec_protect_crashkres(void);
> void arch_kexec_unprotect_crashkres(void);
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b6eec7527e9f..a3ca7cfe070e 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,31 @@ static int locate_mem_hole_callback(u64 start, u64 end,
> void *arg)
> return locate_mem_hole_bottom_up(start, end, kbuf);
> }
>
> +/**
> + * arch_kexec_walk_mem - call func(data) on free memory regions
> + * @image_type: kimage.type
> + * @start: Don't visit memory regions below this address.
> + * @end: Don't visit memory regions above this address.
> + * @top_down:Start from the highest address?
> + * @data:Argument to pass to @func.
> + * @func:Function to call for each memory region.
> + *
> + * Return: The memory walk will stop when func returns a non-zero value
> + * and that value will be returned. If all free regions are visited without
> + * func returning non-zero, then zero will be returned.
> + */
> +int __weak arch_kexec_walk_mem(unsigned int image_type, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *))
> +{
> + if (image_type == KEXEC_TYPE_CRASH)
> + return walk_iomem_res_desc(crashk_res.desc,
> +IORESOURCE_SYSTEM_RAM |
> IORESOURCE_BUSY,
> +start, end, data, func);
> + else
> + return walk_system_ram_res(start, end, data, func);
> +}
> +
> /*
> * Helper function for placing a buffer in a kexec segment. This assumes
> * that kexec_mutex is held.
> @@ -441,6 +466,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz,
> struct kexec_segment *ksegment;
> struct kexec_buf buf, *kbuf;
> int ret;
> + unsigned long start, end;
>
> /* Currently adding segment this way is allowed only in file mode */
> if (!image->file_mode)
> @@ -472,14 +498,16 @@ int kexec_add_buffer(struct kimage *image, char
> *buffer, unsigned long bufsz,
> kbuf->top_down = top_down;
>
> /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - if (image->type == KEXEC_TYPE_CRASH)
> - ret = walk_iomem_res_desc(crashk_res.desc,
> - IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> - crashk_res.start, crashk_res.end, kbuf,
> - locate_mem_hole_callback);
> - else
> - ret = walk_system_ram_res(0, -1, kbuf,
> - locate_mem_hole_callback);
> + if (image->type == KEXEC_TYPE_CRASH) {
> + start = crashk_res.start;
> + end = crashk_res.end;
> + } else {
> + start = 0;
> + end = ULONG_MAX;
> + }
For crashk_res, start and end is global, the non-crash values are
hard coded, thus it is not necessary to pass these two in arguments.
Moving above to arch_kexec_walk_mem will make it cleaner.
> +
> + ret = arch_kexec_walk_mem(image->type, start, end, top_down, kbuf,
> +locate_mem_hole_callback);
> if (ret != 1) {
> /* A suitable memory range could not be found for buffer */
> return -EADDRNOTAVAIL;
> --
> 1.9.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
[PATCH 3.12 55/56] Bluetooth: btmrvl_sdio: fix firmware activation failure
From: Wei-Ning Huang 3.12-stable review patch. If anyone has any objections, please let me know. === commit 9a01242dc7fc4d5fe3f722afbf35b33aa414cd2f upstream. In some case, the btmrvl_sdio firmware would fail to active within the polling time. Increase the polling interval to 100 msec to fix the issue. Signed-off-by: Wei-Ning Huang Signed-off-by: Wei-Ning Huang Signed-off-by: Marcel Holtmann Cc: Oliver Neukum Signed-off-by: Jiri Slaby --- drivers/bluetooth/btmrvl_sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c index 00da6df9f71e..65c5f256a5d5 100644 --- a/drivers/bluetooth/btmrvl_sdio.c +++ b/drivers/bluetooth/btmrvl_sdio.c @@ -269,7 +269,7 @@ static int btmrvl_sdio_verify_fw_download(struct btmrvl_sdio_card *card, if (firmwarestat == FIRMWARE_READY) return 0; - msleep(10); + msleep(100); } return -ETIMEDOUT; -- 2.9.0
[PATCH 3.12 51/56] xfs: skip stale inodes in xfs_iflush_cluster
From: Dave Chinner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.
We don't write back stale inodes so we should skip them in
xfs_iflush_cluster, too.
Signed-off-by: Dave Chinner
Reviewed-by: Brian Foster
Reviewed-by: Christoph Hellwig
Signed-off-by: Dave Chinner
Signed-off-by: Jiri Slaby
---
fs/xfs/xfs_inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 363bcd8eabf6..5d667f740eff 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2902,6 +2902,7 @@ xfs_iflush_cluster(
*/
spin_lock(&iq->i_flags_lock);
if (!iq->i_ino ||
+ __xfs_iflags_test(iq, XFS_ISTALE) ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
spin_unlock(&iq->i_flags_lock);
continue;
--
2.9.0
[PATCH 3.12 35/56] aacraid: Relinquish CPU during timeout wait
From: Raghava Aditya Renukunta
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 07beca2be24cc710461c0b131832524c9ee08910 upstream.
aac_fib_send has a special function case for initial commands during
driver initialization using wait < 0(pseudo sync mode). In this case,
the command does not sleep but rather spins checking for timeout.This
loop is calls cpu_relax() in an attempt to allow other processes/threads
to use the CPU, but this function does not relinquish the CPU and so the
command will hog the processor. This was observed in a KDUMP
"crashkernel" and that prevented the "command thread" (which is
responsible for completing the command from being timed out) from
starting because it could not get the CPU.
Fixed by replacing "cpu_relax()" call with "schedule()"
Signed-off-by: Raghava Aditya Renukunta
Reviewed-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
Signed-off-by: Jiri Slaby
---
drivers/scsi/aacraid/commsup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 6b32ddcefc11..06f73d2c878c 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -590,10 +590,10 @@ int aac_fib_send(u16 command, struct fib *fibptr,
unsigned long size,
}
return -EFAULT;
}
- /* We used to udelay() here but that absorbed
-* a CPU when a timeout occured. Not very
-* useful. */
- cpu_relax();
+ /*
+* Allow other processes / CPUS to use core
+*/
+ schedule();
}
} else if (down_interruptible(&fibptr->event_wait)) {
/* Do nothing ... satisfy
--
2.9.0
[PATCH 3.12 34/56] ath5k: Change led pin configuration for compaq c700 laptop
From: Joseph Salisbury
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.
BugLink: http://bugs.launchpad.net/bugs/972604
Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop") added a pin configuration for the Compaq
c700 laptop. However, the polarity of the led pin is reversed. It should be
red for wifi off and blue for wifi on, but it is the opposite. This bug was
reported in the following bug report:
http://pad.lv/972604
Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop")
Signed-off-by: Joseph Salisbury
Signed-off-by: Kalle Valo
Signed-off-by: Jiri Slaby
---
drivers/net/wireless/ath/ath5k/led.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath5k/led.c
b/drivers/net/wireless/ath/ath5k/led.c
index f77ef36acf87..61879b1f7083 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -77,7 +77,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath5k_led_devices) = {
/* HP Compaq CQ60-206US (ddregg...@jumptv.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },
/* HP Compaq C700 (nitrous...@gmail.com) */
- { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
+ { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },
/* LiteOn AR5BXB63 (mag...@salug.it) */
{ ATH_SDEVICE(PCI_VENDOR_ID_ATHEROS, 0x3067), ATH_LED(3, 0) },
/* IBM-specific AR5212 (all others) */
--
2.9.0
[PATCH 3.12 38/56] PCI: Disable all BAR sizing for devices with non-compliant BARs
From: Prarit Bhargava
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream.
b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant
BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
the PCI spec. But it didn't do anything for expansion ROM BARs, so we
still try to size them, resulting in warnings like this on Broadwell-EP:
pci :ff:12.0: BAR 6: failed to assign [mem size 0x0001 pref]
Move the non-compliant BAR check from __pci_read_base() up to
pci_read_bases() so it applies to the expansion ROM BAR as well as
to BARs 0-5.
Note that direct callers of __pci_read_base(), like sriov_init(), will now
bypass this check. We haven't had reports of devices with broken SR-IOV
BARs yet.
[bhelgaas: changelog]
Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with
non-compliant BARs")
Signed-off-by: Prarit Bhargava
Signed-off-by: Bjorn Helgaas
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: Andi Kleen
Signed-off-by: Jiri Slaby
---
drivers/pci/probe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 51379906c69c..53b23ff577b4 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -175,9 +175,6 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
struct pci_bus_region region, inverted_region;
bool bar_too_big = false, bar_disabled = false;
- if (dev->non_compliant_bars)
- return 0;
-
mask = type ? PCI_ROM_ADDRESS_MASK : ~0;
/* No printks while decoding is disabled! */
@@ -319,6 +316,9 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
int howmany, int rom)
{
unsigned int pos, reg;
+ if (dev->non_compliant_bars)
+ return;
+
for (pos = 0; pos < howmany; pos++) {
struct resource *res = &dev->resource[pos];
reg = PCI_BASE_ADDRESS_0 + (pos << 2);
--
2.9.0
[PATCH 3.12 45/56] ext4: fix hang when processing corrupted orphaned inode list
From: Theodore Ts'o 3.12-stable review patch. If anyone has any objections, please let me know. === commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream. If the orphaned inode list contains inode #5, ext4_iget() returns a bad inode (since the bootloader inode should never be referenced directly). Because of the bad inode, we end up processing the inode repeatedly and this hangs the machine. This can be reproduced via: mke2fs -t ext4 /tmp/foo.img 100 debugfs -w -R "ssv last_orphan 5" /tmp/foo.img mount -o loop /tmp/foo.img /mnt (But don't do this if you are using an unpatched kernel if you care about the system staying functional. :-) This bug was found by the port of American Fuzzy Lop into the kernel to find file system problems[1]. (Since it *only* happens if inode #5 shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not surprising that AFL needed two hours before it found it.) [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf Reported by: Vegard Nossum Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby --- fs/ext4/ialloc.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index fbc6df7b895d..f49349dfebcc 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -1097,11 +1097,13 @@ struct inode *ext4_orphan_get(struct super_block *sb, unsigned long ino) goto iget_failed; /* -* If the orphans has i_nlinks > 0 then it should be able to be -* truncated, otherwise it won't be removed from the orphan list -* during processing and an infinite loop will result. +* If the orphans has i_nlinks > 0 then it should be able to +* be truncated, otherwise it won't be removed from the orphan +* list during processing and an infinite loop will result. +* Similarly, it must not be a bad inode. */ - if (inode->i_nlink && !ext4_can_truncate(inode)) + if ((inode->i_nlink && !ext4_can_truncate(inode)) || + is_bad_inode(inode)) goto bad_orphan; if (NEXT_ORPHAN(inode) > max_ino) -- 2.9.0
[PATCH 3.12 39/56] rtlwifi: Fix logic error in enter/exit power-save mode
From: wang yanqing
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.
In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue"), the tests for enter/exit
power-save mode were inverted. With this change applied, the
wifi connection becomes much more stable.
Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to
use work queue")
Signed-off-by: Wang YanQing
Acked-by: Larry Finger
Signed-off-by: Kalle Valo
Signed-off-by: Jiri Slaby
---
drivers/net/wireless/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c
b/drivers/net/wireless/rtlwifi/base.c
index e99d8b1aa3bd..3fd83a87194f 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1402,9 +1402,9 @@ void rtl_watchdog_wq_callback(void *data)
if (((rtlpriv->link_info.num_rx_inperiod +
rtlpriv->link_info.num_tx_inperiod) > 8) ||
(rtlpriv->link_info.num_rx_inperiod > 2))
- rtlpriv->enter_ps = true;
- else
rtlpriv->enter_ps = false;
+ else
+ rtlpriv->enter_ps = true;
/* LeisurePS only work in infra mode. */
schedule_work(&rtlpriv->works.lps_change_work);
--
2.9.0
[PATCH 3.12 44/56] drm/fb_helper: Fix references to dev->mode_config.num_connector
From: Lyude
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.
During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:
- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
of dev->mode_config.num_connectors, and end up going out of bounds
since dev->mode_config.num_connectors is now larger then the array we
allocated.
fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.
Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.
Signed-off-by: Lyude
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cp...@redhat.com
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/drm_fb_helper.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 49557c957be8..1965b8963606 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1359,7 +1359,6 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
int n, int width, int height)
{
int c, o;
- struct drm_device *dev = fb_helper->dev;
struct drm_connector *connector;
struct drm_connector_helper_funcs *connector_funcs;
struct drm_encoder *encoder;
@@ -1380,7 +1379,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (modes[n] == NULL)
return best_score;
- crtcs = kzalloc(dev->mode_config.num_connector *
+ crtcs = kzalloc(fb_helper->connector_count *
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
if (!crtcs)
return best_score;
@@ -1427,7 +1426,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
best_crtc = crtc;
best_score = score;
memcpy(best_crtcs, crtcs,
- dev->mode_config.num_connector *
+ fb_helper->connector_count *
sizeof(struct drm_fb_helper_crtc *));
}
}
--
2.9.0
[PATCH 3.12 46/56] ext4: address UBSAN warning in mb_find_order_for_block()
From: Nicolai Stange
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream.
Currently, in mb_find_order_for_block(), there's a loop like the following:
while (order <= e4b->bd_blkbits + 1) {
...
bb += 1 << (e4b->bd_blkbits - order);
}
Note that the updated bb is used in the loop's next iteration only.
However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
shift exponent -1 is negative
[...]
Call Trace:
[] dump_stack+0xbc/0x117
[] ? _atomic_dec_and_lock+0x169/0x169
[] ubsan_epilogue+0xd/0x4e
[] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
[] ? __ubsan_handle_load_invalid_value+0x158/0x158
[] ? ext4_mb_generate_from_pa+0x590/0x590
[] ? ext4_read_block_bitmap_nowait+0x598/0xe80
[] mb_find_order_for_block+0x1ce/0x240
[...]
Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of bb is never used again.
Silence UBSAN by introducing another variable, bb_incr, holding the next
increment to apply to bb and adjust that one by right shifting it by one
position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
Signed-off-by: Nicolai Stange
Signed-off-by: Theodore Ts'o
Signed-off-by: Jiri Slaby
---
fs/ext4/mballoc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index c4a5e4df8ca3..4d42e50ab0a0 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1236,6 +1236,7 @@ static void ext4_mb_unload_buddy(struct ext4_buddy *e4b)
static int mb_find_order_for_block(struct ext4_buddy *e4b, int block)
{
int order = 1;
+ int bb_incr = 1 << (e4b->bd_blkbits - 1);
void *bb;
BUG_ON(e4b->bd_bitmap == e4b->bd_buddy);
@@ -1248,7 +1249,8 @@ static int mb_find_order_for_block(struct ext4_buddy
*e4b, int block)
/* this block is part of buddy of order 'order' */
return order;
}
- bb += 1 << (e4b->bd_blkbits - order);
+ bb += bb_incr;
+ bb_incr >>= 1;
order++;
}
return 0;
--
2.9.0
[PATCH 3.12 48/56] dma-debug: avoid spinlock recursion when disabling dma-debug
From: Ville Syrjälä
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream.
With netconsole (at least) the pr_err("... disablingn") call can
recurse back into the dma-debug code, where it'll try to grab
free_entries_lock again. Avoid the problem by doing the printk after
dropping the lock.
Link:
http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
lib/dma-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index eb43517bf261..c32437f6be61 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -445,9 +445,9 @@ static struct dma_debug_entry *dma_entry_alloc(void)
spin_lock_irqsave(&free_entries_lock, flags);
if (list_empty(&free_entries)) {
- pr_err("DMA-API: debugging out of memory - disabling\n");
global_disable = true;
spin_unlock_irqrestore(&free_entries_lock, flags);
+ pr_err("DMA-API: debugging out of memory - disabling\n");
return NULL;
}
--
2.9.0
Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
On 15 June 2016 at 14:49, Herbert Xu wrote: > On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: >> >> After some investigation, I still think we should divide the bulk >> request from dm-crypt into small request (each one is 512bytes) if >> this algorithm is not support bulk mode (like CBC). We have talked >> with dm-crypt >> maintainers why dm-crypt always use 512 bytes as one request size in >> below thread, could you please check it? >> http://www.kernelhub.org/?p=2&msg=907022 > > That link only points to an email about an oops. Ah, sorry. Would you check this thread? http://lkml.iu.edu/hypermail/linux/kernel/1601.1/03829.html > > Diggin through that thread, the only objection I have seen is about > the fact that you have to generate a fresh IV for each sector, which > is precisely what I'm suggesting that you do. > > IOW, implement the IV generators in the crypto API, and then you can > easily generate a new IV (if necessary) for each sector. > >> That means if we move the IV handling into crypto API, we still can >> not use bulk interface for all algorithm, for example we still need to >> read/write with 512 bytes for CBC, you can't use 4k or more block on >> CBC (and most other encryption modes). If only a part of 4k block is >> written (and then system crash happens), CBC would corrupt the block >> completely. It means if we map one whole bio with bulk interface in >> dm-crypt, we need to divide into every 512 bytes requests in crypto >> layer. So I don't think we can handle every algorithm with bulk >> interface just moving the IV handling into crypto API. Thanks. > > Of course you would do CBC in 512-byte blocks, but my point is that > you should do this in a crypto API algorithm, rather than dm-crypt > as we do now. Once you implement that then dm-crypt can treat > every algorithm as if they supported bulk processing. But that means we should divide the bulk request into 512-byte size requests and break up the mapped sg table for each request. Another hand we should allocate memory for each request in crypto layer, which dm-crypt have supplied one high efficiency way. I think these are really top level how to use the crypro APIs, does that need to move into crypto laryer? Thanks. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
[PATCH 3.12 31/56] MIPS: Fix siginfo.h to use strict posix types
From: James Hogan
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.
Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.
Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.
Signed-off-by: James Hogan
Cc: Christopher Ferris
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle
Signed-off-by: Jiri Slaby
---
arch/mips/include/uapi/asm/siginfo.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/mips/include/uapi/asm/siginfo.h
b/arch/mips/include/uapi/asm/siginfo.h
index 88e292b7719e..9997e4d48d70 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -46,13 +46,13 @@ typedef struct siginfo {
/* kill() */
struct {
- pid_t _pid; /* sender's pid */
+ __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid; /* sender's uid */
} _kill;
/* POSIX.1b timers */
struct {
- timer_t _tid; /* timer id */
+ __kernel_timer_t _tid; /* timer id */
int _overrun; /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval; /* same as below */
@@ -61,26 +61,26 @@ typedef struct siginfo {
/* POSIX.1b signals */
struct {
- pid_t _pid; /* sender's pid */
+ __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid; /* sender's uid */
sigval_t _sigval;
} _rt;
/* SIGCHLD */
struct {
- pid_t _pid; /* which child */
+ __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid; /* sender's uid */
int _status;/* exit code */
- clock_t _utime;
- clock_t _stime;
+ __kernel_clock_t _utime;
+ __kernel_clock_t _stime;
} _sigchld;
/* IRIX SIGCHLD */
struct {
- pid_t _pid; /* which child */
- clock_t _utime;
+ __kernel_pid_t _pid;/* which child */
+ __kernel_clock_t _utime;
int _status;/* exit code */
- clock_t _stime;
+ __kernel_clock_t _stime;
} _irix_sigchld;
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
--
2.9.0
[PATCH 3.12 32/56] MIPS: ath79: make bootconsole wait for both THRE and TEMT
From: Matthias Schiffer
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream.
This makes the ath79 bootconsole behave the same way as the generic 8250
bootconsole.
Also waiting for TEMT (transmit buffer is empty) instead of just THRE
(transmit buffer is not full) ensures that all characters have been
transmitted before the real serial driver starts reconfiguring the serial
controller (which would sometimes result in garbage being transmitted.)
This change does not cause a visible performance loss.
In addition, this seems to fix a hang observed in certain configurations on
many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
A more complete follow-up patch will disable 8250 autoconfig for ath79
altogether (the serial controller is detected as a 16550A, which is not
fully compatible with the ath79 serial, and the autoconfig may lead to
undefined behavior on ath79.)
Signed-off-by: Matthias Schiffer
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Jiri Slaby
---
arch/mips/ath79/early_printk.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/mips/ath79/early_printk.c b/arch/mips/ath79/early_printk.c
index b955fafc58ba..d1adc59af5bf 100644
--- a/arch/mips/ath79/early_printk.c
+++ b/arch/mips/ath79/early_printk.c
@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(void __iomem *reg, u32
mask, u32 val)
} while (1);
}
+#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
+
static void prom_putchar_ar71xx(unsigned char ch)
{
void __iomem *base = (void __iomem *)(KSEG1ADDR(AR71XX_UART_BASE));
- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
__raw_writel(ch, base + UART_TX * 4);
- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
}
static void prom_putchar_ar933x(unsigned char ch)
--
2.9.0
[PATCH] libata:fix kernel panic when hotplug
In normal condition,if we use sas protocol and hotplug a sata disk on a port,
the sas driver will send event "PORTE_BYTES_DMAED" and call function
"sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new sata disk,this
operation may cause
a kernel panic like this:
[ 2366.923208] Unable to handle kernel NULL pointer dereference at virtual
address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003,
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E)
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cryptd(E)
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E)
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC, BIOS 1.28
05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a task.ti:
ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : [] pstate:
0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)
This because "dev_to_shost" in "sas_find_dev_by_rphy" return a NULL point,and
SHOST_TO_SAS_HA used it,so kernel panic happed.
why dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,struct device *parent =
&shost->shost_gendev,and in "scsi_alloc_target", "*parent" is
assigned to "starget->dev.parent",then "sas_target_alloc" will get "struct
sas_rphy" according "starget->dev.parent",
and in "sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost" acording
"rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent is
"ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.
when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at the same time,the libata hotplug task will run and
panic will happen.
In fact,we don't need libata to deal with hotplug in sas enviroment.So we can't
run ata hotplug task when ata port is sas host.
Signed-off-by:Dingxiang
Signed-off-by:Chenqilin
---
drivers/ata/libata-eh.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 961acc7..74c5ecf 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,8 +816,11 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host,
struct ata_port *ap)
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
- else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
- schedule_delayed_work(&ap->hotplug_task, 0);
+ else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG){
+ if(ap->flags & ATA_FLAG_SAS_HOST)
+ ap->pflags &= ~ATA_PFLAG_SCSI_HOTPLUG;
+ else
+ schedule_delayed_work(&ap->hotplug_task, 0);
if (ap->pflags & ATA_PFLAG_RECOVERED)
ata_port_info(ap, "EH complete\n");
--
1.7.1
[PATCH 3.12 37/56] cpuidle: Indicate when a device has been unregistered
From: Dave Gerlach 3.12-stable review patch. If anyone has any objections, please let me know. === commit c998c07836f985b24361629dc98506ec7893e7a0 upstream. Currently the 'registered' member of the cpuidle_device struct is set to 1 during cpuidle_register_device. In this same function there are checks to see if the device is already registered to prevent duplicate calls to register the device, but this value is never set to 0 even on unregister of the device. Because of this, any attempt to call cpuidle_register_device after a call to cpuidle_unregister_device will fail which shouldn't be the case. To prevent this, set registered to 0 when the device is unregistered. Fixes: c878a52d3c7c (cpuidle: Check if device is already registered) Signed-off-by: Dave Gerlach Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby --- drivers/cpuidle/cpuidle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c index ef44248a5c37..8626c4761e4d 100644 --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -359,6 +359,8 @@ static void __cpuidle_unregister_device(struct cpuidle_device *dev) list_del(&dev->device_list); per_cpu(cpuidle_devices, dev->cpu) = NULL; module_put(drv->owner); + + dev->registered = 0; } static int __cpuidle_device_init(struct cpuidle_device *dev) -- 2.9.0
[PATCH 3.12 28/56] tty: vt, return error when con_startup fails
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 upstream.
When csw->con_startup() fails in do_register_con_driver, we return no
error (i.e. 0). This was changed back in 2006 by commit 3e795de763.
Before that we used to return -ENODEV.
So fix the return value to be -ENODEV in that case again.
Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT
console")
Signed-off-by: Jiri Slaby
Reported-by: "Dan Carpenter"
Signed-off-by: Jiri Slaby
---
drivers/tty/vt/vt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e341fd52a80d..19aba5091408 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3503,9 +3503,10 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
goto err;
desc = csw->con_startup();
-
- if (!desc)
+ if (!desc) {
+ retval = -ENODEV;
goto err;
+ }
retval = -EINVAL;
--
2.9.0
[PATCH 3.12 33/56] Input: uinput - handle compat ioctl for UI_SET_PHYS
From: Ricky Liang
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.
When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.
Signed-off-by: Ricky Liang
Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Slaby
---
drivers/input/misc/uinput.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index a0a4bbaef02c..3f2f3ac96a55 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -835,9 +835,15 @@ static long uinput_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
}
#ifdef CONFIG_COMPAT
+
+#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+
static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
+ if (cmd == UI_SET_PHYS_COMPAT)
+ cmd = UI_SET_PHYS;
+
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
}
#endif
--
2.9.0
[PATCH 3.12 36/56] aacraid: Fix for aac_command_thread hang
From: Raghava Aditya Renukunta 3.12-stable review patch. If anyone has any objections, please let me know. === commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 upstream. Typically under error conditions, it is possible for aac_command_thread() to miss the wakeup from kthread_stop() and go back to sleep, causing it to hang aac_shutdown. In the observed scenario, the adapter is not functioning correctly and so aac_fib_send() never completes (or time-outs depending on how it was called). Shortly after aac_command_thread() starts it performs aac_fib_send(SendHostTime) which hangs. When aac_probe_one /aac_get_adapter_info send time outs, kthread_stop is called which breaks the command thread out of it's hang. The code will still go back to sleep in schedule_timeout() without checking kthread_should_stop() so it causes aac_probe_one to hang until the schedule_timeout() which is 30 minutes. Fixed by: Adding another kthread_should_stop() before schedule_timeout() Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby --- drivers/scsi/aacraid/commsup.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c index 06f73d2c878c..ce177a50ec05 100644 --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -1921,6 +1921,10 @@ int aac_command_thread(void *data) if (difference <= 0) difference = 1; set_current_state(TASK_INTERRUPTIBLE); + + if (kthread_should_stop()) + break; + schedule_timeout(difference); if (kthread_should_stop()) -- 2.9.0
Re: [PATCH 4/4] coccicheck: add indexing enhancement options
On Wed, 15 Jun 2016, Luis R. Rodriguez wrote:
> On Tue, Jun 14, 2016 at 11:17:13PM +0200, Julia Lawall wrote:
> >
> >
> > On Tue, 14 Jun 2016, Luis R. Rodriguez wrote:
> >
> > > On Tue, Jun 14, 2016 at 10:47:32PM +0200, Julia Lawall wrote:
> > > >
> > > >
> > > > On Tue, 14 Jun 2016, Luis R. Rodriguez wrote:
> > > >
> > > > > On Tue, Jun 14, 2016 at 07:22:03AM +0200, Julia Lawall wrote:
> > > > > >
> > > > > >
> > > > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote:
> > > > > >
> > > > > > > On Mon, Jun 13, 2016 at 09:50:15PM +0200, Julia Lawall wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote:
> > > > > > > > >
> > > > > > > > > I'll redirect stderr to stdout by default when parmap support
> > > > > > > > > is used then.
> > > > > > > >
> > > > > > > > Usually I put them in different files.
> > > > > > >
> > > > > > > We can do that as well but I would only want to deal with parmap
> > > > > > > support
> > > > > > > case. Any preference? How about .coccicheck.stderr.$PID where PID
> > > > > > > would
> > > > > > > be the PID of the shell script?
> > > > > >
> > > > > > I don't understand the connection with parmap.
> > > > >
> > > > > When parmap support is not available the cocciscript will currently
> > > > > disregard stderr, output is provided as it comes to stdout from each
> > > > > thread I guess.
> > > >
> > > > Deepa's recent patch to coccicheck made apparent that Coccicheck uses
> > > > --very-quiet, so there is standard error.
> > >
> > > OK I'm disegarding the redirect for non-parmap for now but we'd have to
> > > determine if we want to append or add one per PID... I rather leave that
> > > stuff as-is and encourage folks to upgrade coccinelle.
> >
> > If coccicheck is using --very-quiet, there will not be much stderr of
> > interest when using parmap either.
>
> OK I don't follow. Does coccinelle only direct error to stderr when
> --very-quiet
> is used ? Or does using --very-quiet suppress stderr ?
--very-quiet suppresses most administrative messages that go to stderr.
There are still actual errors. Bu you don't see eg what file is being
currently processed.
> > > > > > Originally our use of parmap made output, specia files based on
> > > > > > pids. Maybe this
> > > > > > is the default for parmap. I found this completely unusable. I
> > > > > > guess one
> > > > > > could look at the dates to see which file is the most recent one,
> > > > > > but it
> > > > > > seems tedious. If you are putting the standard output in x.out,
> > > > > > then put
> > > > > > the standard error in x.err.
> > > > >
> > > > > I'll use ${DIR}/coccicheck.$$.err for stderr.
> > > >
> > > > What is ${DIR}? and what is $$?
> > >
> > > When you run scripts/coccicheck we take the absolute directory
> > > of it and then go down one level of directory, so in this case it
> > > would be the base directory of the Linux kernel.
> > >
> > > $$ is the PID of the bash script.
> >
> > OK. I still don't find PIDs useful, but I guess if we are talking about
> > the entire output of coccicheck, there is not much else to do. Normally,
> > I don't want these files accumulating, and just write over the old ones.
>
> Which is why I would much prefer to instead just redirect in coccicheck
> case stderr to stdout from coccinelle. Is that preferred?
Then things will be merged in strange ways.
Why not just let the user decide what to do with these things?
julia
[PATCH 3.12 25/56] USB: serial: io_edgeport: fix memory leaks in attach error path
From: Johan Hovold
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c5c0c55598cefc826d6cfb0a417eeaee3631715c upstream.
Private data, URBs and buffers allocated for Epic devices during
attach were never released on errors (e.g. missing endpoints).
Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/io_edgeport.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index c91481d74a14..60bff3b75609 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2879,14 +2879,15 @@ static int edge_startup(struct usb_serial *serial)
usb_alloc_urb(0, GFP_KERNEL);
if (!edge_serial->interrupt_read_urb) {
dev_err(ddev, "out of memory\n");
- return -ENOMEM;
+ response = -ENOMEM;
+ break;
}
edge_serial->interrupt_in_buffer =
kmalloc(buffer_size, GFP_KERNEL);
if (!edge_serial->interrupt_in_buffer) {
dev_err(ddev, "out of memory\n");
-
usb_free_urb(edge_serial->interrupt_read_urb);
- return -ENOMEM;
+ response = -ENOMEM;
+ break;
}
edge_serial->interrupt_in_endpoint =
endpoint->bEndpointAddress;
@@ -2916,14 +2917,15 @@ static int edge_startup(struct usb_serial *serial)
usb_alloc_urb(0, GFP_KERNEL);
if (!edge_serial->read_urb) {
dev_err(ddev, "out of memory\n");
- return -ENOMEM;
+ response = -ENOMEM;
+ break;
}
edge_serial->bulk_in_buffer =
kmalloc(buffer_size, GFP_KERNEL);
if (!edge_serial->bulk_in_buffer) {
dev_err(&dev->dev, "out of memory\n");
- usb_free_urb(edge_serial->read_urb);
- return -ENOMEM;
+ response = -ENOMEM;
+ break;
}
edge_serial->bulk_in_endpoint =
endpoint->bEndpointAddress;
@@ -2949,9 +2951,22 @@ static int edge_startup(struct usb_serial *serial)
}
}
- if (!interrupt_in_found || !bulk_in_found || !bulk_out_found) {
- dev_err(ddev, "Error - the proper endpoints were not
found!\n");
- return -ENODEV;
+ if (response || !interrupt_in_found || !bulk_in_found ||
+ !bulk_out_found) {
+ if (!response) {
+ dev_err(ddev, "expected endpoints not found\n");
+ response = -ENODEV;
+ }
+
+ usb_free_urb(edge_serial->interrupt_read_urb);
+ kfree(edge_serial->interrupt_in_buffer);
+
+ usb_free_urb(edge_serial->read_urb);
+ kfree(edge_serial->bulk_in_buffer);
+
+ kfree(edge_serial);
+
+ return response;
}
/* start interrupt read for this edgeport this interrupt will
--
2.9.0
[PATCH 3.12 09/56] HID: microsoft: Add ID for MS Wireless Comfort Keyboard
From: Slava Bacherikov
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f9a82c2054bcdebdf81a63c26a3b41197bb6070a upstream.
Microsoft Wireless Comfort Keyboard has vendor specific My Favorites
1-5 keys. Linux already supports this buttons on other MS keyboards by
MS_ERGONOMY quirk. So apply MS_ERGONOMY quirk to USB PID 0x00e3
(Microsoft Wireless Optical Desktop Receiver 3.0A). After this
My Favorites 1..5 keys will be reported as KEY_F14..KEY_F15 events.
Signed-off-by: Slava Bacherikov
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-microsoft.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b62ceaf1a11e..6ae4df439d06 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1803,6 +1803,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICOLCD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP,
USB_DEVICE_ID_PICOLCD_BOOTLOADER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_KEYBOARD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_NE4K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_NE4K_JP) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7ab974cafee8..6a6b06ef31b1 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -652,6 +652,7 @@
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1 0x0732
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_600 0x0750
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_45000x076c
+#define USB_DEVICE_ID_MS_COMFORT_KEYBOARD 0x00e3
#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 859ee53f630f..8dfc58ac9d52 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -272,6 +272,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
.driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
+ .driver_data = MS_ERGONOMY},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
2.9.0
[PATCH 3.12 27/56] USB: serial: option: add support for Cinterion PH8 and AHxx
From: Schemmel Hans-Christoph
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 444f94e9e625f6ec6bbe2cb232a6451c637f35a3 upstream.
Added support for Gemalto's Cinterion PH8 and AHxx products
with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
In addition some minor renaming and formatting.
Signed-off-by: Hans-Christoph Schemmel
[johan: sort current entries and trim trailing whitespace ]
Signed-off-by: Johan Hovold
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/option.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 99c89d7fa1ad..bcb6f5c2bae4 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -375,18 +375,22 @@ static void option_instat_callback(struct urb *urb);
#define HAIER_PRODUCT_CE81B0x10f8
#define HAIER_PRODUCT_CE1000x2009
-/* Cinterion (formerly Siemens) products */
-#define SIEMENS_VENDOR_ID 0x0681
-#define CINTERION_VENDOR_ID0x1e2d
+/* Gemalto's Cinterion products (formerly Siemens) */
+#define SIEMENS_VENDOR_ID 0x0681
+#define CINTERION_VENDOR_ID0x1e2d
+#define CINTERION_PRODUCT_HC25_MDMNET 0x0040
#define CINTERION_PRODUCT_HC25_MDM 0x0047
-#define CINTERION_PRODUCT_HC25_MDMNET 0x0040
+#define CINTERION_PRODUCT_HC28_MDMNET 0x004A /* same for HC28J */
#define CINTERION_PRODUCT_HC28_MDM 0x004C
-#define CINTERION_PRODUCT_HC28_MDMNET 0x004A /* same for HC28J */
#define CINTERION_PRODUCT_EU3_E0x0051
#define CINTERION_PRODUCT_EU3_P0x0052
#define CINTERION_PRODUCT_PH8 0x0053
#define CINTERION_PRODUCT_AHXX 0x0055
#define CINTERION_PRODUCT_PLXX 0x0060
+#define CINTERION_PRODUCT_PH8_2RMNET 0x0082
+#define CINTERION_PRODUCT_PH8_AUDIO0x0083
+#define CINTERION_PRODUCT_AHXX_2RMNET 0x0084
+#define CINTERION_PRODUCT_AHXX_AUDIO 0x0085
/* Olivetti products */
#define OLIVETTI_VENDOR_ID 0x0b3c
@@ -641,6 +645,10 @@ static const struct option_blacklist_info
telit_le922_blacklist_usbcfg3 = {
.reserved = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info cinterion_rmnet2_blacklist = {
+ .reserved = BIT(4) | BIT(5),
+};
+
static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1712,7 +1720,13 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
CINTERION_PRODUCT_AHXX, 0xff) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
- { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) },
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
CINTERION_PRODUCT_PH8_2RMNET, 0xff),
+ .driver_info = (kernel_ulong_t)&cinterion_rmnet2_blacklist },
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
CINTERION_PRODUCT_PH8_AUDIO, 0xff),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
CINTERION_PRODUCT_AHXX_2RMNET, 0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID,
CINTERION_PRODUCT_AHXX_AUDIO, 0xff) },
+ { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDMNET) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDM) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDMNET) },
--
2.9.0
Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote: > > But that means we should divide the bulk request into 512-byte size > requests and break up the mapped sg table for each request. Another > hand we should allocate memory for each request in crypto layer, which > dm-crypt have supplied one high efficiency way. I think these are > really top level how to use the crypro APIs, does that need to move > into crypto laryer? Thanks. I have already explained to you how you can piggy-back off dm-crypt's allocation, so what's the problem? -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH 3.12 26/56] USB: serial: io_edgeport: fix memory leaks in probe error path
From: Johan Hovold
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c8d62957d450cc1a22ce3242908709fe367ddc8e upstream.
URBs and buffers allocated in attach for Epic devices would never be
deallocated in case of a later probe error (e.g. failure to allocate
minor numbers) as disconnect is then never called.
Fix by moving deallocation to release and making sure that the
URBs are first unlinked.
Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/io_edgeport.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index 60bff3b75609..0d037cc40e51 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2989,16 +2989,9 @@ static void edge_disconnect(struct usb_serial *serial)
{
struct edgeport_serial *edge_serial = usb_get_serial_data(serial);
- /* stop reads and writes on all ports */
- /* free up our endpoint stuff */
if (edge_serial->is_epic) {
usb_kill_urb(edge_serial->interrupt_read_urb);
- usb_free_urb(edge_serial->interrupt_read_urb);
- kfree(edge_serial->interrupt_in_buffer);
-
usb_kill_urb(edge_serial->read_urb);
- usb_free_urb(edge_serial->read_urb);
- kfree(edge_serial->bulk_in_buffer);
}
}
@@ -3011,6 +3004,16 @@ static void edge_release(struct usb_serial *serial)
{
struct edgeport_serial *edge_serial = usb_get_serial_data(serial);
+ if (edge_serial->is_epic) {
+ usb_kill_urb(edge_serial->interrupt_read_urb);
+ usb_free_urb(edge_serial->interrupt_read_urb);
+ kfree(edge_serial->interrupt_in_buffer);
+
+ usb_kill_urb(edge_serial->read_urb);
+ usb_free_urb(edge_serial->read_urb);
+ kfree(edge_serial->bulk_in_buffer);
+ }
+
kfree(edge_serial);
}
--
2.9.0
[PATCH 3.12 16/56] fs/cifs: correctly to anonymous authentication via NTLMSSP
From: Stefan Metzmacher
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit cfda35d98298131bf38fbad3ce4cd5ecb3cf18db upstream.
See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client:
...
Set NullSession to FALSE
If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND
AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND
(AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1)
OR
AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0))
-- Special case: client requested anonymous authentication
Set NullSession to TRUE
...
Only server which map unknown users to guest will allow
access using a non-null NTChallengeResponse.
For Samba it's the "map to guest = bad user" option.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
Signed-off-by: Stefan Metzmacher
Signed-off-by: Steve French
Signed-off-by: Jiri Slaby
---
fs/cifs/sess.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index e87387dbf39f..bbb50be00ef5 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -399,19 +399,27 @@ int build_ntlmssp_auth_blob(unsigned char *pbuffer,
sec_blob->LmChallengeResponse.MaximumLength = 0;
sec_blob->NtChallengeResponse.BufferOffset = cpu_to_le32(tmp - pbuffer);
- rc = setup_ntlmv2_rsp(ses, nls_cp);
- if (rc) {
- cifs_dbg(VFS, "Error %d during NTLMSSP authentication\n", rc);
- goto setup_ntlmv2_ret;
- }
- memcpy(tmp, ses->auth_key.response + CIFS_SESS_KEY_SIZE,
- ses->auth_key.len - CIFS_SESS_KEY_SIZE);
- tmp += ses->auth_key.len - CIFS_SESS_KEY_SIZE;
+ if (ses->user_name != NULL) {
+ rc = setup_ntlmv2_rsp(ses, nls_cp);
+ if (rc) {
+ cifs_dbg(VFS, "Error %d during NTLMSSP
authentication\n", rc);
+ goto setup_ntlmv2_ret;
+ }
+ memcpy(tmp, ses->auth_key.response + CIFS_SESS_KEY_SIZE,
+ ses->auth_key.len - CIFS_SESS_KEY_SIZE);
+ tmp += ses->auth_key.len - CIFS_SESS_KEY_SIZE;
- sec_blob->NtChallengeResponse.Length =
- cpu_to_le16(ses->auth_key.len - CIFS_SESS_KEY_SIZE);
- sec_blob->NtChallengeResponse.MaximumLength =
- cpu_to_le16(ses->auth_key.len - CIFS_SESS_KEY_SIZE);
+ sec_blob->NtChallengeResponse.Length =
+ cpu_to_le16(ses->auth_key.len -
CIFS_SESS_KEY_SIZE);
+ sec_blob->NtChallengeResponse.MaximumLength =
+ cpu_to_le16(ses->auth_key.len -
CIFS_SESS_KEY_SIZE);
+ } else {
+ /*
+* don't send an NT Response for anonymous access
+*/
+ sec_blob->NtChallengeResponse.Length = 0;
+ sec_blob->NtChallengeResponse.MaximumLength = 0;
+ }
if (ses->domainName == NULL) {
sec_blob->DomainName.BufferOffset = cpu_to_le32(tmp - pbuffer);
--
2.9.0
[PATCH 3.12 29/56] serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()
From: Chanwoo Choi
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream.
This patch fixes the broken serial log when changing the clock source
of uart device. Before disabling the original clock source, this patch
enables the new clock source to protect the clock off state for a split second.
Signed-off-by: Chanwoo Choi
Reviewed-by: Marek Szyprowski
Signed-off-by: Greg Kroah-Hartman
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Jiri Slaby
---
drivers/tty/serial/samsung.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 6b0adfbfacaf..663508b760d8 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -727,6 +727,8 @@ static void s3c24xx_serial_set_termios(struct uart_port
*port,
/* check to see if we need to change clock source */
if (ourport->baudclk != clk) {
+ clk_prepare_enable(clk);
+
s3c24xx_serial_setsource(port, clk_sel);
if (!IS_ERR(ourport->baudclk)) {
@@ -734,8 +736,6 @@ static void s3c24xx_serial_set_termios(struct uart_port
*port,
ourport->baudclk = ERR_PTR(-EINVAL);
}
- clk_prepare_enable(clk);
-
ourport->baudclk = clk;
ourport->baudclk_rate = clk ? clk_get_rate(clk) : 0;
}
--
2.9.0
[PATCH 3.12 21/56] mmc: longer timeout for long read time quirk
From: Matt Gumbel
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 32ecd320db39bcb007679ed42f283740641b81ea upstream.
008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.
This patch will...
() Increase the long read time quirk timeout from 300ms to 600ms. Original
author of that quirk says 300ms was only a guess and that the number
may need to be raised in the future.
() Add this specific MMC to the quirk
Signed-off-by: Matt Gumbel
Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Jiri Slaby
---
drivers/mmc/card/block.c | 5 +++--
drivers/mmc/core/core.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 30076b4f3fee..ee76ff2af935 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2352,11 +2352,12 @@ static const struct mmc_fixup blk_fixups[] =
MMC_QUIRK_BLK_NO_CMD23),
/*
-* Some Micron MMC cards needs longer data read timeout than
-* indicated in CSD.
+* Some MMC cards need longer data read timeout than indicated in CSD.
*/
MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
MMC_QUIRK_LONG_READ_TIME),
+ MMC_FIXUP("008GE0", CID_MANFID_TOSHIBA, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_LONG_READ_TIME),
/*
* On these Samsung MoviNAND parts, performing secure erase or
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 4b12543b0826..3513a5a91c2a 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -821,11 +821,11 @@ void mmc_set_data_timeout(struct mmc_data *data, const
struct mmc_card *card)
/*
* Some cards require longer data read timeout than indicated in CSD.
* Address this by setting the read timeout to a "reasonably high"
-* value. For the cards tested, 300ms has proven enough. If necessary,
+* value. For the cards tested, 600ms has proven enough. If necessary,
* this value can be increased if other problematic cards require this.
*/
if (mmc_card_long_read_time(card) && data->flags & MMC_DATA_READ) {
- data->timeout_ns = 3;
+ data->timeout_ns = 6;
data->timeout_clks = 0;
}
--
2.9.0
[PATCH 3.12 17/56] ring-buffer: Use long for nr_pages to avoid overflow failures
From: "Steven Rostedt (Red Hat)"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 9b94a8fba501f38368aef6ac1b30e7335252a220 upstream.
The size variable to change the ring buffer in ftrace is a long. The
nr_pages used to update the ring buffer based on the size is int. On 64 bit
machines this can cause an overflow problem.
For example, the following will cause the ring buffer to crash:
# cd /sys/kernel/debug/tracing
# echo 10 > buffer_size_kb
# echo 8556384240 > buffer_size_kb
Then you get the warning of:
WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527
rb_update_pages+0x22f/0x260
Which is:
RB_WARN_ON(cpu_buffer, nr_removed);
Note each ring buffer page holds 4080 bytes.
This is because:
1) 10 causes the ring buffer to have 3 pages.
(10kb requires 3 * 4080 pages to hold)
2) (2^31 / 2^10 + 1) * 4080 = 8556384240
The value written into buffer_size_kb is shifted by 10 and then passed
to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760
3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE
which is 4080. 8761737461760 / 4080 = 2147484672
4) nr_pages is subtracted from the current nr_pages (3) and we get:
2147484669. This value is saved in a signed integer nr_pages_to_update
5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int
turns into the value of -2147482627
6) As the value is a negative number, in update_pages_handler() it is
negated and passed to rb_remove_pages() and 2147482627 pages will
be removed, which is much larger than 3 and it causes the warning
because not all the pages asked to be removed were removed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001
Fixes: 7a8e76a3829f1 ("tracing: unified trace buffer")
Reported-by: Hao Qin
Signed-off-by: Steven Rostedt
Signed-off-by: Jiri Slaby
---
kernel/trace/ring_buffer.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 321ee4205160..4940115bbf8d 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -463,7 +463,7 @@ struct ring_buffer_per_cpu {
raw_spinlock_t reader_lock;/* serialize readers */
arch_spinlock_t lock;
struct lock_class_key lock_key;
- unsigned intnr_pages;
+ unsigned long nr_pages;
struct list_head*pages;
struct buffer_page *head_page; /* read from head */
struct buffer_page *tail_page; /* write to tail */
@@ -483,7 +483,7 @@ struct ring_buffer_per_cpu {
u64 write_stamp;
u64 read_stamp;
/* ring buffer pages to update, > 0 to add, < 0 to remove */
- int nr_pages_to_update;
+ longnr_pages_to_update;
struct list_headnew_pages; /* new pages to add */
struct work_struct update_pages_work;
struct completion update_done;
@@ -1120,10 +1120,10 @@ static int rb_check_pages(struct ring_buffer_per_cpu
*cpu_buffer)
return 0;
}
-static int __rb_allocate_pages(int nr_pages, struct list_head *pages, int cpu)
+static int __rb_allocate_pages(long nr_pages, struct list_head *pages, int cpu)
{
- int i;
struct buffer_page *bpage, *tmp;
+ long i;
for (i = 0; i < nr_pages; i++) {
struct page *page;
@@ -1160,7 +1160,7 @@ free_pages:
}
static int rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
-unsigned nr_pages)
+unsigned long nr_pages)
{
LIST_HEAD(pages);
@@ -1185,7 +1185,7 @@ static int rb_allocate_pages(struct ring_buffer_per_cpu
*cpu_buffer,
}
static struct ring_buffer_per_cpu *
-rb_allocate_cpu_buffer(struct ring_buffer *buffer, int nr_pages, int cpu)
+rb_allocate_cpu_buffer(struct ring_buffer *buffer, long nr_pages, int cpu)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct buffer_page *bpage;
@@ -1284,8 +1284,9 @@ struct ring_buffer *__ring_buffer_alloc(unsigned long
size, unsigned flags,
struct lock_class_key *key)
{
struct ring_buffer *buffer;
+ long nr_pages;
int bsize;
- int cpu, nr_pages;
+ int cpu;
/* keep it in its own cache line */
buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()),
@@ -1408,12 +1409,12 @@ static inline unsigned long rb_page_write(struct
buffer_page *bpage)
}
static int
-rb_remove_pages(struct ring_buffer_per_cpu *cpu_buffer, unsigned int nr_pages)
+rb_remove_pages(struct ring_buffer_per_cpu *cpu_buffer, unsigned long nr_pages)
{
struct list_head
[PATCH 3.12 24/56] USB: serial: quatech2: fix use-after-free in probe error path
From: Johan Hovold
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 028c49f5e02a257c94129cd815f7c8485f51d4ef upstream.
The interface read URB is submitted in attach, but was only unlinked by
the driver at disconnect.
In case of a late probe error (e.g. due to failed minor allocation),
disconnect is never called and we would end up with active URBs for an
unbound interface. This in turn could lead to deallocated memory being
dereferenced in the completion callback.
Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/quatech2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index a24d59ae4032..58ab9e52a938 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -142,6 +142,7 @@ static void qt2_release(struct usb_serial *serial)
serial_priv = usb_get_serial_data(serial);
+ usb_kill_urb(serial_priv->read_urb);
usb_free_urb(serial_priv->read_urb);
kfree(serial_priv->read_buffer);
kfree(serial_priv);
--
2.9.0
[PATCH 3.12 22/56] [media] usbvision: revert commit 588afcc1
From: Vladis Dronov
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit d5468d7afaa9c9e961e150f0455a14a9f4872a98 upstream.
Commit 588afcc1c0e4 ("[media] usbvision fix overflow of interfaces
array")' should be reverted, because:
* "!dev->actconfig->interface[ifnum]" won't catch a case where the value
is not NULL but some garbage. This way the system may crash later with
GPF.
* "(ifnum >= USB_MAXINTERFACES)" does not cover all the error
conditions. "ifnum" should be compared to "dev->actconfig->
desc.bNumInterfaces", i.e. compared to the number of "struct
usb_interface" kzalloc()-ed, not to USB_MAXINTERFACES.
* There is a "struct usb_device" leak in this error path, as there is
usb_get_dev(), but no usb_put_dev() on this path.
* There is a bug of the same type several lines below with number of
endpoints. The code is accessing hard-coded second endpoint
("interface->endpoint[1].desc") which may not exist. It would be great
to handle this in the same patch too.
* All the concerns above are resolved by already-accepted commit fa52bd50
("[media] usbvision: fix crash on detecting device with invalid
configuration")
* Mailing list message:
http://www.spinics.net/lists/linux-media/msg94832.html
Signed-off-by: Vladis Dronov
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jiri Slaby
---
drivers/media/usb/usbvision/usbvision-video.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/usb/usbvision/usbvision-video.c
b/drivers/media/usb/usbvision/usbvision-video.c
index d4a222ea8197..bd8f4151884b 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1539,13 +1539,6 @@ static int usbvision_probe(struct usb_interface *intf,
printk(KERN_INFO "%s: %s found\n", __func__,
usbvision_device_data[model].model_string);
- /*
-* this is a security check.
-* an exploit using an incorrect bInterfaceNumber is known
-*/
- if (ifnum >= USB_MAXINTERFACES || !dev->actconfig->interface[ifnum])
- return -ENODEV;
-
if (usbvision_device_data[model].interface >= 0)
interface =
&dev->actconfig->interface[usbvision_device_data[model].interface]->altsetting[0];
else if (ifnum < dev->actconfig->desc.bNumInterfaces)
--
2.9.0
[PATCH 3.12 20/56] ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings
From: Lv Zheng
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 upstream.
The order of the _OSI related functionalities is as follows:
acpi_blacklisted()
acpi_dmi_osi_linux()
acpi_osi_setup()
acpi_osi_setup()
acpi_update_interfaces() if "!*"
parse_args()
__setup("acpi_osi=")
acpi_osi_setup_linux()
acpi_update_interfaces() if "!*"
acpi_early_init()
acpi_initialize_subsystem()
acpi_ut_initialize_interfaces()
^^^
acpi_bus_init()
acpi_os_initialize1()
acpi_install_interface_handler(acpi_osi_handler)
acpi_osi_setup_late()
acpi_update_interfaces() for "!"
acpi_osi_handler()
Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
line setting can override the DMI detection. That's why acpi_blacklisted()
is put before __setup("acpi_osi=").
Then we can notice the following wrong invocation order. There are
acpi_update_interfaces() (marked by ) calls invoked before
acpi_ut_initialize_interfaces() (marked by ). This makes it impossible
to use acpi_osi=!* correctly from OSI DMI table or from the command line.
The use of acpi_osi=!* is meant to disable both ACPICA
(acpi_gbl_supported_interfaces) and Linux specific strings
(osi_setup_entries) while the ACPICA part should have stopped working
because of the order issue.
This patch fixes this issue by moving acpi_update_interfaces() to where
it is invoked for acpi_osi=! (marked by ) as this is ensured to be
invoked after acpi_ut_initialize_interfaces() (marked by ). Linux
specific strings are still handled in the original place in order to make
the following command line working: acpi_osi=!* acpi_osi="Module Device".
Note that since acpi_osi=!* is meant to further disable linux specific
string comparing to the acpi_osi=!, there is no such use case in our bug
fixing work and hence there is no one using acpi_osi=!* either from the
command line or from the DMI quirks, this issue is just a theoretical
issue.
Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings)
Tested-by: Lukas Wunner
Tested-by: Chen Yu
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jiri Slaby
---
drivers/acpi/osl.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 91f850585960..72eb7aaf9e8b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -143,7 +143,7 @@ static struct osi_linux {
unsigned intenable:1;
unsigned intdmi:1;
unsigned intcmdline:1;
- unsigned intdefault_disabling:1;
+ u8 default_disabling;
} osi_linux = {0, 0, 0, 0};
static u32 acpi_osi_handler(acpi_string interface, u32 supported)
@@ -1382,10 +1382,13 @@ void __init acpi_osi_setup(char *str)
if (*str == '!') {
str++;
if (*str == '\0') {
- osi_linux.default_disabling = 1;
+ /* Do not override acpi_osi=!* */
+ if (!osi_linux.default_disabling)
+ osi_linux.default_disabling =
+ ACPI_DISABLE_ALL_VENDOR_STRINGS;
return;
} else if (*str == '*') {
- acpi_update_interfaces(ACPI_DISABLE_ALL_STRINGS);
+ osi_linux.default_disabling = ACPI_DISABLE_ALL_STRINGS;
for (i = 0; i < OSI_STRING_ENTRIES_MAX; i++) {
osi = &osi_setup_entries[i];
osi->enable = false;
@@ -1458,10 +1461,13 @@ static void __init acpi_osi_setup_late(void)
acpi_status status;
if (osi_linux.default_disabling) {
- status =
acpi_update_interfaces(ACPI_DISABLE_ALL_VENDOR_STRINGS);
+ status = acpi_update_interfaces(osi_linux.default_disabling);
if (ACPI_SUCCESS(status))
- printk(KERN_INFO PREFIX "Disabled all _OSI OS
vendors\n");
+ printk(KERN_INFO PREFIX "Disabled all _OSI OS
vendors%s\n",
+ osi_linux.default_disabling ==
+ ACPI_DISABLE_ALL_STRINGS ?
+ " and feature groups" : "");
}
for (i = 0; i < OSI_STRING_ENTRIES_MAX; i++) {
--
2.9.0
[PATCH 3.12 06/56] HID: microsoft: Add Surface 3 type cover
From: Stephen Just
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 0439de75d32c249bd9f5824ffd5e40c4c2109d77 upstream.
Adding support for the Microsoft Surface 3 (non-pro) Type Cover.
The existing definitions and quirks are actually for the Surface
Pro 3 type covers. I've renamed the old constants to reflect that
they belong to the Surface Pro 3, and added a new constant and
matching code for the Surface 3.
Signed-off-by: Stephen Just
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 8 +---
drivers/hid/hid-ids.h | 8 ++--
drivers/hid/hid-microsoft.c | 6 --
drivers/hid/usbhid/hid-quirks.c | 3 ++-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9d24332e1e27..c8c98f1f22d6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -704,8 +704,9 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
hid->group = HID_GROUP_SENSOR_HUB;
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
- (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3_JP ||
+ (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
hid->group == HID_GROUP_MULTITOUCH)
hid->group = HID_GROUP_GENERIC;
@@ -1810,8 +1811,9 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 64f8fd16e9d7..b33fadc32100 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -649,8 +649,12 @@
#define USB_DEVICE_ID_MS_NE7K 0x071d
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_45000x076c
-#define USB_DEVICE_ID_MS_TYPE_COVER_30x07dc
-#define USB_DEVICE_ID_MS_TYPE_COVER_3_JP 0x07dd
+#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
+#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
+#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+#define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
#define USB_VENDOR_ID_MOJO 0x8282
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 755c62d73896..3afea9a98637 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -256,9 +256,11 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3),
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3),
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
.driver_data = MS_HIDINPUT },
- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP),
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3),
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
.driver_data = MS_HIDINPUT },
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 3b3fcbd28320..825d052cd2cb 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -87,8 +87,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE,
[PATCH 3.12 23/56] USB: serial: keyspan: fix use-after-free in probe error path
From: Johan Hovold
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 upstream.
The interface instat and indat URBs were submitted in attach, but never
unlinked in release before deallocating the corresponding transfer
buffers.
In the case of a late probe error (e.g. due to failed minor allocation),
disconnect would not have been called before release, causing the
buffers to be freed while the URBs are still in use. We'd also end up
with active URBs for an unbound interface.
Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/keyspan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index e58e21b46ef0..5419ccc72428 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -2411,6 +2411,10 @@ static void keyspan_release(struct usb_serial *serial)
s_priv = usb_get_serial_data(serial);
+ /* Make sure to unlink the URBs submitted in attach. */
+ usb_kill_urb(s_priv->instat_urb);
+ usb_kill_urb(s_priv->indat_urb);
+
usb_free_urb(s_priv->instat_urb);
usb_free_urb(s_priv->indat_urb);
usb_free_urb(s_priv->glocont_urb);
--
2.9.0
[PATCH 3.12 07/56] HID: microsoft: add support for 3 more devices
From: Alistair Leslie-Hughes
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c847a89a871e1ea21d45120c3045c9b443e258f5 upstream.
Adds support for the Micrsift Digital 4K, Media 600 and Media 3000 V1 Keyboards,
which have the same quirks as the already existing hardware MS_NE4K.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=52841
[jkos...@suse.cz: rephrase changelog]
Signed-off-by: Alistair Leslie-Hughes
Signed-off-by: Jiri Kosina
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-microsoft.c | 6 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c8c98f1f22d6..bde7e255a6b0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1814,6 +1814,9 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b33fadc32100..d974db4e36de 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -641,6 +641,7 @@
#define USB_DEVICE_ID_SIDEWINDER_GV0x003b
#define USB_DEVICE_ID_MS_OFFICE_KB 0x0048
#define USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0 0x009d
+#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K 0x00b4
#define USB_DEVICE_ID_MS_NE4K 0x00db
#define USB_DEVICE_ID_MS_NE4K_JP 0x00dc
#define USB_DEVICE_ID_MS_LK6K 0x00f9
@@ -648,6 +649,8 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_NE7K 0x071d
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
+#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1 0x0732
+#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_600 0x0750
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_45000x076c
#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 3afea9a98637..2f9d260539c9 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -252,6 +252,12 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_PRESENTER },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K),
.driver_data = MS_ERGONOMY | MS_RDESC_3K },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K),
+ .driver_data = MS_ERGONOMY },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_600),
+ .driver_data = MS_ERGONOMY },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1),
+ .driver_data = MS_ERGONOMY },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0),
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
--
2.9.0
[PATCH 3.12 19/56] mmc: mmc: Fix partition switch timeout for some eMMCs
From: Adrian Hunter 3.12-stable review patch. If anyone has any objections, please let me know. === commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 upstream. Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby --- drivers/mmc/core/mmc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 36d6701de972..21fdf157d8f7 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -266,6 +266,9 @@ static void mmc_select_card_type(struct mmc_card *card) card->ext_csd.card_type = card_type; } +/* Minimum partition switch timeout in milliseconds */ +#define MMC_MIN_PART_SWITCH_TIME 300 + /* * Decode extended CSD. */ @@ -329,6 +332,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) /* EXT_CSD value is in units of 10ms, but we store in ms */ card->ext_csd.part_time = 10 * ext_csd[EXT_CSD_PART_SWITCH_TIME]; + /* Some eMMC set the value too low so set a minimum */ + if (card->ext_csd.part_time && + card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) + card->ext_csd.part_time = MMC_MIN_PART_SWITCH_TIME; /* Sleep / awake timeout in 100ns units */ if (sa_shift > 0 && sa_shift <= 0x17) -- 2.9.0
[PATCH 3.12 14/56] ARC: use ASL assembler mnemonic
From: Vineet Gupta 3.12-stable review patch. If anyone has any objections, please let me know. === commit a6416f57ce57fb390b6ee30b12c01c29032a26af upstream. ARCompact and ARCv2 only have ASL, while binutils used to support LSL as a alias mnemonic. Newer binutils (upstream) don't want to do that so replace it. Signed-off-by: Vineet Gupta Signed-off-by: Jiri Slaby --- arch/arc/mm/tlbex.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arc/mm/tlbex.S b/arch/arc/mm/tlbex.S index cf7d7d9ad695..98837a2bfd5e 100644 --- a/arch/arc/mm/tlbex.S +++ b/arch/arc/mm/tlbex.S @@ -89,7 +89,7 @@ ex_saved_reg1: #ifdef CONFIG_SMP sr r0, [ARC_REG_SCRATCH_DATA0] ; freeup r0 to code with GET_CPU_ID r0 ; get to per cpu scratch mem, - lsl r0, r0, L1_CACHE_SHIFT ; cache line wide per cpu + asl r0, r0, L1_CACHE_SHIFT ; cache line wide per cpu add r0, @ex_saved_reg1, r0 #else str0, [@ex_saved_reg1] @@ -108,7 +108,7 @@ ex_saved_reg1: .macro TLBMISS_RESTORE_REGS #ifdef CONFIG_SMP GET_CPU_ID r0 ; get to per cpu scratch mem - lsl r0, r0, L1_CACHE_SHIFT ; each is cache line wide + asl r0, r0, L1_CACHE_SHIFT ; each is cache line wide add r0, @ex_saved_reg1, r0 ld_s r3, [r0,12] ld_s r2, [r0, 8] @@ -220,7 +220,7 @@ ex_saved_reg1: .macro CONV_PTE_TO_TLB andr3, r0, PTE_BITS_RWX ; r w x - lslr2, r3, 3; r w x 0 0 0 + aslr2, r3, 3; Kr Kw Kx 0 0 0 (GLOBAL, kernel only) and.f 0, r0, _PAGE_GLOBAL or.z r2, r2, r3 ; r w x r w x -- 2.9.0
[PATCH 3.12 13/56] HID: usbhid: enable NO_INIT_REPORTS quirk for Semico USB Keykoard2
From: Daniel Bristot de Oliveira
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c14022bfd2eb2d2ece74a405dfbdb02a829c07bc upstream.
The device which identifies itself as a "USB Keykoard" (no typo)
with VID:PID 1a2c:0027 does not seem to be handling the reports
initialization very well.
This results in a "usb_submit_urb(ctrl) failed: -1" message from the
kernel when connected, and a delay before its initialization. It can
also cause the hang the system.
This patch adds the quirk for this device, which causes the delay
to disappear. It is named as "USB Keykoard2" because the "USB Keykoard"
already exists.
Signed-off-by: Daniel Bristot de Oliveira
Signed-off-by: Jiri Kosina
Cc: Oliver Neukum
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 555dc61d2eb3..8a33a5967917 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -802,6 +802,7 @@
#define USB_VENDOR_ID_SEMICO 0x1a2c
#define USB_DEVICE_ID_SEMICO_USB_KEYKOARD 0x0023
+#define USB_DEVICE_ID_SEMICO_USB_KEYKOARD2 0x0027
#define USB_VENDOR_ID_SENNHEISER 0x1395
#define USB_DEVICE_ID_SENNHEISER_BTD500USB 0x002c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 33a08738dba9..d63f7e45b539 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -141,6 +141,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_M912,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS1,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_HD,
HID_QUIRK_NO_INIT_REPORTS },
--
2.9.0
[PATCH 3.12 18/56] ring-buffer: Prevent overflow of size in ring_buffer_resize()
From: "Steven Rostedt (Red Hat)"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 59643d1535eb220668692a5359de22545af579f6 upstream.
If the size passed to ring_buffer_resize() is greater than MAX_LONG -
BUF_PAGE_SIZE
then the DIV_ROUND_UP() will return zero.
Here's the details:
# echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb
tracing_entries_write() processes this and converts kb to bytes.
18014398509481980 << 10 = 18446744073709547520
and this is passed to ring_buffer_resize() as unsigned long size.
size = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
Where DIV_ROUND_UP(a, b) is (a + b - 1)/b
BUF_PAGE_SIZE is 4080 and here
18446744073709547520 + 4080 - 1 = 18446744073709551599
where 18446744073709551599 is still smaller than 2^64
2^64 - 18446744073709551599 = 17
But now 18446744073709551599 / 4080 = 4521260802379792
and size = size * 4080 = 18446744073709551360
This is checked to make sure its still greater than 2 * 4080,
which it is.
Then we convert to the number of buffer pages needed.
nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE)
but this time size is 18446744073709551360 and
2^64 - (18446744073709551360 + 4080 - 1) = -3823
Thus it overflows and the resulting number is less than 4080, which makes
3823 / 4080 = 0
an nr_pages is set to this. As we already checked against the minimum that
nr_pages may be, this causes the logic to fail as well, and we crash the
kernel.
There's no reason to have the two DIV_ROUND_UP() (that's just result of
historical code changes), clean up the code and fix this bug.
Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")
Signed-off-by: Steven Rostedt
Signed-off-by: Jiri Slaby
---
kernel/trace/ring_buffer.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 4940115bbf8d..f100767c8e0b 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1645,14 +1645,13 @@ int ring_buffer_resize(struct ring_buffer *buffer,
unsigned long size,
!cpumask_test_cpu(cpu_id, buffer->cpumask))
return size;
- size = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
- size *= BUF_PAGE_SIZE;
+ nr_pages = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
/* we need a minimum of two pages */
- if (size < BUF_PAGE_SIZE * 2)
- size = BUF_PAGE_SIZE * 2;
+ if (nr_pages < 2)
+ nr_pages = 2;
- nr_pages = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
+ size = nr_pages * BUF_PAGE_SIZE;
/*
* Don't succeed if resizing is disabled, as a reader might be
--
2.9.0
[PATCH 3.12 11/56] HID: sjoy: support Super Joy Box 4
From: Sean Young
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 6e5e9a06a206010eabd19b523fd0833c51afc0b0 upstream.
This device supports force feedback and has two ports.
Signed-off-by: Sean Young
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-sjoy.c | 3 +++
drivers/hid/usbhid/hid-quirks.c | 1 -
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 05867d1d8cdc..178651fe449b 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1909,6 +1909,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP_LTD,
USB_DEVICE_ID_SUPER_JOY_BOX_5_PRO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_WACOM,
USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_WACOM,
USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PLAYDOTCOM,
USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP,
USB_DEVICE_ID_WALTOP_SLIM_TABLET_5_8_INCH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP,
USB_DEVICE_ID_WALTOP_SLIM_TABLET_12_1_INCH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_Q_PAD) },
diff --git a/drivers/hid/hid-sjoy.c b/drivers/hid/hid-sjoy.c
index 37845eccddb5..36b6470af947 100644
--- a/drivers/hid/hid-sjoy.c
+++ b/drivers/hid/hid-sjoy.c
@@ -166,6 +166,9 @@ static const struct hid_device_id sjoy_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_DUAL_USB_JOYPAD),
.driver_data = HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PLAYDOTCOM,
USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII),
+ .driver_data = HID_QUIRK_MULTI_INPUT |
+ HID_QUIRK_SKIP_OUTPUT_REPORTS },
{ }
};
MODULE_DEVICE_TABLE(hid, sjoy_devices);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 99e5407221e6..33a08738dba9 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -52,7 +52,6 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH_2968,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
- { USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_TOUCHPACK, USB_DEVICE_ID_TOUCHPACK_RTS,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_AIREN, USB_DEVICE_ID_AIREN_SLIMPLUS, HID_QUIRK_NOGET },
--
2.9.0
[PATCH 3.12 15/56] remove directory incorrectly tries to set delete on close on non-empty directories
From: Steve French
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 897fba1172d637d344f009d700f7eb8a1fa262f1 upstream.
Wrong return code was being returned on SMB3 rmdir of
non-empty directory.
For SMB3 (unlike for cifs), we attempt to delete a directory by
set of delete on close flag on the open. Windows clients set
this flag via a set info (SET_FILE_DISPOSITION to set this flag)
which properly checks if the directory is empty.
With this patch on smb3 mounts we correctly return
"DIRECTORY NOT EMPTY"
on attempts to remove a non-empty directory.
Signed-off-by: Steve French
Acked-by: Sachin Prabhu
Signed-off-by: Jiri Slaby
---
fs/cifs/smb2glob.h | 1 +
fs/cifs/smb2inode.c | 8 ++--
fs/cifs/smb2pdu.c | 16
fs/cifs/smb2proto.h | 2 ++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/smb2glob.h b/fs/cifs/smb2glob.h
index bc0bb9c34f72..0ffa18094335 100644
--- a/fs/cifs/smb2glob.h
+++ b/fs/cifs/smb2glob.h
@@ -44,6 +44,7 @@
#define SMB2_OP_DELETE 7
#define SMB2_OP_HARDLINK 8
#define SMB2_OP_SET_EOF 9
+#define SMB2_OP_RMDIR 10
/* Used when constructing chained read requests. */
#define CHAINED_REQUEST 1
diff --git a/fs/cifs/smb2inode.c b/fs/cifs/smb2inode.c
index 215f8d3e3e53..f970c5d5b253 100644
--- a/fs/cifs/smb2inode.c
+++ b/fs/cifs/smb2inode.c
@@ -80,6 +80,10 @@ smb2_open_op_close(const unsigned int xid, struct cifs_tcon
*tcon,
* SMB2_open() call.
*/
break;
+ case SMB2_OP_RMDIR:
+ tmprc = SMB2_rmdir(xid, tcon, fid.persistent_fid,
+ fid.volatile_fid);
+ break;
case SMB2_OP_RENAME:
tmprc = SMB2_rename(xid, tcon, fid.persistent_fid,
fid.volatile_fid, (__le16 *)data);
@@ -191,8 +195,8 @@ smb2_rmdir(const unsigned int xid, struct cifs_tcon *tcon,
const char *name,
struct cifs_sb_info *cifs_sb)
{
return smb2_open_op_close(xid, tcon, cifs_sb, name, DELETE, FILE_OPEN,
- CREATE_NOT_FILE | CREATE_DELETE_ON_CLOSE,
- NULL, SMB2_OP_DELETE);
+ CREATE_NOT_FILE,
+ NULL, SMB2_OP_RMDIR);
}
int
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index a47ac835145b..439cb86ed488 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2254,6 +2254,22 @@ SMB2_rename(const unsigned int xid, struct cifs_tcon
*tcon,
}
int
+SMB2_rmdir(const unsigned int xid, struct cifs_tcon *tcon,
+ u64 persistent_fid, u64 volatile_fid)
+{
+ __u8 delete_pending = 1;
+ void *data;
+ unsigned int size;
+
+ data = &delete_pending;
+ size = 1; /* sizeof __u8 */
+
+ return send_set_info(xid, tcon, persistent_fid, volatile_fid,
+ current->tgid, FILE_DISPOSITION_INFORMATION, 1, &data,
+ &size);
+}
+
+int
SMB2_set_hardlink(const unsigned int xid, struct cifs_tcon *tcon,
u64 persistent_fid, u64 volatile_fid, __le16 *target_file)
{
diff --git a/fs/cifs/smb2proto.h b/fs/cifs/smb2proto.h
index d18b19ec1145..5793f3e39a31 100644
--- a/fs/cifs/smb2proto.h
+++ b/fs/cifs/smb2proto.h
@@ -133,6 +133,8 @@ extern int SMB2_query_directory(const unsigned int xid,
struct cifs_tcon *tcon,
extern int SMB2_rename(const unsigned int xid, struct cifs_tcon *tcon,
u64 persistent_fid, u64 volatile_fid,
__le16 *target_file);
+extern int SMB2_rmdir(const unsigned int xid, struct cifs_tcon *tcon,
+ u64 persistent_fid, u64 volatile_fid);
extern int SMB2_set_hardlink(const unsigned int xid, struct cifs_tcon *tcon,
u64 persistent_fid, u64 volatile_fid,
__le16 *target_file);
--
2.9.0
[PATCH 3.12 05/56] HID: microsoft: Add Surface Power Cover
From: Raimund Roth
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 18eec2cd7e9746cd672ada102987534ae16f0f44 upstream.
Adding support for the Microsoft Surface Pro Power Cover.
Signed-off-by: Raimund Roth
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 4 +++-
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-microsoft.c | 2 ++
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 7ca1b4a97a14..9d24332e1e27 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -705,7 +705,8 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
(hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3_JP) &&
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3_JP ||
+hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
hid->group == HID_GROUP_MULTITOUCH)
hid->group = HID_GROUP_GENERIC;
}
@@ -1811,6 +1812,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index fb200df1e78e..64f8fd16e9d7 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -651,6 +651,7 @@
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_45000x076c
#define USB_DEVICE_ID_MS_TYPE_COVER_30x07dc
#define USB_DEVICE_ID_MS_TYPE_COVER_3_JP 0x07dd
+#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 7e56e18665da..755c62d73896 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -260,6 +260,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3_JP),
.driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
+ .driver_data = MS_HIDINPUT },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 3771a7ef6395..3b3fcbd28320 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -89,6 +89,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
--
2.9.0
[PATCH 3.12 08/56] HID: Add new Microsoft Type Cover 3 product ID
From: Donavan Lance
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c6956eb70e2549a3c2fa6ee525e02776d293caf4 upstream.
Adds support for Microsoft Type Cover 3 with 0x07e2 product ID.
Signed-off-by: Donavan Lance
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-core.c | 2 ++
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-microsoft.c | 2 ++
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index bde7e255a6b0..b62ceaf1a11e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -705,6 +705,7 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
(hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
@@ -1812,6 +1813,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d974db4e36de..7ab974cafee8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -656,6 +656,7 @@
#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
+#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 0x07e2
#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
#define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 2f9d260539c9..859ee53f630f 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -264,6 +264,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_DUPLICATE_USAGES },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3),
.driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2),
+ .driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3),
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 825d052cd2cb..99e5407221e6 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -88,6 +88,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER,
HID_QUIRK_NO_INIT_REPORTS },
--
2.9.0
Re: [PATCH v6 1/4] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group
On 15 June 2016 at 00:21, Yuyang Du wrote: > Vincent reported that the first task to a new task group's cfs_rq will > be attached in attach_task_cfs_rq() and once more when it is enqueued > (see https://lkml.org/lkml/2016/5/25/388). > > Actually, it is worse. The sched avgs can be sometimes attached twice > not only when we change task groups but also when we switch to fair class. > These two scenarios will be described in the following respectively. > > (1) Switch to fair class: > > The sched class change is done like this: > > if (queued) > enqueue_task(); > check_class_changed() > switched_from() > switched_to() > > If the task is on_rq, before switched_to(), it has been enqueued, which > already attached sched avgs to the cfs_rq if the task's last_update_time > is 0, which can happen if the task was never fair class, if so, we > shouldn't attach it again in switched_to(), otherwise, we attach it twice. > > To address both the on_rq and !on_rq cases, as well as both the task > was switched from fair and otherwise, the simplest solution is to reset > the task's last_update_time to 0 when the task is switched from fair. > Then let task enqueue do the sched avgs attachment uniformly only once. > > (2) Change between fair task groups: > > The task groups are changed like this: > > if (queued) > dequeue_task() > task_move_group() > if (queued) > enqueue_task() > > Unlike the switch to fair class case, if the task is on_rq, it will be > enqueued right away after we move task groups, and if not, in the future > when the task is runnable. The attach twice problem can happen if the > cfs_rq and the task are both new as Vincent discovered. The simplest > solution is to only reset the task's last_update_time in task_move_group(), > and then let enqueue_task() do the sched avgs attachment. I still have concerned with this change of the behavior that attaches the task only when it is enqueued. The load avg of the task will not be decayed between the time we move it into its new group until its enqueue. With this change, a task's load can stay high whereas it has slept for the last couple of seconds. Then, its load and utilization is no more accounted anywhere in the mean time just because we have moved the task which will be enqueued on the same rq. A task should always be attached to a cfs_rq and its load/utilization should always be accounted on a cfs_rq and decayed for its sleep period Regards, Vincent > > Reported-by: Vincent Guittot > Signed-off-by: Yuyang Du > ---
[PATCH 3.12 10/56] HID: chicony: Add support for Acer Aspire Switch 12
From: Николай Кудрявцев
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 9a1d78a3780e0e37eeff11b377fc5fbb01446a36 upstream.
Acer Aspire Switch 12 keyboard Chicony's controller reports too big usage
index on the 1st interface. The patch fixes the report. The work based on
solution from drivers/hid/hid-holtek-mouse.c
Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=101721
Signed-off-by: Nicholas Kudriavtsev
Signed-off-by: Jiri Kosina
Signed-off-by: Jiri Slaby
---
drivers/hid/hid-chicony.c | 26 ++
drivers/hid/hid-core.c| 1 +
drivers/hid/hid-ids.h | 1 +
3 files changed, 28 insertions(+)
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index b613d5a79684..bc3cec199fee 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "hid-ids.h"
@@ -57,10 +58,34 @@ static int ch_input_mapping(struct hid_device *hdev, struct
hid_input *hi,
return 1;
}
+static __u8 *ch_switch12_report_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+
+ if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
+ /* Change usage maximum and logical maximum from 0x7fff to
+* 0x2fff, so they don't exceed HID_MAX_USAGES */
+ switch (hdev->product) {
+ case USB_DEVICE_ID_CHICONY_ACER_SWITCH12:
+ if (*rsize >= 128 && rdesc[64] == 0xff && rdesc[65] ==
0x7f
+ && rdesc[69] == 0xff && rdesc[70] ==
0x7f) {
+ hid_info(hdev, "Fixing up report descriptor\n");
+ rdesc[65] = rdesc[70] = 0x2f;
+ }
+ break;
+ }
+
+ }
+ return rdesc;
+}
+
+
static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ }
};
MODULE_DEVICE_TABLE(hid, ch_devices);
@@ -68,6 +93,7 @@ MODULE_DEVICE_TABLE(hid, ch_devices);
static struct hid_driver ch_driver = {
.name = "chicony",
.id_table = ch_devices,
+ .report_fixup = ch_switch12_report_fixup,
.input_mapping = ch_input_mapping,
};
module_hid_driver(ch_driver);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 6ae4df439d06..05867d1d8cdc 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1719,6 +1719,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS,
USB_DEVICE_ID_PRODIKEYS_PCMIDI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
USB_DEVICE_ID_CYPRESS_BARCODE_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
USB_DEVICE_ID_CYPRESS_BARCODE_2) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 6a6b06ef31b1..555dc61d2eb3 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -224,6 +224,7 @@
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
#define USB_DEVICE_ID_CHICONY_AK1D 0x1125
+#define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
#define USB_VENDOR_ID_CHUNGHWAT0x2247
#define USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH 0x0001
--
2.9.0
Re: [PATCH 1/3] net: Add MDIO bus driver for the Hisilicon FEMAC
On 2016/6/15 6:27, Rob Herring wrote: > On Mon, Jun 13, 2016 at 02:07:54PM +0800, Dongpo Li wrote: >> This patch adds a separate driver for the MDIO interface of the >> Hisilicon Fast Ethernet MAC. >> >> Reviewed-by: Jiancheng Xue >> Signed-off-by: Dongpo Li >> --- >> .../bindings/net/hisilicon-femac-mdio.txt | 22 +++ > > Acked-by: Rob Herring > Hi Rob, Thanks for your review. >> drivers/net/phy/Kconfig| 8 + >> drivers/net/phy/Makefile | 1 + >> drivers/net/phy/mdio-hisi-femac.c | 165 >> + >> 4 files changed, 196 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/net/hisilicon-femac-mdio.txt >> create mode 100644 drivers/net/phy/mdio-hisi-femac.c > > . >
Re: [very-RFC 0/8] TSN driver for the kernel
On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote: > On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > > Whereas I want to do > > > > aplay some_song.wav > > Can you please explain how your patches accomplish this? In short: modprobe tsn modprobe avb_alsa mkdir /sys/kernel/config/eth0/link cd /sys/kernel/config/eth0/link echo alsa > enabled aplay -Ddefault:CARD=avb some_song.wav Likewise on the receiver side, except add 'Listener' to end_station attribute arecord -c2 -r48000 -f S16_LE -Ddefault:CARD=avb > some_recording.wav I've not had time to fully fix the hw-aprams for alsa, so some manual tweaking of arecord is required. Again, this is a very early attempt to get something useful done with TSN, I know there are rough edges, I know buffer handling and timestamping is not finished Note: if you don't have an intel-card, load tsn in debug-mode and it will let you use all NICs present. modprobe tsn in_debug=1 -- Henrik Austad signature.asc Description: Digital signature
Re: [PATCH 2/4] scripts: add reqs python library
On 2016-06-15 00:10, Luis R. Rodriguez wrote: > +weight = (int(rel_specs['VERSION'])<< 32) + \ > + (int(rel_specs['PATCHLEVEL']) << 16) + \ > + (sublevel << 8 ) + \ > + (extra * 60) + (relmod * 2) This is going to silently break as soon as we have a version number with e.g. a time stamp embedded. And there is actually no need to convert the version string to an integer. You can convert them to arrays of components and compare the components one by one. Michal
Re: [PATCH 3/4] coccicheck: enable use of the kernel's python library
On 2016-06-15 00:10, Luis R. Rodriguez wrote:
> Signed-off-by: Luis R. Rodriguez
> ---
> scripts/coccicheck | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/coccicheck b/scripts/coccicheck
> index ba7301ab0a3d..a4d91d649ad9 100755
> --- a/scripts/coccicheck
> +++ b/scripts/coccicheck
> @@ -12,6 +12,8 @@
>
> DIR=$(dirname $(readlink -f $0))
> DIR="${DIR}/../"
> +export PYTHONPATH=${DIR}/scripts/
The first assignment to DIR already sets the desired path.
Michal
Re: [PATCH] ARM: sun8i: Add Parrot Board DTS
Hi,
On 06/14/2016 03:19 PM, Chen-Yu Tsai wrote:
On Tue, Jun 14, 2016 at 8:59 PM, Quentin Schulz
wrote:
Hi,
On 13/06/2016 15:04, Chen-Yu Tsai wrote:
Hi,
On Mon, Jun 13, 2016 at 6:15 PM, Quentin Schulz
wrote:
The Parrot Board is an evaluation board with an Allwinner R16 (assumed
to be close to an Allwinner A33), 4GB of NAND, 512MB of RAM, USB host
You say NAND here, but you enable mmc2 for eMMC below. Please correct it.
ACK.
and OTG, a WiFi/Bluetooth combo chip, a micro SD Card reader, 2
controllable buttons, an LVDS port with separated backlight and
capacitive touch panel ports, an audio/microphone jack, a camera CSI
port, 2 sets of 22 GPIOs and an accelerometer.
I assume the board is this one:
https://world.taobao.com/item/530374411673.htm
Definitely looks like it.
Signed-off-by: Quentin Schulz
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-r16-parrot.dts | 333 +
2 files changed, 334 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-r16-parrot.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 06b6c2d..1149512 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -760,6 +760,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-ippo-q8h-v1.2.dtb \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
+ sun8i-r16-parrot.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts
b/arch/arm/boot/dts/sun8i-r16-parrot.dts
new file mode 100644
index 000..75e2420
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-r16-parrot.dts
@@ -0,0 +1,333 @@
+/*
+ * Copyright 2015 Quentin Schulz
+ *
+ * Quentin Schulz
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Allwinner Parrot EVB R16";
+ compatible = "allwinner,parrot-evb-r16", "allwinner,sun8i-a33";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_r16>;
IMO r16 is too generic. You may want to add parrot_ or parrot_evb_ to it.
Same goes for all the other r16 identifier names.
ACK.
+
+ led1 {
+ label = "r16:led1:usr";
+ gpio = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
+ };
+
+ led2 {
+ label = "r16:led2:usr";
+ gpio = <&pio 4 16 GPIO_ACTIVE_HIGH>; /* PE16 */
+ };
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&r_pio 0 6 GPIO_ACTIVE_LOW>; /* PL06 */
+ };
+
+};
+
+&ehci0 {
+ status = "okay";
+};
Re: [PATCH] extcon: palmas: Fix boot up state of VBUS when using GPIO detection
On 2016년 06월 15일 15:47, Roger Quadros wrote:
> On 15/06/16 04:57, Chanwoo Choi wrote:
>> On 2016년 06월 14일 23:04, Roger Quadros wrote:
>>> If USB cable is connected prior to boot, we don't get any interrupts
>>> so we must manually check the VBUS state and report it during probe.
>>> If we don't do it then USB controller will never know that peripheral
>>> cable was connected till the user unplugs and replugs the cable.
>>>
>>> Fixes: b7aad8e2685b ("extcon: palmas: Add the support for VBUS detection by
>>> using GPIO")
>>> Signed-off-by: Roger Quadros
>>> ---
>>> drivers/extcon/extcon-palmas.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>>> index 8b3226d..caff46c 100644
>>> --- a/drivers/extcon/extcon-palmas.c
>>> +++ b/drivers/extcon/extcon-palmas.c
>>> @@ -360,6 +360,8 @@ static int palmas_usb_probe(struct platform_device
>>> *pdev)
>>>
>>> palmas_enable_irq(palmas_usb);
>>> /* perform initial detection */
>>> + if (palmas_usb->enable_gpio_vbus_detection)
>>> + palmas_vbus_irq_handler(palmas_usb->gpio_vbus_irq, palmas_usb);
>>> palmas_gpio_id_detect(&palmas_usb->wq_detectid.work);
>>> device_set_wakeup_capable(&pdev->dev, true);
>>> return 0;
>>>
>>
>> Applied it.
>
> Thanks. But this is a bug fix and must go in v4.7-rc
> as well as stable v4.6+.
OK. I'll send the pull request for this patch.
>
> Can you please add
>
> Cc: sta...@vger.kernel.org # v4.6+
If we should add the 'sta...@verger.kernel.org',
this patch should be sent to mailing list.
So, I think that you better to send this patch including stable mailing list.
And then, I'll send pull request which apply this patch to 4.7-rc.
Thanks,
Chanwoo Choi
Re: [PATCH v7 00/12] Support non-lru page migration
Hello Minchan, -next 4.7.0-rc3-next-20160614 [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 315.146546] general protection fault: [#1] PREEMPT SMP KASAN [ 315.146576] Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon crc32c_intel r8169 i2c_i801 mii snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich mfd_core processor sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci libata ehci_pci ehci_hcd scsi_mod usbcore usb_common [ 315.146785] CPU: 3 PID: 38 Comm: khugepaged Not tainted 4.7.0-rc3-next-20160614-dbg-4-ga1c2cbc-dirty #488 [ 315.146841] task: 8800bfaf2900 ti: 880112468000 task.ti: 880112468000 [ 315.146859] RIP: 0010:[] [] zs_page_migrate+0x355/0xaa0 [zsmalloc] [ 315.146892] RSP: :88011246f138 EFLAGS: 00010293 [ 315.146906] RAX: 736761742d6f6e2c RBX: 880017ad9a80 RCX: [ 315.146924] RDX: 1064d704 RSI: 88000511469a RDI: 8326ba20 [ 315.146942] RBP: 88011246f328 R08: 0001 R09: [ 315.146959] R10: 88011246f0a8 R11: 8800bfc07fff R12: 88011246f300 [ 315.146977] R13: ed0015523e6f R14: 8800aa91f378 R15: ea144500 [ 315.146995] FS: () GS:88011378() knlGS: [ 315.147015] CS: 0010 DS: ES: CR0: 80050033 [ 315.147030] CR2: 7f3f97911000 CR3: 02209000 CR4: 06e0 [ 315.147046] Stack: [ 315.147052] 110015523e0f 88011246f240 880005116800 00017f80e000 [ 315.147083] 880017ad9aa8 736761742d6f6e2c 11002248de34 880017ad9a90 [ 315.147113] 069a1246f660 069a 880005114000 ea0002ff0180 [ 315.147143] Call Trace: [ 315.147154] [] ? obj_to_head+0x9d/0x9d [zsmalloc] [ 315.147175] [] ? _raw_spin_unlock_irqrestore+0x47/0x5c [ 315.147195] [] ? isolate_freepages_block+0x2f9/0x5a6 [ 315.147213] [] ? kasan_poison_shadow+0x2f/0x31 [ 315.147230] [] ? kasan_alloc_pages+0x39/0x3b [ 315.147246] [] ? map_pages+0x1f3/0x3ad [ 315.147262] [] ? update_pageblock_skip+0x18d/0x18d [ 315.147280] [] ? up_read+0x1a/0x30 [ 315.147296] [] ? debug_check_no_locks_freed+0x150/0x22b [ 315.147315] [] move_to_new_page+0x4dd/0x615 [ 315.147332] [] ? migrate_page+0x75/0x75 [ 315.147347] [] ? isolate_freepages_block+0x5a6/0x5a6 [ 315.147366] [] migrate_pages+0xadd/0x131a [ 315.147382] [] ? isolate_freepages_block+0x5a6/0x5a6 [ 315.147399] [] ? kzfree+0x2b/0x2b [ 315.147414] [] ? buffer_migrate_page+0x2db/0x2db [ 315.147431] [] compact_zone+0xcdb/0x1155 [ 315.147448] [] ? compaction_suitable+0x76/0x76 [ 315.147465] [] compact_zone_order+0xe0/0x167 [ 315.147481] [] ? debug_show_all_locks+0x226/0x226 [ 315.147499] [] ? compact_zone+0x1155/0x1155 [ 315.147515] [] ? finish_task_switch+0x3de/0x484 [ 315.147533] [] try_to_compact_pages+0x2f1/0x648 [ 315.147550] [] ? try_to_compact_pages+0x2f1/0x648 [ 315.147568] [] ? compaction_zonelist_suitable+0x3a6/0x3a6 [ 315.147589] [] ? get_page_from_freelist+0x2c0/0x129a [ 315.147608] [] __alloc_pages_direct_compact+0xea/0x30d [ 315.147626] [] ? get_page_from_freelist+0x129a/0x129a [ 315.147645] [] __alloc_pages_nodemask+0x840/0x16b6 [ 315.147663] [] ? try_to_wake_up+0x696/0x6c8 [ 315.149147] [] ? warn_alloc_failed+0x226/0x226 [ 315.150615] [] ? wake_up_process+0x10/0x12 [ 315.152078] [] ? wake_up_q+0x89/0xa7 [ 315.153539] [] ? rwsem_wake+0x131/0x15c [ 315.155007] [] ? khugepaged+0x4072/0x484f [ 315.156471] [] khugepaged+0x1d4/0x484f [ 315.157940] [] ? hugepage_vma_revalidate+0xef/0xef [ 315.159402] [] ? finish_task_switch+0x3de/0x484 [ 315.160870] [] ? _raw_spin_unlock_irq+0x27/0x45 [ 315.162341] [] ? trace_hardirqs_on_caller+0x3d2/0x492 [ 315.163814] [] ? prepare_to_wait_event+0x3f7/0x3f7 [ 315.165295] [] ? __schedule+0xa4d/0xd16 [ 315.166763] [] kthread+0x252/0x261 [ 315.168214] [] ? hugepage_vma_revalidate+0xef/0xef [ 315.169646] [] ? kthread_create_on_node+0x377/0x377 [ 315.171056] [] ret_from_fork+0x1f/0x40 [ 315.172462] [] ? kthread_create_on_node+0x377/0x377 [ 315.173869] Code: 03 b5 60 fe ff ff e8 2e fc ff ff a8 01 74 4c 48 83 e0 fe bf 01 00 00 00 48 89 85 38 fe ff ff e8 41 18 e1 e0 48 8b 85 38 fe ff ff 0f ba 28 00 73 29 bf 01 00 00 00 41 bc f5 ff ff ff e8 ea 27 [ 315.175573] RIP [] zs_page_migrate+0x355/0xaa0 [zsmalloc] [ 315.177084] RSP [ 315.186572] ---[ end trace 0962b8ee48c98bbc ]--- [ 315.186577] BUG: sleeping function called from invalid context at include/linux/sched.h:2960 [ 315.186580] in_atomic(): 1, irqs_disabled(): 0, pid: 38, name: khugepaged [ 315.186581] INFO: lockdep is turned off. [ 315.186583] Preemption disabled at:[] zs_page_migrate+0x135/0xaa0 [zsmalloc] [ 315.186594] CPU: 3 PID: 38 Comm: khugepaged
Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier
Hi Waiman,
On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> The osq_lock() and osq_unlock() function may not provide the necessary
> acquire and release barrier in some cases. This patch makes sure
> that the proper barriers are provided when osq_lock() is successful
> or when osq_unlock() is called.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/osq_lock.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> index 05a3785..7dd4ee5 100644
> --- a/kernel/locking/osq_lock.c
> +++ b/kernel/locking/osq_lock.c
> @@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
>* cmpxchg in an attempt to undo our queueing.
>*/
>
> - while (!READ_ONCE(node->locked)) {
> + while (!smp_load_acquire(&node->locked)) {
> /*
>* If we need to reschedule bail... so we can block.
>*/
> @@ -198,7 +198,7 @@ void osq_unlock(struct optimistic_spin_queue *lock)
>* Second most likely case.
>*/
> node = this_cpu_ptr(&osq_node);
> - next = xchg(&node->next, NULL);
> + next = xchg_release(&node->next, NULL);
> if (next) {
> WRITE_ONCE(next->locked, 1);
So we still use WRITE_ONCE() rather than smp_store_release() here?
Though, IIUC, This is fine for all the archs but ARM64, because there
will always be a xchg_release()/xchg() before the WRITE_ONCE(), which
carries a necessary barrier to upgrade WRITE_ONCE() to a RELEASE.
Not sure whether it's a problem on ARM64, but I think we certainly need
to add some comments here, if we count on this trick.
Am I missing something or misunderstanding you here?
Regards,
Boqun
> return;
> --
> 1.7.1
>
signature.asc
Description: PGP signature
Re: [PATCH] dell-smm-hwmon: Detect fan with index=2
On Monday 13 June 2016 19:01:15 Guenter Roeck wrote: > On 06/13/2016 11:26 AM, Pali Rohár wrote: > >Guenter, I think you can take this patch also with Tolga's Tested-by. > > > > The patch on its own doesn't apply. It depends on 'Cache fan-type calls ...'. > Should I take that patch as well ? Ah right, so I will send all patches in new series. > Also, the test feedback was informal. I can not convert it to a formal > Tested-by: without explicit permission (some people don't want to see > their e-mail address in kernel logs). Tolga, can confirm or reject your Tested-by inclusion? -- Pali Rohár pali.ro...@gmail.com
[PATCH] ALSA: seq_oss: Change structure initialisation to C99 style
Replace the in order struct initialisation style with explicit field
style.
The Coccinelle semantic patch used to make this change is as follows:
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@
struct i1 {
fs
T fld;
...};
@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@
struct i1 i2@p = { ...,
+ .fld = e
- e@fix
,...};
Also, removed some unnecessary comments.
Signed-off-by: Amitoj Kaur Chawla
---
sound/core/seq/oss/seq_oss_synth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/core/seq/oss/seq_oss_synth.c
b/sound/core/seq/oss/seq_oss_synth.c
index b16dbef..cd0e0eb 100644
--- a/sound/core/seq/oss/seq_oss_synth.c
+++ b/sound/core/seq/oss/seq_oss_synth.c
@@ -70,11 +70,11 @@ struct seq_oss_synth {
static int max_synth_devs;
static struct seq_oss_synth *synth_devs[SNDRV_SEQ_OSS_MAX_SYNTH_DEVS];
static struct seq_oss_synth midi_synth_dev = {
- -1, /* seq_device */
- SYNTH_TYPE_MIDI, /* synth_type */
- 0, /* synth_subtype */
- 16, /* nr_voices */
- "MIDI", /* name */
+ .seq_device = -1,
+ .synth_type = SYNTH_TYPE_MIDI,
+ .synth_subtype = 0,
+ .nr_voices = 16,
+ .name = "MIDI",
};
static DEFINE_SPINLOCK(register_lock);
--
1.9.1
Re: [PATCH 3/4] x86: Rewrite switch_to() code
* Andy Lutomirski wrote: > On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: > > > Move the low-level context switch code to an out-of-line asm stub instead > > of > > using complex inline asm. This allows constructing a new stack frame for > > the > > child process to make it seamlessly flow to ret_from_fork without an extra > > test and branch in __switch_to(). It also improves code generation for > > __schedule() by using the C calling convention instead of clobbering all > > registers. > > Just a heads up: I'm writing some code that conflicts with this patch. The > conflict will be easy to resolve, and, if this patch beats mine to -tip, I'll > rebase. So I was expecting another iteration of this switch_to() series, but had no fundamental objections to the concept. Thanks, Ingo
Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection
On Monday 13 June 2016 19:02:14 Guenter Roeck wrote: > >And second question: how to fix second bug? I see only one option: > >Create machine blacklist with broken Dell SMM firmware and disallow > >calling I8K_SMM_GET_FAN_TYPE for them. > > > Or maybe a whitelist with known working systems ? > > Guenter Smaller list is better, so I will try to collect blacklist and if it will be big we can use whitelist. -- Pali Rohár pali.ro...@gmail.com
Re: Moving drivers/leds/dell-led.c to drivers/platform/x86
On Monday 13 June 2016 15:49:42 Michał Kępień wrote: > Hi everyone, > > Back in January [1], while working on the dell-smbios module, I > suggested that the code present in drivers/leds/dell-led.c could be > moved to drivers/platform/x86 for coherency. I decided to revisit that > idea. > > dell-led consists of two major parts: > > - the part handling an "Activity LED" present in Dell Latitude 2100 > netbooks, introduced in 72dcd8d; it registers a LED device and uses > a special WMI interface to control its state, > > - the part exposing a "microphone mute LED interface", introduced in > db6d8cc; this interface is used by sound/pci/hda/dell_wmi_helper.c; > while the original implementation also used a WMI interface, it was > changed to use dell-smbios in cf0d7ea and 0c41a08. > > I believe both parts could (and should) be moved to drivers/platform/x86 > as drivers/platform/x86/dell-laptop.c already handles a bunch of LEDs > and drivers/leds/dell-led.c is the only dell-smbios user outside of > drivers/platform/x86. > > My question to you, the maintainers of the relevant drivers and > subsystems, is whether you would like to see such a move happen. I have > prepared a draft patch series which: > > - moves the "microphone mute LED interface" to dell-laptop.c, > effectively causing sound/pci/hda/dell_wmi_helper.c to depend on > CONFIG_DELL_LAPTOP instead of CONFIG_LEDS_DELL_NETBOOKS, > > - moves the "Activity LED" part to a new file, tentatively called > drivers/platform/x86/dell-wmi-led.c. > > Merging the "Activity LED" part with drivers/platform/x86/dell-wmi.c is > not really clean because dell-wmi handles a different GUID, which AFAIK > is not related in any way to the GUID used by dell-led. > > So, before I spam *three* subsystem mailing lists with a bunch of > patches, I would love to hear from the maintainers of both drivers/leds > and drivers/platform/x86 whether there are any arguments against such a > move. Meanwhile, I will keep polishing the patch series and if there is > no strong disagreement from any party involved, I will post the series > next week or so, so that we can discuss code and not just ideas. > > As a side note, if anyone reading this has access to a Dell device which > has an "Activity LED" and/or a "microphone mute LED" currently supported > by dell-led, I would love to hear from you as I do not have the hardware > needed to practically test the patch series I am working on. > > Looking forward to hearing from you, > > [1] https://www.spinics.net/lists/platform-driver-x86/msg08143.html I was talking with Michał and I supports this move. -- Pali Rohár pali.ro...@gmail.com
Re: [very-RFC 0/8] TSN driver for the kernel
On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote: > > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > >> I have seen audio PLL/multiplier chips that will take, for example, a > >> 10 kHz input and produce your 48 kHz media clock. With the right HW > >> design, you can tell your PTP Hardware Clock to produce a 1 PPS, > >> and you will have a synchronized AVB endpoint. The software is all > >> there already. Somebody should tell the ALSA guys about it. > > Just from my curiosity, could I ask you more explanation for it in ALSA > side? (Disclaimer: I really don't know too much about ALSA, expect that is fairly big and complex ;) Here is what I think ALSA should provide: - The DA and AD clocks should appear as attributes of the HW device. - There should be a method for measuring the DA/AD clock rate with respect to both the system time and the PTP Hardware Clock (PHC) time. - There should be a method for adjusting the DA/AD clock rate if possible. If not, then ALSA should fall back to sample rate conversion. - There should be a method to determine the time delay from the point when the audio data are enqueued into ALSA until they pass through the D/A converter. If this cannot be known precisely, then the library should provide an estimate with an error bound. - I think some AVB use cases will need to know the time delay from A/D until the data are available to the local application. (Distributed microphones? I'm not too sure about that.) - If the DA/AD clocks are connected to other clock devices in HW, there should be a way to find this out in SW. For example, if SW can see the PTP-PHC-PLL-DA relationship from the above example, then it knows how to synchronize the DA clock using the network. [ Implementing this point involves other subsystems beyond ALSA. It isn't really necessary for people designing AVB systems, since they know their designs, but it would be nice to have for writing generic applications that can deal with any kind of HW setup. ] > In ALSA, sampling rate conversion should be in userspace, not in kernel > land. In alsa-lib, sampling rate conversion is implemented in shared object. > When userspace applications start playbacking/capturing, depending on PCM > node to access, these applications load the shared object and convert PCM > frames from buffer in userspace to mmapped DMA-buffer, then commit them. The AVB use case places an additional requirement on the rate conversion. You will need to adjust the frequency on the fly, as the stream is playing. I would guess that ALSA doesn't have that option? Thanks, Richard
Re: [PATCH v1 1/1] x86/platform/intel-mid: Enable GPIO expanders on Edison
* Andy Shevchenko wrote:
> +static const struct devs_id pcal9555a_1_dev_id __initconst = {
> + .name = "pcal9555a-1",
> + .type = SFI_DEV_TYPE_I2C,
> + .delay = 1,
> + .get_platform_data = &pcal9555a_platform_data,
> +};
> +
> +static const struct devs_id pcal9555a_2_dev_id __initconst = {
> + .name = "pcal9555a-2",
> + .type = SFI_DEV_TYPE_I2C,
> + .delay = 1,
> + .get_platform_data = &pcal9555a_platform_data,
> +};
> +
> +static const struct devs_id pcal9555a_3_dev_id __initconst = {
> + .name = "pcal9555a-3",
> + .type = SFI_DEV_TYPE_I2C,
> + .delay = 1,
> + .get_platform_data = &pcal9555a_platform_data,
> +};
> +
> +static const struct devs_id pcal9555a_4_dev_id __initconst = {
> + .name = "pcal9555a-4",
> + .type = SFI_DEV_TYPE_I2C,
> + .delay = 1,
> + .get_platform_data = &pcal9555a_platform_data,
> +};
I have the same complaint as yesterday. Going forward could we please get nice
structure initializers in all future patches? :)
Thanks,
Ingo
Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835.
On Tue, Jun 14, 2016 at 11:48:54PM -0700, Eric Anholt wrote: > Catalin Marinas writes: > > > On Thu, Jun 09, 2016 at 05:21:35PM -0700, Eric Anholt wrote: > >> Catalin Marinas writes: > >> > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: > >> >> Catalin Marinas writes: > >> >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: > >> >> >> + This SoC is used in the Raspberry Pi 3 device. > >> >> > > >> >> > I thought we would just use ARCH_BCM, or is it too generic? > >> >> > >> >> Consensus last time around seemed to be to drop adding ARCH_BCM, in > >> >> favor of patch 1 of the series. > >> > > >> > I may have missed that discussion. My point was about consistency with > >> > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see > >> > why it's easier for you since some drivers are built based on > >> > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an > >> > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new > >> > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending > >> > on ARCH_BCM). > >> > >> So I introduce a new ARCH_BCM here, that selects the just the 283x > >> family's core drivers? That seems strange, but I'm willing if that's > >> what you want. > > > > I'll leave this decision to the arm-soc guys. What I want to avoid is > > another ARCH_BCM283[89] when some clock or other device changes in a > > future revision of this board (RPi4?). I also don't want fine-grained > > SoC configuration *within* the arch/arm64 Kconfigs but rather just a > > family ARCH_* entry with selectable individual drivers based on the SoC > > revision you target (in case you want to avoid single Image). > > > > We should in general try to give drivers their own Kconfig entries > > separate from ARCH_* ones (with a "depend on ARCH_*" and default y if > > you want it enabled). > > OK, we haven't added separate ARCH_BCM283* for the 3 chip revs so far, > so I think what you want is actually the status quo, and we're in > serious agreement. The name for the family just happens to be > ARCH_BCM2835. > > Any chance we could get an ack on this? If you need one ;) (arm-soc is maintaining this file): Acked-by: Catalin Marinas
[PATCH] extcon: palmas: Fix boot up state of VBUS when using GPIO detection
If USB cable is connected prior to boot, we don't get any interrupts
so we must manually check the VBUS state and report it during probe.
If we don't do it then USB controller will never know that peripheral
cable was connected till the user unplugs and replugs the cable.
Fixes: b7aad8e2685b ("extcon: palmas: Add the support for VBUS detection by
using GPIO")
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Roger Quadros
---
drivers/extcon/extcon-palmas.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 8b3226d..caff46c 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -360,6 +360,8 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_enable_irq(palmas_usb);
/* perform initial detection */
+ if (palmas_usb->enable_gpio_vbus_detection)
+ palmas_vbus_irq_handler(palmas_usb->gpio_vbus_irq, palmas_usb);
palmas_gpio_id_detect(&palmas_usb->wq_detectid.work);
device_set_wakeup_capable(&pdev->dev, true);
return 0;
--
2.7.4
Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify
On Jun 09 2016 or thereabouts, Benjamin Tissoires wrote: > The i801 chip can handle the Host Notify feature since ICH 3 as mentioned > in > http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf > > Enable the functionality unconditionally and propagate the alert > on each notification. > > With a T440s and a Synaptics touchpad that implements Host Notify, the > payload data is always 0x, so I am not sure if the device actually > sends the payload or if there is a problem regarding the implementation. > > Tested-by: Andrew Duggan > Acked-by: Wolfram Sang > Signed-off-by: Benjamin Tissoires > --- > changes in v2: > - removed the description of the Slave functionality support in the chip table > (the table shows what is supported, not what the hardware is capable of) > - use i2c-smbus to forward the notification > - remove the fifo, and directly retrieve the address and payload in the worker > - do not check for Host Notification is the feature is not enabled > - use inw_p() to read the payload instead of 2 inb_p() calls > - add /* fall-through */ comment > - unconditionally enable Host Notify if the hardware supports it (can be > disabled by the user) > > no changes in v3 > > changes in v4: > - make use of the new API -> no more worker spawning here > - solved a race between the access of the Host Notify registers and the actual > I2C transfers. > > changes in v5: > - added SKL Host Notify support > > changes in v6: > - select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801 > is set to 'Y' while I2C_SMBUS is set to 'M' > > no changes in v7 > > changes in v8: > - reapplied after http://patchwork.ozlabs.org/patch/632768/ and merged the > conflict (minor conflict in the struct i801_priv). > - removed the .resume hook as upstream changed suspend/resume hooks and there > is no need in the end to re-enable host notify on resume (tested on Lenovo > t440 and t450). Actually, this hook seemed to be required on the Lenovo T440 (Haswell) but not on the T450 (Broadwell) laptop I have now here. Wolfram, I can resend the whole series or a follow-up patch to re-enable after resume Host Notify. How do you prefer I deal with that? Cheers, Benjamin
Re: [PATCH] ALSA: seq_oss: Change structure initialisation to C99 style
On Wed, 15 Jun 2016 10:03:31 +0200,
Amitoj Kaur Chawla wrote:
>
> Replace the in order struct initialisation style with explicit field
> style.
>
> The Coccinelle semantic patch used to make this change is as follows:
>
> @decl@
> identifier i1,fld;
> type T;
> field list[n] fs;
> @@
>
> struct i1 {
> fs
> T fld;
> ...};
>
> @@
> identifier decl.i1,i2,decl.fld;
> expression e;
> position bad.p, bad.fix;
> @@
>
> struct i1 i2@p = { ...,
> + .fld = e
> - e@fix
> ,...};
>
> Also, removed some unnecessary comments.
>
> Signed-off-by: Amitoj Kaur Chawla
Applied, thanks.
Takashi
Re: [PATCH v6 1/4] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group
On Wed, Jun 15, 2016 at 09:46:53AM +0200, Vincent Guittot wrote: > I still have concerned with this change of the behavior that attaches > the task only when it is enqueued. The load avg of the task will not > be decayed between the time we move it into its new group until its > enqueue. With this change, a task's load can stay high whereas it has > slept for the last couple of seconds. The task will be updated when it is moved in the detach, so if it stays high, it is highly expected to be enqueued soon. But if the task is never enqueued, we don't bother the new gruop cfs_rq. So this is not perfect, and nothing is perfect, but a simple solution.
Re: [PATCH v2 1/1] x86/platform/intel-mid: Add Power Management Unit driver
* Andy Shevchenko wrote: > Add Power Management Unit driver to handle power states of South Complex > devices on Intel Tangier. In the future it might be expanded to cover North > Complex devices as well. > > With this driver the power state of the host controllers such as SPI, I2C, > UART, eMMC, and DMA would be managed. > > Signed-off-by: Andy Shevchenko > --- > In v2: > - rename *pmu* to *pwr* > - fix indentation to be consistent for definitions > - add comments to explain what driver does > - refactor quirks in intel_mid_pci.c > > arch/x86/include/asm/intel-mid.h | 8 + > arch/x86/pci/intel_mid_pci.c | 40 +++- > arch/x86/platform/intel-mid/Makefile | 2 +- > arch/x86/platform/intel-mid/pwr.c| 416 > +++ > drivers/pci/Makefile | 3 + > drivers/pci/pci-mid.c| 77 +++ > 6 files changed, 540 insertions(+), 6 deletions(-) > create mode 100644 arch/x86/platform/intel-mid/pwr.c > create mode 100644 drivers/pci/pci-mid.c I've applied this to tip:x86/platform. I changed references to 'PMU' to 'PWRMU' - let me know if you'd like to use some other abbreviation. Please send the clean-up patch on top of this. (Feel free to squash the one I sent into yours.) Thanks, Ingo
[PATCH 1/2] pinctrl: uniphier: prohibit drive control for pin 61-66 of PH1-LD11
According to the hardware document, setting the drive control is
prohibited for these pins (N-channel Open Drain pins). Set their
drive control attribute to "fixed".
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
index 150942f..608cd73 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
@@ -151,22 +151,22 @@ static const struct pinctrl_pin_desc uniphier_ld11_pins[]
= {
60, UNIPHIER_PIN_DRV_1BIT,
60, UNIPHIER_PIN_PULL_DOWN),
UNIPHIER_PINCTRL_PIN(61, "DMDSDA0", 61,
-61, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(62, "DMDSCL0", 62,
-62, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(63, "SDA0", 63,
-63, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(64, "SCL0", 64,
-64, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(65, "SDA1", 65,
-65, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(66, "SCL1", 66,
-66, UNIPHIER_PIN_DRV_1BIT,
+-1, UNIPHIER_PIN_DRV_FIXED4,
-1, UNIPHIER_PIN_PULL_NONE),
UNIPHIER_PINCTRL_PIN(67, "HIN", 67,
-1, UNIPHIER_PIN_DRV_FIXED5,
--
1.9.1
[PATCH 0/2] pinctrl: uniphier: two more fixes for UniPhier pin data
Masahiro Yamada (2): pinctrl: uniphier: prohibit drive control for pin 61-66 of PH1-LD11 pinctrl: uniphier: fix meaningless drive control offsets drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 12 ++-- drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) -- 1.9.1
