Skip to content

L
linux
Switch branch/tag
  1. 23 Apr, 2015 14 commits
    • Chen-Yu Tsai's avatar
      ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage · 5ceacd4d
      Chen-Yu Tsai authored 
      [ Upstream commit fdc0074c ]

As the sunxi usb clocks all contain a reset controller, it is not
possible to build the sunxi clock driver without RESET_CONTROLLER
enabled. Doing so results in an undefined symbol error:

    drivers/built-in.o: In function `sunxi_gates_clk_setup':
    linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to
	`reset_controller_register'

This is possible if building a minimal kernel without PHY_SUN4I_USB.

The dependency issue is made visible at compile time instead of
link time by the new A80 mmc clocks, which also use a reset control
itself.

This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and
RESET_CONTROLLER.

Fixes: 559482d1 ARM: sunxi: Split the various SoCs support in Kconfig
Cc: <stable@vger.kernel.org> # 3.16+
Reported-by: default avatarLourens Rozema <ik@lourensrozema.nl>
Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5ceacd4d
    • Vineet Gupta's avatar
      ARC: signal handling robustify · 654acb34
      Vineet Gupta authored 
      [ Upstream commit e4140819 ]

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------
Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      654acb34
    • Vineet Gupta's avatar
      ARC: SA_SIGINFO ucontext regs off-by-one · b0864666
      Vineet Gupta authored 
      [ Upstream commit 6914e1e3 ]

The regfile provided to SA_SIGINFO signal handler as ucontext was off by
one due to pt_regs gutter cleanups in 2013.

Before handling signal, user pt_regs are copied onto user_regs_struct and copied
back later. Both structs are binary compatible. This was all fine until
commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot
at top of pt_regs (corresponding to first pad) and made the corresponding
fixup in struct user_regs_struct (the pad in there was moved out of
@scratch - not removed altogether as it is part of ptrace ABI)

 struct user_regs_struct {
+       long pad;
        struct {
-               long pad;
                long bta, lp_start, lp_end,....
        } scratch;
 ...
 }

This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
which is what this commit does.

This problem was hidden for 2 years, because both save/restore, despite
using wrong location, were using the same location. Only an interim
inspection (reproducer below) exposed the issue.

     void handle_segv(int signo, siginfo_t *info, void *context)
     {
 	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
               regs->scratch.r8, regs->scratch.r9);
     }

     int main()
     {
	struct sigaction sa;

	sa.sa_sigaction = handle_segv;
	sa.sa_flags = SA_SIGINFO;
	sigemptyset(&sa.sa_mask);
	sigaction(SIGSEGV, &sa, NULL);

	asm volatile(
	"mov	r7, 7	\n"
	"mov	r8, 8	\n"
	"mov	r9, 9	\n"
	"mov	r10, 10	\n"
	:::"r7","r8","r9","r10");

	*((unsigned int*)0x10) = 0;
     }

Fixes: 2fa91904 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
CC: <stable@vger.kernel.org>
Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b0864666
    • Matwey V. Kornilov's avatar
      PCI: spear: Drop __initdata from spear13xx_pcie_driver · a78cff34
      Matwey V. Kornilov authored 
      [ Upstream commit a43f32d6 ]

Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it
to platform_driver_register(), which can use the pointer at arbitrary times
in the future, even after the initdata is freed.  That leads to crashes.

