Re: [PATCH] i2c: i2c-qcom-geni: Fix DMA transfer race

[Stephen Boyd]

Quoting Douglas Anderson (2020-07-20 17:24:53)
> When I have KASAN enabled on my kernel and I start stressing the
> touchscreen my system tends to hang.  The touchscreen is one of the
> only things that does a lot of big i2c transfers and ends up hitting
> the DMA paths in the geni i2c driver.  It appears that KASAN adds
> enough delay in my system to tickle a race condition in the DMA setup
> code.
> 
> When the system hangs, I found that it was running the geni_i2c_irq()
> over and over again.  It had these:
> 
> m_stat   = 0x0480
> rx_st= 0x3011
> dm_tx_st = 0x
> dm_rx_st = 0x
> dma  = 0x0001
> 
> Notably we're in DMA mode but are getting M_RX_IRQ_EN and
> M_RX_FIFO_WATERMARK_EN over and over again.
> 
> Putting some traces in geni_i2c_rx_one_msg() showed that when we
> failed we were getting to the start of geni_i2c_rx_one_msg() but were
> never executing geni_se_rx_dma_prep().
> 
> I believe that the problem here is that we are writing the transfer
> length and setting up the geni command before we run
> geni_se_rx_dma_prep().  If a transfer makes it far enough before we do
> that then we get into the state I have observed.  Let's change the
> order, which seems to work fine.

Does the length matter or the I2C_READ m_cmd matter? Or somehow both?
Otherwise it sounds correct to me that we're configuring it to start the
read before mapping the buffer.

> 
> Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm 
> GENI I2C controller")
> Signed-off-by: Douglas Anderson 
> ---
> 
>  drivers/i2c/busses/i2c-qcom-geni.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 18d1e4fd4cf3..21e27f10510a 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -366,15 +366,15 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev 
> *gi2c, struct i2c_msg *msg,
> else
> geni_se_select_mode(se, GENI_SE_FIFO);
>  
> -   writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
> -   geni_se_setup_m_cmd(se, I2C_READ, m_param);
> -
> if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, _dma)) {
> geni_se_select_mode(se, GENI_SE_FIFO);
> i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
> dma_buf = NULL;
> }
>  

I worry that we also need a dmb() here to make sure the dma buffer is
properly mapped before this write to the device is attempted. But it may
only matter to be before the I2C_READ.

> +   writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
> +   geni_se_setup_m_cmd(se, I2C_READ, m_param);
> +
> time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
> if (!time_left)
> geni_i2c_abort_xfer(gi2c);

Re: kworker/0:3+pm hogging CPU

[Michal Hocko]

On Mon 20-07-20 16:02:43, Alan Stern wrote:
> On Mon, Jul 20, 2020 at 08:16:05PM +0200, Michal Hocko wrote:
> > On Mon 20-07-20 13:48:12, Alan Stern wrote:
> > > On Mon, Jul 20, 2020 at 07:45:30PM +0200, Michal Hocko wrote:
> > > > On Mon 20-07-20 13:38:07, Alan Stern wrote:
> > > > > On Mon, Jul 20, 2020 at 06:33:55PM +0200, Michal Hocko wrote:
> > > > > > On Mon 20-07-20 11:12:55, Alan Stern wrote:
> > > > > > [...]
> > > > > > >   sudo echo 'module usbcore =p' >/debug/dynamic_debug/control
> > > > > > > 
> > > > > > > Then wait long enough for some interesting messages to appear in 
> > > > > > > the 
> > > > > > > kernel log (it should only take a few seconds if the worker 
> > > > > > > thread is as 
> > > > > > > busy as you say) and collect the output from the dmesg command.
> > > > > > > 
> > > > > > > To turn dynamic debugging back off when you're finished, use the 
> > > > > > > same 
> > > > > > > command with "=p" changed to "-p".
> > > > > > 
> > > > > > [   95.395815] hub 2-0:1.0: state 7 ports 6 chg 0006 evt 
> > > > > > [   95.395824] usb usb2-port1: status 0088, change , 5.0 Gb/s
> > > > > > [   95.395838] usb usb2-port2: status 0088, change , 5.0 Gb/s
> > > > > > [   95.396016] hub 2-0:1.0: hub_suspend
> > > > > > [   95.396023] usb usb2: bus auto-suspend, wakeup 1
> > > > > > [   95.396029] usb usb2: bus suspend fail, err -16
> > > > > 
> > > > > Okay, that's the problem.  You may get more specific information 
> > > > > about 
> > > > > the suspend failure if you turn on dynamic debugging for the xhci-hcd 
> > > > > module (same command as above but with xhci-hcd instead of usbcore).
> > > > 
> > > > Would that help to pinpoint the problem down?
> > > 
> > > It might.  I can't say for sure without seeing the output.
> > 
> > echo 'module xhci-hcd =p' >/sys/kernel/debug/dynamic_debug/control
> > 
> > doesn't yield to any output. I have tried both with and without usbcore
> > debug output enabled. In the former there is no new output and for the
> > later I get the same I have posted earlier.
> 
> Sorry, my mistake.  The module name needs to be "xhci_hcd" with an '_' 
> character, not a '-' character -- the same as what shows up in the lsmod 
> output.


[14766.973734] xhci_hcd :00:14.0: Get port status 2-1 read: 0xe88, 
return 0x88
[14766.973738] xhci_hcd :00:14.0: Get port status 2-2 read: 0xe88, 
return 0x88
[14766.973742] xhci_hcd :00:14.0: Get port status 2-3 read: 0xe0002a0, 
return 0x2a0
[14766.973746] xhci_hcd :00:14.0: Get port status 2-4 read: 0xe0002a0, 
return 0x2a0
[14766.973750] xhci_hcd :00:14.0: Get port status 2-5 read: 0xe0002a0, 
return 0x2a0
[14766.973754] xhci_hcd :00:14.0: Get port status 2-6 read: 0xe0002a0, 
return 0x2a0
[14766.973759] xhci_hcd :00:14.0: Get port status 2-1 read: 0xe88, 
return 0x88
[14766.973763] xhci_hcd :00:14.0: Get port status 2-2 read: 0xe88, 
return 0x88
[14766.973771] xhci_hcd :00:14.0: set port remote wake mask, actual port 0 
status  = 0xe88
[14766.973780] xhci_hcd :00:14.0: set port remote wake mask, actual port 1 
status  = 0xe88
[14766.973789] xhci_hcd :00:14.0: set port remote wake mask, actual port 2 
status  = 0xe0002a0
[14766.973798] xhci_hcd :00:14.0: set port remote wake mask, actual port 3 
status  = 0xe0002a0
[14766.973807] xhci_hcd :00:14.0: set port remote wake mask, actual port 4 
status  = 0xe0002a0
[14766.973816] xhci_hcd :00:14.0: set port remote wake mask, actual port 5 
status  = 0xe0002a0
[14766.973830] xhci_hcd :00:14.0: Bus suspend bailout, port over-current 
detected

Repeating again and again. The last message suggests a HW problem? But
why does the kernel try the same thing over and over?

> You could also try collect a usbmon trace from the .../2u file.  It does 
> seem that bus 2 is where the problem occurs.

a random sample

8882447743c0 2551256361 S Ii:2:001:1 -115:2048 4 <
888040808cc0 2551256367 C Ci:2:001:0 0 4 = 8800
888040808cc0 2551256373 C Ci:2:001:0 0 4 = 8800
888040808cc0 2551256377 S Co:2:001:0 s 23 03 001b 0701  0
888040808cc0 2551256384 C Co:2:001:0 0 0
888040808cc0 2551256432 C Co:2:001:0 0 0
888040808cc0 2551256482 C Co:2:001:0 0 0
888040808cc0 2551256531 C Co:2:001:0 0 0
888040808cc0 2551256535 S Co:2:001:0 s 23 03 001b 0705  0
888040808cc0 2551256542 C Co:2:001:0 0 0
888040808cc0 2551256551 C Co:2:001:0 0 0
8882447743c0 2551256555 C Ii:2:001:1 -2:2048 0
888040808cc0 2551256562 S Ci:2:001:0 s a3 00  0001 0004 4 <
888040808cc0 2551256566 C Ci:2:001:0 0 4 = 8800
888040808cc0 2551256568 S Ci:2:001:0 s a3 00  0002 0004 4 <
888040808cc0 2551256573 S Ci:2:001:0 s a3 00  0003 0004 4 <
888040808cc0 2551256579 S Ci:2:001:0 s a3 00  0004 0004 4 <
888040808cc0 2551256584 S Ci:2:001:0 s a3 00  0005 0004 4 <
888040808cc0 2551256625 S Ci:2:001:0 s a3 00  0006 0004 4 <
888040808cc0 2551256686 

Re: [PATCH V2 vhost next 10/10] vdpa/mlx5: Add VDPA driver for supported mlx5 devices

[Jason Wang]

On 2020/7/20 下午3:14, Eli Cohen wrote:

Add a front end VDPA driver that registers in the VDPA bus and provides
networking to a guest. The VDPA driver creates the necessary resources
on the VF it is driving such that data path will be offloaded.

Notifications are being communicated through the driver.

Currently, only VFs are supported. In subsequent patches we will have
devlink support to control which VF is used for VDPA and which function
is used for regular networking.

Reviewed-by: Parav Pandit
Signed-off-by: Eli Cohen
---
Changes from V0:
1. Fix include path usage
2. Fix use after free in qp_create()
3. Consistently use mvq->initialized to check if a vq was initialized.
4. Remove unused local variable.
5. Defer modifyig vq to ready to driver ok
6. suspend hardware vq in set_vq_ready(0)
7. Remove reservation for control VQ since it multi queue is not supported in 
this version
8. Avoid call put_device() since this is not a pci device driver.



Looks good to me.

Acked-by: Jason Wang 

[PATCH] xtensa: add boot-elf targets to extra-y

[Max Filippov]

The commit 8fe87a92f262 ("kbuild: always create directories of targets")
exposed an issue in the xtensa makefiles that results in the following
build error in a clean directory:
  scripts/Makefile.build:374: arch/xtensa/boot/boot-elf/boot.lds] Error 1
arch/xtensa/boot/boot-elf/bootstrap.S:21: fatal error:
opening dependency file arch/xtensa/boot/boot-elf/.bootstrap.o.d:
No such file or directory

Intermediate targets in arch/xtensa/boot/boot-elf don't get into
'targets' and build directory is not created for them.
Add boot.lds and bootstrap.o to extra-y.

Cc: Masahiro Yamada 
Signed-off-by: Max Filippov 
---
 arch/xtensa/boot/boot-elf/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/boot/boot-elf/Makefile 
b/arch/xtensa/boot/boot-elf/Makefile
index a62a25506536..eb952d809d81 100644
--- a/arch/xtensa/boot/boot-elf/Makefile
+++ b/arch/xtensa/boot/boot-elf/Makefile
@@ -15,6 +15,7 @@ export CPPFLAGS_boot.lds += -P -C
 export KBUILD_AFLAGS += -mtext-section-literals
 
 boot-y := bootstrap.o
+extra-y:= boot.lds $(boot-y)
 
 OBJS   := $(addprefix $(obj)/,$(boot-y))
 
-- 
2.20.1

Re: [PATCH 11/14] mm: use SWP_SYNCHRONOUS_IO more intelligently

[Minchan Kim]

Thanks for Ccing me, Shakeel.

On Mon, Jul 20, 2020 at 10:52:55AM -0700, Shakeel Butt wrote:
> +Minchan Kim
> 
> On Mon, Jul 20, 2020 at 12:52 AM Christoph Hellwig  wrote:
> >
> > There is no point in trying to call bdev_read_page if SWP_SYNCHRONOUS_IO
> > is not set, as the device won't support it.  Also there is no point in
> > trying a bio submission if bdev_read_page failed.
> 
> This will at least break the failure path of zram_rw_page().

Yes, it needs post processing for error propagaion like *page* handling
part in end_swap_bio_read(mostly, PG_error and PG_uptodate with pr_alert).
bdev_read_page's sematic doesn't need to be synchronous so it could just
submit the IO request and complete the IO afterward. In that case, we
need right error handling, too if the IO encoutered error. BIO fallback
makes it simple.

 * bdev_read_page() - Start reading a page from a block device
 * @bdev: The device to read the page from
 * @sector: The offset on the device to read the page to (need not be aligned)
 * @page: The page to read
 *
 * On entry, the page should be locked.  It will be unlocked when the page
 * has been read.  If the block driver implements rw_page synchronously,
 * that will be true on exit from this function, but it need not be.
 *
 * Errors returned by this function are usually "soft", eg out of memory, or
 * queue full; callers should try a different route to read this page rather
 * than propagate an error back up the stack.

The other concern about this patch is zram have used rw_page for a long
time even though sometime it doesn't declare BDI_CAP_SYNCHRONOUS_IO by itself
because rw_page shows 4~5% bandwidth improvement compared to bio-based.
The performance gain becomes more important these day because compressor
becomes more fast day by day.

> 
> >
> > Signed-off-by: Christoph Hellwig 
> > ---
> >  mm/page_io.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/page_io.c b/mm/page_io.c
> > index ccda7679008851..63b44b8221af0f 100644
> > --- a/mm/page_io.c
> > +++ b/mm/page_io.c
> > @@ -403,8 +403,11 @@ int swap_readpage(struct page *page, bool synchronous)
> > goto out;
> > }
> >
> > -   ret = bdev_read_page(sis->bdev, swap_page_sector(page), page);
> > -   if (!ret) {
> > +   if (sis->flags & SWP_SYNCHRONOUS_IO) {
> > +   ret = bdev_read_page(sis->bdev, swap_page_sector(page), 
> > page);
> > +   if (ret)
> > +   goto out;
> > +
> > if (trylock_page(page)) {
> > swap_slot_free_notify(page);
> > unlock_page(page);
> > --
> > 2.27.0
> >

Re: [PATCH 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

[Paul Mackerras]

On Wed, Jul 08, 2020 at 02:16:36PM +0200, Laurent Dufour wrote:
> Le 08/07/2020 à 13:25, Bharata B Rao a écrit :
> > On Fri, Jul 03, 2020 at 05:59:14PM +0200, Laurent Dufour wrote:
> > > When a secure memslot is dropped, all the pages backed in the secure 
> > > device
> > > (aka really backed by secure memory by the Ultravisor) should be paged out
> > > to a normal page. Previously, this was achieved by triggering the page
> > > fault mechanism which is calling kvmppc_svm_page_out() on each pages.
> > > 
> > > This can't work when hot unplugging a memory slot because the memory slot
> > > is flagged as invalid and gfn_to_pfn() is then not trying to access the
> > > page, so the page fault mechanism is not triggered.
> > > 
> > > Since the final goal is to make a call to kvmppc_svm_page_out() it seems
> > > simpler to directly calling it instead of triggering such a mechanism. 
> > > This
> > > way kvmppc_uvmem_drop_pages() can be called even when hot unplugging a
> > > memslot.
> > 
> > Yes, this appears much simpler.
> 
> Thanks Bharata for reviewing this.
> 
> > 
> > > 
> > > Since kvmppc_uvmem_drop_pages() is already holding kvm->arch.uvmem_lock,
> > > the call to __kvmppc_svm_page_out() is made.
> > > As __kvmppc_svm_page_out needs the vma pointer to migrate the pages, the
> > > VMA is fetched in a lazy way, to not trigger find_vma() all the time. In
> > > addition, the mmap_sem is help in read mode during that time, not in write
> > > mode since the virual memory layout is not impacted, and
> > > kvm->arch.uvmem_lock prevents concurrent operation on the secure device.
> > > 
> > > Cc: Ram Pai 
> > > Cc: Bharata B Rao 
> > > Cc: Paul Mackerras 
> > > Signed-off-by: Laurent Dufour 
> > > ---
> > >   arch/powerpc/kvm/book3s_hv_uvmem.c | 54 --
> > >   1 file changed, 37 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c 
> > > b/arch/powerpc/kvm/book3s_hv_uvmem.c
> > > index 852cc9ae6a0b..479ddf16d18c 100644
> > > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c
> > > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
> > > @@ -533,35 +533,55 @@ static inline int kvmppc_svm_page_out(struct 
> > > vm_area_struct *vma,
> > >* fault on them, do fault time migration to replace the device PTEs in
> > >* QEMU page table with normal PTEs from newly allocated pages.
> > >*/
> > > -void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
> > > +void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *slot,
> > >struct kvm *kvm, bool skip_page_out)
> > >   {
> > >   int i;
> > >   struct kvmppc_uvmem_page_pvt *pvt;
> > > - unsigned long pfn, uvmem_pfn;
> > > - unsigned long gfn = free->base_gfn;
> > > + struct page *uvmem_page;
> > > + struct vm_area_struct *vma = NULL;
> > > + unsigned long uvmem_pfn, gfn;
> > > + unsigned long addr, end;
> > > +
> > > + down_read(>mm->mmap_sem);
> > 
> > You should be using mmap_read_lock(kvm->mm) with recent kernels.
> 
> Absolutely, shame on me, I reviewed Michel's series about that!
> 
> Paul, Michael, could you fix that when pulling this patch or should I sent a
> whole new series?

Given that Ram has reworked his series, I think it would be best if
you rebase on top of his new series and re-send your series.

Thanks,
Paul.

[RFC PATCH] platform: ioremap: Build iomap functions even without HAS_IOMEM

[David Gow]

A number of drivers use devm_platform_ioremap_resource(), but do not (or
did not) explicitly depend on IOMEM[1,2]. Given that the only platform
without HAS_IOMEM seems to be UML, and it has sufficient stubs for
devm_platform_ioremap_resource() and its dependencies to build, we can
remove the HAS_IOMEM requirement here, rather than playing whack-a-mole
with different drivers which don't try to build against ARCH=um.

The reason this works at the moment is that stub ioremap and iounmap
functions were added to UML to support this sort-of thing[3]. This
particular change doesn't require adding any additional stubs, but there
is possibly room in the future to stub out the remaining iomem functions
(or to provide mock implementations for testing), and get rid of
HAS_IOMEM entirely.

[1]: https://lkml.org/lkml/2020/6/30/176
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e7468bd9d30a21e059af477106dc5588ae52dff
[3]:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1405627.html

Signed-off-by: David Gow 
---
 drivers/base/platform.c | 2 --
 lib/Makefile| 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0d0a5490ac6..628dde6675cf 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -61,7 +61,6 @@ struct resource *platform_get_resource(struct platform_device 
*dev,
 }
 EXPORT_SYMBOL_GPL(platform_get_resource);
 
-#ifdef CONFIG_HAS_IOMEM
 /**
  * devm_platform_get_and_ioremap_resource - call devm_ioremap_resource() for a
  * platform device and get resource
@@ -135,7 +134,6 @@ devm_platform_ioremap_resource_byname(struct 
platform_device *pdev,
return devm_ioremap_resource(>dev, res);
 }
 EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname);
-#endif /* CONFIG_HAS_IOMEM */
 
 /**
  * platform_get_irq_optional - get an optional IRQ for a device
diff --git a/lib/Makefile b/lib/Makefile
index b1c42c10073b..35c21af33b93 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -115,7 +115,7 @@ obj-y += math/ crypto/
 
 obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
 obj-$(CONFIG_GENERIC_PCI_IOMAP) += pci_iomap.o
-obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o
+obj-y += iomap_copy.o devres.o
 obj-$(CONFIG_CHECK_SIGNATURE) += check_signature.o
 obj-$(CONFIG_DEBUG_LOCKING_API_SELFTESTS) += locking-selftest.o
 
-- 
2.28.0.rc0.105.gf9edc3c819-goog

[PATCH 0/2] Remove MT6779 UART3 clock support

[Hanks Chen]

remove the redundant clk interface of uart.
CLK_INFRA_UART3 is a dummy clk interface,
it has no effect on the operation of the read/write instruction.

Hanks Chen (2):
  dt-bindings: clock: remove UART3 clock support
  clk: mediatek: remove UART3 clock support

 drivers/clk/mediatek/clk-mt6779.c  | 2 --
 include/dt-bindings/clock/mt6779-clk.h | 1 -
 2 files changed, 3 deletions(-)

-- 
2.18.0

[PATCH 1/2] dt-bindings: clock: remove UART3 clock support

[Hanks Chen]

remove the redundant clk interface of uart.

Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support")
Signed-off-by: Hanks Chen 
---
 include/dt-bindings/clock/mt6779-clk.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/dt-bindings/clock/mt6779-clk.h 
b/include/dt-bindings/clock/mt6779-clk.h
index b083139afbd2..2b5f2354d7eb 100644
--- a/include/dt-bindings/clock/mt6779-clk.h
+++ b/include/dt-bindings/clock/mt6779-clk.h
@@ -229,7 +229,6 @@
 #define CLK_INFRA_UART021
 #define CLK_INFRA_UART122
 #define CLK_INFRA_UART223
-#define CLK_INFRA_UART324
 #define CLK_INFRA_GCE_26M  25
 #define CLK_INFRA_CQ_DMA_FPC   26
 #define CLK_INFRA_BTIF 27
-- 
2.18.0

[PATCH 2/2] clk: mediatek: remove UART3 clock support

[Hanks Chen]

CLK_INFRA_UART3 is a dummy clk interface,
it has no effect on the operation of the read/write instruction.

Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support")
Signed-off-by: Hanks Chen 
---
 drivers/clk/mediatek/clk-mt6779.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt6779.c 
b/drivers/clk/mediatek/clk-mt6779.c
index 9766cccf5844..75f2235486be 100644
--- a/drivers/clk/mediatek/clk-mt6779.c
+++ b/drivers/clk/mediatek/clk-mt6779.c
@@ -923,8 +923,6 @@ static const struct mtk_gate infra_clks[] = {
"uart_sel", 23),
GATE_INFRA0(CLK_INFRA_UART2, "infra_uart2",
"uart_sel", 24),
-   GATE_INFRA0(CLK_INFRA_UART3, "infra_uart3",
-   "uart_sel", 25),
GATE_INFRA0(CLK_INFRA_GCE_26M, "infra_gce_26m",
"axi_sel", 27),
GATE_INFRA0(CLK_INFRA_CQ_DMA_FPC, "infra_cqdma_fpc",
-- 
2.18.0

Re: [PATCH] i2c: i2c-qcom-geni: Fix DMA transfer race

[Sai Prakash Ranjan]

On 2020-07-21 05:54, Douglas Anderson wrote:

When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang.  The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver.  It appears that KASAN adds
enough delay in my system to tickle a race condition in the DMA setup
code.

When the system hangs, I found that it was running the geni_i2c_irq()
over and over again.  It had these:

m_stat   = 0x0480
rx_st= 0x3011
dm_tx_st = 0x
dm_rx_st = 0x
dma  = 0x0001

Notably we're in DMA mode but are getting M_RX_IRQ_EN and
M_RX_FIFO_WATERMARK_EN over and over again.

Putting some traces in geni_i2c_rx_one_msg() showed that when we
failed we were getting to the start of geni_i2c_rx_one_msg() but were
never executing geni_se_rx_dma_prep().

I believe that the problem here is that we are writing the transfer
length and setting up the geni command before we run
geni_se_rx_dma_prep().  If a transfer makes it far enough before we do
that then we get into the state I have observed.  Let's change the
order, which seems to work fine.

Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the
Qualcomm GENI I2C controller")
Signed-off-by: Douglas Anderson 
---

 drivers/i2c/busses/i2c-qcom-geni.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 18d1e4fd4cf3..21e27f10510a 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -366,15 +366,15 @@ static int geni_i2c_rx_one_msg(struct
geni_i2c_dev *gi2c, struct i2c_msg *msg,
else
geni_se_select_mode(se, GENI_SE_FIFO);

-   writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
-   geni_se_setup_m_cmd(se, I2C_READ, m_param);
-
if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, _dma)) {
geni_se_select_mode(se, GENI_SE_FIFO);
i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
dma_buf = NULL;
}

+   writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
+   geni_se_setup_m_cmd(se, I2C_READ, m_param);
+
time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
if (!time_left)
geni_i2c_abort_xfer(gi2c);


Tested-by: Sai Prakash Ranjan 

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Christoph Hellwig]

On Mon, Jul 20, 2020 at 10:30:30PM -0700, Guenter Roeck wrote:
> Guess I lost it somewhere. Are you saying the check was wrong all along
> and your patch fixed it ?

Oh, it is a little complicated.

Normally we have two address space limits, KERNEL_DS and USER_DS,
and they are supposed to be different.  armnommu and m68k define them
to the same value for no good reason.  That leads to:

uaccess_kernel always returning true as it does a positive check
agains KERNEL_DS, which disables a bunch of drivers like sg and
rdma, and could also lead to really strange and probably broken
results in a few places.

It also leads to the SIGKILL in addr_limit_user_check never
triggering due to the negatіve check, which is ok as the limits
never are different.

Re: [PATCH v4 01/24] Documentation: locking: Describe seqlock design and usage

[Ahmed S. Darwish]

On Mon, Jul 20, 2020 at 09:35:51PM -0400, Steven Rostedt wrote:
> On Mon, 20 Jul 2020 17:55:07 +0200
> "Ahmed S. Darwish"  wrote:
> > +Read path, three categories:
> > +
> > +1. Normal Sequence readers which never block a writer but they must
> > +   retry if a writer is in progress by detecting change in the sequence
> > +   number.  Writers do not wait for a sequence reader::
> > +
> > +   do {
> > +   seq = read_seqbegin(_seqlock);
> > +
> > +   /* ... [[read-side critical section]] ... */
> > +
> > +   } while (read_seqretry(_seqlock, seq));
> > +
> > +2. Locking readers which will wait if a writer or another locking reader
> > +   is in progress. A locking reader in progress will also block a writer
> > +   from entering its critical section. This read lock is
> > +   exclusive. Unlike rwlock_t, only one locking reader can acquire it::
>
> Nit, but I would mention that this acts similar to a normal spin_lock,
> and even disables preeption (in the non-RT case).

will do.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

Re: [PATCH V2 vhost next 06/10] vdpa: Modify get_vq_state() to return error code

[Jason Wang]

On 2020/7/20 下午3:14, Eli Cohen wrote:

Modify get_vq_state() so it returns an error code. In case of hardware
acceleration, the available index may be retrieved from the device, an
operation that can possibly fail.

Reviewed-by: Parav Pandit 
Signed-off-by: Eli Cohen 



Acked-by: Jason Wang 



---
  drivers/vdpa/ifcvf/ifcvf_main.c  | 5 +++--
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 5 +++--
  drivers/vhost/vdpa.c | 5 -
  include/linux/vdpa.h | 4 ++--
  4 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 69032ee97824..d9b5f465ac81 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -235,12 +235,13 @@ static u16 ifcvf_vdpa_get_vq_num_max(struct vdpa_device 
*vdpa_dev)
return IFCVF_QUEUE_MAX;
  }
  
-static void ifcvf_vdpa_get_vq_state(struct vdpa_device *vdpa_dev, u16 qid,

-   struct vdpa_vq_state *state)
+static int ifcvf_vdpa_get_vq_state(struct vdpa_device *vdpa_dev, u16 qid,
+  struct vdpa_vq_state *state)
  {
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
  
  	state->avail_index = ifcvf_get_vq_state(vf, qid);

+   return 0;
  }
  
  static int ifcvf_vdpa_set_vq_state(struct vdpa_device *vdpa_dev, u16 qid,

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 599519039f8d..ddf6086d43c2 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -427,14 +427,15 @@ static int vdpasim_set_vq_state(struct vdpa_device *vdpa, 
u16 idx,
return 0;
  }
  
-static void vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx,

-struct vdpa_vq_state *state)
+static int vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx,
+   struct vdpa_vq_state *state)
  {
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
struct vdpasim_virtqueue *vq = >vqs[idx];
struct vringh *vrh = >vring;
  
  	state->avail_index = vrh->last_avail_idx;

+   return 0;
  }
  
  static u32 vdpasim_get_vq_align(struct vdpa_device *vdpa)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index af98c11c9d26..fadad74f882e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -360,7 +360,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
}
  
  	if (cmd == VHOST_GET_VRING_BASE) {

-   ops->get_vq_state(v->vdpa, idx, _state);
+   r = ops->get_vq_state(v->vdpa, idx, _state);
+   if (r)
+   return r;
+
vq->last_avail_idx = vq_state.avail_index;
}
  
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h

index 7b088bebffe8..000d71a9f988 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -185,8 +185,8 @@ struct vdpa_config_ops {
bool (*get_vq_ready)(struct vdpa_device *vdev, u16 idx);
int (*set_vq_state)(struct vdpa_device *vdev, u16 idx,
const struct vdpa_vq_state *state);
-   void (*get_vq_state)(struct vdpa_device *vdev, u16 idx,
-struct vdpa_vq_state *state);
+   int (*get_vq_state)(struct vdpa_device *vdev, u16 idx,
+   struct vdpa_vq_state *state);
struct vdpa_notification_area
(*get_vq_notification)(struct vdpa_device *vdev, u16 idx);
  

Re: [PATCH V2 vhost next 05/10] vhost: Fix documentation

[Jason Wang]

On 2020/7/20 下午3:14, Eli Cohen wrote:

Fix documentation to match actual function prototypes.

Reviewed-by: Parav Pandit 
Signed-off-by: Eli Cohen 



Acked-by: Jason Wang 



---
  drivers/vhost/iotlb.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 1f0ca6e44410..0d4213a54a88 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -149,7 +149,7 @@ EXPORT_SYMBOL_GPL(vhost_iotlb_free);
   * vhost_iotlb_itree_first - return the first overlapped range
   * @iotlb: the IOTLB
   * @start: start of IOVA range
- * @end: end of IOVA range
+ * @last: last byte in IOVA range
   */
  struct vhost_iotlb_map *
  vhost_iotlb_itree_first(struct vhost_iotlb *iotlb, u64 start, u64 last)
@@ -162,7 +162,7 @@ EXPORT_SYMBOL_GPL(vhost_iotlb_itree_first);
   * vhost_iotlb_itree_first - return the next overlapped range
   * @iotlb: the IOTLB
   * @start: start of IOVA range
- * @end: end of IOVA range
+ * @last: last byte IOVA range
   */
  struct vhost_iotlb_map *
  vhost_iotlb_itree_next(struct vhost_iotlb_map *map, u64 start, u64 last)

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Sidong Yang]

On Wed, Jul 15, 2020 at 06:08:44PM +0200, Daniel Vetter wrote:
> On Wed, Jul 15, 2020 at 5:57 PM Melissa Wen  wrote:
> >
> > On 07/15, Sidong Yang wrote:
> > > On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > > > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen  
> > > > wrote:
> > > > >
> > > > > On 07/14, Daniel Vetter wrote:
> > > > > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > > > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On 07/13, Daniel Vetter wrote:
> > > > > > > > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > > > > > > > On 07/02, Daniel Vetter wrote:
> > > > > > > > > > > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > there is an error when igt test is run continuously. 
> > > > > > > > > > > > vkms_atomic_commit_tail()
> > > > > > > > > > > > need to call drm_atomic_helper_wait_for_vblanks() for 
> > > > > > > > > > > > give up ownership of
> > > > > > > > > > > > vblank events. without this code, next atomic commit 
> > > > > > > > > > > > will not enable vblank
> > > > > > > > > > > > and raise timeout error.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Sidong Yang 
> > > > > > > > > > > > ---
> > > > > > > > > > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> > > > > > > > > > > >  1 file changed, 2 insertions(+)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > > > > > > > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > > > index 1e8b2169d834..10b9be67a068 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > > > @@ -93,6 +93,8 @@ static void 
> > > > > > > > > > > > vkms_atomic_commit_tail(struct drm_atomic_state 
> > > > > > > > > > > > *old_state)
> > > > > > > > > > > > flush_work(_state->composer_work);
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > +   drm_atomic_helper_wait_for_vblanks(dev, 
> > > > > > > > > > > > old_state);
> > > > > > > > > > >
> > > > > > > > > > > Uh, we have a wait_for_flip_done right above, which 
> > > > > > > > > > > should be doing
> > > > > > > > > > > exactly the same, but more precisely: Instead of just 
> > > > > > > > > > > waiting for any
> > > > > > > > > > > vblank to happen, we wait for exactly the vblank 
> > > > > > > > > > > corresponding to this
> > > > > > > > > > > atomic commit. So no races possible. If this is papering 
> > > > > > > > > > > over some issue,
> > > > > > > > > > > then I think more debugging is needed.
> > > > > > > > > > >
> > > > > > > > > > > What exactly is going wrong here for you?
> > > > > > > > > >
> > > > > > > > > > Hi Daniel and Sidong,
> > > > > > > > > >
> > > > > > > > > > I noticed a similar issue when running the IGT test 
> > > > > > > > > > kms_cursor_crc. For
> > > > > > > > > > example, a subtest that passes on the first run 
> > > > > > > > > > (alpha-opaque) fails on
> > > > > > > > > > the second due to a kind of busy waiting in subtest 
> > > > > > > > > > preparation (the
> > > > > > > > > > subtest fails before actually running).
> > > > > > > > > >
> > > > > > > > > > In addition, in the same test, the dpms subtest started to 
> > > > > > > > > > fail since
> > > > > > > > > > the commit that change from wait_for_vblanks to 
> > > > > > > > > > wait_for_flip_done. By
> > > > > > > > > > reverting this commit, the dpms subtest passes again and 
> > > > > > > > > > the sequential
> > > > > > > > > > subtests return to normal.
> > > > > > > > > >
> > > > > > > > > > I am trying to figure out what's missing from using 
> > > > > > > > > > flip_done op on
> > > > > > > > > > vkms, since I am also interested in solving this problem 
> > > > > > > > > > and I
> > > > > > > > > > understand that the change for flip_done has been discussed 
> > > > > > > > > > in the past.
> > > > > > > > > >
> > > > > > > > > > Do you have any idea?
> > > > > > > > >
> > > > > > > > > Uh, not at all. This is indeed rather surprising ...
> > > > > > > > >
> > > > > > > > > What exactly is the failure mode when running a test the 2nd 
> > > > > > > > > time? Full
> > > > > > > > > igt logs might give me an idea. But yeah this is kinda 
> > > > > > > > > surprising.
> > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > >
> > > > > > > > This is the IGT log of the 2nd run of 
> > > > > > > > kms_cursor_crc/alpha-opaque:
> > > > > > > >
> > > > > > > > IGT-Version: 1.25-NO-GIT (x86_64) (Linux: 5.8.0-rc2-DRM+ x86_64)
> > > > > > > > Force option used: Using driver vkms
> > > > > > > > Starting subtest: pipe-A-cursor-alpha-opaque
> > > > > > > > Timed out: Opening crc fd, and poll for first CRC.
> > > > > > > > Subtest pipe-A-cursor-alpha-opaque failed.
> > > > > > > >  DEBUG 
> > > > > > > > 

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Guenter Roeck]

