Re: [PATCH v2 2/3] ARM: dts: add Netronix E60K02 board common file

[Andreas Kemnade]

Hi Jonathan,

On Mon, 7 Oct 2019 00:38:48 +0200
Jonathan Neuschäfer  wrote:

> Thanks for CCing me on this patchset. Nice to see more e-book reader
> related work!
> 
> A few comments and questions below.
> 
> On Mon, Sep 30, 2019 at 09:43:31PM +0200, Andreas Kemnade wrote:
> > The Netronix board E60K02 can be found some several Ebook-Readers,
> > at least the Kobo Clara HD and the Tolino Shine 3. The board
> > is equipped with different SoCs requiring different pinmuxes.  
> 
> Do I understand it correctly that i.MX6SL and i.MX6SLL are pin-
> compatible so we can use the same pin numbers and GPIO handles in the
> DT?
> 
Yes, for that purpose yes, The i.MX6SL has more functions than the i.MX6SLL,
which you will of course not find on the SLL pins.

> > +   leds {
> > +   compatible = "gpio-leds";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_led>;
> > +
> > +   GLED {  
> 
> What does "GLED" mean? It's not obvious to me.
> What user-visible purpose does this LED have, or where is it on the
> board?
> 
It is on the power key. So probably we could have "power" in its name.
GLED is just the name in vendors uboot and kernel.

I use that led also as an output in uboot to have multiboot between
vendor system, vendor kernel +debian system and patched mainline + debian 
system.

> > +   gpios = < 7 GPIO_ACTIVE_LOW>;
> > +   linux,default-trigger = "timer";
> > +   };
> > +   };
> > +
> > +   memory {
> > +   reg = <0x8000 0x8000>;  
> 
> 2 GiB of memory?
> 
Well, 512MByte. Seems that uboot overwrites that. But we should use the correct
value here.

> > +   /* Core3_3V3 */  
> 
> What are these labels (Core3_3V3, Core4_1V2, etc.)?
>
I have taken then from the tolino board file. Probably they are netnames
of the pcb but not the names of the regulators in the pmic.
 
> > +   dcdc2_reg: DCDC2 {
> > +   regulator-name = "DCDC2";
> > +   regulator-always-on;
> > +   regulator-boot-on;
> > +   regulator-state-mem {
> > +   regulator-on-in-suspend;
> > +   regulator-suspend-max-microvolt = 
> > <330>;
> > +   regulator-suspend-min-microvolt = 
> > <330>;
> > +   };
> > +   };  
> 
Regards,
Andreas


pgp9H5RqXMyzs.pgp
Description: OpenPGP digital signature

Re: [PATCH 01/11] iomap: add tracing for the readpage / readpages

[Christoph Hellwig]

On Sun, Oct 06, 2019 at 03:43:24PM -0700, Darrick J. Wong wrote:
> > +iomap-y+= trace.o \
> 
> I think this patch is missing fs/iomap/trace.c ?

It does.  The file is in my tree, but I never did a git-add for it..

[PATCH V4 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Anshuman Khandual]

This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various level are
all allocated from system memory with required alignments. If memory pages
with required size and alignment could not be allocated, then all depending
individual tests are skipped.

Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: linux-snps-...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org

Suggested-by: Catalin Marinas 
Signed-off-by: Christophe Leroy 
Tested-by: Christophe Leroy#PPC32
Signed-off-by: Anshuman Khandual 
---
 arch/x86/include/asm/pgtable_64_types.h |   2 +
 mm/Kconfig.debug|  15 +
 mm/Makefile |   1 +
 mm/arch_pgtable_test.c  | 440 
 4 files changed, 458 insertions(+)
 create mode 100644 mm/arch_pgtable_test.c

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 52e5f5f2240d..b882792a3999 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
 #define pgtable_l5_enabled() 0
 #endif /* CONFIG_X86_5LEVEL */
 
+#define mm_p4d_folded(mm) (!pgtable_l5_enabled())
+
 extern unsigned int pgdir_shift;
 extern unsigned int ptrs_per_p4d;
 
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 327b3ebf23bf..683131b1ee7d 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -117,3 +117,18 @@ config DEBUG_RODATA_TEST
 depends on STRICT_KERNEL_RWX
 ---help---
   This option enables a testcase for the setting rodata read-only.
+
+config DEBUG_ARCH_PGTABLE_TEST
+   bool "Test arch page table helpers for semantics compliance"
+   depends on MMU
+   depends on DEBUG_KERNEL
+   depends on !(ARM || IA64)
+   help
+ This options provides a kernel module which can be used to test
+ architecture page table helper functions on various platform in
+ verifying if they comply with expected generic MM semantics. This
+ will help architectures code in making sure that any changes or
+ new additions of these helpers will still conform to generic MM
+ expected semantics.
+
+ If unsure, say N.
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..bb572c5aa8c5 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
 obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
 obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
 obj-$(CONFIG_DEBUG_RODATA_TEST) += rodata_test.o
+obj-$(CONFIG_DEBUG_ARCH_PGTABLE_TEST) += arch_pgtable_test.o
 obj-$(CONFIG_PAGE_OWNER) += page_owner.o
 obj-$(CONFIG_CLEANCACHE) += cleancache.o
 obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
new file mode 100644
index ..2942a0484d63
--- /dev/null
+++ b/mm/arch_pgtable_test.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This kernel module validates architecture page table helpers &
+ * accessors and helps in verifying their continued compliance with
+ * generic MM semantics.
+ *
+ * Copyright (C) 2019 ARM Ltd.
+ *
+ * Author: Anshuman Khandual 
+ */
+#define pr_fmt(fmt) "arch_pgtable_test: %s " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Basic operations
+ *
+ * mkold(entry)= An old and not a young entry
+ * mkyoung(entry)  = A young and not an old entry
+ * mkdirty(entry)  = A dirty and not a clean entry
+ * mkclean(entry)  = A clean and not a dirty entry
+ * mkwrite(entry)  = A write and not a write protected entry
+ * 

[PATCH V4 1/2] mm/hugetlb: Make alloc_gigantic_page() available for general use

[Anshuman Khandual]

alloc_gigantic_page() implements an allocation method where it scans over
various zones looking for a large contiguous memory block which could not
have been allocated through the buddy allocator. A subsequent patch which
tests arch page table helpers needs such a method to allocate PUD_SIZE
sized memory block. In the future such methods might have other use cases
as well. So alloc_gigantic_page() has been split carving out actual memory
allocation method and made available via new alloc_gigantic_page_order().

Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Mike Kravetz 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: linux-snps-...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 include/linux/hugetlb.h |  9 +
 mm/hugetlb.c| 24 ++--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 53fc34f930d0..cc50d5ad4885 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -299,6 +299,9 @@ static inline bool is_file_hugepages(struct file *file)
 }
 
 
+struct page *
+alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
+ int nid, nodemask_t *nodemask);
 #else /* !CONFIG_HUGETLBFS */
 
 #define is_file_hugepages(file)false
@@ -310,6 +313,12 @@ hugetlb_file_setup(const char *name, size_t size, 
vm_flags_t acctflag,
return ERR_PTR(-ENOSYS);
 }
 
+static inline struct page *
+alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
+ int nid, nodemask_t *nodemask)
+{
+   return NULL;
+}
 #endif /* !CONFIG_HUGETLBFS */
 
 #ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ef37c85423a5..3fb81252f52b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1112,10 +1112,9 @@ static bool zone_spans_last_pfn(const struct zone *zone,
return zone_spans_pfn(zone, last_pfn);
 }
 
-static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
+struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
int nid, nodemask_t *nodemask)
 {
-   unsigned int order = huge_page_order(h);
unsigned long nr_pages = 1 << order;
unsigned long ret, pfn, flags;
struct zonelist *zonelist;
@@ -1151,6 +1150,14 @@ static struct page *alloc_gigantic_page(struct hstate 
*h, gfp_t gfp_mask,
return NULL;
 }
 
+static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
+   int nid, nodemask_t *nodemask)
+{
+   unsigned int order = huge_page_order(h);
+
+   return alloc_gigantic_page_order(order, gfp_mask, nid, nodemask);
+}
+
 static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
 static void prep_compound_gigantic_page(struct page *page, unsigned int order);
 #else /* !CONFIG_CONTIG_ALLOC */
@@ -1159,6 +1166,12 @@ static struct page *alloc_gigantic_page(struct hstate 
*h, gfp_t gfp_mask,
 {
return NULL;
 }
+
+struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
+  int nid, nodemask_t *nodemask)
+{
+   return NULL;
+}
 #endif /* CONFIG_CONTIG_ALLOC */
 
 #else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE */
@@ -1167,6 +1180,13 @@ static struct page *alloc_gigantic_page(struct hstate 
*h, gfp_t gfp_mask,
 {
return NULL;
 }
+
+struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
+  int nid, nodemask_t *nodemask)
+{
+   return NULL;
+}
+
 static inline void free_gigantic_page(struct page *page, unsigned int order) { 
}
 static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
-- 
2.20.1

[PATCH V4 0/2] mm/debug: Add tests for architecture exported page table helpers

[Anshuman Khandual]

This series adds a test validation for architecture exported page table
helpers. Patch in the series adds basic transformation tests at various
levels of the page table. Before that it exports gigantic page allocation
function from HugeTLB.

This test was originally suggested by Catalin during arm64 THP migration
RFC discussion earlier. Going forward it can include more specific tests
with respect to various generic MM functions like THP, HugeTLB etc and
platform specific tests.

https://lore.kernel.org/linux-mm/20190628102003.ga56...@arrakis.emea.arm.com/

Changes in V4:

- Disable DEBUG_ARCH_PGTABLE_TEST for ARM and IA64 platforms

Changes in V3: 
(https://lore.kernel.org/patchwork/project/lkml/list/?series=411216)

- Changed test trigger from module format into late_initcall()
- Marked all functions with __init to be freed after completion
- Changed all __PGTABLE_PXX_FOLDED checks as mm_pxx_folded()
- Folded in PPC32 fixes from Christophe

Changes in V2:

https://lore.kernel.org/linux-mm/1568268173-31302-1-git-send-email-anshuman.khand...@arm.com/T/#t

- Fixed small typo error in MODULE_DESCRIPTION()
- Fixed m64k build problems for lvalue concerns in pmd_xxx_tests()
- Fixed dynamic page table level folding problems on x86 as per Kirril
- Fixed second pointers during pxx_populate_tests() per Kirill and Gerald
- Allocate and free pte table with pte_alloc_one/pte_free per Kirill
- Modified pxx_clear_tests() to accommodate s390 lower 12 bits situation
- Changed RANDOM_NZVALUE value from 0xbe to 0xff
- Changed allocation, usage, free sequence for saved_ptep
- Renamed VMA_FLAGS as VMFLAGS
- Implemented a new method for random vaddr generation
- Implemented some other cleanups
- Dropped extern reference to mm_alloc()
- Created and exported new alloc_gigantic_page_order()
- Dropped the custom allocator and used new alloc_gigantic_page_order()

Changes in V1:

https://lore.kernel.org/linux-mm/1567497706-8649-1-git-send-email-anshuman.khand...@arm.com/

- Added fallback mechanism for PMD aligned memory allocation failure

Changes in RFC V2:

https://lore.kernel.org/linux-mm/1565335998-22553-1-git-send-email-anshuman.khand...@arm.com/T/#u

- Moved test module and it's config from lib/ to mm/
- Renamed config TEST_ARCH_PGTABLE as DEBUG_ARCH_PGTABLE_TEST
- Renamed file from test_arch_pgtable.c to arch_pgtable_test.c
- Added relevant MODULE_DESCRIPTION() and MODULE_AUTHOR() details
- Dropped loadable module config option
- Basic tests now use memory blocks with required size and alignment
- PUD aligned memory block gets allocated with alloc_contig_range()
- If PUD aligned memory could not be allocated it falls back on PMD aligned
  memory block from page allocator and pud_* tests are skipped
- Clear and populate tests now operate on real in memory page table entries
- Dummy mm_struct gets allocated with mm_alloc()
- Dummy page table entries get allocated with [pud|pmd|pte]_alloc_[map]()
- Simplified [p4d|pgd]_basic_tests(), now has random values in the entries

Original RFC V1:

https://lore.kernel.org/linux-mm/1564037723-26676-1-git-send-email-anshuman.khand...@arm.com/

Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: Mike Kravetz 
Cc: linux-snps-...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org

Anshuman Khandual (2):
  mm/hugetlb: Make alloc_gigantic_page() available for general use
  mm/pgtable/debug: Add test validating architecture page table helpers

 arch/x86/include/asm/pgtable_64_types.h |   2 +
 include/linux/hugetlb.h |   9 +
 mm/Kconfig.debug|  15 +
 mm/Makefile |   1 +
 mm/arch_pgtable_test.c  | 440 
 mm/hugetlb.c|  24 +-
 6 files changed, 489 insertions(+), 2 deletions(-)
 create mode 100644 mm/arch_pgtable_test.c

-- 
2.20.1

Re: [PATCH 3/3] usb: dwc3: Remove dev_err() on platform_get_irq() failure

[Felipe Balbi]

Hi,

Hans de Goede  writes:

> Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to
> platform_get_irq*()"), platform_get_irq() will call dev_err() itself on
> failure, so there is no need for the driver to also do this.
>
> Signed-off-by: Hans de Goede 

Acked-by: Felipe Balbi 

-- 
balbi

Re: [PATCH 2/3] usb: dwc3: Switch to platform_get_irq_byname_optional()

[Felipe Balbi]

Hi,

Hans de Goede  writes:

> The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries
> platform_get_irq_byname() and then falls back to the IRQ at index 0 if
> the platform_get_irq_byname().
>
> In this case we do not want platform_get_irq_byname() to print an error
> on failure, so switch to platform_get_irq_byname_optional() instead which
> does not print an error.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037
> Signed-off-by: Hans de Goede 

Acked-by: Felipe Balbi 

-- 
balbi

Re: [PATCH RESEND v8 0/4] Make IPA use PM_EM

[Daniel Lezcano]

Hi Quentin,

the series does no longer apply, do you think it is possible to give it
a respin?



On 11/09/2019 15:03, Quentin Perret wrote:
> Re-sending this from an email address I can access. For a cover letter,
> see:
> https://lore.kernel.org/lkml/20190812084235.21440-1-quentin.per...@arm.com/
> 
> Changes in v8:
>  - Fixed checkpatch errors (Rui)
> 
> Changes in v7
>  - Added patch 02/04 to fix the build error reported by the kbuild bot
> 
> Changes in v6
>  - Added Daniel's and Viresh's Acked-by to all patches
> 
> Changes in v5:
>  - Changed patch 02 to guard IPA-specific code in cpu_cooling.c with
>appropriate ifdefery (Daniel)
>  - Rebased on 5.2-rc2
> 
> Changes in v4:
>  - Added Viresh's Acked-by to all 3 patches
>  - Improved commit message of patch 3/3 to explain how it has no
>functional impact on existing users (Eduardo)
> 
> Changes in v3:
>  - Changed warning message for unordered tables to something more
>explicit (Viresh)
>  - Changed WARN() into a pr_err() for consistency
> 
> Changes in v2:
>  - Fixed patch 01/03 to actually enable CONFIG_ENERGY_MODEL
>  - Added "depends on ENERGY_MODEL" to IPA (Daniel)
>  - Added check to bail out if the freq table is unsorted (Viresh)
> 
> 
> Quentin Perret (4):
>   arm64: defconfig: Enable CONFIG_ENERGY_MODEL
>   PM / EM: Declare EM data types unconditionally
>   thermal: cpu_cooling: Make the power-related code depend on IPA
>   thermal: cpu_cooling: Migrate to using the EM framework
> 
>  arch/arm64/configs/defconfig  |   1 +
>  drivers/thermal/Kconfig   |   1 +
>  drivers/thermal/cpu_cooling.c | 427 ++
>  include/linux/energy_model.h  |   3 +-
>  4 files changed, 178 insertions(+), 254 deletions(-)
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 2/5] soc: qcom: smd-rpm: Create RPM interconnect proxy child device

[Bjorn Andersson]

On Sun 06 Oct 19:01 PDT 2019, Brian Masney wrote:

> On Thu, Jun 13, 2019 at 06:13:20PM +0300, Georgi Djakov wrote:
> > Register a platform device to handle the communication of bus bandwidth
> > requests with the remote processor. The interconnect proxy device is part
> > of this remote processor (RPM) hardware. Let's create a icc-smd-rpm proxy
> > child device to represent the bus throughput functionality that is provided
> > by the RPM.
> > 
> > Signed-off-by: Georgi Djakov 
> 
> Reviewed-by: Brian Masney 
> Tested-by: Brian Masney  # msm8974
> 
> I think this patch may have fell through the cracks since I don't see
> it in linux-next. The qcs404 patches in this series were merged.
> 

Yes, I was expecting Georgi to pick the entire series through his tree,
but see now that I didn't actually ask Georgi to do so. Sorry about
that.

I picked the this and the dts patch last week, so if it's not in
linux-next yet it should show up in the next one.

Thanks,
Bjorn

> Brian
> 
> > ---
> > 
> > v4:
> > - Return error if platform_device_register_data() fails
> > - Remove platform_set_drvdata() on the child device.
> > 
> > v3:
> > - New patch.
> > 
> >  drivers/soc/qcom/smd-rpm.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> > index fa9dd12b5e39..34cdd638a6c1 100644
> > --- a/drivers/soc/qcom/smd-rpm.c
> > +++ b/drivers/soc/qcom/smd-rpm.c
> > @@ -19,12 +19,14 @@
> >  /**
> >   * struct qcom_smd_rpm - state of the rpm device driver
> >   * @rpm_channel:   reference to the smd channel
> > + * @icc:   interconnect proxy device
> >   * @ack:   completion for acks
> >   * @lock:  mutual exclusion around the send/complete pair
> >   * @ack_status:result of the rpm request
> >   */
> >  struct qcom_smd_rpm {
> > struct rpmsg_endpoint *rpm_channel;
> > +   struct platform_device *icc;
> > struct device *dev;
> >  
> > struct completion ack;
> > @@ -193,6 +195,7 @@ static int qcom_smd_rpm_callback(struct rpmsg_device 
> > *rpdev,
> >  static int qcom_smd_rpm_probe(struct rpmsg_device *rpdev)
> >  {
> > struct qcom_smd_rpm *rpm;
> > +   int ret;
> >  
> > rpm = devm_kzalloc(>dev, sizeof(*rpm), GFP_KERNEL);
> > if (!rpm)
> > @@ -205,11 +208,23 @@ static int qcom_smd_rpm_probe(struct rpmsg_device 
> > *rpdev)
> > rpm->rpm_channel = rpdev->ept;
> > dev_set_drvdata(>dev, rpm);
> >  
> > -   return of_platform_populate(rpdev->dev.of_node, NULL, NULL, 
> > >dev);
> > +   rpm->icc = platform_device_register_data(>dev, "icc_smd_rpm", -1,
> > +NULL, 0);
> > +   if (IS_ERR(rpm->icc))
> > +   return PTR_ERR(rpm->icc);
> > +
> > +   ret = of_platform_populate(rpdev->dev.of_node, NULL, NULL, >dev);
> > +   if (ret)
> > +   platform_device_unregister(rpm->icc);
> > +
> > +   return ret;
> >  }
> >  
> >  static void qcom_smd_rpm_remove(struct rpmsg_device *rpdev)
> >  {
> > +   struct qcom_smd_rpm *rpm = dev_get_drvdata(>dev);
> > +
> > +   platform_device_unregister(rpm->icc);
> > of_platform_depopulate(>dev);
> >  }
> >  

[PATCH v2] soc: amlogic: meson-gx-socinfo: Add S905X3 ID for VIM3L

[Christian Hewitt]

VIM3L appears to use a different ID:

[0.086470] soc soc0: Amlogic Meson SM1 (S905X3) Revision 2b:c (b0:2) 
Detected

Signed-off-by: Christian Hewitt 
---
 drivers/soc/amlogic/meson-gx-socinfo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
b/drivers/soc/amlogic/meson-gx-socinfo.c
index 3c86d8d..87ed558 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -69,6 +69,7 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
+   { "S905X3", 0x2b, 0xb0, 0xf2 },
{ "A113L", 0x2c, 0x0, 0xf8 },
 };
 
-- 
2.7.4

[PATCH] soc: amlogic: meson-gx-socinfo: Add S905X3 ID for VIM3L

[Christian Hewitt]

[0.086470] soc soc0: Amlogic Meson SM1 (S905X3) Revision 2b:c (b0:2) 
Detected

Signed-off-by: Christian Hewitt 
---
 drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
b/drivers/soc/amlogic/meson-gx-socinfo.c
index 6d0d04f..dc744f1 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -68,6 +68,8 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
+   { "S905X3", 0x2b, 0xb0, 0xf2 },
+   { "A113L", 0x2c, 0x0, 0xf8 },
 };
 
 static inline unsigned int socinfo_to_major(u32 socinfo)
-- 
2.7.4

[PATCH 3/3] HID: logitech-hidpp: add G920 device validation quirk

[Andrey Smirnov]

G920 device only advertises REPORT_ID_HIDPP_LONG and
REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
prevent G920 to be recognized as a valid HID++ device.

Modify hidpp_validate_device() to check only REPORT_ID_HIDPP_LONG with
optional=false on G920 to fix this.

Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be 
handled by this module")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
Reported-by: Sam Bazely 
Signed-off-by: Andrey Smirnov 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: Henrik Rydberg 
Cc: Sam Bazely 
Cc: Pierre-Loup A. Griffais 
Cc: Austin Palmer 
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 drivers/hid/hid-logitech-hidpp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index cadf36d6c6f3..f415bf398e17 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3511,6 +3511,12 @@ static bool hidpp_validate_report(struct hid_device 
*hdev, int id,
 
 static bool hidpp_validate_device(struct hid_device *hdev)
 {
+   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+
+   if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)
+   return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
+HIDPP_REPORT_SHORT_LENGTH, false);
+
return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
 HIDPP_REPORT_SHORT_LENGTH, false) &&
   hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
-- 
2.21.0

[PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data

[Andrey Smirnov]

To simplify resource management in commit that follows as well as to
save a couple of extra kfree()s and simplify hidpp_ff_deinit() switch
driver code to use devres to manage the life-cycle of FF private data.

Signed-off-by: Andrey Smirnov 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: Henrik Rydberg 
Cc: Sam Bazely 
Cc: Pierre-Loup A. Griffais 
Cc: Austin Palmer 
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 drivers/hid/hid-logitech-hidpp.c | 53 +---
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 0179f7ed77e5..58eb928224e5 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct ff_device *ff)
struct hidpp_ff_private_data *data = ff->private;
 
kfree(data->effect_ids);
+   /*
+* Set private to NULL to prevent input_ff_destroy() from
+* freeing our devres allocated memory
+*/
+   ff->private = NULL;
 }
 
 static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index)
@@ -2090,7 +2095,7 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
feature_index)
const u16 bcdDevice = le16_to_cpu(udesc->bcdDevice);
struct ff_device *ff;
struct hidpp_report response;
-   struct hidpp_ff_private_data *data;
+   struct hidpp_ff_private_data *data = hidpp->private_data;
int error, j, num_slots;
u8 version;
 
@@ -2129,18 +2134,13 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
feature_index)
return error;
}
 
-   data = kzalloc(sizeof(*data), GFP_KERNEL);
-   if (!data)
-   return -ENOMEM;
data->effect_ids = kcalloc(num_slots, sizeof(int), GFP_KERNEL);
-   if (!data->effect_ids) {
-   kfree(data);
+   if (!data->effect_ids)
return -ENOMEM;
-   }
+
data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
if (!data->wq) {
kfree(data->effect_ids);
-   kfree(data);
return -ENOMEM;
}
 
@@ -2199,28 +2199,15 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
feature_index)
return 0;
 }
 
-static int hidpp_ff_deinit(struct hid_device *hid)
+static void hidpp_ff_deinit(struct hid_device *hid)
 {
-   struct hid_input *hidinput = list_entry(hid->inputs.next, struct 
hid_input, list);
-   struct input_dev *dev = hidinput->input;
-   struct hidpp_ff_private_data *data;
-
-   if (!dev) {
-   hid_err(hid, "Struct input_dev not found!\n");
-   return -EINVAL;
-   }
+   struct hidpp_device *hidpp = hid_get_drvdata(hid);
+   struct hidpp_ff_private_data *data = hidpp->private_data;
 
hid_info(hid, "Unloading HID++ force feedback.\n");
-   data = dev->ff->private;
-   if (!data) {
-   hid_err(hid, "Private data not found!\n");
-   return -EINVAL;
-   }
 
destroy_workqueue(data->wq);
device_remove_file(>dev, _attr_range);
-
-   return 0;
 }
 
 
@@ -2725,6 +2712,20 @@ static int k400_connect(struct hid_device *hdev, bool 
connected)
 
 #define HIDPP_PAGE_G920_FORCE_FEEDBACK 0x8123
 
+static int g920_allocate(struct hid_device *hdev)
+{
+   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+   struct hidpp_ff_private_data *data;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   hidpp->private_data = data;
+
+   return 0;
+}
+
 static int g920_get_config(struct hidpp_device *hidpp)
 {
u8 feature_type;
@@ -3561,6 +3562,10 @@ static int hidpp_probe(struct hid_device *hdev, const 
struct hid_device_id *id)
ret = k400_allocate(hdev);
if (ret)
return ret;
+   } else if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920) {
+   ret = g920_allocate(hdev);
+   if (ret)
+   return ret;
}
 
INIT_WORK(>work, delayed_work_cb);
-- 
2.21.0

[PATCH 2/3] HID: logitech-hidpp: split g920_get_config()

[Andrey Smirnov]

Original version of g920_get_config() contained two kind of actions:

1. Device specific communication to query/set some parameters
   which requires active communication channel with the device,
   or, put in other way, for the call to be sandwiched between
   hid_device_io_start() and hid_device_io_stop().

2. Input subsystem specific FF controller initialization which, in
   order to access a valid 'struct hid_input' via
   'hid->inputs.next', requires claimed hidinput which means be
   executed after the call to hid_hw_start() with connect_mask
   containing HID_CONNECT_HIDINPUT.

Location of g920_get_config() can only fulfill requirements for #1 and
not #2, which result in following backtrace:

