1. 04 1月, 2022 2 次提交
    • H
      ACPI / x86: Introduce an acpi_quirk_skip_acpi_ac_and_battery() helper · 57a18322
      Hans de Goede 提交于
      Some x86 ACPI boards have broken AC and battery ACPI devices in their ACPI
      tables. This is often tied to these devices using certain PMICs where the
      factory OS image seems to be using native charger and fuel-gauge drivers
      instead.
      
      So far both the AC and battery drivers have almost identical checks for
      these PMICs including both of them having a DMI based mechanism to force
      usage of the ACPI AC and battery drivers on some boards even though one
      of these PMICs is present, with the same 2 boards listed in both driver's
      DMI tables for this.
      
      The only difference is that the AC driver checks for 2 PMICs and the
      battery driver only for one. This has grown this way because the other
      (Whiskey Cove) PMIC is only used on a few boards (3 known boards) and
      although some of these do have non working ACPI battery devices, their
      _STA method always returns 0, but that really should not be relied on.
      
      This patch factors out the shared checks into a new
      acpi_quirk_skip_acpi_ac_and_battery() helper and moves the AC and
      battery drivers over to this new helper.
      
      Note the DMI table is shared with acpi_quirk_skip_i2c_client_enumeration()
      and acpi_quirk_skip_serdev_enumeration(), because boards needing DMI quirks
      for either of these typically also have broken AC and battery ACPI devices.
      
      The ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY quirk is not set yet on boards
      already in this DMI table, to avoid introducing any functional changes
      in this refactoring patch.
      
      Besided sharing the code between the AC and battery drivers this
      refactoring also moves this quirk handling to under #ifdef CONFIG_X86,
      removing this x86 specific code from non x86 ACPI builds.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      57a18322
    • R
      Merge branch 'acpi-scan' into acpi-x86 · 8e0feb25
      Rafael J. Wysocki 提交于
      Merge recent device enumeration changes to satisfy dependencies.
      8e0feb25
  2. 31 12月, 2021 4 次提交
    • H
      serdev: Do not instantiate serdevs on boards with known bogus DSDT entries · 0890186a
      Hans de Goede 提交于
      x86 ACPI devices which ship with only Android as their factory image use
      older kernels which do not yet support ACPI serdev enumeration, as such
      the serdev information in their ACPI tables is not reliable.
      
      For example on the Asus ME176C tablet the serdev describing the Bluetooth
      HCI points to the serdev_controller connected to the GPS and the other way
      around.
      
      Use the new acpi_quirk_skip_serdev_enumeration() helper to identify
      known boards with this issue and then either abort adding the serdev
      controller (creating a tty cdev instead) or only create the controller
      leaving the instantation of the serdev itself up to platform code.
      
      In the case where only the serdev controller is created the necessary
      serdevs will instead be instantiated by the
      drivers/platform/x86/x86-android-tablets.c kernel module.
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0890186a
    • H
      i2c: acpi: Do not instantiate I2C-clients on boards with known bogus DSDT entries · a6e1445c
      Hans de Goede 提交于
      x86 ACPI devices which ship with only Android as their factory image
      usually declare a whole bunch of bogus I2C devices in their ACPI tables.
      
      Instantiating I2C clients for these bogus devices causes various issues,
      e.g. GPIO/IRQ resource conflicts because sometimes drivers do bind to them.
      The Android x86 kernel fork shipped on these devices has some special code
      to remove these bogus devices, instead of just fixing the DSDT <sigh>.
      
      Use the new acpi_quirk_skip_i2c_client_enumeration() helper to identify
      known boards / acpi devices with this issue, and skip enumerating these.
      
      Note these boards typically do actually have I2C devices, just
      different ones then the ones described in their DSDT. The devices
      which are actually present are manually instantiated by the
      drivers/platform/x86/x86-android-tablets.c kernel module.
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NWolfram Sang <wsa@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a6e1445c
    • H
      ACPI / x86: Add acpi_quirk_skip_[i2c_client|serdev]_enumeration() helpers · 35f9e773
      Hans de Goede 提交于
      x86 ACPI boards which ship with only Android as their factory image usually
      declare a whole bunch of bogus I2C devs in their ACPI tables and sometimes
      there are issues with serdev devices on these boards too, e.g. the resource
      points to the wrong serdev_controller.
      
      Instantiating I2C / serdev devs for these bogus devs causes various issues,
      e.g. GPIO/IRQ resource conflicts because sometimes drivers do bind to them.
      The Android x86 kernel fork shipped on these devices has some special code
      to remove the bogus I2C clients (and serdevs are ignored completely).
      
      Introduce acpi_quirk_skip_i2c_client_enumeration() and
      acpi_quirk_skip_serdev_enumeration() helpers. Which can be used by the I2C/
      serdev code to skip instantiating any I2C or serdev devs on broken boards.
      
      These 2 helpers are added to drivers/acpi/x86/utils.c so that the DMI table
      can be shared between the I2C and serdev code.
      
      Note these boards typically do actually have I2C and serdev devices, just
      different ones then the ones described in their DSDT. The devices which
      are actually present are manually instantiated by the
      drivers/platform/x86/x86-android-tablets.c kernel module.
      
      The new helpers are only build if CONFIG_X86_ANDROID_TABLETS is enabled,
      otherwise they are empty stubs to not unnecessarily grow the kernel size.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      35f9e773
    • H
      ACPI: scan: Create platform device for BCM4752 and LNV4752 ACPI nodes · f85196bd
      Hans de Goede 提交于
      BCM4752 and LNV4752 ACPI nodes describe a Broadcom 4752 GPS module
      attached to an UART of the system.
      
      The GPS modules talk a custom protocol which only works with a closed-
      source Android gpsd daemon which knows this protocol.
      
      The ACPI nodes also describe GPIOs to turn the GPS on/off these are
      handled by the net/rfkill/rfkill-gpio.c code. This handling predates the
      addition of enumeration of ACPI instantiated serdevs to the kernel and
      was broken by that addition, because the ACPI scan code now no longer
      instantiates platform_device-s for these nodes.
      
      Rename the i2c_multi_instantiate_ids HID list to ignore_serial_bus_ids
      and add the BCM4752 and LNV4752 HIDs, so that rfkill-gpio gets
      a platform_device to bind to again; and so that a tty cdev for gpsd
      gets created for these.
      
      Fixes: e361d1f8 ("ACPI / scan: Fix enumeration for special UART devices")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f85196bd
  3. 18 12月, 2021 2 次提交
  4. 02 12月, 2021 7 次提交
  5. 29 11月, 2021 7 次提交
  6. 28 11月, 2021 16 次提交
  7. 27 11月, 2021 2 次提交
    • Y
      io_uring: Fix undefined-behaviour in io_issue_sqe · f6223ff7
      Ye Bin 提交于
      We got issue as follows:
      ================================================================================
      UBSAN: Undefined behaviour in ./include/linux/ktime.h:42:14
      signed integer overflow:
      -4966321760114568020 * 1000000000 cannot be represented in type 'long long int'
      CPU: 1 PID: 2186 Comm: syz-executor.2 Not tainted 4.19.90+ #12
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78
       show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x170/0x1dc lib/dump_stack.c:118
       ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161
       handle_overflow+0x188/0x1dc lib/ubsan.c:192
       __ubsan_handle_mul_overflow+0x34/0x44 lib/ubsan.c:213
       ktime_set include/linux/ktime.h:42 [inline]
       timespec64_to_ktime include/linux/ktime.h:78 [inline]
       io_timeout fs/io_uring.c:5153 [inline]
       io_issue_sqe+0x42c8/0x4550 fs/io_uring.c:5599
       __io_queue_sqe+0x1b0/0xbc0 fs/io_uring.c:5988
       io_queue_sqe+0x1ac/0x248 fs/io_uring.c:6067
       io_submit_sqe fs/io_uring.c:6137 [inline]
       io_submit_sqes+0xed8/0x1c88 fs/io_uring.c:6331
       __do_sys_io_uring_enter fs/io_uring.c:8170 [inline]
       __se_sys_io_uring_enter fs/io_uring.c:8129 [inline]
       __arm64_sys_io_uring_enter+0x490/0x980 fs/io_uring.c:8129
       invoke_syscall arch/arm64/kernel/syscall.c:53 [inline]
       el0_svc_common+0x374/0x570 arch/arm64/kernel/syscall.c:121
       el0_svc_handler+0x190/0x260 arch/arm64/kernel/syscall.c:190
       el0_svc+0x10/0x218 arch/arm64/kernel/entry.S:1017
      ================================================================================
      
      As ktime_set only judge 'secs' if big than KTIME_SEC_MAX, but if we pass
      negative value maybe lead to overflow.
      To address this issue, we must check if 'sec' is negative.
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Link: https://lore.kernel.org/r/20211118015907.844807-1-yebin10@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      f6223ff7
    • Y
      io_uring: fix soft lockup when call __io_remove_buffers · 1d0254e6
      Ye Bin 提交于
      I got issue as follows:
      [ 567.094140] __io_remove_buffers: [1]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
      [  594.360799] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
      [  594.364987] Modules linked in:
      [  594.365405] irq event stamp: 604180238
      [  594.365906] hardirqs last  enabled at (604180237): [<ffffffff93fec9bd>] _raw_spin_unlock_irqrestore+0x2d/0x50
      [  594.367181] hardirqs last disabled at (604180238): [<ffffffff93fbbadb>] sysvec_apic_timer_interrupt+0xb/0xc0
      [  594.368420] softirqs last  enabled at (569080666): [<ffffffff94200654>] __do_softirq+0x654/0xa9e
      [  594.369551] softirqs last disabled at (569080575): [<ffffffff913e1d6a>] irq_exit_rcu+0x1ca/0x250
      [  594.370692] CPU: 2 PID: 108 Comm: kworker/u32:5 Tainted: G            L    5.15.0-next-20211112+ #88
      [  594.371891] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
      [  594.373604] Workqueue: events_unbound io_ring_exit_work
      [  594.374303] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50
      [  594.375037] Code: 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 55 f5 55 fd 48 89 ef e8 ed a7 56 fd 80 e7 02 74 06 e8 43 13 7b fd fb bf 01 00 00 00 <e8> f8 78 474
      [  594.377433] RSP: 0018:ffff888101587a70 EFLAGS: 00000202
      [  594.378120] RAX: 0000000024030f0d RBX: 0000000000000246 RCX: 1ffffffff2f09106
      [  594.379053] RDX: 0000000000000000 RSI: ffffffff9449f0e0 RDI: 0000000000000001
      [  594.379991] RBP: ffffffff9586cdc0 R08: 0000000000000001 R09: fffffbfff2effcab
      [  594.380923] R10: ffffffff977fe557 R11: fffffbfff2effcaa R12: ffff8881b8f3def0
      [  594.381858] R13: 0000000000000246 R14: ffff888153a8b070 R15: 0000000000000000
      [  594.382787] FS:  0000000000000000(0000) GS:ffff888399c00000(0000) knlGS:0000000000000000
      [  594.383851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  594.384602] CR2: 00007fcbe71d2000 CR3: 00000000b4216000 CR4: 00000000000006e0
      [  594.385540] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  594.386474] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  594.387403] Call Trace:
      [  594.387738]  <TASK>
      [  594.388042]  find_and_remove_object+0x118/0x160
      [  594.389321]  delete_object_full+0xc/0x20
      [  594.389852]  kfree+0x193/0x470
      [  594.390275]  __io_remove_buffers.part.0+0xed/0x147
      [  594.390931]  io_ring_ctx_free+0x342/0x6a2
      [  594.392159]  io_ring_exit_work+0x41e/0x486
      [  594.396419]  process_one_work+0x906/0x15a0
      [  594.399185]  worker_thread+0x8b/0xd80
      [  594.400259]  kthread+0x3bf/0x4a0
      [  594.401847]  ret_from_fork+0x22/0x30
      [  594.402343]  </TASK>
      
      Message from syslogd@localhost at Nov 13 09:09:54 ...
      kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
      [  596.793660] __io_remove_buffers: [2099199]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
      
      We can reproduce this issue by follow syzkaller log:
      r0 = syz_io_uring_setup(0x401, &(0x7f0000000300), &(0x7f0000003000/0x2000)=nil, &(0x7f0000ff8000/0x4000)=nil, &(0x7f0000000280)=<r1=>0x0, &(0x7f0000000380)=<r2=>0x0)
      sendmsg$ETHTOOL_MSG_FEATURES_SET(0xffffffffffffffff, &(0x7f0000003080)={0x0, 0x0, &(0x7f0000003040)={&(0x7f0000000040)=ANY=[], 0x18}}, 0x0)
      syz_io_uring_submit(r1, r2, &(0x7f0000000240)=@IORING_OP_PROVIDE_BUFFERS={0x1f, 0x5, 0x0, 0x401, 0x1, 0x0, 0x100, 0x0, 0x1, {0xfffd}}, 0x0)
      io_uring_enter(r0, 0x3a2d, 0x0, 0x0, 0x0, 0x0)
      
      The reason above issue  is 'buf->list' has 2,100,000 nodes, occupied cpu lead
      to soft lockup.
      To solve this issue, we need add schedule point when do while loop in
      '__io_remove_buffers'.
      After add  schedule point we do regression, get follow data.
      [  240.141864] __io_remove_buffers: [1]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
      [  268.408260] __io_remove_buffers: [1]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
      [  275.899234] __io_remove_buffers: [2099199]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
      [  296.741404] __io_remove_buffers: [1]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
      [  305.090059] __io_remove_buffers: [2099199]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
      [  325.415746] __io_remove_buffers: [1]start ctx=0xffff8881b92d1000 bgid=65533 buf=0xffff8881a17d8f00
      [  333.160318] __io_remove_buffers: [2099199]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
      ...
      
      Fixes:8bab4c09("io_uring: allow conditional reschedule for intensive iterators")
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Link: https://lore.kernel.org/r/20211122024737.2198530-1-yebin10@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      1d0254e6