Re: [PATCH] mwifiex: Add support for NL80211_ATTR_MAX_AP_ASSOC_STA

[Kalle Valo]

Pali Rohár  wrote:

> SD8997 firmware sends TLV_TYPE_MAX_CONN with struct hw_spec_max_conn to
> inform kernel about maximum number of p2p connections and stations in AP
> mode.
> 
> During initialization of SD8997 wifi chip kernel prints warning:
> 
>   mwifiex_sdio mmc0:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
> 
> This patch adds support for parsing TLV_TYPE_MAX_CONN (0x217) and sets
> appropriate cfg80211 member 'max_ap_assoc_sta' from retrieved structure.
> 
> It allows userspace to retrieve NL80211_ATTR_MAX_AP_ASSOC_STA attribute.
> 
> Signed-off-by: Pali Rohár 

Patch applied to wireless-drivers-next.git, thanks.

982d7287f8da mwifiex: Add support for NL80211_ATTR_MAX_AP_ASSOC_STA

-- 
https://patchwork.kernel.org/patch/11562835/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Patrick Williams]

Hi Guenter,

Thanks for the initial look at this.

One question for you below...

On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
> > +   /* Enable TEMP1 by default */
> > +   config |= ADM1278_TEMP1_EN;
> > +   ret = i2c_smbus_write_byte_data(client,
> > +   ADM1275_PMON_CONFIG,
> > +   config);
> > +   if (ret < 0) {
> > +   dev_err(&client->dev,
> > +   "Failed to enable temperature config\n");
> > +   return -ENODEV;
> > +   }
> 
> This can be handled in a single operation, together with ADM1278_VOUT_EN
> below. There is no need for two separate write operations.

I don't know if you noticed here but the change ends up enabling
TEMP1_EN in all cases.  Is this acceptable?  If not, do you have any
preference on how it is selected for enablement?

> > /* Enable VOUT if not enabled (it is disabled by default) */
> > if (!(config & ADM1278_VOUT_EN)) {
> > @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
> > }
> > }
> >  
> > -   if (config & ADM1278_TEMP1_EN)
> > -   info->func[0] |=
> > -   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> > if (config & ADM1278_VIN_EN)
> > info->func[0] |= PMBUS_HAVE_VIN;
> > break;
> > 
> 

-- 
Patrick Williams


signature.asc
Description: PGP signature

Re: [PATCH for-next 1/1] null_blk: force complete for timeout request

[Jens Axboe]

On 5/29/20 11:31 AM, Dongli Zhang wrote:
> The commit 7b11eab041da ("blk-mq: blk-mq: provide forced completion
> method") exports new API to force a request to complete without error
> injection.
> 
> There should be no error injection when completing a request by timeout
> handler.
> 
> Otherwise, the below would hang because timeout handler is failed.
> 
> echo 100 > /sys/kernel/debug/fail_io_timeout/probability
> echo 1000 > /sys/kernel/debug/fail_io_timeout/times
> echo 1 > /sys/block/nullb0/io-timeout-fail
> dd if=/dev/zero of=/dev/nullb0 bs=512 count=1 oflag=direct
> 
> With this patch, the timeout handler is able to complete the IO.

Applied, thanks.

-- 
Jens Axboe

Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer

[Daniel Lezcano]

On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
> 
> Update the related users to use new function and new callback from the
> Energy Model.
> 
> Acked-by: Quentin Perret 
> Signed-off-by: Lukasz Luba 

Acked-by: Daniel Lezcano 

[ ... ]


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 2/2] soc: samsung: Add simple voltage coupler for Exynos5800

[Krzysztof Kozlowski]

On Fri, May 29, 2020 at 02:49:40PM +0200, Marek Szyprowski wrote:
> Add custom voltage regulator coupler for Exynos5800 SoCs, which require
> coupling between "vdd_arm" and "vdd_int" regulators. This coupler ensures
> that coupled regulators voltage balancing is done only when clients for
> each regulator (cpufreq for "vdd_arm" and devfreq for "vdd_int") apply
> their constraints, so the voltage values don't go beyond the
> bootloader-selected operation point during the boot process. This also
> ensures proper voltage balancing if any of those drivers is missing.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/mach-exynos/Kconfig  |  1 +
>  drivers/soc/samsung/Kconfig   |  3 +
>  drivers/soc/samsung/Makefile  |  1 +
>  .../soc/samsung/exynos-regulator-coupler.c| 59 +++
>  4 files changed, 64 insertions(+)
>  create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 76838255b5fa..f185cd3d4c62 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -118,6 +118,7 @@ config SOC_EXYNOS5800
>   bool "Samsung EXYNOS5800"
>   default y
>   depends on SOC_EXYNOS5420
> + select EXYNOS_REGULATOR_COUPLER
>  
>  config EXYNOS_MCPM
>   bool
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index c7a2003687c7..264185664594 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -37,4 +37,7 @@ config EXYNOS_PM_DOMAINS
>   bool "Exynos PM domains" if COMPILE_TEST
>   depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>  
> +config EXYNOS_REGULATOR_COUPLER
> + bool "Exynos SoC Regulator Coupler" if COMPILE_TEST
> + depends on ARCH_EXYNOS || COMPILE_TEST
>  endif
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index edd1d6ea064d..ecc3a32f6406 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_EXYNOS_PMU)  += exynos-pmu.o
>  obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS) += exynos3250-pmu.o exynos4-pmu.o \
>   exynos5250-pmu.o exynos5420-pmu.o
>  obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_EXYNOS_REGULATOR_COUPLER) += exynos-regulator-coupler.o
> diff --git a/drivers/soc/samsung/exynos-regulator-coupler.c 
> b/drivers/soc/samsung/exynos-regulator-coupler.c
> new file mode 100644
> index ..54445918bd75
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-regulator-coupler.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + * Author: Marek Szyprowski 
> + *
> + * Samsung Exynos SoC voltage coupler
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int exynos_coupler_balance_voltage(struct regulator_coupler *coupler,
> +   struct regulator_dev *rdev,
> +   suspend_state_t state)
> +{
> + struct coupling_desc *c_desc = &rdev->coupling_desc;
> + int ret, cons_uV = 0, cons_max_uV = INT_MAX;
> + bool skip_coupled = false;
> +
> + /* get coupled regulator constraints */
> + ret = regulator_check_consumers(c_desc->coupled_rdevs[1], &cons_uV,
> + &cons_max_uV, state);
> + if (ret < 0)
> + return ret;
> +
> + /* skip adjusting coupled regulator if it has no constraints set yet */
> + if (cons_uV == 0)
> + skip_coupled = true;
> +
> + return regulator_do_balance_voltage(rdev, state, skip_coupled);
> +}
> +
> +static int exynos_coupler_attach(struct regulator_coupler *coupler,
> +  struct regulator_dev *rdev)
> +{
> + if (strcmp(rdev_get_name(rdev), "vdd_arm") == 0 ||
> + strcmp(rdev_get_name(rdev), "vdd_int") == 0)

Thanks for the patch!

You hard-coded specific names of regulators existing
only in DTS. They do not come from any driver nor bindings, therefore
they could change making driver unusable. Someone could add a new DTS
with different names and expect this to work as well.

You need bindings for this. Something like:
Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
But better in YAML, if possible.

Best regards,
Krzysztof

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Lukas Wunner]

On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void 
> *dev_id)
>   if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>   bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>  
> + /* check if we got interrupt enabled */
> + if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
> + return IRQ_NONE;
> +
>   /* Read as many bytes as possible from FIFO */
>   bcm2835_rd_fifo(bs);
>   /* Write as many bytes as possible to FIFO */

This definitely looks wrong.  The check whether the interrupt is enabled
should be moved *before* the conditional calls to bcm2835_rd_fifo_blind()
and bcm2835_wr_fifo_blind(), i.e. to the top of the function.

Otherwise if an interrupt is raised by another SPI controller,
this function may perform read/write accesses to the FIFO and
interfere with an ongoing transfer in DMA or poll mode.

Also, instead of performing an MMIO read, just use the "cs" variable
which was assigned at the top of the function.

The code comment should explain that the check is necessary because the
interrupt may be shared with other controllers on the BCM2711.

Finally, it would be nice if the check would be optimized away when
compiling for pre-RasPi4 products, maybe something like:

+   if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
+   return IRQ_NONE;

Thanks,

Lukas

Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support

[Andy Shevchenko]

On Fri, May 29, 2020 at 08:26:42PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 06:18:32PM +0100, Mark Brown wrote:
> > On Fri, 29 May 2020 16:11:49 +0300, Serge Semin wrote:
> > > Baikal-T1 SoC provides a DW DMA controller to perform low-speed 
> > > peripherals
> > > Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
> > > APB SSI devices embedded into the SoC. Currently the DMA-based transfers
> > > are supported by the DW APB SPI driver only as a middle layer code for
> > > Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
> > > platform DMAC device we introduced a set of patches to fix it within this
> > > series.

> As you can see it has been acked by Rob. So you can also merge it into your
> repo. Though It has to be rebased first due to the Dinh Nguyen patches
> recently merged in. Do you want me to do the rebasing?

I guess now you need to rebase it, because as I see the Dinh's patches are in
the tree as well as yours.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 06/30] KVM: SVM: always update CR3 in VMCB

[Krish Sadhukhan]

On 5/29/20 8:39 AM, Paolo Bonzini wrote:

svm_load_mmu_pgd is delaying the write of GUEST_CR3 to prepare_vmcs02


Did you mean to say enter_svm_guest_mode here ?

as
an optimization, but this is only correct before the nested vmentry.
If userspace is modifying CR3 with KVM_SET_SREGS after the VM has
already been put in guest mode, the value of CR3 will not be updated.
Remove the optimization, which almost never triggers anyway.
This was was added in commit 689f3bf21628 ("KVM: x86: unify callbacks
to load paging root", 2020-03-16) just to keep the two vendor-specific
modules closer, but we'll fix VMX too.

Fixes: 689f3bf21628 ("KVM: x86: unify callbacks to load paging root")
Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/svm/nested.c |  6 +-
  arch/x86/kvm/svm/svm.c| 16 +---
  2 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index dcac4c3510ab..8756c9f463fd 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -256,11 +256,7 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 
vmcb_gpa,
svm_set_efer(&svm->vcpu, nested_vmcb->save.efer);
svm_set_cr0(&svm->vcpu, nested_vmcb->save.cr0);
svm_set_cr4(&svm->vcpu, nested_vmcb->save.cr4);
-   if (npt_enabled) {
-   svm->vmcb->save.cr3 = nested_vmcb->save.cr3;
-   svm->vcpu.arch.cr3 = nested_vmcb->save.cr3;
-   } else
-   (void)kvm_set_cr3(&svm->vcpu, nested_vmcb->save.cr3);
+   (void)kvm_set_cr3(&svm->vcpu, nested_vmcb->save.cr3);
  
  	/* Guest paging mode is active - reset mmu */

kvm_mmu_reset_context(&svm->vcpu);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 545f63ebc720..feb96a410f2d 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3447,7 +3447,6 @@ static fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
  static void svm_load_mmu_pgd(struct kvm_vcpu *vcpu, unsigned long root)
  {
struct vcpu_svm *svm = to_svm(vcpu);
-   bool update_guest_cr3 = true;
unsigned long cr3;
  
  	cr3 = __sme_set(root);

@@ -3456,18 +3455,13 @@ static void svm_load_mmu_pgd(struct kvm_vcpu *vcpu, 
unsigned long root)
mark_dirty(svm->vmcb, VMCB_NPT);
  
  		/* Loading L2's CR3 is handled by enter_svm_guest_mode.  */

-   if (is_guest_mode(vcpu))
-   update_guest_cr3 = false;
-   else if (test_bit(VCPU_EXREG_CR3, (ulong 
*)&vcpu->arch.regs_avail))
-   cr3 = vcpu->arch.cr3;
-   else /* CR3 is already up-to-date.  */
-   update_guest_cr3 = false;
+   if (!test_bit(VCPU_EXREG_CR3, (ulong *)&vcpu->arch.regs_avail))
+   return;
+   cr3 = vcpu->arch.cr3;
}
  
-	if (update_guest_cr3) {

-   svm->vmcb->save.cr3 = cr3;
-   mark_dirty(svm->vmcb, VMCB_CR);
-   }
+   svm->vmcb->save.cr3 = cr3;
+   mark_dirty(svm->vmcb, VMCB_CR);
  }
  
  static int is_disabled(void)

Re: [PATCH net-next v2] hinic: add set_channels ethtool_ops support

[Jakub Kicinski]

On Thu, 28 May 2020 18:36:33 + Luo bin wrote:
> add support to change TX/RX queue number with ethtool -L
> 
> Signed-off-by: Luo bin 

Luo bin, your patches continue to come with Date: header being in the
past. Also suspiciously no time zone offset. Can you address this?

> +static int hinic_set_channels(struct net_device *netdev,
> +   struct ethtool_channels *channels)
> +{
> + struct hinic_dev *nic_dev = netdev_priv(netdev);
> + unsigned int count = channels->combined_count;
> + int err;
> +
> + if (!count) {
> + netif_err(nic_dev, drv, netdev,
> +   "Unsupported combined_count: 0\n");
> + return -EINVAL;
> + }

This check has been added to the core since the last version of you
patch:

/* ensure there is at least one RX and one TX channel */
if (!channels.combined_count &&
(!channels.rx_count || !channels.tx_count))
return -EINVAL;

> + netif_info(nic_dev, drv, netdev, "Set max combined queue number from %d 
> to %d\n",
> +hinic_hwdev_num_qps(nic_dev->hwdev), count);
> +
> + if (netif_running(netdev)) {
> + netif_info(nic_dev, drv, netdev, "Restarting netdev\n");
> + hinic_close(netdev);
> +
> + nic_dev->hwdev->nic_cap.num_qps = count;
> +
> + err = hinic_open(netdev);
> + if (err) {
> + netif_err(nic_dev, drv, netdev,
> +   "Failed to open netdev\n");
> + return -EFAULT;
> + }
> + } else {
> + nic_dev->hwdev->nic_cap.num_qps = count;
> + }
> +
> + return 0;
>  }

Re: Question: livepatch failed for new fork() task stack unreliable

[Josh Poimboeuf]

On Fri, May 29, 2020 at 06:10:59PM +0800, Wang ShaoBo wrote:
> Stack unreliable error is reported by stack_trace_save_tsk_reliable() when 
> trying
> to insmod a hot patch for module modification, this results in frequent 
> failures
> sometimes. We found this 'unreliable' stack is from task just fork.

For livepatch, this shouldn't actually be a failure.  The patch will
just stay in the transition state until after the fork has completed.
Which should happen in a reasonable amount of time, right?

> 1) The task was not actually scheduled to excute, at this time 
> UNWIND_HINT_EMPTY in
> ret_from_fork() has not reset unwind_hint, it's sp_reg and end field remain 
> default value
> and end up throwing an error in unwind_next_frame() when called by 
> arch_stack_walk_reliable();

Yes, this seems to be true for forked-but-not-yet-scheduled tasks.

I can look at fixing that.  I have some ORC cleanups in progress which
are related to UNWIND_HINT_EMPTY and the end of the stack.  I can add
this issue to the list of improvements.

> 2) The task has been scheduled but UNWIND_HINT_REGS not finished, at this time
> arch_stack_walk_reliable() terminates it's backtracing loop for pt_regs 
> unknown
> and return -EINVAL because it's a user task.

Hm, do you see this problem with upstream?  It seems like it should
work.  arch_stack_walk_reliable() has this:

/* Success path for user tasks */
if (user_mode(regs))
return 0;

Where exactly is the error coming from?

-- 
Josh

Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips

[Rob Herring]

On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan 
> 
> - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
>   7211 (STB version of RPi4).
> - add new property 'brcm,scb-sizes'
> - add new property 'resets'
> - add new property 'reset-names'
> - allow 'ranges' and 'dma-ranges' to have more than one item and update
>   the example to show this.
> 
> Signed-off-by: Jim Quinlan 
> ---
>  .../bindings/pci/brcm,stb-pcie.yaml   | 40 +--
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml 
> b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 8680a0f86c5a..66a7df45983d 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -14,7 +14,13 @@ allOf:
>  
>  properties:
>compatible:
> -const: brcm,bcm2711-pcie # The Raspberry Pi 4
> +items:
> +  - enum:

Don't need items here. Just change the const to enum.

> +  - brcm,bcm2711-pcie # The Raspberry Pi 4
> +  - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> +  - brcm,bcm7278-pcie # Broadcom 7278 Arm
> +  - brcm,bcm7216-pcie # Broadcom 7216 Arm
> +  - brcm,bcm7445-pcie # Broadcom 7445 Arm
>  
>reg:
>  maxItems: 1
> @@ -34,10 +40,12 @@ properties:
>- const: msi
>  
>ranges:
> -maxItems: 1
> +minItems: 1
> +maxItems: 4
>  
>dma-ranges:
> -maxItems: 1
> +minItems: 1
> +maxItems: 6
>  
>clocks:
>  maxItems: 1
> @@ -58,8 +66,30 @@ properties:
>  
>aspm-no-l0s: true
>  
> +  resets:
> +description: for "brcm,bcm7216-pcie", must be a valid reset
> +  phandle pointing to the RESCAL reset controller provider node.
> +$ref: "/schemas/types.yaml#/definitions/phandle"
> +
> +  reset-names:
> +items:
> +  - const: rescal

These are going to need to be an if/then schema if they only apply to 
certain compatible(s).

> +
> +  brcm,scb-sizes:
> +description: (u32, u32) tuple giving the 64bit PCIe memory
> +  viewport size of a memory controller.  There may be up to
> +  three controllers, and each size must be a power of two
> +  with a size greater or equal to the amount of memory the
> +  controller supports.

This sounds like what dma-ranges should express?

If not, we do have 64-bit size if that what you need.

> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> +  - items:
> +  minItems: 2
> +  maxItems: 6
> +
>  required:
>- reg
> +  - ranges
>- dma-ranges
>- "#interrupt-cells"
>- interrupts
> @@ -93,7 +123,9 @@ examples:
>  msi-parent = <&pcie0>;
>  msi-controller;
>  ranges = <0x0200 0x0 0xf800 0x6 0x 0x0 
> 0x0400>;
> -dma-ranges = <0x0200 0x0 0x 0x0 0x 
> 0x0 0x8000>;
> +dma-ranges = <0x4200 0x1 0x 0x0 0x4000 
> 0x0 0x8000>,
> + <0x4200 0x1 0x8000 0x3 0x 
> 0x0 0x8000>;
>  brcm,enable-ssc;
> +brcm,scb-sizes = <0x0 0x8000 0x0 0x8000>;
>  };
>  };
> -- 
> 2.17.1
> 

Re: [fixup v2] kunit: use --build_dir=.kunit as default

[Vitor Massaru Iha]

On Thu, May 28, 2020 at 2:28 PM Shuah Khan  wrote:
>
> On 5/26/20 6:34 PM, Vitor Massaru Iha wrote:
> > To make KUnit easier to use, and to avoid overwriting object and
> > .config files, the default KUnit build directory is set to .kunit
> >
> > Fixed up minor merge conflicts - Shuah Khan 
> >
> > Fixed this identation error exchanging spaces for tabs between lines
> > 248 and 252:
> >
> > tools/testing/kunit/kunit.py run --defconfig
> >
> >File "tools/testing/kunit/kunit.py", line 254
> >  if not linux:
> >  ^
> > TabError: inconsistent use of tabs and spaces in indentation
> >
> > Signed-off-by: Vitor Massaru Iha 
> > Reviewed-by: Brendan Higgins 
> > Signed-off-by: Shuah Khan 
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=205221
>
> Vitor,
>
> This patch doesn't apply. Can you change to subject to be unique
> Fix TabError and do the patch on top of linux-kselftest kunit
>
> I think you did this, but I can't apply this on top:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=kunit
>

Sure, I'll do that.

> thanks,
> -- Shuah

[RESEND] sh: Implement __get_user_u64() required for 64-bit get_user()

[John Paul Adrian Glaubitz]

Hi!

This is my attempt of implementing a 64-bit get_user() for SH to address the
build problem when CONFIG_INFINIBAND_USER_ACCESS is enabled.

I have carefully looked at the existing implementations of __get_user_asm(),
__put_user_asm() and the 64-bit __put_user_u64() to come up with the 64-bit
__get_user_u64().

I'm admittedly not an expert when it comes to writing GCC contraints, so the
code might be completely wrong. However, it builds fine without warnings
and fixes the aforementioned issue for me.

Hopefully someone from the more experienced group of kernel developers can
review my code and help me get it into proper shape for submission.

Resent because I forgot to add a subject for the first cover text.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()

[John Paul Adrian Glaubitz]

Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails

 ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko] 
undefined!

with on SH since the kernel misses a 64-bit implementation of get_user().

Implement the missing 64-bit get_user() as __get_user_u64(), matching the
already existing __put_user_u64() which implements the 64-bit put_user().

Signed-off-by: John Paul Adrian Glaubitz 
---
 arch/sh/include/asm/uaccess_32.h | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
