Commits · 0day-ci/linux

The ACPI device with CLSA0100 is a sound card with multiple instances of CS35L41. We add an ID to the I2C multi instantiate list to enumerate all I2C slaves correctly. Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

Add support for CS35L41 using a new separated driver that can be used in all upcoming designs Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

ASoC and HDA will use the same registers to configure internal boost for the device Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

ASoC and HDA will use the same register to set channels for the device Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

ASoC and HDA systems require the same errata patches, so move it to the shared code using a function the correctly applies the patches by revision Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

ASoC and HDA systems for all revisions of CS35L41 will benefit from having this initialization, so add it to reg_sequence of each revision Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

ASoC and HDA will do the same cs35l41_otp_unpack, so move it to shared code Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

Both ASoC and HDA system have to initialize the arrays of supplies in the same way, so create a function for that in shared code Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

Move regmap configs to external include so CS35L41 HDA driver can re-use it. Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

To support CS35L41 in HDA systems the HDA driver for CS35L41 would have to duplicate some functions that already exist on ASoC driver So instead of duplicate the code, use the new lib source as a shared resource for both ASoC and HDA Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

Higher speeds are only supported when PLL is enabled, but the current driver doesn't enable PLL outside of stream use cases, so better to set the lowest SPI speed accepted by the entire device. Move the current frequency set to the spi sub-driver so the whole device can benefit from that speed. spi-max-frequency property could be used, but ACPI systems don't support it, so by setting it in the spi sub-driver probe both Device Trees and ACPI systems are supported. Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…alloc() - fixup3 Due to cd06ab2 ("drm/locking: add backtrace for locking contended locks without backoff") landing recently to -next adding a new stack depot user in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriate call to stack_depot_init() there as well. Link: https://lkml.kernel.org/r/2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…alloc() - fixup On FLATMEM, we call page_ext_init_flatmem_late() just before kmem_cache_init() which means stack_depot_init() (called by page owner init) will not recognize properly it should use kvmalloc() and not memblock_alloc(). memblock_alloc() will also not issue a warning and return a block memory that can be invalid and cause kernel page fault when saving stacks, as reported by the kernel test robot [1]. Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() so that slab_is_available() is true during stack_depot_init(). SPARSEMEM doesn't have this issue, as it doesn't do page_ext_init_flatmem_late(), but a different page_ext_init() even later in the boot process. Thanks to Mike Rapoport for pointing out the FLATMEM init ordering issue. While at it, also actually resolve a checkpatch warning in stack_depot_init() from DRM CI, which was supposed to be in the original patch already. [1] https://lore.kernel.org/all/20211014085450.GC18719@xsang-OptiPlex-9020/ Link: https://lkml.kernel.org/r/6abd9213-19a9-6d58-cedc-2414386d2d81@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: kernel test robot <oliver.sang@intel.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

There is a spelling mistake of the work allocation so fix this and re-phrase the message to make it easier to read. Link: https://lkml.kernel.org/r/20211015104159.11282-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…alloc() Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated from memblock, even if stack depot ends up not actually used. The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit. This is fine for use-cases such as KASAN which is also a config option and has overhead on its own. But it's an issue for functionality that has to be actually enabled on boot (page_owner) or depends on hardware (GPU drivers) and thus the memory might be wasted. This was raised as an issue [1] when attempting to add stackdepot support for SLUB's debug object tracking functionality. It's common to build kernels with CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or create only specific kmem caches with debugging for testing purposes. It would thus be more efficient if stackdepot's table was allocated only when actually going to be used. This patch thus makes the allocation (and whole stack_depot_init() call) optional: - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN select this flag. - Other users have to call stack_depot_init() as part of their own init when it's determined that stack depot will actually be used. This may depend on both config and runtime conditions. Convert current users which are page_owner and several in the DRM subsystem. Same will be done for SLUB later. - Because the init might now be called after the boot-time memblock allocation has given all memory to the buddy allocator, change stack_depot_init() to allocate stack_table with kvmalloc() when memblock is no longer available. Also handle allocation failure by disabling stackdepot (could have theoretically happened even with memblock allocation previously), and don't unnecessarily align the memblock allocation to its own size anymore. [1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/ Link: https://lkml.kernel.org/r/20211013073005.11351-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Marco Elver <elver@google.com> # stackdepot Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

DEFINE_PROC_SHOW_ATTRIBUTE() can be used here to simplify the code. Link: https://lkml.kernel.org/r/20211101093518.86845-5-songmuchun@bytedance.com Signed-off-by: Muchun Song <songmuchun@bytedance.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexey Gladkov <gladkov.alexey@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

There are no users of PDE_DATA() and we do not need it anymore, just remove it. Link: https://lkml.kernel.org/r/20211101093518.86845-4-songmuchun@bytedance.com Signed-off-by: Muchun Song <songmuchun@bytedance.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexey Gladkov <gladkov.alexey@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Since the user can get their private data by inode->i_private, so replace all PDE_DATA(inode) with inode->i_private. Finally we can remove PDE_DATA() completely. Link: https://lkml.kernel.org/r/20211101093518.86845-3-songmuchun@bytedance.com Signed-off-by: Muchun Song <songmuchun@bytedance.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexey Gladkov <gladkov.alexey@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Patch series "remove PDE_DATA()". I found a bug [1] some days ago, which is because we want to use inode->i_private to pass user private data. However, this is wrong on proc fs. We provide a specific function PDE_DATA() to get user private data. Actually, we can hide this detail by storing PDE()->data into inode->i_private and removing PDE_DATA() completely. The user could use inode->i_private to get user private data just like debugfs does. This series is trying to remove PDE_DATA(). [1] https://lore.kernel.org/lkml/20211029032638.84884-1-songmuchun@bytedance.com/ This patch (of 4): PDE_DATA(inode) is introduced to get user private data and hide the layout of struct proc_dir_entry. The inode->i_private is used to do the same thing as well. Save a copy of user private data to inode-> i_private when proc inode is allocated. This means the user also can get their private data by inode->i_private. Link: https://lkml.kernel.org/r/20211101093518.86845-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20211101093518.86845-2-songmuchun@bytedance.com Signed-off-by: Muchun Song <songmuchun@bytedance.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexey Gladkov <gladkov.alexey@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…git/krisman/unicode.git # Conflicts: # fs/f2fs/sysfs.c

# Conflicts: # arch/parisc/include/asm/bitops.h # drivers/dma/ti/edma.c

…che.git

…cxl/cxl.git

…git/mani/mhi.git

…git/mtd/linux.git

…git/srini/nvmem.git

…/git/johan/gnss.git

…rnel/git/gustavoars/linux.git

…rnel/git/kees/linux.git

…/kernel/git/kees/linux.git

Commits on Nov 23, 2021