[   88.312258] logitech-hidpp-device 0003:046D:C262.0005: HID++ 4.2 device 
connected.
[   88.320298] BUG: kernel NULL pointer dereference, address: 0018
[   88.320304] #PF: supervisor read access in kernel mode
[   88.320307] #PF: error_code(0x) - not-present page
[   88.320309] PGD 0 P4D 0
[   88.320315] Oops:  [#1] SMP PTI
[   88.320320] CPU: 1 PID: 3080 Comm: systemd-udevd Not tainted 5.4.0-rc1+ #31
[   88.320322] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
BIOS 149.0.0.0.0 09/17/2018
[   88.320334] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp]
[   88.320338] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f 
b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 
18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80
[   88.320341] RSP: 0018:b0a6824aba68 EFLAGS: 00010246
[   88.320345] RAX:  RBX: 93a50756e000 RCX: 00010408
[   88.320347] RDX:  RSI: 93a51f0ad0a0 RDI: 0002d0a0
[   88.320350] RBP: 93a50416da28 R08: 93a50416da70 R09: 93a50416da70
[   88.320352] R10: 00148ae9e60c R11: 000f1525 R12: 93a50756e000
[   88.320354] R13: 93a50756f8d0 R14:  R15: 93a50756fc38
[   88.320358] FS:  7f8d8c1e0940() GS:93a51f08() 
knlGS:
[   88.320361] CS:  0010 DS:  ES:  CR0: 80050033
[   88.320363] CR2: 0018 CR3: 0003996d8003 CR4: 001606e0
[   88.320366] Call Trace:
[   88.320377]  ? _cond_resched+0x15/0x30
[   88.320387]  ? create_pinctrl+0x2f/0x3c0
[   88.320393]  ? kernfs_link_sibling+0x94/0xe0
[   88.320398]  ? _cond_resched+0x15/0x30
[   88.320402]  ? kernfs_activate+0x5f/0x80
[   88.320406]  ? kernfs_add_one+0xe2/0x130
[   88.320411]  hid_device_probe+0x106/0x170
[   88.320419]  really_probe+0x147/0x3c0
[   88.320424]  driver_probe_device+0xb6/0x100
[   88.320428]  device_driver_attach+0x53/0x60
[   88.320433]  __driver_attach+0x8a/0x150
[   88.320437]  ? device_driver_attach+0x60/0x60
[   88.320440]  bus_for_each_dev+0x78/0xc0
[   88.320445]  bus_add_driver+0x14d/0x1f0
[   88.320450]  driver_register+0x6c/0xc0
[   88.320453]  ? 0xc0d67000
[   88.320457]  __hid_register_driver+0x4c/0x80
[   88.320464]  do_one_initcall+0x46/0x1f4
[   88.320469]  ? _cond_resched+0x15/0x30
[   88.320474]  ? kmem_cache_alloc_trace+0x162/0x220
[   88.320481]  ? do_init_module+0x23/0x230
[   88.320486]  do_init_module+0x5c/0x230
[   88.320491]  load_module+0x26e1/0x2990
[   88.320502]  ? ima_post_read_file+0xf0/0x100
[   88.320508]  ? __do_sys_finit_module+0xaa/0x110
[   88.320512]  __do_sys_finit_module+0xaa/0x110
[   88.320520]  do_syscall_64+0x5b/0x180
[   88.320525]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   88.320528] RIP: 0033:0x7f8d8d1f01fd
[   88.320532] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 5b 8c 0c 00 f7 d8 64 89 01 48
[   88.320535] RSP: 002b:7ffefa3bb068 EFLAGS: 0246 ORIG_RAX: 
0139
[   88.320539] RAX: ffda RBX: 55922040cb40 RCX: 7f8d8d1f01fd
[   88.320541] RDX:  RSI: 7f8d8ce4984d RDI: 0006
[   88.320543] RBP: 0002 R08:  R09: 0007
[   88.320545] R10: 0006 R11: 0246 R12: 7f8d8ce4984d
[   88.320547] R13:  R14: 55922040efc0 R15: 55922040cb40
[   88.320551] Modules linked in: hid_logitech_hidpp(+) fuse rfcomm ccm 
xt_CHECKSUM xt_MASQUERADE bridge stp llc nf_nat_tftp nf_conntrack_tftp 
nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle 
ip6table_raw ip6table_security iptable_nat nf_nat tun iptable_mangle 
iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables 
cmac bnep sunrpc dm_crypt nls_utf8 hfsplus intel_rapl_msr intel_rapl_common 
ath9k_htc ath9k_common x86_pkg_temp_thermal intel_powerclamp b43 ath9k_hw 
coretemp 

[PATCH 0/3] Logitech G920 fixes

[Andrey Smirnov]

Everyone:

This series contains patches to fix a couple of regressions in G920
wheel support by hid-logitech-hidpp driver. Without the patches the
wheel remains stuck in autocentering mode ("resisting" any attempt to
trun) as well as missing support for any FF action.

Thanks,
Andrey Smirnov

Andrey Smirnov (3):
  HID: logitech-hidpp: use devres to manage FF private data
  HID: logitech-hidpp: split g920_get_config()
  HID: logitech-hidpp: add G920 device validation quirk

 drivers/hid/hid-logitech-hidpp.c | 193 +++
 1 file changed, 120 insertions(+), 73 deletions(-)

-- 
2.21.0

Re: [PATCH v2 6/6] pwm: update comment on struct pwm_ops::apply

[Bjorn Andersson]

On Fri, Oct 4, 2019 at 6:33 AM Rasmus Villemoes
 wrote:
>
> Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
> state argument) updated the kernel-doc for pwm_apply_state(), but not
> for the ->apply callback in the pwm_ops struct.
>
> Signed-off-by: Rasmus Villemoes 

Reviewed-by: Bjorn Andersson 