index 624cf55acc27..8bc1cb50f8bf 100644
--- a/arch/sh/include/asm/uaccess_32.h
+++ b/arch/sh/include/asm/uaccess_32.h
@@ -26,6 +26,9 @@ do {  
\
case 4: \
__get_user_asm(x, ptr, retval, "l");\
break;  \
+   case 8: \
+   __get_user_u64(x, ptr, retval); \
+   break;  \
default:\
__get_user_unknown();   \
break;  \
@@ -66,6 +69,52 @@ do { \
 
 extern void __get_user_unknown(void);
 
+#if defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+   "1:\n\t" \
+   "mov.l  %2,%R1\n\t" \
+   "mov.l  %T2,%S1\n\t" \
+   "2:\n" \
+   ".section   .fixup,\"ax\"\n" \
+   "3:\n\t" \
+   "mov#0, %1\n\t" \
+   "mov.l  4f, %0\n\t" \
+   "jmp@%0\n\t" \
+   " mov   %3, %0\n\t" \
+   ".balign4\n" \
+   "4: .long   2b\n\t" \
+   ".previous\n" \
+   ".section   __ex_table,\"a\"\n\t" \
+   ".long  1b, 3b\n\t" \
+   ".previous" \
+   :"=&r" (err), "=&r" (x) \
+   :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#else
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+   "1:\n\t" \
+   "mov.l  %2,%S1\n\t" \
+   "mov.l  %T2,%R1\n\t" \
+   "2:\n" \
+   ".section   .fixup,\"ax\"\n" \
+   "3:\n\t" \
+   "mov#0, %1\n\t" \
+   "mov.l  4f, %0\n\t" \
+   "jmp@%0\n\t" \
+   " mov   %3, %0\n\t" \
+   ".balign4\n" \
+   "4: .long   2b\n\t" \
+   ".previous\n" \
+   ".section   __ex_table,\"a\"\n\t" \
+   ".long  1b, 3b\n\t" \
+   ".previous" \
+   :"=&r" (err), "=&r" (x) \
+   :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#endif
+
 #define __put_user_size(x,ptr,size,retval) \
 do {   \
retval = 0; \
-- 
2.27.0.rc2

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Florian Fainelli]

On 5/29/20 10:43 AM, Lukas Wunner wrote:
> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
>> --- a/drivers/spi/spi-bcm2835.c
>> +++ b/drivers/spi/spi-bcm2835.c
>> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void 
>> *dev_id)
>>  if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>>  bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>>  
>> +/* check if we got interrupt enabled */
>> +if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
>> +return IRQ_NONE;
>> +
>>  /* Read as many bytes as possible from FIFO */
>>  bcm2835_rd_fifo(bs);
>>  /* Write as many bytes as possible to FIFO */
> 
> This definitely looks wrong.  The check whether the interrupt is enabled
> should be moved *before* the conditional calls to bcm2835_rd_fifo_blind()
> and bcm2835_wr_fifo_blind(), i.e. to the top of the function.
> 
> Otherwise if an interrupt is raised by another SPI controller,
> this function may perform read/write accesses to the FIFO and
> interfere with an ongoing transfer in DMA or poll mode.
> 
> Also, instead of performing an MMIO read, just use the "cs" variable
> which was assigned at the top of the function.
> 
> The code comment should explain that the check is necessary because the
> interrupt may be shared with other controllers on the BCM2711.
> 
> Finally, it would be nice if the check would be optimized away when
> compiling for pre-RasPi4 products, maybe something like:
> 
> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
> + return IRQ_NONE;

Rather than keying this off ARM_LPAE or any other option, this should be
keyed off a compatible string, that way we can even conditionally pass
IRQF_SHARED to the interrupt handler if we care so much about performance.
-- 
Florian

Re: [PATCH] spi: bcm2835: Implement shutdown callback

[Lukas Wunner]

On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
> Make sure we clear the FIFOs, stop the block, disable the clock and
> release the DMA channel.

To what end?  Why is this change necessary?  Sorry but this seems like
an awfully terse commit message.

Thanks,

Lukas

> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/spi/spi-bcm2835.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> index 20d8581fdf88..237bd306c268 100644
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -1391,6 +1391,15 @@ static int bcm2835_spi_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static void bcm2835_spi_shutdown(struct platform_device *pdev)
> +{
> + int ret;
> +
> + ret = bcm2835_spi_remove(pdev);
> + if (ret)
> + dev_err(&pdev->dev, "failed to shutdown\n");
> +}
> +
>  static const struct of_device_id bcm2835_spi_match[] = {
>   { .compatible = "brcm,bcm2835-spi", },
>   {}
> @@ -1404,6 +1413,7 @@ static struct platform_driver bcm2835_spi_driver = {
>   },
>   .probe  = bcm2835_spi_probe,
>   .remove = bcm2835_spi_remove,
> + .shutdown   = bcm2835_spi_shutdown,
>  };
>  module_platform_driver(bcm2835_spi_driver);
>  
> -- 
> 2.17.1
> 

Re: [PATCH 7/8] ARM: OMAP2: Switch to use DEVICE_ATTR_RO()

[Tony Lindgren]

* Sudeep Holla  [200523 17:10]:
> Move device attributes to DEVICE_ATTR_RO() as that would make things
> a lot more "obvious" what is happening over the existing __ATTR usage.

Acked-by: Tony Lindgren 

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Mark Brown]

On Fri, May 29, 2020 at 07:43:58PM +0200, Lukas Wunner wrote:

> This definitely looks wrong.  The check whether the interrupt is enabled
> should be moved *before* the conditional calls to bcm2835_rd_fifo_blind()
> and bcm2835_wr_fifo_blind(), i.e. to the top of the function.

Hrm, right - I'll drop the patch.


signature.asc
Description: PGP signature

Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support

[Serge Semin]

On Fri, May 29, 2020 at 08:43:12PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 08:26:42PM +0300, Serge Semin wrote:
> > On Fri, May 29, 2020 at 06:18:32PM +0100, Mark Brown wrote:
> > > On Fri, 29 May 2020 16:11:49 +0300, Serge Semin wrote:
> > > > Baikal-T1 SoC provides a DW DMA controller to perform low-speed 
> > > > peripherals
> > > > Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
> > > > APB SSI devices embedded into the SoC. Currently the DMA-based transfers
> > > > are supported by the DW APB SPI driver only as a middle layer code for
> > > > Intel MID/Elkhart PCI devices. Seeing the same code can be used for 
> > > > normal
> > > > platform DMAC device we introduced a set of patches to fix it within 
> > > > this
> > > > series.
> 
> > As you can see it has been acked by Rob. So you can also merge it into your
> > repo. Though It has to be rebased first due to the Dinh Nguyen patches
> > recently merged in. Do you want me to do the rebasing?
> 
> I guess now you need to rebase it, because as I see the Dinh's patches are in
> the tree as well as yours.

Right. That's what I am doing at the moment.)

-Sergey

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH] spi: bcm2835: Implement shutdown callback

[Florian Fainelli]

On 5/29/20 10:47 AM, Lukas Wunner wrote:
> On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
>> Make sure we clear the FIFOs, stop the block, disable the clock and
>> release the DMA channel.
> 
> To what end?  Why is this change necessary?  Sorry but this seems like
> an awfully terse commit message.

To ensure clocks are disabled and to save power in low power modes used
on 7211 for instance.
-- 
Florian

Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips

[Rob Herring]

On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> v2:
> Commit: "device core: Add ability to handle multiple dma offsets"
>   o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
>   o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
>   o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
>   o dev->dma_pfn_map => dev->dma_pfn_offset_map
>   o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
>   o In device.h: s/const void */const struct dma_pfn_offset_region */
>   o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
>   o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> dev->dma_pfn_offset_map is copied as well.
>   o Merged two of the DMA commits into one (Christoph).
> 
> Commit "arm: dma-mapping: Invoke dma offset func if needed":
>   o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
> 
> Other commits' changes:
>   o Removed need for carrying of_id var in priv (Nicolas)
>   o Commit message rewordings (Bjorn)
>   o Commit log messages filled to 75 chars (Bjorn)
>   o devm_reset_control_get_shared())
> => devm_reset_control_get_optional_shared (Philipp)
>   o Add call to reset_control_assert() in PCIe remove routines (Philipp)
> 
> v1:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi.  Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
> 
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible.  This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller.  This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.

If you can enable the h/w support without the multiple offset support, 
then I'd split up this series. The latter part might take a bit more 
time.

Rob

Re: [PATCH 1/2] dt-bindings: ASoC: renesas,rsnd: Add r8a7742 support

[Rob Herring]

On Tue, 26 May 2020 22:01:43 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

[Jim Quinlan]

On Fri, May 29, 2020 at 1:35 PM Rob Herring  wrote:
>
> On Wed, May 27, 2020 at 9:43 AM Jim Quinlan  
> wrote:
> >
> > Hi Nicolas,
> >
> > On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> >  wrote:
> > >
> > > Hi Jim,
> > > one thing comes to mind, there is a small test suite in 
> > > drivers/of/unittest.c
> > > (specifically of_unittest_pci_dma_ranges()) you could extend it to 
> > > include your
> > > use cases.
> > Sure, will check out.
> > >
> > > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > > The new field in struct device 'dma_pfn_offset_map' is used to 
> > > > facilitate
> > > > the use of multiple pfn offsets between cpu addrs and dma addrs.  It is
> > > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > > cpu or dma address involved.
> > > >
> > > > Signed-off-by: Jim Quinlan 
> > > > ---
> > > >  drivers/of/address.c| 65 +++--
> > > >  drivers/usb/core/message.c  |  3 ++
> > > >  drivers/usb/core/usb.c  |  3 ++
> > > >  include/linux/device.h  | 10 +-
> > > >  include/linux/dma-direct.h  | 10 --
> > > >  include/linux/dma-mapping.h | 46 ++
> > > >  kernel/dma/Kconfig  | 13 
> > > >  7 files changed, 144 insertions(+), 6 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > > device_node *np, u64 *dma_addr,
> > > >   pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > >range.bus_addr, range.cpu_addr, range.size);
> > > >
> > > > + num_ranges++;
> > > >   if (dma_offset && range.cpu_addr - range.bus_addr != 
> > > > dma_offset)
> > > > {
> > > > - pr_warn("Can't handle multiple dma-ranges with 
> > > > different
> > > > offsets on node(%pOF)\n", node);
> > > > - /* Don't error out as we'd break some existing 
> > > > DTs */
> > > > - continue;
> > > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > > + pr_warn("Can't handle multiple dma-ranges 
> > > > with
> > > > different offsets on node(%pOF)\n", node);
> > > > + pr_warn("Perhaps set 
> > > > DMA_PFN_OFFSET_MAP=y?\n");
> > > > + /*
> > > > +  * Don't error out as we'd break some 
> > > > existing
> > > > +  * DTs that are using configs w/o
> > > > +  * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > > +  */
> > > > + continue;
> > >
> > > dev->bus_dma_limit is set in of_dma_configure(), this function's caller, 
> > > based
> > > on dma_start's value (set after this continue). So you'd be effectively 
> > > setting
> > > the dev->bus_dma_limit to whatever we get from the first dma-range.
> > I'm not seeing that at all.  On the  evaluation of each dma-range,
> > dma_start and dma_end are re-evaluated to be the lowest and highest
> > bus values of the  dma-ranges seen so far.  After all dma-ranges are
> > examined,  dev->bus_dma_limit being set to the highest.  In fact, the
> > current code -- ie before my commits -- already does this for multiple
> > dma-ranges as long as the cpu-bus offset is the same in the
> > dma-ranges.
> > >
> > > This can be troublesome depending on how the dma-ranges are setup, for 
> > > example
> > > if the first dma-range doesn't include the CMA area, in arm64 generally 
> > > set as
> > > high as possible in ZONE_DMA32, that would render it useless for
> > > dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if 
> > > smaller
> > > than ZONE_DMA you'd be unable to allocate any DMA memory.
> > >
> > > IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): 
> > > match
> > > the target DMA memory area with each dma-range we have to see if it fits.
> > >
> > > > + }
> > > > + dma_multi_pfn_offset = true;
> > > >   }
> > > >   dma_offset = range.cpu_addr - range.bus_addr;
> > > >
> > > > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > > > device_node *np, u64 *dma_addr,
> > > >   dma_end = range.bus_addr + range.size;
> > > >   }
> > > >
> > > > + if (dma_multi_pfn_offset) {
> > > > + dma_offset = 0;
> > > > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > >   if (dma_start >= dma_end) {
> > > >   ret = -EINVAL;
> > > >   pr_debug("Invalid DMA ranges configuration on 
> > > > node(%pOF)\n",
> > > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > > index 6197938dcc2d..aaa3e58f5eb4 100644
> > > > --- 

[no subject]

[Chris Rankin]

   Linux

https://j.mp/2XC439z


Chris Rankin

Re: [GIT PULL] sh: remove sh5 support

[Rich Felker]

On Fri, May 29, 2020 at 07:30:59AM -0700, Christoph Hellwig wrote:
> On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote:
> > It is in active use. Please do not act on such a request. I would be
> > much quicker to ack things that actually need ack if I weren't CC'd on
> > hundreds of random non-arch-specific changes that don't need it, but I
> > understand that's how the kernel process works. If there are things
> > that need ack please feel free to ping.
> > 
> > Note that I specifically acked and requested the sh5 removal.
> 
> But you did not actually pick it up - because of that it still isn't
> in linux-next and thus most likely will miss Linux 5.8.

Arnd sent the pull request for this and I expected it to be pulled
from his tree, since he already had my approval for the change. Maybe
Linus was expecting it to come through me. This seems to have been a
miscommunication.

Frustratingly, I _still_ don't have an official tree on kernel.org for
the purpose of being the canonical place for linux-next to pull from,
due to policies around pgp keys and nobody following up on signing
mine. This is all really silly since there are ridiculously many
independent channels I could cryptographically validate identity
through with vanishing probability that they're all compromised. For
the time being I'll reactivate my repo on git.musl-libc.org.

Rich

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Lukas Wunner]

On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:43 AM, Lukas Wunner wrote:
> > On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
> >> --- a/drivers/spi/spi-bcm2835.c
> >> +++ b/drivers/spi/spi-bcm2835.c
> >> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, 
> >> void *dev_id)
> >>if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
> >>bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
> >>  
> >> +  /* check if we got interrupt enabled */
> >> +  if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
> >> +  return IRQ_NONE;
> >> +
> >>/* Read as many bytes as possible from FIFO */
> >>bcm2835_rd_fifo(bs);
> >>/* Write as many bytes as possible to FIFO */
[...]
> > Finally, it would be nice if the check would be optimized away when
> > compiling for pre-RasPi4 products, maybe something like:
> > 
> > +   if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
> > +   return IRQ_NONE;
> 
> Rather than keying this off ARM_LPAE or any other option, this should be
> keyed off a compatible string, that way we can even conditionally pass
> IRQF_SHARED to the interrupt handler if we care so much about performance.

But a compatible string can't be checked at compile time, can it?

The point is that at the least the Foundation compiles and ships a separate
kernel for each of the three platforms BCM2835, BCM2837, BCM2711.  It's
unnecessary to check whether an interrupt was actually raised if we *know*
in advance that it's not shared (as is the case with kernels compiled for
BCM2835 and BCM2837).

Thanks,

Lukas

Re: [PATCH v3 1/4] dt-bindings: clk: Add Baikal-T1 CCU PLLs binding

[Rob Herring]

On Wed, 27 May 2020 01:20:53 +0300, Serge Semin wrote:
> Baikal-T1 Clocks Control Unit is responsible for transformation of a
> signal coming from an external oscillator into clocks of various
> frequencies to propagate them then to the corresponding clocks
> consumers (either individual IP-blocks or clock domains). In order
> to create a set of high-frequency clocks the external signal is
> firstly handled by the embedded into CCU PLLs. So the corresponding
> dts-node is just a normal clock-provider node with standard set of
> properties. Note as being part of the Baikal-T1 System Controller its
> DT node is supposed to be a child the system controller node.
> 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Arnd Bergmann 
> Cc: linux-m...@vger.kernel.org
> 
> ---
> 
> Changelog v2:
> - Rearrange the SoBs.
> - Discard comments in the bindings file header.
> - Add dual GPL/BSD license.
> - Add spaces around the ASCII-graphics in the binding description.
> - Remove reference to 
> Documentation/devicetree/bindings/clock/clock-bindings.txt
>   file.
> - Discard redundant object check against "/schemas/clock/clock.yaml#" schema.
> - Discard redundant descriptions of the "#clock-cells" property.
> - Remove "reg" property since from now the clock DT node is supposed to be
>   a child of the syscon-compatible system controller node.
> - Remove "clock-output-names" property support.
> - Replace "additionalProperties: false" with "unevaluatedProperties: false".
> - Lowercase the nodes name in the examples.
> - Use "clock-controller" node name suffix in the examples.
> - Remove unnecessary comments in the clocks dt-bindings header file.
> 
> Changelog v3:
> - Get the reg property back even though the driver is using the parental
>   syscon regmap.
> - The DT schema will live separately from the system controller, but the
>   corresponding sub-node of the later DT schema will $ref this one.
> ---
>  .../bindings/clock/baikal,bt1-ccu-pll.yaml| 131 ++
>  include/dt-bindings/clock/bt1-ccu.h   |  16 +++
>  2 files changed, 147 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
>  create mode 100644 include/dt-bindings/clock/bt1-ccu.h
> 

Reviewed-by: Rob Herring 

Re: linux-next: Tree for May 14 (objtool 2/2)

[Josh Poimboeuf]

On Thu, May 28, 2020 at 11:06:32PM -0700, Kees Cook wrote:
> On Thu, May 28, 2020 at 10:44:04AM -0500, Josh Poimboeuf wrote:
> > On Thu, May 14, 2020 at 09:04:36AM -0700, Randy Dunlap wrote:
> > > On 5/14/20 4:07 AM, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > Changes since 20200512:
> > > > 
> > > 
> > > on x86_64:
> > > 
> > > drivers/ide/ide-tape.o: warning: objtool: 
> > > ide_tape_discard_merge_buffer.constprop.7()+0x4e: unreachable instruction
> > > drivers/scsi/sd.o: warning: objtool: sd_pr_clear()+0x1e: unreachable 
> > > instruction
> > > drivers/scsi/sd_zbc.o: warning: objtool: 
> > > sd_zbc_update_wp_offset_workfn()+0xec: unreachable instruction
> > > drivers/target/target_core_xcopy.o: warning: objtool: 
> > > target_xcopy_do_work()+0xdd6: unreachable instruction
> > > 
> > > 
> > > randconfig file is attached.
> > 
> > Kees,
> > 
> > More UBSAN_TRAP fun.  This randconfig has:
> > 
> > CONFIG_UBSAN_TRAP=y
> > CONFIG_UBSAN_ALIGNMENT=y
> > # CONFIG_COMPILE_TEST is not set
> 
> Ugh, I thought CONFIG_COMPILE_TEST always gets set for randconfig and
> the all*config choices, but now I see that CONFIG_COMPILE_TEST is
> enabled due to the "all" part of the all*config choices. Okay. Big
> hammer:

Yeah, I didn't realize that either... /me wonders if that should change.

> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 929211039bac..27bcc2568c95 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -63,7 +63,7 @@ config UBSAN_SANITIZE_ALL
>  config UBSAN_ALIGNMENT
> bool "Enable checks for pointers alignment"
> default !HAVE_EFFICIENT_UNALIGNED_ACCESS
> -   depends on !X86 || !COMPILE_TEST
> +   depends on !UBSAN_TRAP
> help
>   This option enables the check of unaligned memory accesses.
>   Enabling this option on architectures that support unaligned
> 
> How about that?

But I thought you said the alignment traps might be useful on other
arches?  Should it be

depends on !X86 || !UBSAN_TRAP

?

-- 
Josh

[RFC PATCH linux-next] Revert "net: bcmgenet: bcmgenet_hfb_add_filter() can be static

[kbuild test robot]

Fixes: 14da1510fedc ("Revert "net: bcmgenet: remove unused function in 
bcmgenet.c"")
Signed-off-by: kbuild test robot 
---
 bcmgenet.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index b37ef05c5083a..98e492e066dcb 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2855,8 +2855,8 @@ static int bcmgenet_hfb_find_unused_filter(struct 
bcmgenet_priv *priv)
  * bcmgenet_hfb_add_filter(priv, hfb_filter_ipv4_udp,
  * ARRAY_SIZE(hfb_filter_ipv4_udp), 0);
  */