On 7/20/20 10:20 PM, Christoph Hellwig wrote:
> On Mon, Jul 20, 2020 at 10:15:37PM -0700, Guenter Roeck wrote:
 -   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
 +   if (CHECK_DATA_CORRUPTION(!uaccess_kernel(),

 How does this work anywhere ?
>>>
>>> No, that is the wrong check - we want to make sure the address
>>> space override doesn't leak to userspace.  The problem is that
>>> armnommu (and m68knommu, but that doesn't call the offending
>>> function) pretends to not have a kernel address space, which doesn't
>>> really work.  Here is the fix I sent out yesterday, which I should
>>> have Cc'ed you on, sorry:
>>>
>>
>> The patch below makes sense, and it does work, but I still suspect
>> that something with your original patch is wrong, or at least suspicious.
>> Reason: My change above (Adding the "!") works for _all_ of my arm boot
>> tests. Or, in other words, it doesn't make a difference if true
>> or false is passed as first parameter of CHECK_DATA_CORRUPTION(), except
>> for nommu systems. Also, unless I am really missing something, your
>> original patch _does_ reverse the logic.
> 
> Well.  segment_eq is in current mainline used in two places:
> 
>  1) to implement uaccess_kernel
>  2) in addr_limit_user_check to implement uaccess_kernel-like
> semantics using a strange reverse notation
> 
> I think the explanation for your observation is how addr_limit_user_check
> is called on arm.  The addr_limit_check_failed wrapper for it is called
> from assembly code, but only after already checking the addr_limit,
> basically duplicating the segment_eq check.  So for mmu builds it won't
> get called unless we leak the kernel address space override, which
> is a pretty fatal error and won't show up in your boot tests.  The
> only good way to test it is by explicit injecting it using the
> lkdtm module.
> 

Guess I lost it somewhere. Are you saying the check was wrong all along
and your patch fixed it ?

Thanks,
Guenter

Re: [PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

[kernel test robot]

Hi Ashok,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on pci/next]
[also build test ERROR on iommu/next linux/master linus/master v5.8-rc6 
next-20200720]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Ashok-Raj/PCI-ATS-PASID-and-PRI-are-only-enumerated-in-PF-devices/20200721-004510
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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

All error/warnings (new ones prefixed by >>):

>> drivers/pci/ats.c:471:6: warning: no previous prototype for 
>> 'pci_pri_supported' [-Wmissing-prototypes]
 471 | bool pci_pri_supported(struct pci_dev *pdev)
 |  ^
   drivers/pci/ats.c: In function 'pci_pri_supported':
>> drivers/pci/ats.c:474:30: error: 'struct pci_dev' has no member named 
>> 'pri_cap'; did you mean 'pcie_cap'?
 474 |  return !!(pci_physfn(pdev)->pri_cap);
 |  ^~~
 |  pcie_cap
>> drivers/pci/ats.c:475:1: warning: control reaches end of non-void function 
>> [-Wreturn-type]
 475 | }
 | ^

vim +474 drivers/pci/ats.c

   463  
   464  /**
   465   * pci_pri_supported - Check if PRI is supported.
   466   * @pdev: PCI device structure
   467   *
   468   * Returns false when no PRI capability is present.
   469   * Returns true if PRI feature is supported and enabled
   470   */
 > 471  bool pci_pri_supported(struct pci_dev *pdev)
   472  {
   473  /* VFs share the PF PRI configuration */
 > 474  return !!(pci_physfn(pdev)->pri_cap);
 > 475  }
   476  EXPORT_SYMBOL_GPL(pci_pri_supported);
   477  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 02/24] bpfilter: fix up a sparse annotation

[Al Viro]

On Tue, Jul 21, 2020 at 07:23:26AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 04:40:16AM +0200, Luc Van Oostenryck wrote:
> > >   req.pid = current->pid;
> > >   req.cmd = optname;
> > > - req.addr = (long __force __user)optval;
> > > + req.addr = (__force long)optval;
> > 
> > For casts to integers, even '__force' is not needed (since integers
> > can't be dereferenced, the concept of address-space is meaningless
> > for them, so it's never useful to warn when it's dropped and
> > '__force' is thus not needed).
> 
> That's what I thought. but if I remove it here I actually do get a
> warning:
> 
> CHECK   net/bpfilter/bpfilter_kern.c
> net/bpfilter/bpfilter_kern.c:52:21: warning: cast removes address space 
> '__user' of expression

Cast to unsigned long.  Or to uintptr_t if you want to be fancy.

Re: [GIT PULL] EFI fixes for v5.8-rc

[Ard Biesheuvel]

On Sat, 18 Jul 2020 at 08:54, Ard Biesheuvel  wrote:
>
> On Thu, 9 Jul 2020 at 16:28, Ard Biesheuvel  wrote:
> >
> > The following changes since commit 2a55280a3675203496d302463b941834228b9875:
> >
> >   efi/libstub: arm: Print CPU boot mode and MMU state at boot (2020-06-17 
> > 15:29:11 +0200)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git 
> > tags/efi-urgent-for-v5.8-rc4
> >
> > for you to fetch changes up to 769e0fe1171e95d90ea5a2d6d0b2bdc7d5d2e7b2:
> >
> >   efi: Revert "efi/x86: Fix build with gcc 4" (2020-07-09 10:14:29 +0300)
> >
> > 
> > EFI fixes for v5.8-rc4:
> > - Fix the layering violation in the use of the EFI runtime services
> >   availability mask in users of the 'efivars' abstraction
> > - Revert build fix for GCC v4.8 which is no longer supported
> > - Some fixes for build issues found by Atish while working on RISC-V support
> > - Avoid --whole-archive when linking the stub on arm64
> > - Some x86 EFI stub cleanups from Arvind
> >
> > 
> > Ard Biesheuvel (2):
> >   efi/efivars: Expose RT service availability via efivars abstraction
> >   efi: Revert "efi/x86: Fix build with gcc 4"
> >
> > Arvind Sankar (2):
> >   efi/x86: Remove unused variables
> >   efi/x86: Only copy upto the end of setup_header
> >
> > Atish Patra (2):
> >   efi/libstub: Fix gcc error around __umoddi3 for 32 bit builds
> >   efi/libstub: Move the function prototypes to header file
> >
> > Masahiro Yamada (1):
> >   efi/libstub/arm64: link stub lib.a conditionally
> >
> >  arch/arm64/Makefile   |  2 +-
> >  drivers/firmware/efi/efi-pstore.c |  5 +
> >  drivers/firmware/efi/efi.c| 12 
> >  drivers/firmware/efi/efivars.c|  5 +
> >  drivers/firmware/efi/libstub/Makefile |  3 +--
> >  drivers/firmware/efi/libstub/alignedmem.c |  2 +-
> >  drivers/firmware/efi/libstub/efi-stub.c   | 17 -
> >  drivers/firmware/efi/libstub/efistub.h| 16 
> >  drivers/firmware/efi/libstub/x86-stub.c   |  8 
> >  drivers/firmware/efi/vars.c   |  6 ++
> >  fs/efivarfs/super.c   |  6 +++---
> >  include/linux/efi.h   |  1 +
> >  12 files changed, 43 insertions(+), 40 deletions(-)
>
> Ping?

Ping again?

Re: [PATCH 02/24] bpfilter: fix up a sparse annotation

[Christoph Hellwig]

On Tue, Jul 21, 2020 at 04:40:16AM +0200, Luc Van Oostenryck wrote:
> > req.pid = current->pid;
> > req.cmd = optname;
> > -   req.addr = (long __force __user)optval;
> > +   req.addr = (__force long)optval;
> 
> For casts to integers, even '__force' is not needed (since integers
> can't be dereferenced, the concept of address-space is meaningless
> for them, so it's never useful to warn when it's dropped and
> '__force' is thus not needed).

That's what I thought. but if I remove it here I actually do get a
warning:

CHECK   net/bpfilter/bpfilter_kern.c
net/bpfilter/bpfilter_kern.c:52:21: warning: cast removes address space 
'__user' of expression

Using this recent sparse build:

hch@brick:~/work/linux$ sparse --version
v0.6.2-49-g707c5017

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Christoph Hellwig]

On Mon, Jul 20, 2020 at 10:15:37PM -0700, Guenter Roeck wrote:
> >> -   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
> >> +   if (CHECK_DATA_CORRUPTION(!uaccess_kernel(),
> >>
> >> How does this work anywhere ?
> > 
> > No, that is the wrong check - we want to make sure the address
> > space override doesn't leak to userspace.  The problem is that
> > armnommu (and m68knommu, but that doesn't call the offending
> > function) pretends to not have a kernel address space, which doesn't
> > really work.  Here is the fix I sent out yesterday, which I should
> > have Cc'ed you on, sorry:
> > 
> 
> The patch below makes sense, and it does work, but I still suspect
> that something with your original patch is wrong, or at least suspicious.
> Reason: My change above (Adding the "!") works for _all_ of my arm boot
> tests. Or, in other words, it doesn't make a difference if true
> or false is passed as first parameter of CHECK_DATA_CORRUPTION(), except
> for nommu systems. Also, unless I am really missing something, your
> original patch _does_ reverse the logic.

Well.  segment_eq is in current mainline used in two places:

 1) to implement uaccess_kernel
 2) in addr_limit_user_check to implement uaccess_kernel-like
semantics using a strange reverse notation

I think the explanation for your observation is how addr_limit_user_check
is called on arm.  The addr_limit_check_failed wrapper for it is called
from assembly code, but only after already checking the addr_limit,
basically duplicating the segment_eq check.  So for mmu builds it won't
get called unless we leak the kernel address space override, which
is a pretty fatal error and won't show up in your boot tests.  The
only good way to test it is by explicit injecting it using the
lkdtm module.

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Guenter Roeck]

