Skip to content

L
linux
Switch branch/tag
  1. 10 May, 2016 1 commit
  3. 09 May, 2016 2 commits
    • Marek Szyprowski's avatar
      Input: max8997-haptic - fix NULL pointer dereference · 6ae645d5
      Marek Szyprowski authored 
      NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.

The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
	[0000009c] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
	(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
	(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
	(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
	(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
	(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
	(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
	(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
	(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
	(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)
Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: 104594b0 ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      6ae645d5
    • Chris Diamand's avatar
      Input: byd - update copyright header · 82aaa086
      Chris Diamand authored 
      As pointed out by Richard, the changes to the comment got missed off
the absolute mode patch somehow.
Signed-off-by: default avatarChris Diamand <chris@diamand.org>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      82aaa086
  5. 25 Apr, 2016 3 commits
  7. 20 Apr, 2016 2 commits
  9. 19 Apr, 2016 2 commits
  11. 17 Apr, 2016 2 commits
  13. 06 Apr, 2016 1 commit
  15. 05 Apr, 2016 1 commit
    • Silvan Jegen's avatar
      Input: xpad - add Mad Catz FightStick TE 2 VID/PID · d63b0f0c
      Silvan Jegen authored 
      This adds the VID/PID combination for the Xbox One version of the Mad
Catz FightStick TE 2.

The functionality that this provides is about on par with what the
Windows drivers for the stick manage to deliver.

What works:
- Digital stick
- 6 main buttons
- Xbox button
- The two buttons on the back
- The locking buttons (preventing accidental Xbox button press)

What doesn't work:
- Two of the main buttons (don't work on Windows either)
- The "Haptic" button setting does not have an effect (not sure if it
  works on Windows)

I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
there was no practical difference with or without. The FightStick does
not have triggers though so adding it makes sense.
Signed-off-by: default avatarSilvan Jegen <s.jegen@gmail.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      d63b0f0c
  17. 31 Mar, 2016 1 commit
  19. 24 Mar, 2016 2 commits
  21. 18 Mar, 2016 3 commits
  23. 17 Mar, 2016 1 commit
  25. 16 Mar, 2016 1 commit
  27. 15 Mar, 2016 3 commits
    • Arnd Bergmann's avatar
      ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props · 4d2508a5
      Arnd Bergmann authored 
      gcc-6.0 notices that the use of the property_entry in this file that
was recently introduced cannot work right, as we initialize the wrong
field:

raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_steps, },
   ^~~~~~~~~~~~
raumfeld.c:389:3: error: the address of 'raumfeld_rotary_encoder_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_axis, },
   ^~~~~~~~~~~~
raumfeld.c:391:3: error: the address of 'raumfeld_rotary_encoder_relative_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_relative_axis, },
   ^~~~~~~~~~~~

The problem appears to stem from relying on an old definition of
'struct property', but it has changed several times since the code
could have last been correct.

This changes the code to use the PROPERTY_ENTRY_INTEGER() macro instead,
which works fine for the current definition and is a safer way of doing
the initialization.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Fixes: a9e340dc ("Input: rotary_encoder - move away from platform data structure")
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      4d2508a5
    • Dmitry Torokhov's avatar
      Merge tag 'v4.5' into next · 245f0db0
      Dmitry Torokhov authored 
      Merge with Linux 4.5 to get PROPERTY_ENTRY_INTEGER() that is needed to
fix pxa/raumfeld rotary encoder properties.
      245f0db0
    • Dan Carpenter's avatar
      Input: synaptics-rmi4 - using logical instead of bitwise AND · 24672bdf
      Dan Carpenter authored 
      There is a typo so we have && instead of &.

Fixes: ff8f8370 ('Input: synaptics-rmi4 - add support for 2D sensors and F11')
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Acked-by: default avatarAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      24672bdf
  29. 14 Mar, 2016 2 commits
  31. 13 Mar, 2016 8 commits
  33. 12 Mar, 2016 5 commits
    • Ming Lei's avatar
      block: don't optimize for non-cloned bio in bio_get_last_bvec() · 90d0f0f1
      Ming Lei authored 
      For !BIO_CLONED bio, we can use .bi_vcnt safely, but it
doesn't mean we can just simply return .bi_io_vec[.bi_vcnt - 1]
because the start postion may have been moved in the middle of
the bvec, such as splitting in the middle of bvec.

Fixes: 7bcd79ac(block: bio: introduce helpers to get the 1st and last bvec)
Cc: stable@vger.kernel.org
Reported-by: default avatarKent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      90d0f0f1
    • Matt Fleming's avatar
      x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables · 452308de
      Matt Fleming authored 
      Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.

Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.

For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:

  7d68dc3f ("x86, efi: Do not reserve boot services regions within reserved areas")

That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.

Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.

For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().

The event handler for this driver looks like this,

  sub rsp,0x28
  lea rdx,[rip+0x2445] # 0xaa948720
  mov ecx,0x4
  call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
  mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
  xor eax,eax
  mov BYTE PTR [r11+0x1],0x1
  add rsp,0x28
  ret

Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.

The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: default avatarAlexis Murzeau <amurzeau@gmail.com>
Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      452308de
    • Borislav Petkov's avatar
      x86/fpu: Fix eager-FPU handling on legacy FPU machines · 6e686709
      Borislav Petkov authored 
      i486 derived cores like Intel Quark support only the very old,
legacy x87 FPU (FSAVE/FRSTOR, CPUID bit FXSR is not set), and
our FPU code wasn't handling the saving and restoring there
properly in the 'eagerfpu' case.

So after we made eagerfpu the default for all CPU types:

  58122bf1 x86/fpu: Default eagerfpu=on on all CPUs

these old FPU designs broke. First, Andy Shevchenko reported a splat:

  WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160

which was us trying to execute FXRSTOR on those machines even though
they don't support it.

After taking care of that, Bryan O'Donoghue reported that a simple FPU
test still failed because we weren't initializing the FPU state properly
on those machines.

Take care of all that.
Reported-and-tested-by: default avatarBryan O'Donoghue <pure.logic@nexus-software.ie>
Reported-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yu-cheng <yu-cheng.yu@intel.com>
Link: http://lkml.kernel.org/r/20160311113206.GD4312@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6e686709
    • Vladimir Zapolskiy's avatar
      Input: snvs_pwrkey - fix returned value check of syscon_regmap_lookup_by_phandle() · 9979c1c7
      Vladimir Zapolskiy authored 
      On error syscon_regmap_lookup_by_phandle() returns ERR_PTR() value,
which makes a check for NULL invalid and may lead to oops on error
path.
Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      9979c1c7
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20160311' of git://git.infradead.org/linux-mtd · 03c668a9
      Linus Torvalds authored 
      Pull MTD fixes from Brian Norris:
 "Late MTD fix for v4.5:

   - A simple error code handling fix for the NAND ECC test; this was a
     regression in v4.5-rc1

   - A MAINTAINERS update, which might as well go in ASAP"

* tag 'for-linus-20160311' of git://git.infradead.org/linux-mtd:
  MAINTAINERS: add a maintainer for the NAND subsystem
  mtd: nand: tests: fix regression introduced in mtd_nandectest
      03c668a9
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7