-int bcmgenet_hfb_add_filter(struct bcmgenet_priv *priv, u32 *f_data,
-   u32 f_length, u32 rx_queue)
+static int bcmgenet_hfb_add_filter(struct bcmgenet_priv *priv, u32 *f_data,
+  u32 f_length, u32 rx_queue)
 {
int f_index;
u32 i;

Re: [PATCH] net: atm: Replace kmalloc with kzalloc in the error message

[Markus Elfring]

> Looking into the context (atomic!) and error message itself I would rather 
> drop
> message completely.

How do you think about to take another look at a previous update suggestion
like the following?

net/atm: Delete an error message for a failed memory allocation in five 
functions
https://patchwork.ozlabs.org/project/netdev/patch/5270f15b-5e97-0c3e-3e55-fbded48ae...@users.sourceforge.net/
https://lore.kernel.org/lkml/5270f15b-5e97-0c3e-3e55-fbded48ae...@users.sourceforge.net/
https://lore.kernel.org/patchwork/patch/838867/
https://lkml.org/lkml/2017/10/9/1009

Regards,
Markus

Re: [PATCH] vfio/mdev: Fix reference count leak in add_mdev_supported_type.

[Kirti Wankhede]

On 5/28/2020 12:32 PM, Cornelia Huck wrote:

On Wed, 27 May 2020 21:01:09 -0500
wu000...@umn.edu wrote:


From: Qiushi Wu 

kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object. Thus,
replace kfree() by kobject_put() to fix this issue. Previous
commit "b8eb718348b8" fixed a similar problem.

Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
Signed-off-by: Qiushi Wu 
---
  drivers/vfio/mdev/mdev_sysfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Cornelia Huck 



Thanks for fixing.

Reviewed-by: Kirti Wankhede 

Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips

[Jim Quinlan]

On Fri, May 29, 2020 at 1:49 PM Rob Herring  wrote:
>
> On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> > v2:
> > Commit: "device core: Add ability to handle multiple dma offsets"
> >   o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
> >   o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
> >   o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
> >   o dev->dma_pfn_map => dev->dma_pfn_offset_map
> >   o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
> >   o In device.h: s/const void */const struct dma_pfn_offset_region */
> >   o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> > guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
> >   o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> > dev->dma_pfn_offset_map is copied as well.
> >   o Merged two of the DMA commits into one (Christoph).
> >
> > Commit "arm: dma-mapping: Invoke dma offset func if needed":
> >   o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
> >
> > Other commits' changes:
> >   o Removed need for carrying of_id var in priv (Nicolas)
> >   o Commit message rewordings (Bjorn)
> >   o Commit log messages filled to 75 chars (Bjorn)
> >   o devm_reset_control_get_shared())
> > => devm_reset_control_get_optional_shared (Philipp)
> >   o Add call to reset_control_assert() in PCIe remove routines (Philipp)
> >
> > v1:
> > This patchset expands the usefulness of the Broadcom Settop Box PCIe
> > controller by building upon the PCIe driver used currently by the
> > Raspbery Pi.  Other forms of this patchset were submitted by me years
> > ago and not accepted; the major sticking point was the code required
> > for the DMA remapping needed for the PCIe driver to work [1].
> >
> > There have been many changes to the DMA and OF subsystems since that
> > time, making a cleaner and less intrusive patchset possible.  This
> > patchset implements a generalization of "dev->dma_pfn_offset", except
> > that instead of a single scalar offset it provides for multiple
> > offsets via a function which depends upon the "dma-ranges" property of
> > the PCIe host controller.  This is required for proper functionality
> > of the BrcmSTB PCIe controller and possibly some other devices.
>
> If you can enable the h/w support without the multiple offset support,
> then I'd split up this series. The latter part might take a bit more
> time.
>
> Rob
Unfortunately, the STB PCIe  controller depends on the multiple PFN
offset functionality.
Thanks,
Jim

Re: [PATCH v3 2/6] hwmon: (pmbus/core) Add Block WR

[Guenter Roeck]

On 5/29/20 6:05 AM, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici 
> 
> PmBus devices support Block Write-Block Read Process
> Call described in SMBus specification v 2.0 with the
> exception that Block writes and reads are permitted to
> have up 255 data bytes instead of max 32 bytes (SMBus).
> 
> This patch adds Block WR process call support for PMBus.
> 

I don't think I want to have this code in the PMBus core.
We can move it there if needed at some point in the future,
but for the time being I'd rather have it in the driver
needing it.

> Signed-off-by: Alexandru Tachici 
> ---
>  drivers/hwmon/pmbus/Kconfig  |  2 +-
>  drivers/hwmon/pmbus/pmbus.h  |  4 ++
>  drivers/hwmon/pmbus/pmbus_core.c | 88 
>  3 files changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 6949483aa732..f11712fdcea8 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -5,7 +5,7 @@
>  
>  menuconfig PMBUS
>   tristate "PMBus support"
> - depends on I2C
> + depends on I2C && CRC8

This should be select CRC8, not depends.

>   help
> Say yes here if you want to enable PMBus support.
>  
> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index 18e06fc6c53f..ae4e15c5dff2 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
> @@ -392,6 +392,8 @@ enum pmbus_sensor_classes {
>  #define PMBUS_PHASE_VIRTUAL  BIT(30) /* Phases on this page are virtual */
>  #define PMBUS_PAGE_VIRTUAL   BIT(31) /* Page is virtual */
>  
> +#define PMBUS_BLOCK_MAX  255
> +
>  enum pmbus_data_format { linear = 0, direct, vid };
>  enum vrm_version { vr11 = 0, vr12, vr13, imvp9, amd625mv };
>  
> @@ -467,6 +469,8 @@ int pmbus_read_word_data(struct i2c_client *client, int 
> page, int phase,
>u8 reg);
>  int pmbus_write_word_data(struct i2c_client *client, int page, u8 reg,
> u16 word);
> +int pmbus_block_wr(struct i2c_client *client, u8 cmd, u8 w_len, u8 *data_w,
> +u8 *data_r);
>  int pmbus_read_byte_data(struct i2c_client *client, int page, u8 reg);
>  int pmbus_write_byte(struct i2c_client *client, int page, u8 value);
>  int pmbus_write_byte_data(struct i2c_client *client, int page, u8 reg,
> diff --git a/drivers/hwmon/pmbus/pmbus_core.c 
> b/drivers/hwmon/pmbus/pmbus_core.c
> index 8d321bf7d15b..ef63468da3b5 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
> @@ -6,6 +6,7 @@
>   * Copyright (c) 2012 Guenter Roeck
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -44,6 +45,8 @@
>  
>  #define PMBUS_NAME_SIZE  24
>  
> +DECLARE_CRC8_TABLE(pmbus_crc_table);
> +
>  struct pmbus_sensor {
>   struct pmbus_sensor *next;
>   char name[PMBUS_NAME_SIZE]; /* sysfs sensor name */
> @@ -184,6 +187,89 @@ int pmbus_set_page(struct i2c_client *client, int page, 
> int phase)
>  }
>  EXPORT_SYMBOL_GPL(pmbus_set_page);
>  
> +/* Block Write/Read command.

I won't accept network-style multi-line comments.

> + * @client: Handle to slave device
> + * @cmd: Byte interpreted by slave
> + * @w_len: Size of write data block; PMBus allows at most 255 bytes
> + * @data_w: byte array which will be written.
> + * @data_r: Byte array into which data will be read; big enough to hold
> + *   the data returned by the slave. PMBus allows at most 255 bytes.
> + *
> + * Different from Block Read as it sends data and waits for the slave to
> + * return a value dependent on that data. The protocol is simply a Write 
> Block
> + * followed by a Read Block without the Read-Block command field and the
> + * Write-Block STOP bit.
> + *
> + * Returns number of bytes read or negative errno.
> + */
> +int pmbus_block_wr(struct i2c_client *client, u8 cmd, u8 w_len,

_wr is misleading, since it suggests an abbreviated _write.
Better use something like _transfer or _xfer.

> +u8 *data_w, u8 *data_r)
> +{
> + u8 write_buf[PMBUS_BLOCK_MAX + 1];
> + struct i2c_msg msgs[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .buf = write_buf,
> + .len = w_len + 2,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = PMBUS_BLOCK_MAX,
> + }
> + };
> + u8 addr = 0;
> + u8 crc = 0;
> + int ret;
> +
> + msgs[0].buf[0] = cmd;
> + msgs[0].buf[1] = w_len;
> + memcpy(&msgs[0].buf[2], data_w, w_len);
> +

w_len can be up to 255, meaning up to 255 + 2 bytes can be written
into write_buf. Yet, write_buf is only 256 bytes long.

> + msgs[0].buf = i2c_get_dma_safe_msg_buf(&msgs[0], 1);
> + if (!msgs[0].buf)
> + return -ENOMEM;
> +
> + msgs[1].buf = i2c_get_

Re: [PATCH v3 2/4] dt-bindings: clk: Add Baikal-T1 CCU Dividers binding

[Rob Herring]

On Wed, 27 May 2020 01:20:54 +0300, Serge Semin wrote:
> After being gained by the CCU PLLs the signals must be transformed to
> be suitable for the clock-consumers. This is done by a set of dividers
> embedded into the CCU. A first block of dividers is used to create
> reference clocks for AXI-bus of high-speed peripheral IP-cores of the
> chip. The second block dividers alter the PLLs output signals to be then
> consumed by SoC peripheral devices. Both block DT nodes are ordinary
> clock-providers with standard set of properties supported. But in addition
> to that each clock provider can be used to reset the corresponding clock
> domain. This makes the AXI-bus and System Devices CCU DT nodes to be also
> reset-providers.
> 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Arnd Bergmann 
> Cc: linux-m...@vger.kernel.org
> 
> ---
> 
> Changelog v2:
> - Rearrange the SoBs.
> - Combine AXI-bus and System Devices CCU bindings into a single file.
> - Discard comments in the bindings file header.
> - Add dual GPL/BSD license.
> - Add spaces around the ASCII-graphics in the binding description.
> - Remove reference to 
> Documentation/devicetree/bindings/clock/clock-bindings.txt
>   file.
> - Discard redundant object check against "/schemas/clock/clock.yaml#" schema.
> - Discard redundant descriptions of "#clock-cells" and "#reset-cells"
>   properties.
> - Discard "reg" property since the CCU dividers DT nodes are supposed be
>   children of the syscon-compatible system controller node.
> - Remove "clock-output-names" property support.
> - Replace "additionalProperties: false" with "unevaluatedProperties: false".
> - Lowercase the nodes name in the examples.
> - Use "clock-controller" node name suffix in the examples.
> - Remove unnecessary comments in the clocks and resets dt-binding header
>   files.
> - Discard label definitions in the examples.
> 
> Changelog v3:
> - Get the reg property back even though the driver is using the parental
>   syscon regmap.
> - The DT schema will live separately from the system controller, but the
>   corresponding sub-node of the later DT schema will $ref this one.
> ---
>  .../bindings/clock/baikal,bt1-ccu-div.yaml| 188 ++
>  include/dt-bindings/clock/bt1-ccu.h   |  32 +++
>  include/dt-bindings/reset/bt1-ccu.h   |  25 +++
>  3 files changed, 245 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
>  create mode 100644 include/dt-bindings/reset/bt1-ccu.h
> 

Reviewed-by: Rob Herring 

Re: [PATCH 06/30] KVM: SVM: always update CR3 in VMCB

[Sean Christopherson]

On Fri, May 29, 2020 at 10:41:58AM -0700, Krish Sadhukhan wrote:
> 
> On 5/29/20 8:39 AM, Paolo Bonzini wrote:
> >svm_load_mmu_pgd is delaying the write of GUEST_CR3 to prepare_vmcs02
> 
> Did you mean to say enter_svm_guest_mode here ?

Heh, looks like Vitaly passed the s/vmcs/vmcb bug on to Paolo, too. :-D

Re: [PATCH V7 1/3] dt-bindings: geni-se: Convert QUP geni-se bindings to YAML

[Rob Herring]

On Wed, May 27, 2020 at 11:57:42AM +0530, Akash Asthana wrote:
> Convert QUP geni-se bindings to DT schema format using json-schema.
> 
> Signed-off-by: Akash Asthana 
> Reviewed-by: Rob Herring 
> Reviewed-by: Stephen Boyd 
> ---
> Changes in V2:
>  - As per Stephen's comment corrected defintion of interrupts for UART node.
>Any valid UART node must contain atleast 1 interrupts.
> 
> Changes in V3:
>  - As per Rob's comment, added number of reg entries for reg property.
>  - As per Rob's comment, corrected unit address to hex.
>  - As per Rob's comment, created a pattern which matches everything common
>to geni based I2C, SPI and UART controller and then one pattern  for each.
>  - As per Rob's comment, restored original example.
> 
> Changes in V4:
>  - Resolve below compilation error reported from bot.
> 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/
> qcom,geni-se.yaml: properties:clocks:minItems: False schema does not allow 2
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/
> qcom,geni-se.yaml: properties:clocks:maxItems: False schema does not allow 2
> Documentation/devicetree/bindings/Makefile:12: recipe for target
> 'Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.example.dts' failed
> make[1]: *** [Documentation/devicetree/bindings/soc/qcom/
> qcom,geni-se.example.dts] Error 1
> Makefile:1263: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
> 
> Changes in V6:
>  - Added reg entry for soc@0 example node to address below warning.
> 
> Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.example.dts:22.20-60.11
> : Warning (unit_address_vs_reg): /example-0/soc@0: node has a unit name,
> but no reg or ranges property
> 
> Changes in V7:
>  - No change.
> 
>  .../devicetree/bindings/soc/qcom/qcom,geni-se.txt  |  94 -
>  .../devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 210 
> +
>  2 files changed, 210 insertions(+), 94 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
>  create mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml

Applied, thanks.

Rob

Re: [PATCH V7 2/3] dt-bindings: geni-se: Add interconnect binding for GENI QUP

[Rob Herring]

On Wed, 27 May 2020 11:57:43 +0530, Akash Asthana wrote:
> Add documentation for the interconnect and interconnect-names properties
> for the GENI QUP.
> 
> Signed-off-by: Akash Asthana 
> Reviewed-by: Stephen Boyd 
> ---
> Changes in V5:
>  - Add interconnect property for QUP wrapper (parent node).
>  - Add minItems = 2 for interconnect property in child nodes
> 
> Changes in V6:
>  - As per Rob's comment added minItems = 2 for interconnect-names.
> 
> Changes in V7:
>  - No change.
> 
>  .../devicetree/bindings/soc/qcom/qcom,geni-se.yaml  | 17 
> +
>  1 file changed, 17 insertions(+)
> 

Applied, thanks!

Re: [PATCH V7 3/3] dt-bindings: serial: Add binding for UART pin swap

[Rob Herring]

On Wed, 27 May 2020 11:57:44 +0530, Akash Asthana wrote:
> Add documentation to support RX-TX & CTS-RTS GPIO pin swap in HW.
> 
> Signed-off-by: Akash Asthana 
> Reviewed-by: Stephen Boyd 
> ---
> Changes in V7:
>  - As per Rob's comment, added type: boolean to properties.
> 
>  Documentation/devicetree/bindings/serial/serial.yaml | 8 
>  1 file changed, 8 insertions(+)
> 

Applied, thanks!

Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Vijay Khemka]

On 5/29/20, 5:47 AM, "Manikandan Elumalai"  
wrote:

The adm1278 temperature sysfs attribute need it for one of the openbmc 
platform . 
This functionality is not enabled by default, so PMON_CONFIG needs to be 
modified in order to enable it.

Signed-off-by   : Manikandan Elumalai 

v2:
   - Add Signed-off-by.
   - Removed ADM1278_TEMP1_EN check.
---
 drivers/hwmon/pmbus/adm1275.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 5caa37fb..ab5fceb 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -666,7 +666,23 @@ static int adm1275_probe(struct i2c_client *client,
tindex = 3;
 
info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
-   PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
+   PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
+
+   config = i2c_smbus_read_byte_data(client, ADM1275_PMON_CONFIG);
+   if (config < 0)
+   return config;
+
+   /* Enable TEMP1 by default */
+   config |= ADM1278_TEMP1_EN;
+   ret = i2c_smbus_write_byte_data(client,
+   ADM1275_PMON_CONFIG,
+   config);
+   if (ret < 0) {
+   dev_err(&client->dev,
+   "Failed to enable temperature config\n");
+   return -ENODEV;
+   }
You don't need this above code removing check as below should be enough  to
populate sysfs entry you need.

/* Enable VOUT if not enabled (it is disabled by default) */
if (!(config & ADM1278_VOUT_EN)) {
@@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
}
}
 
-   if (config & ADM1278_TEMP1_EN)
-   info->func[0] |=
-   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
if (config & ADM1278_VIN_EN)
info->func[0] |= PMBUS_HAVE_VIN;
break;
-- 
2.7.4

Re: [PATCH] spi: bcm2835: Implement shutdown callback

[Lukas Wunner]

On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:47 AM, Lukas Wunner wrote:
> > On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
> >> Make sure we clear the FIFOs, stop the block, disable the clock and
> >> release the DMA channel.
> > 
> > To what end?  Why is this change necessary?  Sorry but this seems like
> > an awfully terse commit message.
> 
> To ensure clocks are disabled and to save power in low power modes used
> on 7211 for instance.

Thanks for the explanation, that's an important tidbit.  I wasn't even
aware that this SPI controller is used on SoCs beyond the Raspberry Pi
ones.  Does the BCM7211 use shared interrupts for this controller?
Does it have DMA DREQ attached?

Re: [PATCH v3 00/28] KVM: nSVM: event fixes and migration support

[Sean Christopherson]

> [PATCH v3 00/28] KVM: nSVM: event fixes and migration support

You've got something funky going on with the way you generate cover letters,
looks like it doesn't count patches authored by someone else.  The 'v3' is
also missing from the patches, though I suppose some heathens do that on
purpose.

> Paolo Bonzini (28):
> 
> Vitaly Kuznetsov (2):

Re: [PATCH 8/8] ARM: OMAP2: Use custom soc attribute group instead of device_create_file

[Tony Lindgren]

* Sudeep Holla  [200523 17:10]:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
> 
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
> 
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.

Acked-by: Tony Lindgren 

Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface

[Sebastian Reichel]

Hi,

On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote:
> > ping?
> 
> Well, I thought that we maybe do not need standard LEDs on medical hardware.

The discussion died and the patch was not applied :) In general
IDK how worthwhile it is to use standard LED names for them. I
suppose the number of people planning to create something like
OpenWRT for medical devices is not so big.

> > On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > > From: Ian Ray 
> > > > > 
> > > > > Use kernel LED interface for the alarm LEDs.
> > > > 
> > > > Could we get these changes cced to LED maintainers?
> > > 
> > > Sorry, you are not turning up via get_maintainer.pl and usually
> > > subsystem maintainers are not CC'd for every DT device instance.
> > > E.g. I do not want to be always CC'd for DT board file containing
> > > a battery/charger. I'm quite surprised you want to be CC'd for
> > > them, just looking at ARM DT files there are over 1000 instances
> > > of leds.
> 
> Well, we have mess in the naming; I'd like to clear it up.

I understand.

> > > > > + alarm1 {
> > > > > + label = "alarm:red";
> > > > > + gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > > + };
> > > > 
> > > > So... What is function of these leds, and can we get naming more
> > > > consistent with rest of the kernel?
> > > 
> > > The device is a medical patient monitor and these are alarm LEDs
> > > informing about critical device or patient status. They are
> > > referenced by their color (those are discrete LEDs, not a
> > > multi-color one) basically everywhere. The only exception is
> > > "silenced", which means that audible alarm is surpressed. I
> > > don't think we have something comparable for any of those LEDs
> > > in the mainline tree.
> 
> Actually, we have "platform:*:mute" LEDs, that could be used for
> "silenced".

I see you point, but wonder if mute is the right choice. The LED
signals a silenced alarm, which IMHO is not the same:

* The alarm silencing is temporary and system unsilences after
  1-2 minutes.
* LED is usually blinking instead of solid like a laptop mute LED
  (so that operator is aware of silenced alarm)
* Device usually cannot be put into silenced mode before the alarm
  appears
* Some medical devices still generate perodic beeps

AFAIK this is named alarm silencing by basically everyone for
medical devices. So I think naming this platfrom:*:mute would
increase the mess.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Florian Fainelli]

On 5/29/20 10:53 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:43 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
 --- a/drivers/spi/spi-bcm2835.c
 +++ b/drivers/spi/spi-bcm2835.c
 @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, 
 void *dev_id)
if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
  
 +  /* check if we got interrupt enabled */
 +  if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
 +  return IRQ_NONE;
 +
/* Read as many bytes as possible from FIFO */
bcm2835_rd_fifo(bs);
/* Write as many bytes as possible to FIFO */
> [...]
>>> Finally, it would be nice if the check would be optimized away when
>>> compiling for pre-RasPi4 products, maybe something like:
>>>
>>> +   if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
>>> +   return IRQ_NONE;
>>
>> Rather than keying this off ARM_LPAE or any other option, this should be
>> keyed off a compatible string, that way we can even conditionally pass
>> IRQF_SHARED to the interrupt handler if we care so much about performance.
> 
> But a compatible string can't be checked at compile time, can it?

No, but you can have a different interrupt handler that it set at
runtime if you want to completely eliminate this comparison.

My point is that CONFIG_ARM_LPAE is just too brittle, there is nothing
that prevents you from using a non-LPAE kernel on the Pi 4, even PCIe
could be made to work if using super section mappings to map the PCIe
outbound space. Even on models with over 4GB of DRAM, if you are willing
to lose some of it, it can work.

> 
> The point is that at the least the Foundation compiles and ships a separate
> kernel for each of the three platforms BCM2835, BCM2837, BCM2711.  It's
> unnecessary to check whether an interrupt was actually raised if we *know*
> in advance that it's not shared (as is the case with kernels compiled for
> BCM2835 and BCM2837).

I am fine with any solution that does not involve keying off
CONFIG_ARM_LPAE to discriminate 2711 from any other chip.
-- 
Florian

Re: [PATCH] spi: bcm2835: Implement shutdown callback

[Florian Fainelli]

On 5/29/20 10:58 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:47 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
 Make sure we clear the FIFOs, stop the block, disable the clock and
 release the DMA channel.