On 7/20/20 9:58 PM, Christoph Hellwig wrote:
> On Mon, Jul 20, 2020 at 03:10:46PM -0700, Guenter Roeck wrote:
>> I had another look into the code. Right after this patch, I see
>>
>> #define uaccess_kernel() segment_eq(get_fs(), KERNEL_DS)
>>
>> Yet, this patch is:
>>
>> -   if (CHECK_DATA_CORRUPTION(!segment_eq(get_fs(), USER_DS),
>> +   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
>>
>> So there is a negation in the condition. Indeed, the following change
>> on top of next-20200720 fixes the problem for mps2-an385.
>>
>> -   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
>> +   if (CHECK_DATA_CORRUPTION(!uaccess_kernel(),
>>
>> How does this work anywhere ?
> 
> No, that is the wrong check - we want to make sure the address
> space override doesn't leak to userspace.  The problem is that
> armnommu (and m68knommu, but that doesn't call the offending
> function) pretends to not have a kernel address space, which doesn't
> really work.  Here is the fix I sent out yesterday, which I should
> have Cc'ed you on, sorry:
> 

The patch below makes sense, and it does work, but I still suspect
that something with your original patch is wrong, or at least suspicious.
Reason: My change above (Adding the "!") works for _all_ of my arm boot
tests. Or, in other words, it doesn't make a difference if true
or false is passed as first parameter of CHECK_DATA_CORRUPTION(), except
for nommu systems. Also, unless I am really missing something, your
original patch _does_ reverse the logic.

I didn't track this down further.

Thanks,
Guenter

> ---
>>From 2bb889b2d99a2d978e90640ade8fe02359287092 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig 
> Date: Mon, 20 Jul 2020 17:46:50 +0200
> Subject: arm: don't call addr_limit_user_check for nommu
> 
> On arm nommu kernel use the same constant for USER_DS and KERNEL_DS,
> and seqment_eq always returns false.  With the current check in
> addr_limit_user_check that works by accident, but when replacing
> seqment_eq with uaccess_kerne it will fail.  Just remove the not
> needed check entirely.
> 
> Signed-off-by: Christoph Hellwig 
> Reported-by: Guenter Roeck 

Tested-by: Guenter Roeck 

> ---
>  arch/arm/kernel/signal.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
> index ab2568996ddb0c..c9dc912b83f012 100644
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@ -713,7 +713,9 @@ struct page *get_signal_page(void)
>  /* Defer to generic check */
>  asmlinkage void addr_limit_check_failed(void)
>  {
> +#ifdef CONFIG_MMU
>   addr_limit_user_check();
> +#endif
>  }
>  
>  #ifdef CONFIG_DEBUG_RSEQ
> 

Re: [PATCH 08/10] dma-mapping: consolidate the NO_DMA definition in kernel/dma/Kconfig

[Christoph Hellwig]

On Mon, Jul 20, 2020 at 11:17:26PM -0400, Rich Felker wrote:
> On Tue, Jul 14, 2020 at 02:18:54PM +0200, Christoph Hellwig wrote:
> > Have a single definition that architetures can select.
> > 
> > Signed-off-by: Christoph Hellwig 
> > ---
> >  arch/m68k/Kconfig | 4 +---
> >  arch/m68k/Kconfig.machine | 1 +
> >  arch/um/Kconfig   | 4 +---
> >  kernel/dma/Kconfig| 3 +++
> >  4 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> > index 6ad6cdac74b3dc..8e488369a7e55a 100644
> > --- a/arch/m68k/Kconfig
> > +++ b/arch/m68k/Kconfig
> > @@ -17,6 +17,7 @@ config M68K
> > select HAVE_COPY_THREAD_TLS
> > select GENERIC_IRQ_SHOW
> > select GENERIC_ATOMIC64
> > +   select NO_DMA if !MMU && !COLDFIRE
> > select HAVE_UID16
> > select VIRT_TO_BUS
> > select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
> > @@ -60,9 +61,6 @@ config TIME_LOW_RES
> >  config NO_IOPORT_MAP
> > def_bool y
> >  
> > -config NO_DMA
> > -   def_bool (MMU && SUN3) || (!MMU && !COLDFIRE)
> > -
> >  config ZONE_DMA
> > bool
> > default y
> > diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
> > index a82651d58af483..17e8c3a292d770 100644
> > --- a/arch/m68k/Kconfig.machine
> > +++ b/arch/m68k/Kconfig.machine
> > @@ -126,6 +126,7 @@ config SUN3
> > depends on MMU
> > depends on !MMU_MOTOROLA
> > select MMU_SUN3 if MMU
> > +   select NO_DMA
> > select M68020
> > help
> >   This option enables support for the Sun 3 series of workstations
> > diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> > index 9318dc6d1a0cee..32c1d1945033ec 100644
> > --- a/arch/um/Kconfig
> > +++ b/arch/um/Kconfig
> > @@ -15,6 +15,7 @@ config UML
> > select HAVE_DEBUG_KMEMLEAK
> > select HAVE_DEBUG_BUGVERBOSE
> > select HAVE_COPY_THREAD_TLS
> > +   select NO_DMA
> > select GENERIC_IRQ_SHOW
> > select GENERIC_CPU_DEVICES
> > select GENERIC_CLOCKEVENTS
> > @@ -168,9 +169,6 @@ config MMAPPER
> >   This driver allows a host file to be used as emulated IO memory inside
> >   UML.
> >  
> > -config NO_DMA
> > -   def_bool y
> > -
> >  config PGTABLE_LEVELS
> > int
> > default 3 if 3_LEVEL_PGTABLES
> > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> > index 1da3f44f2565b4..57533d07676f4a 100644
> > --- a/kernel/dma/Kconfig
> > +++ b/kernel/dma/Kconfig
> > @@ -1,5 +1,8 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  
> > +config NO_DMA
> > +   bool
> > +
> >  config HAS_DMA
> > bool
> > depends on !NO_DMA
> > -- 
> > 2.26.2
> 
> This patch is outside the scope of what I can accept in arch/sh, and
> the subsequent patches in the series seem to depend on it. What would
> you like to do for its path upstream?
> 
> I've now picked up everything else from this series that I can.

As the dma-mapping maintainer:  please pick it.  I'd give you an
ACK, but that looks kinda silly if I'm the author as well :)

Re: [PATCH 04/14] bdi: initialize ->ra_pages in bdi_init

[Christoph Hellwig]

On Mon, Jul 20, 2020 at 11:27:57PM +0200, Richard Weinberger wrote:
> On Mon, Jul 20, 2020 at 2:37 PM Artem Bityutskiy  wrote:
> >
> > On Mon, 2020-07-20 at 14:07 +0200, Christoph Hellwig wrote:
> > > What about jffs2 and blk2mtd raw block devices?
> 
> I don't worry much about blk2mtd.
> 
> > If my memory serves me correctly JFFS2 did not mind readahead.
> 
> This covers my knowledge too.
> I fear enabling readahead on JFFS2 will cause performance issues, this
> filesystem
> is mostly used on small and slow NOR devices.

I'm going to wait for Hans for feedback on vboxsf, but in doubt I'll
ust add a prep patch or fold for this one to explicit set ra_pages to 0
with a comment then.

Re: [PATCH v4 5/7] powerpc/iommu: Move iommu_table cleaning routine to iommu_table_clean

[Alexey Kardashevskiy]

On 16/07/2020 17:16, Leonardo Bras wrote:
> Move the part of iommu_table_free() that does struct iommu_table cleaning
> into iommu_table_clean, so we can invoke it separately.
> 
> This new function is useful for cleaning struct iommu_table before
> initializing it again with a new DMA window, without having it freed and
> allocated again.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  arch/powerpc/kernel/iommu.c | 30 ++
>  1 file changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 9704f3f76e63..c3242253a4e7 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -735,21 +735,10 @@ struct iommu_table *iommu_init_table(struct iommu_table 
> *tbl, int nid,
>   return tbl;
>  }
>  
> -static void iommu_table_free(struct kref *kref)
> +static void iommu_table_clean(struct iommu_table *tbl)


iommu_table_free() + iommu_init_table() + set_iommu_table_base() should
work too, why new helper?

There is also iommu_table_clear() which does a different thing so you
need a better name.

Second, iommu_table_free() would print a warning if any IOMMU page is in
use and it would be ok as we would only see this when hot-unplugging a
PE because we always kept the default window.

Btw you must be seeing these warnings now every time you create DDW with
these patches as at least the first page is reserved, do not you?

Since we are replacing a table for a device which is still in the
system, we should not try messing with its DMA if it already has
mappings so the warning should become an error preventing DDW. It is
rather hard to trigger in practice but I could hack a driver to ask for
32bit DMA mask first, map few pages and then ask for 64bit DMA mask, it
is not illegal, I think. So this needs a new helper - "bool
iommu_table_in_use(tbl)" - to use in enable_ddw(). Or I am overthinking
this?... Thanks,



>  {
>   unsigned long bitmap_sz;
>   unsigned int order;
> - struct iommu_table *tbl;
> -
> - tbl = container_of(kref, struct iommu_table, it_kref);
> -
> - if (tbl->it_ops->free)
> - tbl->it_ops->free(tbl);
> -
> - if (!tbl->it_map) {
> - kfree(tbl);
> - return;
> - }
>  
>   iommu_table_release_pages(tbl);
>  
> @@ -763,6 +752,23 @@ static void iommu_table_free(struct kref *kref)
>   /* free bitmap */
>   order = get_order(bitmap_sz);
>   free_pages((unsigned long) tbl->it_map, order);
> +}
> +
> +static void iommu_table_free(struct kref *kref)
> +{
> + struct iommu_table *tbl;
> +
> + tbl = container_of(kref, struct iommu_table, it_kref);
> +
> + if (tbl->it_ops->free)
> + tbl->it_ops->free(tbl);
> +
> + if (!tbl->it_map) {
> + kfree(tbl);
> + return;
> + }
> +
> + iommu_table_clean(tbl);
>  
>   /* free table */
>   kfree(tbl);
> 

-- 
Alexey

Re: [PATCH] unicore32: use get_kernel_nofault in dump mem and dump_instr

[christoph hellwig]

On Tue, Jul 21, 2020 at 10:09:20AM +0800, Guan Xuetao wrote:
> Very good to remove ds/fs in unicore arch.
> Could u send me full patch for test?

This is the full patch for now.  The actual removal will need
more core instrastructure and at least one more merge window.

[PATCH v6 net-next] net: hyperv: Add attributes to show TX indirection table

[Chi Song]

An imbalanced TX indirection table causes netvsc to have low
performance. This table is created and managed during runtime. To help
better diagnose performance issues caused by imbalanced tables, add
device attributes to show the content of TX indirection tables.

Signed-off-by: Chi Song 
---
v4: use a separated group to organize tx_indirection better, change 
 location of attributes init/exit to netvsc_drv_init/exit
v5: update variable orders
v6: update names to be more precise, remove useless assignment

Thank you all for comments, learned a lot.

 drivers/net/hyperv/netvsc_drv.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 6267f706e8ee..f6ad13ed320f 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2370,6 +2370,50 @@ static int netvsc_unregister_vf(struct net_device 
*vf_netdev)
return NOTIFY_OK;
 }
 
+static struct device_attribute 
dev_attr_tx_indirection_attrs[VRSS_SEND_TAB_SIZE];
+static struct attribute *tx_indirection_attrs[VRSS_SEND_TAB_SIZE + 1];
+
+const struct attribute_group tx_indirection_group = {
+   .name = "tx_indirection",
+   .attrs = tx_indirection_attrs,
+};
+
+static ssize_t tx_indirection_show(struct device *dev,
+  struct device_attribute *dev_attr, char *buf)
+{
+   int index = dev_attr - dev_attr_tx_indirection_attrs;
+   struct net_device *ndev = to_net_dev(dev);
+   struct net_device_context *ndc = netdev_priv(ndev);
+
+   return sprintf(buf, "%u\n", ndc->tx_table[index]);
+}
+
+static void netvsc_attrs_init(void)
+{
+   char buffer[4];
+   int i;
+
+   for (i = 0; i < VRSS_SEND_TAB_SIZE; i++) {
+   sprintf(buffer, "%02u", i);
+   dev_attr_tx_indirection_attrs[i].attr.name =
+   kstrdup(buffer, GFP_KERNEL);
+   dev_attr_tx_indirection_attrs[i].attr.mode = 0444;
+   sysfs_attr_init(_attr_tx_indirection_attrs[i].attr);
+
+   dev_attr_tx_indirection_attrs[i].show = tx_indirection_show;
+   tx_indirection_attrs[i] =
+   _attr_tx_indirection_attrs[i].attr;
+   }
+}
+
+static void netvsc_attrs_exit(void)
+{
+   int i;
+
+   for (i = 0; i < VRSS_SEND_TAB_SIZE; i++)
+   kfree(dev_attr_tx_indirection_attrs[i].attr.name);
+}
+
 static int netvsc_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
 {
@@ -2410,6 +2454,7 @@ static int netvsc_probe(struct hv_device *dev,
 
net->netdev_ops = _ops;
net->ethtool_ops = _ops;
+   net->sysfs_groups[0] = _indirection_group;
SET_NETDEV_DEV(net, >device);
 
/* We always need headroom for rndis header */
@@ -2665,6 +2710,7 @@ static void __exit netvsc_drv_exit(void)
 {
unregister_netdevice_notifier(_netdev_notifier);
vmbus_driver_unregister(_drv);
+   netvsc_attrs_exit();
 }
 
 static int __init netvsc_drv_init(void)
@@ -2678,6 +2724,8 @@ static int __init netvsc_drv_init(void)
}
netvsc_ring_bytes = ring_size * PAGE_SIZE;
 
+   netvsc_attrs_init();
+
ret = vmbus_driver_register(_drv);
if (ret)
return ret;
-- 
2.25.1

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Christoph Hellwig]

On Mon, Jul 20, 2020 at 03:10:46PM -0700, Guenter Roeck wrote:
> I had another look into the code. Right after this patch, I see
> 
> #define uaccess_kernel() segment_eq(get_fs(), KERNEL_DS)
> 
> Yet, this patch is:
> 
> -   if (CHECK_DATA_CORRUPTION(!segment_eq(get_fs(), USER_DS),
> +   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
> 
> So there is a negation in the condition. Indeed, the following change
> on top of next-20200720 fixes the problem for mps2-an385.
> 
> -   if (CHECK_DATA_CORRUPTION(uaccess_kernel(),
> +   if (CHECK_DATA_CORRUPTION(!uaccess_kernel(),
> 
> How does this work anywhere ?

No, that is the wrong check - we want to make sure the address
space override doesn't leak to userspace.  The problem is that
armnommu (and m68knommu, but that doesn't call the offending
function) pretends to not have a kernel address space, which doesn't
really work.  Here is the fix I sent out yesterday, which I should
have Cc'ed you on, sorry:

---
>From 2bb889b2d99a2d978e90640ade8fe02359287092 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Mon, 20 Jul 2020 17:46:50 +0200
Subject: arm: don't call addr_limit_user_check for nommu

On arm nommu kernel use the same constant for USER_DS and KERNEL_DS,
and seqment_eq always returns false.  With the current check in
addr_limit_user_check that works by accident, but when replacing
seqment_eq with uaccess_kerne it will fail.  Just remove the not
needed check entirely.

Signed-off-by: Christoph Hellwig 
Reported-by: Guenter Roeck 
---
 arch/arm/kernel/signal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index ab2568996ddb0c..c9dc912b83f012 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -713,7 +713,9 @@ struct page *get_signal_page(void)
 /* Defer to generic check */
 asmlinkage void addr_limit_check_failed(void)
 {
+#ifdef CONFIG_MMU
addr_limit_user_check();
+#endif
 }
 
 #ifdef CONFIG_DEBUG_RSEQ
-- 
2.27.0

Re: [PATCH 1/2] net: dsa: Add flag for 802.1AD when adding VLAN for dsa switch and port

[Florian Fainelli]

On 7/20/2020 3:41 AM, hongbo.w...@nxp.com wrote:
> From: "hongbo.wang" 
> 
> the following command can be supported:
> ip link add link swp1 name swp1.100 type vlan protocol 802.1ad id 100

You should probably include the switch driver that is going to be
benefiting from doing these changes in the patch series, provide a cover
letter when sending more than one patch, and also combine both the add
and delete parts.

Since you already have visibility into proto, it may not be necessary at
all for now to define a BRIDGE_VLAN_INFO_8021AD bit in order to pass
that flag down to DSA for programming the VLAN, just pass proto to
dsa_port_vid_add() or a boolean flag which indicates whether this is the
customer or service tag that you are trying to program?
-- 
Florian

Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917

[Paul Gortmaker]

[Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917] On 20/07/2020 (Mon 16:21) 
Peter Zijlstra wrote:

> On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
> > I have to admit, I do not understand the usage of prev_state in schedule(),
> > it looks really, really subtle...
> 
> Right, so commit dbfb089d360 solved a problem where schedule() re-read
> prev->state vs prev->on_rq = 0. That is, schedule()'s dequeue and
> ttwu()'s enqueue disagreed over sched_contributes_to_load. and as a
> result load-accounting went wobbly.
> 
> Now, looking at that commit again, I might've solved the problem twice
> :-P

[...]

> That said, in a crossed email, I just proposed we could simplify all
> this like so.. but now I need to go ask people to re-validate that
> loadavg muck again :-/

After a two hour "quick" sanity test I then gave it a full 7h run (which
always seemed to break before dbfb089d360) and I didn't see any stuck
load average with master from today + this change.

Paul.

root@t5610:/home/paul/git/linux-head#
[1]+  Donenohup 
tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 24 --duration 420 
--configs TREE03 --trust-make > /tmp/kvm.sh.out 2>&1
root@t5610:/home/paul/git/linux-head# cat /proc/version
Linux version 5.8.0-rc6-1-g5714ee50bb43-dirty (paul@t5610) (gcc (Ubuntu 
9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #3 SMP Mon Jul 
20 12:30:33 EDT 2020
root@t5610:/home/paul/git/linux-head# uptime
 00:49:18 up  7:41,  2 users,  load average: 0.01, 0.00, 0.63
root@t5610:/home/paul/git/linux-head# 

--

> 
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a2a244af9a53..437fc3b241f2 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(bool preempt)
>   local_irq_disable();
>   rcu_note_context_switch(preempt);
>  
> - /* See deactivate_task() below. */
> - prev_state = prev->state;
> -
>   /*
>* Make sure that signal_pending_state()->signal_pending() below
>* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
> @@ -4223,7 +4220,8 @@ static void __sched notrace __schedule(bool preempt)
>* We must re-load prev->state in case ttwu_remote() changed it
>* before we acquired rq->lock.
>*/
> - if (!preempt && prev_state && prev_state == prev->state) {
> + prev_state = prev->state;
> + if (!preempt && prev_state) {
>   if (signal_pending_state(prev_state, prev)) {
>   prev->state = TASK_RUNNING;
>   } else {
> @@ -4237,10 +4235,12 @@ static void __sched notrace __schedule(bool preempt)
>  
>   /*
>* __schedule() ttwu()
> -  *   prev_state = prev->state;if 
> (READ_ONCE(p->on_rq) && ...)
> -  *   LOCK rq->lock  goto out;
> -  *   smp_mb__after_spinlock();
> smp_acquire__after_ctrl_dep();
> -  *   p->on_rq = 0;p->state = 
> TASK_WAKING;
> +  *   if (prev_state)  if (p->on_rq && ...)
> +  * p->on_rq = 0;goto out;
> +  *
> smp_acquire__after_ctrl_dep();
> +  *p->state = TASK_WAKING
> +  *
> +  * Where __schedule() and ttwu() have matching control 
> dependencies.
>*
>* After this, schedule() must not care about p->state 
> any more.
>*/

[PATCH v2] media: cafe-driver: use generic power management

[Vaibhav Gupta]

Drivers using legacy PM have to manage PCI states and device's PM states
themselves. They also need to take care of configuration registers.

With improved and powerful support of generic PM, PCI Core takes care of
above mentioned, device-independent, jobs.

This driver makes use of PCI helper functions like
pci_save/restore_state() and pci_enable/disable_device() to do required
operations. In generic mode, they are no longer needed.

Change function parameter in both .suspend() and .resume() to
"struct device*" type.

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 .../media/platform/marvell-ccic/cafe-driver.c | 31 +--
 .../media/platform/marvell-ccic/mcam-core.c   |  3 --
 .../media/platform/marvell-ccic/mcam-core.h   |  2 --
 3 files changed, 7 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/cafe-driver.c 
b/drivers/media/platform/marvell-ccic/cafe-driver.c
index 9a09a10a3631..58b9915ac7a4 100644
--- a/drivers/media/platform/marvell-ccic/cafe-driver.c
+++ b/drivers/media/platform/marvell-ccic/cafe-driver.c
@@ -604,44 +604,28 @@ static void cafe_pci_remove(struct pci_dev *pdev)
 }
 
 
-#ifdef CONFIG_PM
 /*
  * Basic power management.
  */
-static int cafe_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused cafe_pci_suspend(struct device *dev)
 {
-   struct v4l2_device *v4l2_dev = dev_get_drvdata(>dev);
+   struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
struct cafe_camera *cam = to_cam(v4l2_dev);
-   int ret;
 
-   ret = pci_save_state(pdev);
-   if (ret)
-   return ret;
mccic_suspend(>mcam);
-   pci_disable_device(pdev);
return 0;
 }
 
 
-static int cafe_pci_resume(struct pci_dev *pdev)
+static int __maybe_unused cafe_pci_resume(struct device *dev)
 {
-   struct v4l2_device *v4l2_dev = dev_get_drvdata(>dev);
+   struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
struct cafe_camera *cam = to_cam(v4l2_dev);
-   int ret = 0;
 
-   pci_restore_state(pdev);
-   ret = pci_enable_device(pdev);
-
-   if (ret) {
-   cam_warn(cam, "Unable to re-enable device on resume!\n");
-   return ret;
-   }
cafe_ctlr_init(>mcam);
return mccic_resume(>mcam);
 }
 
-#endif  /* CONFIG_PM */
-
 static const struct pci_device_id cafe_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL,
 PCI_DEVICE_ID_MARVELL_88ALP01_CCIC) },
@@ -650,15 +634,14 @@ static const struct pci_device_id cafe_ids[] = {
 
 MODULE_DEVICE_TABLE(pci, cafe_ids);
 
+static SIMPLE_DEV_PM_OPS(cafe_pci_pm_ops, cafe_pci_suspend, cafe_pci_resume);
+
 static struct pci_driver cafe_pci_driver = {
.name = "cafe1000-ccic",
.id_table = cafe_ids,
.probe = cafe_pci_probe,
.remove = cafe_pci_remove,
-#ifdef CONFIG_PM
-   .suspend = cafe_pci_suspend,
-   .resume = cafe_pci_resume,
-#endif
+   .driver.pm = _pci_pm_ops,
 };
 
 
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 09775b6624c6..d81d0c130e3c 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1967,8 +1967,6 @@ EXPORT_SYMBOL_GPL(mccic_shutdown);
 /*
  * Power management
  */
-#ifdef CONFIG_PM
-
 void mccic_suspend(struct mcam_camera *cam)
 {
mutex_lock(>s_mutex);
@@ -2015,7 +2013,6 @@ int mccic_resume(struct mcam_camera *cam)
return ret;
 }
 EXPORT_SYMBOL_GPL(mccic_resume);
-#endif /* CONFIG_PM */
 
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Jonathan Corbet ");
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h 
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 2e3a7567a76a..b55545822fd2 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -236,10 +236,8 @@ static inline void mcam_reg_set_bit(struct mcam_camera 
*cam,
 int mccic_register(struct mcam_camera *cam);
 int mccic_irq(struct mcam_camera *cam, unsigned int irqs);
 void mccic_shutdown(struct mcam_camera *cam);
-#ifdef CONFIG_PM
 void mccic_suspend(struct mcam_camera *cam);
 int mccic_resume(struct mcam_camera *cam);
-#endif
 
 /*
  * Register definitions for the m88alp01 camera interface.  Offsets in bytes
-- 
2.27.0

Re: [PATCH v5 net-next] net: hyperv: Add attributes to show TX indirection table

[Stephen Hemminger]

On Tue, 21 Jul 2020 03:50:00 +
Chi Song  wrote:

> +static void netvsc_attrs_init(void)
> +{
> + char buffer[4];
> + int i;
> +
> + for (i = 0; i < VRSS_SEND_TAB_SIZE; i++) {
> + sprintf(buffer, "%02u", i);
> + dev_attr_netvsc_dev_attrs[i].attr.name =
> + kstrdup(buffer, GFP_KERNEL);
> + dev_attr_netvsc_dev_attrs[i].attr.mode = 0444;
> + sysfs_attr_init(_attr_netvsc_dev_attrs[i].attr);
> +
> + dev_attr_netvsc_dev_attrs[i].show = tx_indirection_show;
> + dev_attr_netvsc_dev_attrs[i].store = NULL;
> + netvsc_dev_attrs[i] = _attr_netvsc_dev_attrs[i].attr;
> + }
> + netvsc_dev_attrs[VRSS_SEND_TAB_SIZE] = NULL;
You know that last line is unnecessary. The variable is static and 
starts out as all zero.

Overall looks good.

Acked-by: Stephen Hemminger 

KASAN: stack-out-of-bounds Write in sys_imageblit

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:4fa640dc Merge tag 'vfio-v5.8-rc7' of git://github.com/awi..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17ec2d5890
kernel config:  https://syzkaller.appspot.com/x/.config?x=575b381064b1cba2
dashboard link: https://syzkaller.appspot.com/bug?extid=ba5bd977df7bb87862c4
compiler:   gcc (GCC) 10.1.0-syz 20200507
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ba5bd977df7bb8786...@syzkaller.appspotmail.com

==
BUG: KASAN: stack-out-of-bounds in fast_imageblit 
drivers/video/fbdev/core/sysimgblt.c:229 [inline]
BUG: KASAN: stack-out-of-bounds in sys_imageblit+0x117f/0x1290 
drivers/video/fbdev/core/sysimgblt.c:275
Write of size 4 at addr c900097d7d90 by task syz-executor.1/11925

CPU: 1 PID: 11925 Comm: syz-executor.1 Not tainted 5.8.0-rc6-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0x5/0x436 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
 sys_imageblit+0x117f/0x1290 drivers/video/fbdev/core/sysimgblt.c:275
 drm_fb_helper_sys_imageblit+0x1c/0x180 drivers/gpu/drm/drm_fb_helper.c:763
 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
 bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:188
 fbcon_putcs+0x33c/0x3f0 drivers/video/fbdev/core/fbcon.c:1362
 do_update_region+0x399/0x630 drivers/tty/vt/vt.c:683
 invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
 highlight drivers/tty/vt/selection.c:57 [inline]
 clear_selection drivers/tty/vt/selection.c:84 [inline]
 clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
 vc_do_resize+0x1099/0x13f0 drivers/tty/vt/vt.c:1230
 fbcon_do_set_font+0x4ad/0x950 drivers/video/fbdev/core/fbcon.c:2609
 fbcon_set_font+0x767/0x8b0 drivers/video/fbdev/core/fbcon.c:2706
 con_font_set drivers/tty/vt/vt.c:4571 [inline]
 con_font_op+0xd25/0x1110 drivers/tty/vt/vt.c:4636
 vt_ioctl+0x1180/0x2670 drivers/tty/vt/vt_ioctl.c:928
 vt_compat_ioctl+0x168/0x6b0 drivers/tty/vt/vt_ioctl.c:1249
 tty_compat_ioctl+0x19c/0x410 drivers/tty/tty_io.c:2847
 __do_compat_sys_ioctl+0x1d3/0x230 fs/ioctl.c:847
 do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428
 __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline]
 do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503
 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7f48569
Code: Bad RIP value.
RSP: 002b:f5d430bc EFLAGS: 0296 ORIG_RAX: 0036
RAX: ffda RBX: 0003 RCX: 4b61
RDX: 2080 RSI:  RDI: 
RBP:  R08:  R09: 
R10:  R11:  R12: 
R13:  R14:  R15: 


Memory state around the buggy address:
 c900097d7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c900097d7d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>c900097d7d80: 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00 00 00
 ^
 c900097d7e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c900097d7e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [PATCH v4 09/10] powerpc/watchpoint: Return available watchpoints dynamically

[Jordan Niethe]

On Tue, Jul 21, 2020 at 1:57 PM Ravi Bangoria
 wrote:
>
>
>
> On 7/20/20 9:12 AM, Jordan Niethe wrote:
> > On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
> >  wrote:
> >>
> >> So far Book3S Powerpc supported only one watchpoint. Power10 is
> >> introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
> >> Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
> >>
> >> Signed-off-by: Ravi Bangoria 
> >> ---
> >>   arch/powerpc/include/asm/cputable.h  | 4 +++-
> >>   arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
> >>   2 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/powerpc/include/asm/cputable.h 
> >> b/arch/powerpc/include/asm/cputable.h
> >> index 3445c86e1f6f..36a0851a7a9b 100644
> >> --- a/arch/powerpc/include/asm/cputable.h
> >> +++ b/arch/powerpc/include/asm/cputable.h
> >> @@ -633,7 +633,9 @@ enum {
> >>* Maximum number of hw breakpoint supported on powerpc. Number of
> >>* breakpoints supported by actual hw might be less than this.
> >>*/
> >> -#define HBP_NUM_MAX1
> >> +#define HBP_NUM_MAX2
> >> +#define HBP_NUM_ONE1
> >> +#define HBP_NUM_TWO2
> > I wonder if these defines are necessary - has it any advantage over
> > just using the literal?
>
> No, not really. Initially I had something like:
>
> #define HBP_NUM_MAX2
> #define HBP_NUM_P8_P9  1
> #define HBP_NUM_P102
>
> But then I thought it's also not right. So I made it _ONE and _TWO.
> Now the function that decides nr watchpoints dynamically (nr_wp_slots)
> is in different file, I thought to keep it like this so it would be
> easier to figure out why _MAX is 2.
>
> >>
> >>   #endif /* !__ASSEMBLY__ */
> >>
> >> diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
> >> b/arch/powerpc/include/asm/hw_breakpoint.h
> >> index cb424799da0d..d4eab1694bcd 100644
> >> --- a/arch/powerpc/include/asm/hw_breakpoint.h
> >> +++ b/arch/powerpc/include/asm/hw_breakpoint.h
> >> @@ -5,10 +5,11 @@
> >>* Copyright 2010, IBM Corporation.
> >>* Author: K.Prasad 
> >>*/
> >> -
> > Was removing this line deliberate?
>
> Nah. Will remove that hunk.
>
> >>   #ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
> >>   #define _PPC_BOOK3S_64_HW_BREAKPOINT_H
> >>
> >> +#include 
> >> +
> >>   #ifdef __KERNEL__
> >>   struct arch_hw_breakpoint {
> >>  unsigned long   address;
> >> @@ -46,7 +47,7 @@ struct arch_hw_breakpoint {
> >>
> >>   static inline int nr_wp_slots(void)
> >>   {
> >> -   return HBP_NUM_MAX;
> >> +   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE;
> > So it'd be something like:
> > +   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
> > But thinking that there might be more slots added in the future, it
> > may be better to make the number of slots a variable that is set
> > during the init and then have this function return that.
>
> Not sure I follow. What do you mean by setting number of slots a
> variable that is set during the init?
Sorry I was unclear there.
I was just looking and saw arm also has a variable number of hw breakpoints.
If we did something like how they handle it, it might look something like:

static int num_wp_slots __ro_after_init;

int nr_wp_slots(void) {
return num_wp_slots;
}

static int __init arch_hw_breakpoint_init(void) {
num_wp_slots = work out how many wp_slots
}
arch_initcall(arch_hw_breakpoint_init);

Then we wouldn't have to calculate everytime nr_wp_slots() is called.
In the future if more wp's are added nr_wp_slots() will get more complicated.
But just an idea, feel free to ignore.

>
> Thanks,
> Ravi

Re: [PATCH V2 vhost next 10/10] vdpa/mlx5: Add VDPA driver for supported mlx5 devices

[kernel test robot]

Hi Eli,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20200717]

url:
https://github.com/0day-ci/linux/commits/Eli-Cohen/VDPA-support-for-Mellanox-ConnectX-devices/20200720-160220
base:aab7ee9f8ff0110bfcd594b33dc33748dc1baf46
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
cf1105069648446d58adfb7a6cc590013d6886ba)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   In file included from drivers/vdpa/mlx5/net/mlx5_vnet.c:12:
>> drivers/vdpa/mlx5/net/mlx5_vnet.h:13:10: fatal error: 'mlx5_vdpa.h' file not 
>> found
   #include "mlx5_vdpa.h"
^
   1 error generated.

vim +13 drivers/vdpa/mlx5/net/mlx5_vnet.h

 6  
 7  #include 
 8  #include 
 9  #include 
10  #include 
11  #include 
12  #include 
  > 13  #include "mlx5_vdpa.h"
14  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

KASAN: use-after-free Read in sock_def_write_space (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:5714ee50 copy_xstate_to_kernel: Fix typo which caused GDB ..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13059e7f10
kernel config:  https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
dashboard link: https://syzkaller.appspot.com/bug?extid=6720d64f31c081c2f708
compiler:   gcc (GCC) 10.1.0-syz 20200507
userspace arch: i386
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1732cabb10
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=163ace5f10

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6720d64f31c081c2f...@syzkaller.appspotmail.com

IPVS: ftp: loaded support on port[0] = 21
==
BUG: KASAN: use-after-free in list_empty include/linux/list.h:282 [inline]
BUG: KASAN: use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: use-after-free in wq_has_sleeper include/linux/wait.h:161 [inline]
BUG: KASAN: use-after-free in skwq_has_sleeper include/net/sock.h:2143 [inline]
BUG: KASAN: use-after-free in sock_def_write_space+0x609/0x630 
net/core/sock.c:2926
Read of size 8 at addr 88808a6d25c0 by task syz-executor863/6817

CPU: 0 PID: 6817 Comm: syz-executor863 Not tainted 5.8.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 list_empty include/linux/list.h:282 [inline]
 waitqueue_active include/linux/wait.h:127 [inline]
 wq_has_sleeper include/linux/wait.h:161 [inline]
 skwq_has_sleeper include/net/sock.h:2143 [inline]
 sock_def_write_space+0x609/0x630 net/core/sock.c:2926
 sock_wfree+0x1cc/0x240 net/core/sock.c:2060
 skb_release_head_state+0x9f/0x250 net/core/skbuff.c:651
 skb_release_all net/core/skbuff.c:662 [inline]
 __kfree_skb net/core/skbuff.c:678 [inline]
 kfree_skb.part.0+0x89/0x350 net/core/skbuff.c:696
 kfree_skb+0x7d/0x100 include/linux/refcount.h:270
 skb_queue_purge+0x14/0x30 net/core/skbuff.c:3077
 qrtr_tun_release+0x40/0x60 net/qrtr/tun.c:118
 __fput+0x33c/0x880 fs/file_table.c:281
 task_work_run+0xdd/0x190 kernel/task_work.c:135
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop arch/x86/entry/common.c:239 [inline]
 __prepare_exit_to_usermode+0x1e9/0x1f0 arch/x86/entry/common.c:269
 __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline]
 do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503
 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7fc2569
Code: Bad RIP value.
RSP: 002b:ffd1de7c EFLAGS: 0246 ORIG_RAX: 0006
RAX:  RBX: 0006 RCX: 2180
RDX: 0007 RSI: 080bffdb RDI: 218e
RBP: ffd1dee8 R08:  R09: 
R10:  R11:  R12: 
R13:  R14:  R15: 

Allocated by task 6817:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
 slab_post_alloc_hook mm/slab.h:586 [inline]
 slab_alloc mm/slab.c:3320 [inline]
 kmem_cache_alloc+0x12c/0x3b0 mm/slab.c:3484
 sock_alloc_inode+0x18/0x1c0 net/socket.c:253
 alloc_inode+0x61/0x230 fs/inode.c:232
 new_inode_pseudo+0x14/0xe0 fs/inode.c:928
 sock_alloc+0x3c/0x260 net/socket.c:573
 __sock_create+0xb9/0x740 net/socket.c:1392
 sock_create net/socket.c:1479 [inline]
 __sys_socket+0xef/0x200 net/socket.c:1521
 __do_sys_socket net/socket.c:1530 [inline]
 __se_sys_socket net/socket.c:1528 [inline]
 __ia32_sys_socket+0x6f/0xb0 net/socket.c:1528
 do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428
 __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline]
 do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503
 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c

Freed by task 16:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 kasan_set_free_info mm/kasan/common.c:316 [inline]
 __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
 __cache_free mm/slab.c:3426 [inline]
 kmem_cache_free+0x7f/0x310 mm/slab.c:3694
 i_callback+0x3f/0x70 fs/inode.c:221
 rcu_do_batch kernel/rcu/tree.c:2414 [inline]
 rcu_core+0x5c7/0x1160 kernel/rcu/tree.c:2641
 __do_softirq+0x34c/0xa60 kernel/softirq.c:292

The buggy address belongs to the object at 88808a6d2540
 which belongs to the cache sock_inode_cache of size 1216
The buggy address is located 128 bytes inside of
 1216-byte region [88808a6d2540, 88808a6d2a00)
The buggy address belongs to the page:
page:ea000229b480 

[PATCH] x86/cpu: Add Lakefield, Alder Lake and Rocket Lake to Intel family

[Tony Luck]

Three new CPU models.

Signed-off-by: Tony Luck 
---

This patch supercedes
  https://lore.kernel.org/lkml/20200709192353.21151-1-tony.l...@intel.com/
That one just added Rocket Lake

 arch/x86/include/asm/intel-family.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/include/asm/intel-family.h 
b/arch/x86/include/asm/intel-family.h
index a338a6deb950..5e658ba2654a 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -89,8 +89,15 @@
 #define INTEL_FAM6_COMETLAKE   0xA5
 #define INTEL_FAM6_COMETLAKE_L 0xA6
 
+#define INTEL_FAM6_ROCKETLAKE  0xA7
+
 #define INTEL_FAM6_SAPPHIRERAPIDS_X0x8F
 
+/* Hybrid Core/Atom Processors */
+
+#defineINTEL_FAM6_LAKEFIELD0x8A
+#define INTEL_FAM6_ALDERLAKE   0x97
+
 /* "Small Core" Processors (Atom) */
 
 #define INTEL_FAM6_ATOM_BONNELL0x1C /* Diamondville, Pineview 
*/
-- 
2.21.1

Re: KASAN: use-after-free Read in userfaultfd_release (2)

[Stephen Rothwell]

Hi all,

On Mon, 20 Jul 2020 11:50:25 -0400 Qian Cai  wrote:
>
> On Fri, Jul 17, 2020 at 11:05:41AM -0400, Qian Cai wrote:
> > On Mon, Jul 13, 2020 at 08:34:06AM -0700, syzbot wrote:  
> > > syzbot has bisected this bug to:
> > > 
> > > commit d08ac70b1e0dc71ac2315007bcc3efb283b2eae4
> > > Author: Daniel Colascione 
> > > Date:   Wed Apr 1 21:39:03 2020 +
> > > 
> > > Wire UFFD up to SELinux
> > > 
> > > bisection log:  
> > > https://syzkaller.appspot.com/x/bisect.txt?x=14a79d1310
> > > start commit:   89032636 Add linux-next specific files for 20200708
> > > git tree:   linux-next
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=16a79d1310
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=12a79d1310
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=64a250ebabc6c320
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=75867c44841cb6373570
> > > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13c4c8db10
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12cbb68f10
> > > 
> > > Reported-by: syzbot+75867c44841cb6373...@syzkaller.appspotmail.com
> > > Fixes: d08ac70b1e0d ("Wire UFFD up to SELinux")
> > > 
> > > For information about bisection process see: 
> > > https://goo.gl/tpsmEJ#bisection  
> > 
> > This is rather easy to reproduce here,  
> 
> James, Stephen, can you drop this patch? Daniel's email was bounced, and Viro
> mentioned the patch could be quite bad,
> 
> https://lore.kernel.org/lkml/20200719165746.gj2786...@zeniv.linux.org.uk/

I have reverted that commit in linux-next today.

-- 
Cheers,
Stephen Rothwell


pgpgOtTrb8iaw.pgp
Description: OpenPGP digital signature

general protection fault in __xfrm6_tunnel_spi_check

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:4c43049f Add linux-next specific files for 20200716
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f786d710
kernel config:  https://syzkaller.appspot.com/x/.config?x=2c76d72659687242
dashboard link: https://syzkaller.appspot.com/bug?extid=cbb5af985601225ceb76
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+cbb5af985601225ce...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 
0xe01ffc04:  [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0x0120-0x0127]
CPU: 0 PID: 11470 Comm: syz-executor.3 Not tainted 
5.8.0-rc5-next-20200716-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__xfrm6_tunnel_spi_check+0x1e5/0x330 net/ipv6/xfrm6_tunnel.c:111
Code: 0f 85 3c 01 00 00 48 8b 5b 10 48 85 db 74 44 e8 31 41 7b fa 48 83 eb 10 
74 39 e8 26 41 7b fa 48 8d 7b 30 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 74 
08 3c 03 0f 8e fd 00 00 00 8b 6b 30 44 89
RSP: 0018:c900175df3d0 EFLAGS: 00010202
RAX: 0024 RBX: 00f0 RCX: c9000f672000
RDX: 0004 RSI: 86f8eeba RDI: 0120
RBP: 88805bdfc800 R08: 0001 R09: 888089c1cc10
R10: fbfff1571bb9 R11:  R12: 98f1a001
R13: dc00 R14: 0001 R15: 98f19fff
FS:  7f1165c1d700() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20001600 CR3: 92d1e000 CR4: 001526f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __xfrm6_tunnel_alloc_spi net/ipv6/xfrm6_tunnel.c:131 [inline]
 xfrm6_tunnel_alloc_spi+0x296/0x8a0 net/ipv6/xfrm6_tunnel.c:174
 ipcomp6_tunnel_create net/ipv6/ipcomp6.c:84 [inline]
 ipcomp6_tunnel_attach net/ipv6/ipcomp6.c:124 [inline]
 ipcomp6_init_state net/ipv6/ipcomp6.c:159 [inline]
 ipcomp6_init_state+0x2af/0x700 net/ipv6/ipcomp6.c:139
 __xfrm_init_state+0x9a6/0x14b0 net/xfrm/xfrm_state.c:2498
 xfrm_state_construct net/xfrm/xfrm_user.c:627 [inline]
 xfrm_add_sa+0x1db9/0x34f0 net/xfrm/xfrm_user.c:684
 xfrm_user_rcv_msg+0x414/0x700 net/xfrm/xfrm_user.c:2684
 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469
 xfrm_netlink_rcv+0x6b/0x90 net/xfrm/xfrm_user.c:2692
 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2362
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2416
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2449
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c1d9
Code: Bad RIP value.
RSP: 002b:7f1165c1cc78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0002a500 RCX: 0045c1d9
RDX:  RSI: 2180 RDI: 0003
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffc3130211f R14: 7f1165c1d9c0 R15: 0078bf0c
Modules linked in:
---[ end trace 21b48c86a3c64819 ]---
RIP: 0010:__xfrm6_tunnel_spi_check+0x1e5/0x330 net/ipv6/xfrm6_tunnel.c:111
Code: 0f 85 3c 01 00 00 48 8b 5b 10 48 85 db 74 44 e8 31 41 7b fa 48 83 eb 10 
74 39 e8 26 41 7b fa 48 8d 7b 30 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 74 
08 3c 03 0f 8e fd 00 00 00 8b 6b 30 44 89
RSP: 0018:c900175df3d0 EFLAGS: 00010202
RAX: 0024 RBX: 00f0 RCX: c9000f672000
RDX: 0004 RSI: 86f8eeba RDI: 0120
RBP: 88805bdfc800 R08: 0001 R09: 888089c1cc10
R10: fbfff1571bb9 R11:  R12: 98f1a001
R13: dc00 R14: 0001 R15: 98f19fff
FS:  7f1165c1d700() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20001600 CR3: 92d1e000 CR4: 001526f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

linux-next: manual merge of the tip tree with the crypto tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/inst.h

between commit:

  d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")
(also "crypto: x86 - Put back integer parts of include/asm/inst.h"
which I have added to the crypto tree merge today)

from the crypto tree and commit:

  eaad981291ee ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/inst.h
index 438ccd4f3cc4,d063841a17e3..
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@@ -143,6 -203,124 +143,21 @@@
.macro MODRM mod opd1 opd2
.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)
.endm
+ 
 -  .macro PSHUFB_XMM xmm1 xmm2
 -  XMM_NUM pshufb_opd1 \xmm1
 -  XMM_NUM pshufb_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX pshufb_opd1 pshufb_opd2
 -  .byte 0x0f, 0x38, 0x00
 -  MODRM 0xc0 pshufb_opd1 pshufb_opd2
 -  .endm
 -
 -  .macro PCLMULQDQ imm8 xmm1 xmm2
 -  XMM_NUM clmul_opd1 \xmm1
 -  XMM_NUM clmul_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX clmul_opd1 clmul_opd2
 -  .byte 0x0f, 0x3a, 0x44
 -  MODRM 0xc0 clmul_opd1 clmul_opd2
 -  .byte \imm8
 -  .endm
 -
 -  .macro PEXTRD imm8 xmm gpr
 -  R32_NUM extrd_opd1 \gpr
 -  XMM_NUM extrd_opd2 \xmm
 -  PFX_OPD_SIZE
 -  PFX_REX extrd_opd1 extrd_opd2
 -  .byte 0x0f, 0x3a, 0x16
 -  MODRM 0xc0 extrd_opd1 extrd_opd2
 -  .byte \imm8
 -  .endm
 -
 -  .macro AESKEYGENASSIST rcon xmm1 xmm2
 -  XMM_NUM aeskeygen_opd1 \xmm1
 -  XMM_NUM aeskeygen_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aeskeygen_opd1 aeskeygen_opd2
 -  .byte 0x0f, 0x3a, 0xdf
 -  MODRM 0xc0 aeskeygen_opd1 aeskeygen_opd2
 -  .byte \rcon
 -  .endm
 -
 -  .macro AESIMC xmm1 xmm2
 -  XMM_NUM aesimc_opd1 \xmm1
 -  XMM_NUM aesimc_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aesimc_opd1 aesimc_opd2
 -  .byte 0x0f, 0x38, 0xdb
 -  MODRM 0xc0 aesimc_opd1 aesimc_opd2
 -  .endm
 -
 -  .macro AESENC xmm1 xmm2
 -  XMM_NUM aesenc_opd1 \xmm1
 -  XMM_NUM aesenc_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aesenc_opd1 aesenc_opd2
 -  .byte 0x0f, 0x38, 0xdc
 -  MODRM 0xc0 aesenc_opd1 aesenc_opd2
 -  .endm
 -
 -  .macro AESENCLAST xmm1 xmm2
 -  XMM_NUM aesenclast_opd1 \xmm1
 -  XMM_NUM aesenclast_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aesenclast_opd1 aesenclast_opd2
 -  .byte 0x0f, 0x38, 0xdd
 -  MODRM 0xc0 aesenclast_opd1 aesenclast_opd2
 -  .endm
 -
 -  .macro AESDEC xmm1 xmm2
 -  XMM_NUM aesdec_opd1 \xmm1
 -  XMM_NUM aesdec_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aesdec_opd1 aesdec_opd2
 -  .byte 0x0f, 0x38, 0xde
 -  MODRM 0xc0 aesdec_opd1 aesdec_opd2
 -  .endm
 -
 -  .macro AESDECLAST xmm1 xmm2
 -  XMM_NUM aesdeclast_opd1 \xmm1
 -  XMM_NUM aesdeclast_opd2 \xmm2
 -  PFX_OPD_SIZE
 -  PFX_REX aesdeclast_opd1 aesdeclast_opd2
 -  .byte 0x0f, 0x38, 0xdf
 -  MODRM 0xc0 aesdeclast_opd1 aesdeclast_opd2
 -  .endm
 -
 -  .macro MOVQ_R64_XMM opd1 opd2
 -  REG_TYPE movq_r64_xmm_opd1_type \opd1
 -  .if movq_r64_xmm_opd1_type == REG_TYPE_XMM
 -  XMM_NUM movq_r64_xmm_opd1 \opd1
 -  R64_NUM movq_r64_xmm_opd2 \opd2
 -  .else
 -  R64_NUM movq_r64_xmm_opd1 \opd1
 -  XMM_NUM movq_r64_xmm_opd2 \opd2
 -  .endif
 -  PFX_OPD_SIZE
 -  PFX_REX movq_r64_xmm_opd1 movq_r64_xmm_opd2 1
 -  .if movq_r64_xmm_opd1_type == REG_TYPE_XMM
 -  .byte 0x0f, 0x7e
 -  .else
 -  .byte 0x0f, 0x6e
 -  .endif
 -  MODRM 0xc0 movq_r64_xmm_opd1 movq_r64_xmm_opd2
 -  .endm
 -
+ .macro RDPID opd
+   REG_TYPE rdpid_opd_type \opd
+   .if rdpid_opd_type == REG_TYPE_R64
+   R64_NUM rdpid_opd \opd
+   .else
+   R32_NUM rdpid_opd \opd
+   .endif
+   .byte 0xf3
+   .if rdpid_opd > 7
+   PFX_REX rdpid_opd 0
+   .endif
+   .byte 0x0f, 0xc7
+   MODRM 0xc0 rdpid_opd 0x7
+ .endm
  #endif
  
  #endif


pgppcuwK6L0c3.pgp
Description: OpenPGP digital signature

[PATCH 0/3] PWM backlight interpolation adjustments

[Alexandru Stan]

I was trying to adjust the brightness for a new chromebook:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
Like a lot of panels, the low end needs to be cropped,
and now that we have the interpolation stuff I wanted to make use of it
and bake in even the curve.

I found the behavior a little unintuitive and non-linear. See patch 1
for a suggested fix for this.

Unfortunatelly a few veyron dts files were relying on this
(perhaps weird) behavior. Those devices also want a minimum brightness.
The issue is that they also want the 0% point for turning off the
display.
https://github.com/torvalds/linux/commit/6233269bce47bd450196a671ab28eb1ec5eb88d9#diff-e401ae20091bbfb311a062c464f4f47fL23

So the idea here is to change those dts files to only say <3 255> (patch
3), and add in a virtual 0% point at the bottom of the scale (patch 2).

We have to do this conditionally because it seems some devices like to
have the scale inverted:
  % git grep "brightness-levels\s*=\s*<\s*[1-9]"|cat
  arch/arm/boot/dts/tegra124-apalis-eval.dts: brightness-levels = 
<255 231 223 207 191 159 127 0>;


Alexandru Stan (3):
  backlight: pwm_bl: Fix interpolation
  backlight: pwm_bl: Artificially add 0% during interpolation
  ARM: dts: rockchip: Remove 0 point in backlight

 arch/arm/boot/dts/rk3288-veyron-jaq.dts|  2 +-
 arch/arm/boot/dts/rk3288-veyron-minnie.dts |  2 +-
 arch/arm/boot/dts/rk3288-veyron-tiger.dts  |  2 +-
 drivers/video/backlight/pwm_bl.c   | 78 +++---
 4 files changed, 42 insertions(+), 42 deletions(-)

-- 
2.27.0

[PATCH 1/3] backlight: pwm_bl: Fix interpolation

[Alexandru Stan]

Whenever num-interpolated-steps was larger than the distance
between 2 consecutive brightness levels the table would get really
discontinuous. The slope of the interpolation would stick with
integers only and if it was 0 the whole line segment would get skipped.

Example settings:
brightness-levels = <0 1 2 4 8 16 32 64 128 256>;
num-interpolated-steps = <16>;

The distances between 1 2 4 and 8 would be 1, and only starting with 16
it would start to interpolate properly.

Let's change it so there's always interpolation happening, even if
there's no enough points available (read: values in the table would
appear more than once). This should match the expected behavior much
more closely.

Reviewed-by: Douglas Anderson 
Reviewed-by: Matthias Kaehlcke 
Signed-off-by: Alexandru Stan 
---

 drivers/video/backlight/pwm_bl.c | 70 ++--
 1 file changed, 31 insertions(+), 39 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 82b8d7594701..5193a72305a2 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -235,8 +235,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
  struct platform_pwm_backlight_data *data)
 {
struct device_node *node = dev->of_node;
-   unsigned int num_levels = 0;
-   unsigned int levels_count;
+   unsigned int num_levels;
unsigned int num_steps = 0;
struct property *prop;
unsigned int *table;
@@ -265,12 +264,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
if (!prop)
return 0;
 
-   data->max_brightness = length / sizeof(u32);
+   num_levels = length / sizeof(u32);
 
/* read brightness levels from DT property */
-   if (data->max_brightness > 0) {
-   size_t size = sizeof(*data->levels) * data->max_brightness;
-   unsigned int i, j, n = 0;
+   if (num_levels > 0) {
+   size_t size = sizeof(*data->levels) * num_levels;
 
data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
if (!data->levels)
@@ -278,7 +276,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
 
ret = of_property_read_u32_array(node, "brightness-levels",
 data->levels,
-data->max_brightness);
+num_levels);
if (ret < 0)
return ret;
 
@@ -303,7 +301,13 @@ static int pwm_backlight_parse_dt(struct device *dev,
 * between two points.
 */
if (num_steps) {
-   if (data->max_brightness < 2) {
+   unsigned int num_input_levels = num_levels;
+   unsigned int i;
+   u32 x1, x2, x;
+   u32 y1, y2;
+   s64 dx, dy;
+
+   if (num_input_levels < 2) {
dev_err(dev, "can't interpolate\n");
return -EINVAL;
}
@@ -313,14 +317,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
 * taking in consideration the number of interpolated
 * steps between two levels.
 */
-   for (i = 0; i < data->max_brightness - 1; i++) {
-   if ((data->levels[i + 1] - data->levels[i]) /
-  num_steps)
-   num_levels += num_steps;
-   else
-   num_levels++;
-   }
-   num_levels++;
+   num_levels = (num_input_levels - 1) * num_steps + 1;
dev_dbg(dev, "new number of brightness levels: %d\n",
num_levels);
 
@@ -332,24 +329,25 @@ static int pwm_backlight_parse_dt(struct device *dev,
table = devm_kzalloc(dev, size, GFP_KERNEL);
if (!table)
return -ENOMEM;
-
-   /* Fill the interpolated table. */
-   levels_count = 0;
-   for (i = 0; i < data->max_brightness - 1; i++) {
-   value = data->levels[i];
-   n = (data->levels[i + 1] - value) / num_steps;
-   if (n > 0) {
-   for (j = 0; j < num_steps; j++) {
-   table[levels_count] = value;
-   value += n;
-   levels_count++;
-   }
-

[PATCH 2/3] backlight: pwm_bl: Artificially add 0% during interpolation

[Alexandru Stan]

Some displays need the low end of the curve cropped in order to make
them happy. In that case we still want to have the 0% point, even though
anything between 0% and 5%(example) would be skipped.

Signed-off-by: Alexandru Stan 
---

 drivers/video/backlight/pwm_bl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 5193a72305a2..b24711ddf504 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
/* Fill in the last point, since no line starts here. */
table[x2] = y2;
 
+   /*
+* If we don't start at 0 yet we're increasing, assume
+* the dts wanted to crop the low end of the range, so
+* insert a 0 to provide a display off mode.
+*/
+   if (table[0] > 0 && table[0] < table[num_levels - 1])
+   table[0] = 0;
+
/*
 * As we use interpolation lets remove current
 * brightness levels table and replace for the
-- 
2.27.0

[PATCH 3/3] ARM: dts: rockchip: Remove 0 point in backlight

[Alexandru Stan]

After the "PWM backlight interpolation adjustments" patches, the
backlight interpolation works a little differently. The way these
dts files were working before was relying on a bug (IMHO).

Remove the 0-3 range since otherwise we would have a 252 long
interpolation that would slowly go between 0 and 3, looking really bad
in userspace.

We'll still have the 0% point available to userspace, "backlight:
pwm_bl: Artificially add 0% during interpolation" takes care of that.

Signed-off-by: Alexandru Stan 
---

 arch/arm/boot/dts/rk3288-veyron-jaq.dts| 2 +-
 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +-
 arch/arm/boot/dts/rk3288-veyron-tiger.dts  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts 
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 171ba6185b6d..af4b21636c08 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -20,7 +20,7 @@ / {
 
  {
/* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */
-   brightness-levels = <0 8 255>;
+   brightness-levels = <8 255>;
num-interpolated-steps = <247>;
 };
 
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts 
b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index 383fad1a88a1..b25aa2f3cbee 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -39,7 +39,7 @@ volum_up {
 
  {
/* Minnie panel PWM must be >= 1%, so start non-zero brightness at 3 */
-   brightness-levels = <0 3 255>;
+   brightness-levels = <3 255>;
num-interpolated-steps = <252>;
 };
 
diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts 
b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
index 069f0c2c1fdf..52a84cbe7a90 100644
--- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
@@ -23,7 +23,7 @@ / {
 
  {
/* Tiger panel PWM must be >= 1%, so start non-zero brightness at 3 */
-   brightness-levels = <0 3 255>;
+   brightness-levels = <3 255>;
num-interpolated-steps = <252>;
 };
 
-- 
2.27.0

[PATCH v2] Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation

[Fangrui Song]

When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
$(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit,
GCC_TOOLCHAIN_DIR will be set to /usr/bin/.  --prefix= will be set to
/usr/bin/ and Clang as of 11 will search for both
$(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.

GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle,
$(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice,
$(prefix)aarch64-linux-gnu/$needle rarely contains executables.

To better model how GCC's -B/--prefix takes in effect in practice, newer
Clang (since
https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90)
only searches for $(prefix)$needle. Currently it will find /usr/bin/as
instead of /usr/bin/aarch64-linux-gnu-as.

Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE)
(/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the
appropriate cross compiling GNU as (when -no-integrated-as is in
effect).

Reported-by: Nathan Chancellor 
Signed-off-by: Fangrui Song 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Tested-by: Nick Desaulniers 
Link: https://github.com/ClangBuiltLinux/linux/issues/1099
---
Changes in v2:
* Updated description to add tags and the llvm-project commit link.
* Fixed a typo.
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 0b5f8538bde5..3ac83e375b61 100644
--- a/Makefile
+++ b/Makefile
@@ -567,7 +567,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep 
clang),)
 ifneq ($(CROSS_COMPILE),)
 CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
-CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)
+CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE)
 GCC_TOOLCHAIN  := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
 endif
 ifneq ($(GCC_TOOLCHAIN),)
-- 
2.28.0.rc0.105.gf9edc3c819-goog

Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap

[Atish Patra]

On Sat, Jul 18, 2020 at 2:24 AM Arnd Bergmann  wrote:
>
> On Sat, Jul 18, 2020 at 3:05 AM Atish Patra  wrote:
> > On Thu, Jul 16, 2020 at 11:32 PM Arnd Bergmann  wrote:
> > > On Fri, Jul 17, 2020 at 1:41 AM Atish Patra  wrote:
> > > > +#define DTB_EARLY_SIZE SZ_1M
> > > > +static char early_dtb[DTB_EARLY_SIZE] __initdata;
> > >
> > > Hardcoding the size in .bss seems slightly problematic both for
> > > small and for big systems. On machines with very little memory,
> > > this can lead to running out of free pages before .initdata gets freed,
> > > and it increases the size of the uncompressed vmlinux file by quite
> > > a bit.
> > >
> > > On some systems, the 1MB limit may get too small. While most dtbs
> > > would fall into the range between 10KB and 100KB, it can also be
> > > much larger than that, e.g. when there are DT properties that include
> > > blobs like device firmware that gets loaded into hardware by a kernel
> > > driver.
> > >
> > I was not aware that we can do such things. Is there a current example of 
> > that ?
>
> I worked on a product in the distant past where the host firmware
> included the ethernet controller firmware as a DT property[1] to get around
> restrictions on redistributing the blob in the linux-firmware package.
>
> For the .dts files we distribute with the kernel, that would not make
> sense, and I don't know of any current machines that do this in their
> system firmware.
>
> > > Is there anything stopping you from parsing the FDT in its original
> > > location without the extra copy before it gets unflattened?
> >
> > That's what the original code was doing. A fixmap entry was added to
> > map the original fdt
> > location to a virtual so that parse_dtb can be operated on a virtual
> > address. But we can't map
> > both FDT & early ioremap within a single PMD region( 2MB ). That's why
> > we removed the DT
> > mapping from the fixmap to .bss section. The other alternate option is
> > to increase the fixmap space to 4MB which seems more fragile.
>
> Could the original location just be part of the regular linear mapping of all
> RAM?

No. Because we don't map the entire RAM until setup_vm_final().
We need to parse DT before setup_vm_final() to get the memblocks and
reserved memory regions.

I'm not too familiar with the early mapping code myself, so it may not
> be possible, but that would be the most logical place where I'd put it.
>
> Arnd
>
> [1] drivers/net/ethernet/toshiba/spider_net.c



-- 
Regards,
Atish

[RFC][PATCH 3/4] arm64: add host pvstate support

[Sergey Senozhatsky]

Add PV-state support bits to the host. Host uses the guest
PV-state per-CPU pointers to update the VCPU state each time
it kvm_arch_vcpu_load() or kvm_arch_vcpu_put() the VCPU, so
that guest scheduler can become aware of the fact that not
all VCPUs are always available. Currently guest scheduler
on amr64 always assumes that all CPUs are available because
vcpu_is_preempted() is not implemented on arm64.

Signed-off-by: Sergey Senozhatsky 
---
 arch/arm64/include/asm/kvm_host.h | 23 
 arch/arm64/kvm/Makefile   |  2 +-
 arch/arm64/kvm/arm.c  |  4 +++
 arch/arm64/kvm/hypercalls.c   | 11 ++
 arch/arm64/kvm/pvstate.c  | 58 +++
 5 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kvm/pvstate.c

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index f6485c1b8c15..e6f325a4ba70 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -372,6 +372,12 @@ struct kvm_vcpu_arch {
u64 last_steal;
gpa_t base;
} steal;
+
+   /* PV state of the VCPU (e.g. vcpu_is_preempted()) */
+   struct {
+   gpa_t base;
+   struct gfn_to_hva_cache ghc;
+   } pv_state;
 };
 
 /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
@@ -556,6 +562,23 @@ static inline bool kvm_arm_is_pvtime_enabled(struct 
kvm_vcpu_arch *vcpu_arch)
return (vcpu_arch->steal.base != GPA_INVALID);
 }
 
+int kvm_init_vcpu_state(struct kvm_vcpu *vcpu, gfn_t addr);
+int kvm_release_vcpu_state(struct kvm_vcpu *vcpu);
+
+static inline void kvm_arm_vcpu_state_init(struct kvm_vcpu_arch *vcpu_arch)
+{
+   vcpu_arch->pv_state.base = GPA_INVALID;
+   memset(_arch->pv_state.ghc, 0x00, sizeof(struct gfn_to_hva_cache));
+}
+
+static inline bool
+kvm_arm_is_vcpu_state_enabled(struct kvm_vcpu_arch *vcpu_arch)
+{
+   return (vcpu_arch->pv_state.base != GPA_INVALID);
+}
+
+void kvm_update_vcpu_preempted(struct kvm_vcpu *vcpu, bool preempted);
+
 void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
 
 struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 99977c1972cc..efc05ac0d781 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_KVM) += hyp/
 
 kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
 $(KVM)/vfio.o $(KVM)/irqchip.o \
-arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
+arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o pvstate.o \
 inject_fault.o regmap.o va_layout.o hyp.o handle_exit.o \
 guest.o debug.o reset.o sys_regs.o \
 vgic-sys-reg-v3.o fpsimd.o pmu.o \
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 691d21e4c717..a1229e3b7117 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -265,6 +265,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
 
kvm_arm_pvtime_vcpu_init(>arch);
 
+   kvm_arm_vcpu_state_init(>arch);
+
vcpu->arch.hw_mmu = >kvm->arch.mmu;
 
err = kvm_vgic_vcpu_init(vcpu);
@@ -355,10 +357,12 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 
if (vcpu_has_ptrauth(vcpu))
vcpu_ptrauth_disable(vcpu);
+   kvm_update_vcpu_preempted(vcpu, false);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+   kvm_update_vcpu_preempted(vcpu, true);
kvm_arch_vcpu_put_fp(vcpu);
if (has_vhe())
kvm_vcpu_put_sysregs_vhe(vcpu);
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 550dfa3e53cd..3660552a8e02 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -52,6 +52,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_HV_PV_TIME_FEATURES:
val = SMCCC_RET_SUCCESS;
break;
+   case ARM_SMCCC_HV_PV_STATE_FEATURES:
+   val = SMCCC_RET_SUCCESS;
+   break;
}
break;
case ARM_SMCCC_HV_PV_TIME_FEATURES:
@@ -62,6 +65,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
if (gpa != GPA_INVALID)
val = gpa;
break;
+   case ARM_SMCCC_HV_PV_STATE_INIT:
+   if (kvm_init_vcpu_state(vcpu, smccc_get_arg1(vcpu)) == 0)
+   val = SMCCC_RET_SUCCESS;
+   break;
+   case ARM_SMCCC_HV_PV_STATE_RELEASE:
+   if (kvm_release_vcpu_state(vcpu) == 0)
+   val = SMCCC_RET_SUCCESS;
+   break;
default:
return kvm_psci_call(vcpu);
}
diff --git a/arch/arm64/kvm/pvstate.c b/arch/arm64/kvm/pvstate.c
new file mode 100644
index ..3152555f3ed2
--- /dev/null
+++ b/arch/arm64/kvm/pvstate.c

[RFC][PATCH 4/4] arm64: do not use dummy vcpu_is_preempted() anymore

[Sergey Senozhatsky]

vcpu_is_preempted() now can represent the actual state of
the VCPU, so the scheduler can make better decisions when
it picks the idle CPU to enqueue a task on. I executed a
whole bunch of scheduler tests [0]. One particular test
that shows the importance of vcpu_is_preempted() is AIO
stress-ng test:

x Disabled vcpu_is_preempted()
stress-ng: info:  [100] stressor   bogo ops real time  usr time  sys time   
bogo ops/s   bogo ops/s
stress-ng: info:  [100]   (secs)(secs)(secs)   
(real time) (usr+sys time)
stress-ng: info:  [100] aio  222927 10.01  0.89 27.61   
  22262.04  7822.00
stress-ng: info:  [139] aio  217043 10.01  1.00 26.80   
  21685.46  7807.30
stress-ng: info:  [178] aio  217261 10.01  1.08 26.79   
  21709.36  7795.51

+ Enabled vcpu_is_preempted()
stress-ng: info:  [100] aio  432750 10.00  1.14 19.03   
  43264.33 21455.13
stress-ng: info:  [139] aio  426771 10.01  1.09 18.67   
  42629.13 21597.72
stress-ng: info:  [179] aio  533039 10.00  1.42 20.39   
  53281.70 24440.12

Signed-off-by: Sergey Senozhatsky 
---
 arch/arm64/include/asm/spinlock.h | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/spinlock.h 
b/arch/arm64/include/asm/spinlock.h
index 9083d6992603..6a390eeabe82 100644
--- a/arch/arm64/include/asm/spinlock.h
+++ b/arch/arm64/include/asm/spinlock.h
@@ -11,17 +11,20 @@
 /* See include/linux/spinlock.h */
 #define smp_mb__after_spinlock()   smp_mb()
 
-/*
- * Changing this will break osq_lock() thanks to the call inside
- * smp_cond_load_relaxed().
- *
- * See:
- * 
https://lore.kernel.org/lkml/20200110100612.gc2...@hirez.programming.kicks-ass.net
- */
 #define vcpu_is_preempted vcpu_is_preempted
+
+#ifdef CONFIG_PARAVIRT
+extern bool paravirt_vcpu_is_preempted(int cpu);
+
+static inline bool vcpu_is_preempted(int cpu)
+{
+   return paravirt_vcpu_is_preempted(cpu);
+}
+#else
 static inline bool vcpu_is_preempted(int cpu)
 {
return false;
 }
+#endif /* CONFIG_PARAVIRT */
 
 #endif /* __ASM_SPINLOCK_H */
-- 
2.27.0

[RFC][PATCH 2/4] arm64: add guest pvstate support

[Sergey Senozhatsky]

PV-state is a per-CPU struct, which, for the time being,
holds boolean `preempted' vCPU state. During the startup,
given that host supports PV-state, each guest vCPU sends
a pointer to its per-CPU variable to the host as a payload
with the SMCC HV call, so that host can update vCPU state
when it puts or loads vCPU.

This has impact on the guest's scheduler - it does check
the state of the vCPU it wants to run a task on:

[..]
  wake_up_process()
   try_to_wake_up()
select_task_rq_fair()
 available_idle_cpu()
  vcpu_is_preempted()

Some sched benchmarks data is available on the github page [0].

[0] https://github.com/sergey-senozhatsky/arm64-vcpu_is_preempted
Signed-off-by: Sergey Senozhatsky 
---
 arch/arm64/include/asm/paravirt.h  |  15 
 arch/arm64/kernel/Makefile |   2 +-
 arch/arm64/kernel/paravirt-state.c | 117 +
 arch/arm64/kernel/paravirt.c   |   4 +-
 arch/arm64/kernel/time.c   |   1 +
 5 files changed, 137 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/kernel/paravirt-state.c

diff --git a/arch/arm64/include/asm/paravirt.h 
b/arch/arm64/include/asm/paravirt.h
index cf3a0fd7c1a7..1bf164b2041b 100644
--- a/arch/arm64/include/asm/paravirt.h
+++ b/arch/arm64/include/asm/paravirt.h
@@ -7,12 +7,22 @@ struct static_key;
 extern struct static_key paravirt_steal_enabled;
 extern struct static_key paravirt_steal_rq_enabled;
 
+struct pvstate_vcpu_info {
+   boolpreempted;
+   u8  reserved[63];
+};
+
+struct pv_state_ops {
+   bool (*vcpu_is_preempted)(int cpu);
+};
+
 struct pv_time_ops {
unsigned long long (*steal_clock)(int cpu);
 };
 
 struct paravirt_patch_template {
struct pv_time_ops time;
+   struct pv_state_ops state;
 };
 
 extern struct paravirt_patch_template pv_ops;
@@ -22,10 +32,15 @@ static inline u64 paravirt_steal_clock(int cpu)
return pv_ops.time.steal_clock(cpu);
 }
 
+bool native_vcpu_is_preempted(int cpu);
+bool paravirt_vcpu_is_preempted(int cpu);
+
+int __init pv_state_init(void);
 int __init pv_time_init(void);
 
 #else
 
+#define pv_state_init() do {} while (0)
 #define pv_time_init() do {} while (0)
 
 #endif // CONFIG_PARAVIRT
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 5fb9b728459b..18974d5e798d 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -48,7 +48,7 @@ obj-$(CONFIG_ARMV8_DEPRECATED)+= 
armv8_deprecated.o
 obj-$(CONFIG_ACPI) += acpi.o
 obj-$(CONFIG_ACPI_NUMA)+= acpi_numa.o
 obj-$(CONFIG_ARM64_ACPI_PARKING_PROTOCOL)  += acpi_parking_protocol.o
-obj-$(CONFIG_PARAVIRT) += paravirt.o
+obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt-state.o
 obj-$(CONFIG_RANDOMIZE_BASE)   += kaslr.o
 obj-$(CONFIG_HIBERNATION)  += hibernate.o hibernate-asm.o
 obj-$(CONFIG_KEXEC_CORE)   += machine_kexec.o relocate_kernel.o
\
diff --git a/arch/arm64/kernel/paravirt-state.c 
b/arch/arm64/kernel/paravirt-state.c
new file mode 100644
index ..4ae92a84c73d
--- /dev/null
+++ b/arch/arm64/kernel/paravirt-state.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#define pr_fmt(fmt) "arm-pvstate: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static DEFINE_PER_CPU(struct pvstate_vcpu_info, vcpus_states);
+
+bool native_vcpu_is_preempted(int cpu)
+{
+   return false;
+}
+
+static bool pv_vcpu_is_preempted(int cpu)
+{
+   struct pvstate_vcpu_info *st;
+
+   st = _cpu(vcpus_states, cpu);
+   return READ_ONCE(st->preempted);
+}
+
+bool paravirt_vcpu_is_preempted(int cpu)
+{
+   return pv_ops.state.vcpu_is_preempted(cpu);
+}
+
+static bool has_pvstate(void)
+{
+   struct arm_smccc_res res;
+
+   /* To detect the presence of PV time support we require SMCCC 1.1+ */
+   if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
+   return false;
+
+   arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ARM_SMCCC_HV_PV_STATE_FEATURES,
+);
+
+   if (res.a0 != SMCCC_RET_SUCCESS)
+   return false;
+   return true;
+}
+
+static int __pvstate_cpu_hook(unsigned int cpu, int event)
+{
+   struct arm_smccc_res res;
+   struct pvstate_vcpu_info *st;
+
+   st = _cpu(vcpus_states, cpu);
+   arm_smccc_1_1_invoke(event, virt_to_phys(st), );
+   if (res.a0 != SMCCC_RET_SUCCESS)
+   return -EINVAL;
+   return 0;
+}
+
+static int pvstate_cpu_init(unsigned int cpu)
+{
+   int ret = __pvstate_cpu_hook(cpu, ARM_SMCCC_HV_PV_STATE_INIT);
+
+   if (ret)
+   pr_warn("Unable to ARM_SMCCC_HV_PV_STATE_INIT\n");
+   return ret;
+}
+
+static int pvstate_cpu_release(unsigned int cpu)
+{
+   int ret = __pvstate_cpu_hook(cpu, 

[RFC][PATCH 1/4] arm64:kvm: define pv_state SMCCC HV calls

[Sergey Senozhatsky]

These will be used later on to configure and enable vCPU
PV-state support, which is needed for vcpu_is_preempted().

Signed-off-by: Sergey Senozhatsky 
---
 include/linux/arm-smccc.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 15c706fb0a37..cba054662692 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -99,6 +99,24 @@
   ARM_SMCCC_OWNER_STANDARD_HYP,\
   0x21)
 
+#define ARM_SMCCC_HV_PV_STATE_FEATURES \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_SMC_64,\
+  ARM_SMCCC_OWNER_STANDARD_HYP,\
+  0x22)
+
+#define ARM_SMCCC_HV_PV_STATE_INIT \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_SMC_64,\
+  ARM_SMCCC_OWNER_STANDARD_HYP,\
+  0x23)
+
+#define ARM_SMCCC_HV_PV_STATE_RELEASE  \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_SMC_64,\
+  ARM_SMCCC_OWNER_STANDARD_HYP,\
+  0x24)
+
 /*
  * Return codes defined in ARM DEN 0070A
  * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
-- 
2.27.0

[RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted

[Sergey Senozhatsky]

Hello,

RFC

We noticed that in a number of cases when we wake_up_process()
on arm64 guest we end up enqueuing that task on a preempted VCPU. The culprit
appears to be the fact that arm64 guests are not aware of VCPU preemption
as such, so when sched picks up an idle VCPU it always assumes that VCPU
is available:

  wake_up_process()
   try_to_wake_up()
select_task_rq_fair()
 available_idle_cpu()
  vcpu_is_preempted()// return false;

Which is, obviously, not the case.

This RFC patch set adds a simple vcpu_is_preempted() implementation so
that scheduler can make better decisions when it search for the idle
(v)CPU.

I ran a number of sched benchmarks please refer to [0] for more
details.

[0] https://github.com/sergey-senozhatsky/arm64-vcpu_is_preempted

Sergey Senozhatsky (4):
  arm64:kvm: define pv_state SMCCC HV calls
  arm64: add guest pvstate support
  arm64: add host pvstate support
  arm64: do not use dummy vcpu_is_preempted() anymore

 arch/arm64/include/asm/kvm_host.h  |  23 ++
 arch/arm64/include/asm/paravirt.h  |  15 
 arch/arm64/include/asm/spinlock.h  |  17 +++--
 arch/arm64/kernel/Makefile |   2 +-
 arch/arm64/kernel/paravirt-state.c | 117 +
 arch/arm64/kernel/paravirt.c   |   4 +-
 arch/arm64/kernel/time.c   |   1 +
 arch/arm64/kvm/Makefile|   2 +-
 arch/arm64/kvm/arm.c   |   4 +
 arch/arm64/kvm/hypercalls.c|  11 +++
 arch/arm64/kvm/pvstate.c   |  58 ++
 include/linux/arm-smccc.h  |  18 +
 12 files changed, 262 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm64/kernel/paravirt-state.c
 create mode 100644 arch/arm64/kvm/pvstate.c

-- 
2.27.0

Re: [PATCH] riscv: Select ARCH_HAS_DEBUG_VM_PGTABLE

[Palmer Dabbelt]

On Tue, 14 Jul 2020 20:20:54 PDT (-0700), anshuman.khand...@arm.com wrote:



On 07/15/2020 02:56 AM, Emil Renner Berthing wrote:

This allows the pgtable tests to be built.

Signed-off-by: Emil Renner Berthing 
---

The tests seem to succeed both in Qemu and on the HiFive Unleashed

Both with and without the recent additions in
https://lore.kernel.org/linux-riscv/1594610587-4172-1-git-send-email-anshuman.khand...@arm.com/


That's great, thanks for testing.


Actually, looking at this I'm not sure it actually helps us any.  This changes
the behavior of two functions.  Pulling out the relevant sections, I see:

unsigned int __sw_hweight32(unsigned int w)
{
#ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
   w -= (w >> 1) & 0x;
   w =  (w & 0x) + ((w >> 2) & 0x);
   w =  (w + (w >> 4)) & 0x0f0f0f0f;
   return (w * 0x01010101) >> 24;
#else
   unsigned int res = w - ((w >> 1) & 0x);
   res = (res & 0x) + ((res >> 2) & 0x);
   res = (res + (res >> 4)) & 0x0F0F0F0F;
   res = res + (res >> 8);
   return (res + (res >> 16)) & 0x00FF;
#endif
}

and

unsigned long memchr_inv(unsigned long value64)
{
#if defined(CONFIG_ARCH_HAS_FAST_MULTIPLIER) && BITS_PER_LONG == 64
   value64 *= 0x0101010101010101ULL;
#elif defined(CONFIG_ARCH_HAS_FAST_MULTIPLIER)
   value64 *= 0x01010101;
   value64 |= value64 << 32;
#else
   value64 |= value64 << 8;
   value64 |= value64 << 16;
   value64 |= value64 << 32;
#endif
return value64;
}

GCC optimizer the multiplication out of the first one:

__sw_hweight32:
li  a4,1431654400
srliw   a5,a0,1
addia4,a4,1365
and a5,a5,a4
subwa0,a0,a5
li  a5,858992640
srliw   a4,a0,2
addia5,a5,819
and a0,a5,a0
and a5,a5,a4
addwa5,a0,a5
srliw   a0,a5,4
addwa0,a0,a5
li  a5,252645376
addia5,a5,-241
and a5,a5,a0
srliw   a0,a5,8
addwa5,a0,a5
srliw   a0,a5,16
addwa0,a0,a5
andia0,a0,0xff
ret

__sw_hweight32:
li  a5,1431654400
srliw   a4,a0,1
addia5,a5,1365
and a5,a5,a4
subwa0,a0,a5
li  a5,858992640
srliw   a4,a0,2
addia5,a5,819
and a0,a5,a0
and a5,a5,a4
addwa5,a0,a5
srliw   a0,a5,4
addwa5,a0,a5
li  a0,252645376
addia0,a0,-241
and a5,a0,a5
slliw   a0,a5,8
addwa0,a0,a5
slliw   a5,a0,16
addwa0,a0,a5
srliw   a0,a0,24
ret

so that doesn't matter.  The second one is really a wash: 


memchr_inv:
ld  a5,.LC0
mul a0,a0,a5
ret
.rodata
.LC0:
.dword  72340172838076673

vs

memchr_inv:
sllia5,a0,8
or  a5,a5,a0
sllia0,a5,16
or  a0,a0,a5
sllia5,a0,32
or  a0,a5,a0
ret

It's unlikely that load ends up relaxed, so it's going to be two instructions.
That means we have 4 cycles to forward the load and multiply, for a cache hit.
IIRC the multiplier on the existing hardware isn't that fast -- GCC lists it as
imul as 10 cycles, but I remember it being more like 5 so that might just be an
architecture-inaccurate tuning in the generic pipeline model.  This is out of
the inner loop, so it's probably not all that important anyway.  The result
isn't used for a while so on a bigger machine it's probably worth picking the
smaller code path, but it seems like a very small thing to optimize for either
way.

I'm actually a bit surprised about this.  Do you have benchmarks that indicate
ARCH_HAS_FAST_MULTIPLIER is actually faster?  Otherwise I guess I'm going to
reject this, as it's really more
ARCH_HAS_FAST_MULTIPLIER_AND_FAST_LARGE_CONSTANTS than just
ARCH_HAS_FAST_MULTIPLIER.

Re: [PATCH v2 13/16] scripts/kallsyms: move ignored symbol types to is_ignored_symbol()

[Finn Thain]

On Mon, 20 Jul 2020, Masahiro Yamada wrote:

> 
> I got a similar report before.
> 
> I'd like to know whether or not
> this is the same issue as fixed by
> 7883a14339299773b2ce08dcfd97c63c199a9289
> 

The problem can be observed with 3d77e6a8804ab ("Linux 5.7").
So it appears that 7883a14339299 ("scripts/kallsyms: fix wrong 
kallsyms_relative_base") is not sufficient to fix it.

> 
> Does your problem happen on the latest kernel?

Unfortunately this cross compiler (gcc 4.6.4) is too old to build 
v5.8-rc1 or later. I will have to upgrade.

> Which version of binutils are you using?
> 

This toolchain uses binutils 2.22.

In case it helps,

$ powerpc-linux-gnu-nm -n vmlinux |head  
 w mach_chrp
0005 a LG_CACHELINE_BYTES
0005 a LG_CACHELINE_BYTES
0005 a LG_CACHELINE_BYTES
000c a Hash_bits
001f a CACHELINE_MASK
001f a CACHELINE_MASK
001f a CACHELINE_MASK
0020 a CACHELINE_BYTES
0020 a CACHELINE_BYTES
0020 a CACHELINE_BYTES
0020 a reg
0003ffc0 a Hash_msk
c000 T _start
c000 A _stext
c000 A _text
c00c T __start
c054 t __after_mmu_off
c090 t turn_on_mmu
c0c4 T __secondary_hold
c0dc T __secondary_hold_spinloop
c0e0 T __secondary_hold_acknowledge
c100 t Reset

[PATCH v3 1/2] dt-bindings: devapc: add bindings for mtk-devapc

[Neal Liu]

Add bindings for mtk-devapc.

Signed-off-by: Neal Liu 
---
 .../devicetree/bindings/soc/mediatek/devapc.yaml   |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml 
b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
new file mode 100644
index 000..6c763f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MediaTek Device Access Permission Control driver
+
+description: |
+  MediaTek bus fabric provides TrustZone security support and data
+  protection to prevent slaves from being accessed by unexpected masters.
+  The security violation is logged and sent to the processor for further
+  analysis and countermeasures.
+
+maintainers:
+  - Neal Liu 
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6779-devapc
+
+  reg:
+description: The base address of devapc register bank
+maxItems: 1
+
+  interrupts:
+description: A single interrupt specifier
+maxItems: 1
+
+  clocks:
+description: Contains module clock source and clock names
+maxItems: 1
+
+  clock-names:
+description: Names of the clocks list in clocks property
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+examples:
+  - |
+#include 
+#include 
+
+devapc: devapc@10207000 {
+  compatible = "mediatek,mt6779-devapc";
+  reg = <0x10207000 0x1000>;
+  interrupts = ;
+  clocks = <_ao CLK_INFRA_DEVICE_APC>;
+  clock-names = "devapc-infra-clock";
+};
-- 
1.7.9.5

[PATCH v3 2/2] soc: mediatek: add mtk-devapc driver

[Neal Liu]

MediaTek bus fabric provides TrustZone security support and data
protection to prevent slaves from being accessed by unexpected
masters.
The security violation is logged and sent to the processor for
further analysis or countermeasures.

Any occurrence of security violation would raise an interrupt, and
it will be handled by mtk-devapc driver. The violation
information is printed in order to find the murderer.

Signed-off-by: Neal Liu 
---
 drivers/soc/mediatek/Kconfig  |9 +
 drivers/soc/mediatek/Makefile |1 +
 drivers/soc/mediatek/mtk-devapc.c |  372 +
 drivers/soc/mediatek/mtk-devapc.h |   54 ++
 4 files changed, 436 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c
 create mode 100644 drivers/soc/mediatek/mtk-devapc.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..1177c98 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -17,6 +17,15 @@ config MTK_CMDQ
  time limitation, such as updating display configuration during the
  vblank.
 
+config MTK_DEVAPC
+   tristate "Mediatek Device APC Support"
+   help
+ Say yes here to enable support for Mediatek Device APC driver.
+ This driver is mainly used to handle the violation which catches
+ unexpected transaction.
+ The violation information is logged for further analysis or
+ countermeasures.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..abfd4ba 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
+obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-devapc.c 
b/drivers/soc/mediatek/mtk-devapc.c
new file mode 100644
index 000..1397e98
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -0,0 +1,372 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "mtk-devapc.h"
+
+static u32 get_shift_group(struct mtk_devapc_context *ctx, u32 vio_idx)
+{
+   u32 vio_shift_sta;
+   void __iomem *reg;
+
+   reg = ctx->devapc_pd_base + ctx->offset->vio_shift_sta;
+   vio_shift_sta = readl(reg);
+
+   if (vio_shift_sta)
+   return __ffs(vio_shift_sta);
+
+   return 31;
+}
+
+static int check_vio_mask_sta(struct mtk_devapc_context *ctx, u32 module,
+ u32 offset)
+{
+   void __iomem *reg;
+   u32 value;
+
+   reg = ctx->devapc_pd_base + offset;
+   reg += 0x4 * VIO_MOD_TO_REG_IND(module);
+
+   value = readl(reg);
+
+   return ((value >> VIO_MOD_TO_REG_OFF(module)) & 0x1);
+}
+
+static int check_vio_mask(struct mtk_devapc_context *ctx, u32 module)
+{
+   return check_vio_mask_sta(ctx, module, ctx->offset->vio_mask);
+}
+
+static int check_vio_status(struct mtk_devapc_context *ctx, u32 module)
+{
+   return check_vio_mask_sta(ctx, module, ctx->offset->vio_sta);
+}
+
+static void clear_vio_status(struct mtk_devapc_context *ctx, u32 module)
+{
+   void __iomem *reg;
+
+   reg = ctx->devapc_pd_base + ctx->offset->vio_sta;
+   reg += 0x4 * VIO_MOD_TO_REG_IND(module);
+
+   writel(0x1 << VIO_MOD_TO_REG_OFF(module), reg);
+
+   if (check_vio_status(ctx, module))
+   dev_err(ctx->dev, "%s: Clear failed, module_index:0x%x\n",
+   __func__, module);
+}
+
+static void mask_module_irq(struct mtk_devapc_context *ctx, u32 module,
+   bool mask)
+{
+   void __iomem *reg;
+   u32 value;
+
+   reg = ctx->devapc_pd_base + ctx->offset->vio_mask;
+   reg += 0x4 * VIO_MOD_TO_REG_IND(module);
+
+   value = readl(reg);
+   if (mask)
+   value |= (0x1 << VIO_MOD_TO_REG_OFF(module));
+   else
+   value &= ~(0x1 << VIO_MOD_TO_REG_OFF(module));
+
+   writel(value, reg);
+}
+
+#define PHY_DEVAPC_TIMEOUT 0x1
+
+/*
+ * sync_vio_dbg - do "shift" mechansim" to get full violation information.
+ *shift mechanism is depends on devapc hardware design.
+ *Mediatek devapc set multiple slaves as a group. When 
violation
+ *is triggered, violation info is kept inside devapc hardware.
+ *Driver should do shift mechansim to "shift" full violation
+ *info to VIO_DBGs registers.
+ *
+ */
+static int sync_vio_dbg(struct mtk_devapc_context *ctx, u32 shift_bit)
+{
+   void __iomem *pd_vio_shift_sta_reg;
+   void __iomem *pd_vio_shift_sel_reg;
+   

[PATCH v3] Add MediaTek MT6779 devapc driver

[Neal Liu]

These patch series introduce a MediaTek MT6779 devapc driver.

MediaTek bus fabric provides TrustZone security support and data protection to 
prevent slaves from being accessed by unexpected masters.
The security violation is logged and sent to the processor for further analysis 
or countermeasures.

Any occurrence of security violation would raise an interrupt, and it will be 
handled by mtk-devapc driver.
The violation information is printed in order to find the murderer.

changes since v2:
- pass platform info through DT data.
- remove unnecessary function.
- remove slave_type because it always equals to 1 in current support SoC.
- use vio_idx_num instread of list all devices' index.
- add more comments to describe hardware behavior.

changes since v1:
- move SoC specific part to DT data.
- remove unnecessary boundary check.
- remove unnecessary data type declaration.
- use read_poll_timeout() instread of for loop polling.
- revise coding style elegantly.


*** BLURB HERE ***

Neal Liu (2):
  dt-bindings: devapc: add bindings for mtk-devapc
  soc: mediatek: add mtk-devapc driver

 .../bindings/soc/mediatek/devapc.yaml |  58 +++
 drivers/soc/mediatek/Kconfig  |   9 +
 drivers/soc/mediatek/Makefile |   1 +
 drivers/soc/mediatek/mtk-devapc.c | 372 ++
 drivers/soc/mediatek/mtk-devapc.h |  54 +++
 5 files changed, 494 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c
 create mode 100644 drivers/soc/mediatek/mtk-devapc.h

-- 
2.18.0

Re: [PATCH v4 09/10] powerpc/watchpoint: Return available watchpoints dynamically

[Ravi Bangoria]

On 7/20/20 9:12 AM, Jordan Niethe wrote:

On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
 wrote:


So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.

Signed-off-by: Ravi Bangoria 
---
  arch/powerpc/include/asm/cputable.h  | 4 +++-
  arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
  2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 3445c86e1f6f..36a0851a7a9b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -633,7 +633,9 @@ enum {
   * Maximum number of hw breakpoint supported on powerpc. Number of
   * breakpoints supported by actual hw might be less than this.
   */
-#define HBP_NUM_MAX1
+#define HBP_NUM_MAX2
+#define HBP_NUM_ONE1
+#define HBP_NUM_TWO2

I wonder if these defines are necessary - has it any advantage over
just using the literal?


No, not really. Initially I had something like:

#define HBP_NUM_MAX2
#define HBP_NUM_P8_P9  1
#define HBP_NUM_P102

But then I thought it's also not right. So I made it _ONE and _TWO.
Now the function that decides nr watchpoints dynamically (nr_wp_slots)
is in different file, I thought to keep it like this so it would be
easier to figure out why _MAX is 2.



  #endif /* !__ASSEMBLY__ */

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index cb424799da0d..d4eab1694bcd 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -5,10 +5,11 @@
   * Copyright 2010, IBM Corporation.
   * Author: K.Prasad 
   */
-

Was removing this line deliberate?


Nah. Will remove that hunk.


  #ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
  #define _PPC_BOOK3S_64_HW_BREAKPOINT_H

+#include 
+
  #ifdef __KERNEL__
  struct arch_hw_breakpoint {
 unsigned long   address;
@@ -46,7 +47,7 @@ struct arch_hw_breakpoint {

  static inline int nr_wp_slots(void)
  {
-   return HBP_NUM_MAX;
+   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE;

So it'd be something like:
+   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
But thinking that there might be more slots added in the future, it
may be better to make the number of slots a variable that is set
during the init and then have this function return that.


Not sure I follow. What do you mean by setting number of slots a
variable that is set during the init?

Thanks,
Ravi

Re: [PATCH 2/4] printk: store instead of processing cont parts

[Joe Perches]

On Mon, 2020-07-20 at 11:30 -0700, Linus Torvalds wrote:
> On Sun, Jul 19, 2020 at 6:51 PM Sergey Senozhatsky
>  wrote:
> > Do I get it right, what you are saying is - when we process a PR_CONT
> > message the cont buffer should already contain previous non-LOG_NEWLINE
> > and non-PR_CONT message, otherwise it's a bug?
> 
> No.
> 
> I'm saying that the code that does PR_CONT should have done *some*
> printing before, otherwise it's at the very least questionable.
> 
> IOW, you can't just randomly start printing with PR_CONT, without
> having established _some_ context for it.

I believe there are at least a few cases that
_only_ use pr_cont to emit
complete lines.

For example: SEQ_printf in kernel/sched/debug.c

Re: [PATCH v2 3/3] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

[Xu Yilun]

On Tue, Jul 21, 2020 at 11:47:13AM +0800, Xu Yilun wrote:
> On Fri, Jul 17, 2020 at 07:16:09PM +0100, Mark Brown wrote:
> > On Thu, Jul 16, 2020 at 06:42:54PM +0800, Xu Yilun wrote:
> > 
> > > +static const struct spi_device_id m10bmc_spi_id[] = {
> > > + { "m10-n3000", M10_N3000 },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(spi, m10bmc_spi_id);
> > 
> > > +static struct spi_driver intel_m10bmc_spi_driver = {
> > > + .driver = {
> > > + .name = "intel-m10-bmc",
> > > + .dev_groups = m10bmc_dev_groups,
> > > + },
> > > + .probe = intel_m10_bmc_spi_probe,
> > > + .id_table = m10bmc_spi_id,
> > > +};
> > 
> > > +module_spi_driver(intel_m10bmc_spi_driver);
> > 
> > This device has no ACPI information - how will it be instantiated?
> 
> In our case, The m10-bmc is connected to the intel FPGA (PAC N3000),
> which uses the Device Feature List (DFL) mechanism to enumerate features
> (devices) on FPGA. Each feature in DFL has a feature_id. And for this
> m10-n3000 feature (feature_id = 0xd), it contains a spi-altera & a
> m10-n3000 chip. So the DFL subsystem would help enumerate the info.

And some DFL related infomation:
  Documentation/fpga/dfl.rst
  drivers/fpga/dfl*

Thanks,
Yilun

> 
> Recently I added the platform data for slave information in spi-altera,
> to support this use case.
> 
> Thanks,
> Yilun

KASAN: slab-out-of-bounds Read in xfrm6_tunnel_alloc_spi

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:4c43049f Add linux-next specific files for 20200716
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10e7e9d710
kernel config:  https://syzkaller.appspot.com/x/.config?x=2c76d72659687242
dashboard link: https://syzkaller.appspot.com/bug?extid=87b2b4484df1d40e7ece
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=117f936f10
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1074fc7f10

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+87b2b4484df1d40e7...@syzkaller.appspotmail.com

==
BUG: KASAN: slab-out-of-bounds in __xfrm6_tunnel_alloc_spi 
net/ipv6/xfrm6_tunnel.c:124 [inline]
BUG: KASAN: slab-out-of-bounds in xfrm6_tunnel_alloc_spi+0x779/0x8a0 
net/ipv6/xfrm6_tunnel.c:174
Read of size 4 at addr 88809a3fe000 by task syz-executor597/6834
CPU: 1 PID: 6834 Comm: syz-executor597 Not tainted 
5.8.0-rc5-next-20200716-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 __xfrm6_tunnel_alloc_spi net/ipv6/xfrm6_tunnel.c:124 [inline]
 xfrm6_tunnel_alloc_spi+0x779/0x8a0 net/ipv6/xfrm6_tunnel.c:174
 ipcomp6_tunnel_create net/ipv6/ipcomp6.c:84 [inline]
 ipcomp6_tunnel_attach net/ipv6/ipcomp6.c:124 [inline]
 ipcomp6_init_state net/ipv6/ipcomp6.c:159 [inline]
 ipcomp6_init_state+0x2af/0x700 net/ipv6/ipcomp6.c:139
 __xfrm_init_state+0x9a6/0x14b0 net/xfrm/xfrm_state.c:2498
 xfrm_init_state+0x1a/0x70 net/xfrm/xfrm_state.c:2525
 pfkey_msg2xfrm_state net/key/af_key.c:1291 [inline]
 pfkey_add+0x1a10/0x2b70 net/key/af_key.c:1508
 pfkey_process+0x66d/0x7a0 net/key/af_key.c:2834
 pfkey_sendmsg+0x42d/0x800 net/key/af_key.c:3673
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x331/0x810 net/socket.c:2362
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2416
 __sys_sendmmsg+0x195/0x480 net/socket.c:2506
 __do_sys_sendmmsg net/socket.c:2535 [inline]
 __se_sys_sendmmsg net/socket.c:2532 [inline]
 __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2532
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440409
Code: Bad RIP value.
RSP: 002b:7ffea3e50018 EFLAGS: 0246 ORIG_RAX: 0133
RAX: ffda RBX: 004002c8 RCX: 00440409
RDX: 04000282 RSI: 2180 RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10:  R11: 0246 R12: 00401c10
R13: 00401ca0 R14:  R15: 
Allocated by task 6731:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
 slab_post_alloc_hook mm/slab.h:535 [inline]
 slab_alloc mm/slab.c:3312 [inline]
 kmem_cache_alloc+0x138/0x3a0 mm/slab.c:3482
 dup_fd+0x89/0xc90 fs/file.c:293
 copy_files kernel/fork.c:1459 [inline]
 copy_process+0x1dd0/0x6b70 kernel/fork.c:2064
 _do_fork+0xe8/0xb10 kernel/fork.c:2434
 __do_sys_clone+0xc8/0x110 kernel/fork.c:2551
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 88809a3fe0c0
 which belongs to the cache files_cache of size 832
The buggy address is located 192 bytes to the left of
 832-byte region [88809a3fe0c0, 88809a3fe400)
The buggy address belongs to the page:
page:7671797d refcount:1 mapcount:0 mapping: 
index:0x88809a3fec00 pfn:0x9a3fe
flags: 0xfffe000200(slab)
raw: 00fffe000200 ea00027a5248 ea0002a3b648 88821bc47600
raw: 88809a3fec00 88809a3fe0c0 00010003 
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 88809a3fdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88809a3fdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88809a3fe000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   ^
 88809a3fe080: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
 88809a3fe100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with 

Re: [PATCH v2 3/3] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

[Xu Yilun]

On Fri, Jul 17, 2020 at 07:16:09PM +0100, Mark Brown wrote:
> On Thu, Jul 16, 2020 at 06:42:54PM +0800, Xu Yilun wrote:
> 
> > +static const struct spi_device_id m10bmc_spi_id[] = {
> > +   { "m10-n3000", M10_N3000 },
> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(spi, m10bmc_spi_id);
> 
> > +static struct spi_driver intel_m10bmc_spi_driver = {
> > +   .driver = {
> > +   .name = "intel-m10-bmc",
> > +   .dev_groups = m10bmc_dev_groups,
> > +   },
> > +   .probe = intel_m10_bmc_spi_probe,
> > +   .id_table = m10bmc_spi_id,
> > +};
> 
> > +module_spi_driver(intel_m10bmc_spi_driver);
> 
> This device has no ACPI information - how will it be instantiated?

In our case, The m10-bmc is connected to the intel FPGA (PAC N3000),
which uses the Device Feature List (DFL) mechanism to enumerate features
(devices) on FPGA. Each feature in DFL has a feature_id. And for this
m10-n3000 feature (feature_id = 0xd), it contains a spi-altera & a
m10-n3000 chip. So the DFL subsystem would help enumerate the info.

Recently I added the platform data for slave information in spi-altera,
to support this use case.

Thanks,
Yilun

[PATCH v5 net-next] net: hyperv: Add attributes to show TX indirection table

[Chi Song]

An imbalanced TX indirection table causes netvsc to have low
performance. This table is created and managed during runtime. To help
better diagnose performance issues caused by imbalanced tables, add
device attributes to show the content of TX indirection tables.

Signed-off-by: Chi Song 
---
v4: use a separated group to organize tx_indirection better, change 
 location of attributes init/exit to netvsc_drv_init/exit
v5: update variable orders.

 drivers/net/hyperv/netvsc_drv.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 6267f706e8ee..a1e009edd37e 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2370,6 +2370,51 @@ static int netvsc_unregister_vf(struct net_device 
*vf_netdev)
return NOTIFY_OK;
 }
 
+static struct device_attribute dev_attr_netvsc_dev_attrs[VRSS_SEND_TAB_SIZE];
+static struct attribute *netvsc_dev_attrs[VRSS_SEND_TAB_SIZE + 1];
+
+const struct attribute_group netvsc_dev_group = {
+   .name = "tx_indirection",
+   .attrs = netvsc_dev_attrs,
+};
+
+static ssize_t tx_indirection_show(struct device *dev,
+  struct device_attribute *dev_attr, char *buf)
+{
+   int index = dev_attr - dev_attr_netvsc_dev_attrs;
+   struct net_device *ndev = to_net_dev(dev);
+   struct net_device_context *ndc = netdev_priv(ndev);
+
+   return sprintf(buf, "%u\n", ndc->tx_table[index]);
+}
+
+static void netvsc_attrs_init(void)
+{
+   char buffer[4];
+   int i;
+
+   for (i = 0; i < VRSS_SEND_TAB_SIZE; i++) {
+   sprintf(buffer, "%02u", i);
+   dev_attr_netvsc_dev_attrs[i].attr.name =
+   kstrdup(buffer, GFP_KERNEL);
+   dev_attr_netvsc_dev_attrs[i].attr.mode = 0444;
+   sysfs_attr_init(_attr_netvsc_dev_attrs[i].attr);
+
+   dev_attr_netvsc_dev_attrs[i].show = tx_indirection_show;
+   dev_attr_netvsc_dev_attrs[i].store = NULL;
+   netvsc_dev_attrs[i] = _attr_netvsc_dev_attrs[i].attr;
+   }
+   netvsc_dev_attrs[VRSS_SEND_TAB_SIZE] = NULL;
+}
+
+static void netvsc_attrs_exit(void)
+{
+   int i;
+
+   for (i = 0; i < VRSS_SEND_TAB_SIZE; i++)
+   kfree(dev_attr_netvsc_dev_attrs[i].attr.name);
+}
+
 static int netvsc_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
 {
@@ -2410,6 +2455,7 @@ static int netvsc_probe(struct hv_device *dev,
 
net->netdev_ops = _ops;
net->ethtool_ops = _ops;
+   net->sysfs_groups[0] = _dev_group;
SET_NETDEV_DEV(net, >device);
 
/* We always need headroom for rndis header */
@@ -2665,6 +2711,7 @@ static void __exit netvsc_drv_exit(void)
 {
unregister_netdevice_notifier(_netdev_notifier);
vmbus_driver_unregister(_drv);
+   netvsc_attrs_exit();
 }
 
 static int __init netvsc_drv_init(void)
@@ -2678,6 +2725,8 @@ static int __init netvsc_drv_init(void)
}
netvsc_ring_bytes = ring_size * PAGE_SIZE;
 
+   netvsc_attrs_init();
+
ret = vmbus_driver_register(_drv);
if (ret)
return ret;
-- 
2.25.1

[PATCH v3] hwmon: adm1272: Enable temperature sampling for adm1272 adm1278

[Chu Lin]

Problem:
adm1272 and adm1278 supports temperature sampling. The
current way of enabling it requires the user manually unbind the device
from the driver, flip the temperature sampling control bit and then bind
the device back to the driver. It would be nice if we can control this in a
better way by reading the dt.

Solution:
Introducing device tree binding analog,temp1-enable. If the
flag is set, flip the temp1_en control bit on probing.

Testing:
1). iotools smbus_write16 35 0x10 0xd4 0x0037 // disable the temp1_en
2). recompile the dt to have  analog,temp1-enable set
3). Probe the driver and make sure tempX shows up in hwmon

Signed-off-by: Chu Lin 
---
ChangeLog v1->v2:
 - Rename adm1272-adm1278-temp1-en to analog-temperature1-enable

ChangeLog v2->v3:
 - Rename analog-temperature1-enable analog,temp1-enable

 drivers/hwmon/pmbus/adm1275.c | 36 +--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 19317575d1c6..0482670281bd 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -475,6 +475,7 @@ static int adm1275_probe(struct i2c_client *client,
const struct coefficients *coefficients;
int vindex = -1, voindex = -1, cindex = -1, pindex = -1;
int tindex = -1;
+   bool temp1_en;
u32 shunt;
 
if (!i2c_check_functionality(client->adapter,
@@ -536,6 +537,9 @@ static int adm1275_probe(struct i2c_client *client,
if (shunt == 0)
return -EINVAL;
 
+   temp1_en = of_property_read_bool(client->dev.of_node, 
"analog,temp1-enable") &&
+   (mid->driver_data == adm1272 || mid->driver_data == adm1278);
+
data->id = mid->driver_data;
 
info = >info;
@@ -614,16 +618,18 @@ static int adm1275_probe(struct i2c_client *client,
info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
 
+   ret = config;
+   /* Enable temp if it is instructed by dt (it is disabled by 
default) */
+   if (temp1_en && !(config & ADM1278_TEMP1_EN))
+   config |= ADM1278_TEMP1_EN;
/* Enable VOUT if not enabled (it is disabled by default) */
-   if (!(config & ADM1278_VOUT_EN)) {
+   if (!(config & ADM1278_VOUT_EN))
config |= ADM1278_VOUT_EN;
-   ret = i2c_smbus_write_byte_data(client,
-   ADM1275_PMON_CONFIG,
-   config);
+   if (ret != config) {
+   ret = i2c_smbus_write_word_data(client, 
ADM1275_PMON_CONFIG, config);
if (ret < 0) {
-   dev_err(>dev,
-   "Failed to enable VOUT monitoring\n");
-   return -ENODEV;
+   dev_err(>dev, "Failed to enable config 
control bits");
+   return ret;
}
}
 
@@ -685,16 +691,18 @@ static int adm1275_probe(struct i2c_client *client,
info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
 
+   ret = config;
+   /* Enable temp if it is instructed by dt (it is disabled by 
default) */
+   if (temp1_en && !(config & ADM1278_TEMP1_EN))
+   config |= ADM1278_TEMP1_EN;
/* Enable VOUT if not enabled (it is disabled by default) */
-   if (!(config & ADM1278_VOUT_EN)) {
+   if (!(config & ADM1278_VOUT_EN))
config |= ADM1278_VOUT_EN;
-   ret = i2c_smbus_write_byte_data(client,
-   ADM1275_PMON_CONFIG,
-   config);
+   if (ret != config) {
+   ret = i2c_smbus_write_word_data(client, 
ADM1275_PMON_CONFIG, config);
if (ret < 0) {
-   dev_err(>dev,
-   "Failed to enable VOUT monitoring\n");
-   return -ENODEV;
+   dev_err(>dev, "Failed to enable config 
control bits");
+   return ret;
}
}
 
-- 
2.28.0.rc0.105.gf9edc3c819-goog

[PATCH v3] dt-bindings: hwmon: adm1272: add analog,temp1-enable binding

[Chu Lin]

Problem:
adm1272 and adm1278 supports temperature sampling. The
current way of enabling it requires the user manually unbind the device
from the driver, flip the temperature sampling control bit and then bind
the device back to the driver. It would be nice if we can control this in a
better way by reading the dt.

Solution:
Introducing device tree binding analog,temp1-enable. If the
flag is set, flip the temp1_en control bit on probing.

Testing:
make dt_binding_check

Signed-off-by: Chu Lin 
---
ChangeLog v1->v2:
 - Rename adm1272-adm1278-temp1-en to analog-temperature1-enable

ChangeLog v2->v3:
 - Rename analog-temperature1-enable analog,temp1-enable

 Documentation/devicetree/bindings/hwmon/adm1275.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/adm1275.txt 
b/Documentation/devicetree/bindings/hwmon/adm1275.txt
index 1ecd03f3da4d..22ca5a321d5c 100644
--- a/Documentation/devicetree/bindings/hwmon/adm1275.txt
+++ b/Documentation/devicetree/bindings/hwmon/adm1275.txt
@@ -15,6 +15,8 @@ Optional properties:
 
 - shunt-resistor-micro-ohms
Shunt resistor value in micro-Ohm
+- analog,temp1-enable
+   Enable temperature sampling. This is supported on adm1272 and adm1278
 
 Example:
 
@@ -22,4 +24,5 @@ adm1272@10 {
compatible = "adi,adm1272";
reg = <0x10>;
shunt-resistor-micro-ohms = <500>;
+   analog,temp1-enable;
 };
-- 
2.28.0.rc0.105.gf9edc3c819-goog

[PATCH 2/2] ASoC: bindings: fsl-asoc-card: Support properties for configuring dai fmt

[Shengjiu Wang]

In order to support configuring dai fmt through DT, add some properties.
These properiese are same as the properties in simple card.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt 
b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 8a6a3d0fda5e..63ebf52b43e8 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -71,6 +71,11 @@ Optional properties:
 
   - hp-det-gpio: The GPIO that detect headphones are plugged in
   - mic-det-gpio   : The GPIO that detect microphones are plugged in
+  - bitclock-master: Indicates dai-link bit clock master; for details see 
simple-card.yaml.
+  - frame-master   : Indicates dai-link frame master; for details see 
simple-card.yaml.
+  - dai-format : audio format, for details see simple-card.yaml.
+  - frame-inversion: dai-link uses frame clock inversion, for details see 
simple-card.yaml.
+  - bitclock-inversion : dai-link uses bit clock inversion, for details see 
simple-card.yaml.
 
 Optional unless SSI is selected as a CPU DAI:
 
-- 
2.27.0

[PATCH 1/2] ASoC: fsl-asoc-card: Support configuring dai fmt from DT

[Shengjiu Wang]

Support same propeties as simple card for configuring fmt
from DT.
In order to make this change compatible with old DT, these
properties are optional.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl-asoc-card.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index ee80d02b56c6..4848ba61d083 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -531,11 +531,14 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
struct device_node *cpu_np, *codec_np, *asrc_np;
struct device_node *np = pdev->dev.of_node;
struct platform_device *asrc_pdev = NULL;
+   struct device_node *bitclkmaster = NULL;
+   struct device_node *framemaster = NULL;
struct platform_device *cpu_pdev;
struct fsl_asoc_card_priv *priv;
struct device *codec_dev = NULL;
const char *codec_dai_name;
const char *codec_dev_name;
+   unsigned int daifmt;
u32 width;
int ret;
 
@@ -667,6 +670,31 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
goto asrc_fail;
}
 
+   /* Format info from DT is optional. */
+   daifmt = snd_soc_of_parse_daifmt(np, NULL,
+, );
+   daifmt &= ~SND_SOC_DAIFMT_MASTER_MASK;
+   if (bitclkmaster || framemaster) {
+   if (codec_np == bitclkmaster)
+   daifmt |= (codec_np == framemaster) ?
+   SND_SOC_DAIFMT_CBM_CFM : SND_SOC_DAIFMT_CBM_CFS;
+   else
+   daifmt |= (codec_np == framemaster) ?
+   SND_SOC_DAIFMT_CBS_CFM : SND_SOC_DAIFMT_CBS_CFS;
+
+   /* Override dai_fmt with value from DT */
+   priv->dai_fmt = daifmt;
+   }
+
+   /* Change direction according to format */
+   if (priv->dai_fmt & SND_SOC_DAIFMT_CBM_CFM) {
+   priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_IN;
+   priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_IN;
+   }
+
+   of_node_put(bitclkmaster);
+   of_node_put(framemaster);
+
if (!fsl_asoc_card_is_ac97(priv) && !codec_dev) {
dev_err(>dev, "failed to find codec device\n");
ret = -EPROBE_DEFER;
-- 
2.27.0

Re: [PATCH v2] scsi: scsi_transport_sas: add missing newline when printing 'enable' by sysfs

[Martin K. Petersen]

On Fri, 17 Jul 2020 16:44:32 +0800, Xiongfeng Wang wrote:

> When I cat sysfs file 'enable' below 'sas_phy', it displays as follows.
> It's better to add a newline for easy reading.
> 
> [root@localhost ~]# cat 
> /sys/devices/pci:00/:00:0d.0/:0f:00.0/host3/phy-3:2/sas_phy/phy-3:2/enable
> 1[root@localhost ~]#

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: scsi_transport_sas: Add missing newline in sysfs 'enable' attribute
  https://git.kernel.org/mkp/scsi/c/38364267251f

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v3] smp: Fix a potential usage of stale nr_cpus

[Muchun Song]

When the cmdline of "nr_cpus" is not valid, the @nr_cpu_ids is assigned
a stale value. The nr_cpus is only valid when get_option() return 1. So
check the return value to prevent this.

Signed-off-by: Muchun Song 
---
changelog in v3:
 1) Return -EINVAL when the parameter is bogus. 

changelog in v2:
 1) Rework the commit log.
 2) Rework the return value check.

 kernel/smp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index a5a66fc28f4e..0dacfcfcf00b 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -772,9 +772,13 @@ static int __init nrcpus(char *str)
 {
int nr_cpus;
 
-   get_option(, _cpus);
+   if (get_option(, _cpus) != 1)
+   return -EINVAL;
+
if (nr_cpus > 0 && nr_cpus < nr_cpu_ids)
nr_cpu_ids = nr_cpus;
+   else
+   return -EINVAL;
 
return 0;
 }
-- 
2.11.0

Re: [PATCH] SCSI: scsi_transport_iscsi.h: drop a duplicated word

[Martin K. Petersen]

On Sat, 18 Jul 2020 17:32:32 -0700, Randy Dunlap wrote:

> Drop the repeated word "the" in a comment.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: scsi_transport_iscsi: Drop a duplicated word
  https://git.kernel.org/mkp/scsi/c/05b18b1eb3eb

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3 4/4] bus: mhi: clients: Add user space client interface driver

[Hemant Kumar]

Hi Mani,

On 6/19/20 3:40 AM, Manivannan Sadhasivam wrote:

On Thu, Jun 11, 2020 at 11:13:44AM -0700, Hemant Kumar wrote:

This MHI client driver allows user space clients to transfer
data between MHI device and host using standard file operations.


I think we need to explicitly specify 'raw' data here. Because we have different
APIs for queuing different types of data. So saying just data sounds vague
unless this driver can handle multiple types of data which I don't think can
happen.

And you need to update the same in docs.

Done.



Device file node is created with format

/dev/mhi__

Currently it supports loopback client.

Signed-off-by: Hemant Kumar 
---
  drivers/bus/mhi/Kconfig  |   2 +
  drivers/bus/mhi/Makefile |   1 +
  drivers/bus/mhi/clients/Kconfig  |  16 +
  drivers/bus/mhi/clients/Makefile |   3 +
  drivers/bus/mhi/clients/uci.c| 652 +++
  5 files changed, 674 insertions(+)
  create mode 100644 drivers/bus/mhi/clients/Kconfig
  create mode 100644 drivers/bus/mhi/clients/Makefile
  create mode 100644 drivers/bus/mhi/clients/uci.c

diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index 6a217ff..f224be8 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,5 @@ config MHI_BUS_DEBUG
 Enable debugfs support for use with the MHI transport. Allows
 reading and/or modifying some values within the MHI controller
 for debug and test purposes.


Hmm, so this patchset depends on debugfs patches? You need to mention this in
cover letter. Or even better, just make it independent

Driver does not depend on debugfs. i need to fix that.




+
+source "drivers/bus/mhi/clients/Kconfig"
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..48f6028 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,3 @@
  # core layer
  obj-y += core/
+obj-y += clients/
diff --git a/drivers/bus/mhi/clients/Kconfig b/drivers/bus/mhi/clients/Kconfig
new file mode 100644
index 000..cd84419
--- /dev/null
+++ b/drivers/bus/mhi/clients/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "MHI clients support"
+   depends on MHI_BUS


I don't think we need MHI_BUS dependency here.
Reason i added was, if MHI BUS is not enabled "MHI clients support" 
would not show up in the menu.



+
+config MHI_UCI
+   tristate "MHI UCI"
+   depends on MHI_BUS
+   help
+ MHI based userspace client interface driver is for transferring


s/is for/used for/g. Also provide indent for help text.

Done.



+ data between host and device using standard file operations from
+ user space. Open, read, write, and close operations are supported


Please use 'userspace' everywhere.

Done.



+ by this driver. Please check mhi_uci_match_table for all supported
+ channels that are exposed to userspace.
+
+endmenu
diff --git a/drivers/bus/mhi/clients/Makefile b/drivers/bus/mhi/clients/Makefile
new file mode 100644
index 000..dd2930c
--- /dev/null
+++ b/drivers/bus/mhi/clients/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_MHI_UCI) +=uci.o


space after '+='

Done.



diff --git a/drivers/bus/mhi/clients/uci.c b/drivers/bus/mhi/clients/uci.c
new file mode 100644
index 000..8f36fb0
--- /dev/null
+++ b/drivers/bus/mhi/clients/uci.c
@@ -0,0 +1,652 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include 
+#include 
+#include 
+#include 


Please sort includes alphabetically.

you mean like this
#include 
#include 
#include 
#include 




+#include 
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_DEVICES (64)
+


How about the kdoc comments for all fields and structures used?

Done.



+struct uci_chan {
+   wait_queue_head_t wq;
+
+   /* locks ul/dl uci device channel */
+   spinlock_t lock;


It seems like you are trying to protect a field (enabled) in parent structure
(uci_dev) using this lock. This sounds weird. Why can't you just use the mutex
present in that?

i agree, let me fix locking in the entire driver.



+
+/* user space waiting to read */


The comments should clearly portray what the field is for.

list of pending read buffers ?



+   struct list_head pending;
+
+/* current buffer user space reading */


This sentence is not correct.

current buffer user space is reading ?



+   struct uci_buf *cur_buf;
+   size_t rx_size;
+};
+
+struct uci_buf {
+   void *data;
+   size_t len;
+   struct list_head node;
+};
+
+struct mhi_uci_drv {
+   struct list_head head;
+
+   /* uci driver lock to sync open, probe and remove */
+   struct mutex lock;
+   struct class *class;
+   int major;
+   dev_t dev_t;


devt?

will rename it to devt



+};
+
+struct uci_dev {
+   struct 

linux-next: build warning after merge of the backlight tree

[Stephen Rothwell]

Hi all,

After merging the backlight tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/video/backlight/cr_bllcd.c: In function 'cr_backlight_set_intensity':
drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable 'intensity' 
[-Wunused-variable]
   62 |  int intensity = bd->props.brightness;
  |  ^

Introduced by commit

  24d34617c24f ("backlight: cr_bllcd: Introduce gpio-backlight semantics")

-- 
Cheers,
Stephen Rothwell


pgpfupB5L70Iu.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom: Add msm8226 pinctrl bindings

[Rob Herring]

On Thu, 16 Jul 2020 22:55:28 +0200, Bartosz Dudziak wrote:
> Add device tree binding Documentation details for Qualcomm msm8226
> pinctrl driver.
> 
> - Bindings documentation was based on qcom,ipq6018-pinctrl.yaml added by
>   Sricharan R  and then modified for msm8226
>   content
> 
> Signed-off-by: Bartosz Dudziak 
> ---
>  .../pinctrl/qcom,msm8226-pinctrl.yaml | 132 ++
>  1 file changed, 132 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
> 

Reviewed-by: Rob Herring 

Re: [PATCH 16/20] dt-bindings: media: renesas,csi2: Add R8A774E1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:31 +0100, Lad Prabhakar wrote:
> Add the compatible string for RZ/G2H (R8A774E1) to the list of supported
> SoCs.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/media/renesas,csi2.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH] clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4

[Sekhar Nori]

On 7/20/20 8:00 PM, Tony Lindgren wrote:
> * Carlos Hernandez  [200717 21:35]:
>> On 7/17/20 6:29 AM, Daniel Lezcano wrote:
>>> On 13/07/2020 18:26, Tony Lindgren wrote:
 Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
 clocksource support")
 Reported-by: Carlos Hernandez 
 Signed-off-by: Tony Lindgren 
 ---
>>> Carlos, were you able to test this patch ?
>>
>> Tested the patch on top of 5.8-rc5.
>>
>> cbdb2617290d (HEAD) clocksource/drivers/timer-ti-dm: Fix suspend and resume
>> for am3 and am4
>> 11ba468877bb (tag: v5.8-rc5) Linux 5.8-rc5
>>
>> It works on am335x-evm but fails on am437x-evm
> 
> Thanks for testing.
> 
>> am4:
>>
>> ** 1196 printk messages dropped **
> 
> The above does not look normal..
> 
>> 4400.ocp:L3 Custom Error: MASTER DSS TARGET GPMC (Read)
>> ** 34 printk messages dropped **
> 
> ..but the above points to the GPMC module failing to suspend.
> This seems to be some other GPMC specific issue not related
> to the system timers.

So, I guess this patch can still go into v5.8 while the AM437x GP EVM
failures are root caused.

Carlos, Daniel is looking for your tested by. Can you send it because it
fixes the original problem report with dmtimer?

Thanks,
Sekhar

Re: [PATCH 17/20] dt-bindings: media: renesas,vin: Add R8A774E1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:32 +0100, Lad Prabhakar wrote:
> Document support for the VIN module in the Renesas RZ/G2H (R8A774E1) SoC.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/media/renesas,vin.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 11/20] dt-bindings: usb: renesas,usbhs: Add r8a774e1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:26 +0100, Lad Prabhakar wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 07/20] dt-bindings: usb: renesas, usb3-peri: Document r8a774e1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:22 +0100, Lad Prabhakar wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 08/20] dt-bindings: usb: usb-xhci: Document r8a774e1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:23 +0100, Lad Prabhakar wrote:
> Document r8a774e1 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen3-xhci", therefore no driver
> change is needed.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 01/20] dt-bindings: pci: rcar-pci: Add device tree support for r8a774e1

[Rob Herring]

On Thu, 16 Jul 2020 18:18:16 +0100, Lad Prabhakar wrote:
> Add PCIe support for the RZ/G2H (a.k.a. R8A774E1).
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 03/20] dt-bindings: ata: renesas, rcar-sata: Add r8a774e1 support

[Rob Herring]

On Thu, 16 Jul 2020 18:18:18 +0100, Lad Prabhakar wrote:
> Document SATA support for the RZ/G2H, no driver change required.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH v2 1/4] mm/page_alloc: fix non cma alloc context

[Joonsoo Kim]

2020년 7월 21일 (화) 오전 8:23, Andrew Morton 님이 작성:
>
> On Mon, 20 Jul 2020 13:56:15 +0900 js1...@gmail.com wrote:
>
> > Currently, preventing cma area in page allocation is implemented by using
> > current_gfp_context(). However, there are two problems of this
> > implementation.
> >
> > First, this doesn't work for allocation fastpath. In the fastpath,
> > original gfp_mask is used since current_gfp_context() is introduced in
> > order to control reclaim and it is on slowpath.
> > Second, clearing __GFP_MOVABLE has a side effect to exclude the memory
> > on the ZONE_MOVABLE for allocation target.
> >
> > To fix these problems, this patch changes the implementation to exclude
> > cma area in page allocation. Main point of this change is using the
> > alloc_flags. alloc_flags is mainly used to control allocation so it fits
> > for excluding cma area in allocation.
> >
> > Fixes: d7fefcc8de91 (mm/cma: add PF flag to force non cma alloc)
> > Cc: 
>
> This patch is against linux-next (or -mm) and has a lot of issues
> applying to mainline.  If we indeed wish to backport it to -stable, it
> should be against mainline, please.

I sent a revised patch against the mainline a minute ago. Subject and commit
description is updated.

Thanks.

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

[Rob Herring]

On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
> and 6.18 inches size. It is found in some of the Poco F1 phones.
> 
> Signed-off-by: Sumit Semwal 
> ---
>  .../display/panel/tianma,nt36672a.yaml| 110 ++
>  1 file changed, 110 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
> b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> new file mode 100644
> index ..3c583ca926ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tianma model NT36672A DSI Panel display driver
> +
> +maintainers:
> +  - Sumit Semwal 
> +
> +description: |
> +  The nt36672a panel from Tianma is a FHD+ LCD display panel with a 
> resolution
> +  of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: tianma,nt36672a
> +
> +  reg:
> +description: DSI virtual channel of the peripheral
> +
> +  reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> +  can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> +  vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> +  Power IC supply
> +
> +  vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> +  vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> +  pinctrl-names:
> +description: Pinctrl for panel active and suspend
> +
> +  pinctrl-0:
> +description: Active pinctrls
> +
> +  pinctrl-1:
> +description: Suspend pinctrls

I think the pinctrl should go in the DSI controller node, not the 
display unless it is settings for 'reset-gpios'.

> +
> +  ports:
> +type: object
> +properties:
> +  port@0:
> +type: object
> +description: DSI input port driven by master DSI
> +properties:
> +  reg:
> +const: 0
> +
> +required:
> +  - reg

For a single port, you can do just 'port' (without ports node).

> +
> +required:
> +  - compatible
> +  - reg
> +  - vddi0-supply
> +  - vddpos-supply
> +  - vddneg-supply
> +  - reset-gpios
> +  - pinctrl-names
> +  - pinctrl-0
> +  - pinctrl-1
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +dsi0 {

dsi {

> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  panel@0 {
> +compatible = "tianma,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +pinctrl-names = "panel_active", "panel_suspend";
> +pinctrl-0 = <_dsi_active>;
> +pinctrl-1 = <_dsi_suspend>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +tianma_nt36672a_in_0: endpoint {
> +  remote-endpoint = <_out>;
> +};
> +  };
> +};
> +  };
> +};
> +
> +...
> -- 
> 2.27.0
> 

Re: [PATCH v2 3/3] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

[Xu Yilun]

On Fri, Jul 17, 2020 at 10:45:42AM +0100, Lee Jones wrote:
> On Thu, 16 Jul 2020, Xu Yilun wrote:
> 
> > This patch implements the basic functions of the BMC chip for some Intel
> > FPGA PCIe Acceleration Cards (PAC). The BMC is implemented using the
> > intel max10 CPLD.
> > 
> > This BMC chip is connected to FPGA by a SPI bus. To provide reliable
> > register access from FPGA, an Avalon Memory-Mapped (Avmm) transaction
> > protocol over the SPI bus is used between host and slave.
> > 
> > This driver implements the basic register access using the
> > regmap-spi-avmm. The mfd cells array is empty now as a placeholder.
> > 
> > Signed-off-by: Xu Yilun 
> > Signed-off-by: Wu Hao 
> > Signed-off-by: Matthew Gerlach 
> > Signed-off-by: Russ Weight 
> > Signed-off-by: Tom Rix 
> > ---
> > v2: Split out the regmap-spi-avmm part.
> > Rename the file intel-m10-bmc-main.c to intel-m10-bmc.c, cause
> >  there is only one source file left for this module now.
> > ---
> >  .../ABI/testing/sysfs-driver-intel-m10-bmc |  15 ++
> >  drivers/mfd/Kconfig|  13 ++
> >  drivers/mfd/Makefile   |   2 +
> >  drivers/mfd/intel-m10-bmc.c| 174 
> > +
> >  include/linux/mfd/intel-m10-bmc.h  |  57 +++
> >  5 files changed, 261 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
> >  create mode 100644 drivers/mfd/intel-m10-bmc.c
> >  create mode 100644 include/linux/mfd/intel-m10-bmc.h
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc 
> > b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
> > new file mode 100644
> > index 000..54cf5bc
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
> > @@ -0,0 +1,15 @@
> > +What:  /sys/bus/spi/devices/.../bmc_version
> 
> Why is this in your MFD patch?
> 
> Again, this looks like it's documenting a SPI device?

The intel-m10-bmc device is a spi device, which contains several sub
devices in it, and I use the mfd APIs for subdev creating.
I see some example drivers in mfd folder which also match a spi/i2c parent
device and creates the sub devices. So I think I may follow the examples
and put the intel-m10-bmc driver in mfd folder.

A little difference is that the driver added 2 sysfs nodes for the
parent device itself. I'm not sure how I should document the sysfs path
correctly. The device is a mfd parent, but I didn't find a sysfs path that
could explicitly indicate its role of mfd parent.

Do you have any suggestion on that?

> 
> > +Date:  June 2020
> > +KernelVersion: 5.9
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the hardware build version of Intel
> > +   MAX10 BMC chip.
> > +   Format: "0x%x".
> > +
> > +What:  /sys/bus/spi/devices/.../bmcfw_version
> > +Date:  June 2020
> > +KernelVersion: 5.9
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the firmware version of Intel MAX10
> > +   BMC chip.
> > +   Format: "0x%x".
> 
> [...]
> 
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index d13bb0a..42252c8 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -2130,5 +2130,18 @@ config SGI_MFD_IOC3
> >   If you have an SGI Origin, Octane, or a PCI IOC3 card,
> >   then say Y. Otherwise say N.
> >  
> > +config MFD_INTEL_M10_BMC
> > +   tristate "Intel MAX10 board management controller"
> 
> "Board Management Controller"

Yes, I'll change it.

> 
> > +   depends on SPI_MASTER
> > +   select REGMAP_SPI_AVMM
> > +   select MFD_CORE
> > +   help
> > + Support for the Intel MAX10 board management controller using the
> > + SPI interface.
> > +
> > + This driver provides common support for accessing the device,
> > + additional drivers must be enabled in order to use the functionality
> > + of the device.
> > +
> >  endmenu
> >  endif
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 1c8d6be..149d7d1 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -265,3 +265,5 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o
> >  obj-$(CONFIG_MFD_KHADAS_MCU)   += khadas-mcu.o
> >  
> >  obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> > +
> > +obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
> > diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> > new file mode 100644
> > index 000..0d5e5d6
> > --- /dev/null
> > +++ b/drivers/mfd/intel-m10-bmc.c
> > @@ -0,0 +1,174 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Intel Max10 Board Management Controller chip Driver
> 
> Drop "Driver"

Yes

> 
> > + * Copyright (C) 2018-2020 Intel Corporation. All rights reserved.
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> 

Re: [PATCH v3 0/4] regulator_sync_state() support

[Saravana Kannan]

On Wed, Jul 15, 2020 at 9:20 PM Saravana Kannan  wrote:
>
> Consider the following example:
> - regulator-X is provided by device-X.
> - regulator-X is a supplier to device-A, device-B and device-C.
> - device-A is off/inactive from boot.
> - device-B and device-C are left on/active by the bootloader
> - regulator-X is left on boot by the bootloader at 2000 mV to supply
>   device-B and device-C.
>
> Example boot sequence 1:
> 1. device-X is probed successfully.
> 2. device-A is probed by driver-A
>a. driver-A gets regulator-X
>b. driver-A votes on regulator-X
>c. driver-A initializes device-A
>d. driver-A votes off regulator-X
>e. regulator-X is turned off.
> 3. System crashes or device-B and device-C become unreliable because
>regulator-X was turned off without following the proper quiescing
>steps for device-B and device-C.
>
> Example boot sequence 2:
> 1. device-X is probed successfully.
> 2. device-B is probed by driver-B
>a. driver-B gets regulator-X
>b. driver-B votes on regulator-X
>c. driver-B lowers device-B performance point.
>d. driver-B lowers voltage vote to 1000 mV.
>e. regulator-X voltage is lowered to 1000 mV.
> 3. System crashes or device-C becomes unreliable because regulator-X
>voltage was lowered to 1000 mV when device-C still needed it at 2000 mV

Marek,

I'd appreciate it if you could test this series to see if it fixes
your coupled regulator issue that you reported earlier. I'm expecting
it to fix it without needing any special case handling in your
regulator drivers. But it'll be good to get confirmation from you.

Thanks,
Saravana

[PATCH] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs

[js1304]

From: Joonsoo Kim 

Currently, memalloc_nocma_{save/restore} API that prevents CMA area
in page allocation is implemented by using current_gfp_context(). However,
there are two problems of this implementation.

First, this doesn't work for allocation fastpath. In the fastpath,
original gfp_mask is used since current_gfp_context() is introduced in
order to control reclaim and it is on slowpath. So, CMA area can be
allocated through the allocation fastpath even if
memalloc_nocma_{save/restore} APIs are used. Currently, there is just
one user for these APIs and it has a fallback method to prevent actual
problem.
Second, clearing __GFP_MOVABLE in current_gfp_context() has a side effect
to exclude the memory on the ZONE_MOVABLE for allocation target.

To fix these problems, this patch changes the implementation to exclude
CMA area in page allocation. Main point of this change is using the
alloc_flags. alloc_flags is mainly used to control allocation so it fits
for excluding CMA area in allocation.

Fixes: d7fefcc8de91 (mm/cma: add PF flag to force non cma alloc)
Cc: 
Signed-off-by: Joonsoo Kim 
---
 include/linux/sched/mm.h |  8 +---
 mm/page_alloc.c  | 33 +++--
 2 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 480a4d1..17e0c31 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -177,12 +177,10 @@ static inline bool in_vfork(struct task_struct *tsk)
  * Applies per-task gfp context to the given allocation flags.
  * PF_MEMALLOC_NOIO implies GFP_NOIO
  * PF_MEMALLOC_NOFS implies GFP_NOFS
- * PF_MEMALLOC_NOCMA implies no allocation from CMA region.
  */
 static inline gfp_t current_gfp_context(gfp_t flags)
 {
-   if (unlikely(current->flags &
-(PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS | 
PF_MEMALLOC_NOCMA))) {
+   if (unlikely(current->flags & (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS))) {
/*
 * NOIO implies both NOIO and NOFS and it is a weaker context
 * so always make sure it makes precedence
@@ -191,10 +189,6 @@ static inline gfp_t current_gfp_context(gfp_t flags)
flags &= ~(__GFP_IO | __GFP_FS);
else if (current->flags & PF_MEMALLOC_NOFS)
flags &= ~__GFP_FS;
-#ifdef CONFIG_CMA
-   if (current->flags & PF_MEMALLOC_NOCMA)
-   flags &= ~__GFP_MOVABLE;
-#endif
}
return flags;
 }
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e028b87c..08cb35c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2790,7 +2790,7 @@ __rmqueue(struct zone *zone, unsigned int order, int 
migratetype,
 * allocating from CMA when over half of the zone's free memory
 * is in the CMA area.
 */
-   if (migratetype == MIGRATE_MOVABLE &&
+   if (alloc_flags & ALLOC_CMA &&
zone_page_state(zone, NR_FREE_CMA_PAGES) >
zone_page_state(zone, NR_FREE_PAGES) / 2) {
page = __rmqueue_cma_fallback(zone, order);
@@ -2801,7 +2801,7 @@ __rmqueue(struct zone *zone, unsigned int order, int 
migratetype,
 retry:
page = __rmqueue_smallest(zone, order, migratetype);
if (unlikely(!page)) {
-   if (migratetype == MIGRATE_MOVABLE)
+   if (alloc_flags & ALLOC_CMA)
page = __rmqueue_cma_fallback(zone, order);
 
if (!page && __rmqueue_fallback(zone, order, migratetype,
@@ -3671,6 +3671,20 @@ alloc_flags_nofragment(struct zone *zone, gfp_t gfp_mask)
return alloc_flags;
 }
 
+static inline unsigned int current_alloc_flags(gfp_t gfp_mask,
+   unsigned int alloc_flags)
+{
+#ifdef CONFIG_CMA
+   unsigned int pflags = current->flags;
+
+   if (!(pflags & PF_MEMALLOC_NOCMA) &&
+   gfp_migratetype(gfp_mask) == MIGRATE_MOVABLE)
+   alloc_flags |= ALLOC_CMA;
+
+#endif
+   return alloc_flags;
+}
+
 /*
  * get_page_from_freelist goes through the zonelist trying to allocate
  * a page.
@@ -4316,10 +4330,8 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
 
-#ifdef CONFIG_CMA
-   if (gfp_migratetype(gfp_mask) == MIGRATE_MOVABLE)
-   alloc_flags |= ALLOC_CMA;
-#endif
+   alloc_flags = current_alloc_flags(gfp_mask, alloc_flags);
+
return alloc_flags;
 }
 
@@ -4619,8 +4631,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
order,
wake_all_kswapds(order, gfp_mask, ac);
 
reserve_flags = __gfp_pfmemalloc_flags(gfp_mask);
-   if (reserve_flags)
+   if (reserve_flags) {
alloc_flags = reserve_flags;
+   alloc_flags = current_alloc_flags(gfp_mask, alloc_flags);
+   }
 
/*
 * Reset the nodemask and zonelist iterators if memory policies 

Re: Re: [PATCH 04/21] dt-binding: mediatek: Add binding for mt8192 IOMMU and SMI

[Yong Wu]

On Mon, 2020-07-20 at 17:16 -0600, Rob Herring wrote:
> On Sat, Jul 11, 2020 at 02:48:29PM +0800, Yong Wu wrote:
> > This patch adds decriptions for mt8192 IOMMU and SMI.
> > 
> > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > table format. The M4U-SMI HW diagram is as below:
> > 
> >   EMI
> >|
> >   M4U
> >|
> >   
> >SMI Common
> >   
> >|
> >   +---+--+--+--+---+
> >   |   |  |  |   .. |   |
> >   |   |  |  |  |   |
> > larb0   larb1  larb2  larb4 ..  larb19   larb20
> > disp0   disp1   mdpvdec   IPE  IPE
> > 
> > All the connections are HW fixed, SW can NOT adjust it.
> > 
> > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > into different iova ranges:
> > 
> > domain-id  module iova-range  larbs
> >0   disp0 ~ 4G  larb0/1
> >1   vcodec  4G ~ 8G larb4/5/7
> >2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> >3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
> >4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> 
> You probably want to use dma-ranges for defining these 
> address restrictions. 

Yes. Please see the commit message of [18/21] in this patchset.

> 
> How is the domain-id used or needed?

Here we assign different larb/ports in different iova ranges.
In the iommu driver, we will list the iova ranges as above and use the
domain-id to get the detailed iova range, then create a iommu domain for
each a iova range.

For the iommu masters, it only need use its special port in its dtsi
node, then the iova got from dma_alloc_attrs for that device will locate
in the special iova ranges.

> 
> Rob 
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 0/9] arm64: Stolen time support

[zhukeqian]

Hi Steven,

On 2019/8/2 22:50, Steven Price wrote:
> This series add support for paravirtualized time for arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
> 
> https://developer.arm.com/docs/den0057/a
> 
> It implements support for stolen time, allowing the guest to
> identify time when it is forcibly not executing.
> 
> It doesn't implement support for Live Physical Time (LPT) as there are
> some concerns about the overheads and approach in the above
Do you plan to pick up LPT support? As there is demand of cross-frequency 
migration
(from older platform to newer platform).

I am not clear about the overheads and approach problem here, could you please
give some detail information? Maybe we can work together to solve these 
concerns. :-)

Thanks,
Keqian
> specification, and I expect an updated version of the specification to
> be released soon with just the stolen time parts.
> 
> I previously posted a series including LPT (as well as stolen time):
> https://lore.kernel.org/kvmarm/20181212150226.38051-1-steven.pr...@arm.com/
> 
> Patches 2, 5, 7 and 8 are cleanup patches and could be taken separately.
> 
> Christoffer Dall (1):
>   KVM: arm/arm64: Factor out hypercall handling from PSCI code
> 
> Steven Price (8):
>   KVM: arm64: Document PV-time interface
>   KVM: arm64: Implement PV_FEATURES call
>   KVM: arm64: Support stolen time reporting via shared structure
>   KVM: Allow kvm_device_ops to be const
>   KVM: arm64: Provide a PV_TIME device to user space
>   arm/arm64: Provide a wrapper for SMCCC 1.1 calls
>   arm/arm64: Make use of the SMCCC 1.1 wrapper
>   arm64: Retrieve stolen time as paravirtualized guest
> 
>  Documentation/virtual/kvm/arm/pvtime.txt | 107 +
>  arch/arm/kvm/Makefile|   2 +-
>  arch/arm/kvm/handle_exit.c   |   2 +-
>  arch/arm/mm/proc-v7-bugs.c   |  13 +-
>  arch/arm64/include/asm/kvm_host.h|  13 +-
>  arch/arm64/include/asm/kvm_mmu.h |   2 +
>  arch/arm64/include/asm/pvclock-abi.h |  20 +++
>  arch/arm64/include/uapi/asm/kvm.h|   6 +
>  arch/arm64/kernel/Makefile   |   1 +
>  arch/arm64/kernel/cpu_errata.c   |  80 --
>  arch/arm64/kernel/kvm.c  | 155 ++
>  arch/arm64/kvm/Kconfig   |   1 +
>  arch/arm64/kvm/Makefile  |   2 +
>  arch/arm64/kvm/handle_exit.c |   4 +-
>  include/kvm/arm_hypercalls.h |  44 ++
>  include/kvm/arm_psci.h   |   2 +-
>  include/linux/arm-smccc.h|  58 +++
>  include/linux/cpuhotplug.h   |   1 +
>  include/linux/kvm_host.h |   4 +-
>  include/linux/kvm_types.h|   2 +
>  include/uapi/linux/kvm.h |   2 +
>  virt/kvm/arm/arm.c   |  18 +++
>  virt/kvm/arm/hypercalls.c| 138 
>  virt/kvm/arm/mmu.c   |  44 ++
>  virt/kvm/arm/psci.c  |  84 +-
>  virt/kvm/arm/pvtime.c| 190 +++
>  virt/kvm/kvm_main.c  |   6 +-
>  27 files changed, 848 insertions(+), 153 deletions(-)
>  create mode 100644 Documentation/virtual/kvm/arm/pvtime.txt
>  create mode 100644 arch/arm64/include/asm/pvclock-abi.h
>  create mode 100644 arch/arm64/kernel/kvm.c
>  create mode 100644 include/kvm/arm_hypercalls.h
>  create mode 100644 virt/kvm/arm/hypercalls.c
>  create mode 100644 virt/kvm/arm/pvtime.c
> 

Re: [PATCH] dt-bindings: power: rockchip: Convert to json-schema

[Rob Herring]

On Wed, Jul 15, 2020 at 07:02:16PM +0200, Enric Balletbo i Serra wrote:
> Convert the soc/rockchip/power_domain.txt binding document to json-schema
> and move to the power bindings directory.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
>  .../power/rockchip,power-controller.yaml  | 154 ++
>  .../bindings/soc/rockchip/power_domain.txt| 136 
>  2 files changed, 154 insertions(+), 136 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml 
> b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> new file mode 100644
> index ..af50cf2b3e63
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip Power Domains
> +
> +maintainers:
> +  - Caesar Wang 
> +  - Heiko Stuebner 
> +
> +description: |
> +  Rockchip processors include support for multiple power domains which can be
> +  powered up/down by software based on different application scenes to save 
> power.
> +
> +  Power domains contained within power-controller node are generic power 
> domain
> +  providers documented in 
> Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +  IP cores belonging to a power domain should contain a 'power-domains'
> +  property that is a phandle for the power domain node representing the 
> domain.
> +
> +properties:
> +  power-controller:
> +type: object
> +description: List of power domains provided by this controller.
> +
> +properties:
> +  compatible:
> +enum:
> +  - rockchip,px30-power-controller
> +  - rockchip,rk3036-power-controller
> +  - rockchip,rk3066-power-controller
> +  - rockchip,rk3128-power-controller
> +  - rockchip,rk3188-power-controller
> +  - rockchip,rk3228-power-controller
> +  - rockchip,rk3288-power-controller
> +  - rockchip,rk3328-power-controller
> +  - rockchip,rk3366-power-controller
> +  - rockchip,rk3368-power-controller
> +  - rockchip,rk3399-power-controller
> +
> +  reg:
> +description: |
> +  Power domain index. Valid values are defined in:
> +  "include/dt-bindings/power/px30-power.h" - for PX30 type power 
> domain.
> +  "include/dt-bindings/power/rk3036-power.h" - for RK3036 type power 
> domain.
> +  "include/dt-bindings/power/rk3066-power.h" - for RK3066 type power 
> domain.
> +  "include/dt-bindings/power/rk3128-power.h" - for RK3128 type power 
> domain.
> +  "include/dt-bindings/power/rk3188-power.h" - for RK3188 type power 
> domain.
> +  "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power 
> domain.
> +  "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power 
> domain.
> +  "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power 
> domain.
> +  "include/dt-bindings/power/rk3366-power.h" - for RK3366 type power 
> domain.
> +  "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power 
> domain.
> +  "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power 
> domain.
> +maxItems: 1
> +
> +  clocks:
> +description: |
> +  A number of phandles to clocks that need to be enabled while power 
> domain
> +  switches state.
> +  pm_qos:
> +description: |
> +  A number of phandles to qos blocks which need to be saved and 
> restored
> +  while power domain switches state.
> +
> +  power-supply: true
> +
> +required:
> +  - compatible
> +  - reg

You need:

   additionalProperties: false

(with indentation). Then you will get a bunch of errors as you are 
missing a level of nodes. The 'power-controller' node doesn't have 
'reg' for example. You'll need to use 'patternProperties' with '^pd_'.

And to describe the nested power domains, you have to describe yet 
another level. You can do a $ref with something like:

$ref: '#/properties/power-controller/patternProperties/^pd_'

That creates a circular reference though and I'm not sure what will 
happen. :)

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +qos_iep: qos@ffa98000 {
> +compatible = "syscon";

This will generate a warning now. 'syscon' should not be used alone.

> +reg = <0x0 0xffa98000 0x0 0x20>;

[PATCH] Fix memory overwriting issue when copy an address to user space

[lebon zhou]

On Mon, Jul 20, 2020 at 11:12 PM David Laight  wrote:
>
> From: lebon zhou
> > Sent: 20 July 2020 05:35
> > To: da...@davemloft.net; k...@kernel.org
> > Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org
> > Subject: [PATCH] Fix memory overwriting issue when copy an address to user 
> > space
> >
> > When application provided buffer size less than sockaddr_storage, then
> > kernel will overwrite some memory area which may cause memory corruption,
> > e.g.: in recvmsg case, let msg_name=malloc(8) and msg_namelen=8, then
> > usually application can call recvmsg successful but actually application
> > memory get corrupted.
>
> Where?
> The copy_to_user() uses the short length provided by the user.
> There is even a comment saying that if the address is truncated
> the length returned to the user is the full length.
>
> Maybe the application is reusing the msg without re-initialising
> it properly.

It is not related with copy_to_user(), it is about move_addr_to_user()
implementation itself,
there is comment /*After copying the data up to the limit the user
specifies...*/, but the fact
is when (ulen < klen), this function will copy more content to user
buffer over than user
specifies in @ulen, this will cause the user buffer to corrupt, this
patch fixes this issue.

Re: [PATCH v4 10/10] powerpc/watchpoint: Remove 512 byte boundary

[Ravi Bangoria]

Hi Jordan,

On 7/20/20 12:24 PM, Jordan Niethe wrote:

On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
 wrote:


Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.

It looks like this change is not mentioned in ISA v3.1 Book III 9.4
Data Address Watchpoint. It could be useful to mention that in the
commit message.


Yes, ISA 3.1 Book III 9.4 has a documentation mistake and hopefully it
will be fixed in the next version of ISA. Though, this is mentioned in
ISA 3.1 change log:

  Multiple DEAW:
  Added a second Data Address Watchpoint. [H]DAR is
  set to the first byte of overlap. 512B boundary is
  removed.

I'll mention this in the commit description.


Also I wonder if could add a test for this to the ptrace-hwbreak selftest?


Yes, I already have a selftest for this in perf-hwbreak. Will send that soon.

Thanks,
Ravi

Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling

[Viresh Kumar]

On 20-07-20, 08:03, Rob Clark wrote:
> On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar  wrote:
> >
> > On 15-07-20, 08:36, Rob Clark wrote:
> > > I can take the first two into msm-next, the 3rd will need to wait
> > > until dev_pm_opp_set_bw() lands
> >
> > You can base that on a8351c12c6c7 in linux-next, I will make sure not to 
> > rebase
> > it anymore.

This was 5.8-rc1 + 2 patches for OPP. That's all.

> >
> 
> I can't really base on something newer than drm-next

But you need the OPP dependency, isn't it ?

-- 
viresh

Re: [PATCH v3 4/4] regulator: core: Add voltage support for sync_state() callbacks

[Saravana Kannan]

On Mon, Jul 20, 2020 at 7:35 AM Mark Brown  wrote:
>
> On Wed, Jul 15, 2020 at 09:20:53PM -0700, Saravana Kannan wrote:
>
> > - if (!handoff)
> > + if (!handoff) {
> >   regulator_disable(rdev->boot_limits);
> > - else
> > + regulator_set_voltage(rdev->boot_limits, 0, INT_MAX);
> > + } else {
> >   rdev->use_count--;
> > + }
> >   destroy_regulator(rdev->boot_limits);
>
> These sets should be completely redundant since they will go away when
> the regulator is destroyed, if there's an issue with that we should fix
> it rather than bodging around it.

Yeah, I was aware of this, but I thought it was clearer to have an
explicit unwinding. Since you prefer the other way around, I can drop
the set voltage.

Btw, going a tangent, why is regulator_set_voltage() not dependent on
a consumer's regulator enable request? If they don't care if the
regulator goes off, do they really care if the voltage goes lower?
What's the reason behind not tying voltage request with the enable
request?

-Saravana

Re: [PATCH v3 3/6] sh/mm: use default dummy memory_add_physaddr_to_nid()

[Pankaj Gupta]

> After making default memory_add_physaddr_to_nid in mm/memory_hotplug,
> there is no use to define a similar one in arch specific directory.
>
> Signed-off-by: Jia He 
> ---
>  arch/sh/mm/init.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
> index a70ba0fdd0b3..f75932ba87a6 100644
> --- a/arch/sh/mm/init.c
> +++ b/arch/sh/mm/init.c
> @@ -430,15 +430,6 @@ int arch_add_memory(int nid, u64 start, u64 size,
> return ret;
>  }
>
> -#ifdef CONFIG_NUMA
> -int memory_add_physaddr_to_nid(u64 addr)
> -{
> -   /* Node 0 for now.. */
> -   return 0;
> -}
> -EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> -#endif
> -
>  void arch_remove_memory(int nid, u64 start, u64 size,
> struct vmem_altmap *altmap)
>  {

Reviewed-by: Pankaj Gupta 

Re: [PATCH v3 3/4] regulator: core: Add basic enable/disable support for sync_state() callbacks

[Saravana Kannan]

On Mon, Jul 20, 2020 at 7:28 AM Mark Brown  wrote:
>
> On Wed, Jul 15, 2020 at 09:20:52PM -0700, Saravana Kannan wrote:
>
> > There are Android devices that exhibit the issue in the example where
> > regulator-X is an LDO, device-A is a camera device and device-B and
> > device-C are UFS and USB. To avoid this, they have their own downstream
> > changes to the regulator framework.
>
> Can you provide any references to these bodges?

This is the best I could dig up. The site is slow as molasses. I don't
want to focus or critique any specific vendor's downstream code
though. Providing these links just to prove that this is a real issue.

Search for "proxy" here. You'll notice how that will also need changes
to regulator header files, etc. The 4.9 kernel is the latest publicly
available version AFAIK.
https://source.codeaurora.org/quic/la/kernel/msm-4.9/plain/drivers/regulator/core.c?h=msm-4.9

As for the specific example of those devices, I'm not sure how much of
that stuff is publicly available and I don't want to deal with finding
that out.

> > 1. When a regulator is registered,
> >a. The sync_state() callback for the regulator's device is set to
> >   regulator_sync_state(). The sync_state() callback is called when
> >   all the consumers of the regulator's device have probed
> >   successfully.
>
> As I indicated on my previous review this doesn't seem OK, given that a
> huge proportion of the regulators on most systems are part of a single
> PMIC this means that devices won't be able to fully control regulators
> for the majority of the boot process, possibly quite a long time after
> userspace has started in systems where not all devices have drivers.

By default regulator_cleanup_timeout is set to 30s. So by default,
it's not going to be "possibly quite a long time". So, at worst, for
the first 30 seconds voltages can't be lowered below boot level and
regulators can't be turned off if they were left on by the boot
loader. If a consumer is not an exclusive consumer, then none of this
should break functional correctness for them and just be 30 seconds of
suboptimal power. And exclusive consumers won't have this issue.

I think the default behavior should be for functional correctness
(example in the commit text) and then go for optimization (being able
to power off regulators before 30s into boot). Even with the timeout
set, this series makes it much easier for driver developers to ensure
functional correctness instead of playing initcall chicken between the
supplier and the N consumers.

Actually on systems without all the drivers, I'd argue the correct
behavior is this patch series + regulator_cleanup_timeout=-1. This
patch series will prevent system instability/unusability (Eg: missing
display backlight driver) at the cost of power optimization. However,
to allow turning off boot on regulators in systems without all the
drivers where it happens to not cause functional correctness issues,
we have the timeout default to 30s.

> That seems unreasonably restrictive, it seems like this is shifting the
> problem around so we have this new very late init phase where we
> actually implement changes that devices asked for. Devices can work
> around it by using _get_exclusive() but that makes things more complex
> if they can also support non-exclusive use.

I agree, hacking around any issues using _get_exclusive() when they
don't really need exclusive access is not a solution.

> I don't understand the motivation for doing things this way.  Like I
> said last time it really feels like this turns the whole mechanism into
> a very complicated way of implementing a new initcall.

Treating this as a "LATER_initcall()" has several issues.
1. initcall levels set a max limit on the depth of device dependency.
Since DT devices are added at arch initcall level, that gives us about
5 levels if you ignore the _sync ones. Adding more isn't going to
scale or solve the problem because in reality, the dependencies are
much deeper.
2. Also, initcall call ordering also depends on Makefile/link
ordering. Which is fragile and error prone.
3. I know Greg hates playing initcall chicken.
4. "initcall levels" don't work for modules. The kernel initcall
levels are done by the time modules are loaded.
5. "initcall levels" don't work with deferred probing.
6. If the answer is, "have userspace tell us when all modules are
loaded" -- then we are depending on userspace for functional
correctness AND for turning off regulators. Which IMHO is worse than
this patch series.
7. If we somehow manage to add a "LATER_initcall" that doesn't have
the issues above, it has to work for all frameworks. So, it has to
come after ALL the devices in the system have probed. Not just "all
devices of a supplier". So, again, it's worse than this patch series,
at least for systems where all the drivers are present.

> >b. If the regulator is ON at boot, a BOOT-LIMITS consumer is created
> >   for the regulator and an enable vote is 

Re: [PATCH v2] dt-bindings: thermal: Get rid of thermal.txt and replace references

[Viresh Kumar]

On 20-07-20, 17:23, Amit Kucheria wrote:
> Now that we have yaml bindings for the thermal subsystem, get rid of the
> old bindings (thermal.txt).
> 
> Replace all references to thermal.txt in the Documentation with a link
> to the appropriate YAML bindings using the following search and replace
> pattern:
>  - If the reference is specific to the thermal-sensor-cells property,
>  replace with a pointer to thermal-sensor.yaml
>  - If the reference is to the cooling-cells property, replace with a
>  pointer to thermal-cooling-devices.yaml
>  - If the reference is generic thermal bindings, replace with a
>  reference to thermal*.yaml.
> 
> Signed-off-by: Amit Kucheria 
> Reviewed-by: Rob Herring 
> 
> ---
> Changes since v1:
>  - Rebase onto v.5.8-rc6 to make it apply again
>  - Fix cpufreq/nvidia,tegra20-cpufreq.txt
>  - Fix bindings/arm/freescale/fsl,scu.txt
> 
> 
>  .../bindings/cpufreq/cpufreq-dt.txt   |   3 +-
>  .../bindings/cpufreq/cpufreq-mediatek.txt |   4 +-
>  .../cpufreq/nvidia,tegra20-cpufreq.txt|   2 +-

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH v7] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl

[Daeho Jeong]

From: Daeho Jeong 

Added a new ioctl to send discard commands or/and zero out
to selected data area of a regular file for security reason.

The way of handling range.len of F2FS_IOC_SEC_TRIM_FILE:
1. Added -1 value support for range.len to secure trim the whole blocks
   starting from range.start regardless of i_size.
2. If the end of the range passes over the end of file, it means until
   the end of file (i_size).
3. ignored the case of that range.len is zero to prevent the function
   from making end_addr zero and triggering different behaviour of
   the function.

Signed-off-by: Daeho Jeong 
Reviewed-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
---
Changes in v7:
 - Polish coding style
---
Changes in v6:
 - Support zeroout for encrypted files
---
 fs/f2fs/f2fs.h |  15 
 fs/f2fs/file.c | 191 +
 2 files changed, 206 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a555377cf51f..6d0ce33ed65e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -430,6 +430,8 @@ static inline bool __has_cursum_space(struct f2fs_journal 
*journal,
_IOR(F2FS_IOCTL_MAGIC, 18, __u64)
 #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS   \
_IOR(F2FS_IOCTL_MAGIC, 19, __u64)
+#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20,  \
+   struct f2fs_sectrim_range)
 
 /*
  * should be same as XFS_IOC_GOINGDOWN.
@@ -442,6 +444,13 @@ static inline bool __has_cursum_space(struct f2fs_journal 
*journal,
 #define F2FS_GOING_DOWN_METAFLUSH  0x3 /* going down with meta flush */
 #define F2FS_GOING_DOWN_NEED_FSCK  0x4 /* going down to trigger fsck */
 
+/*
+ * Flags used by F2FS_IOC_SEC_TRIM_FILE
+ */
+#define F2FS_TRIM_FILE_DISCARD 0x1 /* send discard command */
+#define F2FS_TRIM_FILE_ZEROOUT 0x2 /* zero out */
+#define F2FS_TRIM_FILE_MASK0x3
+
 struct f2fs_gc_range {
u32 sync;
u64 start;
@@ -465,6 +474,12 @@ struct f2fs_flush_device {
u32 segments;   /* # of segments to flush */
 };
 
+struct f2fs_sectrim_range {
+   u64 start;
+   u64 len;
+   u64 flags;
+};
+
 /* for inline stuff */
 #define DEF_INLINE_RESERVED_SIZE   1
 static inline int get_extra_isize(struct inode *inode);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 521987cd8772..cc7f5670390f 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "f2fs.h"
 #include "node.h"
@@ -3759,6 +3760,193 @@ static int f2fs_reserve_compress_blocks(struct file 
*filp, unsigned long arg)
return ret;
 }
 
+static int f2fs_secure_erase(struct block_device *bdev, struct inode *inode,
+   pgoff_t off, block_t block, block_t len, u32 flags)
+{
+   struct request_queue *q = bdev_get_queue(bdev);
+   sector_t sector = SECTOR_FROM_BLOCK(block);
+   sector_t nr_sects = SECTOR_FROM_BLOCK(len);
+   int ret = 0;
+
+   if (!q)
+   return -ENXIO;
+
+   if (flags & F2FS_TRIM_FILE_DISCARD)
+   ret = blkdev_issue_discard(bdev, sector, nr_sects, GFP_NOFS,
+   blk_queue_secure_erase(q) ?
+   BLKDEV_DISCARD_SECURE : 0);
+
+   if (!ret && (flags & F2FS_TRIM_FILE_ZEROOUT)) {
+   if (IS_ENCRYPTED(inode))
+   ret = fscrypt_zeroout_range(inode, off, block, len);
+   else
+   ret = blkdev_issue_zeroout(bdev, sector, nr_sects,
+   GFP_NOFS, 0);
+   }
+
+   return ret;
+}
+
+static int f2fs_sec_trim_file(struct file *filp, unsigned long arg)
+{
+   struct inode *inode = file_inode(filp);
+   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   struct address_space *mapping = inode->i_mapping;
+   struct block_device *prev_bdev = NULL;
+   struct f2fs_sectrim_range range;
+   pgoff_t index, pg_end, prev_index = 0;
+   block_t prev_block = 0, len = 0;
+   loff_t end_addr;
+   bool to_end = false;
+   int ret = 0;
+
+   if (!(filp->f_mode & FMODE_WRITE))
+   return -EBADF;
+
+   if (copy_from_user(, (struct f2fs_sectrim_range __user *)arg,
+   sizeof(range)))
+   return -EFAULT;
+
+   if (range.flags == 0 || (range.flags & ~F2FS_TRIM_FILE_MASK) ||
+   !S_ISREG(inode->i_mode))
+   return -EINVAL;
+
+   if (((range.flags & F2FS_TRIM_FILE_DISCARD) &&
+   !f2fs_hw_support_discard(sbi)) ||
+   ((range.flags & F2FS_TRIM_FILE_ZEROOUT) &&
+IS_ENCRYPTED(inode) && f2fs_is_multi_device(sbi)))
+   return -EOPNOTSUPP;
+
+   file_start_write(filp);
+   inode_lock(inode);

Re: ioremap and dma cleanups and fixes for superh (2nd resend)

[Rich Felker]

On Mon, Jul 20, 2020 at 10:53:26AM -0400, Rich Felker wrote:
> On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Christoph!
> > 
> > On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> > >> Hello!
> > >>
> > >> I have applied Christoph's full series on top of Linus' tree and I can 
> > >> confirm that
> > >> the kernel boots fine on my SH-7785LCR board.
> > >>
> > >> Thus, for the whole series of patches:
> > >>
> > >> Tested-by: John Paul Adrian Glaubitz 
> > > 
> > > Any chance we get the patches queue up while you're all sorting out
> > > totally independent issues?
> > 
> > I would love to buy only Rich can do that. I'm fine with your patches
> > and would much appreciate if Rich could queue them up.
> > 
> > I'm also still waiting for my patch to be queued as well.
> 
> I saw it looked like this is solved and I'm going to look at it later
> today. Thanks!

I read and replied to this from my phone this morning so I was
mistaken about the context in the above reply, but I've now queued
(push still pending after some cleanup of sequence and testing)
everything I can take from this series for linux-next. Some of the
patches seem to depend on work in other maintainers' domains that need
clarification.

Rich

Re: [PATCH 08/10] dma-mapping: consolidate the NO_DMA definition in kernel/dma/Kconfig

[Rich Felker]

On Tue, Jul 14, 2020 at 02:18:54PM +0200, Christoph Hellwig wrote:
> Have a single definition that architetures can select.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/m68k/Kconfig | 4 +---
>  arch/m68k/Kconfig.machine | 1 +
>  arch/um/Kconfig   | 4 +---
>  kernel/dma/Kconfig| 3 +++
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 6ad6cdac74b3dc..8e488369a7e55a 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -17,6 +17,7 @@ config M68K
>   select HAVE_COPY_THREAD_TLS
>   select GENERIC_IRQ_SHOW
>   select GENERIC_ATOMIC64
> + select NO_DMA if !MMU && !COLDFIRE
>   select HAVE_UID16
>   select VIRT_TO_BUS
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
> @@ -60,9 +61,6 @@ config TIME_LOW_RES
>  config NO_IOPORT_MAP
>   def_bool y
>  
> -config NO_DMA
> - def_bool (MMU && SUN3) || (!MMU && !COLDFIRE)
> -
>  config ZONE_DMA
>   bool
>   default y
> diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
> index a82651d58af483..17e8c3a292d770 100644
> --- a/arch/m68k/Kconfig.machine
> +++ b/arch/m68k/Kconfig.machine
> @@ -126,6 +126,7 @@ config SUN3
>   depends on MMU
>   depends on !MMU_MOTOROLA
>   select MMU_SUN3 if MMU
> + select NO_DMA
>   select M68020
>   help
> This option enables support for the Sun 3 series of workstations
> diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> index 9318dc6d1a0cee..32c1d1945033ec 100644
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -15,6 +15,7 @@ config UML
>   select HAVE_DEBUG_KMEMLEAK
>   select HAVE_DEBUG_BUGVERBOSE
>   select HAVE_COPY_THREAD_TLS
> + select NO_DMA
>   select GENERIC_IRQ_SHOW
>   select GENERIC_CPU_DEVICES
>   select GENERIC_CLOCKEVENTS
> @@ -168,9 +169,6 @@ config MMAPPER
> This driver allows a host file to be used as emulated IO memory inside
> UML.
>  
> -config NO_DMA
> - def_bool y
> -
>  config PGTABLE_LEVELS
>   int
>   default 3 if 3_LEVEL_PGTABLES
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 1da3f44f2565b4..57533d07676f4a 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -1,5 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
> +config NO_DMA
> + bool
> +
>  config HAS_DMA
>   bool
>   depends on !NO_DMA
> -- 
> 2.26.2

This patch is outside the scope of what I can accept in arch/sh, and
the subsequent patches in the series seem to depend on it. What would
you like to do for its path upstream?

I've now picked up everything else from this series that I can.

Rich

Re: [PATCH v4 net-next] net: hyperv: Add attributes to show TX indirection table

[David Miller]

From: Chi Song 
Date: Tue, 21 Jul 2020 02:37:42 +

> +static ssize_t tx_indirection_show(struct device *dev,
> +struct device_attribute *dev_attr, char *buf)
> +{
> + struct net_device *ndev = to_net_dev(dev);
> + struct net_device_context *ndc = netdev_priv(ndev);
> + int index = dev_attr - dev_attr_netvsc_dev_attrs;

Reverse christmas tree ordering for local variables please.

> +static void netvsc_attrs_init(void)
> +{
> + int i;
> + char buffer[4];

Likewise.