Move spear13xx_pcie_driver and things referenced by it
(spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata.

[bhelgaas: changelog]
Fixes: 6675ef21 ("PCI: spear: Fix Section mismatch compilation warning for probe()")
Signed-off-by: default avatarMatwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
CC: stable@vger.kernel.org	# v3.17+
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a78cff34
    • Bjorn Helgaas's avatar
      PCI: Don't look for ACPI hotplug parameters if ACPI is disabled · f31d6097
      Bjorn Helgaas authored 
      [ Upstream commit 8647ca9a ]

Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):

  BUG: unable to handle kernel paging request at 0030303e
  IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a
  Call Trace:
   [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc
   [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0
   [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30
   [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4
   [<c0699d34>] ? pci_device_add+0x24/0x450

Don't look for ACPI configuration information if ACPI has been disabled.

I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML.  There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing.  This is an interim fix to address the regression.

Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by: default avatarMichael D Labriola <mlabriol@gdeb.com>
Tested-by: default avatarMichael D Labriola <mlabriol@gdeb.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.18+
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f31d6097
    • Dan Carpenter's avatar
      PCI: cpcihp: Add missing curly braces in cpci_configure_slot() · 5a3edbcd
      Dan Carpenter authored 
      [ Upstream commit bc3b5b47 ]

I don't have this hardware but it looks like we weren't adding bridge
devices as intended.  Maybe the bridge is always the last device?

Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarYijing Wang <wangyijing@huawei.com>
CC: stable@vger.kernel.org	# v3.9+
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5a3edbcd
    • Rasmus Villemoes's avatar
      PCI/AER: Avoid info leak in __print_tlp_header() · 02e0fab6
      Rasmus Villemoes authored 
      [ Upstream commit a1b7f2f6 ]

Commit fab4c256 ("PCI/AER: Add a TLP header print helper") introduced
the helper function __print_tlp_header(), but contrary to the intention,
the behaviour did change: Since we're taking the address of the parameter
t, the first 4 or 8 bytes printed will be the value of the pointer t
itself, and the remaining 12 or 8 bytes will be who-knows-what (something
from the stack).

We want to show the values of the four members of the struct
aer_header_log_regs; that can be done without ugly and error-prone casts.
On little-endian this should produce the same output as originally
intended, and since no-one has complained about getting garbage output so
far, I think big-endian should be ok too.

Fixes: fab4c256 ("PCI/AER: Add a TLP header print helper")
Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarBorislav Petkov <bp@suse.de>
CC: stable@vger.kernel.org	# v3.14+
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      02e0fab6
    • Takashi Iwai's avatar
      ALSA: hda - Fix headphone pin config for Lifebook T731 · e045a4c5
      Takashi Iwai authored 
      [ Upstream commit cc7016ab ]

Some BIOS version of Fujitsu Lifebook T731 seems to set up the
headphone pin (0x21) without the assoc number 0x0f while it's set only
to the output on the docking port (0x1a).  With the recent commit
[03ad6a8c: ALSA: hda - Fix "PCM" name being used on one DAC when
 there are two DACs], this resulted in the weird mixer element
mapping where the headphone on the laptop is assigned as a shared
volume with the speaker and the docking port is assigned as an
individual headphone.

This patch improves the situation by correcting the headphone pin
config to the more appropriate value.
Reported-and-tested-by: default avatarTaylor Smock <smocktaylor@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e045a4c5
    • Kailang Yang's avatar
      ALSA: hda/realtek - Make more stable to get pin sense for ALC283 · 432b1f9b
      Kailang Yang authored 
      [ Upstream commit a59d7199 ]

Pin sense will active when power pin is wake up.
Power pin will not wake up immediately during resume state.
Add some delay to wait for power pin activated.
Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      432b1f9b
    • Takashi Sakamoto's avatar
      ALSA: bebob: fix to processing in big-endian machine for sending cue · 8c54c7cb
      Takashi Sakamoto authored 
      [ Upstream commit a053fc31 ]

Some M-Audio devices require to receive bootup command just after
powering on, while codes in BeBoB driver doesn't work properly in
big-endian machine because the command should be aligned by
little-endian.

This commit fixes this bug. This fix should go to stable kernel.

Cc: Takayuki Shiroma <t.shiroma.oki@gmail.com>
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8c54c7cb
    • Dmitry M. Fedin's avatar
      ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support · 1f1c12d2
      Dmitry M. Fedin authored 
      [ Upstream commit 3dc8523f ]

Adds an entry for Creative USB X-Fi to the rc_config array in
mixer_quirks.c to allow use of volume knob on the device.
Adds support for newer X-Fi Pro card, known as "Model No. SB1095"
with USB ID "041e:3237"
Signed-off-by: default avatarDmitry M. Fedin <dmitry.fedin@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1f1c12d2
    • Hui Wang's avatar
      ALSA: hda - Add one more node in the EAPD supporting candidate list · e8543577
      Hui Wang authored 
      [ Upstream commit af95b414 ]

We have a HP machine which use the codec node 0x17 connecting the
internal speaker, and from the node capability, we saw the EAPD,
if we don't set the EAPD on for this node, the internal speaker
can't output any sound.

Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1436745Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e8543577
    • Sebastian Wicki's avatar
      ALSA: hda - Add dock support for Thinkpad T450s (17aa:5036) · fc9a2d46
      Sebastian Wicki authored 
      [ Upstream commit 80b311d3 ]

This model uses the same dock port as the previous generation.
Signed-off-by: default avatarSebastian Wicki <gandro@gmx.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fc9a2d46
    • Peter Hurley's avatar
      n_tty: Fix read buffer overwrite when no newline · 49118e22
      Peter Hurley authored 
      [ Upstream commit fb5ef9e7 ]

BugLink: http://bugs.launchpad.net/bugs/1381005

In canon mode, the read buffer head will advance over the buffer tail
if the input > 4095 bytes without receiving a line termination char.

Discard additional input until a line termination is received.
Before evaluating for overflow, the 'room' value is normalized for
I_PARMRK and 1 byte is reserved for line termination (even in !icanon
mode, in case the mode is switched). The following table shows the
transform:

 actual buffer |  'room' value before overflow calc
  space avail  |    !I_PARMRK    |    I_PARMRK
 --------------------------------------------------
      0        |       -1        |       -1
      1        |        0        |        0
      2        |        1        |        0
      3        |        2        |        0
      4+       |        3        |        1

When !icanon or when icanon and the read buffer contains newlines,
normalized 'room' values of -1 and 0 are clamped to 0, and
'overflow' is 0, so read_head is not adjusted and the input i/o loop
exits (setting no_room if called from flush_to_ldisc()). No input
is discarded since the reader does have input available to read
which ensures forward progress.

When icanon and the read buffer does not contain newlines and the
normalized 'room' value is 0, then overflow and room are reset to 1,
so that the i/o loop will process the next input char normally
(except for parity errors which are ignored). Thus, erasures, signalling
chars, 7-bit mode, etc. will continue to be handled properly.

If the input char processed was not a line termination char, then
the canon_head index will not have advanced, so the normalized 'room'
value will now be -1 and 'overflow' will be set, which indicates the
read_head can safely be reset, effectively erasing the last char
processed.

If the input char processed was a line termination, then the
canon_head index will have advanced, so 'overflow' is cleared to 0,
the read_head is not reset, and 'room' is cleared to 0, which exits
the i/o loop (because the reader now have input available to read
which ensures forward progress).

Note that it is possible for a line termination to be received, and
for the reader to copy the line to the user buffer before the
input i/o loop is ready to process the next input char. This is
why the i/o loop recomputes the room/overflow state with every
input char while handling overflow.

Finally, if the input data was processed without receiving
a line termination (so that overflow is still set), the pty
driver must receive a write wakeup. A pty writer may be waiting
to write more data in n_tty_write() but without unthrottling
here that wakeup will not arrive, and forward progress will halt.
(Normally, the pty writer is woken when the reader reads data out
of the buffer and more space become available).
Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit fb5ef9e7)
Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      49118e22
  3. 20 Apr, 2015 1 commit
  5. 17 Apr, 2015 25 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7