>>>
>>> To what end?  Why is this change necessary?  Sorry but this seems like
>>> an awfully terse commit message.
>>
>> To ensure clocks are disabled and to save power in low power modes used
>> on 7211 for instance.
> 
> Thanks for the explanation, that's an important tidbit.  I wasn't even
> aware that this SPI controller is used on SoCs beyond the Raspberry Pi
> ones.  Does the BCM7211 use shared interrupts for this controller?
> Does it have DMA DREQ attached?

For all practical purposes you can consider that 7211 is identical to a
2711, it does use shared interrupts for this controller and there is a
DRAM DREQ attached as well. Where they differ are on the display, video,
and memory controller MAC.
-- 
Florian

Re: [RFC] decrease tsk->signal->live before profile_task_exit

[Eric W. Biederman]

liuchao  writes:

> I want to dermine which thread is the last one to enter
> do_exit in profile_task_exit. But when a lot of threads
> exit, tsk->signal->live is not correct since it decrease
> after profile_task_exit.

I don't think that would be wise.

Any additional code before the sanity checks at the start of do_exit
seems like a bad idea.

We could probably move the decrement of tsk->signal->live a little
earlier, but not that much earlier in the function.

Does profile_task_exit even make sense that early in the code?  If the
code is doing much of anything that is a completely inappopriate
placement of profile_task_exit.

Eric


> Signed-off-by: liuchao 
> ---
>  kernel/exit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/exit.c b/kernel/exit.c
> index ce2a75bc0ade..1693764bc356 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -708,6 +708,7 @@ void __noreturn do_exit(long code)
>   struct task_struct *tsk = current;
>   int group_dead;
>  
> + group_dead = atomic_dec_and_test(&tsk->signal->live);
>   profile_task_exit(tsk);
>   kcov_task_exit(tsk);
>  
> @@ -755,7 +756,6 @@ void __noreturn do_exit(long code)
>   if (tsk->mm)
>   sync_mm_rss(tsk->mm);
>   acct_update_integrals(tsk);
> - group_dead = atomic_dec_and_test(&tsk->signal->live);
>   if (group_dead) {
>   /*
>* If the last thread of global init has exited, panic

Re: [PATCH] [v2] PCI: tegra: Fix runtime PM imbalance on error

[Thierry Reding]

On Thu, May 21, 2020 at 10:47:09AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
> 
> Also, call pm_runtime_disable() when pm_runtime_get_sync() returns
> an error code.
> 
> Signed-off-by: Dinghao Liu 
> ---
>  drivers/pci/controller/pci-tegra.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

[PATCH] dt-bindings: Merge gpio-usb-b-connector with usb-connector

[Thierry Reding]

From: Thierry Reding 

The binding for usb-connector is a superset of gpio-usb-b-connector. One
major difference is that gpio-usb-b-connector requires at least one of
the vbus-gpios and id-gpios properties to be specified. Merge the two
bindings by adding the compatible string combination for the GPIO USB-B
variant and an extra conditional for the required properties list to the
usb-connector.yaml file.

Signed-off-by: Thierry Reding 
---
 .../bindings/connector/usb-connector.yaml | 39 +--
 .../devicetree/bindings/usb/usb-conn-gpio.txt | 30 --
 2 files changed, 35 insertions(+), 34 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 03b92b6f35fa..9bd52e63c935 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -15,10 +15,15 @@ description:
 
 properties:
   compatible:
-enum:
-  - usb-a-connector
-  - usb-b-connector
-  - usb-c-connector
+oneOf:
+  - enum:
+  - usb-a-connector
+  - usb-b-connector
+  - usb-c-connector
+
+  - items:
+  - const: gpio-usb-b-connector
+  - const: usb-b-connector
 
   label:
 description: Symbolic name for the connector.
@@ -140,6 +145,19 @@ properties:
 required:
   - compatible
 
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: gpio-usb-b-connector
+then:
+  anyOf:
+- required:
+- vbus-gpios
+- required:
+- id-gpios
+
 examples:
   # Micro-USB connector with HS lines routed via controller (MUIC).
   - |
@@ -202,3 +220,16 @@ examples:
 op-sink-microwatt = <1000>;
   };
 };
+
+  # USB connector with GPIO control lines
+  - |
+#include 
+
+usb {
+  connector {
+compatible = "gpio-usb-b-connector", "usb-b-connector";
+type = "micro";
+id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
+vbus-supply = <&usb_p0_vbus>;
+  };
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt 
b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
deleted file mode 100644
index ec80641208a5..
--- a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-USB GPIO Based Connection Detection
-
-This is typically used to switch dual role mode from the USB ID pin connected
-to an input GPIO, and also used to enable/disable device mode from the USB
-Vbus pin connected to an input GPIO.
-
-Required properties:
-- compatible : should include "gpio-usb-b-connector" and "usb-b-connector".
-- id-gpios, vbus-gpios : input gpios, either one of them must be present,
-   and both can be present as well.
-   see connector/usb-connector.yaml
-
-Optional properties:
-- vbus-supply : can be present if needed when supports dual role mode.
-   see connector/usb-connector.yaml
-
-- Sub-nodes:
-   - port : can be present.
-   see graph.txt
-
-Example:
-
-&mtu3 {
-   connector {
-   compatible = "gpio-usb-b-connector", "usb-b-connector";
-   type = "micro";
-   id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
-   vbus-supply = <&usb_p0_vbus>;
-   };
-};
-- 
2.24.1

Re: [PATCH v14 1/1] perf tools: add support for libpfm4

[Ian Rogers]

On Fri, May 29, 2020 at 10:36 AM Arnaldo Carvalho de Melo
 wrote:
>
> Em Fri, May 29, 2020 at 02:23:10PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, May 29, 2020 at 10:03:51AM -0700, Ian Rogers escreveu:
> > > On Tue, May 5, 2020 at 11:29 AM Ian Rogers  wrote:
> > > >
> > > > From: Stephane Eranian 
> > > >
> > > > This patch links perf with the libpfm4 library if it is available
> > > > and LIBPFM4 is passed to the build. The libpfm4 library
> > > > contains hardware event tables for all processors supported by
> > > > perf_events. It is a helper library that helps convert from a
> > > > symbolic event name to the event encoding required by the
> > > > underlying kernel interface. This library is open-source and
> > > > available from: http://perfmon2.sf.net.
> > > >
> > > > With this patch, it is possible to specify full hardware events
> > > > by name. Hardware filters are also supported. Events must be
> > > > specified via the --pfm-events and not -e option. Both options
> > > > are active at the same time and it is possible to mix and match:
> > > >
> > > > $ perf stat --pfm-events inst_retired:any_p:c=1:i -e cycles 
> > > >
> > > > Signed-off-by: Stephane Eranian 
> > > > Reviewed-by: Ian Rogers 
> > >
> > > Ping.
> >
> > Check my tmp.perf/core branch, I had to make some adjustments, mostly in
> > the 'perf test' entries as I merged a java demangle test that touched
> > the same files,
> >
> > I'm now doing the build tests.
>
> Talking about build  tests, you forgot to add it there, like I did
> below, I'll eventually do it, as it is opt-in, no biggie at this point.
>
> I'll install libpfm-devel that is in fedora and do further tests, later
> today.

Sorry for that, tbh I wasn't sure what to do. When I test locally I
make sure the build is and isn't adding libpfm into the man pages, the
libpfm tests pass, some command line uses. It'd be great to automate
this as it is not something you'd want to do for every patch and there
is some build sensitivity that potentially could break it.

Thanks,
Ian

> - Arnaldo
>
> commit a01c205e3c4cd6d134317413f2dc3129c4ab7a5a
> Author: Arnaldo Carvalho de Melo 
> Date:   Fri May 29 11:31:23 2020 -0300
>
> perf build: Add NO_SYSCALL_TABLE=1 to the build tests
>
> So that we make sure that even on x86-64 and other architectures where
> that is the default method we test build the fallback to libaudit that
> other architectures use.
>
> I.e. now this line got added to:
>
>   $ make -C tools/perf build-test
>   
>make_no_syscall_tbl_O: cd . && make NO_SYSCALL_TABLE=1 
> FEATURES_DUMP=/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j12 
> O=/tmp/tmp.W0HtKR1mfr DESTDIR=/tmp/tmp.lNezgCVPzW
>   
>   $
>
> Cc: Adrian Hunter 
> Cc: Ingo Molnar 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Signed-off-by: Arnaldo Carvalho de Melo 
>
> diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> index 29ce0da7fca6..a4ffa3c7fcb6 100644
> --- a/tools/perf/tests/make
> +++ b/tools/perf/tests/make
> @@ -88,6 +88,7 @@ make_no_libbpf_DEBUG := NO_LIBBPF=1 DEBUG=1
>  make_no_libcrypto   := NO_LIBCRYPTO=1
>  make_with_babeltrace:= LIBBABELTRACE=1
>  make_no_sdt:= NO_SDT=1
> +make_no_syscall_tbl := NO_SYSCALL_TABLE=1
>  make_with_clangllvm := LIBCLANGLLVM=1
>  make_tags   := tags
>  make_cscope := cscope
> @@ -113,7 +114,7 @@ make_minimal+= NO_DEMANGLE=1 NO_LIBELF=1 
> NO_LIBUNWIND=1 NO_BACKTRACE=1
>  make_minimal+= NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1
>  make_minimal+= NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1
>  make_minimal+= NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1 NO_LIBZSTD=1
> -make_minimal+= NO_LIBCAP=1
> +make_minimal+= NO_LIBCAP=1 NO_SYSCALL_TABLE=1
>
>  # $(run) contains all available tests
>  run := make_pure
> @@ -146,6 +147,7 @@ run += make_no_libbionic
>  run += make_no_auxtrace
>  run += make_no_libbpf
>  run += make_no_libbpf_DEBUG
> +run += make_no_syscall_tbl
>  run += make_with_babeltrace
>  run += make_with_clangllvm
>  run += make_help

Re: [PATCH 2/2] perf build: Allow explicitely disabling the NO_SYSCALL_TABLE variable

[Jiri Olsa]

On Fri, May 29, 2020 at 12:55:52PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
> 
> This is useful to see if, on x86, the legacy libaudit still works, as it
> is used in architectures that don't have the SYSCALL_TABLE logic and we
> want to have it tested in 'make -C tools/perf/ build-test'.
> 
> E.g.:
> 
> Without having audit-libs-devel installed:
> 
>   $ make NO_SYSCALL_TABLE=1 O=/tmp/build/perf -C tools/perf install-bin
>   make: Entering directory '/home/acme/git/perf/tools/perf'
> BUILD:   Doing 'make -j12' parallel build
>   
>   Auto-detecting system features:
>   
>   ...  libaudit: [ OFF ]
>   ...libbfd: [ on  ]
>   ...libcap: [ on  ]
>   
>   Makefile.config:664: No libaudit.h found, disables 'trace' tool, please 
> install audit-libs-devel or libaudit-dev
>   
> 
> After installing it:
> 
>   $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf
>   $ time make NO_SYSCALL_TABLE=1 O=/tmp/build/perf  -C tools/perf install-bin 
> ; perf test python

heya,
seems ok, perhaps also put it in comment to Makefile.perf
among other NO_* stuff and to tests/make

jirka

>   make: Entering directory '/home/acme/git/perf/tools/perf'
> BUILD:   Doing 'make -j12' parallel build
> HOSTCC   /tmp/build/perf/fixdep.o
> HOSTLD   /tmp/build/perf/fixdep-in.o
> LINK /tmp/build/perf/fixdep
>   Warning: Kernel ABI header at 'tools/arch/x86/include/asm/msr-index.h' 
> differs from latest version at 'arch/x86/include/asm/msr-index.h'
>   diff -u tools/arch/x86/include/asm/msr-index.h 
> arch/x86/include/asm/msr-index.h
>   Warning: Kernel ABI header at 'tools/perf/util/hashmap.h' differs from 
> latest version at 'tools/lib/bpf/hashmap.h'
>   diff -u tools/perf/util/hashmap.h tools/lib/bpf/hashmap.h
>   Warning: Kernel ABI header at 'tools/perf/util/hashmap.c' differs from 
> latest version at 'tools/lib/bpf/hashmap.c'
>   diff -u tools/perf/util/hashmap.c tools/lib/bpf/hashmap.c
> 
>   Auto-detecting system features:
>   
>   ...  libaudit: [ on  ]
>   ...libbfd: [ on  ]
>   ...libcap: [ on  ]
>   
>   $ ldd ~/bin/perf | grep audit
>   libaudit.so.1 => /lib64/libaudit.so.1 (0x7fc18978e000)
>   $
> 
> Cc: Adrian Hunter 
> Cc: Ingo Molnar 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Signed-off-by: Arnaldo Carvalho de Melo 
> ---
>  tools/perf/Makefile.config | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 93fb7510a9a9..6bc9251f1634 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -24,20 +24,22 @@ $(call detected_var,SRCARCH)
>  
>  NO_PERF_REGS := 1
>  
> -NO_SYSCALL_TABLE := 1
> +ifneq ($(NO_SYSCALL_TABLE),1)
> +  NO_SYSCALL_TABLE := 1
>  
> -ifeq ($(SRCARCH),x86)
> -  ifeq (${IS_64_BIT}, 1)
> -NO_SYSCALL_TABLE := 0
> -  endif
> -else
> -  ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
> -NO_SYSCALL_TABLE := 0
> +  ifeq ($(SRCARCH),x86)
> +ifeq (${IS_64_BIT}, 1)
> +  NO_SYSCALL_TABLE := 0
> +endif
> +  else
> +ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
> +  NO_SYSCALL_TABLE := 0
> +endif
>endif
> -endif
>  
> -ifneq ($(NO_SYSCALL_TABLE),1)
> -  CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
> +  ifneq ($(NO_SYSCALL_TABLE),1)
> +CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
> +  endif
>  endif
>  
>  # Additional ARCH settings for ppc
> -- 
> 2.25.3
> 

Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone

[Pavel Machek]

Hi!

Plus, do we need calibration matrix for magnetometer?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH V6 1/5] dt-bindings: clock: add ipq6018 a53 pll compatible

[Rob Herring]

On Wed, May 27, 2020 at 05:54:48PM +0530, Sivaprakash Murugesan wrote:
> cpus on ipq6018 are clocked by a53 pll, add device compatible for a53
> pll found on ipq6018 devices.
> 
> Signed-off-by: Sivaprakash Murugesan 
> ---
> * [V6]
> re-ordered compatible string, dropped Rob's review tag for this change.

Not really significant enough to drop it, but if you really want me to 
stare at this again...

>  .../devicetree/bindings/clock/qcom,a53pll.yaml | 18 
> ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml 
> b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
> index 20d2638..a4f2d01 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
> @@ -15,6 +15,7 @@ description:
>  
>  properties:
>compatible:
> +const: qcom,ipq6018-a53pll
>  const: qcom,msm8916-a53pll
>  
>reg:
> @@ -23,6 +24,14 @@ properties:
>'#clock-cells':
>  const: 0
>  
> +  clocks:
> +items:
> +  - description: board XO clock
> +
> +  clock-names:
> +items:
> +  - const: xo
> +
>  required:
>- compatible
>- reg
> @@ -38,3 +47,12 @@ examples:
>  reg = <0xb016000 0x40>;
>  #clock-cells = <0>;
>  };
> +  #Example 2 - A53 PLL found on IPQ6018 devices
> +  - |
> +a53pll_ipq: clock@b116000 {

clock-controller@...

> +compatible = "qcom,ipq6018-a53pll";
> +reg = <0x0b116000 0x40>;
> +#clock-cells = <0>;
> +clocks = <&xo>;
> +clock-names = "xo";
> +};
> -- 
> 2.7.4
> 

Re: [PATCH v7 1/4] bitops: Introduce the the for_each_set_clump macro

[Syed Nayyar Waris]

On Sun, May 24, 2020 at 8:15 PM kbuild test robot  wrote:
>
> Hi Syed,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce]
>
> url:
> https://github.com/0day-ci/linux/commits/Syed-Nayyar-Waris/Introduce-the-for_each_set_clump-macro/20200524-130931
> base:b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
> reproduce (this is a W=1 build):
> # save the attached .config to linux build tree
> make ARCH=i386
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot 
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
> In file included from include/asm-generic/atomic-instrumented.h:20:0,
> from arch/x86/include/asm/atomic.h:265,
> from include/linux/atomic.h:7,
> from include/linux/crypto.h:15,
> from arch/x86/kernel/asm-offsets.c:9:
> include/linux/bitmap.h: In function 'bitmap_get_value':
> include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> ^~~
> >> include/linux/bitmap.h:590:35: note: in expansion of macro 'GENMASK'
> return (map[index] >> offset) & GENMASK(nbits - 1, 0);
> ^~~
> include/linux/bits.h:26:40: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> ^~~
> >> include/linux/bitmap.h:590:35: note: in expansion of macro 'GENMASK'
> return (map[index] >> offset) & GENMASK(nbits - 1, 0);
> ^~~
> include/linux/bitmap.h: In function 'bitmap_set_value':
> include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> ^~~
> include/linux/bitmap.h:630:11: note: in expansion of macro 'GENMASK'
> value &= GENMASK(nbits - 1, 0);
> ^~~
> include/linux/bits.h:26:40: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> ^~~
> include/linux/bitmap.h:630:11: note: in expansion of macro 'GENMASK'
> value &= GENMASK(nbits - 1, 0);
> ^~~
> --
> In file included from include/linux/bits.h:23:0,
> from include/linux/bitops.h:5,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/x86/include/asm/bug.h:83,
> from include/linux/bug.h:5,
> from include/linux/mmdebug.h:5,
> from include/linux/gfp.h:5,
> from arch/x86/mm/init.c:1:
> include/linux/bitmap.h: In function 'bitmap_get_value':
> include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> ^~~
> >> include/linux/bitmap.h:590:35: note: in expansion of macro 'GENMASK'
> return (map[index] >> offset) & GENMASK(nbits - 1, 0);
> ^~~
> include/linux/bits.h:26:40: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> ^
> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> 

Re: [PATCH V6 3/5] clk: qcom: Add DT bindings for ipq6018 apss clock controller

[Rob Herring]

On Wed, 27 May 2020 17:54:50 +0530, Sivaprakash Murugesan wrote:
> Add dt-binding for ipq6018 apss clock controller
> 
> Signed-off-by: Sivaprakash Murugesan 
> ---
> [V6]
>  * Addressed review comment from Stephen
>  include/dt-bindings/clock/qcom,apss-ipq.h | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 include/dt-bindings/clock/qcom,apss-ipq.h
> 

Acked-by: Rob Herring 

Re: [PATCH 1/4] sctp: add sctp_sock_set_nodelay

[David Teigland]

On Fri, May 29, 2020 at 02:09:40PM +0200, Christoph Hellwig wrote:
> Add a helper to directly set the SCTP_NODELAY sockopt from kernel space
> without going through a fake uaccess.

Ack, they look fine to me, thanks.
Dave

Re: general protection fault in inet_unhash

[Eric Dumazet]

On 5/29/20 10:32 AM, Eric Dumazet wrote:

> L2TP seems to use sk->sk_node to insert sockets into l2tp_ip_table, _and_ 
> uses l2tp_ip_prot.unhash == inet_unhash
> 
> So if/when BPF_CGROUP_RUN_PROG_INET_SOCK(sk) returns an error and 
> inet_create() calls sk_common_release()
> bad things happen, because inet_unhash() expects a valid hashinfo pointer.
> 
> I guess the following patch should fix this.
> 
> Bug has been there forever, but only BPF_CGROUP_RUN_PROG_INET_SOCK(sk) could 
> trigger it.
>

Official submission : 
https://patchwork.ozlabs.org/project/netdev/patch/20200529180838.107255-1-eduma...@google.com/

Re: [PATCH 08/30] KVM: nSVM: move map argument out of enter_svm_guest_mode

[Krish Sadhukhan]

On 5/29/20 8:39 AM, Paolo Bonzini wrote:

Unmapping the nested VMCB in enter_svm_guest_mode is a bit of a wart,
since the map is not used elsewhere in the function.  There are
just two calls, so move it there.



The last sentence sounds bit incomplete.

Also, does it make sense to mention the reason why unmapping is not 
required before we enter guest mode ?




Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/svm/nested.c | 14 ++
  arch/x86/kvm/svm/svm.c|  3 ++-
  arch/x86/kvm/svm/svm.h|  2 +-
  3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 8756c9f463fd..8e98d5e420a5 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -229,7 +229,7 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
  }
  
  void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

- struct vmcb *nested_vmcb, struct kvm_host_map *map)
+ struct vmcb *nested_vmcb)
  {
bool evaluate_pending_interrupts =
is_intercept(svm, INTERCEPT_VINTR) ||
@@ -304,8 +304,6 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 
vmcb_gpa,
svm->vmcb->control.pause_filter_thresh =
nested_vmcb->control.pause_filter_thresh;
  
-	kvm_vcpu_unmap(&svm->vcpu, map, true);

-
/* Enter Guest-Mode */
enter_guest_mode(&svm->vcpu);
  
@@ -368,10 +366,7 @@ int nested_svm_vmrun(struct vcpu_svm *svm)

nested_vmcb->control.exit_code_hi = 0;
nested_vmcb->control.exit_info_1  = 0;
nested_vmcb->control.exit_info_2  = 0;
-
-   kvm_vcpu_unmap(&svm->vcpu, &map, true);
-
-   return ret;
+   goto out;
}
  
  	trace_kvm_nested_vmrun(svm->vmcb->save.rip, vmcb_gpa,

@@ -414,7 +409,7 @@ int nested_svm_vmrun(struct vcpu_svm *svm)
copy_vmcb_control_area(hsave, vmcb);
  
  	svm->nested.nested_run_pending = 1;

-   enter_svm_guest_mode(svm, vmcb_gpa, nested_vmcb, &map);
+   enter_svm_guest_mode(svm, vmcb_gpa, nested_vmcb);
  
  	if (!nested_svm_vmrun_msrpm(svm)) {

svm->vmcb->control.exit_code= SVM_EXIT_ERR;
@@ -425,6 +420,9 @@ int nested_svm_vmrun(struct vcpu_svm *svm)
nested_svm_vmexit(svm);
}
  
+out:

+   kvm_vcpu_unmap(&svm->vcpu, &map, true);
+
return ret;
  }
  
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c