> ---
>  include/linux/pwm.h | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index b2c9c460947d..0ef808d925bb 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -243,10 +243,7 @@ pwm_set_relative_duty_cycle(struct pwm_state *state, 
> unsigned int duty_cycle,
>   * @request: optional hook for requesting a PWM
>   * @free: optional hook for freeing a PWM
>   * @capture: capture and report PWM signal
> - * @apply: atomically apply a new PWM config. The state argument
> - *should be adjusted with the real hardware config (if the
> - *approximate the period or duty_cycle value, state should
> - *reflect it)
> + * @apply: atomically apply a new PWM config
>   * @get_state: get the current PWM state. This function is only
>   *called once per PWM device when the PWM chip is
>   *registered.
> --
> 2.20.1
>

checkpatch: false positive "does MAINTAINERS need updating?" warning

[Masahiro Yamada]

Hi Joe,


I ran checkpatch.pl against the following:
https://lore.kernel.org/patchwork/patch/1136334/


I did update MAINTAINERS, but I still get
"does MAINTAINERS need updating?" warning.
Why?



$ scripts/checkpatch.pl
0001-doc-move-namespaces.rst-out-of-kbuild-directory.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#18:
 Documentation/{kbuild => admin-guide}/namespaces.rst | 0

total: 0 errors, 1 warnings, 14 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

0001-doc-move-namespaces.rst-out-of-kbuild-directory.patch has style
problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.


-- 
Best Regards
Masahiro Yamada

mmotm 2019-10-06-21-12 uploaded

[akpm]

The mm-of-the-moment snapshot 2019-10-06-21-12 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/



The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 5.4-rc2:
(patches marked "*" will be included in linux-next)

* ocfs2-clear-zero-in-unaligned-direct-io.patch
* 
fs-ocfs2-fix-possible-null-pointer-dereferences-in-ocfs2_xa_prepare_entry.patch
* 
fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_write_end_nolock.patch
* 
fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_info_scan_inode_alloc.patch
* panic-ensure-preemption-is-disabled-during-panic.patch
* mm-memremap-drop-unused-section_size-and-section_mask.patch
* writeback-fix-use-after-free-in-finish_writeback_work.patch
* mm-fix-wmissing-prototypes-warnings.patch
* 
memcg-only-record-foreign-writebacks-with-dirty-pages-when-memcg-is-not-disabled.patch
* kernel-sysctlc-do-not-override-max_threads-provided-by-userspace.patch
* z3fold-claim-page-in-the-beginning-of-free.patch
* mm-page_alloc-fix-a-crash-in-free_pages_prepare.patch
* mm-vmpressure-fix-a-signedness-bug-in-vmpressure_register_event.patch
* mm-proportional-memorylowmin-reclaim.patch
* mm-make-memoryemin-the-baseline-for-utilisation-determination.patch
* mm-make-memoryemin-the-baseline-for-utilisation-determination-fix.patch
* mm-slb-improve-memory-accounting.patch
* mm-slb-guarantee-natural-alignment-for-kmallocpower-of-two.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* mm-page_owner-fix-off-by-one-error-in-__set_page_owner_handle.patch
* mm-page_owner-decouple-freeing-stack-trace-from-debug_pagealloc.patch
* mm-page_owner-rename-flag-indicating-that-page-is-allocated.patch
* kmemleak-do-not-corrupt-the-object_list-during-clean-up.patch
* mm-slub-fix-a-deadlock-in-show_slab_objects.patch
* lib-generic-radix-treec-add-kmemleak-annotations.patch
* genalloc-fix-a-set-of-docs-build-warnings.patch
* ocfs2-protect-extent-tree-in-the-ocfs2_prepare_inode_for_write.patch
* 
ocfs2-protect-extent-tree-in-the-ocfs2_prepare_inode_for_write-checkpatch-fixes.patch
* ocfs2-remove-unused-function-ocfs2_prepare_inode_for_refcount.patch
* ocfs2-fix-passing-zero-to-ptr_err-warning.patch
* ramfs-support-o_tmpfile.patch
  mm.patch
* mm-slab-make-kmalloc_info-contain-all-types-of-names.patch
* mm-slab-remove-unused-kmalloc_size.patch
* 
mm-slab_common-use-enum-kmalloc_cache_type-to-iterate-over-kmalloc-caches.patch
* mm-slub-print-the-offset-of-fault-addresses.patch
* mm-memcg-clean-up-reclaim-iter-array.patch
* 
mm-vmscan-get-number-of-pages-on-the-lru-list-in-memcgroup-base-on-lru_zone_size.patch
* mm-vmscan-expose-cgroup_ino-for-memcg-reclaim-tracepoints.patch
* mm-drop-mmap_sem-before-calling-balance_dirty_pages-in-write-fault.patch
* shmem-pin-the-file-in-shmem_fault-if-mmap_sem-is-dropped.patch
* mm-emit-tracepoint-when-rss-changes.patch
* mm-mmapc-remove-a-never-trigger-warning-in-__vma_adjust.patch
* mm-pgmap-use-correct-alignment-when-looking-at-first-pfn-from-a-region.patch
* 
mm-pgmap-use-correct-alignment-when-looking-at-first-pfn-from-a-region-checkpatch-fixes.patch
* mm-mmap-fix-the-adjusted-length-error.patch
* mm-rmapc-reuse-mergeable-anon_vma-as-parent-when-fork.patch
* mm-rmapc-reuse-mergeable-anon_vma-as-parent-when-fork-fix.patch
* mm-swap-piggyback-lru_add_drain_all-calls.patch
* mm-mmapc-prev-could-be-retrieved-from-vma-vm_prev.patch
* 

[RFC PATCH] media: videodev2.h: include instead of

[Masahiro Yamada]

Currently, linux/videodev.h is excluded from the UAPI header test since
it is not self-contained. Building it for user-space would fail.

(build log1 begin)

  CC  usr/include/linux/videodev2.h.s
In file included from :32:0:
./usr/include/linux/videodev2.h:2320:20: error: field ‘timestamp’ has 
incomplete type
  struct timespec   timestamp;
^

-(build log1 end)-

The in-kernel timespec definition exists in include/uapi/linux/time.h,
but just including  causes a lot of redefinition errors.

(build log2 begin)

  CC  usr/include/linux/videodev2.h.s
In file included from ./usr/include/linux/videodev2.h:63:0,
 from :32:
./usr/include/linux/time.h:16:8: error: redefinition of ‘struct timeval’
 struct timeval {
^~~
In file included from /usr/include/x86_64-linux-gnu/sys/time.h:25:0,
 from ./usr/include/linux/videodev2.h:60,
 from :32:
/usr/include/x86_64-linux-gnu/bits/types/struct_timeval.h:8:8: note: originally 
defined here
 struct timeval
^~~
In file included from ./usr/include/linux/videodev2.h:63:0,
 from :32:
./usr/include/linux/time.h:30:0: warning: "ITIMER_REAL" redefined
 #define ITIMER_REAL  0

In file included from ./usr/include/linux/videodev2.h:60:0,
 from :32:
/usr/include/x86_64-linux-gnu/sys/time.h:92:0: note: this is the location of 
the previous definition
 #define ITIMER_REAL ITIMER_REAL

In file included from ./usr/include/linux/videodev2.h:63:0,
 from :32:
./usr/include/linux/time.h:31:0: warning: "ITIMER_VIRTUAL" redefined
 #define ITIMER_VIRTUAL  1

In file included from ./usr/include/linux/videodev2.h:60:0,
 from :32:
/usr/include/x86_64-linux-gnu/sys/time.h:95:0: note: this is the location of 
the previous definition
 #define ITIMER_VIRTUAL ITIMER_VIRTUAL

In file included from ./usr/include/linux/videodev2.h:63:0,
 from :32:
./usr/include/linux/time.h:32:0: warning: "ITIMER_PROF" redefined
 #define ITIMER_PROF  2

In file included from ./usr/include/linux/videodev2.h:60:0,
 from :32:
/usr/include/x86_64-linux-gnu/sys/time.h:99:0: note: this is the location of 
the previous definition
 #define ITIMER_PROF ITIMER_PROF

In file included from ./usr/include/linux/videodev2.h:63:0,
 from :32:
./usr/include/linux/time.h:39:8: error: redefinition of ‘struct itimerval’
 struct itimerval {
^
In file included from ./usr/include/linux/videodev2.h:60:0,
 from :32:
/usr/include/x86_64-linux-gnu/sys/time.h:104:8: note: originally defined here
 struct itimerval
^

-(build log2 end)-

Replacing  with  solves it, and allow more
headers to join the UAPI header test.

Signed-off-by: Masahiro Yamada 
---

I am not 100% sure about the compatibility
between  and , hence RFC.

But, if they were not compatible,
I guess it would have broken already.

I CCed Arnd Bergmann, who might have a better insight.

A related comment is here:
https://lkml.org/lkml/2019/6/4/1046


 include/uapi/linux/videodev2.h | 4 +---
 usr/include/Makefile   | 7 ---
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 530638dffd93..2571130aa1ca 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -57,11 +57,9 @@
 #ifndef _UAPI__LINUX_VIDEODEV2_H
 #define _UAPI__LINUX_VIDEODEV2_H
 
-#ifndef __KERNEL__
-#include 
-#endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/usr/include/Makefile b/usr/include/Makefile
index 57b20f7b6729..dafa6cb9b07e 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -23,7 +23,6 @@ header-test- += asm/shmbuf.h
 header-test- += asm/signal.h
 header-test- += asm/ucontext.h
 header-test- += drm/vmwgfx_drm.h
-header-test- += linux/am437x-vpfe.h
 header-test- += linux/android/binder.h
 header-test- += linux/android/binderfs.h
 header-test-$(CONFIG_CPU_BIG_ENDIAN) += linux/byteorder/big_endian.h
@@ -33,13 +32,10 @@ header-test- += linux/elfcore.h
 header-test- += linux/errqueue.h
 header-test- += linux/fsmap.h
 header-test- += linux/hdlc/ioctl.h
-header-test- += linux/ivtv.h
 header-test- += linux/kexec.h
-header-test- += linux/matroxfb.h
 header-test- += linux/netfilter_ipv4/ipt_LOG.h
 header-test- += linux/netfilter_ipv6/ip6t_LOG.h
 header-test- += linux/nfc.h
-header-test- += linux/omap3isp.h
 header-test- += linux/omapfb.h
 header-test- += linux/patchkey.h
 header-test- += linux/phonet.h
@@ -49,9 +45,6 @@ header-test- += linux/sctp.h
 header-test- += linux/signal.h
 header-test- += linux/sysctl.h
 header-test- += linux/usb/audio.h
-header-test- += linux/v4l2-mediabus.h
-header-test- += 

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Max Filippov]

On Sun, Oct 6, 2019 at 3:25 PM Guenter Roeck  wrote:
> this patch causes all my sparc64 emulations to stall during boot. It causes
> all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> disk, and one of the xtensa emulations to crash with [2].

[...]

> [2]
>
> Unable to handle kernel paging request at virtual address 0004
> reboot(50): Oops -1
> pc = [<0004>]  ra = []  ps = Tainted: G 
>  D
> pc is at 0x4
> ra is at filldir64+0x64/0x320
> v0 =   t0 = 67736d6b  t1 = 00012011445b
> t2 =   t3 =   t4 = 7ef8
> t5 = 000120114448  t6 =   t7 = fc0007eec000
> s0 = fc000792b5c3  s1 = 0004  s2 = 0018
> s3 = fc0007eefec8  s4 = 0008  s5 = f0a3
> s6 = 000b
> a0 = fc000792b5c3  a1 = 2f2f2f2f2f2f2f2f  a2 = 0004
> a3 = 000b  a4 = f0a3  a5 = 0008
> t8 = 0018  t9 =   t10= 22e1d02a
> t11= 00011fd6f3b8  pv = fcb9a810  at = 22e1ccf8
> gp = fcf03930  sp = (ptrval)
> Trace:
> [] proc_readdir_de+0x170/0x300
> [] filldir64+0x0/0x320
> [] proc_root_readdir+0x3c/0x80
> [] iterate_dir+0x198/0x240
> [] ksys_getdents64+0xa8/0x160
> [] sys_getdents64+0x20/0x40
> [] filldir64+0x0/0x320
> [] entSys+0xa4/0xc0

This doesn't look like a dump from xtensa core.
v5.4-rc2 kernel doesn't crash for me on xtensa, but the userspace
doesn't work well, because all directories appear to be empty.

__put_user/__get_user don't do unaligned access on xtensa,
they check address alignment and return -EFAULT if it's bad.

-- 
Thanks.
-- Max

[PATCH v5 5/7] backlight: gpio: remove unused fields from platform data

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Remove the platform data fields that nobody uses.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Reviewed-by: Daniel Thompson 
---
 include/linux/platform_data/gpio_backlight.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/platform_data/gpio_backlight.h 
b/include/linux/platform_data/gpio_backlight.h
index 34179d600360..1a8b5b1946fe 100644
--- a/include/linux/platform_data/gpio_backlight.h
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -9,9 +9,6 @@ struct device;
 
 struct gpio_backlight_platform_data {
struct device *fbdev;
-   int gpio;
-   int def_value;
-   const char *name;
 };
 
 #endif
-- 
2.23.0

[PATCH v5 3/7] backlight: gpio: simplify the platform data handling

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Now that the last user of platform data (sh ecovec24) defines a proper
GPIO lookup and sets the 'default-on' device property, we can drop the
platform_data-specific GPIO handling and unify a big chunk of code.

The only field used from the platform data is now the fbdev pointer.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Reviewed-by: Daniel Thompson 
Reviewed-by: Andy Shevchenko 
---
 drivers/video/backlight/gpio_backlight.c | 62 +---
 1 file changed, 11 insertions(+), 51 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index 7e1990199fae..20c5311c7ed2 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include  /* Only for legacy support */
 #include 
 #include 
 #include 
@@ -54,28 +53,6 @@ static const struct backlight_ops gpio_backlight_ops = {
.check_fb   = gpio_backlight_check_fb,
 };
 
-static int gpio_backlight_probe_dt(struct platform_device *pdev,
-  struct gpio_backlight *gbl)
-{
-   struct device *dev = >dev;
-   int ret;
-
-   gbl->def_value = device_property_read_bool(dev, "default-on");
-
-   gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
-   if (IS_ERR(gbl->gpiod)) {
-   ret = PTR_ERR(gbl->gpiod);
-
-   if (ret != -EPROBE_DEFER) {
-   dev_err(dev,
-   "Error: The gpios parameter is missing or 
invalid.\n");
-   }
-   return ret;
-   }
-
-   return 0;
-}
-
 static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
 {
struct device_node *node = gbl->dev->of_node;
@@ -107,35 +84,18 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
 
gbl->dev = >dev;
 
-   if (pdev->dev.fwnode) {
-   ret = gpio_backlight_probe_dt(pdev, gbl);
-   if (ret)
-   return ret;
-   } else if (pdata) {
-   /*
-* Legacy platform data GPIO retrieveal. Do not expand
-* the use of this code path, currently only used by one
-* SH board.
-*/
-   unsigned long flags = GPIOF_DIR_OUT;
-
+   if (pdata)
gbl->fbdev = pdata->fbdev;
-   gbl->def_value = pdata->def_value;
-   flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
-
-   ret = devm_gpio_request_one(gbl->dev, pdata->gpio, flags,
-   pdata ? pdata->name : "backlight");
-   if (ret < 0) {
-   dev_err(>dev, "unable to request GPIO\n");
-   return ret;
-   }
-   gbl->gpiod = gpio_to_desc(pdata->gpio);
-   if (!gbl->gpiod)
-   return -EINVAL;
-   } else {
-   dev_err(>dev,
-   "failed to find platform data or device tree node.\n");
-   return -ENODEV;
+
+   gbl->def_value = device_property_read_bool(>dev, "default-on");
+
+   gbl->gpiod = devm_gpiod_get(>dev, NULL, GPIOD_ASIS);
+   if (IS_ERR(gbl->gpiod)) {
+   ret = PTR_ERR(gbl->gpiod);
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev,
+   "Error: The gpios parameter is missing or 
invalid.\n");
+   return ret;
}
 
memset(, 0, sizeof(props));
-- 
2.23.0

[PATCH v5 7/7] backlight: gpio: pull gpio_backlight_initial_power_state() into probe

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

The probe function in the gpio-backlight driver is quite short. If we
pull gpio_backlight_initial_power_state() into probe we can drop two
more fields from struct gpio_backlight and shrink the driver code.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/video/backlight/gpio_backlight.c | 37 +---
 1 file changed, 13 insertions(+), 24 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index 6247687b6330..407d4eaafc5c 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -17,11 +17,8 @@
 #include 
 
 struct gpio_backlight {
-   struct device *dev;
struct device *fbdev;
-
struct gpio_desc *gpiod;
-   int def_value;
 };
 
 static int gpio_backlight_update_status(struct backlight_device *bl)
@@ -53,41 +50,24 @@ static const struct backlight_ops gpio_backlight_ops = {
.check_fb   = gpio_backlight_check_fb,
 };
 
-static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
-{
-   struct device_node *node = gbl->dev->of_node;
-
-   /* Not booted with device tree or no phandle link to the node */
-   if (!node || !node->phandle)
-   return gbl->def_value ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
-
-   /* if the enable GPIO is disabled, do not enable the backlight */
-   if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
-   return FB_BLANK_POWERDOWN;
-
-   return FB_BLANK_UNBLANK;
-}
-
-
 static int gpio_backlight_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
+   struct device_node *of_node = dev->of_node;
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
-   int ret;
+   int ret, def_value;
 
gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
 
-   gbl->dev = dev;
-
if (pdata)
gbl->fbdev = pdata->fbdev;
 
-   gbl->def_value = device_property_read_bool(dev, "default-on");
+   def_value = device_property_read_bool(dev, "default-on");
 
gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
if (IS_ERR(gbl->gpiod)) {
@@ -109,7 +89,16 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
return PTR_ERR(bl);
}
 
-   bl->props.power = gpio_backlight_initial_power_state(gbl);
+   /* Set the initial power state */
+   if (!of_node || !of_node->phandle)
+   /* Not booted with device tree or no phandle link to the node */
+   bl->props.power = def_value ? FB_BLANK_UNBLANK
+   : FB_BLANK_POWERDOWN;
+   else if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
+   bl->props.power = FB_BLANK_POWERDOWN;
+   else
+   bl->props.power = FB_BLANK_UNBLANK;
+
bl->props.brightness = 1;
 
backlight_update_status(bl);
-- 
2.23.0

Re: Aw: Re: [PATCH] mfd: mt6397: fix probe after changing mt6397-core

[Hsin-hsiung Wang]

On Sat, 2019-10-05 at 10:16 +0200, Matthias Brugger wrote:
> 
> On 04/10/2019 17:51, Frank Wunderlich wrote:
> > This Question goes to Hsin-Hsiung Wang ;)
> > 
> > i only took his code (and splitted the 3rd part) to get mt6323 working 
> > again without reverting the other 2 Patches
> >> regards Frank

Hi, Frank
Sorry for the late reply.
I appreciate your help very much for splitting the code to fix the
issue.
This patch is ok for me.

> > 
> > 
> >> Gesendet: Freitag, 04. Oktober 2019 um 17:20 Uhr
> >> Von: "Lee Jones" 
> > 
> >> Will there be other devices which have a !0 CID shift?
> > 
> 
> Frank, a quick look at the series would have given you the answer.
> @Lee: yes, this change is the preparation to support MT6358:
> https://patchwork.kernel.org/patch/0515/
> 
Hi, Lee
MT6358 uses 8 for the cid shift and I will submit next version patch of
mt6358 which is based on Frank's patch.

Hi, Matthias
Many thanks for the explanation.

> Regards,
> Matthias

[PATCH v5 6/7] backlight: gpio: use a helper variable for >dev

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Reviewed-by: Daniel Thompson 
Reviewed-by: Andy Shevchenko 
---
 drivers/video/backlight/gpio_backlight.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index 20c5311c7ed2..6247687b6330 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -71,25 +71,25 @@ static int gpio_backlight_initial_power_state(struct 
gpio_backlight *gbl)
 
 static int gpio_backlight_probe(struct platform_device *pdev)
 {
-   struct gpio_backlight_platform_data *pdata =
-   dev_get_platdata(>dev);
+   struct device *dev = >dev;
+   struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
int ret;
 
-   gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
+   gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
 
-   gbl->dev = >dev;
+   gbl->dev = dev;
 
if (pdata)
gbl->fbdev = pdata->fbdev;
 
-   gbl->def_value = device_property_read_bool(>dev, "default-on");
+   gbl->def_value = device_property_read_bool(dev, "default-on");
 
-   gbl->gpiod = devm_gpiod_get(>dev, NULL, GPIOD_ASIS);
+   gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
if (ret != -EPROBE_DEFER)
@@ -101,11 +101,11 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = 1;
-   bl = devm_backlight_device_register(>dev, dev_name(>dev),
-   >dev, gbl, _backlight_ops,
+   bl = devm_backlight_device_register(dev, dev_name(dev),
+   dev, gbl, _backlight_ops,
);
if (IS_ERR(bl)) {
-   dev_err(>dev, "failed to register backlight\n");
+   dev_err(dev, "failed to register backlight\n");
return PTR_ERR(bl);
}
 
-- 
2.23.0

[PATCH v5 4/7] sh: ecovec24: don't set unused fields in platform data

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Platform data fields other than fbdev are no longer used by the
backlight driver. Remove them.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
---
 arch/sh/boards/mach-ecovec24/setup.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c 
b/arch/sh/boards/mach-ecovec24/setup.c
index aaa8ea62636f..dd427bac5cde 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -386,9 +386,6 @@ static struct property_entry gpio_backlight_props[] = {
 
 static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = _device.dev,
-   .gpio = GPIO_PTR1,
-   .def_value = 1,
-   .name = "backlight",
 };
 
 static const struct platform_device_info gpio_backlight_device_info = {
-- 
2.23.0

Re: Aw: Re: [PATCH] mfd: mt6397: fix probe after changing mt6397-core

[Hsin-hsiung Wang]

On Sat, 2019-10-05 at 10:16 +0200, Matthias Brugger wrote:
> 
> On 04/10/2019 17:51, Frank Wunderlich wrote:
> > This Question goes to Hsin-Hsiung Wang ;)
> > 
> > i only took his code (and splitted the 3rd part) to get mt6323 working 
> > again without reverting the other 2 Patches
> >> regards Frank
> > 
Hi Frank,
Sorry for the late reply.
I appreciate your help very much for splitting the code to fix the
issue.
This patch is ok for me.

> > 
> >> Gesendet: Freitag, 04. Oktober 2019 um 17:20 Uhr
> >> Von: "Lee Jones" 
> > 
> >> Will there be other devices which have a !0 CID shift?
> > 
> 
> Frank, a quick look at the series would have given you the answer.
> @Lee: yes, this change is the preparation to support MT6358:
> https://patchwork.kernel.org/patch/0515/
> 

Hi, Lee
MT6358 uses 8 for the cid shift and I will submit next version patch of
mt6358 which is based on Frank's patch.

Hi, Matthias
Many thanks for the explanation.

> Regards,
> Matthias

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Walter Wu]

On Fri, 2019-10-04 at 15:52 +0200, Dmitry Vyukov wrote:
> On Fri, Oct 4, 2019 at 2:05 PM Walter Wu  wrote:
> >
> > On Fri, 2019-10-04 at 11:54 +0200, Dmitry Vyukov wrote:
> > > > > "out-of-bounds" is the _least_ frequent KASAN bug type. So saying
> > > > > "out-of-bounds" has downsides of both approaches and won't prevent
> > > > > duplicate reports by syzbot...
> > > > >
> > > > maybe i should add your comment into the comment in get_bug_type?
> > >
> > > Yes, that's exactly what I meant above:
> > >
> > > "I would change get_bug_type() to return "slab-out-of-bounds" (as the
> > > most common OOB) in such case (with a comment)."
> > >
> > >  ;)
> >
> >
> > The patchset help to produce KASAN report when size is negative size in
> > memory operation function. It is helpful for programmer to solve the
> > undefined behavior issue. Patch 1 based on Dmitry's suggestion and
> > review, patch 2 is a test in order to verify the patch 1.
> >
> > [1]https://bugzilla.kernel.org/show_bug.cgi?id=199341
> > [2]https://lore.kernel.org/linux-arm-kernel/20190927034338.15813-1-walter-zh...@mediatek.com/
> >
> > Walter Wu (2):
> > kasan: detect invalid size in memory operation function
> > kasan: add test for invalid size in memmove
> >
> > lib/test_kasan.c  | 18 ++
> > mm/kasan/common.c | 13 -
> > mm/kasan/generic.c|  5 +
> > mm/kasan/generic_report.c | 10 ++
> > mm/kasan/tags.c   |  5 +
> > mm/kasan/tags_report.c| 10 ++
> > 6 files changed, 56 insertions(+), 5 deletions(-)
> >
> >
> >
> >
> > commit 0bc50c759a425fa0aafb7ef623aa1598b3542c67
> > Author: Walter Wu 
> > Date:   Fri Oct 4 18:38:31 2019 +0800
> >
> > kasan: detect invalid size in memory operation function
> >
> > It is an undefined behavior to pass a negative value to
> > memset()/memcpy()/memmove()
> > , so need to be detected by KASAN.
> >
> > If size is negative value, then it will be larger than ULONG_MAX/2,
> > so that we will qualify as out-of-bounds issue.
> >
> > KASAN report:
> >
> >  BUG: KASAN: out-of-bounds in kmalloc_memmove_invalid_size+0x70/0xa0
> >  Read of size 18446744073709551608 at addr ff8069660904 by task
> > cat/72
> >
> >  CPU: 2 PID: 72 Comm: cat Not tainted
> > 5.4.0-rc1-next-20191004ajb-1-gdb8af2f372b2-dirty #1
> >  Hardware name: linux,dummy-virt (DT)
> >  Call trace:
> >   dump_backtrace+0x0/0x288
> >   show_stack+0x14/0x20
> >   dump_stack+0x10c/0x164
> >   print_address_description.isra.9+0x68/0x378
> >   __kasan_report+0x164/0x1a0
> >   kasan_report+0xc/0x18
> >   check_memory_region+0x174/0x1d0
> >   memmove+0x34/0x88
> >   kmalloc_memmove_invalid_size+0x70/0xa0
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
> >
> > Signed-off-by: Walter Wu 
> > Reported -by: Dmitry Vyukov 
> > Suggested-by: Dmitry Vyukov 
> >
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 6814d6d6a023..6ef0abd27f06 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -102,7 +102,8 @@ EXPORT_SYMBOL(__kasan_check_write);
> >  #undef memset
> >  void *memset(void *addr, int c, size_t len)
> >  {
> > -   check_memory_region((unsigned long)addr, len, true, _RET_IP_);
> > +   if (!check_memory_region((unsigned long)addr, len, true, _RET_IP_))
> > +   return NULL;
> >
> > return __memset(addr, c, len);
> >  }
> > @@ -110,8 +111,9 @@ void *memset(void *addr, int c, size_t len)
> >  #undef memmove
> >  void *memmove(void *dest, const void *src, size_t len)
> >  {
> > -   check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > -   check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> > +   if (!check_memory_region((unsigned long)src, len, false, _RET_IP_) 
> > ||
> > +   !check_memory_region((unsigned long)dest, len, true, _RET_IP_))
> > +   return NULL;
> >
> > return __memmove(dest, src, len);
> >  }
> > @@ -119,8 +121,9 @@ void *memmove(void *dest, const void *src, size_t
> > len)
> >  #undef memcpy
> >  void *memcpy(void *dest, const void *src, size_t len)
> >  {
> > -   check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > -   check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> > +   if (!check_memory_region((unsigned long)src, len, false, _RET_IP_) 
> > ||
> > +   !check_memory_region((unsigned long)dest, len, true, _RET_IP_))
> > +   return NULL;
> >
> > return __memcpy(dest, src, len);
> >  }
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 616f9dd82d12..02148a317d27 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -173,6 +173,11 @@ static __always_inline bool
> > check_memory_region_inline(unsigned long addr,
> > if (unlikely(size == 0))
> > return true;
> >
> > +   if (unlikely((long)size < 0)) {
> > +

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 7:30 PM Guenter Roeck  wrote:
>
> > Mind humoring me and trying that on your alpha machine (or emulator,
> > or whatever)?
>
> Here you are. This is with v5.4-rc2 and your previous patch applied
> on top.
>
> / # ./mmtest
> Unable to handle kernel paging request at virtual address 0004

Oookay.

Well, that's what I expected, but it's good to just have it confirmed.

Well, not "good" in this case. Bad bad bad.

The fs/readdir.c changes clearly exposed a pre-existing bug on alpha.
Not making excuses for it, but at least it explains why code that
_looks_ correct ends up causing that kind of issue.

I guess the other 'strict alignment' architectures should be checking
that test program too. I'll post my test program to the arch
maintainers list.

 Linus

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 7:50 PM Al Viro  wrote:
>
> Out of those, only __copy_to_user_inatomic(), __copy_to_user(),
> _copy_to_user() and iov_iter.c:copyout() can be called on
> any architecture.
>
> The last two should just do user_access_begin()/user_access_end()
> instead of access_ok().  __copy_to_user_inatomic() has very few callers as 
> well:

Yeah, good points.

It looks like it would be better to just change over semantics
entirely to the unsafe_copy_user() model.

> So few, in fact, that I wonder if we want to keep it at all; the only
> thing stopping me from "let's remove it" is that I don't understand
> the i915 side of things.  Where does it do an equivalent of access_ok()?

Honestly, if you have to ask, I think the answer is: just add one.

Every single time we've had people who optimized things to try to
avoid the access_ok(), they just caused bugs and problems.

In this case, I think it's done a few callers up in i915_gem_pread_ioctl():

if (!access_ok(u64_to_user_ptr(args->data_ptr),
   args->size))
return -EFAULT;

but honestly, trying to optimize away another "access_ok()" is just
not worth it. I'd rather have an extra one than miss one.

> And mm/maccess.c one is __probe_kernel_write(), so presumably we don't
> want stac/clac there at all...

Yup.

> So do we want to bother with separation between raw_copy_to_user() and
> unsafe_copy_to_user()?  After all, __copy_to_user() also has only few
> callers, most of them in arch/*

No, you're right. Just switch over.

> I'll take a look into that tomorrow - half-asleep right now...

Thanks. No huge hurry.

 Linus

kexec breaks with 5.4 due to memzero_explicit

[Arvind Sankar]

Hi, arch/x86/purgatory/purgatory.ro has an undefined symbol
memzero_explicit. This has come from commit 906a4bb97f5d ("crypto:
sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
according to git bisect.

The patch mentions that it impacts purgatory code, but I don't see any
changes to actually include the definition of memzero_explicit into
purgatory? It used to get memset from arch/x86/boot/compressed/string.c
I think.

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Al Viro]

On Sun, Oct 06, 2019 at 07:06:19PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 6:24 PM Al Viro  wrote:
> >
> > Ugh...  I wonder if it would be better to lift STAC/CLAC out of
> > raw_copy_to_user(), rather than trying to reinvent its guts
> > in readdir.c...
> 
> Yeah, I suspect that's the best option.
> 
> Do something like
> 
>  - lift STAC/CLAC out of raw_copy_to_user
> 
>  - rename it to unsafe_copy_to_user
> 
>  - create a new raw_copy_to_user that is just unsafe_copy_to_user()
> with the STAC/CLAC around it.
> 
> and the end result would actually be cleanert than what we have now
> (which duplicates that STAC/CLAC for each size case etc).
> 
> And then for the "architecture doesn't have user_access_begin/end()"
> fallback case, we just do
> 
>#define unsafe_copy_to_user raw_copy_to_user

Callers of raw_copy_to_user():
arch/hexagon/mm/uaccess.c:27:   uncleared = raw_copy_to_user(dest, 
_zero_page, PAGE_SIZE);
arch/hexagon/mm/uaccess.c:34:   count = raw_copy_to_user(dest, 
_zero_page, count);
arch/powerpc/kvm/book3s_64_mmu_radix.c:68:  ret = 
raw_copy_to_user(to, from, n);
arch/s390/include/asm/uaccess.h:150:size = raw_copy_to_user(ptr, x, size);
include/asm-generic/uaccess.h:145:  return unlikely(raw_copy_to_user(ptr, 
x, size)) ? -EFAULT : 0;
include/linux/uaccess.h:93: return raw_copy_to_user(to, from, n);
include/linux/uaccess.h:102:return raw_copy_to_user(to, from, n);
include/linux/uaccess.h:131:n = raw_copy_to_user(to, from, n);
lib/iov_iter.c:142: n = raw_copy_to_user(to, from, n);
lib/usercopy.c:28:  n = raw_copy_to_user(to, from, n);


Out of those, only __copy_to_user_inatomic(), __copy_to_user(),
_copy_to_user() and iov_iter.c:copyout() can be called on
any architecture.

The last two should just do user_access_begin()/user_access_end()
instead of access_ok().  __copy_to_user_inatomic() has very few callers as well:

arch/mips/kernel/unaligned.c:1307:  res = 
__copy_to_user_inatomic(addr, fpr, sizeof(*fpr));
drivers/gpu/drm/i915/i915_gem.c:345:unwritten = 
__copy_to_user_inatomic(user_data,
lib/test_kasan.c:471:   unused = __copy_to_user_inatomic(usermem, kmem, size + 
1);
mm/maccess.c:98:ret = __copy_to_user_inatomic((__force void __user 
*)dst, src, size);

So few, in fact, that I wonder if we want to keep it at all; the only
thing stopping me from "let's remove it" is that I don't understand
the i915 side of things.  Where does it do an equivalent of access_ok()?

And mm/maccess.c one is __probe_kernel_write(), so presumably we don't
want stac/clac there at all...

So do we want to bother with separation between raw_copy_to_user() and
unsafe_copy_to_user()?  After all, __copy_to_user() also has only few
callers, most of them in arch/*

I'll take a look into that tomorrow - half-asleep right now...

[PATCH v2] iio: pressure: bmp280: use devm action and remove labels from probe

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We can drop some duplicate code if we use devm_action for disabling
regulators and pm and the managed variant of iio_device_register().

This allows us to completely remove all remove() callbacks from both
i2c and spi code.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- squash the patches using devm_iio_device_register() and devm_action
  to keep the changes bisectable

 drivers/iio/pressure/bmp280-core.c | 62 +++---
 drivers/iio/pressure/bmp280-i2c.c  |  6 ---
 drivers/iio/pressure/bmp280-spi.c  |  6 ---
 drivers/iio/pressure/bmp280.h  |  1 -
 4 files changed, 30 insertions(+), 45 deletions(-)

diff --git a/drivers/iio/pressure/bmp280-core.c 
b/drivers/iio/pressure/bmp280-core.c
index c2988dbdb1a7..79254dd26dfd 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -984,6 +984,22 @@ static int bmp085_fetch_eoc_irq(struct device *dev,
return 0;
 }
 
+static void bmp280_pm_disable(void *data)
+{
+   struct device *dev = data;
+
+   pm_runtime_get_sync(dev);
+   pm_runtime_put_noidle(dev);
+   pm_runtime_disable(dev);
+}
+
+static void bmp280_regulators_disable(void *data)
+{
+   struct regulator_bulk_data *supplies = data;
+
+   regulator_bulk_disable(BMP280_NUM_SUPPLIES, supplies);
+}
+
 int bmp280_common_probe(struct device *dev,
struct regmap *regmap,
unsigned int chip,
@@ -1055,6 +1071,11 @@ int bmp280_common_probe(struct device *dev,
return ret;
}
 
+   ret = devm_add_action_or_reset(dev, bmp280_regulators_disable,
+  data->supplies);
+   if (ret)
+   return ret;
+
/* Wait to make sure we started up properly */
usleep_range(data->start_up_time, data->start_up_time + 100);
 
@@ -1069,17 +1090,16 @@ int bmp280_common_probe(struct device *dev,
data->regmap = regmap;
ret = regmap_read(regmap, BMP280_REG_ID, _id);
if (ret < 0)
-   goto out_disable_regulators;
+   return ret;
if (chip_id != chip) {
dev_err(dev, "bad chip id: expected %x got %x\n",
chip, chip_id);
-   ret = -EINVAL;
-   goto out_disable_regulators;
+   return -EINVAL;
}
 
ret = data->chip_info->chip_config(data);
if (ret < 0)
-   goto out_disable_regulators;
+   return ret;
 
dev_set_drvdata(dev, indio_dev);
 
@@ -1093,14 +1113,14 @@ int bmp280_common_probe(struct device *dev,
if (ret < 0) {
dev_err(data->dev,
"failed to read calibration coefficients\n");
-   goto out_disable_regulators;
+   return ret;
}
} else if (chip_id == BMP280_CHIP_ID || chip_id == BME280_CHIP_ID) {
ret = bmp280_read_calib(data, >calib.bmp280, chip_id);
if (ret < 0) {
dev_err(data->dev,
"failed to read calibration coefficients\n");
-   goto out_disable_regulators;
+   return ret;
}
}
 
@@ -1112,7 +1132,7 @@ int bmp280_common_probe(struct device *dev,
if (irq > 0 || (chip_id  == BMP180_CHIP_ID)) {
ret = bmp085_fetch_eoc_irq(dev, name, irq, data);
if (ret)
-   goto out_disable_regulators;
+   return ret;
}
 
/* Enable runtime PM */
@@ -1127,36 +1147,14 @@ int bmp280_common_probe(struct device *dev,
pm_runtime_use_autosuspend(dev);
pm_runtime_put(dev);
 
-   ret = iio_device_register(indio_dev);
+   ret = devm_add_action_or_reset(dev, bmp280_pm_disable, dev);
if (ret)
-   goto out_runtime_pm_disable;
-
-   return 0;
+   return ret;
 
-out_runtime_pm_disable:
-   pm_runtime_get_sync(data->dev);
-   pm_runtime_put_noidle(data->dev);
-   pm_runtime_disable(data->dev);
-out_disable_regulators:
-   regulator_bulk_disable(BMP280_NUM_SUPPLIES, data->supplies);
-   return ret;
+   return devm_iio_device_register(dev, indio_dev);
 }
 EXPORT_SYMBOL(bmp280_common_probe);
 
-int bmp280_common_remove(struct device *dev)
-{
-   struct iio_dev *indio_dev = dev_get_drvdata(dev);
-   struct bmp280_data *data = iio_priv(indio_dev);
-
-   iio_device_unregister(indio_dev);
-   pm_runtime_get_sync(data->dev);
-   pm_runtime_put_noidle(data->dev);
-   pm_runtime_disable(data->dev);
-   regulator_bulk_disable(BMP280_NUM_SUPPLIES, data->supplies);
-   return 0;
-}
-EXPORT_SYMBOL(bmp280_common_remove);
-
 #ifdef CONFIG_PM
 static int bmp280_runtime_suspend(struct device *dev)
 {
diff --git a/drivers/iio/pressure/bmp280-i2c.c 

Re: [PATCH v3 0/2] mmc: sdhci-milbeaut: add Milbeaut SD driver

[orito.takao]

Thanks for checking and pushing my patch !

Orito

> On Tue, 10 Sep 2019 at 03:39, Takao Orito  wrote:
> >
> > The following patches add driver for SD Host controller on
> > Socionext's Milbeaut M10V platforms.
> >
> > SD Host controller on Milbeaut consists of two controller parts.
> > One is core controller F_SDH30, this is similar to sdhci-fujitsu
> > controller.
> > Another is bridge controller. This bridge controller is not compatible
> > with sdhci-fujitsu controller. This is special for Milbeaut series.
> >
> > It has the several parts,
> >  - reset control
> >  - clock enable / select for SDR50/25/12
> >  - hold control of DATA/CMD line
> >  - select characteristics for WP/CD/LED line
> >  - Re-tuning control for mode3
> >  - Capability setting
> >Timeout Clock / Base Clock / Timer Count for Re-Tuning /
> >Debounce period
> > These requires special procedures at reset or clock enable/change or
> >  further tuning of clock.
> >
> > Takao Orito (2):
> >   dt-bindings: mmc: add DT bindings for Milbeaut SD controller
> >   mmc: sdhci-milbeaut: add Milbeaut SD controller driver
> >
> >  .../devicetree/bindings/mmc/sdhci-milbeaut.txt |  30 ++
> >  drivers/mmc/host/Kconfig   |  11 +
> >  drivers/mmc/host/Makefile  |   1 +
> >  drivers/mmc/host/sdhci-milbeaut.c  | 362 
> > +
> >  drivers/mmc/host/sdhci_f_sdh30.c   |  26 +-
> >  drivers/mmc/host/sdhci_f_sdh30.h   |  32 ++
> >  6 files changed, 437 insertions(+), 25 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
> >  create mode 100644 drivers/mmc/host/sdhci-milbeaut.c
> >  create mode 100644 drivers/mmc/host/sdhci_f_sdh30.h
> >
> > --
> > 1.9.1
> >
> >
> 
> Applied for next, thanks!
> 
> Kind regards
> Uffe

-
Takao Orito
Socionext Inc.
E-mail:orito.ta...@socionext.com
Tel:+81-80-9815-1460
-

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Guenter Roeck]

On 10/6/19 6:17 PM, Linus Torvalds wrote:

On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck  wrote:

[ ... ]

And yes, I'll fix that name copy loop in filldir to align the
destination first, *but* if I'm right, it means that something like
this should also likely cause issues:

   #define _GNU_SOURCE
   #include 
   #include 

   int main(int argc, char **argv)
   {
 void *mymap;
 uid_t *bad_ptr = (void *) 0x01;

 /* Create unpopulated memory area */
 mymap = mmap(NULL, 16384, PROT_READ | PROT_WRITE, MAP_PRIVATE
| MAP_ANONYMOUS, -1, 0);

 /* Unaligned uidpointer in that memory area */
 bad_ptr = mymap+1;

 /* Make the kernel do put_user() on it */
 return getresuid(bad_ptr, bad_ptr+1, bad_ptr+2);
   }

because that simple user mode program should cause that same "page
fault on unaligned put_user()" behavior as far as I can tell.

Mind humoring me and trying that on your alpha machine (or emulator,
or whatever)?



Here you are. This is with v5.4-rc2 and your previous patch applied
on top.

/ # ./mmtest
Unable to handle kernel paging request at virtual address 0004
mmtest(75): Oops -1
pc = [<0004>]  ra = []  ps = Not tainted
pc is at 0x4
ra is at entSys+0xa4/0xc0
v0 = fff2  t0 =   t1 = 
t2 =   t3 =   t4 = 
t5 = fffe  t6 =   t7 = fc0007edc000
s0 =   s1 = 000126f0  s2 = 0001200df19f
s3 = 0001200ea0b9  s4 = 000120114630  s5 = 0001201145d8
s6 = 00011f955c50
a0 = 0202c001  a1 = 0202c005  a2 = 0202c009
a3 =   a4 =   a5 = 
t8 =   t9 = fc00  t10= 
t11= 00011f955788  pv = fc349450  at = f8db54d3
gp = fcf2a160  sp = ab237c72
Disabling lock debugging due to kernel taint
Trace:

Code:
 
 00063301
 07b6
 
 3f8d

Segmentation fault

Guenter

ehci-pci breakage with dma-mapping changes in 5.4-rc2

[Arvind Sankar]

Hi,
Commit 249baa547901 ("dma-mapping: provide a better default
->get_required_mask") causes an error on ehci-pci for me.

Either reverting the commit or disabling iommu=pt seems to fix this.

[9.81] usb 1-1: new high-speed USB device number 2 using ehci-pci
[9.000755] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 8 bytes), 
total 0 (slots), used 0 (slots)
[9.001179] ehci-pci :00:1a.0: overflow 0x00042f541790+8 of DMA mask 
 bus mask 0
[9.001552] [ cut here ]
[9.001933] WARNING: CPU: 0 PID: 7 at kernel/dma/direct.c:35 
report_addr+0x3c/0x70
[9.002355] Modules linked in:
[9.002802] CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 
5.4.0-rc2-stable-rani-zfs+ #67
[9.003270] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8 WS/Z10PE-D8 WS, 
BIOS 3703 04/13/2018
[9.003761] Workqueue: usb_hub_wq hub_event
[9.004241] RIP: 0010:report_addr+0x3c/0x70
[9.004722] Code: 48 89 34 24 48 8b 85 e8 01 00 00 48 85 c0 74 30 4c 8b 00 
b8 fe ff ff ff 49 39 c0 76 17 80 3d 86 6f 23 01 00 0f 84 df 06 00 00 <0f> 0b 48 
83 c4 08 5d 41 5c c3 48 83 bd f8 01 00 00 00 74 ec eb dd
[9.005743] RSP: :b25706307af8 EFLAGS: 00010286
[9.006261] RAX:  RBX: e0e3d0bd5040 RCX: 06fc
[9.006783] RDX:  RSI: 0092 RDI: ab163fe8
[9.007301] RBP: a38c678a00b0 R08:  R09: 06fc
[9.007826] R10: 00aa R11: ff00 R12: 0008
[9.008339] R13:  R14: 0790 R15: a38c678a00b0
[9.008849] FS:  () GS:a38b5f60() 
knlGS:
[9.009355] CS:  0010 DS:  ES:  CR0: 80050033
[9.009866] CR2: a396b4001000 CR3: 0013b340a001 CR4: 003606f0
[9.010498] DR0:  DR1:  DR2: 
[9.011034] DR3:  DR6: fffe0ff0 DR7: 0400
[9.011580] Call Trace:
[9.012110]  dma_direct_map_page+0xf8/0x110
[9.012632]  usb_hcd_map_urb_for_dma+0x204/0x530
[9.013149]  usb_hcd_submit_urb+0x375/0xb70
[9.013668]  usb_start_wait_urb+0x8a/0x190
[9.014188]  usb_control_msg+0xe5/0x150
[9.014693]  hub_port_init+0x21b/0xb40
[9.015190]  hub_event+0xb21/0x14f0
[9.015710]  process_one_work+0x1e5/0x390
[9.016215]  worker_thread+0x4d/0x3d0
[9.016720]  kthread+0xfd/0x130
[9.017207]  ? process_one_work+0x390/0x390
[9.017687]  ? kthread_park+0x90/0x90
[9.018163]  ret_from_fork+0x3a/0x50
[9.018642] ---[ end trace 55eaa8968ea11ab5 ]---
[9.019124] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 8 bytes), 
total 0 (slots), used 0 (slots)

cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 79
model name  : Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz
stepping: 1
microcode   : 0xb38
cpu MHz : 3353.679
cache size  : 28160 KB
physical id : 0
siblings: 44
core id : 0
cpu cores   : 22
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd ibrs ibpb 
stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle 
avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt 
cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp 
md_clear flush_l1d
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs
bogomips: 4390.26
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

lspci:

00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced 
Host Controller #2 (rev 05) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. C610/X99 series chipset USB Enhanced 
Host Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 

Re: [PATCH] NFS: Fix O_DIRECT read problem when another write is going on

[Su Yanjun]

在 2019/10/1 2:06, Trond Myklebust 写道:

Hi Su,

On Mon, 2019-09-30 at 17:11 +0800, Su Yanjun wrote:

In xfstests generic/465 tests failed. Because O_DIRECT r/w use
async rpc calls, when r/w rpc calls are running concurrently we
may read partial data which is wrong.

For example as follows.
  user buffer
/\

||

  rpc0 rpc1

When rpc0 runs it encounters eof so return 0, then another writes
something. When rpc1 runs it returns some data. The total data
buffer contains wrong data.

In this patch we check eof mark for each direct request. If
encounters
eof then set eof mark in the request, when we meet it again report
-EAGAIN error. In nfs_direct_complete we convert -EAGAIN as if read
nothing. When the reader issue another read it will read ok.

Signed-off-by: Su Yanjun 
---
  fs/nfs/direct.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 222d711..7f737a3 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -93,6 +93,7 @@ struct nfs_direct_req {
bytes_left, /* bytes left to be
sent */
error;  /* any reported error
*/
struct completion   completion; /* wait for i/o completion */
+   int eof;/* eof mark in the
req */
  
  	/* commit state */

struct nfs_mds_commit_info mds_cinfo;   /* Storage for cinfo
*/
@@ -380,6 +381,12 @@ static void nfs_direct_complete(struct
nfs_direct_req *dreq)
  {
struct inode *inode = dreq->inode;
  
+	/* read partial data just as read nothing */

+   if (dreq->error == -EAGAIN) {
+   dreq->count = 0;
+   dreq->error = 0;
+   }
+
inode_dio_end(inode);
  
  	if (dreq->iocb) {

@@ -413,8 +420,13 @@ static void nfs_direct_read_completion(struct
nfs_pgio_header *hdr)
if (hdr->good_bytes != 0)
nfs_direct_good_bytes(dreq, hdr);
  
-	if (test_bit(NFS_IOHDR_EOF, >flags))

+   if (dreq->eof)
+   dreq->error = -EAGAIN;
+
+   if (test_bit(NFS_IOHDR_EOF, >flags)) {
dreq->error = 0;
+   dreq->eof = 1;
+   }
  
  	spin_unlock(>lock);
  

Thanks for looking into this issue. I agree with your analysis of what
is going wrong in generic/465.

However, I think the problem is greater than just EOF. I think we also
need to look at the generic error handling, and ensure that it handles
a truncated RPC call in the middle of a series of calls correctly.

Please see the two patches I sent you just now and check if they fix
the problem for you.


The patchset you sent works for generic/465.

Thanks a lot

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 6:24 PM Al Viro  wrote:
>
> Ugh...  I wonder if it would be better to lift STAC/CLAC out of
> raw_copy_to_user(), rather than trying to reinvent its guts
> in readdir.c...

Yeah, I suspect that's the best option.

Do something like

 - lift STAC/CLAC out of raw_copy_to_user

 - rename it to unsafe_copy_to_user

 - create a new raw_copy_to_user that is just unsafe_copy_to_user()
with the STAC/CLAC around it.

and the end result would actually be cleanert than what we have now
(which duplicates that STAC/CLAC for each size case etc).

And then for the "architecture doesn't have user_access_begin/end()"
fallback case, we just do

   #define unsafe_copy_to_user raw_copy_to_user

and the only slight painpoint is that we need to deal with that
copy_user_generic() case too.

We'd have to mark it uaccess_safe in objtool (but we already have that
__memcpy_mcsafe and csum_partial_copy_generic, os it all makes sense),
and we'd have to make all the other copy_user_generic() cases then do
the CLAC/STAC dance too or something.

ANYWAY.  As mentioned, I'm not actually all that worried about this all.

I could easily also just see the filldir() copy do an extra

#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
if (len && (1 & (uint_ptr_t)dst)) .. copy byte ..
if (len > 1 && (2 & (uint_ptr_t)dst)) .. copy word ..
if (len > 3 && (4 & (uint_ptr_t)dst) && sizeof(unsigned long) > 4)
.. copy dword ..
#endif

at the start to align the destination.

The filldir code is actually somewhat unusual in that it deals with
pretty small strings on average, so just doing this might be more
efficient anyway.

So that doesn't worry me. Multiple ways to solve that part.

The "uhhuh, unaligned accesses cause more than performance problems" -
that's what worries me.

Linus

Re: [PATCH v4 2/5] soc: qcom: smd-rpm: Create RPM interconnect proxy child device

[Brian Masney]

On Thu, Jun 13, 2019 at 06:13:20PM +0300, Georgi Djakov wrote:
> Register a platform device to handle the communication of bus bandwidth
> requests with the remote processor. The interconnect proxy device is part
> of this remote processor (RPM) hardware. Let's create a icc-smd-rpm proxy
> child device to represent the bus throughput functionality that is provided
> by the RPM.
> 
> Signed-off-by: Georgi Djakov 

Reviewed-by: Brian Masney 
Tested-by: Brian Masney  # msm8974

I think this patch may have fell through the cracks since I don't see
it in linux-next. The qcs404 patches in this series were merged.

Brian

> ---
> 
> v4:
> - Return error if platform_device_register_data() fails
> - Remove platform_set_drvdata() on the child device.
> 
> v3:
> - New patch.
> 
>  drivers/soc/qcom/smd-rpm.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index fa9dd12b5e39..34cdd638a6c1 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -19,12 +19,14 @@
>  /**
>   * struct qcom_smd_rpm - state of the rpm device driver
>   * @rpm_channel: reference to the smd channel
> + * @icc: interconnect proxy device
>   * @ack: completion for acks
>   * @lock:mutual exclusion around the send/complete pair
>   * @ack_status:  result of the rpm request
>   */
>  struct qcom_smd_rpm {
>   struct rpmsg_endpoint *rpm_channel;
> + struct platform_device *icc;
>   struct device *dev;
>  
>   struct completion ack;
> @@ -193,6 +195,7 @@ static int qcom_smd_rpm_callback(struct rpmsg_device 
> *rpdev,
>  static int qcom_smd_rpm_probe(struct rpmsg_device *rpdev)
>  {
>   struct qcom_smd_rpm *rpm;
> + int ret;
>  
>   rpm = devm_kzalloc(>dev, sizeof(*rpm), GFP_KERNEL);
>   if (!rpm)
> @@ -205,11 +208,23 @@ static int qcom_smd_rpm_probe(struct rpmsg_device 
> *rpdev)
>   rpm->rpm_channel = rpdev->ept;
>   dev_set_drvdata(>dev, rpm);
>  
> - return of_platform_populate(rpdev->dev.of_node, NULL, NULL, 
> >dev);
> + rpm->icc = platform_device_register_data(>dev, "icc_smd_rpm", -1,
> +  NULL, 0);
> + if (IS_ERR(rpm->icc))
> + return PTR_ERR(rpm->icc);
> +
> + ret = of_platform_populate(rpdev->dev.of_node, NULL, NULL, >dev);
> + if (ret)
> + platform_device_unregister(rpm->icc);
> +
> + return ret;
>  }
>  
>  static void qcom_smd_rpm_remove(struct rpmsg_device *rpdev)
>  {
> + struct qcom_smd_rpm *rpm = dev_get_drvdata(>dev);
> +
> + platform_device_unregister(rpm->icc);
>   of_platform_depopulate(>dev);
>  }
>  

Re: [PATCH] ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360

[Takashi Iwai]

On Thu, 03 Oct 2019 06:39:19 +0200,
Kai-Heng Feng wrote:
> 
> Headphone on XPS 9350/9360 produces a background white noise. The The
> noise level somehow correlates with "Headphone Mic Boost", when it sets
> to 1 the noise disappears. However, doing this has a side effect, which
> also decreases the overall headphone volume so I didn't send the patch
> upstream.
> 
> The noise was bearable back then, but after commit 717f43d81afc ("ALSA:
> hda/realtek - Update headset mode for ALC256") the noise exacerbates to
> a point it starts hurting ears.
> 
> So let's use the workaround to set "Headphone Mic Boost" to 1 and lock
> it so it's not touchable by userspace.
> 
> Fixes: 717f43d81afc ("ALSA: hda/realtek - Update headset mode for ALC256")
> BugLink: https://bugs.launchpad.net/bugs/1654448
> BugLink: https://bugs.launchpad.net/bugs/1845810
> Signed-off-by: Kai-Heng Feng 

Applied now.  Thanks.


Takashi

Re: [RESEND TRIVIAL] sound: Fix Kconfig indentation

[Takashi Iwai]

On Fri, 04 Oct 2019 16:49:31 +0200,
Krzysztof Kozlowski wrote:
> 
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Mark Brown 

Applied now.  Sorry for the late reaction, as I've been (still)
traveling.

Thanks.


Takashi

[PATCH V6 4/5] arm64: dts: imx8qxp-mek: Enable scu key

[Anson Huang]

Enable scu key for i.MX8QXP MEK board.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts 
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..88dd9132 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
 _dsp {
status = "okay";
 };
+
+_key {
+   status = "okay";
+};
-- 
2.7.4

[PATCH V6 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_KEY as module

[Anson Huang]

Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to
support i.MX8QXP scu key driver.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c9adae4..9062d57 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -314,6 +314,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_ADC=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_SNVS_PWRKEY=m
+CONFIG_KEYBOARD_IMX_SC_KEY=m
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=m
-- 
2.7.4

[PATCH V6 1/5] dt-bindings: fsl: scu: add scu key binding

[Anson Huang]

NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for i.MX system controller
key driver.

Signed-off-by: Anson Huang 
Reviewed-by: Rob Herring 
---
Changes since V5:
- use "linux,keycodes" instead of "linux,keycode" in example.
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index c149fad..70c1a62 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -157,6 +157,15 @@ Required properties:
 Optional properties:
 - timeout-sec: contains the watchdog timeout in seconds.
 
+SCU key bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+  "fsl,imx8qxp-sc-key"
+  followed by "fsl,imx-sc-key";
+- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
+
 Example (imx8qxp):
 -
 aliases {
@@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
 
+   scu_key: scu-key {
+   compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+   linux,keycodes = ;
+   };
+
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
-- 
2.7.4

[PATCH V6 2/5] input: keyboard: imx_sc: Add i.MX system controller key support

[Anson Huang]

i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..

Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key's status.

Signed-off-by: Anson Huang 
---
Changes since V5:
- use "linux,keycodes" instead of "linux,keycode" according to DT 
change.
---
 drivers/input/keyboard/Kconfig  |   7 ++
 drivers/input/keyboard/Makefile |   1 +
 drivers/input/keyboard/imx_sc_key.c | 184 
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/input/keyboard/imx_sc_key.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 8911bc2..00f8428 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -469,6 +469,13 @@ config KEYBOARD_IMX
  To compile this driver as a module, choose M here: the
  module will be called imx_keypad.
 
+config KEYBOARD_IMX_SC_KEY
+   tristate "IMX SCU Key Driver"
+   depends on IMX_SCU
+   help
+ This is the system controller key driver for NXP i.MX SoCs with
+ system controller inside.
+
 config KEYBOARD_NEWTON
tristate "Newton keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 9510325..f5b1752 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL)+= hil_kbd.o
 obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
 obj-$(CONFIG_KEYBOARD_IPAQ_MICRO)  += ipaq-micro-keys.o
 obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
+obj-$(CONFIG_KEYBOARD_IMX_SC_KEY)  += imx_sc_key.o
 obj-$(CONFIG_KEYBOARD_HP6XX)   += jornada680_kbd.o
 obj-$(CONFIG_KEYBOARD_HP7XX)   += jornada720_kbd.o
 obj-$(CONFIG_KEYBOARD_LKKBD)   += lkkbd.o
diff --git a/drivers/input/keyboard/imx_sc_key.c 
b/drivers/input/keyboard/imx_sc_key.c
new file mode 100644
index 000..a357346
--- /dev/null
+++ b/drivers/input/keyboard/imx_sc_key.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEBOUNCE_TIME  30
+#define REPEAT_INTERVAL60
+
+#define SC_IRQ_BUTTON  1
+#define SC_IRQ_GROUP_WAKE  3
+#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
+
+struct imx_key_drv_data {
+   int keycode;
+   bool keystate;  /* 1: pressed, 0: release */
+   struct delayed_work check_work;
+   struct input_dev *input;
+   struct imx_sc_ipc *key_ipc_handle;
+   struct notifier_block key_notifier;
+};
+
+struct imx_sc_msg_key {
+   struct imx_sc_rpc_msg hdr;
+   u8 state;
+};
+
+static int imx_sc_key_notify(struct notifier_block *nb,
+unsigned long event, void *group)
+{
+   struct imx_key_drv_data *priv =
+container_of(nb,
+ struct imx_key_drv_data,
+ key_notifier);
+
+   if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)) {
+   schedule_delayed_work(>check_work,
+ msecs_to_jiffies(DEBOUNCE_TIME));
+   pm_wakeup_event(priv->input->dev.parent, 0);
+   }
+
+   return 0;
+}
+
+static void imx_sc_check_for_events(struct work_struct *work)
+{
+   struct imx_key_drv_data *priv =
+container_of(work,
+ struct imx_key_drv_data,
+ check_work.work);
+   struct input_dev *input = priv->input;
+   struct imx_sc_msg_key msg;
+   struct imx_sc_rpc_msg *hdr = 
+   bool state;
+   int error;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_MISC;
+   hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
+   hdr->size = 1;
+
+   error = imx_scu_call_rpc(priv->key_ipc_handle, , true);
+   if (error) {
+   dev_err(>dev, "read imx sc key failed, error %d\n", 
error);
+   return;
+   }
+
+   state = (bool)msg.state;
+
+   if (state ^ priv->keystate) {
+   priv->keystate = state;
+   input_event(input, EV_KEY, priv->keycode, state);
+   input_sync(input);
+   if (!priv->keystate)
+   pm_relax(priv->input->dev.parent);
+   }
+
+   if (state)
+   schedule_delayed_work(>check_work,
+ msecs_to_jiffies(REPEAT_INTERVAL));
+}
+
+static int imx_sc_key_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   static 

[PATCH V6 3/5] arm64: dts: imx8qxp: Add scu key node

[Anson Huang]

Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.

Signed-off-by: Anson Huang 
---
Changes since V5:
- use "linux,keycodes" instead of "linux,keycode".
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..2d69f1a 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -174,6 +175,12 @@
#power-domain-cells = <1>;
};
 
+   scu_key: scu-key {
+   compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+   linux,keycodes = ;
+   status = "disabled";
+   };
+
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
-- 
2.7.4

RE: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding

[Anson Huang]

Hi, Shawn

> On Mon, Sep 23, 2019 at 02:34:07AM +, Anson Huang wrote:
> > Hi, Pavel
> >
> > > Subject: Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key
> > > binding
> > >
> > > On Tue 2019-09-03 10:03:40, Anson Huang wrote:
> > > > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> > > > system controller, the system controller is in charge of system
> > > > power, clock and power key event etc. management, Linux kernel has
> > > > to communicate with system controller via MU (message unit) IPC to
> > > > get power key event, add binding doc for i.MX system controller power
> key driver.
> > > >
> > > > Signed-off-by: Anson Huang 
> > > > ---
> > > > Changes since V1:
> > > > - remove "wakeup-source" property, as it is NOT needed for SCU
> > > interrupt;
> > > > - remove "status" in example.
> > > > ---
> > > >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 14
> > > ++
> > > >  1 file changed, 14 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > index c149fad..f93e2e4 100644
> > > > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > @@ -157,6 +157,15 @@ Required properties:
> > > >  Optional properties:
> > > >  - timeout-sec: contains the watchdog timeout in seconds.
> > > >
> > > > +Power key bindings based on SCU Message Protocol
> > > > +
> > > > +
> > > > +Required properties:
> > > > +- compatible: should be:
> > > > +  "fsl,imx8qxp-sc-pwrkey"
> > > > +  followed by "fsl,imx-sc-pwrkey";
> > > > +- linux,keycodes: See
> > > > +Documentation/devicetree/bindings/input/keys.txt
> > >
> > > Note you have keycode_s_ here, but keycode in the example and in the
> > > dts patch.
> >
> > NOT quite understand your point, could you please provide more details?
> 
> The property being used in driver, DTS, and DT example in the bindings are
> all 'linux,keycode' rather than 'linux,keycodes'.

I see now, since Documentation/devicetree/bindings/input/keys.txt uses 
"linux,keycodes",
so I will also use "linux,keycodes" for driver, DTS and DT example in V3.

Thanks,
Anson

Re: [PATCH] rcu/nocb: Fix dump_tree hierarchy print always active

[Paul E. McKenney]

On Fri, Oct 04, 2019 at 03:24:02PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 04, 2019 at 07:49:10PM +, Stefan Reiter wrote:
> > Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
> > dump_tree") added print statements to rcu_organize_nocb_kthreads for
> > debugging, but incorrectly guarded them, causing the function to always
> > spew out its message.
> > 
> > This patch fixes it by guarding both pr_alert statements with dump_tree,
> > while also changing the second pr_alert to a pr_cont, to print the
> > hierarchy in a single line (assuming that's how it was supposed to
> > work).
> > 
> > Fixes: 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if dump_tree")
> > Signed-off-by: Stefan Reiter 
> 
> Queued for testing and review, thank you!

And here is an updated version to make the special case of a nocb GP
kthread having no other nocb CB kthreads look less strange.  Does this
work for you?

Thanx, Paul



commit e6223b0705369750990c32ddc80251942e61be30
Author: Stefan Reiter 
Date:   Fri Oct 4 19:49:10 2019 +

rcu/nocb: Fix dump_tree hierarchy print always active

Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
dump_tree") added print statements to rcu_organize_nocb_kthreads for
debugging, but incorrectly guarded them, causing the function to always
spew out its message.

This patch fixes it by guarding both pr_alert statements with dump_tree,
while also changing the second pr_alert to a pr_cont, to print the
hierarchy in a single line (assuming that's how it was supposed to
work).

Fixes: 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if dump_tree")
Signed-off-by: Stefan Reiter 
[ paulmck: Make single-nocbs-CPU GP kthreads look less erroneous. ]
Signed-off-by: Paul E. McKenney 

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index d5334e4..d43f4e0 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2295,6 +2295,8 @@ static void __init rcu_organize_nocb_kthreads(void)
 {
int cpu;
bool firsttime = true;
+   bool gotnocbs = false;
+   bool gotnocbscbs = true;
int ls = rcu_nocb_gp_stride;
int nl = 0;  /* Next GP kthread. */
struct rcu_data *rdp;
@@ -2317,21 +2319,31 @@ static void __init rcu_organize_nocb_kthreads(void)
rdp = per_cpu_ptr(_data, cpu);
if (rdp->cpu >= nl) {
/* New GP kthread, set up for CBs & next GP. */
+   gotnocbs = true;
nl = DIV_ROUND_UP(rdp->cpu + 1, ls) * ls;
rdp->nocb_gp_rdp = rdp;
rdp_gp = rdp;
-   if (!firsttime && dump_tree)
-   pr_cont("\n");
-   firsttime = false;
-   pr_alert("%s: No-CB GP kthread CPU %d:", __func__, cpu);
+   if (dump_tree) {
+   if (!firsttime)
+   pr_cont("%s\n", gotnocbscbs
+   ? "" : " (self only)");
+   gotnocbscbs = false;
+   firsttime = false;
+   pr_alert("%s: No-CB GP kthread CPU %d:",
+__func__, cpu);
+   }
} else {
/* Another CB kthread, link to previous GP kthread. */
+   gotnocbscbs = true;
rdp->nocb_gp_rdp = rdp_gp;
rdp_prev->nocb_next_cb_rdp = rdp;
-   pr_alert(" %d", cpu);
+   if (dump_tree)
+   pr_cont(" %d", cpu);
}
rdp_prev = rdp;
}
+   if (gotnocbs && dump_tree)
+   pr_cont("%s\n", gotnocbscbs ? "" : " (self only)");
 }
 
 /*

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Al Viro]

On Sun, Oct 06, 2019 at 06:17:02PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck  wrote:
> >
> > All my alpha, sparc64, and xtensa tests pass with the attached patch
> > applied on top of v5.4-rc2. I didn't test any others.
> 
> Okay... I really wish my guess had been wrong.
> 
> Because fixing filldir64 isn't the problem. I can come up with
> multiple ways to avoid the unaligned issues if that was the problem.
> 
> But it does look to me like the fundamental problem is that unaligned
> __put_user() calls might just be broken on alpha (and likely sparc
> too). Because that looks to be the only difference between the
> __copy_to_user() approach and using unsafe_put_user() in a loop.
> 
> Now, I should have handled unaligned things differently in the first
> place, and in that sense I think commit 9f79b78ef744 ("Convert
> filldir[64]() from __put_user() to unsafe_put_user()") really is
> non-optimal on architectures with alignment issues.
> 
> And I'll fix it.

Ugh...  I wonder if it would be better to lift STAC/CLAC out of
raw_copy_to_user(), rather than trying to reinvent its guts
in readdir.c...

Re: MAP_FIXED_NOREPLACE appears to break older i386 binaries

[Kees Cook]

On Sun, Oct 06, 2019 at 02:14:59PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 11:07 AM Linus Torvalds
>  wrote:
> >
> > Yes, we should get this fixed. But I continue to ask you to point to
> > the actual binaries for testing..
> 
> Just to bring the resolution back publicly to lkml after rmk sent me
> test binaries in private email, the end result is commit b212921b13bd
> ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings").

Unsurprisingly, I'm not a fan of reverting that patch, but obviously we
must since it breaks old userspace. :) I'm travelling tomorrow, so if
Michal doesn't fix it before I'm back, I'll take a stab at it. I'd like
to retain the general best-effort-defense of "don't let mappings collide"
but I think it'll require us retaining more details about what the ELF
told us to collide with. (i.e. the LOADs can collide, but not into
stack, brk, etc.)

And better yet, we need self-tests here. execve has SO many corner
cases... I'd like to figure out some way to capture all these.

-- 
Kees Cook

RE: [PATCH] firmware: imx: Skip return value check for some special SCU firmware APIs

[Anson Huang]

Hi, Marco

> On 19-09-30 08:32, Anson Huang wrote:
> > Hi, Marco
> >
> > > On 19-09-30 07:42, Anson Huang wrote:
> > > > Hi, Leonard
> > > >
> > > > > On 2019-09-27 4:20 AM, Anson Huang wrote:
> > > > > >> On 2019-09-26 1:06 PM, Marco Felsch wrote:
> > > > > >>> On 19-09-26 08:03, Anson Huang wrote:
> > > > > > On 19-09-25 18:07, Anson Huang wrote:
> > > > > >> The SCU firmware does NOT always have return value stored
> > > > > >> in message header's function element even the API has
> > > > > >> response data, those special APIs are defined as void
> > > > > >> function in SCU firmware, so they should be treated as return
> success always.
> > > > > >>
> > > > > >> +static const struct imx_sc_rpc_msg whitelist[] = {
> > > > > >> +  { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > > > > > IMX_SC_MISC_FUNC_UNIQUE_ID },
> > > > > >> +  { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > > > > >> +IMX_SC_MISC_FUNC_GET_BUTTON_STATUS }, };
> > > > > >
> > > > > > Is this going to be extended in the near future? I see
> > > > > > some upcoming problems here if someone uses a different
> > > > > > scu-fw<->kernel combination as nxp would suggest.
> > > > > 
> > > > >  Could be, but I checked the current APIs, ONLY these 2 will
> > > > >  be used in Linux kernel, so I ONLY add these 2 APIs for now.
> > > > > >>>
> > > > > >>> Okay.
> > > > > >>>
> > > > >  However, after rethink, maybe we should add another
> > > > >  imx_sc_rpc API for those special APIs? To avoid checking it
> > > > >  for all the APIs called which
> > > > > >> may impact some performance.
> > > > >  Still under discussion, if you have better idea, please advise,
> thanks!
> > > > > >>
> > > > > >> My suggestion is to refactor the code and add a new API for
> > > > > >> the this "no error value" convention. Internally they can
> > > > > >> call a common function with flags.
> > > > > >
> > > > > > If I understand your point correctly, that means the loop
> > > > > > check of whether the API is with "no error value" for every
> > > > > > API still NOT be skipped, it is just refactoring the code, right?
> > > > >
> > > > > There would be no "loop" anywhere: the responsibility would fall
> > > > > on the call to call the right RPC function. In the current
> > > > > layering scheme (drivers -> RPC ->
> > > > > mailbox) the RPC layer treats all calls the same and it's up the
> > > > > the caller to provide information about calling convention.
> > > > >
> > > > > An example implementation:
> > > > > * Rename imx_sc_rpc_call to __imx_sc_rpc_call_flags
> > > > > * Make a tiny imx_sc_rpc_call wrapper which just converts
> > > > > resp/noresp to a flag
> > > > > * Make get button status call __imx_sc_rpc_call_flags with the
> > > > > _IMX_SC_RPC_NOERROR flag
> > > > >
> > > > > Hope this makes my suggestion clearer? Pushing this to the
> > > > > caller is a bit ugly but I think it's worth preserving the fact
> > > > > that the imx rpc core treats services in an uniform way.
> > > >
> > > > It is clear now, so essentially it is same as 2 separate APIs,
> > > > still need to change the button driver and uid driver to use the
> > > > special flag, meanwhile, need to change the third parament of
> > > > imx_sc_rpc_call()
> > > from bool to u32.
> > > >
> > > > If no one opposes this approach, I will redo the patch together
> > > > with the button driver and uid driver after holiday.
> > >
> > > As Ansons said that are two approaches and in both ways the caller
> > > needs to know if the error code is valid. Extending the flags seems
> > > better to me but it looks still not that good. One question, does
> > > the scu-fw set the error-msg to something? If not than why should we
> specify a flag or a other api?
> > > Nowadays the caller needs to know that the error-msg-field isn't set
> > > so if the caller sets the msg-packet to zero and fills the rpc-id
> > > the error-msg-field shouldn't be touched by the firmware. So it should be
> zero.
> >
> > The flow are as below for those special APIs with response data but no
> return value from SCU FW:
> >
> > 1. caller sends msg with a header field and data field, the header
> > field has svc ID and function ID; 2. SCU FW will service the caller
> > and then clear the SVC ID before return, the response data will be Put
> > in msg data field, and if the APIs has return value, SCU FW will put
> > the return value in function ID of msg;
> 
> Thanks for the declaration :)
> 
> > The caller has no chance to set the msg-packet to zero and rpc-id, it
> > needs to pass correct rpc-id to SCU FW and Get response data from SCU
> > FW, and for those special APIs has function ID NOT over-written by SCU
> > FW's return Value, but the function ID is a unsigned int, and the SCU FW
> return value is also a unsigned int, so we have no idea to separate them for
> no-return value API or error-return API.
> 
> I see.
> 
> > With new approach, I can use 

[PATCH V2] firmware: imx: Skip return value check for some special SCU firmware APIs

[Anson Huang]

The SCU firmware does NOT always have return value stored in message
header's function element even the API has response data, those special
APIs are defined as void function in SCU firmware, so they should be
treated as return success always.

Signed-off-by: Anson Huang 
---
Changes since V1:
- Use direct API check instead of calling another function to check.
- This patch is based on https://patchwork.kernel.org/patch/11129553/
---
 drivers/firmware/imx/imx-scu.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 869be7a..03b43b7 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -162,6 +162,7 @@ static int imx_scu_ipc_write(struct imx_sc_ipc *sc_ipc, 
void *msg)
  */
 int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, bool have_resp)
 {
+   uint8_t saved_svc, saved_func;
struct imx_sc_rpc_msg *hdr;
int ret;
 
@@ -171,8 +172,11 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, 
bool have_resp)
mutex_lock(_ipc->lock);
reinit_completion(_ipc->done);
 
-   if (have_resp)
+   if (have_resp) {
sc_ipc->msg = msg;
+   saved_svc = ((struct imx_sc_rpc_msg *)msg)->svc;
+   saved_func = ((struct imx_sc_rpc_msg *)msg)->func;
+   }
sc_ipc->count = 0;
ret = imx_scu_ipc_write(sc_ipc, msg);
if (ret < 0) {
@@ -191,6 +195,16 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, 
bool have_resp)
/* response status is stored in hdr->func field */
hdr = msg;
ret = hdr->func;
+   /*
+* Some special SCU firmware APIs do NOT have return value
+* in hdr->func, but they do have response data, those special
+* APIs are defined as void function in SCU firmware, so they
+* should be treated as return success always.
+*/
+   if ((saved_svc == IMX_SC_RPC_SVC_MISC) &&
+   (saved_func == IMX_SC_MISC_FUNC_UNIQUE_ID ||
+saved_func == IMX_SC_MISC_FUNC_GET_BUTTON_STATUS))
+   ret = 0;
}
 
 out:
-- 
2.7.4

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 5:04 PM Guenter Roeck  wrote:
>
> All my alpha, sparc64, and xtensa tests pass with the attached patch
> applied on top of v5.4-rc2. I didn't test any others.

Okay... I really wish my guess had been wrong.

Because fixing filldir64 isn't the problem. I can come up with
multiple ways to avoid the unaligned issues if that was the problem.

But it does look to me like the fundamental problem is that unaligned
__put_user() calls might just be broken on alpha (and likely sparc
too). Because that looks to be the only difference between the
__copy_to_user() approach and using unsafe_put_user() in a loop.

Now, I should have handled unaligned things differently in the first
place, and in that sense I think commit 9f79b78ef744 ("Convert
filldir[64]() from __put_user() to unsafe_put_user()") really is
non-optimal on architectures with alignment issues.

And I'll fix it.

But at the same time, the fact that "non-optimal" turns into "doesn't
work" is a fairly nasty issue.

> I'll (try to) send you some disassembly next.

Thanks, verified.

The "ra is at filldir64+0x64/0x320" is indeed right at the return
point of the "jsr verify_dirent_name".

But the problem isn't there - that's just left-over state. I'm pretty
sure that function worked fine, and returned.

The problem is that "pc is at 0x4" and the page fault that then
happens at that address as a result.

And that seems to be due to this:

 8c0:   00 00 29 2c ldq_u   t0,0(s0)
 8c4:   07 00 89 2c ldq_u   t3,7(s0)
 8c8:   03 04 e7 47 mov t6,t2
 8cc:   c1 06 29 48 extql   t0,s0,t0
 8d0:   44 0f 89 48 extqh   t3,s0,t3
 8d4:   01 04 24 44 or  t0,t3,t0
 8d8:   00 00 22 b4 stq t0,0(t1)

that's the "get_unaligned((type *)src)" (the first six instructions)
followed by the "unsafe_put_user()" done with a single "stq". That's
the guts of the unsafe_copy_loop() as part of
unsafe_copy_dirent_name()

And what I think happens is that it is writing to user memory that is

 (a) unaligned

 (b) not currently mapped in user space

so then the do_entUna() function tries to handle the unaligned trap,
but then it takes an exception while doing that (due to the unmapped
page), and then something in that nested exception mess causes it to
mess up badly and corrupt the register contents on stack, and it
returns with garbage in 'pc', and then you finally die with that

   Unable to handle kernel paging request at virtual address 0004
   pc is at 0x4

thing.

And yes, I'll fix that name copy loop in filldir to align the
destination first, *but* if I'm right, it means that something like
this should also likely cause issues:

  #define _GNU_SOURCE
  #include 
  #include 

  int main(int argc, char **argv)
  {
void *mymap;
uid_t *bad_ptr = (void *) 0x01;

/* Create unpopulated memory area */
mymap = mmap(NULL, 16384, PROT_READ | PROT_WRITE, MAP_PRIVATE
| MAP_ANONYMOUS, -1, 0);

/* Unaligned uidpointer in that memory area */
bad_ptr = mymap+1;

/* Make the kernel do put_user() on it */
return getresuid(bad_ptr, bad_ptr+1, bad_ptr+2);
  }

because that simple user mode program should cause that same "page
fault on unaligned put_user()" behavior as far as I can tell.

Mind humoring me and trying that on your alpha machine (or emulator,
or whatever)?

   Linus

Re: [PATCH v6 01/12] tools lib traceevent: Convert remaining %p[fF] users to %p[sS]

[Steven Rostedt]

On Tue, 10 Sep 2019 11:42:06 -0700
Joe Perches  wrote:

> On Tue, 2019-09-10 at 14:26 -0400, Steven Rostedt wrote:
> > On Tue, 10 Sep 2019 10:18:44 -0700
> > Joe Perches  wrote:
> >   
> > > > It's not just for the lastest kernel. We must maintain backward
> > > > compatibility here too. If there use to be a usage of this, then we
> > > > must keep it until the kernels are no longer used (perhaps 7 years?)
> > > 
> > > That argues for not using "%pfw" at all for some number of years.
> > > 
> > > Perhaps the '%pfw' should be '%pnfw' for 'name' and 'fwnode'  
> >
> >   -ENOCOMPREHENSION  
> 
> Perhaps you were not copied on the whole series.
> 
> https://lore.kernel.org/lkml/20190910084707.18380-1-sakari.ai...@linux.intel.com/

Thanks for the link.

> 
> As I understand it, Sakair Ailus is proposing to
> obsolete the current vsprintf "%p[Ff]" extension
> and replace the usage with a new "%pfw" extension
> which would emit the name of a pointer to "struct fwnode {}".
> 
> https://lore.kernel.org/lkml/20190910084707.18380-10-sakari.ai...@linux.intel.com/
> 
> If reusing "%pf" is a problem, then instead
> it might be reasonable to have a new "%pn" for
> that use instead.
> 
> btw:
> 
> Is there kernel version information available in
> trace output files?

Not really. This is just a library that parses the trace event formats,
there's not kernel versions passed in, but we do use variations in
formats and such to determine what is supported.

> 
> If so, it might be reasonable to change the tooling
> there instead.
> 

Actually, I think we could just look to see if "%pfw" is used and fall
to that, otherwise consider it an older kernel and do it the original
way.

-- Steve

[ANNOUNCE] autofs 5.1.6 release

[Ian Kent]

Hi all,

It's time for a release, autofs-5.1.6.

This is an important release because it marks the beginning of
work to be done torward resolving the very long standing problem
of using very large direct mount maps in autofs, along with the
needed mitigatigation of the effects of those large mount tables
in user space.

The first thing that needs to be done is for autofs to get back
to what is was before the symlinking of the mount table to the
proc file system. From experience having a large number of (largely
not useful) autofs mount entries showing up in the mount table
makes system administation frustrating and is quite annoying.

To do this I'm using the same approach used in other SysV autofs
implementations of providing an autofs pseudo mount option "ignore"
that can be used by user space as a hint to ignore these mount
entries.

This will require fairly straight forward changes to glibc and
libmount at least. The glibc change has been accepted and I plan
on submitting a change for libmount when I get a chance.

A configuration option, use_ignore_mount_option, has been added
to autofs that is initially disabled to allow people to enable it
when they are confident that there won't be unexpected problems.

The side effects of very large mount tables in user space is
somewhat difficult to mitigate.

First, to acheive this autofs needs to not use the system mount
table for expiration "at all". Not using the mount table for expires
has proven very difficult to do and initial attempts resulted in
changes that didn't fit in well at all.

The changes to clean up the mount table listing amounted to making
autofs use it's own genmntent(3) implementation (borrowed from glibc)
but quite a bit of that change was re-factoring toward eliminating
the need to use the mount table during expires. I had trouble getting
that to work, let alone stable, but the approach will fit in well
with the current design so it's progress.

Then there's the affect of very large mount tables on other user
space applications.

For example, under rapid mount activity we see several user space
process, systemd, udisk2, et. al., growing to consume all available
CPU and a couple of others performing poorly simply because the
mount table is large.

I had planned on using the fsinfo() system call being proposed by
David Howells for initial mount handing improvements in libmount,
and later David's related kernel notifications proposal for further
libmount mount table handling improvements but those propsals have
seen some challenges being accepted so we will have to wait and see
how things go before working out how to acheive this rather difficult
goal.

So there's a long way to go but progress is bieng made!

Additionally there are a number of bug fixes and other minor
improvements.

autofs
==

The package can be found at:
https://www.kernel.org/pub/linux/daemons/autofs/v5/

It is autofs-5.1.6.tar.[gz|xz]

No source rpm is there as it can be produced by using:

rpmbuild -ts autofs-5.1.6.tar.gz

and the binary rpm by using:

rpmbuild -tb autofs-5.1.6.tar.gz

Here are the entries from the CHANGELOG which outline the updates:

07/10/2019 autofs-5.1.6
- support strictexpire mount option.
- fix hesiod string check in master_parse().
- add NULL check for get_addr_string() return.
- use malloc(3) in spawn.c.
- add mount_verbose configuration option.
- optionally log mount requestor process info.
- log mount call arguments if mount_verbose is set.
- Fix NFS mount from IPv6 addresses.
- make expire remaining log level debug.
- allow period following macro in selector value.
- fix macro expansion in selector values.
- fix typing errors.
- Explain /etc/auto.master.d usage.
- plus map includes are only allowed in file sources.
- Update README.
- fix additional typing errors.
- update autofs(8) offset map entry update description.
- increase group buffer size geometrically.
- also use strictexpire for offsets.
- remove unused function has_fstab_option().
- remove unused function reverse_mnt_list().
- remove a couple of old debug messages.
- fix amd entry memory leak.
- fix unlink_mount_tree() not umounting mounts.
- use ignore option for offset mounts as well.
- add config option for "ignore" mount option
- use bit flags for autofs mount types in mnt_list.
- use mp instead of path in mnt_list entries.
- always use PROC_MOUNTS to make mount lists.
- add glibc getmntent_r().
- use local getmntent_r in table_is_mounted().
- refactor unlink_active_mounts() in direct.c.
- don't use tree_is_mounted() for mounted checks.
- use single unlink_umount_tree() for both direct and indirect mounts.
- move unlink_mount_tree() to lib/mounts.c.
- use local_getmntent_r() for unlink_mount_tree().
- use local getmntent_r() in get_mnt_list().
- use local getmntent_r() in tree_make_mnt_list().
- fix missing initialization of autofs_point flags.

Ian

RE: [PATCH] ARM: dts: imx7s: Correct GPT's ipg clock source

[Anson Huang]

Hi, Shawn

> On Mon, Sep 16, 2019 at 04:29:09PM +0800, Anson Huang wrote:
> > i.MX7S/D's GPT ipg clock should be from GPT clock root and controlled
> > by CCM's GPT CCGR, using correct clock source for GPT ipg clock
> > instead of IMX7D_CLK_DUMMY.
> 
> So both 'ipg' and 'per' clock are coming from GPT root clock?

Yes.

> 
> > Signed-off-by: Anson Huang 
> 
> It looks like a fix, so do we need a Fixes tag here?

Sure, will add a fixes tag in V2.

Thanks,
Anson.

[PATCH V2] ARM: dts: imx7s: Correct GPT's ipg clock source

[Anson Huang]

i.MX7S/D's GPT ipg clock should be from GPT clock root and
controlled by CCM's GPT CCGR, using correct clock source for
GPT ipg clock instead of IMX7D_CLK_DUMMY.

Fixes: 3ef79ca6bd1d ("ARM: dts: imx7d: use imx7s.dtsi as base device tree")
Signed-off-by: Anson Huang 
---
Changes since V1:
- Add Fixes tag.
---
 arch/arm/boot/dts/imx7s.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 710f850..e2e604d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -448,7 +448,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302d 0x1>;
interrupts = ;
-   clocks = < IMX7D_CLK_DUMMY>,
+   clocks = < IMX7D_GPT1_ROOT_CLK>,
 < IMX7D_GPT1_ROOT_CLK>;
clock-names = "ipg", "per";
};
@@ -457,7 +457,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302e 0x1>;
interrupts = ;
-   clocks = < IMX7D_CLK_DUMMY>,
+   clocks = < IMX7D_GPT2_ROOT_CLK>,
 < IMX7D_GPT2_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
@@ -467,7 +467,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302f 0x1>;
interrupts = ;
-   clocks = < IMX7D_CLK_DUMMY>,
+   clocks = < IMX7D_GPT3_ROOT_CLK>,
 < IMX7D_GPT3_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
@@ -477,7 +477,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x3030 0x1>;
interrupts = ;
-   clocks = < IMX7D_CLK_DUMMY>,
+   clocks = < IMX7D_GPT4_ROOT_CLK>,
 < IMX7D_GPT4_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
-- 
2.7.4

Re: [PATCH] media: vimc: Make capture devices and subdevices use different link_validates

[Helen Koike]

Hi Nícolas,

Thanks for you patch, just some small comments below.

On 10/6/19 4:14 PM, Nícolas F. R. A. Prado wrote:
> Instead of validating the links to capture devices and subdevices with
> the same function, use the default v4l function for links between
> subdevices and only use a different function for validating between
> capture device and subdevice.
> This change should also ease future work to associate multiple mbus
> codes for the same pixelformat in vimc_pix_map.
> 
> These changes were tested with 
> v4l2-compliance SHA: 3f806630e2ecbcebe31872b865c5c4b42f111a99, 64 bits
> and passed all tests:
> Grand Total for vimc device /dev/media0: 451, Succeeded: 451, Failed: 0, 
> Warnings: 0
> 
> Signed-off-by: Nícolas F. R. A. Prado 
> ---
>  drivers/media/platform/vimc/vimc-capture.c |  78 +++-
>  drivers/media/platform/vimc/vimc-common.c  | 103 -
>  drivers/media/platform/vimc/vimc-common.h  |   3 +
>  3 files changed, 96 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/media/platform/vimc/vimc-capture.c 
> b/drivers/media/platform/vimc/vimc-capture.c
> index 602f80323031..924b99f82123 100644
> --- a/drivers/media/platform/vimc/vimc-capture.c
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -321,8 +321,84 @@ static const struct vb2_ops vimc_cap_qops = {
>   .wait_finish= vb2_ops_wait_finish,
>  };
>  
> +int vimc_cap_link_validate(struct media_link *link)

This function is only used inside the capture, it could be static.

Unless if you want to make it a generic function in vimc-common.h, so the future
output device could use it as well, but it can be done in the output patch.


> +{
> + struct v4l2_pix_format source_fmt, sink_fmt;
> + int ret;
> +
> + ret = vimc_get_pix_format(link->source, _fmt);
> + if (ret)
> + return ret;
> +
> + ret = vimc_get_pix_format(link->sink, _fmt);
> + if (ret)
> + return ret;
> +
> + pr_info("vimc link validate: "
> + "%s:src:%dx%d (0x%x, %d, %d, %d, %d) "
> + "%s:snk:%dx%d (0x%x, %d, %d, %d, %d)\n",
> + /* src */
> + link->source->entity->name,
> + source_fmt.width, source_fmt.height,
> + source_fmt.pixelformat, source_fmt.colorspace,
> + source_fmt.quantization, source_fmt.xfer_func,
> + source_fmt.ycbcr_enc,
> + /* sink */
> + link->sink->entity->name,
> + sink_fmt.width, sink_fmt.height,
> + sink_fmt.pixelformat, sink_fmt.colorspace,
> + sink_fmt.quantization, sink_fmt.xfer_func,
> + sink_fmt.ycbcr_enc);
> +
> + /* The width, height and pixelformat must match. */
> + if (source_fmt.width != sink_fmt.width
> + || source_fmt.height != sink_fmt.height
> + || source_fmt.pixelformat != sink_fmt.pixelformat)
> + return -EPIPE;
> +
> + /*
> +  * The field order must match, or the sink field order must be NONE
> +  * to support interlaced hardware connected to bridges that support
> +  * progressive formats only.
> +  */
> + if (source_fmt.field != sink_fmt.field &&
> + sink_fmt.field != V4L2_FIELD_NONE)
> + return -EPIPE;
> +
> + /*
> +  * If colorspace is DEFAULT, then assume all the colorimetry is also
> +  * DEFAULT, return 0 to skip comparing the other colorimetry parameters
> +  */
> + if (source_fmt.colorspace == V4L2_COLORSPACE_DEFAULT
> + || sink_fmt.colorspace == V4L2_COLORSPACE_DEFAULT)
> + return 0;
> +
> + /* Colorspace must match. */
> + if (source_fmt.colorspace != sink_fmt.colorspace)
> + return -EPIPE;
> +
> + /* Colorimetry must match if they are not set to DEFAULT */
> + if (source_fmt.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
> + && sink_fmt.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
> + && source_fmt.ycbcr_enc != sink_fmt.ycbcr_enc)
> + return -EPIPE;
> +
> + if (source_fmt.quantization != V4L2_QUANTIZATION_DEFAULT
> + && sink_fmt.quantization != V4L2_QUANTIZATION_DEFAULT
> + && source_fmt.quantization != sink_fmt.quantization)
> + return -EPIPE;
> +
> + if (source_fmt.xfer_func != V4L2_XFER_FUNC_DEFAULT
> + && sink_fmt.xfer_func != V4L2_XFER_FUNC_DEFAULT
> + && source_fmt.xfer_func != sink_fmt.xfer_func)
> + return -EPIPE;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vimc_cap_link_validate);

No need to export it here.

> +
>  static const struct media_entity_operations vimc_cap_mops = {
> - .link_validate  = vimc_link_validate,
> + .link_validate  = vimc_cap_link_validate,
>  };
>  
>  static void vimc_cap_release(struct video_device *vdev)
> diff --git a/drivers/media/platform/vimc/vimc-common.c 
> b/drivers/media/platform/vimc/vimc-common.c
> index a3120f4f7a90..fe91d67811e5 100644
> --- 

krzysztof/for-next boot bisection: v5.4-rc1-48-g0bc9c79979ea on peach-pi

[kernelci.org bot]

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis  *
* that you may be involved with the breaking commit it has  *
* found.  No manual investigation has been done to verify it,   *
* and the root cause of the problem may be somewhere else.  *
*   *
* If you do send a fix, please include this trailer:*
*   Reported-by: "kernelci.org bot"   *
*   *
* Hope this helps!  *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

krzysztof/for-next boot bisection: v5.4-rc1-48-g0bc9c79979ea on peach-pi

Summary:
  Start:  0bc9c79979ea Merge branch 'for-v5.5/memory-samsung-dmc-dt' into 
for-next
  Details:https://kernelci.org/boot/id/5d9a50af59b5141ce5857c07
  Plain log:  
https://storage.kernelci.org//krzysztof/for-next/v5.4-rc1-48-g0bc9c79979ea/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5800-peach-pi.txt
  HTML log:   
https://storage.kernelci.org//krzysztof/for-next/v5.4-rc1-48-g0bc9c79979ea/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5800-peach-pi.html
  Result: 0899a480ac65 ARM: dts: exynos: Add initial data for coupled 
regulators for Exynos5422/5800

Checks:
  revert: PASS
  verify: PASS

Parameters:
  Tree:   krzysztof
  URL:https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
  Branch: for-next
  Target: peach-pi
  CPU arch:   arm
  Lab:lab-collabora
  Compiler:   gcc-8
  Config: multi_v7_defconfig
  Test suite: boot

Breaking commit found:

---
commit 0899a480ac658144b1fa351bb880c2858d43f824
Author: Marek Szyprowski 
Date:   Thu Oct 3 12:08:14 2019 +0200

ARM: dts: exynos: Add initial data for coupled regulators for 
Exynos5422/5800

Declare Exynos5422/5800 voltage ranges for opp points for big cpu core and
bus wcore and couple their voltage supllies as vdd_arm and vdd_int should
be in 300mV range.

Signed-off-by: Marek Szyprowski 
[k.konieczny: add missing patch description]
Signed-off-by: Kamil Konieczny 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Krzysztof Kozlowski 

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 2c131ad78c09..d08101b1018c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -48,62 +48,62 @@
 
opp-18 {
opp-hz = /bits/ 64 <18>;
-   opp-microvolt = <125>;
+   opp-microvolt = <125 125 150>;
clock-latency-ns = <14>;
};
opp-17 {
opp-hz = /bits/ 64 <17>;
-   opp-microvolt = <1212500>;
+   opp-microvolt = <1212500 1212500 150>;
clock-latency-ns = <14>;
};
opp-16 {
opp-hz = /bits/ 64 <16>;
-   opp-microvolt = <1175000>;
+   opp-microvolt = <1175000 1175000 150>;
clock-latency-ns = <14>;
};
opp-15 {
opp-hz = /bits/ 64 <15>;
-   opp-microvolt = <1137500>;
+   opp-microvolt = <1137500 1137500 150>;
clock-latency-ns = <14>;
};
opp-14 {
opp-hz = /bits/ 64 <14>;
-   opp-microvolt = <1112500>;
+   opp-microvolt = <1112500 1112500 150>;
clock-latency-ns = <14>;
};
opp-13 {
opp-hz = /bits/ 64 <13>;
-   opp-microvolt = <1062500>;
+   opp-microvolt = <1062500 1062500 150>;
clock-latency-ns = <14>;
};
opp-12 {
opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <1037500>;
+   opp-microvolt = <1037500 1037500 150>;
clock-latency-ns = <14>;
};
opp-11 {
opp-hz = /bits/ 64 <11>;
-   opp-microvolt = <1012500>;
+   opp-microvolt = <1012500 1012500 150>;
clock-latency-ns = <14>;
};
opp-10 {
opp-hz = /bits/ 64 <10>;
-   opp-microvolt = < 987500>;
+  

Re: [PATCH 4.9 00/47] 4.9.196-stable review

[kernelci.org bot]

stable-rc/linux-4.9.y boot: 41 boots: 0 failed, 41 passed 
(v4.9.195-48-gce2cf4ffcd94)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.195-48-gce2cf4ffcd94/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.195-48-gce2cf4ffcd94/

Tree: stable-rc
Branch: linux-4.9.y
Git Describe: v4.9.195-48-gce2cf4ffcd94
Git Commit: ce2cf4ffcd946bd02d4afd26f17f425dc921448e
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 23 unique boards, 13 SoC families, 10 builds out of 197

---
For more info write to 

[PATCH] staging: rtl8712: align arguments with open parenthesis in file rtl8712_led.c

[Gabriela Bittencourt]

Cleans up checks of "Alignment should match open parenthesis"

Signed-off-by: Gabriela Bittencourt 
---
 drivers/staging/rtl8712/rtl8712_led.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_led.c 
b/drivers/staging/rtl8712/rtl8712_led.c
index db99129d3169..5901026949f2 100644
--- a/drivers/staging/rtl8712/rtl8712_led.c
+++ b/drivers/staging/rtl8712/rtl8712_led.c
@@ -75,7 +75,7 @@ static void BlinkWorkItemCallback(struct work_struct *work);
  * Initialize an LED_871x object.
  */
 static void InitLed871x(struct _adapter *padapter, struct LED_871x *pLed,
-enum LED_PIN_871x  LedPin)
+   enum LED_PIN_871x   LedPin)
 {
pLed->padapter = padapter;
pLed->LedPin = LedPin;
-- 
2.20.1

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Guenter Roeck]

On Sun, Oct 06, 2019 at 04:06:16PM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck  wrote:
> >
> > this patch causes all my sparc64 emulations to stall during boot. It causes
> > all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> > disk, and one of the xtensa emulations to crash with [2].
> 
> Ho humm. I've run variations of that patch over a few years on x86,
> but obviously not on alpha/sparc.
> 
> At least I should still be able to read alpha assembly, even after all
> these years. Would you mind sending me the result of
> 
> make fs/readdir.s
> 
> on alpha with the broken config? I'd hope that the sparc issue is the same.
> 
> Actually, could you also do
> 
> make fs/readdir.o
> 
> and then send me the "objdump --disassemble" of that? That way I get
> the instruction offsets without having to count by hand.
> 

Both attached for alpha.

> > Unable to handle kernel paging request at virtual address 0004
> > rcS(47): Oops -1
> > pc = [<0004>]  ra = []  ps = Not 
> > tainted
> > pc is at 0x4
> 
> That is _funky_. I'm not seeing how it could possibly jump to 0x4, but
> it clearly does.
> 
> That said, are you sure it's _that_ commit? Because this pattern:
> 
Bisect on sparc pointed to this commit, and re-running the tests with
the commit reverted passed for all architectures. I didn't check any
further.

Please let me know if you need anything else at this point.

Thanks,
Guenter
.set noreorder
.set volatile
.set noat
.set nomacro
.arch ev5
 # GNU C89 (GCC) version 9.2.0 (alpha-linux)
 #  compiled by GNU C version 6.5.0 20181026, GMP version 6.1.0, MPFR 
version 3.1.4, MPC version 1.0.3, isl version none
 # warning: GMP header version 6.1.0 differs from library version 6.1.2.
 # warning: MPC header version 1.0.3 differs from library version 1.1.0.
 # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 # options passed:  -nostdinc -I ./arch/alpha/include
 # -I ./arch/alpha/include/generated -I ./include
 # -I ./arch/alpha/include/uapi -I ./arch/alpha/include/generated/uapi
 # -I ./include/uapi -I ./include/generated/uapi
 # -iprefix 
/opt/kernel/gcc-9.2.0-nolibc/alpha-linux/bin/../lib/gcc/alpha-linux/9.2.0/
 # -D __KERNEL__ -D KBUILD_BASENAME="readdir" -D KBUILD_MODNAME="readdir"
 # -isystem 
/opt/kernel/gcc-9.2.0-nolibc/alpha-linux/bin/../lib/gcc/alpha-linux/9.2.0/include
 # -include ./include/linux/kconfig.h
 # -include ./include/linux/compiler_types.h -MD fs/.readdir.s.d
 # fs/readdir.c -mno-fp-regs -mcpu=ev5 -auxbase-strip fs/readdir.s -O2
 # -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
 # -Werror=implicit-function-declaration -Werror=implicit-int
 # -Wno-format-security -Wno-frame-address -Wformat-truncation=0
 # -Wformat-overflow=0 -Wno-address-of-packed-member
 # -Wframe-larger-than=2048 -Wno-unused-but-set-variable
 # -Wimplicit-fallthrough=3 -Wunused-const-variable=0
 # -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
 # -Wno-stringop-truncation -Werror=date-time
 # -Werror=incompatible-pointer-types -Werror=designated-init
 # -Wno-packed-not-aligned -std=gnu90 -fno-strict-aliasing -fno-common
 # -fshort-wchar -fno-PIE -ffixed-8 -fno-jump-tables
 # -fno-delete-null-pointer-checks -fno-stack-protector
 # -fomit-frame-pointer -fno-strict-overflow -fno-merge-all-constants
 # -fmerge-constants -fstack-check=no -fconserve-stack
 # -fmacro-prefix-map=./= -fverbose-asm --param allow-store-data-races=0
 # options enabled:  -faggressive-loop-optimizations -falign-functions
 # -falign-jumps -falign-labels -falign-loops -fassume-phsa -fauto-inc-dec
 # -fbranch-count-reg -fcaller-saves -fcode-hoisting
 # -fcombine-stack-adjustments -fcompare-elim -fcprop-registers
 # -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdevirtualize
 # -fdevirtualize-speculatively -fdwarf2-cfi-asm -fearly-inlining
 # -feliminate-unused-debug-types -fexpensive-optimizations
 # -fforward-propagate -ffp-int-builtin-inexact -ffunction-cse -fgcse
 # -fgcse-lm -fgnu-runtime -fgnu-unique -fguess-branch-probability
 # -fhoist-adjacent-loads -fident -fif-conversion -fif-conversion2
 # -findirect-inlining -finline -finline-atomics
 # -finline-functions-called-once -finline-small-functions -fipa-bit-cp
 # -fipa-cp -fipa-icf -fipa-icf-functions -fipa-icf-variables -fipa-profile
 # -fipa-pure-const -fipa-ra -fipa-reference -fipa-reference-addressable
 # -fipa-sra -fipa-stack-alignment -fipa-vrp -fira-hoist-pressure
 # -fira-share-save-slots -fira-share-spill-slots
 # -fisolate-erroneous-paths-dereference -fivopts -fkeep-static-consts
 # -fleading-underscore -flifetime-dse -flra-remat -flto-odr-type-merging
 # -fmath-errno -fmerge-constants -fmerge-debug-strings
 # -fmove-loop-invariants -fomit-frame-pointer -foptimize-sibling-calls
 # -foptimize-strlen -fpartial-inlining -fpcc-struct-return -fpeephole
 # -fpeephole2 -fplt -fprefetch-loop-arrays -free -freorder-blocks
 

Re: [PATCH 5.3 000/166] 5.3.5-stable review

[kernelci.org bot]

stable-rc/linux-5.3.y boot: 62 boots: 1 failed, 60 passed with 1 
untried/unknown (v5.3.4-167-ga2703e78c28a)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.3.y/kernel/v5.3.4-167-ga2703e78c28a/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-5.3.y/kernel/v5.3.4-167-ga2703e78c28a/

Tree: stable-rc
Branch: linux-5.3.y
Git Describe: v5.3.4-167-ga2703e78c28a
Git Commit: a2703e78c28a6166f8796b4733620c6d0b8f479a
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 44 unique boards, 17 SoC families, 12 builds out of 208

Boot Regressions Detected:

arm64:

defconfig:
gcc-8:
  meson-gxl-s805x-p241:
  lab-baylibre: new failure (last pass: v5.3.4-162-gde3c43ffab53)

i386:

i386_defconfig:
gcc-8:
  qemu_i386:
  lab-baylibre: new failure (last pass: v5.3.4-162-gde3c43ffab53)

Boot Failure Detected:

i386:
i386_defconfig:
gcc-8:
qemu_i386: 1 failed lab

---
For more info write to 

Re: [PATCH] Make SPLIT_RSS_COUNTING configurable

[Kirill A. Shutemov]

On Fri, Oct 04, 2019 at 06:45:21AM -0700, Daniel Colascione wrote:
> On Fri, Oct 4, 2019 at 6:26 AM Kirill A. Shutemov  
> wrote:
> > On Fri, Oct 04, 2019 at 02:33:49PM +0200, Michal Hocko wrote:
> > > On Wed 02-10-19 19:08:16, Daniel Colascione wrote:
> > > > On Wed, Oct 2, 2019 at 6:56 PM Qian Cai  wrote:
> > > > > > On Oct 2, 2019, at 4:29 PM, Daniel Colascione  
> > > > > > wrote:
> > > > > >
> > > > > > Adding the correct linux-mm address.
> > > > > >
> > > > > >
> > > > > >> +config SPLIT_RSS_COUNTING
> > > > > >> +   bool "Per-thread mm counter caching"
> > > > > >> +   depends on MMU
> > > > > >> +   default y if NR_CPUS >= SPLIT_PTLOCK_CPUS
> > > > > >> +   help
> > > > > >> + Cache mm counter updates in thread structures and
> > > > > >> + flush them to visible per-process statistics in batches.
> > > > > >> + Say Y here to slightly reduce cache contention in 
> > > > > >> processes
> > > > > >> + with many threads at the expense of decreasing the 
> > > > > >> accuracy
> > > > > >> + of memory statistics in /proc.
> > > > > >> +
> > > > > >> endmenu
> > > > >
> > > > > All those vague words are going to make developers almost
> > > > > impossible to decide the right selection here. It sounds like we
> > > > > should kill SPLIT_RSS_COUNTING at all to simplify the code as
> > > > > the benefit is so small vs the side-effect?
> > > >
> > > > Killing SPLIT_RSS_COUNTING would be my first choice; IME, on mobile
> > > > and a basic desktop, it doesn't make a difference. I figured making it
> > > > a knob would help allay concerns about the performance impact in more
> > > > extreme configurations.
> > >
> > > I do agree with Qian. Either it is really helpful (is it? probably on
> > > the number of cpus) and it should be auto-enabled or it should be
> > > dropped altogether. You cannot really expect people know how to enable
> > > this without a deep understanding of the MM internals. Not to mention
> > > all those users using distro kernels/configs.
> > >
> > > A config option sounds like a bad way forward.
> >
> > And I don't see much point anyway. Reading RSS counters from proc is
> > inherently racy. It can just either way after the read due to process
> > behaviour.
> 
> Split RSS accounting doesn't make reading from mm counters racy. It
> makes these counters *wrong*. We flush task mm counters to the
> mm_struct once every 64 page faults that a task incurs or when that
> task exits. That means that if a thread takes 63 page faults and then
> sleeps for a week, that thread's process's mm counters are wrong by 63
> pages *for a week*. And some processes have a lot of threads,
> compounding the error. Split RSS accounting means that memory usage
> numbers don't add up. I don't think it's unreasonable to want a mode
> where memory counters to agree with other indicators of system
> activity.

It's documented behaviour that is upstream for 9 years. Why is your workload
special?

The documentation suggests to use smaps if you want to have precise data.
Why would it not fly for you?

> Nobody has demonstrated that split RSS accounting actually helps in
> the real world.

The original commit 34e55232e59f ("mm: avoid false sharing of mm_counter")
shows numbers on cache misses. It's not a real world workload, but you
don't have any numbers at all to back your claim.

> But I've described above, concretely, how split RSS
> accounting hurts. I've been trying for over a year to either disable
> split RSS accounting or to let people opt out of it. If you won't
> remove split RSS accounting and you won't let me add a configuration
> knob that lets people opt out of it, what will you accept?

Keeping stats precise is welcome, but often expensive. It might be
negligible for small machine, but becomes a problem on multisocket
machine with dozens or hundreds of cores. We need to keep kernel scalable.

We have other stats that update asynchronously (i.e. /proc/vmstat). Would
you like to convert them too?

-- 
 Kirill A. Shutemov

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Guenter Roeck]

On 10/6/19 4:35 PM, Linus Torvalds wrote:
[ ... ]


Anyway, let me think about this, but just for testing, does the
attached patch make any difference? It's not the right thing in
general (and most definitely not on x86), but for testing whether this
is about unaligned accesses it might work.



All my alpha, sparc64, and xtensa tests pass with the attached patch
applied on top of v5.4-rc2. I didn't test any others.

I'll (try to) send you some disassembly next.

Guenter

Re: [PATCH 4.19 000/106] 4.19.78-stable review

[kernelci.org bot]

stable-rc/linux-4.19.y boot: 56 boots: 0 failed, 56 passed 
(v4.19.77-107-g61e72e79b84d)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.77-107-g61e72e79b84d/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.77-107-g61e72e79b84d/

Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.77-107-g61e72e79b84d
Git Commit: 61e72e79b84d3a2519ad88c10964d7e4fa11ef1d
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 39 unique boards, 16 SoC families, 12 builds out of 206

---
For more info write to 

[PATCH] taskstats: fix data-race

[Christian Brauner]

When assiging and testing taskstats in taskstats_exit() there's a race
when writing and reading sig->stats when a thread-group with more than
one thread exits:

cpu0:
thread catches fatal signal and whole thread-group gets taken down
 do_exit()
 do_group_exit()
 taskstats_exit()
 taskstats_tgid_alloc()
The tasks reads sig->stats holding sighand lock seeing garbage.

cpu1:
task calls exit_group()
 do_exit()
 do_group_exit()
 taskstats_exit()
 taskstats_tgid_alloc()
The task takes sighand lock and assigns new stats to sig->stats.

Fix this by using READ_ONCE() and smp_store_release().

Reported-by: syzbot+c5d03165a1bd1dead...@syzkaller.appspotmail.com
Cc: Dmitry Vyukov 
Signed-off-by: Christian Brauner 
---
/* v1 */
Link: 
https://lore.kernel.org/r/20191005112806.13960-1-christian.brau...@ubuntu.com

/* v2 */
- Dmitry Vyukov , Marco Elver :
  - fix the original double-checked locking using memory barriers
---
 kernel/taskstats.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index 13a0f2e6ebc2..8ee046e8a792 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -554,24 +554,25 @@ static int taskstats_user_cmd(struct sk_buff *skb, struct 
genl_info *info)
 static struct taskstats *taskstats_tgid_alloc(struct task_struct *tsk)
 {
struct signal_struct *sig = tsk->signal;
-   struct taskstats *stats;
+   struct taskstats *stats_new, *stats;
 
-   if (sig->stats || thread_group_empty(tsk))
-   goto ret;
+   stats = READ_ONCE(sig->stats);
+   if (stats || thread_group_empty(tsk))
+   return stats;
 
/* No problem if kmem_cache_zalloc() fails */
-   stats = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL);
+   stats_new = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL);
 
spin_lock_irq(>sighand->siglock);
if (!sig->stats) {
-   sig->stats = stats;
-   stats = NULL;
+   smp_store_release(>stats, stats_new);
+   stats_new = NULL;
}
spin_unlock_irq(>sighand->siglock);
 
-   if (stats)
-   kmem_cache_free(taskstats_cache, stats);
-ret:
+   if (stats_new)
+   kmem_cache_free(taskstats_cache, stats_new);
+
return sig->stats;
 }
 
-- 
2.23.0

Re: [PATCH] rculist: Describe variadic macro argument in a Sphinx-compatible way

[Joel Fernandes]

On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> > Without this patch, Sphinx shows "variable arguments" as the description
> > of the cond argument, rather than the intended description, and prints
> > the following warnings:
> > 
> > ./include/linux/rculist.h:374: warning: Excess function parameter 'cond' 
> > description in 'list_for_each_entry_rcu'
> > ./include/linux/rculist.h:651: warning: Excess function parameter 'cond' 
> > description in 'hlist_for_each_entry_rcu'
> > 
> > Signed-off-by: Jonathan Neuschäfer 
> 
> Applied for testing and review, thank you!
> 
> Joel, does this look sane to you?

Sorry for late reply due to weekend. Yes, looks good to me.

thanks,

 - Joel

Re: [PATCH 5.2 000/137] 5.2.20-stable review

[kernelci.org bot]

stable-rc/linux-5.2.y boot: 62 boots: 0 failed, 61 passed with 1 
untried/unknown (v5.2.19-138-gc7a8121be8ef)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.19-138-gc7a8121be8ef/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.19-138-gc7a8121be8ef/

Tree: stable-rc
Branch: linux-5.2.y
Git Describe: v5.2.19-138-gc7a8121be8ef
Git Commit: c7a8121be8ef67066e07c79b2204dea12511b17b
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 43 unique boards, 16 SoC families, 12 builds out of 209

Boot Regressions Detected:

arm64:

defconfig:
gcc-8:
  meson-gxl-s805x-p241:
  lab-baylibre: new failure (last pass: v5.2.19-133-ga4c5f9f59786)

---
For more info write to 

Re: [PATCH v22 16/24] x86/vdso: Add support for exception fixup in vDSO functions

[Jarkko Sakkinen]

On Mon, Oct 07, 2019 at 02:38:17AM +0300, Jarkko Sakkinen wrote:
> On Fri, Oct 04, 2019 at 09:52:21PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 03, 2019 at 05:15:00PM -0700, Sean Christopherson wrote:
> > > I'll tackle this tomorrow.  I've been working on the feature control MSR
> > > series and will get that sent out tomorrow as well.  I should also be able
> > > to get you the multi-page EADD patch.
> > 
> > Great I'll compose the patch set during the weekend and take Monday off
> > so you have the full work day to get everything (probably send the patch
> > set on Sunday).
> 
> I don't see why the multipage version could not be ioctl of its own and
> ioctl's can then use the same internals. Having a single page version
> does not cause any kind of bottleneck really.
> 
> Thus, sending now v23 based on these conclusions.

Sure, you can argue it is redudant but I see it as a nice convenience
for simple stuff that does not really hurt at all.

/Jarkko

Re: [PATCH v22 16/24] x86/vdso: Add support for exception fixup in vDSO functions

[Jarkko Sakkinen]

On Fri, Oct 04, 2019 at 09:52:21PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 05:15:00PM -0700, Sean Christopherson wrote:
> > I'll tackle this tomorrow.  I've been working on the feature control MSR
> > series and will get that sent out tomorrow as well.  I should also be able
> > to get you the multi-page EADD patch.
> 
> Great I'll compose the patch set during the weekend and take Monday off
> so you have the full work day to get everything (probably send the patch
> set on Sunday).

I don't see why the multipage version could not be ioctl of its own and
ioctl's can then use the same internals. Having a single page version
does not cause any kind of bottleneck really.

Thus, sending now v23 based on these conclusions.

/Jarkko

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 4:06 PM Linus Torvalds
 wrote:
>
> Ho humm. I've run variations of that patch over a few years on x86,
> but obviously not on alpha/sparc.

Oooh.

I wonder... This may be the name string copy loop. And it's special in
that the result may not be aligned.

Now, a "__put_user()" with an unaligned address _should_ work - it's
very easy to trigger that from user space by just giving an unaligned
address to any system call that then writes a single word.

But alpha does

  #define __put_user_32(x, addr)  \
  __asm__ __volatile__("1: stl %r2,%1\n"  \
  "2:\n"  \
  EXC(1b,2b,$31,%0)   \
  : "=r"(__pu_err)\
  : "m"(__m(addr)), "rJ"(x), "0"(__pu_err))

iow it implements that 32-bit __put_user() as a 'stl'.

Which will trap if it's not aligned.

And I wonder how much testing that has ever gotten. Nobody really does
unaigned accesses on alpha.

We need to do that memcpy unrolling on x86, because x86 actually uses
"user_access_begin()" and we have magic rules about what is inside
that region.

But on alpha (and sparc) it might be better to just do "__copy_to_user()".

Anyway, this does look like a possible latent bug where the alpha
unaligned trap doesn't then handle the case of exceptions. I know it
_tries_, but I doubt it's gotten a whole lot of testing.

Anyway, let me think about this, but just for testing, does the
attached patch make any difference? It's not the right thing in
general (and most definitely not on x86), but for testing whether this
is about unaligned accesses it might work.

It's entirely untested, and in fact on x86 it should cause objtool to
complain about a function call with AC set. But I think that on alpha
and sparc, using __copy_to_user() for the name copy should work, and
would work around the unaligned issue.

That said, if it *is* the unaligned issue, then that just means that
we have a serious bug elsewhere in the alpha port. Maybe nobody cares.

  Linus
 fs/readdir.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/readdir.c b/fs/readdir.c
index 19bea591c3f1..d49c4e2c66a8 100644
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -76,6 +76,15 @@
 	unsafe_put_user(0, dst, label);\
 } while (0)
 
+/* Alpha (and sparc?) test patch! */
+#undef unsafe_copy_dirent_name
+#define unsafe_copy_dirent_name(_dst, _src, _len, label) do {	\
+	char __user *dst = (_dst);\
+	const char *src = (_src);\
+	size_t len = (_len);	\
+	if (__copy_to_user(dst, src, len)) goto label;		\
+	unsafe_put_user(0, dst+len, label);			\
+} while (0)
 
 int iterate_dir(struct file *file, struct dir_context *ctx)
 {

Re: [PATCH v3 2/2] tpm: Detach page allocation from tpm_buf

[Jarkko Sakkinen]

On Fri, Oct 04, 2019 at 11:24:34AM -0700, Jerry Snitselaar wrote:
> On Fri Oct 04 19, James Bottomley wrote:
> > On Fri, 2019-10-04 at 13:37 -0400, Mimi Zohar wrote:
> > > On Fri, 2019-10-04 at 09:37 -0700, James Bottomley wrote:
> > > > On Thu, 2019-10-03 at 21:51 +0300, Jarkko Sakkinen wrote:
> > > > > As has been seen recently, binding the buffer allocation and
> > > > > tpm_buf
> > > > > together is sometimes far from optimal.
> > > >
> > > > Can you elaborate on this a bit more?  I must have missed the
> > > > discussion.
> > > 
> > > Refer to e13cd21ffd50 ("tpm: Wrap the buffer from the caller to
> > > tpm_buf in tpm_send()") for the details.
> > 
> > Yes, I get that, but to my mind that calls for moving the
> > tpm_init/destroy_buf into the callers of tpm_send (which, for the most
> > part, already exist), which means there's no need to separate the buf
> > and data lifetimes.
> > 
> > James
> > 
> 
> Sumit has been working on a patchset that does this.  His patchset
> converts both the asymmetric keys and trusted keys code to using the
> tpm_buf manipulation functions.

And it is also in a shape that it can soon be merged (within
few iterations at most).

/Jarkko

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Sun, Oct 6, 2019 at 3:20 PM Guenter Roeck  wrote:
>
> this patch causes all my sparc64 emulations to stall during boot. It causes
> all alpha emulations to crash with [1a] and [1b] when booting from a virtual
> disk, and one of the xtensa emulations to crash with [2].

Ho humm. I've run variations of that patch over a few years on x86,
but obviously not on alpha/sparc.

At least I should still be able to read alpha assembly, even after all
these years. Would you mind sending me the result of

make fs/readdir.s

on alpha with the broken config? I'd hope that the sparc issue is the same.

Actually, could you also do

make fs/readdir.o

and then send me the "objdump --disassemble" of that? That way I get
the instruction offsets without having to count by hand.

> Unable to handle kernel paging request at virtual address 0004
> rcS(47): Oops -1
> pc = [<0004>]  ra = []  ps = Not tainted
> pc is at 0x4

That is _funky_. I'm not seeing how it could possibly jump to 0x4, but
it clearly does.

That said, are you sure it's _that_ commit? Because this pattern:

> a0 = fc0007dbca56  a1 = 2f2f2f2f2f2f2f2f  a2 = 000a

implicates the memchr('/') call in the next one. That's a word full of
'/' characters.

Of course, it could just be left-over register contents from that
memchr(), but it makes me wonder. Particularly since it seems to
happen early in filldir64():

> ra is at filldir64+0x64/0x320

which is just a fairly small handful of instructions in, and I
wouldn't be shocked if that's the return address for the call to
memchr.

  Linus

Re: [PATCH 4.14 00/68] 4.14.148-stable review

[kernelci.org bot]

stable-rc/linux-4.14.y boot: 54 boots: 0 failed, 54 passed 
(v4.14.147-69-gb970b501da0b)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.147-69-gb970b501da0b/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.147-69-gb970b501da0b/

Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.147-69-gb970b501da0b
Git Commit: b970b501da0bee5eba4e61ea7d424adab428a165
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 32 unique boards, 15 SoC families, 10 builds out of 201

---
For more info write to 

Re: [PATCH 01/11] iomap: add tracing for the readpage / readpages

[Darrick J. Wong]

On Sun, Oct 06, 2019 at 05:45:58PM +0200, Christoph Hellwig wrote:
> Lift the xfs code for tracing address space operations to the iomap
> layer.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  fs/iomap/Makefile  | 16 --
>  fs/iomap/buffered-io.c |  5 +
>  fs/iomap/trace.h   | 49 ++
>  3 files changed, 63 insertions(+), 7 deletions(-)
>  create mode 100644 fs/iomap/trace.h
> 
> diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile
> index 93cd11938bf5..eef2722d93a1 100644
> --- a/fs/iomap/Makefile
> +++ b/fs/iomap/Makefile
> @@ -3,13 +3,15 @@
>  # Copyright (c) 2019 Oracle.
>  # All Rights Reserved.
>  #
> -obj-$(CONFIG_FS_IOMAP)   += iomap.o
>  
> -iomap-y  += \
> - apply.o \
> - buffered-io.o \
> - direct-io.o \
> - fiemap.o \
> - seek.o
> +ccflags-y += -I $(srctree)/$(src)# needed for trace events
> +
> +obj-$(CONFIG_FS_IOMAP)   += iomap.o
>  
> +iomap-y  += trace.o \

I think this patch is missing fs/iomap/trace.c ?

--D

> +apply.o \
> +buffered-io.o \
> +direct-io.o \
> +fiemap.o \
> +seek.o
>  iomap-$(CONFIG_SWAP) += swapfile.o
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e25901ae3ff4..fb209272765c 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include "trace.h"
>  
>  #include "../internal.h"
>  
> @@ -293,6 +294,8 @@ iomap_readpage(struct page *page, const struct iomap_ops 
> *ops)
>   unsigned poff;
>   loff_t ret;
>  
> + trace_iomap_readpage(page->mapping->host, 1);
> +
>   for (poff = 0; poff < PAGE_SIZE; poff += ret) {
>   ret = iomap_apply(inode, page_offset(page) + poff,
>   PAGE_SIZE - poff, 0, ops, ,
> @@ -389,6 +392,8 @@ iomap_readpages(struct address_space *mapping, struct 
> list_head *pages,
>   loff_t last = page_offset(list_entry(pages->next, struct page, lru));
>   loff_t length = last - pos + PAGE_SIZE, ret = 0;
>  
> + trace_iomap_readpages(mapping->host, nr_pages);
> +
>   while (length > 0) {
>   ret = iomap_apply(mapping->host, pos, length, 0, ops,
>   , iomap_readpages_actor);
> diff --git a/fs/iomap/trace.h b/fs/iomap/trace.h
> new file mode 100644
> index ..7798aeda7fb9
> --- /dev/null
> +++ b/fs/iomap/trace.h
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2009-2019, Christoph Hellwig
> + *
> + * NOTE: none of these tracepoints shall be consider a stable kernel ABI
> + * as they can change at any time.
> + */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM iomap
> +
> +#if !defined(_IOMAP_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _IOMAP_TRACE_H
> +
> +#include 
> +
> +struct inode;
> +
> +DECLARE_EVENT_CLASS(iomap_readpage_class,
> + TP_PROTO(struct inode *inode, int nr_pages),
> + TP_ARGS(inode, nr_pages),
> + TP_STRUCT__entry(
> + __field(dev_t, dev)
> + __field(u64, ino)
> + __field(int, nr_pages)
> + ),
> + TP_fast_assign(
> + __entry->dev = inode->i_sb->s_dev;
> + __entry->ino = inode->i_ino;
> + __entry->nr_pages = nr_pages;
> + ),
> + TP_printk("dev %d:%d ino 0x%llx nr_pages %d",
> +   MAJOR(__entry->dev), MINOR(__entry->dev),
> +   __entry->ino,
> +   __entry->nr_pages)
> +)
> +
> +#define DEFINE_READPAGE_EVENT(name)  \
> +DEFINE_EVENT(iomap_readpage_class, name, \
> + TP_PROTO(struct inode *inode, int nr_pages), \
> + TP_ARGS(inode, nr_pages))
> +DEFINE_READPAGE_EVENT(iomap_readpage);
> +DEFINE_READPAGE_EVENT(iomap_readpages);
> +
> +#endif /* _IOMAP_TRACE_H */
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH .
> +#define TRACE_INCLUDE_FILE trace
> +#include 
> -- 
> 2.20.1
> 

Question about sched_prio_to_weight values

[Francesco Poli]

Hello,
I am trying to understand something about the internals of the
completely fair scheduler (CFS) used in the Linux kernel.

I have a question about the mapping between nice levels and weights,
I hope someone can shed some light on those numbers.
Please note that I am not subscribed to the LKML: could you please Cc
me on replies? Thanks for your understanding.


As far as I can see, the mapping is hard-coded in the
sched_prio_to_weight array, which is defined in kernel/sched/core.c
The [latest code] defines the following values:

  const int sched_prio_to_weight[40] = {
   /* -20 */ 88761, 71755, 56483, 46273, 36291,
   /* -15 */ 29154, 23254, 18705, 14949, 11916,
   /* -10 */  9548,  7620,  6100,  4904,  3906,
   /*  -5 */  3121,  2501,  1991,  1586,  1277,
   /*   0 */  1024,   820,   655,   526,   423,
   /*   5 */   335,   272,   215,   172,   137,
   /*  10 */   110,87,70,56,45,
   /*  15 */36,29,23,18,15,
  };

but I found the same values in much more ancient versions
(the values probably date back to the first patch that introduced
the CFS in the kernel).

[latest code]: 


Now, the comments in the code suggest that each value is obtained by
dividing the previous one by 1.25: I found [some] [documentation] that
seems to confirm that the "weight is roughly equivalent to
1024/(1.25)^(nice)"

[some]: 

[documentation]: 

I tried to see whether I could re-obtain those numbers by rounding (to
integers) the values computed with that formula, but the result does not
look quite right.
By using calc(1), I get:

  ; for (nice = -20; nice < 20; ++nice) { 
  ;; w = 1024/(1.25)^(nice);
  ;; printf('%3d %7d (%.2f)\n', nice, round(w), w);
  ;; }
  -20   88818 (~88817.84)
  -19   71054 (~71054.27)
  -18   56843 (~56843.42)
  -17   45475 (~45474.74)
  -16   36380 (~36379.79)
  -15   29104 (~29103.83)
  -14   23283 (~23283.06)
  -13   18626 (~18626.45)
  -12   14901 (~14901.16)
  -11   11921 (~11920.93)
  -109537 (~9536.74)
   -97629 (~7629.39)
   -86104 (~6103.52)
   -74883 (~4882.81)
   -63906 (3906.25)
   -53125 (3125)
   -42500 (2500)
   -32000 (2000)
   -21600 (1600)
   -11280 (1280)
01024 (1024)
1 819 (819.2)
2 655 (655.36)
3 524 (~524.29)
4 419 (~419.43)
5 336 (~335.54)
6 268 (~268.44)
7 215 (~214.75)
8 172 (~171.80)
9 137 (~137.44)
   10 110 (~109.95)
   11  88 (~87.96)
   12  70 (~70.37)
   13  56 (~56.29)
   14  45 (~45.04)
   15  36 (~36.03)
   16  29 (~28.82)
   17  23 (~23.06)
   18  18 (~18.45)
   19  15 (~14.76)

where some numbers correspond, while others differ from those found
in kernel/sched/core.c ...

I tried to tweak the 1.25 factor: 1.2499599 makes me get
weight == 88761 for nice == -20, but other numbers still differ.
A non-linear curve fitting with grace(1) leads to a factor of 1.25018,
which still produces values that fail to completely match those found
in kernel/sched/core.c ...

I searched the web and the mailing list archives, but I failed to find
an answer to this question. Could someone please explain me how those
numbers were picked?

Thanks for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpDMBDK7yi7R.pgp
Description: PGP signature

Re: [PATCH v2 2/3] ARM: dts: add Netronix E60K02 board common file

[Jonathan Neuschäfer]

Thanks for CCing me on this patchset. Nice to see more e-book reader
related work!

A few comments and questions below.

On Mon, Sep 30, 2019 at 09:43:31PM +0200, Andreas Kemnade wrote:
> The Netronix board E60K02 can be found some several Ebook-Readers,
> at least the Kobo Clara HD and the Tolino Shine 3. The board
> is equipped with different SoCs requiring different pinmuxes.

Do I understand it correctly that i.MX6SL and i.MX6SLL are pin-
compatible so we can use the same pin numbers and GPIO handles in the
DT?

> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led>;
> +
> + GLED {

What does "GLED" mean? It's not obvious to me.
What user-visible purpose does this LED have, or where is it on the
board?

> + gpios = < 7 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "timer";
> + };
> + };
> +
> + memory {
> + reg = <0x8000 0x8000>;

2 GiB of memory?

> + /* Core3_3V3 */

What are these labels (Core3_3V3, Core4_1V2, etc.)?

> + dcdc2_reg: DCDC2 {
> + regulator-name = "DCDC2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-max-microvolt = 
> <330>;
> + regulator-suspend-min-microvolt = 
> <330>;
> + };
> + };


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH v7 0/6] tpm: Add driver for cr50

[Jarkko Sakkinen]

On Fri, Sep 20, 2019 at 11:32:34AM -0700, Stephen Boyd wrote:
> This patch series adds support for the H1 secure microcontroller
> running cr50 firmware found on various recent Chromebooks. This driver
> is necessary to boot into a ChromeOS userspace environment. It
> implements support for several functions, including TPM-like
> functionality over a SPI interface.
> 
> The last time this was series sent looks to be [1]. I've looked over the
> patches and review comments and tried to address any feedback that
> Andrey didn't address (really minor things like newlines). I've reworked
> the patches from the last version to layer on top of the existing TPM
> TIS SPI implementation in tpm_tis_spi.c. Hopefully this is more
> palatable than combining the two drivers together into one file.
> 
> Please review so we can get the approach to supporting this device
> sorted out.
> 
> [1] 
> https://lkml.kernel.org/r/1469757314-116169-1-git-send-email-apro...@chromium.org
> 
> TODO:
>  * Add a patch to spit out WARN_ON() when TPM is suspended and some
>kernel code attempts to use it
>  * Rework the i2c driver per Alexander's comments on v2
> 
> Changes from v6 
> (https://lkml.kernel.org/r/20190829224110.91103-1-swb...@chromium.org):
>  * Two new patches to cleanup includes and module usage
>  * Moved cr50 C file to tpm_tis_spi_cr50.c
>  * Used the tpm_tis_spi_mod target approach to make the module work
>  * Brought back Kconfig option to allow user to disable cr50 code
>  * Rebased to v5.3
> 
> Changes from v5 
> (https://lkml.kernel.org/r/20190828082150.42194-1-swb...@chromium.org):
>  * Picked up Jarkko's ack/review tags
>  * Fixed bug with irqs happening before completion is initialized
>  * Dropped is_cr50 bool
>  * Moved wake_after to tpm_tis_spi struct
>  * Changed authorship of main cr50 patch to Andrey as I'm just shuffling
>code here
> 
> Changes from v4 
> (https://lkml.kernel.org/r/20190812223622.73297-1-swb...@chromium.org):
>  * Dropped the 'pre-transfer' hook patch and added a 'ready' member instead
>  * Combined cr50_spi and tpm_tis_spi into one kernel module
>  * Introduced a swizzle in tpm_tis_spi probe routine to jump to cr50
>probe path
>  * Moved binding to start of the thread
>  * Picked up Jarkko reviewed-by tag on new flag for suspend/resume
>  * Added a comment to flow control patch indicating what it's all about
> 
> Changes from v3:
>  * Split out hooks into separate patches
>  * Update commit text to not say "libify"
>  * Collapse if statement into one for first patch
>  * Update commit text on first patch to mention flag
>  * Drop TIS_IS_CR50 as it's unused
> 
> Changes from v2:
>  * Sent khwrng thread patch separately
>  * New patch to expose TPM SPI functionality from tpm_tis_spi.c
>  * Usage of that new patch in cr50 SPI driver
>  * Drop i2c version of cr50 SPI driver for now (will resend later)
>  * New patch to add a TPM chip flag indicating TPM shouldn't be reset
>over suspend. Allows us to get rid of the cr50 suspend/resume functions
>that are mostly generic
> 
> Changes from v1:
>  * Dropped symlink and sysfs patches
>  * Removed 'is_suspended' bits
>  * Added new patch to freeze khwrng thread
>  * Moved binding to google,cr50.txt and added Reviewed-by tag from Rob
> 
> Cc: Andrey Pronin 
> Cc: Duncan Laurie 
> Cc: Jason Gunthorpe 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Guenter Roeck 
> Cc: Alexander Steffen 
> Cc: Heiko Stuebner 

OK, so, I put these to my master in hopes to get testing exposure.
I think the changes are in great shape now. Thank you.

/Jarkko

Re: [PATCH v7 5/6] tpm: tpm_tis_spi: Cleanup includes

[Jarkko Sakkinen]

On Fri, Sep 20, 2019 at 11:32:39AM -0700, Stephen Boyd wrote:
> Some of these includes aren't used, for example of_gpio.h and freezer.h,
> or they are missing, for example kernel.h for min_t() usage. Add missing
> headers and remove unused ones so that we don't have to expand all these
> headers into this file when they're not actually necessary.
> 
> Cc: Andrey Pronin 
> Cc: Duncan Laurie 
> Cc: Jason Gunthorpe 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Guenter Roeck 
> Cc: Alexander Steffen 
> Cc: Heiko Stuebner 
> Signed-off-by: Stephen Boyd 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

Re: [PATCH v7 6/6] tpm: tpm_tis_spi: Drop THIS_MODULE usage from driver struct

[Jarkko Sakkinen]

On Fri, Sep 20, 2019 at 11:32:40AM -0700, Stephen Boyd wrote:
> The module_spi_driver() macro already inserts THIS_MODULE into the
> driver .owner field. Remove it to save a line.
> 
> Cc: Andrey Pronin 
> Cc: Duncan Laurie 
> Cc: Jason Gunthorpe 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Guenter Roeck 
> Cc: Alexander Steffen 
> Cc: Heiko Stuebner 
> Signed-off-by: Stephen Boyd 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

Re: [PATCH v7 4/6] tpm: tpm_tis_spi: Support cr50 devices

[Jarkko Sakkinen]

On Fri, Sep 20, 2019 at 11:32:38AM -0700, Stephen Boyd wrote:
> From: Andrey Pronin 
> 
> Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
> firmware. The firmware running on the currently supported H1 Secure
> Microcontroller requires a special driver to handle its specifics:
> 
>  - need to ensure a certain delay between SPI transactions, or else
>the chip may miss some part of the next transaction
>  - if there is no SPI activity for some time, it may go to sleep,
>and needs to be waken up before sending further commands
>  - access to vendor-specific registers
> 
> Cr50 firmware has a requirement to wait for the TPM to wakeup before
> sending commands over the SPI bus. Otherwise, the firmware could be in
> deep sleep and not respond. The method to wait for the device to wakeup
> is slightly different than the usual flow control mechanism described in
> the TCG SPI spec. Add a completion to tpm_tis_spi_transfer() before we
> start a SPI transfer so we can keep track of the last time the TPM
> driver accessed the SPI bus to support the flow control mechanism.
> 
> Split the cr50 logic off into a different file to keep it out of the
> normal code flow of the existing SPI driver while making it all part of
> the same module when the code is optionally compiled into the same
> module. Export a new function, tpm_tis_spi_init(), and the associated
> read/write/transfer APIs so that we can do this. Make the cr50 code wrap
> the tpm_tis_spi_phy struct with its own struct to override the behavior
> of tpm_tis_spi_transfer() by supplying a custom flow control hook. This
> shares the most code between the core driver and the cr50 support
> without combining everything into the core driver or exporting module
> symbols.
> 
> Signed-off-by: Andrey Pronin 
> Cc: Andrey Pronin 
> Cc: Duncan Laurie 
> Cc: Jason Gunthorpe 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Guenter Roeck 
> Cc: Alexander Steffen 
> Cc: Heiko Stuebner 

First, I apologize for such a long latency (two weeks).

I think this looks legit now.

Reviewed-by: Jarkko Sakkinen 

/Jarkko

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Guenter Roeck]

On Sat, May 21, 2016 at 09:59:07PM -0700, Linus Torvalds wrote:
> We really should avoid the "__{get,put}_user()" functions entirely,
> because they can easily be mis-used and the original intent of being
> used for simple direct user accesses no longer holds in a post-SMAP/PAN
> world.
> 
> Manually optimizing away the user access range check makes no sense any
> more, when the range check is generally much cheaper than the "enable
> user accesses" code that the __{get,put}_user() functions still need.
> 
> So instead of __put_user(), use the unsafe_put_user() interface with
> user_access_{begin,end}() that really does generate better code these
> days, and which is generally a nicer interface.  Under some loads, the
> multiple user writes that filldir() does are actually quite noticeable.
> 
> This also makes the dirent name copy use unsafe_put_user() with a couple
> of macros.  We do not want to make function calls with SMAP/PAN
> disabled, and the code this generates is quite good when the
> architecture uses "asm goto" for unsafe_put_user() like x86 does.
> 
> Note that this doesn't bother with the legacy cases.  Nobody should use
> them anyway, so performance doesn't really matter there.
> 
> Signed-off-by: Linus Torvalds 

Linus,

this patch causes all my sparc64 emulations to stall during boot. It causes
all alpha emulations to crash with [1a] and [1b] when booting from a virtual
disk, and one of the xtensa emulations to crash with [2].

Reverting this patch fixes the problem.

Guenter

---
[1a]

Unable to handle kernel paging request at virtual address 0004
rcS(47): Oops -1
pc = [<0004>]  ra = []  ps = Not tainted
pc is at 0x4
ra is at filldir64+0x64/0x320
v0 =   t0 =   t1 = 000120117e8b
t2 = 646e617275303253  t3 = 646e61727530  t4 = 7fe8
t5 = 000120117e78  t6 =   t7 = fc0007ec8000
s0 = fc0007dbca56  s1 = 000a  s2 = 0020
s3 = fc0007ecbec8  s4 = 0008  s5 = 0021
s6 = 1cd2631fe897bf5a
a0 = fc0007dbca56  a1 = 2f2f2f2f2f2f2f2f  a2 = 000a
a3 = 1cd2631fe897bf5a  a4 = 0021  a5 = 0008
t8 = 0020  t9 =   t10= fc0007dbca60
t11= 0001  pv = fcb9a810  at = 0001
gp = fcf03930  sp = (ptrval)
Disabling lock debugging due to kernel taint
Trace:
[] call_filldir+0xe8/0x1b0
[] ext4_readdir+0x924/0xa70
[] _raw_spin_unlock+0x18/0x30
[] __handle_mm_fault+0x9fc/0xc30
[] iterate_dir+0x198/0x240
[] iterate_dir+0x5c/0x240
[] ksys_getdents64+0xa8/0x160
[] sys_getdents64+0x20/0x40
[] filldir64+0x0/0x320
[] entSys+0xa4/0xc0

---
[1b]

Unable to handle kernel paging request at virtual address 0004
reboot(50): Oops -1
pc = [<0004>]  ra = []  ps = Tainted: G   
   D
pc is at 0x4
ra is at filldir64+0x64/0x320
v0 =   t0 = 67736d6b  t1 = 00012011445b
t2 =   t3 =   t4 = 7ef8
t5 = 000120114448  t6 =   t7 = fc0007eec000
s0 = fc000792b5c3  s1 = 0004  s2 = 0018
s3 = fc0007eefec8  s4 = 0008  s5 = f0a3
s6 = 000b
a0 = fc000792b5c3  a1 = 2f2f2f2f2f2f2f2f  a2 = 0004
a3 = 000b  a4 = f0a3  a5 = 0008
t8 = 0018  t9 =   t10= 22e1d02a
t11= 00011f8fd3b8  pv = fcb9a810  at = 22e1ccf8
gp = fcf03930  sp = (ptrval)
Trace:
[] proc_readdir_de+0x170/0x300
[] filldir64+0x0/0x320
[] proc_root_readdir+0x3c/0x80
[] iterate_dir+0x198/0x240
[] ksys_getdents64+0xa8/0x160
[] sys_getdents64+0x20/0x40
[] filldir64+0x0/0x320
[] entSys+0xa4/0xc0

---
[2]

Unable to handle kernel paging request at virtual address 0004
reboot(50): Oops -1
pc = [<0004>]  ra = []  ps = Tainted: G   
   D
pc is at 0x4
ra is at filldir64+0x64/0x320
v0 =   t0 = 67736d6b  t1 = 00012011445b
t2 =   t3 =   t4 = 7ef8
t5 = 000120114448  t6 =   t7 = fc0007eec000
s0 = fc000792b5c3  s1 = 0004  s2 = 0018
s3 = fc0007eefec8  s4 = 0008  s5 = f0a3
s6 = 000b
a0 = fc000792b5c3  a1 = 2f2f2f2f2f2f2f2f  a2 = 0004
a3 = 000b  a4 = f0a3  a5 = 0008
t8 = 0018  t9 =   t10= 22e1d02a
t11= 00011fd6f3b8  pv = fcb9a810  at = 22e1ccf8
gp = fcf03930  sp = (ptrval)
Trace:
[] proc_readdir_de+0x170/0x300
[] filldir64+0x0/0x320
[] proc_root_readdir+0x3c/0x80
[] iterate_dir+0x198/0x240
[] ksys_getdents64+0xa8/0x160
[] sys_getdents64+0x20/0x40
[] filldir64+0x0/0x320
[] entSys+0xa4/0xc0

Code:
 
 00063301
 07a3
 

[PATCH] staging: rtl8712: align arguments with open parenthesis

[Gabriela Bittencourt]

Cleans up checks of: "Alignment should match open parenthesis"

Signed-off-by: Gabriela Bittencourt 
---
 drivers/staging/rtl8712/osdep_service.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/osdep_service.h 
b/drivers/staging/rtl8712/osdep_service.h
index e939c4a954b3..d33ddffb7ad9 100644
--- a/drivers/staging/rtl8712/osdep_service.h
+++ b/drivers/staging/rtl8712/osdep_service.h
@@ -46,7 +46,7 @@ struct__queue {
} while (0)
 
 static inline u32 end_of_queue_search(struct list_head *head,
-   struct list_head *plist)
+ struct list_head *plist)
 {
return (head == plist);
 }
-- 
2.20.1

Re: [PATCH 4.4 00/36] 4.4.196-stable review

[kernelci.org bot]

stable-rc/linux-4.4.y boot: 39 boots: 1 failed, 36 passed with 2 conflicts 
(v4.4.195-37-g13cac61d31df)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.195-37-g13cac61d31df/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.195-37-g13cac61d31df/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.195-37-g13cac61d31df
Git Commit: 13cac61d31df3572c7a2c88f2f40c59e0a92baf2
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 21 unique boards, 10 SoC families, 8 builds out of 190

Boot Failure Detected:

arm64:
defconfig:
gcc-8:
qcom-qdf2400: 1 failed lab

Conflicting Boot Failures Detected: (These likely are not failures as other 
labs are reporting PASS. Needs review.)

x86_64:
x86_64_defconfig:
qemu_x86_64:
lab-baylibre: FAIL (gcc-8)
lab-linaro-lkft: PASS (gcc-8)

i386:
i386_defconfig:
qemu_i386:
lab-baylibre: FAIL (gcc-8)
lab-linaro-lkft: PASS (gcc-8)

---
For more info write to 

Re: [PATCH net-next 1/3] net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available

[kbuild test robot]

Hi Jose,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Jose-Abreu/net-stmmac-Improvements-for-next/20191007-013324
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-42-g38eda53-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: sparse: sparse: 
incorrect type in argument 1 (different address spaces) @@expected void 
[noderef]  *ioaddr @@got void [noderef]  *ioaddr @@
   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: sparse:
expected void [noderef]  *ioaddr
   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: sparse:got 
struct mac_device_info *hw
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4224:21: sparse: sparse: 
>> incorrect type in assignment (different base types) @@expected unsigned 
>> short [assigned] [usertype] vid @@got  short [assigned] [usertype] vid @@
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4224:21: sparse:
>> expected unsigned short [assigned] [usertype] vid
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4224:21: sparse:got 
>> restricted __le16 [usertype]

vim +4224 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

  4206  
  4207  static int stmmac_vlan_update(struct stmmac_priv *priv, bool is_double)
  4208  {
  4209  u32 crc, hash = 0;
  4210  int count = 0;
  4211  u16 vid = 0;
  4212  
  4213  for_each_set_bit(vid, priv->active_vlans, VLAN_N_VID) {
  4214  __le16 vid_le = cpu_to_le16(vid);
  4215  crc = bitrev32(~stmmac_vid_crc32_le(vid_le)) >> 28;
  4216  hash |= (1 << crc);
  4217  count++;
  4218  }
  4219  
  4220  if (!priv->dma_cap.vlhash) {
  4221  if (count > 2) /* VID = 0 always passes filter */
  4222  return -EOPNOTSUPP;
  4223  
> 4224  vid = cpu_to_le16(vid);
  4225  hash = 0;
  4226  }
  4227  
  4228  return stmmac_update_vlan_hash(priv, priv->hw, hash, vid, 
is_double);
  4229  }
  4230  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Linux 5.4-rc2

[Linus Torvalds]

Back to the usual Sunday afternoon schedule, and -rc2 is out.

Nothing particularly stands out here. It's roughly one third arch
updates, one third drivers, and one third "misc" (kvm selftests,
networking, filesystems, core kernel, header files etc). No real
theme, just random fixes all over the place.

The diffstat is pretty flat too, which is just another sign of "small
fixes all over".

So nothing looks particularly worrisome, but usually rc2 is fairly
calm and it takes a while for any regressions to be noticed. And this
one was one of the nice small rc2's (5.2 and 5.3 rc2's were both
larger than usual), but maybe it's because it was also a day shorter.

Anyway, nothing for it but to go out and test, people. Go at it!

   Linus

---

Aaron Liu (1):
  Revert "drm/amdgpu: disable stutter mode for renoir"

Adam Ford (1):
  ARM: omap2plus_defconfig: Enable DRM_TI_TFP410

Adam Zerella (1):
  docs: networking: Add title caret and missing doc

Albert Ou (1):
  riscv: Fix memblock reservation for device tree blob

Aleksa Sarai (4):
  lib: introduce copy_struct_from_user() helper
  clone3: switch to copy_struct_from_user()
  sched_setattr: switch to copy_struct_from_user()
  perf_event_open: switch to copy_struct_from_user()

Alex Deucher (1):
  drm/amdgpu: don't increment vram lost if we are in hibernation

Alex Gaynor (1):
  kbuild: correct formatting of header in kbuild module docs

Alexey Dobriyan (1):
  net: make sock_prot_memory_pressure() return "const char *"

Andrea Merello (1):
  net: phy: allow for reset line to be tied to a sleepy GPIO controller

Andrey Smirnov (1):
  dma-mapping: fix false positivse warnings in dma_common_free_remap()

Arnd Bergmann (8):
  drm/tilcdc: include linux/pinctrl/consumer.h again
  io_uring: use __kernel_timespec in timeout ABI
  ionic: select CONFIG_NET_DEVLINK
  drm/amdgpu: make pmu support optional, again
  drm/amdgpu: hide another #warning
  drm/amdgpu: display_mode_vba_21: remove uint typedef
  drm/amd/display: hide an unused variable
  drm/amd/display: fix dcn21 Makefile for clang

Austin Kim (1):
  scsi: qedf: Remove always false 'tmp_prio < 0' statement

Balasubramani Vivekanandan (1):
  tick: broadcast-hrtimer: Fix a race in bc_set_next

Balbir Singh (1):
  nvme-pci: Fix a race in controller removal

Borislav Petkov (1):
  char/random: Add a newline at the end of the file

Christian Brauner (2):
  fork: add kernel-doc for clone3
  sched: add kernel-doc for struct clone_args

Christian König (1):
  drm/amdgpu: revert "disable bulk moves for now"

Christophe JAILLET (2):
  ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
  mips: Loongson: Fix the link time qualifier of 'serial_exit()'

Dan Carpenter (1):
  nvme: fix an error code in nvme_init_subsystem()

David Ahern (3):
  ipv6: Handle race in addrconf_dad_work
  Revert "ipv6: Handle race in addrconf_dad_work"
  ipv6: Handle missing host route in __ipv6_ifa_notify

David Hildenbrand (4):
  xen/balloon: Set pages PageOffline() in balloon_add_region()
  xen/balloon: Drop __balloon_append()
  xen/balloon: Mark pages PG_offline in balloon_append()
  xen/balloon: Clear PG_offline in balloon_retrieve()

David Howells (1):
  rxrpc: Fix rxrpc_recvmsg tracepoint

Dexuan Cui (1):
  vsock: Fix a lockdep warning in __vsock_release()

Dmitry Goldin (1):
  kheaders: make headers archive reproducible

Dongli Zhang (1):
  xen-netfront: do not use ~0U as error return value for xennet_fill_frags()

Dotan Barak (1):
  net/rds: Fix error handling in rds_ib_add_one()

Douglas Anderson (1):
  MAINTAINERS: kgdb: Add myself as a reviewer for kgdb/kdb

Eric Dumazet (6):
  sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
  tcp: adjust rto_base in retransmits_timed_out()
  ipv6: drop incoming packets having a v4mapped source address
  tcp: fix slab-out-of-bounds in tcp_zerocopy_receive()
  sch_dsmark: fix potential NULL deref in dsmark_init()
  nfc: fix memory leak in llcp_sock_bind()

Eric Sandeen (1):
  vfs: Fix EOVERFLOW testing in put_compat_statfs64

Florian Westphal (1):
  netfilter: drop bridge nf reset from nf_reset

Gabriel Craciunescu (1):
  Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Gao Xiang (3):
  MAINTAINERS: erofs: complete sub-entries for erofs
  erofs: fix erofs_get_meta_page locking due to a cleanup
  erofs: fix mis-inplace determination related with noio chain

H. Nikolaus Schaller (1):
  DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again

Haishuang Yan (1):
  erspan: remove the incorrect mtu limit for erspan

Heiko Carstens (8):
  s390/atomic,bitops: mark function(s) __always_inline
  s390/cpu_mf: mark function(s) __always_inline
  s390/jump_label: mark function(s) __always_inline
  s390/mm: mark function(s) 

Re: [PATCH] staging: comedi: Capitalize macro name to fix camelcase checkpatch warning

[Al Viro]

On Sun, Oct 06, 2019 at 07:49:03PM +0100, Jules Irenge wrote:

[mA vs. MA]

Table 5.  SI prefixes
Factor  NameSymbol

10^6megaM

10^-3   milli   m

Confusing one for another (especially for electrical units) can be...
spectacular.  FYI, 1mA is more or less what you get if you lick
the terminals of a 9V battery; 1MA is about 30 times the current
in typical lightning strike...

Re: MAP_FIXED_NOREPLACE appears to break older i386 binaries

[Linus Torvalds]

On Sun, Oct 6, 2019 at 11:07 AM Linus Torvalds
 wrote:
>
> Yes, we should get this fixed. But I continue to ask you to point to
> the actual binaries for testing..

Just to bring the resolution back publicly to lkml after rmk sent me
test binaries in private email, the end result is commit b212921b13bd
("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings").

 Linus

[PATCH] staging: rtl8712: align arguments with open parenthesis

[Gabriela Bittencourt]

Cleans up checks of "Alignment should match open parenthesis"

Signed-off-by: Gabriela Bittencourt 
---
 drivers/staging/rtl8712/recv_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/recv_linux.c 
b/drivers/staging/rtl8712/recv_linux.c
index 70a4dcd4a1e5..808f21c5767a 100644
--- a/drivers/staging/rtl8712/recv_linux.c
+++ b/drivers/staging/rtl8712/recv_linux.c
@@ -61,7 +61,7 @@ int r8712_os_recvbuf_resource_alloc(struct _adapter *padapter,
 
 /*free os related resource in struct recv_buf*/
 int r8712_os_recvbuf_resource_free(struct _adapter *padapter,
-struct recv_buf *precvbuf)
+  struct recv_buf *precvbuf)
 {
if (precvbuf->pskb)
dev_kfree_skb_any(precvbuf->pskb);
-- 
2.20.1

[PATCH] staging: rtl8712: align block comments

[Gabriela Bittencourt]

Cleans up warnings of "Block comments should align the * on each line"

Signed-off-by: Gabriela Bittencourt 
---
 drivers/staging/rtl8712/recv_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/recv_linux.c 
b/drivers/staging/rtl8712/recv_linux.c
index 84c4c8580f9a..70a4dcd4a1e5 100644
--- a/drivers/staging/rtl8712/recv_linux.c
+++ b/drivers/staging/rtl8712/recv_linux.c
@@ -115,8 +115,8 @@ void r8712_recv_indicatepkt(struct _adapter *adapter,
skb->protocol = eth_type_trans(skb, adapter->pnetdev);
netif_rx(skb);
recvframe->u.hdr.pkt = NULL; /* pointers to NULL before
-   * r8712_free_recvframe()
-   */
+ * r8712_free_recvframe()
+ */
r8712_free_recvframe(recvframe, free_recv_queue);
return;
 _recv_indicatepkt_drop:
-- 
2.20.1

Re: [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages()

[David Hildenbrand]

On 06.10.19 21:58, Damian Tometzki wrote:
> Hello David,
> 
> patch 05/10 is missing in the patch series. 
> 

Hi Damian,

not really. Could be that lkml is slow today. E.g., check

https://marc.info/?l=linux-mm=157035222620403=2

and especially

https://marc.info/?l=linux-mm=157035225120440=2

All mails popped up on the mm list.

> 
> On Sun, 06. Oct 10:56, David Hildenbrand wrote:
>> From: "Aneesh Kumar K.V" 
>>
>> With an altmap, the memmap falling into the reserved altmap space are
>> not initialized and, therefore, contain a garbage NID and a garbage
>> zone. Make sure to read the NID/zone from a memmap that was initialzed.
>>
>> This fixes a kernel crash that is observed when destroying a namespace:
>>
>> [   81.356173] kernel BUG at include/linux/mm.h:1107!
>> cpu 0x1: Vector: 700 (Program Check) at [c00274087890]
>> pc: c04b9728: memunmap_pages+0x238/0x340
>> lr: c04b9724: memunmap_pages+0x234/0x340
>> ...
>> pid   = 3669, comm = ndctl
>> kernel BUG at include/linux/mm.h:1107!
>> [c00274087ba0] c09e3500 devm_action_release+0x30/0x50
>> [c00274087bc0] c09e4758 release_nodes+0x268/0x2d0
>> [c00274087c30] c09dd144 
>> device_release_driver_internal+0x174/0x240
>> [c00274087c70] c09d9dfc unbind_store+0x13c/0x190
>> [c00274087cb0] c09d8a24 drv_attr_store+0x44/0x60
>> [c00274087cd0] c05a7470 sysfs_kf_write+0x70/0xa0
>> [c00274087d10] c05a5cac kernfs_fop_write+0x1ac/0x290
>> [c00274087d60] c04be45c __vfs_write+0x3c/0x70
>> [c00274087d80] c04c26e4 vfs_write+0xe4/0x200
>> [c00274087dd0] c04c2a6c ksys_write+0x7c/0x140
>> [c00274087e20] c000bbd0 system_call+0x5c/0x68
>>
>> Cc: Dan Williams 
>> Cc: Andrew Morton 
>> Cc: Jason Gunthorpe 
>> Cc: Logan Gunthorpe 
>> Cc: Ira Weiny 
>> Signed-off-by: Aneesh Kumar K.V 
>> [ minimze code changes, rephrase description ]
>> Signed-off-by: David Hildenbrand 
>> ---
>>  mm/memremap.c | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/memremap.c b/mm/memremap.c
>> index 557e53c6fb46..8c2fb44c3b4d 100644
>> --- a/mm/memremap.c
>> +++ b/mm/memremap.c
>> @@ -123,6 +123,7 @@ static void dev_pagemap_cleanup(struct dev_pagemap 
>> *pgmap)
>>  void memunmap_pages(struct dev_pagemap *pgmap)
>>  {
>>  struct resource *res = >res;
>> +struct page *first_page;
>>  unsigned long pfn;
>>  int nid;
>>  
>> @@ -131,14 +132,16 @@ void memunmap_pages(struct dev_pagemap *pgmap)
>>  put_page(pfn_to_page(pfn));
>>  dev_pagemap_cleanup(pgmap);
>>  
>> +/* make sure to access a memmap that was actually initialized */
>> +first_page = pfn_to_page(pfn_first(pgmap));
>> +
>>  /* pages are dead and unused, undo the arch mapping */
>> -nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
>> +nid = page_to_nid(first_page);
> 
> Why we need 'nid = page_to_nid(first_page)' we didnt use it anymore in this 
> function ?

Please see ...

> 
>>  
>>  mem_hotplug_begin();
>>  if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
>> -pfn = PHYS_PFN(res->start);
>> -__remove_pages(page_zone(pfn_to_page(pfn)), pfn,
>> - PHYS_PFN(resource_size(res)), NULL);
>> +__remove_pages(page_zone(first_page), PHYS_PFN(res->start),
>> +   PHYS_PFN(resource_size(res)), NULL);
>>  } else {
>>  arch_remove_memory(nid, res->start, resource_size(res),
   ^ here

:)

>>  pgmap_altmap(pgmap));



-- 

Thanks,

David / dhildenb

[PATCH v5 2/3] docs: driver-api: generic-counter: Update Count and Signal data types

[William Breathitt Gray]

Count data is now always represented as an unsigned integer, while
Signal data is either SIGNAL_LOW or SIGNAL_HIGH. In addition,
clarification changes and additions are made to better explain the
theory of the Generic Counter interface and its use.

Signed-off-by: William Breathitt Gray 
---
 Documentation/driver-api/generic-counter.rst | 162 +++
 1 file changed, 92 insertions(+), 70 deletions(-)

diff --git a/Documentation/driver-api/generic-counter.rst 
b/Documentation/driver-api/generic-counter.rst
index 8382f01a53e3..e622f8f6e56a 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -7,7 +7,7 @@ Generic Counter Interface
 Introduction
 
 
-Counter devices are prevalent within a diverse spectrum of industries.
+Counter devices are prevalent among a diverse spectrum of industries.
 The ubiquitous presence of these devices necessitates a common interface
 and standard of interaction and exposure. This driver API attempts to
 resolve the issue of duplicate code found among existing counter device
@@ -26,23 +26,72 @@ the Generic Counter interface.
 
 There are three core components to a counter:
 
-* Count:
-  Count data for a set of Signals.
-
 * Signal:
-  Input data that is evaluated by the counter to determine the count
-  data.
+  Stream of data to be evaluated by the counter.
 
 * Synapse:
-  The association of a Signal with a respective Count.
+  Association of a Signal, and evaluation trigger, with a Count.
+
+* Count:
+  Accumulation of the effects of connected Synapses.
+
+SIGNAL
+--
+A Signal represents a stream of data. This is the input data that is
+evaluated by the counter to determine the count data; e.g. a quadrature
+signal output line of a rotary encoder. Not all counter devices provide
+user access to the Signal data, so exposure is optional for drivers.
+
+When the Signal data is available for user access, the Generic Counter
+interface provides the following available signal values:
+
+* SIGNAL_LOW:
+  Signal line is in a low state.
+
+* SIGNAL_HIGH:
+  Signal line is in a high state.
+
+A Signal may be associated with one or more Counts.
+
+SYNAPSE
+---
+A Synapse represents the association of a Signal with a Count. Signal
+data affects respective Count data, and the Synapse represents this
+relationship.
+
+The Synapse action mode specifies the Signal data condition that
+triggers the respective Count's count function evaluation to update the
+count data. The Generic Counter interface provides the following
+available action modes:
+
+* None:
+  Signal does not trigger the count function. In Pulse-Direction count
+  function mode, this Signal is evaluated as Direction.
+
+* Rising Edge:
+  Low state transitions to high state.
+
+* Falling Edge:
+  High state transitions to low state.
+
+* Both Edges:
+  Any state transition.
+
+A counter is defined as a set of input signals associated with count
+data that are generated by the evaluation of the state of the associated
+input signals as defined by the respective count functions. Within the
+context of the Generic Counter interface, a counter consists of Counts
+each associated with a set of Signals, whose respective Synapse
+instances represent the count function update conditions for the
+associated Counts.
+
+A Synapse associates one Signal with one Count.
 
 COUNT
 -
-A Count represents the count data for a set of Signals. The Generic
-Counter interface provides the following available count data types:
-
-* COUNT_POSITION:
-  Unsigned integer value representing position.
+A Count represents the accumulation of the effects of connected
+Synapses; i.e. the count data for a set of Signals. The Generic
+Counter interface represents the count data as a natural number.
 
 A Count has a count function mode which represents the update behavior
 for the count data. The Generic Counter interface provides the following
@@ -86,60 +135,7 @@ available count function modes:
 Any state transition on either quadrature pair signals updates the
 respective count. Quadrature encoding determines the direction.
 
-A Count has a set of one or more associated Signals.
-
-SIGNAL
---
-A Signal represents a counter input data; this is the input data that is
-evaluated by the counter to determine the count data; e.g. a quadrature
-signal output line of a rotary encoder. Not all counter devices provide
-user access to the Signal data.
-
-The Generic Counter interface provides the following available signal
-data types for when the Signal data is available for user access:
-
-* SIGNAL_LEVEL:
-  Signal line state level. The following states are possible:
-
-  - SIGNAL_LEVEL_LOW:
-Signal line is in a low state.
-
-  - SIGNAL_LEVEL_HIGH:
-Signal line is in a high state.
-
-A Signal may be associated with one or more Counts.
-
-SYNAPSE

-A Synapse represents the association of a Signal with a respective
-Count. Signal data affects 

[PATCH v5 3/3] counter: Fix typo in action_get description

[William Breathitt Gray]

The action_get callback returns a Synapse's action mode.

Signed-off-by: William Breathitt Gray 
---
 include/linux/counter.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/counter.h b/include/linux/counter.h
index 32fb4d8cc3fd..9dbd5df4cd34 100644
--- a/include/linux/counter.h
+++ b/include/linux/counter.h
@@ -315,7 +315,7 @@ enum counter_signal_value {
  * Count's functions_list array.
  * @action_get:function to get the current action mode. 
Returns 0 on
  * success and negative error code on error. The index of
- * the respective Signal's returned action mode should be
+ * the respective Synapse's returned action mode should be
  * passed back via the action parameter.
  * @action_set:function to set the action mode. action is the 
index of
  * the requested action mode from the respective Synapse's
-- 
2.23.0

[PATCH v5 0/3] Simplify count_read/count_write/signal_read

[William Breathitt Gray]

Changes in v5:
 - Add changes and additions to generic-counter.rst to clarify theory
   and use of the Generic Counter interface
 - Fix typo in counter.h action_get description comment

The changes in this patchset will not affect the userspace interface.
Rather, these changes are intended to simplify the kernelspace Counter
callbacks for counter device driver authors.

The following main changes are proposed:

* Retire the opaque counter_count_read_value/counter_count_write_value
  structures and simply represent count data as an unsigned integer.

* Retire the opaque counter_signal_read_value structure and represent
  Signal data as a counter_signal_value enum.

These changes should reduce some complexity and code in the use and
implementation of the count_read, count_write, and signal_read
callbacks.

The opaque structures for Count data and Signal data were introduced
originally in anticipation of supporting various representations of
counter data (e.g. arbitrary-precision tallies, floating-point spherical
coordinate positions, etc). However, with the counter device drivers
that have appeared, it's become apparent that utilizing opaque
structures in kernelspace is not the best approach to take.

I believe it is best to let userspace applications decide how to
interpret the count data they receive. There are a couple of reasons why
it would be good to do so:

* Users use their devices in unexpected ways.

  For example, a quadrature encoder counter device is typically used to
  keep track of the position of a motor, but a user could set the device
  in a pulse-direction mode and instead use it to count sporadic rising
  edges from an arbitrary signal line unrelated to positioning. Users
  should have the freedom to decide what their data represents.

* Most counter devices represent data as unsigned integers anyway.

  For example, whether the device is a tally counter or position
  counter, the count data is represented to the user as an unsigned
  integer value. So specifying that one device is representing tallies
  while the other specifies positions does not provide much utility from
  an interface perspective.

For these reasons, the count_read and count_write callbacks have been
redefined to pass count data directly as unsigned long instead of passed
via opaque structures:

count_read(struct counter_device *counter,
   struct counter_count *count, unsigned long *val);
count_write(struct counter_device *counter,
struct counter_count *count, unsigned long val);

Similarly, the signal_read is redefined to pass Signal data directly as
a counter_signal_value enum instead of via an opaque structure:

signal_read(struct counter_device *counter,
struct counter_signal *signal,
enum counter_signal_value *val);

The counter_signal_value enum is simply the counter_signal_level enum
redefined to remove the references to the Signal data "level" data type.

William Breathitt Gray (3):
  counter: Simplify the count_read and count_write callbacks
  docs: driver-api: generic-counter: Update Count and Signal data types
  counter: Fix typo in action_get description

 Documentation/driver-api/generic-counter.rst | 162 +++
 drivers/counter/104-quad-8.c |  33 ++--
 drivers/counter/counter.c| 101 ++--
 drivers/counter/ftm-quaddec.c|  14 +-
 drivers/counter/stm32-lptimer-cnt.c  |   5 +-
 drivers/counter/stm32-timer-cnt.c|  17 +-
 drivers/counter/ti-eqep.c|  19 +--
 include/linux/counter.h  |  76 ++---
 8 files changed, 144 insertions(+), 283 deletions(-)


base-commit: 0c3aa63a842d84990bd02622f2fa50d2bd33c652
prerequisite-patch-id: ebe284609b3db8d4130ea2915f7f7b185c743a70
prerequisite-patch-id: cbe857759f10d875690df125d18bc04f585ac7c9
prerequisite-patch-id: 21f2660dc88627387ee4666d08044c63dd961dae
-- 
2.23.0

[PATCH v5 1/3] counter: Simplify the count_read and count_write callbacks

[William Breathitt Gray]

The count_read and count_write callbacks are simplified to pass val as
unsigned long rather than as an opaque data structure. The opaque
counter_count_read_value and counter_count_write_value structures,
counter_count_value_type enum, and relevant counter_count_read_value_set
and counter_count_write_value_get functions, are removed as they are no
longer used.

Cc: Patrick Havelange 
Acked-by: Fabrice Gasnier 
Acked-by: David Lechner 
Signed-off-by: William Breathitt Gray 
---
 drivers/counter/104-quad-8.c|  33 +++--
 drivers/counter/counter.c   | 101 +---
 drivers/counter/ftm-quaddec.c   |  14 ++--
 drivers/counter/stm32-lptimer-cnt.c |   5 +-
 drivers/counter/stm32-timer-cnt.c   |  17 ++---
 drivers/counter/ti-eqep.c   |  19 ++
 include/linux/counter.h |  74 +++-
 7 files changed, 51 insertions(+), 212 deletions(-)

diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
index 00b113f4b958..17e67a84777d 100644
--- a/drivers/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -562,11 +562,10 @@ static const struct iio_chan_spec quad8_channels[] = {
 };
 
 static int quad8_signal_read(struct counter_device *counter,
-   struct counter_signal *signal, struct counter_signal_read_value *val)
+   struct counter_signal *signal, enum counter_signal_value *val)
 {
const struct quad8_iio *const priv = counter->priv;
unsigned int state;
-   enum counter_signal_level level;
 
/* Only Index signal levels can be read */
if (signal->id < 16)
@@ -575,22 +574,19 @@ static int quad8_signal_read(struct counter_device 
*counter,
state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
& BIT(signal->id - 16);
 
-   level = (state) ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
-
-   counter_signal_read_value_set(val, COUNTER_SIGNAL_LEVEL, );
+   *val = (state) ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
 
return 0;
 }
 
 static int quad8_count_read(struct counter_device *counter,
-   struct counter_count *count, struct counter_count_read_value *val)
+   struct counter_count *count, unsigned long *val)
 {
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
unsigned int flags;
unsigned int borrow;
unsigned int carry;
-   unsigned long position;
int i;
 
flags = inb(base_offset + 1);
@@ -598,36 +594,27 @@ static int quad8_count_read(struct counter_device 
*counter,
carry = !!(flags & QUAD8_FLAG_CT);
 
/* Borrow XOR Carry effectively doubles count range */
-   position = (unsigned long)(borrow ^ carry) << 24;
+   *val = (unsigned long)(borrow ^ carry) << 24;
 
/* Reset Byte Pointer; transfer Counter to Output Latch */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
 base_offset + 1);
 
for (i = 0; i < 3; i++)
-   position |= (unsigned long)inb(base_offset) << (8 * i);
-
-   counter_count_read_value_set(val, COUNTER_COUNT_POSITION, );
+   *val |= (unsigned long)inb(base_offset) << (8 * i);
 
return 0;
 }
 
 static int quad8_count_write(struct counter_device *counter,
-   struct counter_count *count, struct counter_count_write_value *val)
+   struct counter_count *count, unsigned long val)
 {
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
-   int err;
-   unsigned long position;
int i;
 
-   err = counter_count_write_value_get(, COUNTER_COUNT_POSITION,
-   val);
-   if (err)
-   return err;
-
/* Only 24-bit values are supported */
-   if (position > 0xFF)
+   if (val > 0xFF)
return -EINVAL;
 
/* Reset Byte Pointer */
@@ -635,7 +622,7 @@ static int quad8_count_write(struct counter_device *counter,
 
/* Counter can only be set via Preset Register */
for (i = 0; i < 3; i++)
-   outb(position >> (8 * i), base_offset);
+   outb(val >> (8 * i), base_offset);
 
/* Transfer Preset Register to Counter */
outb(QUAD8_CTR_RLD | QUAD8_RLD_PRESET_CNTR, base_offset + 1);
@@ -644,9 +631,9 @@ static int quad8_count_write(struct counter_device *counter,
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
 
/* Set Preset Register back to original value */
-   position = priv->preset[count->id];
+   val = priv->preset[count->id];
for (i = 0; i < 3; i++)
-   outb(position >> (8 * i), base_offset);
+   outb(val >> (8 * i), base_offset);
 
/* Reset Borrow, Carry, Compare, and Sign flags */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_FLAGS, base_offset + 1);
diff --git a/drivers/counter/counter.c 

[PATCH] staging: vt6656: remove duplicated blank line

[Gabriela Bittencourt]

Cleans up checks of "don't use multiple blank line"

Signed-off-by: Gabriela Bittencourt 
---
 drivers/staging/vt6656/main_usb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index 856ba97aec4f..a1884b5cc915 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -362,7 +362,6 @@ static int vnt_init_registers(struct vnt_private *priv)
goto end;
}
 
-
ret = vnt_mac_set_led(priv, LEDSTS_TMLEN, 0x38);
if (ret)
goto end;
-- 
2.20.1

Re: [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages()

[Damian Tometzki]

Hello David,

patch 05/10 is missing in the patch series. 


On Sun, 06. Oct 10:56, David Hildenbrand wrote:
> From: "Aneesh Kumar K.V" 
> 
> With an altmap, the memmap falling into the reserved altmap space are
> not initialized and, therefore, contain a garbage NID and a garbage
> zone. Make sure to read the NID/zone from a memmap that was initialzed.
> 
> This fixes a kernel crash that is observed when destroying a namespace:
> 
> [   81.356173] kernel BUG at include/linux/mm.h:1107!
> cpu 0x1: Vector: 700 (Program Check) at [c00274087890]
> pc: c04b9728: memunmap_pages+0x238/0x340
> lr: c04b9724: memunmap_pages+0x234/0x340
> ...
> pid   = 3669, comm = ndctl
> kernel BUG at include/linux/mm.h:1107!
> [c00274087ba0] c09e3500 devm_action_release+0x30/0x50
> [c00274087bc0] c09e4758 release_nodes+0x268/0x2d0
> [c00274087c30] c09dd144 device_release_driver_internal+0x174/0x240
> [c00274087c70] c09d9dfc unbind_store+0x13c/0x190
> [c00274087cb0] c09d8a24 drv_attr_store+0x44/0x60
> [c00274087cd0] c05a7470 sysfs_kf_write+0x70/0xa0
> [c00274087d10] c05a5cac kernfs_fop_write+0x1ac/0x290
> [c00274087d60] c04be45c __vfs_write+0x3c/0x70
> [c00274087d80] c04c26e4 vfs_write+0xe4/0x200
> [c00274087dd0] c04c2a6c ksys_write+0x7c/0x140
> [c00274087e20] c000bbd0 system_call+0x5c/0x68
> 
> Cc: Dan Williams 
> Cc: Andrew Morton 
> Cc: Jason Gunthorpe 
> Cc: Logan Gunthorpe 
> Cc: Ira Weiny 
> Signed-off-by: Aneesh Kumar K.V 
> [ minimze code changes, rephrase description ]
> Signed-off-by: David Hildenbrand 
> ---
>  mm/memremap.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 557e53c6fb46..8c2fb44c3b4d 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -123,6 +123,7 @@ static void dev_pagemap_cleanup(struct dev_pagemap *pgmap)
>  void memunmap_pages(struct dev_pagemap *pgmap)
>  {
>   struct resource *res = >res;
> + struct page *first_page;
>   unsigned long pfn;
>   int nid;
>  
> @@ -131,14 +132,16 @@ void memunmap_pages(struct dev_pagemap *pgmap)
>   put_page(pfn_to_page(pfn));
>   dev_pagemap_cleanup(pgmap);
>  
> + /* make sure to access a memmap that was actually initialized */
> + first_page = pfn_to_page(pfn_first(pgmap));
> +
>   /* pages are dead and unused, undo the arch mapping */
> - nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
> + nid = page_to_nid(first_page);

Why we need 'nid = page_to_nid(first_page)' we didnt use it anymore in this 
function ?

>  
>   mem_hotplug_begin();
>   if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
> - pfn = PHYS_PFN(res->start);
> - __remove_pages(page_zone(pfn_to_page(pfn)), pfn,
> -  PHYS_PFN(resource_size(res)), NULL);
> + __remove_pages(page_zone(first_page), PHYS_PFN(res->start),
> +PHYS_PFN(resource_size(res)), NULL);
>   } else {
>   arch_remove_memory(nid, res->start, resource_size(res),
>   pgmap_altmap(pgmap));
> -- 
> 2.21.0
>
Best regards
Damian
 

Re: [PATCH v10 12/16] leds: lp55xx: Add multicolor framework support to lp55xx

[Jacek Anaszewski]

Dan,

On 10/1/19 4:56 PM, Dan Murphy wrote:
> Add multicolor framework support for the lp55xx family.
> 
> Signed-off-by: Dan Murphy 
> ---
>  drivers/leds/Kconfig  |   1 +
>  drivers/leds/leds-lp55xx-common.c | 169 +++---
>  drivers/leds/leds-lp55xx-common.h |  11 ++
>  include/linux/platform_data/leds-lp55xx.h |   6 +
>  4 files changed, 163 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 84f60e35c5ee..dc3d9f2194cd 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -377,6 +377,7 @@ config LEDS_LP50XX
>  config LEDS_LP55XX_COMMON
>   tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
>   depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
> + depends on LEDS_CLASS_MULTI_COLOR && OF
>   select FW_LOADER
>   select FW_LOADER_USER_HELPER
>   help
> diff --git a/drivers/leds/leds-lp55xx-common.c 
> b/drivers/leds/leds-lp55xx-common.c
> index 44ced02b49f9..5de4f1789a44 100644
> --- a/drivers/leds/leds-lp55xx-common.c
> +++ b/drivers/leds/leds-lp55xx-common.c
> @@ -131,14 +131,50 @@ static struct attribute *lp55xx_led_attrs[] = {
>  };
>  ATTRIBUTE_GROUPS(lp55xx_led);
>  
> +struct led_mc_color_conversion color_component[LP55XX_MAX_GROUPED_CHAN];

Why is this global? Please move it to lp55xx_set_brightness().

> +
> +static int lp55xx_get_channel(struct lp55xx_led *led, int color_id)
> +{
> + int i;
> +
> + for (i = 0; i < led->mc_cdev.num_leds; i++) {
> + if (led->channel_color[i] == color_id)
> + return led->grouped_channels[i];
> + }
> +
> + return -EINVAL;
> +}
> +
>  static int lp55xx_set_brightness(struct led_classdev *cdev,
>enum led_brightness brightness)
>  {
>   struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
>   struct lp55xx_device_config *cfg = led->chip->cfg;
> + int channel_num;
> + int ret;
> + int i;
>  
> - led->brightness = (u8)brightness;
> - return cfg->brightness_fn(led);
> + if (led->mc_cdev.num_leds > 1) {
> + led_mc_calc_brightness(>mc_cdev, brightness,
> +_component[0]);

s/_component[0]/color_component/

> +
> + for (i = 0; i < led->mc_cdev.num_leds; i++) {
> + channel_num = lp55xx_get_channel(led,
> + color_component[i].color_id);
> + if (channel_num < 0)
> + return channel_num;
> +
> + ret = cfg->color_intensity_fn(led, channel_num,
> +  color_component[i].brightness);

If you passed struct led_mc_color_conversion instead of brightness,
then in the color_intensity_fn op you could obtain channel numbers
by calling lp55xx_get_channel in a loop. And you could setup the whole
cluster in a single call.

> + if (ret)
> + return ret;
> + }
> + } else {
> + led->brightness = (u8)brightness;
> + ret = cfg->brightness_fn(led);
> + }
> +
> + return ret;
>  }
>  
>  static int lp55xx_init_led(struct lp55xx_led *led,
> @@ -147,9 +183,9 @@ static int lp55xx_init_led(struct lp55xx_led *led,
>   struct lp55xx_platform_data *pdata = chip->pdata;
>   struct lp55xx_device_config *cfg = chip->cfg;
>   struct device *dev = >cl->dev;
> + int max_channel = cfg->max_channel;
>   char name[32];
>   int ret;
> - int max_channel = cfg->max_channel;
>  
>   if (chan >= max_channel) {
>   dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
> @@ -159,10 +195,37 @@ static int lp55xx_init_led(struct lp55xx_led *led,
>   if (pdata->led_config[chan].led_current == 0)
>   return 0;
>  
> + if (pdata->led_config[chan].name) {
> + led->cdev.name = pdata->led_config[chan].name;
> + } else {
> + snprintf(name, sizeof(name), "%s:channel%d",
> + pdata->label ? : chip->cl->name, chan);
> + led->cdev.name = name;
> + }
> +
> + if (pdata->led_config[chan].num_colors > 1) {
> + led->mc_cdev.led_cdev = >cdev;
> + led->cdev.brightness_set_blocking = lp55xx_set_brightness;
> + led->cdev.groups = lp55xx_led_groups;
> + led->mc_cdev.num_leds = pdata->led_config[chan].num_colors;
> + led->mc_cdev.available_colors =
> + pdata->led_config[chan].available_colors;
> + memcpy(led->channel_color,
> +pdata->led_config[chan].channel_color,
> +sizeof(led->channel_color));
> + memcpy(led->grouped_channels,
> +pdata->led_config[chan].grouped_channels,
> +sizeof(led->grouped_channels));
> + } else {
> +
> 

Re: [PATCH] arm64: dts: rockchip: Fix usb-c on Hugsun X99 TV Box

[Vicente Bergas]

On Saturday, October 5, 2019 2:52:00 AM CEST, Vivek Unune wrote:

On Fri, Oct 04, 2019 at 11:45:08PM +0200, Heiko Stuebner wrote:

Hi Vivek,

Am Montag, 30. September 2019, 01:46:15 CEST schrieb Vivek Unune: ...


Hi Heiko,

I tested the c09b73cf patch without modifying exsisting dts. I can confirm
that that patch doesn't work for me. No usb-c devices were recognized.

Vicenç - were you able to test it?


I can also confirm that

c09b73cfac2a9317f1104169045c519c6021aa1d
usb: dwc3: don't set gadget->is_otg flag

alone does not fix the issue.

e1d9149e8389f1690cdd4e4056766dd26488a0fe
arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire

is still required for the USB-C to work on the Sapphire board.

Regards,
 Vicenç.


As soon as I apply dts patch, usb-c devices are recognized.

Thanks,

Vivek