index feb96a410f2d..76b3f553815e 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3814,7 +3814,8 @@ static int svm_pre_leave_smm(struct kvm_vcpu *vcpu, const 
char *smstate)
if (kvm_vcpu_map(&svm->vcpu, gpa_to_gfn(vmcb), &map) == -EINVAL)
return 1;
nested_vmcb = map.hva;
-   enter_svm_guest_mode(svm, vmcb, nested_vmcb, &map);
+   enter_svm_guest_mode(svm, vmcb, nested_vmcb);
+   kvm_vcpu_unmap(&svm->vcpu, &map, true);
}
return 0;
  }
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 89fab75dd4f5..33e3f09d7a8e 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -395,7 +395,7 @@ static inline bool nested_exit_on_nmi(struct vcpu_svm *svm)
  }
  
  void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

- struct vmcb *nested_vmcb, struct kvm_host_map *map);
+ struct vmcb *nested_vmcb);
  int nested_svm_vmrun(struct vcpu_svm *svm);
  void nested_svm_vmloadsave(struct vmcb *from_vmcb, struct vmcb *to_vmcb);
  int nested_svm_vmexit(struct vcpu_svm *svm);

Re: [PATCH V5 0/9] Enable ext4 support for per-file/directory DAX operations

[Ira Weiny]

On Fri, May 29, 2020 at 12:17:17AM -0400, Theodore Y. Ts'o wrote:
> On Thu, May 28, 2020 at 10:54:41PM -0400, Theodore Y. Ts'o wrote:
> > 
> > Thanks, applied to the ext4-dax branch.
> > 
> 
> I spoke too soon.  While I tried merging with the ext4.git dev branch,
> a merge conflict made me look closer and I realize I needed to make
> the following changes (see diff between your patch set and what is
> currently in ext4-dax).
> 
> Essentially, I needed to rework the branch to take into account commit
> e0198aff3ae3 ("ext4: reject mount options not supported when
> remounting in handle_mount_opt()").
> 
> The problem is that if you allow handle_mount_opt() to apply the
> changes to the dax settings, and then later on, ext4_remount() realize
> that we're remounting, and we need to reject the change, there's a
> race if we restore the mount options to the original configuration.
> Specifically, as Syzkaller pointed out, between when we change the dax
> settings and then reset them, it's possible for some file to be opened
> with "wrong" dax setting, and then when they are reset, *boom*.
> 
> The correct way to deal with this is to reject the mount option change
> much earlier, in handle_mount_opt(), *before* we mess with the dax
> settings.
> 
> Please take a look at the ext4-dax for the actual changes which I
> made.
> 
> Cheers,
> 
>   - Ted
> 
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 3658e3016999..9a37d70394b2 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1733,7 +1733,7 @@ static int clear_qf_name(struct super_block *sb, int 
> qtype)
>  #define MOPT_NO_EXT3 0x0200
>  #define MOPT_EXT4_ONLY   (MOPT_NO_EXT2 | MOPT_NO_EXT3)
>  #define MOPT_STRING  0x0400
> -#define MOPT_SKIP0x0800

I think we still need MOPT_SKIP...

This was put in to skip these options when printing to deal with printing only
dax=inode when it was specified by the user.

Ah but I see now.  By taking MOPT_SET away you have created the same behavior?

This is  orthogonal to the remount issue right?

> +#define MOPT_NO_REMOUNT  0x0800
>  
>  static const struct mount_opts {
>   int token;
> @@ -1783,18 +1783,15 @@ static const struct mount_opts {
>   {Opt_min_batch_time, 0, MOPT_GTE0},
>   {Opt_inode_readahead_blks, 0, MOPT_GTE0},
>   {Opt_init_itable, 0, MOPT_GTE0},
> - {Opt_dax, EXT4_MOUNT_DAX_ALWAYS, MOPT_SET | MOPT_SKIP},
> - {Opt_dax_always, EXT4_MOUNT_DAX_ALWAYS,
> - MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
> - {Opt_dax_inode, EXT4_MOUNT2_DAX_INODE,
> - MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
> - {Opt_dax_never, EXT4_MOUNT2_DAX_NEVER,
> - MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
> + {Opt_dax, 0, MOPT_NO_REMOUNT},
> + {Opt_dax_always, 0, MOPT_NO_REMOUNT},
> + {Opt_dax_inode, 0, MOPT_NO_REMOUNT},
> + {Opt_dax_never, 0, MOPT_NO_REMOUNT},

Even if MOPT_SET is redundant.  Why don't we need still need MOPT_EXT4_ONLY?

And why don't we need to associate the defines; EXT4_MOUNT_DAX_ALWAYS etc?

>   {Opt_stripe, 0, MOPT_GTE0},
>   {Opt_resuid, 0, MOPT_GTE0},
>   {Opt_resgid, 0, MOPT_GTE0},
> - {Opt_journal_dev, 0, MOPT_NO_EXT2 | MOPT_GTE0},
> - {Opt_journal_path, 0, MOPT_NO_EXT2 | MOPT_STRING},
> + {Opt_journal_dev, 0, MOPT_NO_EXT2 | MOPT_GTE0 | MOPT_NO_REMOUNT},
> + {Opt_journal_path, 0, MOPT_NO_EXT2 | MOPT_STRING | MOPT_NO_REMOUNT},
>   {Opt_journal_ioprio, 0, MOPT_NO_EXT2 | MOPT_GTE0},
>   {Opt_data_journal, EXT4_MOUNT_JOURNAL_DATA, MOPT_NO_EXT2 | MOPT_DATAJ},
>   {Opt_data_ordered, EXT4_MOUNT_ORDERED_DATA, MOPT_NO_EXT2 | MOPT_DATAJ},
> @@ -1831,7 +1828,7 @@ static const struct mount_opts {
>   {Opt_jqfmt_vfsv1, QFMT_VFS_V1, MOPT_QFMT},
>   {Opt_max_dir_size_kb, 0, MOPT_GTE0},
>   {Opt_test_dummy_encryption, 0, MOPT_GTE0},
> - {Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET},
> + {Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET | MOPT_NO_REMOUNT},
>   {Opt_err, 0, 0}
>  };
>  
> @@ -1929,6 +1926,12 @@ static int handle_mount_opt(struct super_block *sb, 
> char *opt, int token,
>"Mount option \"%s\" incompatible with ext3", opt);
>   return -1;
>   }
> + if ((m->flags & MOPT_NO_REMOUNT) && is_remount) {
> + ext4_msg(sb, KERN_ERR,
> +  "Mount option \"%s\" not supported when remounting",
> +  opt);
> + return -1;
> + }

I think this is cleaner!

Thanks, I did test this but not while trying to manipulate files as the same 
time
as a remount.  So a race would not have been caught.

Thanks!
Ira

>  
>   if (args->from && !(m->flags & MOPT_STRING) && match_int(args, &arg))
>   return -1;
> @@ -2008,11 +2011,6 @@ static int handle_mount_opt(struct super_block *sb, 
> char *opt, int token,
>   }
>   sbi->s_resgid = gid;
>   } else if (token == Opt_journal_dev) {
> -  

Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

[Rob Herring]

On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> Rob,
> Could you pay attention to this patch? The patchset review procedure is
> nearly over, while the DT part is only partly reviewed by you.

Pretty sure I commented on this. Not sure what version, you're sending 
new versions too fast. Give people time to review.

> 
> Thanks
> -Sergey
> 
> On Wed, May 27, 2020 at 06:30:37PM +0300, Serge Semin wrote:
> > dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> > i2c "reg" property. If it is the compiler will print a warning:
> > 
> > Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64: I2C bus unit 
> > address format error, expected "4064"
> > Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64:reg: I2C address 
> > must be less than 10-bits, got "0x4064"
> > 
> > In order to silence dtc up let's discard the flag from the DW I2C DT
> > binding example for now. Just revert this commit when dtc is fixed.
> > 
> > Signed-off-by: Serge Semin 
> > Cc: Alexey Malahov 
> > Cc: Thomas Bogendoerfer 
> > Cc: Andy Shevchenko 
> > Cc: Mika Westerberg 
> > Cc: linux-m...@vger.kernel.org
> > 
> > ---
> > 
> > Changelog v3:
> > - This is a new patch created as a result of the Rob request to remove
> >   the EEPROM-slave bit setting in the DT binndings example until the dtc
> >   is fixed.
> > ---
> >  Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml 
> > b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > index 4bd430b2b41d..101d78e8f19d 100644
> > --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > @@ -137,7 +137,7 @@ examples:
> >  
> >eeprom@64 {
> >  compatible = "linux,slave-24c02";
> > -reg = <0x4064>;
> > +reg = <0x64>;

This is wrong though because "linux,slave-24c02" should have bit 30 set. 
(And either the unit-address was wrong or we can define the unit-address 
does not include the high bits.)

Rob

Re: [PATCH 8/8] blk-mq: drain I/O when all CPUs in a hctx are offline

[Paul E. McKenney]

On Fri, May 29, 2020 at 11:53:15AM +0800, Ming Lei wrote:
> Hi Paul,
> 
> On Thu, May 28, 2020 at 08:07:28PM -0700, Paul E. McKenney wrote:
> > On Fri, May 29, 2020 at 09:53:04AM +0800, Ming Lei wrote:
> > > Hi Paul,
> > > 
> > > Thanks for your response!
> > > 
> > > On Thu, May 28, 2020 at 10:21:21AM -0700, Paul E. McKenney wrote:
> > > > On Thu, May 28, 2020 at 06:37:47AM -0700, Bart Van Assche wrote:
> > > > > On 2020-05-27 22:19, Ming Lei wrote:
> > > > > > On Wed, May 27, 2020 at 08:33:48PM -0700, Bart Van Assche wrote:
> > > > > >> My understanding is that operations that have acquire semantics 
> > > > > >> pair
> > > > > >> with operations that have release semantics. I haven't been able 
> > > > > >> to find
> > > > > >> any documentation that shows that smp_mb__after_atomic() has 
> > > > > >> release
> > > > > >> semantics. So I looked up its definition. This is what I found:
> > > > > >>
> > > > > >> $ git grep -nH 'define __smp_mb__after_atomic'
> > > > > >> arch/ia64/include/asm/barrier.h:49:#define __smp_mb__after_atomic()
> > > > > >> barrier()
> > > > > >> arch/mips/include/asm/barrier.h:133:#define 
> > > > > >> __smp_mb__after_atomic()
> > > > > >> smp_llsc_mb()
> > > > > >> arch/s390/include/asm/barrier.h:50:#define __smp_mb__after_atomic()
> > > > > >> barrier()
> > > > > >> arch/sparc/include/asm/barrier_64.h:57:#define 
> > > > > >> __smp_mb__after_atomic()
> > > > > >> barrier()
> > > > > >> arch/x86/include/asm/barrier.h:83:#define __smp_mb__after_atomic() 
> > > > > >> do {
> > > > > >> } while (0)
> > > > > >> arch/xtensa/include/asm/barrier.h:20:#define 
> > > > > >> __smp_mb__after_atomic()  
> > > > > >> barrier()
> > > > > >> include/asm-generic/barrier.h:116:#define __smp_mb__after_atomic()
> > > > > >> __smp_mb()
> > > > > >>
> > > > > >> My interpretation of the above is that not all 
> > > > > >> smp_mb__after_atomic()
> > > > > >> implementations have release semantics. Do you agree with this 
> > > > > >> conclusion?
> > > > > > 
> > > > > > I understand smp_mb__after_atomic() orders 
> > > > > > set_bit(BLK_MQ_S_INACTIVE)
> > > > > > and reading the tag bit which is done in blk_mq_all_tag_iter().
> > > > > > 
> > > > > > So the two pair of OPs are ordered:
> > > > > > 
> > > > > > 1) if one request(tag bit) is allocated before setting 
> > > > > > BLK_MQ_S_INACTIVE,
> > > > > > the tag bit will be observed in blk_mq_all_tag_iter() from 
> > > > > > blk_mq_hctx_has_requests(),
> > > > > > so the request will be drained.
> > > > > > 
> > > > > > OR
> > > > > > 
> > > > > > 2) if one request(tag bit) is allocated after setting 
> > > > > > BLK_MQ_S_INACTIVE,
> > > > > > the request(tag bit) will be released and retried on another CPU
> > > > > > finally, see __blk_mq_alloc_request().
> > > > > > 
> > > > > > Cc Paul and linux-kernel list.
> > > > > 
> > > > > I do not agree with the above conclusion. My understanding of
> > > > > acquire/release labels is that if the following holds:
> > > > > (1) A store operation that stores the value V into memory location M 
> > > > > has
> > > > > a release label.
> > > > > (2) A load operation that reads memory location M has an acquire 
> > > > > label.
> > > > > (3) The load operation (2) retrieves the value V that was stored by 
> > > > > (1).
> > > > > 
> > > > > that the following ordering property holds: all load and store
> > > > > instructions that happened before the store instruction (1) in program
> > > > > order are guaranteed to happen before the load and store instructions
> > > > > that follow (2) in program order.
> > > > > 
> > > > > In the ARM manual these semantics have been described as follows: "A
> > > > > Store-Release instruction is multicopy atomic when observed with a
> > > > > Load-Acquire instruction".
> > > > > 
> > > > > In this case the load-acquire operation is the
> > > > > "test_and_set_bit_lock(nr, word)" statement from the sbitmap code. 
> > > > > That
> > > > > code is executed indirectly by blk_mq_get_tag(). Since there is no
> > > > > matching store-release instruction in __blk_mq_alloc_request() for
> > > > > 'word', ordering of the &data->hctx->state and 'tag' memory locations 
> > > > > is
> > > > > not guaranteed by the acquire property of the 
> > > > > "test_and_set_bit_lock(nr,
> > > > > word)" statement from the sbitmap code.
> > > > 
> > > > I feel like I just parachuted into the middle of the conversation,
> > > > so let me start by giving a (silly) example illustrating the limits of
> > > > smp_mb__{before,after}_atomic() that might be tangling things up.
> > > > 
> > > > But please please please avoid doing this in real code unless you have
> > > > an extremely good reason included in a comment.
> > > > 
> > > > void t1(void)
> > > > {
> > > > WRITE_ONCE(a, 1);
> > > > smp_mb__before_atomic();
> > > > WRITE_ONCE(b, 1);  // Just Say No to code here!!!
> > > > atomic_inc(&c);
> > > > WRITE_ONCE(d, 1);  // Just Say No to code here!!!
> > > >

Re: [PATCH v3 02/25] dt-bindings: clock: Add a binding for the RPi Firmware clocks

[Rob Herring]

On Wed, 27 May 2020 17:44:58 +0200, Maxime Ripard wrote:
> The firmware running on the RPi VideoCore can be used to discover and
> change the various clocks running in the BCM2711. Since devices will
> need to use them through the DT, let's add a pretty simple binding.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Rob Herring 
> Cc: linux-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml 
> | 24 
>  1 file changed, 24 insertions(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode

[Mark Brown]

On Sat, May 30, 2020 at 01:26:20AM +0800, Tzung-Bi Shih wrote:
> On Fri, May 29, 2020 at 9:05 PM Mark Brown  wrote:

> > I thought that was normal for DMICs - is this selecting between left and
> > right or something?

> Not sure what is the common name but use the same context here.

> MT6358 accepts up to 2 PDM wires for 2 DMICs.
> If one wire mode is on, MT6358 only accepts 1 PDM wire.
> If one wire mode is off, MT6358 merges L/R from 2 PDM wires into 1
> I2S-like to SoC.

Oh, interesting - so it's essentially a mixer?  Not seen that before but
makes sense.  In any case this definitely seems like a good fit for a DT
property.


signature.asc
Description: PGP signature

Re: [PATCH] spi: bcm2835: Enable shared interrupt support

[Lukas Wunner]

On Fri, May 29, 2020 at 11:03:48AM -0700, Florian Fainelli wrote:
> On 5/29/20 10:53 AM, Lukas Wunner wrote:
> > On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
> >> On 5/29/20 10:43 AM, Lukas Wunner wrote:
> >>> Finally, it would be nice if the check would be optimized away when
> >>> compiling for pre-RasPi4 products, maybe something like:
> >>>
> >>> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
> >>> + return IRQ_NONE;
> >>
> >> Rather than keying this off ARM_LPAE or any other option, this should be
> >> keyed off a compatible string, that way we can even conditionally pass
> >> IRQF_SHARED to the interrupt handler if we care so much about performance.
> > 
> > But a compatible string can't be checked at compile time, can it?
> 
> No, but you can have a different interrupt handler that it set at
> runtime if you want to completely eliminate this comparison.

Good idea.  In fact the IRQ handler for platforms with shared interrupts
could just be a wrapper which performs the BCM2835_SPI_CS_INTR check
then tail-calls the existing IRQ handler.  The compiler would just
inline it and everything would be fine.


> My point is that CONFIG_ARM_LPAE is just too brittle, there is nothing
> that prevents you from using a non-LPAE kernel on the Pi 4, even PCIe
> could be made to work if using super section mappings to map the PCIe
> outbound space. Even on models with over 4GB of DRAM, if you are willing
> to lose some of it, it can work.

Agreed.

Thanks,

Lukas

Re: [PATCH 0/2] x86/entry: simplify RESTORE_CR3

[Andy Lutomirski]

On Mon, May 25, 2020 at 9:35 PM Lai Jiangshan  wrote:
>
> When I searched percpu data touched by entry code for #DB
> protection[1], it seems to me RESTORE_CR3() does too much work,
> this patchset simplifies it.
>
> Patch 1 enhances 21e944591102("x86/mm: Optimize RESTORE_CR3") for
> kernel CR3.
>
> Patch 2 *reverts* 21e944591102("x86/mm: Optimize RESTORE_CR3") for
> User CR3.

This series looks correct, but I don't think it's 5.8 material.  I
also want to try moving all this code to C, so it's possible this
little series will become obsolete.

>
> Cc: Andy Lutomirski 
> Cc: Peter Zijlstra (Intel) 
> Cc: Thomas Gleixner 
> Cc: x...@kernel.org
> Link: 
> https://lore.kernel.org/lkml/20200525145102.122557-1-la...@linux.alibaba.com
> Lai Jiangshan (2):
>   x86/entry: Don't write to CR3 when restoring to kernel CR3
>   x86/entry: always flush user CR3 in RESTORE_CR3
>
>  arch/x86/entry/calling.h  | 36 
>  arch/x86/entry/entry_64.S |  6 +++---
>  2 files changed, 11 insertions(+), 31 deletions(-)
>
> --
> 2.20.1
>

Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

[Rob Herring]

On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 
> -
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0

Dual license...

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> +  - Eric Anholt 
> +
> +properties:
> +  compatible:
> +enum:
> +  - brcm,bcm2711-hdmi0
> +  - brcm,bcm2711-hdmi1

What's the difference between the 2 blocks? 

> +
> +  reg:
> +items:
> +  - description: HDMI controller register range
> +  - description: DVP register range
> +  - description: HDMI PHY register range
> +  - description: Rate Manager register range
> +  - description: Packet RAM register range
> +  - description: Metadata RAM register range
> +  - description: CSC register range
> +  - description: CEC register range
> +  - description: HD register range
> +
> +  reg-names:
> +items:
> +  - const: hdmi
> +  - const: dvp
> +  - const: phy
> +  - const: rm
> +  - const: packet
> +  - const: metadata
> +  - const: csc
> +  - const: cec
> +  - const: hd
> +
> +  clocks:
> +description: The HDMI state machine clock
> +
> +  clock-names:
> +const: hdmi
> +
> +  ddc:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> +  Phandle of the I2C controller used for DDC EDID probing

Goes in the connector.

And isn't the standard name ddc-i2c-bus?

> +
> +  hpd-gpios:
> +description: >
> +  The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> +  as an interrupt/status bit in the HDMI controller itself)

Goes in the connector.

> +
> +  dmas:
> +maxItems: 1
> +description: >
> +  Should contain one entry pointing to the DMA channel used to
> +  transfer audio data.
> +
> +  dma-names:
> +const: audio-rx
> +
> +  resets:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - resets
> +  - ddc
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> +  <0x7ef00300 0x200>,
> +  <0x7ef00f00 0x80>,
> +  <0x7ef00f80 0x80>,
> +  <0x7ef01b00 0x200>,
> +  <0x7ef01f00 0x400>,
> +  <0x7ef00200 0x80>,
> +  <0x7ef04300 0x100>,
> +  <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <&firmware_clocks 13>;
> +clock-names = "hdmi";
> +resets = <&dvp 0>;
> +ddc = <&ddc0>;
> +};
> +
> +...
> -- 
> git-series 0.9.1

Re: [PATCH v30 09/20] mm: Introduce vm_ops->may_mprotect()

[Jarkko Sakkinen]

On Fri, May 29, 2020 at 02:10:38PM +0200, Borislav Petkov wrote:
> On Fri, May 15, 2020 at 03:43:59AM +0300, Jarkko Sakkinen wrote:
> > From: Sean Christopherson 
> > 
> > Add vm_ops()->may_mprotect() to check additional constrains set by a
> 
> "constraints"
> 
> > subsystem for a mprotect() call.
> > 
> > Signed-off-by: Sean Christopherson 
> > Acked-by: Jethro Beekman 
> > Signed-off-by: Jarkko Sakkinen 
> > ---
> >  include/linux/mm.h |  2 ++
> >  mm/mprotect.c  | 14 +++---
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> This needs an ACK from an mm person.

Good point. I'll add the needed cc's.

/Jarkko

Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone

[Martin Kepplinger]

On 29.05.20 20:07, Pavel Machek wrote:
> Hi!
> 
> Plus, do we need calibration matrix for magnetometer?

I guess so. It's not a calibration matrix, it's the mount matrix that
tells you how the chip is placed on the PCB relative to a "natural"
orientation, see
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-iio#L1638

> 
> Best regards,
>   Pavel
> 

Re: [PATCH][next] RDMA/hns: remove duplicate assignment to pointer raq

[Jason Gunthorpe]

On Thu, May 28, 2020 at 04:04:27PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The pointer raq is being assigned twice. Fix this by removing
> one of the redundant assignments.
> 
> Fixes: 14ba87304bf9 ("RDMA/hns: Remove redundant type cast for general 
> pointers")
> Addressses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to for-next

Thanks,
Jason

Re: [GIT PULL] sh: remove sh5 support

[Christoph Hellwig]

On Fri, May 29, 2020 at 01:53:38PM -0400, Rich Felker wrote:
> Frustratingly, I _still_ don't have an official tree on kernel.org for
> the purpose of being the canonical place for linux-next to pull from,
> due to policies around pgp keys and nobody following up on signing
> mine. This is all really silly since there are ridiculously many
> independent channels I could cryptographically validate identity
> through with vanishing probability that they're all compromised. For
> the time being I'll reactivate my repo on git.musl-libc.org.

You don't need a kernel.org tree.  None of the trees I maintain are
hosted on kernel.org.  Just make sure you sign your tags.

Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

[Serge Semin]

On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> > Rob,
> > Could you pay attention to this patch? The patchset review procedure is
> > nearly over, while the DT part is only partly reviewed by you.
> 

> Pretty sure I commented on this. Not sure what version, you're sending 
> new versions too fast. Give people time to review.

Yeah, you did. Sorry for sending the new versions very fast. Normally I prefer
to keep up with comments so to past a particular maintainer review as fast as
possible without long delays. In my experience the longer you wait, the lesser
maintainers remember about your patchset, the harder for one to continue the
next versions review.

Regarding this patch the brand new version on is v6:
[PATCH v6 02/11] dt-bindings: i2c: Convert DW I2C slave to the DW I2C master 
example

Could you please find it in your email log? I've left a note there for you about
options what we can do with this case.

-Sergey

> 
> > 
> > Thanks
> > -Sergey
> > 
> > On Wed, May 27, 2020 at 06:30:37PM +0300, Serge Semin wrote:
> > > dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> > > i2c "reg" property. If it is the compiler will print a warning:
> > > 
> > > Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64: I2C bus unit 
> > > address format error, expected "4064"
> > > Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64:reg: I2C address 
> > > must be less than 10-bits, got "0x4064"
> > > 
> > > In order to silence dtc up let's discard the flag from the DW I2C DT
> > > binding example for now. Just revert this commit when dtc is fixed.
> > > 
> > > Signed-off-by: Serge Semin 
> > > Cc: Alexey Malahov 
> > > Cc: Thomas Bogendoerfer 
> > > Cc: Andy Shevchenko 
> > > Cc: Mika Westerberg 
> > > Cc: linux-m...@vger.kernel.org
> > > 
> > > ---
> > > 
> > > Changelog v3:
> > > - This is a new patch created as a result of the Rob request to remove
> > >   the EEPROM-slave bit setting in the DT binndings example until the dtc
> > >   is fixed.
> > > ---
> > >  Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml 
> > > b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > index 4bd430b2b41d..101d78e8f19d 100644
> > > --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > @@ -137,7 +137,7 @@ examples:
> > >  
> > >eeprom@64 {
> > >  compatible = "linux,slave-24c02";
> > > -reg = <0x4064>;
> > > +reg = <0x64>;
> 
> This is wrong though because "linux,slave-24c02" should have bit 30 set. 
> (And either the unit-address was wrong or we can define the unit-address 
> does not include the high bits.)
> 
> Rob

Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver

[Grygorii Strashko]

Hi Santosh,

On 12/05/2020 15:34, Grygorii Strashko wrote:

Hi All,

This series introduces TI K3 Multicore SoC platforms chipid module driver
which provides identification support of the TI K3 SoCs (family, revision)
and register this information with the SoC bus. It is available under
/sys/devices/soc0/ for user space, and can be checked, where needed,
in Kernel using soc_device_match().
It is also required for introducing support for new revisions of
K3 AM65x/J721E SoCs.

Example J721E:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments K3 J721E SoC
   J721E
   SR1.0

Example AM65x:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments AM654 Base Board
   AM65X
   SR1.0

Changes in v4:
  - convert to platform_driver as suggested by Arnd Bergmann 

Changes in v3:
  - add handling of kasprintf() fail

Changes in v2:
  - pr_debug() replaced with pr_info() to show SoC info on init
  - minor format change
  - split series on driver and platform changes
  - add Reviewed-by: Lokesh Vutla 

v3: https://lkml.org/lkml/2020/5/8/357
v2: https://lkml.org/lkml/2020/5/5/1193
v1: https://lwn.net/Articles/818577/

Grygorii Strashko (2):
   dt-bindings: soc: ti: add binding for k3 platforms chipid module
   soc: ti: add k3 platforms chipid module driver

  .../bindings/soc/ti/k3-socinfo.yaml   |  40 +
  drivers/soc/ti/Kconfig|  10 ++
  drivers/soc/ti/Makefile   |   1 +
  drivers/soc/ti/k3-socinfo.c   | 152 ++
  4 files changed, 203 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
  create mode 100644 drivers/soc/ti/k3-socinfo.c



Any chances you can pick this up?

--
Best regards,
grygorii

Re: [PATCH net-next v4 1/4] dt-bindings: net: Add tx and rx internal delays

[Rob Herring]

On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
> 
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid.  These modes indicate to the
> controller that the PHY will add the internal delay for the connection.
> 
> Signed-off-by: Dan Murphy 
> ---
>  .../bindings/net/ethernet-controller.yaml  | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml 
> b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> index ac471b60ed6a..70702a4ef5e8 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> @@ -143,6 +143,20 @@ properties:
>Specifies the PHY management type. If auto is set and fixed-link
>is not specified, it uses MDIO for management.
>  
> +  rx-internal-delay-ps:
> +$ref: /schemas/types.yaml#definitions/uint32
> +description: |
> +  RGMII Receive PHY Clock Delay defined in pico seconds.  This is used 
> for
> +  PHY's that have configurable RX internal delays.  This property is only
> +  used when the phy-mode or phy-connection-type is rgmii-id or 
> rgmii-rxid.

Isn't this a property of the phy (this is the controller schema)? Looks 
like we have similar properties already and they go in phy nodes. Would 
be good to have a standard property, but let's be clear where it goes.

We need to add '-ps' as a standard unit suffix (in dt-schema) and then a 
type is not needed here.

Rob

[PATCH v7] dt-bindings: spi: Convert DW SPI binding to DT schema

[Serge Semin]

Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces two DW SPI legacy
bare text bindings with YAML file. As before the bindings file states
that the corresponding dts node is supposed to be compatible either
with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
vendors-specific controllers, to have registers, interrupts and clocks
properties. Though in case of Microsemi version of the controller
there must be two registers resources specified. Properties like
clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
sub-nodes are optional.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Feng Tang 
Cc: Andy Shevchenko 
Cc: Arnd Bergmann 
Cc: linux-m...@vger.kernel.org

---

Changelog v7:
- Rebase on top of the spi/for-next branch.
- Add resets and reset-names properties, since Dinh Nguyen has slipped the
  patchset optional reset-support in right in front of my nose.
---
 .../bindings/spi/snps,dw-apb-ssi.txt  |  49 ---
 .../bindings/spi/snps,dw-apb-ssi.yaml | 133 ++
 .../devicetree/bindings/spi/spi-dw.txt|  24 
 3 files changed, 133 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt

diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt 
b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
deleted file mode 100644
index 0f21407a7ea3..
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
-
-Required properties:
-- compatible : "snps,dw-apb-ssi" or "mscc,-spi", where soc is "ocelot" or
-  "jaguar2", or "amazon,alpine-dw-apb-ssi", or "snps,dwc-ssi-1.01a" or
-  "intel,keembay-ssi"
-- reg : The register base for the controller. For "mscc,-spi", a second
-  register set is required (named ICPU_CFG:SPI_MST)
-- interrupts : One interrupt, used by the controller.
-- #address-cells : <1>, as required by generic SPI binding.
-- #size-cells : <0>, also as required by generic SPI binding.
-- clocks : phandles for the clocks, see the description of clock-names below.
-   The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock
-   is optional. If a single clock is specified but no clock-name, it is the
-   "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
-
-Optional properties:
-- clock-names : Contains the names of the clocks:
-"ssi_clk", for the core clock used to generate the external SPI clock.
-"pclk", the interface clock, required for register access. If a clock 
domain
- used to enable this clock then it should be named "pclk_clkdomain".
-- cs-gpios : Specifies the gpio pins to be used for chipselects.
-- num-cs : The number of chipselects. If omitted, this will default to 4.
-- reg-io-width : The I/O register width (in bytes) implemented by this
-  device.  Supported values are 2 or 4 (the default).
-- dmas : Phandle + identifiers of Tx and Rx DMA channels.
-- dma-names : Contains the names of the DMA channels. Must be "tx" and "rx".
-- resets : contains an entry for each entry in reset-names.
-  See ../reset/reset.txt for details.
-- reset-names : must contain "spi"
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
-   spi@fff0 {
-   compatible = "snps,dw-apb-ssi";
-   reg = <0xfff0 0x1000>;
-   interrupts = <0 154 4>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = <&spi_m_clk>;
-   num-cs = <2>;
-   cs-gpios = <&gpio0 13 0>,
-  <&gpio0 14 0>;
-   resets = <&rst SPIM0_RST>;
-   reset-names = "spi";
-   };
-
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml 
b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
new file mode 100644
index ..c62cbe79f00d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/snps,dw-apb-ssi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface
+
+maintainers:
+  - Mark Brown 
+
+allOf:
+  - $ref: "spi-controller.yaml#"
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - mscc,ocelot-spi
+  - mscc,jaguar2-spi
+then:
+  properties:
+reg:
+  minItems: 2
+
+properties:
+  compatible:
+oneOf:
+  - description: Generic DW SPI C

Re: [PATCH 10/30] KVM: nSVM: extract preparation of VMCB for nested run

[Krish Sadhukhan]

On 5/29/20 8:39 AM, Paolo Bonzini wrote:

Split out filling svm->vmcb.save and svm->vmcb.control before VMRUN.
Only the latter will be useful when restoring nested SVM state.

This patch introduces no semantic change, so the MMU setup is still
done in nested_prepare_vmcb_save.  The next patch will clean up things.

Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/svm/nested.c | 40 +++
  1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index fc0c6d1678eb..73be7af79453 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -245,21 +245,8 @@ static void load_nested_vmcb_control(struct vcpu_svm *svm,
svm->vcpu.arch.tsc_offset += control->tsc_offset;
  }
  
-void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

- struct vmcb *nested_vmcb)
+static void nested_prepare_vmcb_save(struct vcpu_svm *svm, struct vmcb 
*nested_vmcb)



Not a big deal, but I feel that it helps a lot in readability if we keep 
the names symmetric. This one could be named prepare_nested_vmcb_save to 
match load_nested_vmcb_control that you created in the previous patch. 
Or load_nested_vmcb_control could be renamed to nested_load_vmcb_control 
to match the name here.



  {
-   bool evaluate_pending_interrupts =
-   is_intercept(svm, INTERCEPT_VINTR) ||
-   is_intercept(svm, INTERCEPT_IRET);
-
-   svm->nested.vmcb = vmcb_gpa;
-   if (kvm_get_rflags(&svm->vcpu) & X86_EFLAGS_IF)
-   svm->vcpu.arch.hflags |= HF_HIF_MASK;
-   else
-   svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
-
-   load_nested_vmcb_control(svm, &nested_vmcb->control);
-
if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE)
nested_svm_init_mmu_context(&svm->vcpu);
  
@@ -291,7 +278,10 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

svm->vmcb->save.dr7 = nested_vmcb->save.dr7;
svm->vcpu.arch.dr6  = nested_vmcb->save.dr6;
svm->vmcb->save.cpl = nested_vmcb->save.cpl;
+}
  
+static void nested_prepare_vmcb_control(struct vcpu_svm *svm, struct vmcb *nested_vmcb)

+{
svm_flush_tlb(&svm->vcpu);
if (nested_vmcb->control.int_ctl & V_INTR_MASKING_MASK)
svm->vcpu.arch.hflags |= HF_VINTR_MASK;
@@ -321,6 +311,26 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 
vmcb_gpa,
 */
recalc_intercepts(svm);
  
+	mark_all_dirty(svm->vmcb);

+}
+
+void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
+ struct vmcb *nested_vmcb)
+{
+   bool evaluate_pending_interrupts =
+   is_intercept(svm, INTERCEPT_VINTR) ||
+   is_intercept(svm, INTERCEPT_IRET);
+
+   svm->nested.vmcb = vmcb_gpa;
+   if (kvm_get_rflags(&svm->vcpu) & X86_EFLAGS_IF)
+   svm->vcpu.arch.hflags |= HF_HIF_MASK;
+   else
+   svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
+
+   load_nested_vmcb_control(svm, &nested_vmcb->control);
+   nested_prepare_vmcb_save(svm, nested_vmcb);
+   nested_prepare_vmcb_control(svm, nested_vmcb);
+
/*
 * If L1 had a pending IRQ/NMI before executing VMRUN,
 * which wasn't delivered because it was disallowed (e.g.
@@ -336,8 +346,6 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 
vmcb_gpa,
enable_gif(svm);
if (unlikely(evaluate_pending_interrupts))
kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
-
-   mark_all_dirty(svm->vmcb);
  }
  
  int nested_svm_vmrun(struct vcpu_svm *svm)

Re: [PATCH] x86/resctrl: fix a NULL vs IS_ERR() static checker warning

[Reinette Chatre]

Hi Dan,

On 5/29/2020 5:27 AM, Dan Carpenter wrote:
> The callers don't expect *d_cdp to be set to an error pointer, they only
> check for NULL.  This leads to a static checker warning:
> 
> arch/x86/kernel/cpu/resctrl/rdtgroup.c:2648 __init_one_rdt_domain()
> warn: 'd_cdp' could be an error pointer
> 
> I don't think this will lead to a real life bug, but it's easy enough to
> change it to be NULL.

Using "I don't think" could be a bit vague to the reader. It could be
changed to:

"This would not trigger a bug in this specific case because
__init_one_rdt_domain() calls it with a valid domain that would not have
a negative id and thus not trigger the return of the ERR_PTR(). If this
was a negative domain id then the call to rdt_find_domain() in
domain_add_cpu() would have returned the ERR_PTR() much earlier and the
creation of the domain with an invalid id would have been prevented.

Even though a bug is not triggered currently the right and safe thing to
do is to set the pointer to NULL because that is what can be checked for
when the caller is handling the CDP and non-CDP cases."


> 
> Signed-off-by: Dan Carpenter 
> ---
>  arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c 
> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 23b4b61319d3f..3f844f14fc0a6 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -1117,6 +1117,7 @@ static int rdt_cdp_peer_get(struct rdt_resource *r, 
> struct rdt_domain *d,
>   _d_cdp = rdt_find_domain(_r_cdp, d->id, NULL);
>   if (WARN_ON(IS_ERR_OR_NULL(_d_cdp))) {
>   _r_cdp = NULL;
> + _d_cdp = NULL;
>   ret = -EINVAL;
>   }
>  
> 


The below fixes tag may be helpful:
Fixes: 52eb74339a62 ("x86/resctrl: Fix rdt_find_domain() return value
and checks")

Thank you very much for catching this and sending a fix. I just have the
commit message comments, apart from that the your fix looks good to me.

Acked-by: Reinette Chatre 

Reinette

Re: [PATCH][next] IB/hfi1: fix spelling mistake "enought" -> "enough"

[Jason Gunthorpe]

On Thu, May 28, 2020 at 12:07:09PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> There is a spelling mistake in an error message. Fix it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/hw/hfi1/chip.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to for-next, thanks

Jason

Re: [PATCH v30 09/20] mm: Introduce vm_ops->may_mprotect()

[Dave Hansen]

On 5/14/20 5:43 PM, Jarkko Sakkinen wrote:
> From: Sean Christopherson 
> 
> Add vm_ops()->may_mprotect() to check additional constrains set by a
> subsystem for a mprotect() call.

This changelog needs some more detail about why this is needed.  It
would also be nice to include thought about what else it could get used
for and what subsystems can expect by doing this and what the mm core is
expected to do.

Re: [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations

[Randy Dunlap]

On 5/29/20 10:25 AM, Josh Poimboeuf wrote:
> On Fri, May 29, 2020 at 06:54:19PM +0200, Peter Zijlstra wrote:
>> On Fri, May 29, 2020 at 11:50:11AM -0500, Josh Poimboeuf wrote:
>>> The nested likelys seem like overkill anyway -- user_access_begin() is
>>> __always_inline and it already has unlikely(), which should be
>>> propagated.
>>>
>>> So just remove the outer likelys?
>>
>> That fixes it. Ack!
> 
> If there are no objections to the patch, I can add it to my objtool-core
> branch unless anybody else wants to take it.  It only affects
> linux-next.
> 
> ---8<---
> 
> From: Josh Poimboeuf 
> Subject: [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations
> 
> Since user_access_begin() already has an unlikely() annotation for its
> access_ok() check, "if (likely(user_access_begin))" results in nested
> likely annotations.  When combined with CONFIG_TRACE_BRANCH_PROFILING,
> GCC converges the error/success paths of the nested ifs, using a
> register value to distinguish between them.
> 
> While the code is technically uaccess safe, it complicates the
> branch-profiling generated code.  It also confuses objtool, because it
> doesn't do register value tracking, resulting in the following warnings:
> 
>   arch/x86/lib/csum-wrappers_64.o: warning: objtool: 
> csum_and_copy_from_user()+0x2a4: call to memset() with UACCESS enabled
>   arch/x86/lib/csum-wrappers_64.o: warning: objtool: 
> csum_and_copy_to_user()+0x243: return with UACCESS enabled
> 
> The outer likely annotations aren't actually needed anyway, since the
> compiler propagates the error path coldness when it inlines
> user_access_begin().
> 
> Fixes: 18372ef87665 ("x86_64: csum_..._copy_..._user(): switch to 
> unsafe_..._user()")
> Reported-by: Randy Dunlap 
> Acked-by: Peter Zijlstra 
> Signed-off-by: Josh Poimboeuf 

Acked-by: Randy Dunlap  # build-tested

Thanks.

> ---
>  arch/x86/lib/csum-wrappers_64.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/lib/csum-wrappers_64.c b/arch/x86/lib/csum-wrappers_64.c
> index a12b8629206d..ee63d7576fd2 100644
> --- a/arch/x86/lib/csum-wrappers_64.c
> +++ b/arch/x86/lib/csum-wrappers_64.c
> @@ -27,7 +27,7 @@ csum_and_copy_from_user(const void __user *src, void *dst,
>   might_sleep();
>   *errp = 0;
>  
> - if (!likely(user_access_begin(src, len)))
> + if (!user_access_begin(src, len))
>   goto out_err;
>  
>   /*
> @@ -89,7 +89,7 @@ csum_and_copy_to_user(const void *src, void __user *dst,
>  
>   might_sleep();
>  
> - if (unlikely(!user_access_begin(dst, len))) {
> + if (!user_access_begin(dst, len)) {
>   *errp = -EFAULT;
>   return 0;
>   }
> 


-- 
~Randy

Re: [PATCH V2 0/4] x86/entry: simply stack switching when exception on userspace

[Andy Lutomirski]

On Fri, May 29, 2020 at 1:26 AM Lai Jiangshan  wrote:
>
> 7f2590a110b8("x86/entry/64: Use a per-CPU trampoline stack for IDT entries")
> has resulted that when exception on userspace, the kernel (error_entry)
> always push the pt_regs to entry stack(sp0), and then copy them to the
> kernel stack.
>
> And recent x86/entry work makes interrupt also use idtentry
> and makes all the interrupt code save the pt_regs on the sp0 stack
> and then copy it to the thread stack like exception.
>
> This is hot path (page fault, ipi), such overhead should be avoided.
> And the original interrupt_entry directly switches to kernel stack
> and pushes pt_regs to kernel stack. We should do it for error_entry.
> This is the job of patch1.
>
> Patch 2-4 simply stack switching for .Lerror_bad_iret by just doing
> all the work in one function (fixup_bad_iret()).
>
> The patch set is based on tip/x86/entry (28447ea41542) (May 20).

There are definitely good cleanups in here, but I think it would be
nice rebased to whatever lands in 5.8-rc1 settles.

--Andy

Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver

[Arnd Bergmann]

On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
 wrote:
> On 12/05/2020 15:34, Grygorii Strashko wrote:

> >   .../bindings/soc/ti/k3-socinfo.yaml   |  40 +
> >   drivers/soc/ti/Kconfig|  10 ++
> >   drivers/soc/ti/Makefile   |   1 +
> >   drivers/soc/ti/k3-socinfo.c   | 152 ++
> >   4 files changed, 203 insertions(+)
> >   create mode 100644 
> > Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
> >   create mode 100644 drivers/soc/ti/k3-socinfo.c
> >
>
> Any chances you can pick this up?

I merged a version of this driver from Santosh's pull request into the
arm/drviers tree yesterday.

Is there something missing?

   Arnd

Re: [PATCH v3 3/6] hwmon: pmbus: adm1266: Add support for GPIOs

[Guenter Roeck]

On 5/29/20 6:05 AM, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici 
> 
> Adm1266 exposes 9 GPIOs and 16 PDIOs which are currently read-only. They
> are controlled by the internal sequencing engine.
> 
> This patch makes adm1266 driver expose GPIOs and PDIOs to user-space
> using GPIO provider kernel api.
> 
> Signed-off-by: Alexandru Tachici 
> ---
>  drivers/hwmon/pmbus/adm1266.c | 233 +-
>  1 file changed, 232 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index a7ef048a9a5c..190170300ef1 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
> @@ -6,7 +6,11 @@
>   * Copyright 2020 Analog Devices Inc.
>   */
>  
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -14,16 +18,243 @@
>  
>  #include "pmbus.h"
>  
> +#define ADM1266_PDIO_CONFIG  0xD4
> +#define ADM1266_GPIO_CONFIG  0xE1
> +#define ADM1266_PDIO_STATUS  0xE9
> +#define ADM1266_GPIO_STATUS  0xEA
> +
> +/* ADM1266 GPIO defines */
> +#define ADM1266_GPIO_NR  9
> +#define ADM1266_GPIO_FUNCTIONS(x)FIELD_GET(BIT(0), x)
> +#define ADM1266_GPIO_INPUT_EN(x) FIELD_GET(BIT(2), x)
> +#define ADM1266_GPIO_OUTPUT_EN(x)FIELD_GET(BIT(3), x)
> +#define ADM1266_GPIO_OPEN_DRAIN(x)   FIELD_GET(BIT(4), x)
> +
> +/* ADM1266 PDIO defines */
> +#define ADM1266_PDIO_NR  16
> +#define ADM1266_PDIO_PIN_CFG(x)  FIELD_GET(GENMASK(15, 13), x)
> +#define ADM1266_PDIO_GLITCH_FILT(x)  FIELD_GET(GENMASK(12, 9), x)
> +#define ADM1266_PDIO_OUT_CFG(x)  FIELD_GET(GENMASK(2, 0), x)
> +
> +struct adm1266_data {
> + struct pmbus_driver_info info;
> + struct gpio_chip gc;
> + const char *gpio_names[ADM1266_GPIO_NR + ADM1266_PDIO_NR];
> + struct i2c_client *client;
> +};
> +
> +#if IS_ENABLED(CONFIG_GPIOLIB)

GPIOLIB is bool. IS_ENABLED suggests tristate, which won't happen. Just use 
#ifdef.

> +static const unsigned int adm1266_gpio_mapping[ADM1266_GPIO_NR][2] = {
> + {1, 0},
> + {2, 1},
> + {3, 2},
> + {4, 8},
> + {5, 9},
> + {6, 10},
> + {7, 11},
> + {8, 6},
> + {9, 7},
> +};
> +
> +static const char *adm1266_names[ADM1266_GPIO_NR + ADM1266_PDIO_NR] = {
> + "GPIO1", "GPIO2", "GPIO3", "GPIO4", "GPIO5", "GPIO6", "GPIO7", "GPIO8",
> + "GPIO9", "PDIO1", "PDIO2", "PDIO3", "PDIO4", "PDIO5", "PDIO6",
> + "PDIO7", "PDIO8", "PDIO9", "PDIO10", "PDIO11", "PDIO12", "PDIO13",
> + "PDIO14", "PDIO15", "PDIO16",
> +};
> +
> +static int adm1266_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct adm1266_data *data = gpiochip_get_data(chip);
> + u8 read_buf[PMBUS_BLOCK_MAX + 1];

Unnecessarily large. SMBUS_BLOCK_MAX is sufficient here.

> + unsigned long pins_status;
> + unsigned int pmbus_cmd;
> + int ret;
> +
> + if (offset < ADM1266_GPIO_NR)
> + pmbus_cmd = ADM1266_GPIO_STATUS;
> + else
> + pmbus_cmd = ADM1266_PDIO_STATUS;
> +
> + ret = i2c_smbus_read_block_data(data->client, pmbus_cmd,
> + read_buf);
> + if (ret < 0)
> + return ret;
> +
> + pins_status = read_buf[0] + (read_buf[1] << 8);
> + if (offset < ADM1266_GPIO_NR)
> + return test_bit(adm1266_gpio_mapping[offset][1], &pins_status);
> + else

else after return is unnecessary.

> + return test_bit(offset - ADM1266_GPIO_NR, &pins_status);
> +}
> +
> +static int adm1266_gpio_get_multiple(struct gpio_chip *chip,
> +  unsigned long *mask,
> +  unsigned long *bits)
> +{
> + struct adm1266_data *data = gpiochip_get_data(chip);
> + u8 gpio_data[PMBUS_BLOCK_MAX + 1];
> + u8 pdio_data[PMBUS_BLOCK_MAX + 1];

This is quite some strain on the stack. I would suggest to use only
one buffer and handle gpio completely first, then pdio.

> + unsigned long gpio_status;
> + unsigned long pdio_status;
> + unsigned int gpio_nr;
> + int ret;
> +
> + ret = i2c_smbus_read_block_data(data->client, ADM1266_GPIO_STATUS,
> + gpio_data);
> + if (ret < 0)
> + return ret;
> +
> + ret = i2c_smbus_read_block_data(data->client, ADM1266_PDIO_STATUS,
> + pdio_data);
> + if (ret < 0)
> + return ret;
> +
> + gpio_status = gpio_data[0] + (gpio_data[1] << 8);
> + pdio_status = pdio_data[0] + (pdio_data[1] << 8);
> + *bits = 0;
> + for_each_set_bit(gpio_nr, mask, ADM1266_GPIO_NR) {
> + if (test_bit(adm1266_gpio_mapping[gpio_nr][1], &gpio_status))
> + set_bit(gpio_nr, bits);
> + }
> +
> + for_each_set_bit_from(gpio_nr, mask,
> +   ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) {
> + if (test_bit(gpio_nr - AD

Re: [PATCH] RDMA/core: Fix several reference count leaks.

[Jason Gunthorpe]

On Wed, May 27, 2020 at 10:02:30PM -0500, wu000...@umn.edu wrote:
> From: Qiushi Wu 
> 
> kobject_init_and_add() takes reference even when it fails.
> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object. Previous
> commit "b8eb718348b8" fixed a similar problem.
> 
> Signed-off-by: Qiushi Wu 
> ---
>  drivers/infiniband/core/sysfs.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applied to for-next, thanks

Jason

Re: [PATCH -tip v3 05/11] kcsan: Remove 'noinline' from __no_kcsan_or_inline

[Marco Elver]

On Fri, 29 May 2020 at 19:08, Peter Zijlstra  wrote:
[...]
>
> Doesn't this mean we can do the below?

If nobody complains about the lack of __no_kcsan_or_inline, let's do
it. See comments below.

> ---
>  Documentation/dev-tools/kcsan.rst |  6 --
>  arch/x86/include/asm/bitops.h |  6 +-
>  include/linux/compiler_types.h| 14 --
>  kernel/kcsan/kcsan-test.c |  4 ++--
>  4 files changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/dev-tools/kcsan.rst 
> b/Documentation/dev-tools/kcsan.rst
> index ce4bbd918648..b38379f06194 100644
> --- a/Documentation/dev-tools/kcsan.rst
> +++ b/Documentation/dev-tools/kcsan.rst
> @@ -114,12 +114,6 @@ functions, compilation units, or entire subsystems.  For 
> static blacklisting,
>To dynamically limit for which functions to generate reports, see the
>`DebugFS interface`_ blacklist/whitelist feature.
>
> -  For ``__always_inline`` functions, replace ``__always_inline`` with
> -  ``__no_kcsan_or_inline`` (which implies ``__always_inline``)::
> -
> -static __no_kcsan_or_inline void foo(void) {
> -...
> -
>  * To disable data race detection for a particular compilation unit, add to 
> the
>``Makefile``::

I suppose, if we say that __no_kcsan_or_inline should just disappear
because '__no_kcsan inline' is now good enough, we can delete it.

I think functions that absolutely must be __always_inline would break
with __no_kcsan_or_inline under KCSAN anyway. So, let's simplify.

> diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
> index 35460fef39b8..0367efdc5b7a 100644
> --- a/arch/x86/include/asm/bitops.h
> +++ b/arch/x86/include/asm/bitops.h
> @@ -201,12 +201,8 @@ arch_test_and_change_bit(long nr, volatile unsigned long 
> *addr)
> return GEN_BINARY_RMWcc(LOCK_PREFIX __ASM_SIZE(btc), *addr, c, "Ir", 
> nr);
>  }
>
> -static __no_kcsan_or_inline bool constant_test_bit(long nr, const volatile 
> unsigned long *addr)
> +static __always_inline bool constant_test_bit(long nr, const volatile 
> unsigned long *addr)
>  {
> -   /*
> -* Because this is a plain access, we need to disable KCSAN here to
> -* avoid double instrumentation via instrumented bitops.
> -*/

Yes, we should have reverted this eventually.

> return ((1UL << (nr & (BITS_PER_LONG-1))) &
> (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
>  }
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 4e4982d6f3b0..6a2c0f857ac3 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -118,10 +118,6 @@ struct ftrace_likely_data {
>  #define notrace
> __attribute__((__no_instrument_function__))
>  #endif
>
> -/* Section for code which can't be instrumented at all */
> -#define noinstr  
>   \
> -   noinline notrace __attribute((__section__(".noinstr.text")))
> -
>  /*
>   * it doesn't make sense on ARM (currently the only user of __naked)
>   * to trace naked functions because then mcount is called without
> @@ -192,17 +188,15 @@ struct ftrace_likely_data {
>  #endif
>
>  #define __no_kcsan __no_sanitize_thread
> -#ifdef __SANITIZE_THREAD__
> -# define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
> -# define __no_sanitize_or_inline __no_kcsan_or_inline

I think we just want to keep __no_sanitize_or_inline, for
READ_ONCE_NOCHECK. Having READ_ONCE_NOCHECK do KCSAN-checking seems
wrong, and I don't know what might break.

> -#else
> -# define __no_kcsan_or_inline __always_inline
> -#endif
>
>  #ifndef __no_sanitize_or_inline
>  #define __no_sanitize_or_inline __always_inline
>  #endif
>
> +/* Section for code which can't be instrumented at all */
> +#define noinstr  
>   \
> +   noinline notrace __attribute((__section__(".noinstr.text"))) 
> __no_kcsan
> +

Will this eventually need __no_sanitize_address?

>  #endif /* __KERNEL__ */
>
>  #endif /* __ASSEMBLY__ */
> diff --git a/kernel/kcsan/kcsan-test.c b/kernel/kcsan/kcsan-test.c
> index a8c11506dd2a..374263ddffe2 100644
> --- a/kernel/kcsan/kcsan-test.c
> +++ b/kernel/kcsan/kcsan-test.c
> @@ -43,7 +43,7 @@ static struct {
>  };
>
>  /* Setup test checking loop. */
> -static __no_kcsan_or_inline void
> +static __no_kcsan inline void
>  begin_test_checks(void (*func1)(void), void (*func2)(void))
>  {
> kcsan_disable_current();
> @@ -60,7 +60,7 @@ begin_test_checks(void (*func1)(void), void (*func2)(void))
>  }
>
>  /* End test checking loop. */
> -static __no_kcsan_or_inline bool
> +static __no_kcsan inline bool
>  end_test_checks(bool stop)
>  {
> if (!stop && time_before(jiffies, end_time)) {

Acked -- if you send a patch, do split the test-related change, so
that Paul can apply it to the test which is currently only in -rcu.

Thanks,
-- Marco

Re: [PATCH v7 1/4] bitops: Introduce the the for_each_set_clump macro

[Andy Shevchenko]

On Fri, May 29, 2020 at 11:38:18PM +0530, Syed Nayyar Waris wrote:
> On Sun, May 24, 2020 at 8:15 PM kbuild test robot  wrote:

...

> >579  static inline unsigned long bitmap_get_value(const unsigned long 
> > *map,
> >580unsigned long start,
> >581unsigned long nbits)
> >582  {
> >583  const size_t index = BIT_WORD(start);
> >584  const unsigned long offset = start % BITS_PER_LONG;
> >585  const unsigned long ceiling = roundup(start + 1, 
> > BITS_PER_LONG);
> >586  const unsigned long space = ceiling - start;
> >587  unsigned long value_low, value_high;
> >588
> >589  if (space >= nbits)
> >  > 590  return (map[index] >> offset) & GENMASK(nbits - 1, 
> > 0);
> >591  else {
> >592  value_low = map[index] & 
> > BITMAP_FIRST_WORD_MASK(start);
> >593  value_high = map[index + 1] & 
> > BITMAP_LAST_WORD_MASK(start + nbits);
> >594  return (value_low >> offset) | (value_high << 
> > space);
> >595  }
> >596  }

> Regarding the above compilation warnings. All the warnings are because
> of GENMASK usage in my patch.
> The warnings are coming because of sanity checks present for 'GENMASK'
> macro in include/linux/bits.h.
> 
> Taking the example statement (in my patch) where compilation warning
> is getting reported:
> return (map[index] >> offset) & GENMASK(nbits - 1, 0);
> 
> 'nbits' is of type 'unsigned long'.
> In above, the sanity check is comparing '0' with unsigned value. And
> unsigned value can't be less than '0' ever, hence the warning.
> But this warning will occur whenever there will be '0' as one of the
> 'argument' and an unsigned variable as another 'argument' for GENMASK.
> 
> This warning is getting cleared if I cast the 'nbits' to 'long'.
> 
> Let me know if I should submit a next patch with the casts applied.
> What do you guys think?

Proper fix is to fix GENMASK(), but allowed workaround is to use
(BIT(nbits) - 1)
instead.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

[Andy Shevchenko]

On Fri, May 29, 2020 at 09:22:56PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> > On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:

> > you're sending 
> > new versions too fast. Give people time to review.
> 
> Yeah, you did. Sorry for sending the new versions very fast. Normally I prefer
> to keep up with comments so to past a particular maintainer review as fast as
> possible without long delays. In my experience the longer you wait, the lesser
> maintainers remember about your patchset, the harder for one to continue the
> next versions review.

Documentation/process/submitting-patches.rst:

"Wait for a minimum of one week before resubmitting or pinging reviewers -
possibly longer during busy times like merge windows."


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 4/6] hwmon: pmbus: adm1266: add debugfs attr for states

[Guenter Roeck]

On 5/29/20 6:05 AM, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici 
> 
> Add debugfs files for go_command and read_state.
> 
> Signed-off-by: Alexandru Tachici 
> ---
>  drivers/hwmon/pmbus/adm1266.c | 47 +++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index 190170300ef1..85d6795b79d3 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
> @@ -19,6 +19,8 @@
>  #include "pmbus.h"
>  
>  #define ADM1266_PDIO_CONFIG  0xD4
> +#define ADM1266_GO_COMMAND   0xD8
> +#define ADM1266_READ_STATE   0xD9
>  #define ADM1266_GPIO_CONFIG  0xE1
>  #define ADM1266_PDIO_STATUS  0xE9
>  #define ADM1266_GPIO_STATUS  0xEA
> @@ -41,6 +43,7 @@ struct adm1266_data {
>   struct gpio_chip gc;
>   const char *gpio_names[ADM1266_GPIO_NR + ADM1266_PDIO_NR];
>   struct i2c_client *client;
> + struct dentry *debugfs_dir;
>  };
>  
>  #if IS_ENABLED(CONFIG_GPIOLIB)
> @@ -234,6 +237,48 @@ static inline int adm1266_config_gpio(struct 
> adm1266_data *data)
>  }
>  #endif
>  
> +static int adm1266_get_state_op(void *pdata, u64 *state)
> +{
> + struct adm1266_data *data = pdata;
> + int ret;
> +
> + ret = i2c_smbus_read_word_data(data->client, ADM1266_READ_STATE);
> + if (ret < 0)
> + return ret;
> +
> + *state = ret;
> +
> + return 0;
> +}
> +
> +static int adm1266_set_go_command_op(void *pdata, u64 val)
> +{
> + struct adm1266_data *data = pdata;
> + u8 reg;
> +
> + reg = FIELD_GET(GENMASK(4, 0), val);
> +
> + return i2c_smbus_write_word_data(data->client, ADM1266_GO_COMMAND, reg);
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(go_command_fops, NULL, adm1266_set_go_command_op,
> +  "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(read_state_fops, adm1266_get_state_op, NULL, 
> "%llu\n");
> +
> +static void adm1266_debug_init(struct adm1266_data *data)
> +{
> + struct dentry *root;
> + char dir_name[30];
> +
> + sprintf(dir_name, "adm1266-%x_debugfs", data->client->addr);
> + root = debugfs_create_dir(dir_name, NULL);
> + data->debugfs_dir = root;
> + debugfs_create_file_unsafe("go_command", 0200, root, data,
> +&go_command_fops);

I am not entirely sure what this does, but from the description in the datasheet
it is way too critical to support as debugfs command. Anyone believing this
is needed should use ioctl commands instead.


> + debugfs_create_file_unsafe("read_state", 0400, root, data,
> +&read_state_fops);
> +}
> +

We have standard pmbus debug functions. Please use it.

>  static int adm1266_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
>  {
> @@ -254,6 +299,8 @@ static int adm1266_probe(struct i2c_client *client,
>   if (ret < 0)
>   return ret;
>  
> + adm1266_debug_init(data);
> +
>   info = &data->info;
>   info->pages = 17;
>   info->format[PSC_VOLTAGE_OUT] = linear;
> 

Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

[Serge Semin]

On Fri, May 29, 2020 at 09:42:01PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 09:22:56PM +0300, Serge Semin wrote:
> > On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> > > On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> 
> > > you're sending 
> > > new versions too fast. Give people time to review.
> > 
> > Yeah, you did. Sorry for sending the new versions very fast. Normally I 
> > prefer
> > to keep up with comments so to past a particular maintainer review as fast 
> > as
> > possible without long delays. In my experience the longer you wait, the 
> > lesser
> > maintainers remember about your patchset, the harder for one to continue the
> > next versions review.
> 

> Documentation/process/submitting-patches.rst:
> 
> "Wait for a minimum of one week before resubmitting or pinging reviewers -
> possibly longer during busy times like merge windows."

Good to know what I already know.) How much do you personally wait before
resubmitting? In my experience reviewing your DW APB GPIO patches, no longer
than a few hours.

-Sergey

> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH v3 5/6] hwmon: pmbus: adm1266: read blackbox

[Guenter Roeck]

On 5/29/20 6:05 AM, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici 
> 
> Use the nvmem kernel api to expose the black box
> chip functionality to userspace.
> 

This needs to be split into two functions: Add nvmem support, add
debugfs file.

Guenter

> Signed-off-by: Alexandru Tachici 
> ---
>  drivers/hwmon/pmbus/adm1266.c | 160 ++
>  1 file changed, 160 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index 85d6795b79d3..831156004087 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
> @@ -14,14 +14,19 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "pmbus.h"
>  
> +#define ADM1266_BLACKBOX_CONFIG  0xD3
>  #define ADM1266_PDIO_CONFIG  0xD4
>  #define ADM1266_GO_COMMAND   0xD8
>  #define ADM1266_READ_STATE   0xD9
> +#define ADM1266_READ_BLACKBOX0xDE
>  #define ADM1266_GPIO_CONFIG  0xE1
> +#define ADM1266_BLACKBOX_INFO0xE6
>  #define ADM1266_PDIO_STATUS  0xE9
>  #define ADM1266_GPIO_STATUS  0xEA
>  
> @@ -38,12 +43,26 @@
>  #define ADM1266_PDIO_GLITCH_FILT(x)  FIELD_GET(GENMASK(12, 9), x)
>  #define ADM1266_PDIO_OUT_CFG(x)  FIELD_GET(GENMASK(2, 0), x)
>  
> +#define ADM1266_BLACKBOX_OFFSET  0x7F700
> +#define ADM1266_BLACKBOX_SIZE64
> +
>  struct adm1266_data {
>   struct pmbus_driver_info info;
>   struct gpio_chip gc;
>   const char *gpio_names[ADM1266_GPIO_NR + ADM1266_PDIO_NR];
>   struct i2c_client *client;
>   struct dentry *debugfs_dir;
> + struct nvmem_config nvmem_config;
> + struct nvmem_device *nvmem;
> + u8 *dev_mem;
> +};
> +
> +static const struct nvmem_cell_info adm1266_nvmem_cells[] = {
> + {
> + .name   = "blackbox",
> + .offset = ADM1266_BLACKBOX_OFFSET,
> + .bytes  = 2048,
> + },
>  };
>  
>  #if IS_ENABLED(CONFIG_GPIOLIB)
> @@ -261,6 +280,28 @@ static int adm1266_set_go_command_op(void *pdata, u64 
> val)
>   return i2c_smbus_write_word_data(data->client, ADM1266_GO_COMMAND, reg);
>  }
>  
> +static int adm1266_blackbox_information_read(struct seq_file *s, void *pdata)
> +{
> + struct device *dev = s->private;
> + struct i2c_client *client = to_i2c_client(dev);
> + u8 read_buf[PMBUS_BLOCK_MAX + 1];
> + unsigned int latest_id;
> + int ret;
> +
> + ret = i2c_smbus_read_block_data(client, ADM1266_BLACKBOX_INFO,
> + read_buf);
> + if (ret < 0)
> + return ret;
> +
> + seq_puts(s, "BLACKBOX_INFORMATION:\n");
> + latest_id = read_buf[0] + (read_buf[1] << 8);
> + seq_printf(s, "Black box ID: %x\n", latest_id);
> + seq_printf(s, "Logic index: %x\n", read_buf[2]);
> + seq_printf(s, "Record count: %x\n", read_buf[3]);
> +
> + return 0;
> +}
> +
>  DEFINE_DEBUGFS_ATTRIBUTE(go_command_fops, NULL, adm1266_set_go_command_op,
>"%llu\n");
>  DEFINE_DEBUGFS_ATTRIBUTE(read_state_fops, adm1266_get_state_op, NULL, 
> "%llu\n");
> @@ -277,6 +318,121 @@ static void adm1266_debug_init(struct adm1266_data 
> *data)
>  &go_command_fops);
>   debugfs_create_file_unsafe("read_state", 0400, root, data,
>  &read_state_fops);
> + debugfs_create_devm_seqfile(&data->client->dev, "blackbox_information",
> + root, adm1266_blackbox_information_read);
> +}
> +
> +static int adm1266_nvmem_read_blackbox(struct adm1266_data *data, u8 *buf)
> +{
> + u8 write_buf[PMBUS_BLOCK_MAX + 1];
> + u8 read_buf[PMBUS_BLOCK_MAX + 1];
> + int record_count;
> + int ret;
> + int i;
> +
> + ret = i2c_smbus_read_block_data(data->client, ADM1266_BLACKBOX_INFO,
> + read_buf);
> + if (ret < 0)
> + return ret;
> +
> + record_count = read_buf[3];
> +
> + for (i = 0; i < record_count; i++) {
> + write_buf[0] = i;
> + ret = pmbus_block_wr(data->client, ADM1266_READ_BLACKBOX, 1,
> +  write_buf, buf);
> + if (ret < 0)
> + return ret;
> +
> + buf += ADM1266_BLACKBOX_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +static bool adm1266_cell_is_accessed(const struct nvmem_cell_info *mem_cell,
> +  unsigned int offset, size_t bytes)
> +{
> + unsigned int start_addr = offset;
> + unsigned int end_addr = offset + bytes;
> + unsigned int cell_start = mem_cell->offset;
> + unsigned int cell_end = mem_cell->offset + mem_cell->bytes;
> +
> + if (start_addr <= cell_end && cell_start <= end_addr)
> + return true;
> +
> + return false;
> +}
> +
> +static int adm1266_read_mem_cell(struct adm1266_data *data,
> +  const struct nvmem_cell_

Re: [PATCH v2 3/3] selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD

[Sargun Dhillon]

On Fri, May 29, 2020 at 12:41:51AM -0700, Kees Cook wrote:
> On Thu, May 28, 2020 at 04:08:58AM -0700, Sargun Dhillon wrote:
> > +   EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0);
> > +
> > +   nextid = req.id + 1;
> > +
> > +   /* Wait for getppid to be called for the second time */
> > +   sleep(1);
> 
> I always rebel at finding "sleep" in tests. ;) Is this needed? IIUC,
> userspace will immediately see EINPROGRESS after the NOTIF_SEND
> finishes, yes?
> 
> Otherwise, yes, this looks good.
> 
> -- 
> Kees Cook
I'm open to better suggestions, but there's a race where if getppid
is not called before the second SECCOMP_IOCTL_NOTIF_ADDFD is called,
you will just get an ENOENT, since the notification ID is not found.

The other approach is to "poll" the child, and wait for it to enter
the second syscall. Calling receive beforehand doesn't work because
it moves the state of the notification in the kernel to received,
and then the kernel doesn't error with EINPROGRESS.

RE: [EXTERNAL] Re: [PATCH v4] perf inject --jit: Remove //anon mmap events

[Steve MacLean]

> I've been trying variants of:
>
> Before:
>/tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java 
>-agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer 
>-XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar 
>dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o 
>/tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep class\ 
>|wc -l
> 578
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 6
> 
> After:
> /tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java 
> -agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer 
> -XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar 
> dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o 
> /tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep 
> class\ |wc -l
> 589
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 60
>
> So maybe the jit cache isn't behaving the way that the patch cures, the 
> uptick in unknowns appears consistent in my testing though. I expect user 
> error, is there an obvious explanation I'm missing?

That is certainly disturbing. I don't see an obvious user error, but I haven't 
played with java jitdump

Couple of ideas come to mind.

+ When I was drafting .NET jitdump support, I looked briefly at the java agent. 
 My impression was the java agent support wasn't thread safe.  The jitdump file 
format requires that certain records are collocated to simplify the reader.  I 
wasn't sure how that was being accomplished by the writer if JAVA's JIT was 
multithreaded (like CoreCLR JIT is).

+ The way I implemented jitdump on CoreCLR was to hook into the existing system 
to write perf-map files.  So I am pretty confident there is a 1:1 
correspondence of perf-map records with jitdump records.  Is it possible that 
Java choose to only emit interesting jitdump records?  Perhaps skipping 
thunks/stubs/trampolines?  

+ There are still some `unknown` records in CoreCLR, but I don't believe there 
is an increase.  I am pretty sure some of our stubs are not being generated.  
They were present in our before case too.

+ Your methodology would be more repeatable if you record once, and analyze 
multiple times.  record, report, inject / report, inject / report

+ I was focusing on eliminating duplicate symbols for the same address.  So 
having the module name in the report allowed me to see if the symbol was from 
jitdump or from perf-map.  In the before case I could see duplicate symbols for 
the same address.  This was how the problem was first observed.

+ I would be more interested in looking at the diff of the reports.  Possibly 
sorted by address.  Probably with zero context.

If I were to guess, I would think Java choose to optimize jitdump and only 
record interesting code.

So if we need to support that scenario the approach of this patch wouldn't work.

We would need to use a different approach.  Ideas...
+ Keep anon mappings from overwriting jitdump mappings.  Introduce a weak add 
map method, that would only fill empty/anon.
+ Move the anon mapping timestamp to the beginning of time, so they are 
processed first
+ Fix the kernel perf map events
+ Keep the anon mappings in a separate fall back map

I kind of like the add weak map approach.

[PATCH] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG

[Christophe Leroy]

From: Christophe Leroy 

'thread' doesn't exist in kuap_check() macro.

Use 'current' instead.

Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access 
Protection")
Signed-off-by: Christophe Leroy 
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index db0a1c281587..668508c8a1b5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -75,7 +75,7 @@
 
 .macro kuap_check  current, gpr
 #ifdef CONFIG_PPC_KUAP_DEBUG
-   lwz \gpr, KUAP(thread)
+   lwz \gpr, THREAD + KUAP(\current)
 999:   twnei   \gpr, 0
EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | 
BUGFLAG_ONCE)
 #endif
-- 
2.25.0

Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message

[Markus Elfring]

> Please just remove the message instead, it's a tiny allocation that's
> unlikely to ever fail, and the caller will print an error anyway.

How do you think about to take another look at a previous update suggestion
like the following?

powerpc/nvram: Delete three error messages for a failed memory allocation
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/
https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/
https://lore.kernel.org/patchwork/patch/752720/
https://lkml.org/lkml/2017/1/19/537

Regards,
Markus

Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Guenter Roeck]

On 5/29/20 10:42 AM, Patrick Williams wrote:
> Hi Guenter,
> 
> Thanks for the initial look at this.
> 
> One question for you below...
> 
> On Fri, May 29, 2020 at 10:30:16AM -0700, Guenter Roeck wrote:
>> On 5/29/20 5:46 AM, Manikandan Elumalai wrote:
>>> +   /* Enable TEMP1 by default */
>>> +   config |= ADM1278_TEMP1_EN;
>>> +   ret = i2c_smbus_write_byte_data(client,
>>> +   ADM1275_PMON_CONFIG,
>>> +   config);
>>> +   if (ret < 0) {
>>> +   dev_err(&client->dev,
>>> +   "Failed to enable temperature config\n");
>>> +   return -ENODEV;
>>> +   }
>>
>> This can be handled in a single operation, together with ADM1278_VOUT_EN
>> below. There is no need for two separate write operations.
> 
> I don't know if you noticed here but the change ends up enabling
> TEMP1_EN in all cases.  Is this acceptable?  If not, do you have any
> preference on how it is selected for enablement?
> 

I did. We are doing the same for output voltage already, so I am not that
much concerned about it. If it is, we might consider adding _enable
attribute support (see Documentation/hwmon/sysfs-interface.rst) to the
PMBus core (presumably as virtual PMBus commands) and let the user
enable/disable individual attributes as needed.

What _should_ really be done, of course, is that the BIOS/ROMMON
configures the chip as desired. Obviously that is not happening here.

Guenter

>>> /* Enable VOUT if not enabled (it is disabled by default) */
>>> if (!(config & ADM1278_VOUT_EN)) {
>>> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
>>> }
>>> }
>>>  
>>> -   if (config & ADM1278_TEMP1_EN)
>>> -   info->func[0] |=
>>> -   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>>> if (config & ADM1278_VIN_EN)
>>> info->func[0] |= PMBUS_HAVE_VIN;
>>> break;
>>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG

[Christophe Leroy]

Le 29/05/2020 à 20:50, Christophe Leroy a écrit :

From: Christophe Leroy 

'thread' doesn't exist in kuap_check() macro.

Use 'current' instead.

Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access 
Protection")
Signed-off-by: Christophe Leroy 


Argh, can you drop this line ?


Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 


Reported-by: kbuild test robot 


---
  arch/powerpc/include/asm/book3s/32/kup.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index db0a1c281587..668508c8a1b5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -75,7 +75,7 @@
  
  .macro kuap_check	current, gpr

  #ifdef CONFIG_PPC_KUAP_DEBUG
-   lwz \gpr, KUAP(thread)
+   lwz \gpr, THREAD + KUAP(\current)
  999:  twnei   \gpr, 0
EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | 
BUGFLAG_ONCE)
  #endif

Re: [PATCH v2] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Guenter Roeck]

On 5/29/20 10:57 AM, Vijay Khemka wrote:
> 
> 
> On 5/29/20, 5:47 AM, "Manikandan Elumalai" 
>  wrote:
> 
> The adm1278 temperature sysfs attribute need it for one of the openbmc 
> platform . 
> This functionality is not enabled by default, so PMON_CONFIG needs to be 
> modified in order to enable it.
> 
> Signed-off-by   : Manikandan Elumalai 
> 
> v2:
>- Add Signed-off-by.
>- Removed ADM1278_TEMP1_EN check.
> ---
>  drivers/hwmon/pmbus/adm1275.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 5caa37fb..ab5fceb 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -666,7 +666,23 @@ static int adm1275_probe(struct i2c_client *client,
>   tindex = 3;
>  
>   info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
> - PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> +
> + config = i2c_smbus_read_byte_data(client, ADM1275_PMON_CONFIG);
> + if (config < 0)
> + return config;
> +
> + /* Enable TEMP1 by default */
> + config |= ADM1278_TEMP1_EN;
> + ret = i2c_smbus_write_byte_data(client,
> + ADM1275_PMON_CONFIG,
> + config);
> + if (ret < 0) {
> + dev_err(&client->dev,
> + "Failed to enable temperature config\n");
> + return -ENODEV;
> + }
> You don't need this above code removing check as below should be enough  to
> populate sysfs entry you need.
> 

You mean you are only interested in having the attribute, even if it doesn't
report anything useful because monitoring is disabled in the chip ?
Sorry, I don't understand. Can you elaborate ?

Thanks,
Guenter

>   /* Enable VOUT if not enabled (it is disabled by default) */
>   if (!(config & ADM1278_VOUT_EN)) {
> @@ -681,9 +697,6 @@ static int adm1275_probe(struct i2c_client *client,
>   }
>   }
>  
> - if (config & ADM1278_TEMP1_EN)
> - info->func[0] |=
> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>   if (config & ADM1278_VIN_EN)
>   info->func[0] |= PMBUS_HAVE_VIN;
>   break;
> -- 
> 2.7.4
> 
> 
> 

Re: [PATCH v8 0/8] powerpc: switch VDSO to C implementation

[Christophe Leroy]

Hi Michael,

Le 28/04/2020 à 15:16, Christophe Leroy a écrit :

This is the seventh version of a series to switch powerpc VDSO to
generic C implementation.

Main changes since v7 are:
- Added gettime64 on PPC32

This series applies on today's powerpc/merge branch.

See the last patches for details on changes and performance.


Do you have any plans for this series ?

Even if you don't feel like merging it this cycle, I think patches 1 to 
3 are worth it.


Christophe



Christophe Leroy (8):
   powerpc/vdso64: Switch from __get_datapage() to get_datapage inline
 macro
   powerpc/vdso: Remove __kernel_datapage_offset and simplify
 __get_datapage()
   powerpc/vdso: Remove unused \tmp param in __get_datapage()
   powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
   powerpc/vdso: Prepare for switching VDSO to generic C implementation.
   powerpc/vdso: Switch VDSO to generic C implementation.
   lib/vdso: force inlining of __cvdso_clock_gettime_common()
   powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32

  arch/powerpc/Kconfig |   2 +
  arch/powerpc/include/asm/clocksource.h   |   7 +
  arch/powerpc/include/asm/processor.h |  10 +-
  arch/powerpc/include/asm/vdso/clocksource.h  |   7 +
  arch/powerpc/include/asm/vdso/gettimeofday.h | 175 +++
  arch/powerpc/include/asm/vdso/processor.h|  23 ++
  arch/powerpc/include/asm/vdso/vsyscall.h |  25 ++
  arch/powerpc/include/asm/vdso_datapage.h |  50 ++--
  arch/powerpc/kernel/asm-offsets.c|  49 +--
  arch/powerpc/kernel/time.c   |  91 +-
  arch/powerpc/kernel/vdso.c   |  58 +---
  arch/powerpc/kernel/vdso32/Makefile  |  32 +-
  arch/powerpc/kernel/vdso32/cacheflush.S  |   2 +-
  arch/powerpc/kernel/vdso32/config-fake32.h   |  34 +++
  arch/powerpc/kernel/vdso32/datapage.S|   7 +-
  arch/powerpc/kernel/vdso32/gettimeofday.S| 300 +--
  arch/powerpc/kernel/vdso32/vdso32.lds.S  |   8 +-
  arch/powerpc/kernel/vdso32/vgettimeofday.c   |  35 +++
  arch/powerpc/kernel/vdso64/Makefile  |  23 +-
  arch/powerpc/kernel/vdso64/cacheflush.S  |   9 +-
  arch/powerpc/kernel/vdso64/datapage.S|  31 +-
  arch/powerpc/kernel/vdso64/gettimeofday.S| 243 +--
  arch/powerpc/kernel/vdso64/vdso64.lds.S  |   7 +-
  arch/powerpc/kernel/vdso64/vgettimeofday.c   |  29 ++
  lib/vdso/gettimeofday.c  |   2 +-
  25 files changed, 460 insertions(+), 799 deletions(-)
  create mode 100644 arch/powerpc/include/asm/clocksource.h
  create mode 100644 arch/powerpc/include/asm/vdso/clocksource.h
  create mode 100644 arch/powerpc/include/asm/vdso/gettimeofday.h
  create mode 100644 arch/powerpc/include/asm/vdso/processor.h
  create mode 100644 arch/powerpc/include/asm/vdso/vsyscall.h
  create mode 100644 arch/powerpc/kernel/vdso32/config-fake32.h
  create mode 100644 arch/powerpc/kernel/vdso32/vgettimeofday.c
  create mode 100644 arch/powerpc/kernel/vdso64/vgettimeofday.c

[git pull] IOMMU Fixes for Linux v5.7-rc7

[Joerg Roedel]

Hi Linus,

The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:

  Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
tags/iommu-fixes-v5.7-rc7

for you to fetch changes up to 7cc31613734c4870ae32f5265d576ef296621343:

  iommu: Fix reference count leak in iommu_group_alloc. (2020-05-29 15:27:50 
+0200)


IOMMU Fixes for Linux v5.7-rc7

Including:

- Two compile test fixes for issues introduced during the
  5.7-rc1 merge window.

- A fix for a reference count leak in an error path of
  iommu_group_alloc().


Krzysztof Kozlowski (2):
  ia64: Hide the archdata.iommu field behind generic IOMMU_API
  x86: Hide the archdata.iommu field behind generic IOMMU_API

Qiushi Wu (1):
  iommu: Fix reference count leak in iommu_group_alloc.

 arch/ia64/include/asm/device.h | 2 +-
 arch/x86/include/asm/device.h  | 2 +-
 drivers/iommu/iommu.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

Please pull.

Thanks,

Joerg


signature.asc
Description: Digital signature

Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

[Serge Semin]

On Fri, May 29, 2020 at 09:45:37PM +0300, Serge Semin wrote:
> On Fri, May 29, 2020 at 09:42:01PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2020 at 09:22:56PM +0300, Serge Semin wrote:
> > > On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> > > > On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> > 
> > > > you're sending 
> > > > new versions too fast. Give people time to review.
> > > 
> > > Yeah, you did. Sorry for sending the new versions very fast. Normally I 
> > > prefer
> > > to keep up with comments so to past a particular maintainer review as 
> > > fast as
> > > possible without long delays. In my experience the longer you wait, the 
> > > lesser
> > > maintainers remember about your patchset, the harder for one to continue 
> > > the
> > > next versions review.
> > 
> 

> > Documentation/process/submitting-patches.rst:
> > 
> > "Wait for a minimum of one week before resubmitting or pinging reviewers -
> > possibly longer during busy times like merge windows."
> 
> Good to know what I already know.) How much do you personally wait before
> resubmitting? In my experience reviewing your DW APB GPIO patches, no longer
> than a few hours.

Moreover the statement you cited is about the patches, which doesn't get any
attention from the maintainers/reviewers for quite some time. In this case I
normally resubmit the patches no sooner than a week. I was talking about the
situation when you get the review comments, which need to be addressed.

-Sergey

> 
> -Sergey
> 
> > 
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko
> > 
> > 

Re: [PATCH -tip v3 05/11] kcsan: Remove 'noinline' from __no_kcsan_or_inline

[Peter Zijlstra]

On Fri, May 29, 2020 at 08:36:56PM +0200, Marco Elver wrote:

> > +/* Section for code which can't be instrumented at all */
> > +#define noinstr
> > \
> > +   noinline notrace __attribute((__section__(".noinstr.text"))) 
> > __no_kcsan
> > +
> 
> Will this eventually need __no_sanitize_address?

Yes, and __no_sanitize_undefined and whatever else there is.

https://lkml.kernel.org/r/20200529171104.gd706...@hirez.programming.kicks-ass.net


> Acked -- if you send a patch, do split the test-related change, so
> that Paul can apply it to the test which is currently only in -rcu.

Ok, I'll try not forget over the weekend ;-)

[PATCH v2 0/2] fix missing handling of __user in nommu's uaccess()

[Luc Van Oostenryck]

I received a bug report for an unrelated patch when used with m68k-nommu.
It appears that the origin of the problem is that __get_user() and
__put_user() doesn't handle correctly __user. These 2 patches fix this.

Note: this is only minimaly tested but is quite straightforward and
  since this only change __user annotation it will not change the
  generated code.


Changes since v1:
* fix typo: s/plan/plain/
* appease checkpatch with better style: s/__force*/__force */
* avoid excessive line length caused by the added cast.

Luc Van Oostenryck (2):
  m68k,nommu: add missing __user in uaccess' __ptr() macro
  m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()

 arch/m68k/include/asm/uaccess_no.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.26.2