Re: [GIT PULL] Last straggler for 4.20-rc8 or final

[Paolo Bonzini]

On 22/12/18 21:59, Ingo Molnar wrote:
> 
> * Paolo Bonzini  wrote:
> 
>> On 21/12/18 23:40, Borislav Petkov wrote:
>>> + mingo.
>>>
>>> On Fri, Dec 21, 2018 at 02:09:02PM +0100, Paolo Bonzini wrote:
 Linus,

 The following changes since commit 
 7566ec393f4161572ba6f11ad5171fd5d59b0fbd:

   Linux 4.20-rc7 (2018-12-16 15:46:55 -0800)

 are available in the git repository at:

   https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

 for you to fetch changes up to 3cf85f9f6bd7b172122865432b4c6f0ec844e22a:

   KVM: x86: nSVM: fix switch to guest mmu (2018-12-19 22:19:22 +0100)

 A simple patch for a pretty bad bug.  I haven't yet sent my 4.21 pull
 request because currently I'm waiting for a patch to be removed from
 tip (MPX removal breaks KVM live migration and was committed without
 Cc or Ack from me) and until that happens I cannot finalize my
 conflict resolution instructions.
>>>
>>> Lemme make sure I understand it correctly: you'd like us to not send
>>>
>>> https://git.kernel.org/tip/eb012ef3b4e331ae479dd7cd9378041d9b7f851c
>>>
>>> up now and delay it for 4.22, right?
>>
>> Right, and also I will have to provide you with a topic branch to base
>> that patch on.
> 
> Ok - x86/mpx delayed for v4.22 at least.
> 
> Can we turn off CONFIG_X86_INTEL_MPX configurability in the Kconfig, via 
> a patch like below?
> 
> Thanks,
> 
>   Ingo
> 
>  arch/x86/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 8689e794a43c..20fd5695f265 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1870,6 +1870,7 @@ config X86_INTEL_MPX
>   def_bool n
>   # Note: only available in 64-bit mode due to VMA flags shortage
>   depends on CPU_SUP_INTEL && X86_64
> + depends on DEPRECATED
>   select ARCH_USES_HIGH_VMA_FLAGS
>   ---help---
> MPX provides hardware features that can be used in
> 

I think so, you can even delete all X86_INTEL_MPX code already.  All
that KVM still needs is that BNDCSR and BNDREGS remain in XCR0, I don't
see anything that affects that depending on X86_INTEL_MPX.

Thanks,

Paolo

[PATCH V6 1/2] dt-bindings: iio: accel: mma8452: add power supplies property

[Anson Huang]

The accelerometer's power supplies could be controllable on some
platforms, add property "vdd/vddio" power supply to let device tree
to pass phandles to the regulators to driver.

Signed-off-by: Anson Huang 
---
No change since V5.
---
 Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 2100e9a..e132394 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -20,6 +20,10 @@ Optional properties:
   - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
 interrupt line in use.
 
+  - vdd-supply: phandle to the regulator that provides vdd power to the 
accelerometer.
+
+  - vddio-supply: phandle to the regulator that provides vddio power to the 
accelerometer.
+
 Example:
 
mma8453fc@1d {
-- 
2.7.4

RE: [PATCH V5 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support

[Anson Huang]

Hi, Jonathan

Best Regards!
Anson Huang

> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 2018年12月23日 1:20
> To: Anson Huang 
> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> robh...@kernel.org; mark.rutl...@arm.com; mart...@posteo.de;
> gre...@linuxfoundation.org; gust...@embeddedor.com; Leonard Crestez
> ; rtres...@electromag.com.au;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; feste...@gmail.com;
> pr...@electromag.com.au; dl-linux-imx 
> Subject: Re: [PATCH V5 2/2] iio: accell: mma8452: add vdd/vddio regulator
> operation support
> 
> On Mon, 17 Dec 2018 05:22:55 +
> Anson Huang  wrote:
> 
> > The accelerometer's power supply could be controllable on some
> > platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
> > are controlled by a GPIO fixed regulator, need to make sure the
> > regulators are enabled before any communication with mma8451, this
> > patch adds vdd/vddio regulator operation support.
> >
> > Signed-off-by: Anson Huang 
> > Acked-by: Martin Kepplinger 
> 
> There is a lot of manual handling in the suspend and resume I would not
> expect to see.  That should be using the runtime pm calls to take control of
> pm rather than making assumptions about what runtime pm state we are in...

Yes, but I found we can just use pm_runtime_force_suspend/resume for 
suspend/resume
operations, since the operations are same, it will simply the code and I tested 
it, it works.

Anson.

> 
> Jonathan
> 
> > ---
> > ChangeLog since V4:
> > - using devm_regulator_get() instead of devm_regulator_get_optional()
> since the regulator is
> >   there always, if dtb does NOT specify one, regulator framework will
> assign dummy regulator for it.
> > ---
> >  drivers/iio/accel/mma8452.c | 183
> > +---
> >  1 file changed, 172 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> > index 421a0a8..9a52426 100644
> > --- a/drivers/iio/accel/mma8452.c
> > +++ b/drivers/iio/accel/mma8452.c
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define MMA8452_STATUS 0x00
> >  #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | 
> > BIT(0))
> > @@ -107,6 +108,8 @@ struct mma8452_data {
> > u8 data_cfg;
> > const struct mma_chip_info *chip_info;
> > int sleep_val;
> > +   struct regulator *vdd_reg;
> > +   struct regulator *vddio_reg;
> >  };
> >
> >   /**
> > @@ -1534,9 +1537,37 @@ static int mma8452_probe(struct i2c_client
> *client,
> > mutex_init(>lock);
> > data->chip_info = match->data;
> >
> > +   data->vdd_reg = devm_regulator_get(>dev, "vdd");
> > +   if (IS_ERR(data->vdd_reg)) {
> > +   ret = PTR_ERR(data->vdd_reg);
> > +   if (ret != -EPROBE_DEFER)
> > +   dev_err(>dev, "failed to get VDD regulator!\n");
> > +   return ret;
> > +   }
> > +
> > +   ret = regulator_enable(data->vdd_reg);
> > +   if (ret) {
> > +   dev_err(>dev, "failed to enable VDD regulator!\n");
> > +   return ret;
> > +   }
> 
> Please reorder so the unwind order in remove and devm cleanup is the
> opposite of setup order.  I suspect that is just a case of doing the two gets
> before enabling either regulator, but I haven't checked.
> 
> > +
> > +   data->vddio_reg = devm_regulator_get(>dev, "vddio");
> > +   if (IS_ERR(data->vddio_reg)) {
> > +   ret = PTR_ERR(data->vddio_reg);
> > +   if (ret != -EPROBE_DEFER)
> > +   dev_err(>dev, "failed to get VDDIO 
> > regulator!\n");
> > +   goto disable_regulator_vdd;
> > +   }
> > +
> > +   ret = regulator_enable(data->vddio_reg);
> > +   if (ret) {
> > +   dev_err(>dev, "failed to enable VDDIO regulator!\n");
> > +   goto disable_regulator_vdd;
> > +   }
> > +
> > ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
> > if (ret < 0)
> > -   return ret;
> > +   goto disable_regulators;
> >
> > switch (ret) {
> > case MMA8451_DEVICE_ID:
> > @@ -1549,7 +1580,8 @@ static int mma8452_probe(struct i2c_client
> *client,
> > break;
> > /* else: fall through */
> > default:
> > -   return -ENODEV;
> > +   ret = -ENODEV;
> > +   goto disable_regulators;
> > }
> >
> > dev_info(>dev, "registering %s accelerometer; ID 0x%x\n", @@
> > -1566,13 +1598,13 @@ static int mma8452_probe(struct i2c_client
> > *client,
> >
> > ret = mma8452_reset(client);
> > if (ret < 0)
> > -   return ret;
> > +   goto disable_regulators;
> >
> > data->data_cfg = MMA8452_DATA_CFG_FS_2G;
> > ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
> > data->data_cfg);
> > if (ret < 0)
> > -   return ret;
> > +   goto 

[PATCH V6 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support

[Anson Huang]

The accelerometer's power supply could be controllable on some
platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
are controlled by a GPIO fixed regulator, need to make sure the
regulators are enabled before any communication with mma8451, this
patch adds vdd/vddio regulator operation support.

Signed-off-by: Anson Huang 
Acked-by: Martin Kepplinger 
---
ChangeLog since V5:
- ONLY enable vdd/vddio regulators after both of them are aquired;
- Since the suspend/resume operations are same as runtime suspend/resume, 
so just use the
  pm_runtime_force_suspend/resume for suspend/resuem callback to simply the 
code.
---
 drivers/iio/accel/mma8452.c | 99 +++--
 1 file changed, 77 insertions(+), 22 deletions(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 421a0a8..7519ed5 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -107,6 +108,8 @@ struct mma8452_data {
u8 data_cfg;
const struct mma_chip_info *chip_info;
int sleep_val;
+   struct regulator *vdd_reg;
+   struct regulator *vddio_reg;
 };
 
  /**
@@ -1534,9 +1537,33 @@ static int mma8452_probe(struct i2c_client *client,
mutex_init(>lock);
data->chip_info = match->data;
 
+   data->vdd_reg = devm_regulator_get(>dev, "vdd");
+   data->vddio_reg = devm_regulator_get(>dev, "vddio");
+   if (IS_ERR(data->vdd_reg) || IS_ERR(data->vddio_reg)) {
+   if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER ||
+   PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   dev_err(>dev, "failed to get VDD/VDDIO regulator!\n");
+   return IS_ERR(data->vdd_reg) ?
+  PTR_ERR(data->vdd_reg) : PTR_ERR(data->vddio_reg);
+   }
+
+   ret = regulator_enable(data->vdd_reg);
+   if (ret) {
+   dev_err(>dev, "failed to enable VDD regulator!\n");
+   return ret;
+   }
+
+   ret = regulator_enable(data->vddio_reg);
+   if (ret) {
+   dev_err(>dev, "failed to enable VDDIO regulator!\n");
+   goto disable_regulator_vdd;
+   }
+
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
switch (ret) {
case MMA8451_DEVICE_ID:
@@ -1549,7 +1576,8 @@ static int mma8452_probe(struct i2c_client *client,
break;
/* else: fall through */
default:
-   return -ENODEV;
+   ret = -ENODEV;
+   goto disable_regulators;
}
 
dev_info(>dev, "registering %s accelerometer; ID 0x%x\n",
@@ -1566,13 +1594,13 @@ static int mma8452_probe(struct i2c_client *client,
 
ret = mma8452_reset(client);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
data->data_cfg = MMA8452_DATA_CFG_FS_2G;
ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
data->data_cfg);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
/*
 * By default set transient threshold to max to avoid events if
@@ -1581,7 +1609,7 @@ static int mma8452_probe(struct i2c_client *client,
ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
MMA8452_TRANSIENT_THS_MASK);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
if (client->irq) {
int irq2;
@@ -1595,7 +1623,7 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG5,
data->chip_info->all_events);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
dev_dbg(>dev, "using interrupt line INT1\n");
}
@@ -1604,11 +1632,11 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG4,
data->chip_info->enabled_events);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
 
ret = mma8452_trigger_setup(indio_dev);
if (ret < 0)
-   return ret;
+   goto disable_regulators;
}
 
data->ctrl_reg1 = MMA8452_CTRL_ACTIVE |
@@ -1661,12 +1689,19 @@ static int mma8452_probe(struct i2c_client *client,
 

RE: [PATCH] pinctrl: freescale: Break dependency on SOC_IMX8MQ for i.MX8MQ

[Aisheng Dong]

> -Original Message-
> From: Abel Vesa
> Sent: Sunday, December 23, 2018 3:09 PM
> 
> The CONFIG_SOC_IMX8MQ will go away, so the dependency can be based on
> ARCH_MXC && ARM64.
> 
> Signed-off-by: Abel Vesa 

Acked-by: Dong Aisheng 

Regards
Dong Aisheng

RE: [PATCH] phy: freescale: Break dependency on SOC_IMX8MQ for USB PHY

[Aisheng Dong]

> -Original Message-
> From: Abel Vesa
> Sent: Sunday, December 23, 2018 3:04 PM
> To: Kishon Vijay Abraham I ; Jun Li ; Lucas
> Stach 
> Cc: dl-linux-imx ; Linux Kernel Mailing List
> ; Abel Vesa 
> Subject: [PATCH] phy: freescale: Break dependency on SOC_IMX8MQ for USB
> PHY
> 
> Since this is going to be used on more SoCs than just i.MX8MQ, make the
> dependency here more generic.
> 
> Signed-off-by: Abel Vesa 

Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

[GIT PULL] Changes for KVM 4.21

[Paolo Bonzini]

Linus,

The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d:

  Linux 4.20-rc6 (2018-12-09 15:31:00 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to a0aea130afebcd091d5396d13f25b9da24c9144a:

  KVM: x86: Add CPUID support for new instruction WBNOINVD (2018-12-21 14:26:32 
+0100)

The PT and Hyper-V changes have been acked by the maintainers; since
Ingo acked the MPX issue and is going to remove the topic branch, all that
is left is two trivial conflicts.

One is due to the disintegration of arch/x86/kvm/vmx.c; only one commit
in all of linux-next touched that file, so this will be enough to fix it:

$ git log --oneline v4.20-rc6..origin/master -- arch/x86/kvm/vmx.c
c2dd5146e9fe KVM: Fix UAF in nested posted interrupt processing
$ git rm arch/x86/kvm/vmx.c
$ git show c2dd5146e9fe | patch arch/x86/kvm/vmx/nested.c
patching file arch/x86/kvm/vmx/nested.c
Hunk #1 succeeded at 2881 (offset -9104 lines).

The second is with the PPC tree, due to commit d7b456152230 in my tree, you
can solve it in your sleep but anyway the resolution is after the diffstat.
 
Thanks,

Paolo


* ARM: selftests improvements, large PUD support for HugeTLB,
single-stepping fixes, improved tracing, various timer and vGIC
fixes

* x86: Processor Tracing virtualization, STIBP support, some correctness fixes,
refactorings and splitting of vmx.c, use the Hyper-V range TLB flush hypercall,
reduce order of vcpu struct, WBNOINVD support, do not use -ftrace for __noclone
functions, nested guest support for PAUSE filtering on AMD, more Hyper-V
enlightenments (direct mode for synthetic timers)

* PPC: nested VFIO

* s390: bugfixes only this time


Andrew Jones (8):
  kvm: selftests: x86_64: dirty_log_test: fix -t
  kvm: selftests: dirty_log_test: don't identity map the test mem
  kvm: selftests: dirty_log_test: always use -t
  kvm: selftests: dirty_log_test: reset guest test phys offset
  kvm: selftests: dirty_log_test: improve mode param management
  kvm: selftests: add pa-48/va-48 VM modes
  kvm: selftests: aarch64: dirty_log_test: support greater than 40-bit IPAs
  kvm: selftests: ucall: fix exit mmio address guessing

Bharata B Rao (1):
  KVM: PPC: Pass change type down to memslot commit function

Chao Peng (7):
  perf/x86/intel/pt: Move Intel PT MSRs bit defines to global header
  perf/x86/intel/pt: Export pt_cap_get()
  KVM: x86: Add Intel PT virtualization work mode
  KVM: x86: Add Intel Processor Trace cpuid emulation
  KVM: x86: Add Intel PT context switch for each vcpu
  KVM: x86: Implement Intel PT MSRs read/write emulation
  KVM: x86: Set intercept for Intel PT MSRs read/write

Christoffer Dall (9):
  KVM: arm/arm64: Fix VMID alloc race by reverting to lock-less
  KVM: arm/arm64: vgic-v2: Set active_source to 0 when restoring state
  KVM: arm64: Clarify explanation of STAGE2_PGTABLE_LEVELS
  KVM: arm/arm64: vgic: Consider priority and active state for pending irq
  KVM: arm/arm64: Fixup the kvm_exit tracepoint
  KVM: arm/arm64: Remove arch timer workqueue
  KVM: arm/arm64: arch_timer: Simplify kvm_timer_vcpu_terminate
  KVM: arm64: Make vcpu const in vcpu_read_sys_reg
  KVM: arm/arm64: Fix unintended stage 2 PMD mappings

Eduardo Habkost (1):
  kvm: x86: Report STIBP on GET_SUPPORTED_CPUID

Gustavo A. R. Silva (1):
  KVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq()

Jim Mattson (11):
  KVM: nVMX: Unrestricted guest mode requires EPT
  kvm: nVMX: Set VM instruction error for VMPTRLD of unbacked page
  kvm: vmx: Set IA32_TSC_AUX for legacy mode guests
  kvm: vmx: Document the need for MSR_STAR in i386 builds
  kvm: vmx: Don't set hardware IA32_CSTAR MSR on VM-entry
  kvm: vmx: Skip all SYSCALL MSRs in setup_msrs() when !EFER.SCE
  kvm: x86: Don't modify MSR_PLATFORM_INFO on vCPU reset
  kvm: Disallow wraparound in kvm_gfn_to_hva_cache_init
  kvm: Change offset in kvm_write_guest_offset_cached to unsigned
  kvm: nVMX: NMI-window and interrupt-window exiting should wake L2 from HLT
  kvm: vmx: Allow guest read access to IA32_TSC

Julien Thierry (1):
  KVM: arm/arm64: vgic: Do not cond_resched_lock() with IRQs disabled

Krish Sadhukhan (8):
  nVMX x86: Check VMX-preemption timer controls on vmentry of L2 guests
  KVM nVMX: MSRs should not be stored if VM-entry fails during or after 
loading guest state
  KVM: nVMX: Prepend "nested_vmx_" to check_vmentry_{pre,post}reqs()
  KVM: nVMX: Move the checks for VM-Execution Control Fields to a separate 
helper function
  KVM: nVMX: Move the checks for VM-Exit Control Fields to a separate 
helper function
  KVM: nVMX: 

RE: [PATCH] soc: imx: Break dependency on SOC_IMX8MQ for GPCv2

[Aisheng Dong]

> -Original Message-
> From: Abel Vesa
> Sent: Sunday, December 23, 2018 3:00 PM
> To: Shawn Guo ; Sascha Hauer
> ; Fabio Estevam 
> Cc: dl-linux-imx ; linux-arm-ker...@lists.infradead.org;
> Linux Kernel Mailing List ; Abel Vesa
> 
> Subject: [PATCH] soc: imx: Break dependency on SOC_IMX8MQ for GPCv2
> 
> Since this is going to be used on more SoCs than just i.MX8MQ, make the
> dependency here more generic.
> 
> Signed-off-by: Abel Vesa 
> ---
>  drivers/soc/imx/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig index
> 2112d18..7ffbb6b 100644
> --- a/drivers/soc/imx/Kconfig
> +++ b/drivers/soc/imx/Kconfig
> @@ -2,7 +2,7 @@ menu "i.MX SoC drivers"
> 
>  config IMX_GPCV2_PM_DOMAINS
>   bool "i.MX GPCv2 PM domains"
> - depends on SOC_IMX7D || SOC_IMX8MQ || (COMPILE_TEST && OF)
> + depends on SOC_IMX7D || ARCH_MXC || (COMPILE_TEST && OF)

Nitpick:
ARCH_MXC already contains SOC_IMX7D, so simply depends on
ARCH_MXC || (COMPILE_TEST && OF) should be enough.

Otherwise:
Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

>   depends on PM
>   select PM_GENERIC_DOMAINS
>   default y if SOC_IMX7D
> --
> 2.7.4

[PATCH 04/20] scsi: lpfc: lpfc_scsi: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

These were introduced in 8a9d2e8003040 ("[SCSI] lpfc 8.3.31:
Correct handling of SLI4-port XRI resource-provisioning profile
change"), but were not even used at that time.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 8a9d2e8003040 ("[SCSI] lpfc 8.3.31: Correct handling of SLI4-port XRI 
resource-provisioning profile change")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/scsi/lpfc/lpfc_scsi.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index b4f1a840b3b4..dd415d783593 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -805,9 +805,7 @@ lpfc_new_scsi_buf_s4(struct lpfc_vport *vport, int 
num_to_alloc)
dma_addr_t pdma_phys_bpl;
uint16_t iotag, lxri = 0;
int bcnt, num_posted, sgl_size;
-   LIST_HEAD(prep_sblist);
LIST_HEAD(post_sblist);
-   LIST_HEAD(scsi_sblist);
 
sgl_size = phba->cfg_sg_dma_buf_size -
(sizeof(struct fcp_cmnd) + sizeof(struct fcp_rsp));

[PATCH 01/20] nfsd: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

This was introduced in c5c707f96fc9a ("nfsd: implement pNFS
layout recalls"), but was not used even in that commit.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: c5c707f96fc9a ("nfsd: implement pNFS layout recalls")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 fs/nfsd/nfs4layouts.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index 2b36aa037ce0..44517fb5c0de 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -656,7 +656,6 @@ nfsd4_cb_layout_done(struct nfsd4_callback *cb, struct 
rpc_task *task)
struct nfsd_net *nn;
ktime_t now, cutoff;
const struct nfsd4_layout_ops *ops;
-   LIST_HEAD(reaplist);
 
 
switch (task->tk_status) {

[PATCH 10/20] scsi: qla2xxx: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The uses of new_fcports were removed in 726b85487067 ("qla2xxx:
Add framework for async fabric discovery"), but not the
declaration.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/scsi/qla2xxx/qla_init.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 364bb52ed2a6..d72e3ad97a54 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -5400,7 +5400,6 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
fc_port_t   *fcport;
uint16_tmb[MAILBOX_REGISTER_COUNT];
uint16_tloop_id;
-   LIST_HEAD(new_fcports);
struct qla_hw_data *ha = vha->hw;
int discovery_gen;
 

[PATCH 17/20] dmaengine: pl330: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The variable has not been used since the function was introduced
in 740aa95703c5 ("dmaengine: pl330: Split device_control").

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 740aa95703c5 ("dmaengine: pl330: Split device_control")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/dma/pl330.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index cff1b143fff5..eec79fdf27a5 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2267,7 +2267,6 @@ static int pl330_terminate_all(struct dma_chan *chan)
struct dma_pl330_desc *desc;
unsigned long flags;
struct pl330_dmac *pl330 = pch->dmac;
-   LIST_HEAD(list);
bool power_down = false;
 
pm_runtime_get_sync(pl330->ddma.dev);

[PATCH 11/20] Btrfs: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The uses were removed in 3fd0a5585eb9 ("Btrfs: Metadata ENOSPC
handling for balance"), but not the declaration.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 3fd0a5585eb9 ("Btrfs: Metadata ENOSPC handling for balance")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 fs/btrfs/relocation.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 272b287f8cf0..de802ba35a34 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2128,7 +2128,6 @@ static noinline_for_stack int merge_reloc_root(struct 
reloc_control *rc,
   struct btrfs_root *root)
 {
struct btrfs_fs_info *fs_info = rc->extent_root->fs_info;
-   LIST_HEAD(inode_list);
struct btrfs_key key;
struct btrfs_key next_key;
struct btrfs_trans_handle *trans = NULL;

[PATCH 18/20] dmaengine: sa11x0: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never been
used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 4a533218fccf ("dmaengine: sa11x0: Split device_control")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/dma/sa11x0-dma.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/dma/sa11x0-dma.c b/drivers/dma/sa11x0-dma.c
index 784d5f1a473b..3fae23768b47 100644
--- a/drivers/dma/sa11x0-dma.c
+++ b/drivers/dma/sa11x0-dma.c
@@ -705,7 +705,6 @@ static int sa11x0_dma_device_pause(struct dma_chan *chan)
struct sa11x0_dma_chan *c = to_sa11x0_dma_chan(chan);
struct sa11x0_dma_dev *d = to_sa11x0_dma(chan->device);
struct sa11x0_dma_phy *p;
-   LIST_HEAD(head);
unsigned long flags;
 
dev_dbg(d->slave.dev, "vchan %p: pause\n", >vc);
@@ -732,7 +731,6 @@ static int sa11x0_dma_device_resume(struct dma_chan *chan)
struct sa11x0_dma_chan *c = to_sa11x0_dma_chan(chan);
struct sa11x0_dma_dev *d = to_sa11x0_dma(chan->device);
struct sa11x0_dma_phy *p;
-   LIST_HEAD(head);
unsigned long flags;
 
dev_dbg(d->slave.dev, "vchan %p: resume\n", >vc);

[PATCH 16/20] mlxsw: spectrum: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The uses were removed in 244cd96adb5f ("net_sched: remove
list_head from tc_action"), but not the declaration.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 244cd96adb5f ("net_sched: remove list_head from tc_action")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/net/ethernet/mellanox/mlxsw/spectrum.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index c742a581f0d0..eed1045e4d96 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -1347,7 +1347,6 @@ static int mlxsw_sp_port_add_cls_matchall(struct 
mlxsw_sp_port *mlxsw_sp_port,
struct mlxsw_sp_port_mall_tc_entry *mall_tc_entry;
__be16 protocol = f->common.protocol;
const struct tc_action *a;
-   LIST_HEAD(actions);
int err;
 
if (!tcf_exts_has_one_action(f->exts)) {

[PATCH 15/20] NFS: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never
been used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 0e20162ed1e9 ("NFSv4.1 Use MDS auth flavor for data server connection")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 fs/nfs/nfs4client.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 2548405da1f7..735c1056a91c 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -145,7 +145,6 @@ static void
 nfs4_shutdown_ds_clients(struct nfs_client *clp)
 {
struct nfs4_ds_server *dss;
-   LIST_HEAD(shutdown_list);
 
while (!list_empty(>cl_ds_clients)) {
dss = list_entry(clp->cl_ds_clients.next,

[PATCH 20/20] cw1200: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never
been used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: a910e4a94f692 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN 
chipsets")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/net/wireless/st/cw1200/queue.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/st/cw1200/queue.c 
b/drivers/net/wireless/st/cw1200/queue.c
index 7c31b63b8258..7895efefa95d 100644
--- a/drivers/net/wireless/st/cw1200/queue.c
+++ b/drivers/net/wireless/st/cw1200/queue.c
@@ -283,7 +283,6 @@ int cw1200_queue_put(struct cw1200_queue *queue,
 struct cw1200_txpriv *txpriv)
 {
int ret = 0;
-   LIST_HEAD(gc_list);
struct cw1200_queue_stats *stats = queue->stats;
 
if (txpriv->link_id >= queue->stats->map_capacity)

[PATCH 19/20] net/mlx4_core: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never
been used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: c82e9aa0a8bc ("mlx4_core: resource tracking for HCA resources used by 
guests")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c 
b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 31bd56727022..eb13d3618162 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -4729,7 +4729,6 @@ static void rem_slave_srqs(struct mlx4_dev *dev, int 
slave)
struct res_srq *tmp;
int state;
u64 in_param;
-   LIST_HEAD(tlist);
int srqn;
int err;
 
@@ -4795,7 +4794,6 @@ static void rem_slave_cqs(struct mlx4_dev *dev, int slave)
struct res_cq *tmp;
int state;
u64 in_param;
-   LIST_HEAD(tlist);
int cqn;
int err;
 
@@ -4858,7 +4856,6 @@ static void rem_slave_mrs(struct mlx4_dev *dev, int slave)
struct res_mpt *tmp;
int state;
u64 in_param;
-   LIST_HEAD(tlist);
int mptn;
int err;
 
@@ -4926,7 +4923,6 @@ static void rem_slave_mtts(struct mlx4_dev *dev, int 
slave)
struct res_mtt *mtt;
struct res_mtt *tmp;
int state;
-   LIST_HEAD(tlist);
int base;
int err;
 
@@ -5115,7 +5111,6 @@ static void rem_slave_eqs(struct mlx4_dev *dev, int slave)
struct res_eq *tmp;
int err;
int state;
-   LIST_HEAD(tlist);
int eqn;
 
err = move_all_busy(dev, slave, RES_EQ);

[PATCH 14/20] dmaengine: st_fdma: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The declarations were introduced with the file, but the declared
variables were not used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine 
driver support")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/dma/st_fdma.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 07c20aa2e955..954f7cf62bb1 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -294,8 +294,6 @@ static void st_fdma_free_chan_res(struct dma_chan *chan)
struct rproc *rproc = fchan->fdev->slim_rproc->rproc;
unsigned long flags;
 
-   LIST_HEAD(head);
-
dev_dbg(fchan->fdev->dev, "%s: freeing chan:%d\n",
__func__, fchan->vchan.chan.chan_id);
 
@@ -626,7 +624,6 @@ static void st_fdma_issue_pending(struct dma_chan *chan)
 static int st_fdma_pause(struct dma_chan *chan)
 {
unsigned long flags;
-   LIST_HEAD(head);
struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
int ch_id = fchan->vchan.chan.chan_id;
unsigned long cmd = FDMA_CMD_PAUSE(ch_id);

[PATCH 05/20] scsi: lpfc: lpfc_sli: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never
been used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 895427bd012ce ("scsi: lpfc: NVME Initiator: Base modifications")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/scsi/lpfc/lpfc_sli.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 30734caf77e1..13fe9d3331b9 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -3948,7 +3948,6 @@ lpfc_sli_abort_iocb_ring(struct lpfc_hba *phba, struct 
lpfc_sli_ring *pring)
 void
 lpfc_sli_abort_wqe_ring(struct lpfc_hba *phba, struct lpfc_sli_ring *pring)
 {
-   LIST_HEAD(completions);
struct lpfc_iocbq *iocb, *next_iocb;
 
if (pring->ringno == LPFC_ELS_RING)

[PATCH 13/20] xenbus: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

The declarations were introduced with the file, but the declared
variables were not used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 1107ba885e46 ("xen: add xenfs to allow usermode <-> Xen interaction")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/xen/xenbus/xenbus_dev_frontend.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index c3e201025ef0..25c53545ea01 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -465,7 +465,6 @@ static int xenbus_write_watch(unsigned msg_type, struct 
xenbus_file_priv *u)
struct watch_adapter *watch;
char *path, *token;
int err, rc;
-   LIST_HEAD(staging_q);
 
path = u->u.buffer + sizeof(u->u.msg);
token = memchr(path, 0, u->u.msg.len);
@@ -523,7 +522,6 @@ static ssize_t xenbus_file_write(struct file *filp,
uint32_t msg_type;
int rc = len;
int ret;
-   LIST_HEAD(staging_q);
 
/*
 * We're expecting usermode to be writing properly formed

[PATCH 00/20] drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

---

 drivers/dma/at_hdmac.c|5 -
 drivers/dma/dw/core.c |1 -
 drivers/dma/pl330.c   |1 -
 drivers/dma/sa11x0-dma.c  |2 --
 drivers/dma/st_fdma.c |3 ---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c   |1 -
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |5 -
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c   |3 ---
 drivers/net/ethernet/mellanox/mlxsw/spectrum.c|1 -
 drivers/net/wireless/st/cw1200/queue.c|1 -
 drivers/scsi/lpfc/lpfc_nvme.c |2 --
 drivers/scsi/lpfc/lpfc_scsi.c |2 --
 drivers/scsi/lpfc/lpfc_sli.c  |1 -
 drivers/scsi/qla2xxx/qla_init.c   |1 -
 drivers/xen/xenbus/xenbus_dev_frontend.c  |2 --
 fs/btrfs/relocation.c |1 -
 fs/nfs/nfs4client.c   |1 -
 fs/nfsd/nfs4layouts.c |1 -
 fs/xfs/xfs_buf.c  |1 -
 fs/xfs/xfs_fsops.c|1 -
 20 files changed, 36 deletions(-)

[PATCH 03/20] scsi: lpfc: lpfc_nvme: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

These were introduced with the file, but were not even used
at that time.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 01649561a8b4b ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/scsi/lpfc/lpfc_nvme.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 4c66b19e6199..2119f36213e4 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2234,9 +2234,7 @@ lpfc_new_nvme_buf(struct lpfc_vport *vport, int 
num_to_alloc)
dma_addr_t pdma_phys_sgl;
uint16_t iotag, lxri = 0;
int bcnt, num_posted;
-   LIST_HEAD(prep_nblist);
LIST_HEAD(post_nblist);
-   LIST_HEAD(nvme_nblist);
 
for (bcnt = 0; bcnt < num_to_alloc; bcnt++) {
lpfc_ncmd = kzalloc(sizeof(struct lpfc_nvme_buf), GFP_KERNEL);

[PATCH 12/20] dmaengine: dw: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

Commit ab703f818ac3 ("dmaengine: dw: lazy allocation of dma
descriptors") removed the uses, but not the declaration.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: ab703f818ac3 ("dmaengine: dw: lazy allocation of dma descriptors")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/dma/dw/core.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index dc053e62f894..290d21be4d4c 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1150,7 +1150,6 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
struct dw_dma_chan  *dwc = to_dw_dma_chan(chan);
struct dw_dma   *dw = to_dw_dma(chan->device);
unsigned long   flags;
-   LIST_HEAD(list);
 
dev_dbg(chan2dev(chan), "%s: descs allocated=%u\n", __func__,
dwc->descs_allocated);

[PATCH 07/20] dmaengine: at_hdmac: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

tmp_list has been declared since the introduction of the driver
and has never been used.  The two declarations of list were
introduced with the containing functions but were also not used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA 
Controller")
Fixes: 4facfe7f09f2b ("dmaengine: hdmac: Split device_control")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/dma/at_hdmac.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 01d936c9fe89..a0a9cd76c1d4 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -134,7 +134,6 @@ static struct at_desc *atc_desc_get(struct at_dma_chan 
*atchan)
struct at_desc *ret = NULL;
unsigned long flags;
unsigned int i = 0;
-   LIST_HEAD(tmp_list);
 
spin_lock_irqsave(>lock, flags);
list_for_each_entry_safe(desc, _desc, >free_list, desc_node) {
@@ -1387,8 +1386,6 @@ static int atc_pause(struct dma_chan *chan)
int chan_id = atchan->chan_common.chan_id;
unsigned long   flags;
 
-   LIST_HEAD(list);
-
dev_vdbg(chan2dev(chan), "%s\n", __func__);
 
spin_lock_irqsave(>lock, flags);
@@ -1408,8 +1405,6 @@ static int atc_resume(struct dma_chan *chan)
int chan_id = atchan->chan_common.chan_id;
unsigned long   flags;
 
-   LIST_HEAD(list);
-
dev_vdbg(chan2dev(chan), "%s\n", __func__);
 
if (!atc_chan_is_paused(atchan))

[PATCH 09/20] xfs: xfs_fsops: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

Commit 0410c3bb2b88 ("xfs: factor ag btree root block
initialisation") stopped using buffer_list and started using a
buffer list in an aghdr_init_data structure, but the declaration
of buffer_list was not removed.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 0410c3bb2b88 ("xfs: factor ag btree root block initialisation")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 fs/xfs/xfs_fsops.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index ec2e63a7963b..f3ef70c542e1 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -40,7 +40,6 @@ xfs_growfs_data_private(
xfs_rfsblock_t  new;
xfs_agnumber_t  oagcount;
xfs_trans_t *tp;
-   LIST_HEAD   (buffer_list);
struct aghdr_init_data  id = {};
 
nb = in->newblocks;

[PATCH 06/20] IB/ipoib: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

Commit 31c02e215700 ("IPoIB: Avoid using stale last_send counter
when reaping AHs") removed the uses, but not the declaration.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 31c02e215700 ("IPoIB: Avoid using stale last_send counter when reaping 
AHs")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/infiniband/ulp/ipoib/ipoib_ib.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c 
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 6d35570092d6..78fa777c87b1 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -669,7 +669,6 @@ static void __ipoib_reap_ah(struct net_device *dev)
 {
struct ipoib_dev_priv *priv = ipoib_priv(dev);
struct ipoib_ah *ah, *tah;
-   LIST_HEAD(remove_list);
unsigned long flags;
 
netif_tx_lock_bh(dev);

[PATCH 02/20] net/mlx5e: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares is never used.

These became useless in 244cd96adb5f ("net_sched: remove list_head
from tc_action")

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 244cd96adb5f ("net_sched: remove list_head from tc_action")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 4d6c9757afad..cae6c6d48984 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2183,7 +2183,6 @@ static bool modify_header_match_supported(struct 
mlx5_flow_spec *spec,
 {
const struct tc_action *a;
bool modify_ip_header;
-   LIST_HEAD(actions);
u8 htype, ip_proto;
void *headers_v;
u16 ethertype;
@@ -2272,7 +2271,6 @@ static int parse_tc_nic_actions(struct mlx5e_priv *priv, 
struct tcf_exts *exts,
 {
struct mlx5_nic_flow_attr *attr = flow->nic_attr;
const struct tc_action *a;
-   LIST_HEAD(actions);
u32 action = 0;
int err, i;
 
@@ -2511,7 +2509,6 @@ static int parse_tc_fdb_actions(struct mlx5e_priv *priv, 
struct tcf_exts *exts,
struct mlx5e_rep_priv *rpriv = priv->ppriv;
struct ip_tunnel_info *info = NULL;
const struct tc_action *a;
-   LIST_HEAD(actions);
bool encap = false;
u32 action = 0;
int err, i;

[PATCH 08/20] xfs: xfs_buf: drop useless LIST_HEAD

[Julia Lawall]

Drop LIST_HEAD where the variable it declares has never
been used.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
identifier x;
@@
- LIST_HEAD(x);
  ... when != x
// 

Fixes: 26f1fe858f274 ("xfs: reduce lock hold times in buffer writeback")
Signed-off-by: Julia Lawall 

---
Successfully 0-day tested on 151 configurations.

 fs/xfs/xfs_buf.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index b21ea2ba768d..eedc5e0156ff 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -1992,7 +1992,6 @@ xfs_buf_delwri_submit_buffers(
struct list_head*wait_list)
 {
struct xfs_buf  *bp, *n;
-   LIST_HEAD   (submit_list);
int pinned = 0;
struct blk_plug plug;
 

Re: [PATCH 02/20] net/mlx5e: drop useless LIST_HEAD

[Leon Romanovsky]

On Sun, Dec 23, 2018 at 09:56:57AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> These became useless in 244cd96adb5f ("net_sched: remove list_head
> from tc_action")
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
>   ... when != x
> // 
>
> Fixes: 244cd96adb5f ("net_sched: remove list_head from tc_action")
> Signed-off-by: Julia Lawall 
>

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH 06/20] IB/ipoib: drop useless LIST_HEAD

[Leon Romanovsky]

On Sun, Dec 23, 2018 at 09:57:01AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> Commit 31c02e215700 ("IPoIB: Avoid using stale last_send counter
> when reaping AHs") removed the uses, but not the declaration.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
>   ... when != x
> // 
>
> Fixes: 31c02e215700 ("IPoIB: Avoid using stale last_send counter when reaping 
> AHs")
> Signed-off-by: Julia Lawall 
>

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

[PATCH 2/4] bitmap_parselist: move part of logic to helpers

[Yuri Norov]

Move region checking and setting functionality of __bitmap_parselist()
to helpers.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 64 +++-
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index ad43ba397c58..a60fd9723677 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -477,6 +477,42 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const 
unsigned long *maskp,
 }
 EXPORT_SYMBOL(bitmap_print_to_pagebuf);
 
+/*
+ * Region 9-38:4/10 describes the following bitmap structure:
+ * 0  9  1218  38
+ * .......
+ * ^  ^ ^   ^
+ *  start  off   grlenend
+ */
+struct region {
+   unsigned int start;
+   unsigned int off;
+   unsigned int grlen;
+   unsigned int end;
+};
+
+static int bitmap_set_region(const struct region *r,
+   unsigned long *bitmap, int nbits)
+{
+   unsigned int start;
+
+   if (r->end >= nbits)
+   return -ERANGE;
+
+   for (start = r->start; start <= r->end; start += r->grlen)
+   bitmap_set(bitmap, start, min(r->end - start + 1, r->off));
+
+   return 0;
+}
+
+static int bitmap_check_region(const struct region *r)
+{
+   if (r->start > r->end || r->grlen == 0 || r->off > r->grlen)
+   return -EINVAL;
+
+   return 0;
+}
+
 /**
  * __bitmap_parselist - convert list format ASCII string to bitmap
  * @buf: read nul-terminated user string from this buffer
@@ -507,10 +543,11 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
int nmaskbits)
 {
unsigned int a, b, old_a, old_b;
-   unsigned int group_size, used_size, off;
+   unsigned int group_size, used_size;
int c, old_c, totaldigits, ndigits;
const char __user __force *ubuf = (const char __user __force *)buf;
-   int at_start, in_range, in_partial_range;
+   int at_start, in_range, in_partial_range, ret;
+   struct region r;
 
totaldigits = c = 0;
old_a = old_b = 0;
@@ -599,15 +636,20 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
/* if no digit is after '-', it's wrong*/
if (at_start && in_range)
return -EINVAL;
-   if (!(a <= b) || group_size == 0 || !(used_size <= group_size))
-   return -EINVAL;
-   if (b >= nmaskbits)
-   return -ERANGE;
-   while (a <= b) {
-   off = min(b - a + 1, used_size);
-   bitmap_set(maskp, a, off);
-   a += group_size;
-   }
+
+   r.start = a;
+   r.off = used_size;
+   r.grlen = group_size;
+   r.end = b;
+
+   ret = bitmap_check_region();
+   if (ret)
+   return ret;
+
+   ret = bitmap_set_region(, maskp, nmaskbits);
+   if (ret)
+   return ret;
+
} while (buflen && c == ',');
return 0;
 }
-- 
2.17.1

[PATCH 1/4] bitmap_parselist: don't calculate length of the input string

[Yuri Norov]

bitmap_parselist() calculates length of the input string before passing
it to the __bitmap_parselist(). But the end-of-line condition is checked
for every character in __bitmap_parselist() anyway. So doing it in wrapper
is a simple waste of time.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index eead55aa7170..ad43ba397c58 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -614,10 +614,7 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
 
 int bitmap_parselist(const char *bp, unsigned long *maskp, int nmaskbits)
 {
-   char *nl  = strchrnul(bp, '\n');
-   int len = nl - bp;
-
-   return __bitmap_parselist(bp, len, 0, maskp, nmaskbits);
+   return __bitmap_parselist(bp, UINT_MAX, 0, maskp, nmaskbits);
 }
 EXPORT_SYMBOL(bitmap_parselist);
 
-- 
2.17.1

[PATCH 4/4] test_bitmap: add testcases for bitmap_parselist

[Yuri Norov]

Add tests for non-number character, empty regions, integer overflow.

Signed-off-by: Yury Norov 
---
 lib/test_bitmap.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6cd7d0740005..7580dd6ac599 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -224,7 +224,8 @@ static const unsigned long exp[] __initconst = {
BITMAP_FROM_U64(0x),
BITMAP_FROM_U64(0xfffe),
BITMAP_FROM_U64(0xULL),
-   BITMAP_FROM_U64(0xULL)
+   BITMAP_FROM_U64(0xULL),
+   BITMAP_FROM_U64(0),
 };
 
 static const unsigned long exp2[] __initconst = {
@@ -247,19 +248,34 @@ static const struct test_bitmap_parselist 
parselist_tests[] __initconst = {
{0, "1-31:4/4", [9 * step], 32, 0},
{0, "0-31:1/4,32-63:2/4",   [10 * step], 64, 0},
{0, "0-31:3/4,32-63:4/4",   [11 * step], 64, 0},
+   {0, "  ,,  0-31:3/4  ,, 32-63:4/4  ,,  ",   [11 * step], 64, 0},
 
{0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
 
{0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
 
+   {0, "", [12], 8, 0},
+   {0, "\n",   [12], 8, 0},
+   {0, ",,  ,,  , ,  ,",   [12], 8, 0},
+   {0, " ,  ,,  , ,   ",   [12], 8, 0},
+   {0, " ,  ,,  , ,   \n", [12], 8, 0},
+
{-EINVAL, "-1", NULL, 8, 0},
{-EINVAL, "-0", NULL, 8, 0},
{-EINVAL, "10-1", NULL, 8, 0},
{-EINVAL, "0-31:", NULL, 8, 0},
{-EINVAL, "0-31:0", NULL, 8, 0},
+   {-EINVAL, "0-31:0/", NULL, 8, 0},
{-EINVAL, "0-31:0/0", NULL, 8, 0},
{-EINVAL, "0-31:1/0", NULL, 8, 0},
{-EINVAL, "0-31:10/1", NULL, 8, 0},
+   {-EOVERFLOW, "0-98765432123456789:10/1", NULL, 8, 0},
+
+   {-EINVAL, "a-31", NULL, 8, 0},
+   {-EINVAL, "0-a1", NULL, 8, 0},
+   {-EINVAL, "a-31:10/1", NULL, 8, 0},
+   {-EINVAL, "0-31:a/1", NULL, 8, 0},
+   {-EINVAL, "0-\n", NULL, 8, 0},
 };
 
 static void __init test_bitmap_parselist(void)
-- 
2.17.1

[PATCH 0/4] rework bitmap_parselist

[Yuri Norov]

bitmap_parselist evolved from a pretty simple idea for long and now lacks
for refactoring. It is not structured, has nested loops and a set of
opaque-named variables. All this leads to extremely hard understanding
of the code. Once during the optimization of it I missed a scenario which
leads to kernel hangup. Tetsuo Handa spotted this and found it simpler to
rewrite the code instead fixing it. (Though, that attempt had some flaws.)
https://lkml.org/lkml/2018/4/1/93

Things are more complicated than they may be because bitmap_parselist()
is part of user interface, and its behavior should not change.

In this patchset __bitmap_parselist() is split to a set of smaller
functions doing only one thing.

Yury Norov (4):
  bitmap_parselist: don't calculate length of the input string
  bitmap_parselist: move part of logic to helpers
  bitmap_parselist: rework input string parser
  test_bitmap: add testcases for bitmap_parselist

 lib/bitmap.c  | 294 ++
 lib/test_bitmap.c |  18 ++-
 2 files changed, 208 insertions(+), 104 deletions(-)

-- 
2.17.1

[PATCH 3/4] bitmap_parselist: rework input string parser

[Yuri Norov]

The requirement for this rework is to keep the __bitmap_parselist()
copy-less and single-pass but make it more readable and maintainable by
splitting into logical parts and removing explicit nested cycles and
opaque local variables.

__bitmap_parselist() can parse userspace inputs and therefore we cannot
use simple_strtoul() to parse numbers.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 247 ++-
 1 file changed, 148 insertions(+), 99 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index a60fd9723677..edc7068c28a6 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -513,6 +513,140 @@ static int bitmap_check_region(const struct region *r)
return 0;
 }
 
+static long get_char(char *c, const char *str, int is_user)
+{
+   if (unlikely(is_user))
+   return __get_user(*c, str);
+
+   *c = *str;
+   return 0;
+}
+
+static const char *bitmap_getnum(unsigned int *num, const char *str,
+   const char *const end, int is_user)
+{
+   unsigned int n = 0;
+   const char *_str;
+   long ret;
+   char c;
+
+   for (_str = str, *num = 0; _str <= end; _str++) {
+   ret = get_char(, _str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (!isdigit(c)) {
+   if (_str == str)
+   return (char *)-EINVAL;
+
+   goto out;
+   }
+
+   *num = *num * 10 + (c - '0');
+   if (*num < n)
+   return (char *)-EOVERFLOW;
+
+   n = *num;
+   }
+
+out:
+   return _str;
+}
+
+static const char *bitmap_find_region(const char *str,
+   const char *const end, int is_user)
+{
+   long ret;
+   char c;
+
+   for (; str < end; str++) {
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   /* Unexpected end of line. */
+   if (c == 0 || c == '\n')
+   return NULL;
+
+   /*
+* The format allows commas and whitespases
+* at the beginning of the region, so skip it.
+*/
+   if (!isspace(c) && c != ',')
+   break;
+   }
+
+   return str;
+}
+
+static const char *bitmap_parse_region(struct region *r, const char *str,
+const char *const end, int is_user)
+{
+   long ret;
+   char c;
+
+   str = bitmap_getnum(>start, str, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (c == 0 || c == '\n') {
+   str = end + 1;
+   goto no_end;
+   }
+
+   if (isspace(c) || c == ',')
+   goto no_end;
+
+   if (c != '-')
+   return (char *)-EINVAL;
+
+   str = bitmap_getnum(>end, str + 1, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (c == 0 || c == '\n') {
+   str = end + 1;
+   goto no_pattern;
+   }
+
+   if (isspace(c) || c == ',')
+   goto no_pattern;
+
+   if (c != ':')
+   return (char *)-EINVAL;
+
+   str = bitmap_getnum(>off, str + 1, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (c != '/')
+   return (char *)-EINVAL;
+
+   str = bitmap_getnum(>grlen, str + 1, end, is_user);
+
+   return str;
+
+no_end:
+   r->end = r->start;
+no_pattern:
+   r->off = r->end + 1;
+   r->grlen = r->end + 1;
+
+   return (char *)str;
+}
+
 /**
  * __bitmap_parselist - convert list format ASCII string to bitmap
  * @buf: read nul-terminated user string from this buffer
@@ -534,113 +668,28 @@ static int bitmap_check_region(const struct region *r)
  *
  * Returns: 0 on success, -errno on invalid input strings. Error values:
  *
- *   - ``-EINVAL``: second number in range smaller than first
+ *   - ``-EINVAL``: wrong region format
  *   - ``-EINVAL``: invalid character in string
  *   - ``-ERANGE``: bit number specified too large for mask
+ *   - ``-EOVERFLOW``: integer overflow in the input parameters
  */
-static int __bitmap_parselist(const char *buf, unsigned int buflen,
+static int __bitmap_parselist(const char *buf, const char *const end,
int is_user, unsigned long *maskp,
int nmaskbits)
 {
-   unsigned int a, b, old_a, old_b;
-   unsigned int group_size, used_size;
-   int c, old_c, totaldigits, ndigits;
-   const char __user __force *ubuf = (const char __user __force *)buf;
- 

[PATCH] staging: mt29f_spinand: add SPDX identifiers

[Michael Straube]

This satisfies a checkpatch warning and is the preferred
method for notating the license.

The SPDX identifier is a legally binding shorthand, which
can be used instead of the full boiler plate text.

Signed-off-by: Michael Straube 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 11 +--
 drivers/staging/mt29f_spinand/mt29f_spinand.h | 12 ++--
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index def8a1f57d1c..8630f7012957 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -1,17 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright (c) 2003-2013 Broadcom Corporation
  *
  * Copyright (c) 2009-2010 Micron Technology, Inc.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
  */
 
 #include 
diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.h 
b/drivers/staging/mt29f_spinand/mt29f_spinand.h
index 457dc7ffdaf1..38837cc6421c 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.h
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.h
@@ -1,17 +1,9 @@
-/*-
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
  * Copyright 2013 Broadcom Corporation
  *
  * Copyright (c) 2009-2010 Micron Technology, Inc.
  *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
  * Henry Pan 
  *
  * based on nand.h
-- 
2.20.1

Re: general protection fault in put_pid

[Dmitry Vyukov]

On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov  wrote:
>
> On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul  
> wrote:
> >
> > Hi Dmitry,
> >
> > On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
> > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
> > >  wrote:
> > >> Hello Dmitry,
> > >>
> > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
> > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot
> > >>>  wrote:
> >  Hello,
> > 
> >  syzbot found the following crash on:
> > 
> >  HEAD commit:f5d582777bcb Merge branch 'for-linus' of 
> >  git://git.kernel...
> >  git tree:   upstream
> >  console output: 
> >  https://syzkaller.appspot.com/x/log.txt?x=135bc54740
> >  kernel config:  
> >  https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> >  dashboard link: 
> >  https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> >  compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >  syz repro:  
> >  https://syzkaller.appspot.com/x/repro.syz?x=16803afb40
> > >>> +Manfred, this looks similar to the other few crashes related to
> > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at.
> > >> I found one unexpected (incorrect?) locking, see the attached patch.
> > >>
> > >> But I doubt that this is the root cause of the crashes.
> > >
> > > But why? These one-off sporadic crashes reported by syzbot looks
> > > exactly like a subtle race and your patch touches sem_exit_ns involved
> > > in all reports.
> > > So if you don't spot anything else, I would say close these 3 reports
> > > with this patch (I see you already included Reported-by tags which is
> > > great!) and then wait for syzbot reaction. Since we got 3 of them, if
> > > it's still not fixed I would expect that syzbot will be able to
> > > retrigger this later again.
> >
> > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and
> > nothing can happen.
> >
> > Every single-operation semop() reduces use_global_lock by one, i.e a
> > single semop call as done here cannot trigger the bug:
> >
> > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40
>
> It contains "repeat":true,"procs":6, which means that it run 6
> processes running this test in infinite loop. The last mark about
> number of tests executed was:
> 2018/12/11 18:38:02 executed programs: 2955
>
> > But, one more finding:
> >
> > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> >
> > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40
> >
> > The log file contain 1080 lines like these:
> >
> > > semget$private(..., 0x4003, ...)
> > >
> > > semget$private(..., 0x4006, ...)
> > >
> > > semget$private(..., 0x4007, ...)
> >
> > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an
> > allocation in the 4 MB kmalloc buffer:
> >
> > > [ 1201.210245] kmalloc-4194304  4698112KB4698112KB
> > >
> > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the
> > semaphore arrays??
>
> /\/\/\/\/\/\
>
> Ha, this is definitely not healthy.

I can reproduce this infinite memory consumption with the C program:
https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt

But this is working as intended, right? It just creates infinite
number of large semaphore sets, which reasonably consumes infinite
amount of memory.
Except that it also violates the memcg bound and a process can have
effectively unlimited amount of such "drum memory" in semaphores.




> > This one looks similar:
> >
> > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
> >
> > except that the array sizes are mixed, and thus there are kmalloc-1M and
> > kmalloc-2M as well.
> >
> > (and I did not count the number of semget calls)
> >
> >
> > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct?
> >
> > I.e. no CLONE_NEWUSER.
> >
> > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523
>
> CLONE_NEWUSER is used on some instances as well:
> https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765
> This crash happened on 2 different instances and 1 of them uses
> CLONE_NEWUSER and another does not.
> If it's important because of CAP_ADMIN in IPC namespace, then all
> instances should have it (instances that don't use NEWUSER are just
> root).

[PATCH] arm64: dts: rockchip: add rk3328 ACODEC node

[Katsuhiro Suzuki]

This patch adds audio codec (ACODEC) node that converts to analog
audio signal from I2S for rk3328.

Signed-off-by: Katsuhiro Suzuki 
---

This patch depends on Rockcihp RK3328 ACODEC driver patches that were
applied in ALSA SoC tree. We can see the patches on this thread.
  https://lkml.org/lkml/2018/12/20/665

 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index ecd7f19c3542..0f02b1dc87e3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -672,6 +672,16 @@
};
};
 
+   codec: codec@ff41 {
+   compatible = "rockchip,rk3328-codec";
+   reg = <0x0 0xff41 0x0 0x1000>;
+   rockchip,grf = <>;
+   clocks = < PCLK_ACODECPHY>, < SCLK_I2S1>;
+   clock-names = "pclk", "mclk";
+   #sound-dai-cells = <0>;
+   status = "disabled";
+   };
+
hdmiphy: phy@ff43 {
compatible = "rockchip,rk3328-hdmi-phy";
reg = <0x0 0xff43 0x0 0x1>;
-- 
2.19.2

[PATCH] arm64: dts: rockchip: enable analog audio node for rock64

[Katsuhiro Suzuki]

The Rock64 boards has analog audio jack on it. RK3328 can output
analog audio signal using I2S1 and ACODEC core.

This patch adds sound node for analog audio for Rock64.

Signed-off-by: Katsuhiro Suzuki 
---

This patch depends on the following ACODEC node patch. If ACODEC
patch is not good to you, please drop this patch too.
  https://lkml.org/lkml/2018/12/23/53

 .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index bd937d68ca3b..0a71e1287a1b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -66,7 +66,8 @@
sound {
compatible = "audio-graph-card";
label = "rockchip,rk3328";
-   dais = <_p0>;
+   dais = <_p0
+   _p0>;
};
 
spdif-dit {
@@ -81,6 +82,17 @@
};
 };
 
+ {
+   status = "okay";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   codec_p0_0: endpoint {
+   remote-endpoint = <_p0_0>;
+   };
+   };
+};
+
  {
cpu-supply = <_arm>;
 };
@@ -243,6 +255,19 @@
};
 };
 
+ {
+   status = "okay";
+   #sound-dai-cells = <0>;
+
+   i2s1_p0: port {
+   i2s1_p0_0: endpoint {
+   dai-format = "i2s";
+   mclk-fs = <256>;
+   remote-endpoint = <_p0_0>;
+   };
+   };
+};
+
 _domains {
status = "okay";
 
-- 
2.19.2

Re: general protection fault in put_pid

[Dmitry Vyukov]

On Sun, Dec 23, 2018 at 10:57 AM Dmitry Vyukov  wrote:
>
> On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov  wrote:
> >
> > On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul  
> > wrote:
> > >
> > > Hi Dmitry,
> > >
> > > On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
> > > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
> > > >  wrote:
> > > >> Hello Dmitry,
> > > >>
> > > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
> > > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot
> > > >>>  wrote:
> > >  Hello,
> > > 
> > >  syzbot found the following crash on:
> > > 
> > >  HEAD commit:f5d582777bcb Merge branch 'for-linus' of 
> > >  git://git.kernel...
> > >  git tree:   upstream
> > >  console output: 
> > >  https://syzkaller.appspot.com/x/log.txt?x=135bc54740
> > >  kernel config:  
> > >  https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> > >  dashboard link: 
> > >  https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> > >  compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > >  syz repro:  
> > >  https://syzkaller.appspot.com/x/repro.syz?x=16803afb40
> > > >>> +Manfred, this looks similar to the other few crashes related to
> > > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at.
> > > >> I found one unexpected (incorrect?) locking, see the attached patch.
> > > >>
> > > >> But I doubt that this is the root cause of the crashes.
> > > >
> > > > But why? These one-off sporadic crashes reported by syzbot looks
> > > > exactly like a subtle race and your patch touches sem_exit_ns involved
> > > > in all reports.
> > > > So if you don't spot anything else, I would say close these 3 reports
> > > > with this patch (I see you already included Reported-by tags which is
> > > > great!) and then wait for syzbot reaction. Since we got 3 of them, if
> > > > it's still not fixed I would expect that syzbot will be able to
> > > > retrigger this later again.
> > >
> > > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and
> > > nothing can happen.
> > >
> > > Every single-operation semop() reduces use_global_lock by one, i.e a
> > > single semop call as done here cannot trigger the bug:
> > >
> > > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40
> >
> > It contains "repeat":true,"procs":6, which means that it run 6
> > processes running this test in infinite loop. The last mark about
> > number of tests executed was:
> > 2018/12/11 18:38:02 executed programs: 2955
> >
> > > But, one more finding:
> > >
> > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> > >
> > > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40
> > >
> > > The log file contain 1080 lines like these:
> > >
> > > > semget$private(..., 0x4003, ...)
> > > >
> > > > semget$private(..., 0x4006, ...)
> > > >
> > > > semget$private(..., 0x4007, ...)
> > >
> > > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an
> > > allocation in the 4 MB kmalloc buffer:
> > >
> > > > [ 1201.210245] kmalloc-4194304  4698112KB4698112KB
> > > >
> > > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the
> > > semaphore arrays??
> >
> > /\/\/\/\/\/\
> >
> > Ha, this is definitely not healthy.
>
> I can reproduce this infinite memory consumption with the C program:
> https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt
>
> But this is working as intended, right? It just creates infinite
> number of large semaphore sets, which reasonably consumes infinite
> amount of memory.
> Except that it also violates the memcg bound and a process can have
> effectively unlimited amount of such "drum memory" in semaphores.
>
>
>
>
> > > This one looks similar:
> > >
> > > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
> > >
> > > except that the array sizes are mixed, and thus there are kmalloc-1M and
> > > kmalloc-2M as well.
> > >
> > > (and I did not count the number of semget calls)
> > >
> > >
> > > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct?
> > >
> > > I.e. no CLONE_NEWUSER.
> > >
> > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523
> >
> > CLONE_NEWUSER is used on some instances as well:
> > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765
> > This crash happened on 2 different instances and 1 of them uses
> > CLONE_NEWUSER and another does not.
> > If it's important because of CAP_ADMIN in IPC namespace, then all
> > instances should have it (instances that don't use NEWUSER are just
> > root).

My naive attempts to re-reproduce this failed so far.
But I noticed that _all_ logs for these 3 crashes:
https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
https://syzkaller.appspot.com/bug?extid=9d8b6fa6ee7636f350c1
involve low 

Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver

[Pavel Machek]

Hi!

> So the little elves have been slowly working to get voice calls
> working on droid 4 with the mainline kernel. And just in time for the
> upcoming holidays, it might be possible to call friends and relatives.
> 
> I've pushed out an experimental branch containing serdev ts 27.010
> UART multiplexing support. That contains a serdev core driver for the
> mdm6600 modem (that also now idles the modem for PM), support for Alsa
> ASoC voice codec and mixer, and a GNSS driver for the GPS.
> 
> Where it does not make sense to do a kernel serdev driver, I've
> exposed the rest of the available 27.010 channels as ten /dev/motmdm*
> character devices. There's /dev/motmdm1 for AT commands to dial voice
> calls, /dev/motmdm3 for SMS eventually, and I think there's also a SIM
> card reader at /dev/motmdm10. Then /dev/motmdm7 seems to be just an
> echo channel. The other channels are still a bit of a mystery.

I suspected it does not work in non-modular case, so I tried with
modules:

root@devuan:/my/ko# insmod gnss.ko
root@devuan:/my/ko# insmod gnss-motmdm.ko
insmod: ERROR: could not insert module gnss-motmdm.ko: Unknown symbol
in module
root@devuan:/my/ko# insmod n_gsm.ko
root@devuan:/my/ko# insmod snd-soc-motmdm.ko
insmod: ERROR: could not insert module snd-soc-motmdm.ko: Unknown
symbol in module
root@devuan:/my/ko# insmod motorola-mdm.ko
root@devuan:/my/ko# insmod snd-soc-motmdm.ko
root@devuan:/my/ko# insmod gnss-motmdm.ko
root@devuan:/my/ko#

But...

root@devuan:/my/ko# ls -al /dev/motmdm*
ls: cannot access '/dev/motmdm*': No such file or directory
root@devuan:/my/ko# ls -al /dev/gnss*
ls: cannot access '/dev/gnss*': No such file or directory
root@devuan:/my/ko#
[  116.25] gnss: GNSS driver registered with major 242
[  119.892547] gnss_motmdm: Unknown symbol motmdm_register_dlci (err
-2)
[  119.899444] gnss_motmdm: Unknown symbol motmdm_unregister_dlci (err
-2)
[  129.145935] snd_soc_motmdm: Unknown symbol motmdm_register_dlci
(err -2)
[  129.153106] snd_soc_motmdm: Unknown symbol motmdm_unregister_dlci
(err -2)
[  131.120361] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  161.190216] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  191.270263] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  221.360107] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  251.429962] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  281.509643] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[  292.816436] g_ether gadget: packet filter 0e
[  292.825256] g_ether gadget: ecm req21.43 v000e i l0

...do I need to make devices manually or some udev rules?

user@devuan:~$ cat /proc/devices | grep motmdm
user@devuan:~$ cat /proc/devices | grep gnss
242 gnss
user@devuan:~$

Hmm, I suspect the driver just did not recognize the hw.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: general protection fault in put_pid

[Dmitry Vyukov]

On Sun, Dec 23, 2018 at 11:30 AM Dmitry Vyukov  wrote:
>
> On Sun, Dec 23, 2018 at 10:57 AM Dmitry Vyukov  wrote:
> >
> > On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov  wrote:
> > >
> > > On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul  
> > > wrote:
> > > >
> > > > Hi Dmitry,
> > > >
> > > > On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
> > > > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
> > > > >  wrote:
> > > > >> Hello Dmitry,
> > > > >>
> > > > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
> > > > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot
> > > > >>>  wrote:
> > > >  Hello,
> > > > 
> > > >  syzbot found the following crash on:
> > > > 
> > > >  HEAD commit:f5d582777bcb Merge branch 'for-linus' of 
> > > >  git://git.kernel...
> > > >  git tree:   upstream
> > > >  console output: 
> > > >  https://syzkaller.appspot.com/x/log.txt?x=135bc54740
> > > >  kernel config:  
> > > >  https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> > > >  dashboard link: 
> > > >  https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> > > >  compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > >  syz repro:  
> > > >  https://syzkaller.appspot.com/x/repro.syz?x=16803afb40
> > > > >>> +Manfred, this looks similar to the other few crashes related to
> > > > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at.
> > > > >> I found one unexpected (incorrect?) locking, see the attached patch.
> > > > >>
> > > > >> But I doubt that this is the root cause of the crashes.
> > > > >
> > > > > But why? These one-off sporadic crashes reported by syzbot looks
> > > > > exactly like a subtle race and your patch touches sem_exit_ns involved
> > > > > in all reports.
> > > > > So if you don't spot anything else, I would say close these 3 reports
> > > > > with this patch (I see you already included Reported-by tags which is
> > > > > great!) and then wait for syzbot reaction. Since we got 3 of them, if
> > > > > it's still not fixed I would expect that syzbot will be able to
> > > > > retrigger this later again.
> > > >
> > > > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and
> > > > nothing can happen.
> > > >
> > > > Every single-operation semop() reduces use_global_lock by one, i.e a
> > > > single semop call as done here cannot trigger the bug:
> > > >
> > > > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40
> > >
> > > It contains "repeat":true,"procs":6, which means that it run 6
> > > processes running this test in infinite loop. The last mark about
> > > number of tests executed was:
> > > 2018/12/11 18:38:02 executed programs: 2955
> > >
> > > > But, one more finding:
> > > >
> > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
> > > >
> > > > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40
> > > >
> > > > The log file contain 1080 lines like these:
> > > >
> > > > > semget$private(..., 0x4003, ...)
> > > > >
> > > > > semget$private(..., 0x4006, ...)
> > > > >
> > > > > semget$private(..., 0x4007, ...)
> > > >
> > > > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an
> > > > allocation in the 4 MB kmalloc buffer:
> > > >
> > > > > [ 1201.210245] kmalloc-4194304  4698112KB4698112KB
> > > > >
> > > > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the
> > > > semaphore arrays??
> > >
> > > /\/\/\/\/\/\
> > >
> > > Ha, this is definitely not healthy.
> >
> > I can reproduce this infinite memory consumption with the C program:
> > https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt
> >
> > But this is working as intended, right? It just creates infinite
> > number of large semaphore sets, which reasonably consumes infinite
> > amount of memory.
> > Except that it also violates the memcg bound and a process can have
> > effectively unlimited amount of such "drum memory" in semaphores.
> >
> >
> >
> >
> > > > This one looks similar:
> > > >
> > > > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
> > > >
> > > > except that the array sizes are mixed, and thus there are kmalloc-1M and
> > > > kmalloc-2M as well.
> > > >
> > > > (and I did not count the number of semget calls)
> > > >
> > > >
> > > > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), 
> > > > correct?
> > > >
> > > > I.e. no CLONE_NEWUSER.
> > > >
> > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523
> > >
> > > CLONE_NEWUSER is used on some instances as well:
> > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765
> > > This crash happened on 2 different instances and 1 of them uses
> > > CLONE_NEWUSER and another does not.
> > > If it's important because of CAP_ADMIN in IPC namespace, then all
> > > instances should have it (instances that don't use NEWUSER are just
> > > 

Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn

[Thomas Backlund]

Den 23-12-2018 kl. 01:28, skrev Linus Torvalds:

On Sat, Dec 22, 2018 at 3:07 PM Christian Brauner
 wrote:


However, for this case should I resend the revert?


Since I was pointed at the original email thread, I just picked it up
from there directly. It still applied cleanly, nothing had changed in
that area.

 Linus



This should also be picked up for 4.19 lts

Greg, it's now upstream as:

From 94f82008ce30e2624537d240d64ce718255e0b80 Mon Sep 17 00:00:00 2001
From: Christian Brauner 
Date: Thu, 5 Jul 2018 17:51:20 +0200
Subject: Revert "vfs: Allow userns root to call mknod on owned filesystems."

--
Thomas

Re: [PATCH V2 00/10] unify the interface of the proportional-share policy in blkio/io

[Paolo Valente]

> Il giorno 18 dic 2018, alle ore 18:22, Paolo Valente 
>  ha scritto:
> 
> 
> 
>> Il giorno 18 dic 2018, alle ore 17:41, Tejun Heo  ha 
>> scritto:
>> 
>> Hello, Paolo.
>> 
>> On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote:
>>> If Tejun cannot see any solution to his concern, then can we just
>>> switch to this extension, considering that
>>> - for non-shared names the interface is *identical* to the current
>>> one;
>>> - by using this new interface, and getting feedback we could
>>> understand how to better handle Tejun's concern?
>>> A lot of systems do use weights, and people don't even know that these
>>> systems don't work correctly in blk-mq.  And they won't work correctly
>>> in any available configuration from 4.21, if we don't fix this problem.
>> 
>> So, when seen from userland, how it should behave isn't vague or
>> complicated.  For a given device and policy type, there can be only
>> one implementation active.
> 
> Yes, but the problem is the opposite. You may have
> - two different policies, with the same interface parameter, 
> - one active on one device
> - the other one active on another device
> 
> In that case, statistics from one policy necessarily differ from
> statistics from the other policy.
> 
> In this respect, in a system with more than one drive it already
> happens that the same policy is active on different devices.  When
> printing a statistics interface file for the policy, the output will
> be a list of separate statistics, with a bunch of statistics *for
> each* drive (plus a grand total in some cases).
> 
> So, our proposal simply extends this scheme in the most natural way:
> if, now, also two or more policies share the same statistics file,
> then the output will be a list of separate statistics, one for each
> policy.  The statistics for each policy will be tagged with the policy
> name, and will have the same identical form as above.  It seems the
> most natural hierarchical extension of the same scheme.
> 

Maybe my generic description didn't highlight how plain are.

If you print, e.g., io_serviced with the current interface, you get

--

8:0 Read 4291168
8:0 Write 2181577
8:0 Sync 5897755
8:0 Async 574990
8:0 Total 6472745
Total 6472745

--

With the new, interface, you get *the same output*, if only one policy
is attached to this interface file.  In, instead
- two policies share
the the file, because one is active on a device and one on another
device
- these policies are named, e.g., bfq and pol2
then you get (device number and statistics invented):

--

bfq:
8:0 Read 4291168
8:0 Write 2181577
8:0 Sync 5897755
8:0 Async 574990
8:0 Total 6472745
Total 6472745

pol2:
16:0 Read 238768
16:0 Write 323123
16:0 Sync 43243
16:0 Async 432432
16:0 Total 412435
Total 4341244

--

So you see the per-device statistics as before, without the problem
of inventing a new set of names for every new policy that has the same
interface files of an existing policy.

Tejun, let's try to converge, to whatever solution you prefer.


4.21 is coming ...  and the legacy proportional share interface will
be gone with cfq.  This will break legacy code using the
proportional-share interface on top of bfq.  This code may just fail
when trying to use interface files that don't exist any longer.

Thanks,
Paolo

> At any rate, if you don't like it, just tell us how you prefer it
> done.  Do you prefer the sharing of statistics file to be simply
> forbidden?  (If this can be done.) I think such an incomplete solution
> would preserve part of the current mess; but, if this allows us to
> exit from this impasse, then it is ok for me.
> 
> *Any* feasible option is ok for me. Just pick one.
> 
>> It doesn't make sense to have two weight
>> mechanisms active on one device, right?
> 
> (Un)fortunately, the problem are not weights.  There won't be two
> weights for two policies expiring a weight parameter.  The problems
> concerns statistics.  See above.
> 
> 
>> So, the interface should only
>> present what makes sense to the user for both configuration knobs and
>> statistics, and that'd be a hard requirement because we don't want to
>> present confusing spurious information to userspace.
>> 
>> There seemd to have been significant misunderstandings as to what the
>> requirements are when this was discussed way back, so idk what the
>> good path forward is at this point.  Just keep the current names?
>> 
> 
> I don't clearly understand how "just picking the current names" is a
> way forward, but if we do not make this extension, in a way or the
> other, then two policies will simply not be allowed to share the same
> interface files.  And we will be still at the starting point.
> 
> Thanks,
> Paolo
> 
>> Thanks.
>> 
>> -- 
>> tejun
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "bfq-iosched" group.
> To unsubscribe from this group and stop 

Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver

[Pavel Machek]

Hi!

> > So the little elves have been slowly working to get voice calls
> > working on droid 4 with the mainline kernel. And just in time for the
> > upcoming holidays, it might be possible to call friends and relatives.
> > 
> > I've pushed out an experimental branch containing serdev ts 27.010
> > UART multiplexing support. That contains a serdev core driver for the
> > mdm6600 modem (that also now idles the modem for PM), support for Alsa
> > ASoC voice codec and mixer, and a GNSS driver for the GPS.
> > 
> > Where it does not make sense to do a kernel serdev driver, I've
> > exposed the rest of the available 27.010 channels as ten /dev/motmdm*
> > character devices. There's /dev/motmdm1 for AT commands to dial voice
> > calls, /dev/motmdm3 for SMS eventually, and I think there's also a SIM
> > card reader at /dev/motmdm10. Then /dev/motmdm7 seems to be just an
> > echo channel. The other channels are still a bit of a mystery.
> 
> I suspected it does not work in non-modular case, so I tried with
> modules:
> 
> root@devuan:/my/ko# insmod gnss.ko
> root@devuan:/my/ko# insmod gnss-motmdm.ko
> insmod: ERROR: could not insert module gnss-motmdm.ko: Unknown symbol
> in module
> root@devuan:/my/ko# insmod n_gsm.ko
> root@devuan:/my/ko# insmod snd-soc-motmdm.ko
> insmod: ERROR: could not insert module snd-soc-motmdm.ko: Unknown
> symbol in module
> root@devuan:/my/ko# insmod motorola-mdm.ko
> root@devuan:/my/ko# insmod snd-soc-motmdm.ko
> root@devuan:/my/ko# insmod gnss-motmdm.ko
> root@devuan:/my/ko#
...
> ...do I need to make devices manually or some udev rules?
> 
> user@devuan:~$ cat /proc/devices | grep motmdm
> user@devuan:~$ cat /proc/devices | grep gnss
> 242 gnss
> user@devuan:~$
> 
> Hmm, I suspect the driver just did not recognize the hw.

I added some printks to motmdm_probe, and they don't appear to be
called. I wonder if I'm missing something else in the config? I do
have serial

root@devuan:/my/ko# ls -al /dev/ttyS0
crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0

but not gsm multiplex:

root@devuan:/my/ko# ls -al /dev/gsm*
ls: cannot access '/dev/gsm*': No such file or directory

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


signature.asc
Description: Digital signature

Re: [PATCH] binderfs: implement "max" mount option

[Greg KH]

On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> Since binderfs can be mounted by userns root in non-initial user namespaces
> some precautions are in order. First, a way to set a maximum on the number
> of binder devices that can be allocated per binderfs instance and second, a
> way to reserve a reasonable chunk of binderfs devices for the initial ipc
> namespace.
> A first approach as seen in [1] used sysctls similiar to devpts but was
> shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> is an alternative approach which avoids sysctls completely and instead
> switches to a single mount option.
> 
> Starting with this commit binderfs instances can be mounted with a limit on
> the number of binder devices that can be allocated. The max= mount
> option serves as a per-instance limit. If max= is set then only
>  number of binder devices can be allocated in this binderfs
> instance.

Ok, this is fine, but why such a big default?  You only need 4 to run a
modern android system, and anyone using binder outside of android is
really too crazy to ever be using it in a container :)

> Additionally, the binderfs instance in the initial ipc namespace will
> always have a reserve of at least 1024 binder devices unless explicitly
> capped via max=.

Again, why so many?  And why wouldn't that initial ipc namespace already
have their device nodes created _before_ anything else is mounted?

Some comments on the patch below:

> +/*
> + * Ensure that the initial ipc namespace always has a good chunk of devices
> + * available.
> + */
> +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)

Again that seems crazy big, how about splitting this into two different
patches, one for the max= stuff, and one for this "reserve some minors"
thing, so we can review them separately.

>  
>  static struct vfsmount *binderfs_mnt;
>  
> @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
>  static DEFINE_MUTEX(binderfs_minors_mutex);
>  static DEFINE_IDA(binderfs_minors);
>  
> +/**
> + * binderfs_mount_opts - mount options for binderfs
> + * @max: maximum number of allocatable binderfs binder devices
> + */
> +struct binderfs_mount_opts {
> + int max;
> +};
> +
> +enum {
> + Opt_max,
> + Opt_err
> +};
> +
> +static const match_table_t tokens = {
> + { Opt_max, "max=%d" },
> + { Opt_err, NULL }
> +};
> +
>  /**
>   * binderfs_info - information about a binderfs mount
>   * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
>   *  created.
>   * @root_gid:   gid that needs to be used when a new binder device is
>   *  created.
> + * @mount_opts: The mount options in use.
> + * @device_count:   The current number of allocated binder devices.
>   */
>  struct binderfs_info {
>   struct ipc_namespace *ipc_ns;
>   struct dentry *control_dentry;
>   kuid_t root_uid;
>   kgid_t root_gid;
> -
> + struct binderfs_mount_opts mount_opts;
> + atomic_t device_count;

Why atomic?

You should already have the lock held every time this is accessed,
so no need to use an atomic value, just use an int.

>   /* Reserve new minor number for the new device. */
>   mutex_lock(_minors_mutex);
> - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> + if (atomic_inc_return(>device_count) < info->mount_opts.max)

No need for atomic, see, your lock is held :)

thanks,

greg k-h

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

Hi Mimi,

On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> 
> > When I remove the timeout and boot directly to the linux kernel, I get that
> > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > detected
> > by IMA and works fine then.
> > 
> > Some more tests showed that any delay before booting the kernel causes the
> > TPM
> > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some
> > very
> > rare cases the TPM got detected.
> > 
> > I wanted to know if the TPM is in an well initialized state at the time of
> > that
> > error. Since I was not able to get some test/debug kernel patches working I
> > decided to try kexec. It turned out that the TPM is indeed correctly working
> > and
> > will be detected just fine by linux after kexec!
> 
> No surprise here.  kexec would be the equivalent of a soft reboot.

Well, I am not that deep in kexec internals but isn't a soft reboot much more
than a kexec? I thought kexec would "just" load the new kernel to memory and
executes it while a soft reboot goes at least through some UEFI initialization.
For example, my pwm fans - in fact the EC - get resetted on a soft reboot, while
a kexec does not touch them.

That is why I wanted to test if there is a different behaviour on kexec compared
to a "real" soft reboot. If there was such difference I would have assumed a
UEFI bug that does not initialize the TPM correctly.
Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in the
same state as before kexec and since there is no difference between sr and kexec
I have the feeling there is something wrong in the kernel.

Correct me if I am wrong here, please.

My current workaround is to do a machine_emergency_reboot() when TPM isn't
detected correctly. That is a pretty hard workaround but it seems to work for
now...

> 
> > 
> > Is there anyone having an idea what could be wrong here? I am willing to
> > debug
> > this but I have really no idea where to start :-(
> 
> A while ago, I was "playing" with a pi.  Commenting out
> tpm2_do_selftest() seemed to resolve a similar problem, but that was
> before James' patches.  I don't know if that would make a difference
> now.

Hm, I will try that..


> Mimi
> 

There is another issue but I don't know if both are related. Maybe that's just a
timing issue...

root@debian:~# dd if=/dev/hwrng bs=1 count=1
dd: error reading '/dev/hwrng': Operation not permitted
0+0 records in
0+0 records out
0 bytes copied, 0.755958 s, 0.0 kB/s
root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
count=1 | xxd
dd: error reading '/dev/hwrng': Operation not permitted
0+0 records in
0+0 records out
0 bytes copied, 0.755697 s, 0.0 kB/s
1+0 records in
1+0 records out
: 52   R
1 byte copied, 0.0106268 s, 0.1 kB/s


Michael

linux-next: Signed-off-by missing for commit in the crypto tree

[Stephen Rothwell]

Hi Herbert,

Commit

  6501ab5ed4d9 ("crypto: chelsio - Reset counters on cxgb4 Detach")

is missing a Signed-off-by from its author.

-- 
Cheers,
Stephen Rothwell


pgpC8B63BMDpr.pgp
Description: OpenPGP digital signature

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

[Boaz Harrosh]

On 19/12/18 16:43, Christoph Hellwig wrote:
> On Mon, Nov 26, 2018 at 07:11:10PM +0200, Boaz Harrosh wrote:
>> On 11/11/18 15:32, Christoph Hellwig wrote:
>>> The only real user of the T10 OSD protocol, the pNFS object layout
>>> driver never went to the point of having shipping products, and we
>>> removed it 1.5 years ago.  Exofs is just a simple example without
>>> real life users.
>>>
>>
>> You have failed to say what is your motivation for this patchset? What
>> is it you are trying to fix/improve.
> 
> Drop basically unused support, which allows us to
> 
>  1) reduce the size of every kernel with block layer support, and
> even more for every kernel with scsi support

Do you have numbers? its mainly code-segment so I don't think you will see
any real life measurable difference.

>  2) reduce the size of the critical struct request structure by
> 128 bits, thus reducing the memory used by every blk-mq driver
> significantly, never mind the cache effects

128 bits? I see the "struct request *next_rq;"
is there another one?

It could share space with elv; && flush;
Do you want a patch?

>  3) stop having the maintainance overhead for this code in the
> block layer, which has been rather painful at times
> 

I hear you man. Life is pain. But is it really such an overhead?
I mean it is already implemented. What else is there to do?
Please please show me? (Sorry for being slow)

Jai Maa
Boaz

Re: general protection fault in put_pid

[Manfred Spraul]

Hello Dmitry,

On 12/23/18 10:57 AM, Dmitry Vyukov wrote:


I can reproduce this infinite memory consumption with the C program:
https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt

But this is working as intended, right? It just creates infinite
number of large semaphore sets, which reasonably consumes infinite
amount of memory.
Except that it also violates the memcg bound and a process can have
effectively unlimited amount of such "drum memory" in semaphores.


Yes, this is as intended:

If you call semget(), then you can use memory, up to the limits in 
/proc/sys/kernel/sem.


Memcg is not taken into account, an admin must set /proc/sys/kernel/sem.

The default are "infinite amount of memory allowed", as this is the most 
sane default: We had a logic that tried to autotune (i.e.: a new 
namespace "inherits" a fraction of the parent namespaces memory limits), 
but this we more or less always wrong.



--

    Manfred

Re: linux-next: Signed-off-by missing for commit in the crypto tree

[Herbert Xu]

On Sun, Dec 23, 2018 at 11:13:04PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> Commit
> 
>   6501ab5ed4d9 ("crypto: chelsio - Reset counters on cxgb4 Detach")
> 
> is missing a Signed-off-by from its author.

Hi Stephen:

I believe the issue here is not a missing sign-off from the author,
but rather that the author was incorrectly set to Harsh who sent
the email rather than Atul.

Harsh, please add a From header to the patch description in future
so that the Author field is set correctly.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: general protection fault in put_pid

[Manfred Spraul]

Hi Dmitry,

let's simplify the mail, otherwise noone can follow:

On 12/23/18 11:42 AM, Dmitry Vyukov wrote:



My naive attempts to re-reproduce this failed so far.
But I noticed that _all_ logs for these 3 crashes:
https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
https://syzkaller.appspot.com/bug?extid=9d8b6fa6ee7636f350c1
involve low memory conditions. My gut feeling says this is not a
coincidence. This is also probably the reason why all reproducers
create large sem sets. There must be some bad interaction between low
memory condition and semaphores/ipc namespaces.


Actually was able to reproduce this with a syzkaller program:

./syz-execprog -repeat=0 -procs=10 prog
...
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8788 Comm: syz-executor8 Not tainted 4.20.0-rc7+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
Code: ad de 4c 8b 26 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48
89 da 48 39 c3 74 65 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8 00
RSP: 0018:88804faef210 EFLAGS: 00010a02
RAX: dc00 RBX: f817edba555e1f00 RCX: 831bad5f
RDX: 1f02fdb74aabc3e0 RSI: 88801b8a0720 RDI: 88801b8a0728
RBP: 88804faef228 R08: f52001055401 R09: f52001055401
R10: 0001 R11: f52001055400 R12: 88802d52cc98
R13: 88801b8a0728 R14: 88801b8a0720 R15: dc00
FS:  00d24940() GS:88802d50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004bb580 CR3: 11177005 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  __list_del_entry include/linux/list.h:117 [inline]
  list_del include/linux/list.h:125 [inline]
  unlink_queue ipc/sem.c:786 [inline]
  freeary+0xddb/0x1c90 ipc/sem.c:1164
  free_ipcs+0xf0/0x160 ipc/namespace.c:112
  sem_exit_ns+0x20/0x40 ipc/sem.c:237
  free_ipc_ns ipc/namespace.c:120 [inline]
  put_ipc_ns+0x55/0x160 ipc/namespace.c:152
  free_nsproxy+0xc0/0x1f0 kernel/nsproxy.c:180
  switch_task_namespaces+0xa5/0xc0 kernel/nsproxy.c:229
  exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:234
  do_exit+0x19e5/0x27d0 kernel/exit.c:866
  do_group_exit+0x151/0x410 kernel/exit.c:970
  __do_sys_exit_group kernel/exit.c:981 [inline]
  __se_sys_exit_group kernel/exit.c:979 [inline]
  __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979
  do_syscall_64+0x192/0x770 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4570e9
Code: 5d af fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 2b af fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffe35f12018 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX: 0001 RCX: 004570e9
RDX: 00410540 RSI: 00a34c00 RDI: 0045
RBP: 004a43a4 R08: 000c R09: 
R10: 00d24940 R11: 0246 R12: 
R13: 0001 R14:  R15: 0008
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 17829b0f00569a59 ]---
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
Code: ad de 4c 8b 26 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48
89 da 48 39 c3 74 65 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8 00
RSP: 0018:88804faef210 EFLAGS: 00010a02
RAX: dc00 RBX: f817edba555e1f00 RCX: 831bad5f
RDX: 1f02fdb74aabc3e0 RSI: 88801b8a0720 RDI: 88801b8a0728
RBP: 88804faef228 R08: f52001055401 R09: f52001055401
R10: 0001 R11: f52001055400 R12: 88802d52cc98
R13: 88801b8a0728 R14: 88801b8a0720 R15: dc00
FS:  00d24940() GS:88802d50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004bb580 CR3: 11177005 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


The prog is:
unshare(0x802)
semget$private(0x0, 0x4007, 0x0)

kernel is on 9105b8aa50c182371533fc97db64fc8f26f051b3

and again it involved lots of oom kills, the repro eats all memory, a
process getting killed, frees some memory and the process repeats.


Ok, thus the above program triggers two bugs:

- a huge memory leak with semaphore arrays

- under OOM pressure, an oops.


1) I can reproduce the memory leak, it happens all the 

Re: [PATCH 4/4] test_bitmap: add testcases for bitmap_parselist

[kbuild test robot]

Hi Yuri,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc7 next-20181221]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yuri-Norov/rework-bitmap_parselist/20181223-175529
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> lib//bitmap.c:519:24: warning: incorrect type in argument 1 (different 
>> address spaces)
   lib//bitmap.c:519:24:expected void const volatile [noderef]  *
   lib//bitmap.c:519:24:got char const *str
   lib//bitmap.c:735:53: warning: incorrect type in argument 2 (different 
address spaces)
   lib//bitmap.c:735:53:expected char const *const end
   lib//bitmap.c:735:53:got char const [noderef]  *
   include/linux/slab.h:332:43: warning: dubious: x & !y

vim +519 lib//bitmap.c

87ac23b8 Yuri Norov 2018-12-23  515  
32eb0e6b Yuri Norov 2018-12-23  516  static long get_char(char *c, const char 
*str, int is_user)
32eb0e6b Yuri Norov 2018-12-23  517  {
32eb0e6b Yuri Norov 2018-12-23  518 if (unlikely(is_user))
32eb0e6b Yuri Norov 2018-12-23 @519 return __get_user(*c, str);
32eb0e6b Yuri Norov 2018-12-23  520  
32eb0e6b Yuri Norov 2018-12-23  521 *c = *str;
32eb0e6b Yuri Norov 2018-12-23  522 return 0;
32eb0e6b Yuri Norov 2018-12-23  523  }
32eb0e6b Yuri Norov 2018-12-23  524  

:: The code at line 519 was first introduced by commit
:: 32eb0e6b5e705132d4efef268c65730a2f2b9c41 bitmap_parselist: rework input 
string parser

:: TO: Yuri Norov 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

[GIT PULL] x86/cache updates for 4.21

[Borislav Petkov]

Hi Linus,

please pull the latest x86-cache-for-linus tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus

This update contains:

 - The generalization of the RDT code to accommodate the addition of AMD's
   very similar implementation of the cache monitoring feature.

   This entails a subsystem move into a separate and generic
   arch/x86/kernel/cpu/resctrl/ directory along with adding
   vendor-specific initialization and feature detection helpers.

   Ontop of that is the unification of user-visible strings, both in the
   resctrl filesystem error handling and Kconfig.

   Provided by Babu Moger and Sherry Hurwitz.

 - Code simplifications and error handling improvements by Reinette
   Chatre.

And just because we're not having enough fun, this pull request
conflicts with the fs context changes in the vfs tree. Find the merge
conflict resolution (git show -M) at the end of this mail. For reference,
the merge resolution is also available at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git vfs-x86-cache

Thanks,
Boris.

-->

The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:

  Linux 4.20-rc3 (2018-11-18 13:33:44 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus

for you to fetch changes up to 52eb74339a6233c69f4e3794b69ea7c98eeeae1b:

  x86/resctrl: Fix rdt_find_domain() return value and checks (2018-12-11 
22:09:28 +0100)


Babu Moger (13):
  x86/resctrl: Rename and move rdt files to a separate directory
  x86/resctrl: Rename the RDT functions and definitions
  x86/resctrl: Re-arrange the RDT init code
  x86/resctrl: Move all the macros to resctrl/internal.h
  x86/resctrl: Initialize the vendor-specific resource functions
  x86/resctrl: Bring cbm_validate() into the resource structure
  x86/resctrl: Add vendor check for the MBA software controller
  x86/resctrl: Rename the config option INTEL_RDT to RESCTRL
  x86/resctrl: Fixup the user-visible strings
  x86/resctrl: Introduce AMD QOS feature
  Documentation: Rename and update intel_rdt_ui.txt to resctrl_ui.txt
  MAINTAINERS: Update resctrl filename patterns
  x86/resctrl: Remove unnecessary check for cbm_validate()

Reinette Chatre (2):
  x86/resctrl: Use rdt_last_cmd_puts() where possible
  x86/resctrl: Fix rdt_find_domain() return value and checks

Sherry Hurwitz (1):
  x86/resctrl: Add AMD's X86_FEATURE_MBA to the scattered CPUID features

 Documentation/x86/{intel_rdt_ui.txt => resctrl_ui.txt} 
|   9 ++-
 MAINTAINERS
|   6 +-
 arch/x86/Kconfig   
|  22 ---
 arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h}
|  28 -
 arch/x86/kernel/cpu/Makefile   
|   5 +-
 arch/x86/kernel/cpu/resctrl/Makefile   
|   4 ++
 arch/x86/kernel/cpu/{intel_rdt.c => resctrl/core.c}
| 186 +++-
 arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c => resctrl/ctrlmondata.c} 
| 107 --
 arch/x86/kernel/cpu/{intel_rdt.h => resctrl/internal.h}
|  55 +++---
 arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl/monitor.c} 
|  16 +++---
 arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c => resctrl/pseudo_lock.c} 
|  40 ++---
 arch/x86/kernel/cpu/{intel_rdt_pseudo_lock_event.h => 
resctrl/pseudo_lock_event.h} |   2 +-
 arch/x86/kernel/cpu/{intel_rdt_rdtgroup.c => resctrl/rdtgroup.c}   
|  61 ++--
 arch/x86/kernel/cpu/scattered.c
|   7 ++-
 arch/x86/kernel/process_32.c   
|   4 +-
 arch/x86/kernel/process_64.c   
|   4 +-
 include/linux/sched.h  
|   2 +-
 17 files changed, 385 insertions(+), 173 deletions(-)
 rename Documentation/x86/{intel_rdt_ui.txt => resctrl_ui.txt} (99%)
 rename arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} (77%)
 create mode 100644 arch/x86/kernel/cpu/resctrl/Makefile
 rename arch/x86/kernel/cpu/{intel_rdt.c => resctrl/core.c} (83%)
 rename arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c => resctrl/ctrlmondata.c} 
(81%)
 rename arch/x86/kernel/cpu/{intel_rdt.h => resctrl/internal.h} (91%)
 rename arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl/monitor.c} (98%)
 rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c 

[GIT PULL] x86/microcode updates for 4.21

[Borislav Petkov]

Hi Linus,

please pull the latest x86-microcode-for-linus tree from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-microcode-for-linus


This update contains work started by Maciej to make the microcode
container verification more robust against all kinds of corruption and
also unify verification paths between early and late loading.

The result is a set of verification routines which validate the
microcode blobs before loading it on the CPU. In addition, the code is a
lot more streamlined and unified.

In the process, some of the aspects of patch handling and loading were
simplified.

All provided by Maciej S. Szmigiero and Borislav Petkov.

Thanks,
Boris.

-->

The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:

  Linux 4.20-rc3 (2018-11-18 13:33:44 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-microcode-for-linus

for you to fetch changes up to 2ffcbce39ea1e355eed8c6527308624f366f1c58:

  x86/microcode/AMD: Update copyright (2018-11-19 10:55:12 +0100)


Borislav Petkov (11):
  x86/microcode/AMD: Move verify_patch_size() up in the file
  x86/microcode/AMD: Clean up per-family patch size checks
  x86/microcode/AMD: Cleanup verify_patch_size() more
  x86/microcode/AMD: Concentrate patch verification
  x86/microcode/AMD: Simplify patch family detection
  x86/microcode/AMD: Move patch family check to verify_patch()
  x86/microcode/AMD: Move chipset-specific check into verify_patch()
  x86/microcode/AMD: Change verify_patch()'s return value
  x86/microcode/AMD: Convert early parser to the new verification routines
  x86/microcode/AMD: Fix container size's type
  x86/microcode/AMD: Update copyright

Maciej S. Szmigiero (5):
  x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length
  x86/microcode/AMD: Add microcode container verification
  x86/microcode/AMD: Check microcode container data in the late loader
  x86/microcode/AMD: Convert CPU equivalence table variable into a struct
  x86/microcode/AMD: Check the equivalence table size when scanning it

 arch/x86/kernel/cpu/microcode/amd.c | 470 +++-
 1 file changed, 308 insertions(+), 162 deletions(-)

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)

Re: x86/sgx: uapi change proposal

[Jarkko Sakkinen]

On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > opening a new instance of /dev/sgx for each encalve?
> > > 
> > > I think that fits better to the SCM_RIGHTS scenario i.e. you could send
> > > the enclav to a process that does not have necessarily have rights to
> > > /dev/sgx. Gives more robust environment to configure SGX.
> > 
> > Sean, is this why you wanted enclave fd and anon inode and not just use
> > the address space of /dev/sgx? Just taking notes of all observations.
> > I'm not sure what your rationale was (maybe it was somewhere). This was
> > something I made up, and this one is wrong deduction. You can easily
> > get the same benefit with /dev/sgx associated fd representing the
> > enclave.
> > 
> > This all means that for v19 I'm going without enclave fd involved with
> > fd to /dev/sgx representing the enclave. No anon inodes will be
> > involved.
> 
> Based on these observations I updated the uapi.
> 
> As far as I'm concerned there has to be a solution to do EPC mapping
> with a sequence:
> 
> 1. Ping /dev/kvm to do something.
> 2. KVM asks SGX core to do something.
> 3. SGX core does something.
> 
> I don't care what the something is exactly is, but KVM is the only sane
> place for KVM uapi. I would be surprised if KVM maintainers didn't agree
> that they don't want to sprinkle KVM uapi to random places in other
> subsystems.

The one option to consider to do would be to have a device driver for
KVM if you really want this e.g. something like /dev/vsgx. With the
current knowledge I'm not yet sure why all could not be done just
through /dev/kvm.

/Jarkko

[GIT PULL] RAS updates for 4.21

[Borislav Petkov]

Hi Linus,

please pull the latest ras-core-for-linus tree from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus

This time around we have a subsystem reorganization to offer, with the new
directory being

  arch/x86/kernel/cpu/mce/

and all compilation units' names streamlined under it.

Thanks,
Boris.

-->

The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:

  Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus

for you to fetch changes up to 72a8f089c382c078f8c7c1c759cb726de80d4284:

  x86/mce: Restore MCE injector's module name (2018-12-19 00:04:36 +0100)


Borislav Petkov (3):
  x86/mce: Streamline MCE subsystem's naming
  x86/mce: Unify pr_* prefix
  x86/mce: Restore MCE injector's module name

 arch/x86/kernel/cpu/Makefile  |  2 +-
 arch/x86/kernel/cpu/{mcheck => mce}/Makefile  | 10 ++
 arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c}   |  2 +-
 arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} |  2 +-
 arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c}  |  4 +---
 arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c  |  4 +---
 arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c}   |  2 +-
 arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} |  2 +-
 arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c}   |  2 +-
 arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} |  3 +++
 arch/x86/kernel/cpu/{mcheck => mce}/p5.c  |  2 ++
 arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} |  2 +-
 arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c |  2 ++
 arch/x86/kernel/cpu/{mcheck => mce}/threshold.c   |  2 ++
 arch/x86/kernel/cpu/{mcheck => mce}/winchip.c |  2 ++
 15 files changed, 26 insertions(+), 17 deletions(-)
 rename arch/x86/kernel/cpu/{mcheck => mce}/Makefile (61%)
 rename arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} (98%)
 rename arch/x86/kernel/cpu/{mcheck => mce}/p5.c (98%)
 rename arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} (99%)
 rename arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c (99%)
 rename arch/x86/kernel/cpu/{mcheck => mce}/threshold.c (96%)
 rename arch/x86/kernel/cpu/{mcheck => mce}/winchip.c (97%)

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)

Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

[Boaz Harrosh]

On 20/12/18 09:26, Christoph Hellwig wrote:
> On Wed, Dec 19, 2018 at 09:01:53PM -0500, Douglas Gilbert wrote:
>>>   1) reduce the size of every kernel with block layer support, and
>>>  even more for every kernel with scsi support
>>
>> By proposing the removal of bidi support from the block layer, it isn't
>> just the SCSI subsystem that will be impacted. Those NVMe documents
>> that you referred me to earlier in the year, in the command tables
>> in 1.3c and earlier you have noticed the 2 bit direction field and
>> what 11b means? Even if there aren't any bidi NVMe commands *** yet,
>> the fact that NVMe's 64 byte command format has provision for 4
>> (not 2) independent data transfers (data + meta, for each direction).
>> Surely NVMe will sooner or later take advantage of those ... a
>> command like READ GATHERED comes to mind.
> 
> NVMe on the other hand does have support for separate read and write
> buffers as in the current SCSI bidi support, as it encodes the data
> transfers in that SQE.  So IFF NVMe does bidi commands it would have
> to use a single buffer for data in/out, 

There is no such thing as "buffer" there is at first a bio, and after
virtual-to-iommu mapping a scatter-gather-list. All these are currently
governed by a struct request.
request, bio, and sgl, have a single direction, All API's expect a single
direction.

All BIDI did was to say. Lets not change any API or structure but just
use two of them at the same time.

All the wiser is the very high level user, and the very low HW driver like
iscsi. All the middlewere was never touched.

In the view of a bidi target like say an osd. It all stream looks like a single
"Buffer" on the wire, were some of it is read and some of it is written
to.

> which can be easily done

?? Did you try. It will take much more than an additional pointer sir

> in the block layer without the current bidi support that chains
> two struct request instances for data in and data out.
> 

That was the all trick of not changing a single API or structure
Just have two of the same thing, we already know how to handle

>>>   2) reduce the size of the critical struct request structure by
>>>  128 bits, thus reducing the memory used by every blk-mq driver
>>>  significantly, never mind the cache effects
>>
>> Hmm, one pointer (that is null in the non-bidi case) should be enough,
>> that's 64 or 32 bits.
> 
> Due to the way we use request chaining we need two fields at the
> moment.  ->special and ->next_rq.  

No! ->special is nothing to do with bidi. ->special is a field to be
used by LLD's only and are not to be touched by block layer or transports
or high level users.
 
Request has the single ->next_rq for bidi. And could be eliminated by
sharing space with the elevator info. Do you want a patch?

(So in effect it can be taking 0 bytes, and yes a little bit of code)

> If we'd refactor the whole thing
> for the basically non-existent user we could indeed probably get it
> down to a single pointer. 
> 
>> While on the subject of bidi, the order of transfers: is the data-out
>> (to the target) always before the data-in or is it the target device
>> that decides (depending on the semantics of the command) who is first?
> 
> The way I read SAM data needs to be transferred to the device for
> processing first, then the processing occurs and then it is transferred
> out, so the order seems fixed.
> 

Not sure what is the "SAM" above. But most of the BIDI commands I know,
osd and otherwise, the order is command specific, and many times it is
done in parallel.
Read some bits than write some bits, rinse and repeat ...

(You see in scsi the all OUT buffer is part of the actual CDB, so in effect
 any READ is a BIDI. The novelty here is the variable sizes and the SW stack
 memory targets for the different operations)

>>
>> Doug Gilbert
>>
>>  *** there could already be vendor specific bidi NVMe commands out
>> there (ditto for SCSI)
> 
> For NVMe they'd need to transfer data in and out in the same buffer
> to sort work, and even then only if we don't happen to be bounce
> buffering using swiotlb, or using a network transport.  Similarly for
> SCSI only iSCSI at the moment supports bidi CDBs, so we could have
> applications using vendor specific bidi commands on iSCSI, which
> is exactly what we're trying to find out, but it is a bit of a very
> niche use case.
> 

Again bidi works NOW. Did not yet see the big gain, of throwing it
out.

Jai Maa
Boaz

Re: [PATCH 3/4] bitmap_parselist: rework input string parser

[kbuild test robot]

Hi Yuri,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc7 next-20181221]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yuri-Norov/rework-bitmap_parselist/20181223-175529
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   lib/bitmap.c:679: warning: Excess function parameter 'buflen' description in 
'__bitmap_parselist'
   lib/bitmap.c:680: warning: Excess function parameter 'buflen' description in 
'__bitmap_parselist'
>> lib/bitmap.c:680: warning: Function parameter or member 'end' not described 
>> in '__bitmap_parselist'
   lib/bitmap.c:680: warning: Excess function parameter 'buflen' description in 
'__bitmap_parselist'
   include/linux/rcutree.h:1: warning: no structured comments found
   kernel/rcu/tree.c:684: warning: Excess function parameter 'irq' description 
in 'rcu_nmi_exit'
   include/linux/srcu.h:175: warning: Function parameter or member 'p' not 
described in 'srcu_dereference_notrace'
   include/linux/srcu.h:175: warning: Function parameter or member 'sp' not 
described in 'srcu_dereference_notrace'
   include/linux/gfp.h:1: warning: no structured comments found
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.ibss' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.connect' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.keys' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ie' 
not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.ie_len' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.bssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.ssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.default_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.default_mgmt_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4439: warning: Function parameter or member 
'wext.prev_bssid_valid' not described in 'wireless_dev'
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stats '
   include/net/cfg80211.h:2838: warning: cannot understand function prototype: 
'struct cfg80211_ftm_responder_stat

Re: [PATCH] binderfs: implement "max" mount option

[Christian Brauner]

On Sun, Dec 23, 2018 at 12:29:44PM +0100, Greg KH wrote:
> On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> > Since binderfs can be mounted by userns root in non-initial user namespaces
> > some precautions are in order. First, a way to set a maximum on the number
> > of binder devices that can be allocated per binderfs instance and second, a
> > way to reserve a reasonable chunk of binderfs devices for the initial ipc
> > namespace.
> > A first approach as seen in [1] used sysctls similiar to devpts but was
> > shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> > is an alternative approach which avoids sysctls completely and instead
> > switches to a single mount option.
> > 
> > Starting with this commit binderfs instances can be mounted with a limit on
> > the number of binder devices that can be allocated. The max= mount
> > option serves as a per-instance limit. If max= is set then only
> >  number of binder devices can be allocated in this binderfs
> > instance.
> 
> Ok, this is fine, but why such a big default?  You only need 4 to run a
> modern android system, and anyone using binder outside of android is
> really too crazy to ever be using it in a container :)
> 
> > Additionally, the binderfs instance in the initial ipc namespace will
> > always have a reserve of at least 1024 binder devices unless explicitly
> > capped via max=.
> 
> Again, why so many?  And why wouldn't that initial ipc namespace already
> have their device nodes created _before_ anything else is mounted?

Right, my issue is with re-creating devices, like if binderfs gets
unmounted or if devices get removed via rm. But we can lower the number
to 4 (see below).

> 
> Some comments on the patch below:

Thanks!

> 
> > +/*
> > + * Ensure that the initial ipc namespace always has a good chunk of devices
> > + * available.
> > + */
> > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)
> 
> Again that seems crazy big, how about splitting this into two different
> patches, one for the max= stuff, and one for this "reserve some minors"
> thing, so we can review them separately.

Yes, let's do that. I will also lower this to 4 reserved devices.

> 
> >  
> >  static struct vfsmount *binderfs_mnt;
> >  
> > @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
> >  static DEFINE_MUTEX(binderfs_minors_mutex);
> >  static DEFINE_IDA(binderfs_minors);
> >  
> > +/**
> > + * binderfs_mount_opts - mount options for binderfs
> > + * @max: maximum number of allocatable binderfs binder devices
> > + */
> > +struct binderfs_mount_opts {
> > +   int max;
> > +};
> > +
> > +enum {
> > +   Opt_max,
> > +   Opt_err
> > +};
> > +
> > +static const match_table_t tokens = {
> > +   { Opt_max, "max=%d" },
> > +   { Opt_err, NULL }
> > +};
> > +
> >  /**
> >   * binderfs_info - information about a binderfs mount
> >   * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> > @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
> >   *  created.
> >   * @root_gid:   gid that needs to be used when a new binder device is
> >   *  created.
> > + * @mount_opts: The mount options in use.
> > + * @device_count:   The current number of allocated binder devices.
> >   */
> >  struct binderfs_info {
> > struct ipc_namespace *ipc_ns;
> > struct dentry *control_dentry;
> > kuid_t root_uid;
> > kgid_t root_gid;
> > -
> > +   struct binderfs_mount_opts mount_opts;
> > +   atomic_t device_count;
> 
> Why atomic?
> 
> You should already have the lock held every time this is accessed,
> so no need to use an atomic value, just use an int.
> 
> > /* Reserve new minor number for the new device. */
> > mutex_lock(_minors_mutex);
> > -   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> > +   if (atomic_inc_return(>device_count) < info->mount_opts.max)
> 
> No need for atomic, see, your lock is held :)

Habit, to be honest.

Thanks, fixed version to follow in a bit.
Christian

[PATCH] arm64: defconfig: Add i.MX8MQ boot necessary configs

[Abel Vesa]

Enable all the i.MX8MQ configs necessary to boot.

Signed-off-by: Abel Vesa 
---
 arch/arm64/configs/defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 989f51b..8534bce 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -43,6 +43,7 @@ CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MVEBU=y
+CONFIG_ARCH_MXC=y
 CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_R8A774A1=y
@@ -246,6 +247,7 @@ CONFIG_NET_XGENE=y
 CONFIG_ATL1C=m
 CONFIG_MACB=y
 CONFIG_THUNDER_NIC_PF=y
+CONFIG_FEC=y
 CONFIG_HIX5HD2_GMAC=y
 CONFIG_HNS_DSAF=y
 CONFIG_HNS_ENET=y
@@ -320,6 +322,8 @@ CONFIG_SERIAL_MESON_CONSOLE=y
 CONFIG_SERIAL_SAMSUNG=y
 CONFIG_SERIAL_SAMSUNG_CONSOLE=y
 CONFIG_SERIAL_TEGRA=y
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_SH_SCI=y
 CONFIG_SERIAL_MSM=y
 CONFIG_SERIAL_MSM_CONSOLE=y
@@ -366,6 +370,7 @@ CONFIG_SPI_SPIDEV=m
 CONFIG_SPMI=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_PINCTRL_MAX77620=y
+CONFIG_PINCTRL_IMX8MQ=y
 CONFIG_PINCTRL_IPQ8074=y
 CONFIG_PINCTRL_MSM8916=y
 CONFIG_PINCTRL_MSM8994=y
@@ -613,6 +618,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y
 CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_CLK_QORIQ=y
 CONFIG_COMMON_CLK_PWM=y
+CONFIG_CLK_IMX8MQ=y
 CONFIG_TI_SCI_CLK=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_QCOM_CLK_SMD_RPM=y
-- 
2.7.4

[PATCH v2] soc: imx: Break dependency on SOC_IMX8MQ for GPCv2

[Abel Vesa]

Since this is going to be used on more SoCs than just i.MX8MQ,
make the dependency here more generic.

Signed-off-by: Abel Vesa 
Reviewed-by: Dong Aisheng 
---
Changes since v1:
 * removed the SOC_IMX7D since it's included by ARCH_MXC
   as suggested by Dong Aisheng.

 drivers/soc/imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index 2112d18..d80f899 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -2,7 +2,7 @@ menu "i.MX SoC drivers"
 
 config IMX_GPCV2_PM_DOMAINS
bool "i.MX GPCv2 PM domains"
-   depends on SOC_IMX7D || SOC_IMX8MQ || (COMPILE_TEST && OF)
+   depends on ARCH_MXC || (COMPILE_TEST && OF)
depends on PM
select PM_GENERIC_DOMAINS
default y if SOC_IMX7D
-- 
2.7.4

Re: powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"

[Michael Ellerman]

On Tue, 2018-11-20 at 15:12:30 UTC, Alexandre Belloni wrote:
> Fix a spelling mistake in a register description.
> 
> Signed-off-by: Alexandre Belloni 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a083787680f80f2c16316a1d907bf8

cheers

Re: powerpc: pseries: pmem: Convert to using %pOFn instead of device_node.name

[Michael Ellerman]

On Wed, 2018-12-05 at 19:50:17 UTC, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier. pmem.c was
> recently added and missed the initial conversion.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0d1223dd9273b2ba3e965a81092a23

cheers

Re: [5/5] powerpc/4xx: Delete an unnecessary return statement in two functions

[Michael Ellerman]

On Thu, 2018-01-11 at 18:04:54 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:40:23 +0100
> 
> The script "checkpatch.pl" pointed information out like the following.
> 
> WARNING: void function return statements are not generally useful
> 
> Thus remove such a statement in the affected functions.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ae6263cc33742d1c179510b6aadd31

cheers

Re: powerpc/8xx: Allow pinning IMMR TLB when using early debug console

[Michael Ellerman]

On Thu, 2018-12-20 at 07:25:28 UTC, Christophe Leroy wrote:
> CONFIG_EARLY_DEBUG_CPM requires IMMR area TLB to be pinned
> otherwise it doesn't survive MMU_init, and the boot fails.
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/96d19d70e1012383365c68e271d99f

cheers

Re: [2/5] powerpc/4xx: Use seq_putc() in ocm_debugfs_show()

[Michael Ellerman]

On Thu, 2018-01-11 at 18:01:33 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:10:02 +0100
> 
> A single character (line break) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/52930bc6e87191af3894bec302774f

cheers

Re: macintosh: Use of_node_name_{eq, prefix} for node name comparisons

[Michael Ellerman]

On Wed, 2018-12-05 at 19:50:28 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_{eq,prefix}
> helpers instead. This removes direct access to the node name pointer.
> 
> This changes a single case insensitive node name comparison to case
> sensitive for "ata4". This is the only instance of a case insensitive
> comparison for all the open coded node name comparisons on powerpc.
> Searching the commit history, there doesn't appear to be any reason for
> it to be case insensitive.
> 
> A couple of open coded iterating thru the child node names are converted
> to use for_each_child_of_node() instead.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f1e0addca8bd7386f8cabbc64c9988

cheers

Re: [1/5] powerpc/4xx: Combine four seq_printf() calls into two in ocm_debugfs_show()

[Michael Ellerman]

On Thu, 2018-01-11 at 18:00:33 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:08:08 +0100
> 
> Some data were printed into a sequence by four separate function calls.
> Print the same data by two single function calls instead.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/b52106a040e6f86848b05be1b43174

cheers

Re: [3/5] powerpc/4xx: Delete an error message for a failed memory allocation in three functions

[Michael Ellerman]

On Thu, 2018-01-11 at 18:02:45 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:28:54 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a8d5dadae59f5866ac3b68cb993d53

cheers

Re: [v2] Powerpc/perf: Wire up PMI throttling

[Michael Ellerman]

On Wed, 2018-11-21 at 03:56:37 UTC, Ravi Bangoria wrote:
> Commit 14c63f17b1fde ("perf: Drop sample rate when sampling is too
> slow") introduced a way to throttle PMU interrupts if we're spending
> too much time just processing those. Wire up powerpc PMI handler to
> use this infrastructure.
> 
> We have throttling of the *rate* of interrupts, but this adds
> throttling based on the *time taken* to process the interrupts.
> 
> Signed-off-by: Ravi Bangoria 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0c9108b083706330cd5484d121fbb0

cheers

Re: [v2, 01/11] powerpc/mm: Fix reporting of kernel execute faults on the 8xx

[Michael Ellerman]

On Wed, 2018-11-28 at 09:27:04 UTC, Christophe Leroy wrote:
> On the 8xx, no-execute is set via PPP bits in the PTE. Therefore
> a no-exec fault generates DSISR_PROTFAULT error bits,
> not DSISR_NOEXEC_OR_G.
> 
> This patch adds DSISR_PROTFAULT in the test mask.
> 
> Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults")
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ffca395b11c4a5a6df6d6345f794b0

cheers

Re: ide: Use of_node_name_eq for node name comparisons

[Michael Ellerman]

On Wed, 2018-12-05 at 19:50:25 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> Cc: "David S. Miller" 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c1fa31b0fc90a80d64a334e5d35dca

cheers

Re: powerpc: Use of_node_name_eq for node name comparisons

[Michael Ellerman]

On Wed, 2018-12-05 at 19:50:18 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> A couple of open coded iterating thru the child node names are converted
> to use for_each_child_of_node() instead.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Alistair Popple 
> Cc: Matt Porter 
> Cc: Anatolij Gustschin 
> Cc: Arnd Bergmann 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2c8e65b595cf0bf7c1413404dff9b9

cheers

Re: [v6,1/5] powerpc: add __NR_syscalls along with NR_syscalls

[Michael Ellerman]

On Mon, 2018-12-17 at 10:40:32 UTC, Firoz Khan wrote:
> NR_syscalls macro holds the number of system call exist
> in powerpc architecture. We have to change the value of
> NR_syscalls, if we add or delete a system call.
> 
> One of the patch in this patch series has a script which
> will generate a uapi header based on syscall.tbl file.
> The syscall.tbl file contains the number of system call
> information. So we have two option to update NR_syscalls
> value.
> 
> 1. Update NR_syscalls in asm/unistd.h manually by count-
>ing the no.of system calls. No need to update NR_sys-
>calls until we either add a new system call or delete
>existing system call.
> 
> 2. We can keep this feature in above mentioned script,
>that will count the number of syscalls and keep it in
>a generated file. In this case we don't need to expli-
>citly update NR_syscalls in asm/unistd.h file.
> 
> The 2nd option will be the recommended one. For that, I
> added the __NR_syscalls macro in uapi/asm/unistd.h along
> with NR_syscalls asm/unistd.h. The macro __NR_syscalls
> also added for making the name convention same across all
> architecture. While __NR_syscalls isn't strictly part of
> the uapi, having it as part of the generated header to
> simplifies the implementation. We also need to enclose
> this macro with #ifdef __KERNEL__ to avoid side effects.
> 
> Signed-off-by: Firoz Khan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/8a19eeeab66dfdd7c67bc8e3048ac0

cheers

Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup

[Noralf Trønnes]

Den 23.12.2018 01.55, skrev Peter Wu:

After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
"dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
have some effect). After that, drm_fb_helper_initial_config is called
which may call the "fb_probe" driver callback.

This driver callback may call drm_fb_helper_defio_init (as is done by
drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
as documented. These are normally cleaned up on exit by
drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.

If an error occurs after "fb_probe", but before setup is complete, then
calling just drm_fb_helper_fini will leak resources. This was triggered
by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):

 [   50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this 
framebuffer
 [   50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup] 
*ERROR* fbdev: Failed to set configuration (ret=-38)
 [   50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 
on minor 2
 [   50.013604] WARNING: CPU: 1 PID: 1 at 
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
 [   50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT 
4.20.0-rc7 #1
 [   50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
 ...
 [   50.023155] Call Trace:
 [   50.023155]  ? bochs_kms_fini+0x1e/0x30
 [   50.023155]  ? bochs_unload+0x18/0x40

This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.

Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
Reported-by: kernel test robot 
Cc: Noralf Trønnes 
Signed-off-by: Peter Wu 
---
  drivers/gpu/drm/drm_fb_helper.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d64f874f965..432e0f3b9267 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
return 0;
  
  err_drm_fb_helper_fini:

-   drm_fb_helper_fini(fb_helper);
+   drm_fb_helper_fbdev_teardown(dev);


This change will break the error path for drm_fbdev_generic_setup()
because drm_fb_helper_generic_probe() cleans up on error but doesn't
clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().

My assumption has been that the drm_fb_helper_funcs->fb_probe callback
cleans up its resources on error. Clearly this is not the case for 
bochs, so my take on this is that bochsfb_create() needs to clean up on 
error.


Gerd has a patchset that switches bochs over to the generic fbdev
emulation, but ofc that doesn't help with 4.20:
https://patchwork.freedesktop.org/series/54269/

Noralf.

  
  	return ret;

  }

[PATCH] Staging: iio: adt7316: Add regmap support

[Shreeya Patel]

Both i2c and spi drivers have functions for reading and writing
to/from registers. Remove this redundant and common code by using
regmap API.
Also remove multi_read and multi_write functions from i2c
and spi driver as they are not being used anywhere.

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316-i2c.c | 101 ++--
 drivers/staging/iio/addac/adt7316-spi.c |  94 +++
 drivers/staging/iio/addac/adt7316.c | 147 
 drivers/staging/iio/addac/adt7316.h |  15 +--
 4 files changed, 103 insertions(+), 254 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316-i2c.c 
b/drivers/staging/iio/addac/adt7316-i2c.c
index ac91163656b5..435b65845174 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -12,105 +12,28 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "adt7316.h"
 
-/*
- * adt7316 register access by I2C
- */
-static int adt7316_i2c_read(void *client, u8 reg, u8 *data)
-{
-   struct i2c_client *cl = client;
-   int ret;
-
-   ret = i2c_smbus_write_byte(cl, reg);
-   if (ret < 0) {
-   dev_err(>dev, "I2C fail to select reg\n");
-   return ret;
-   }
-
-   ret = i2c_smbus_read_byte(client);
-
-   if (!ret)
-   return -EIO;
-
-   if (ret < 0) {
-   dev_err(>dev, "I2C read error\n");
-   return ret;
-   }
-
-   *data = ret;
-
-   return 0;
-}
-
-static int adt7316_i2c_write(void *client, u8 reg, u8 data)
-{
-   struct i2c_client *cl = client;
-   int ret = 0;
-
-   ret = i2c_smbus_write_byte_data(cl, reg, data);
-   if (ret < 0)
-   dev_err(>dev, "I2C write error\n");
-
-   return ret;
-}
-
-static int adt7316_i2c_multi_read(void *client, u8 reg, u8 count, u8 *data)
-{
-   struct i2c_client *cl = client;
-   int i, ret = 0;
-
-   if (count > ADT7316_REG_MAX_ADDR)
-   count = ADT7316_REG_MAX_ADDR;
-
-   for (i = 0; i < count; i++) {
-   ret = adt7316_i2c_read(cl, reg, [i]);
-   if (ret < 0) {
-   dev_err(>dev, "I2C multi read error\n");
-   return ret;
-   }
-   }
-
-   return 0;
-}
-
-static int adt7316_i2c_multi_write(void *client, u8 reg, u8 count, u8 *data)
-{
-   struct i2c_client *cl = client;
-   int i, ret = 0;
-
-   if (count > ADT7316_REG_MAX_ADDR)
-   count = ADT7316_REG_MAX_ADDR;
-
-   for (i = 0; i < count; i++) {
-   ret = adt7316_i2c_write(cl, reg, data[i]);
-   if (ret < 0) {
-   dev_err(>dev, "I2C multi write error\n");
-   return ret;
-   }
-   }
-
-   return 0;
-}
-
 /*
  * device probe and remove
  */
-
 static int adt7316_i2c_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   struct adt7316_bus bus = {
-   .client = client,
-   .irq = client->irq,
-   .read = adt7316_i2c_read,
-   .write = adt7316_i2c_write,
-   .multi_read = adt7316_i2c_multi_read,
-   .multi_write = adt7316_i2c_multi_write,
-   };
+   struct regmap *regmap;
+
+   regmap = devm_regmap_init_i2c(client, _regmap_config);
+
+   if (IS_ERR(regmap)) {
+   dev_err(>dev, "Error initializing i2c regmap: %ld\n",
+   PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
 
-   return adt7316_probe(>dev, , id->name);
+   return adt7316_probe(>dev, regmap, id ? id->name : NULL,
+client->irq);
 }
 
 static const struct i2c_device_id adt7316_i2c_id[] = {
diff --git a/drivers/staging/iio/addac/adt7316-spi.c 
b/drivers/staging/iio/addac/adt7316-spi.c
index e75827e326a6..9e3decb5cb77 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -11,79 +11,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "adt7316.h"
 
 #define ADT7316_SPI_MAX_FREQ_HZ500
-#define ADT7316_SPI_CMD_READ   0x91
-#define ADT7316_SPI_CMD_WRITE  0x90
-
-/*
- * adt7316 register access by SPI
- */
-
-static int adt7316_spi_multi_read(void *client, u8 reg, u8 count, u8 *data)
-{
-   struct spi_device *spi_dev = client;
-   u8 cmd[2];
-   int ret = 0;
-
-   if (count > ADT7316_REG_MAX_ADDR)
-   count = ADT7316_REG_MAX_ADDR;
-
-   cmd[0] = ADT7316_SPI_CMD_WRITE;
-   cmd[1] = reg;
-
-   ret = spi_write(spi_dev, cmd, 2);
-   if (ret < 0) {
-   dev_err(_dev->dev, "SPI fail to select reg\n");
-   return ret;
-   }
-
-   cmd[0] = ADT7316_SPI_CMD_READ;
-
-   ret = spi_write_then_read(spi_dev, cmd, 1, data, count);
-   if (ret < 0) {
-   dev_err(_dev->dev, "SPI read data error\n");

Re: [PATCH] binderfs: implement "max" mount option

[Christian Brauner]

On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> Since binderfs can be mounted by userns root in non-initial user namespaces
> some precautions are in order. First, a way to set a maximum on the number
> of binder devices that can be allocated per binderfs instance and second, a
> way to reserve a reasonable chunk of binderfs devices for the initial ipc
> namespace.
> A first approach as seen in [1] used sysctls similiar to devpts but was
> shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> is an alternative approach which avoids sysctls completely and instead
> switches to a single mount option.
> 
> Starting with this commit binderfs instances can be mounted with a limit on
> the number of binder devices that can be allocated. The max= mount
> option serves as a per-instance limit. If max= is set then only
>  number of binder devices can be allocated in this binderfs
> instance.
> Additionally, the binderfs instance in the initial ipc namespace will
> always have a reserve of at least 1024 binder devices unless explicitly
> capped via max=.
> 
> This allows to safely bind-mount binderfs instances into unprivileged user
> namespaces since userns root in a non-initial user namespace cannot change
> the mount option as long as it does not own the mount namespace the
> binderfs mount was created in and hence cannot drain the host of minor
> device numbers
> 
> [1]: https://lore.kernel.org/lkml/20181221133909.18794-1-christ...@brauner.io/
> [2]; https://lore.kernel.org/lkml/20181221163316.ga8...@kroah.com/
> [3]: 
> https://lore.kernel.org/lkml/cahrssex+gdvw4fkkk8oznair9g5icjlyodo8hykv3o0o1jt...@mail.gmail.com/
> [4]: https://lore.kernel.org/lkml/20181221192044.5yvfnuri7gdop...@brauner.io/
> 
> Cc: Todd Kjos 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Christian Brauner 
> ---
>  drivers/android/binderfs.c | 109 +++--
>  1 file changed, 104 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 7496b10532aa..93aee00994d4 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -39,6 +40,11 @@
>  #define INODE_OFFSET 3
>  #define INTSTRLEN 21
>  #define BINDERFS_MAX_MINOR (1U << MINORBITS)
> +/*
> + * Ensure that the initial ipc namespace always has a good chunk of devices
> + * available.
> + */
> +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)
>  
>  static struct vfsmount *binderfs_mnt;
>  
> @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
>  static DEFINE_MUTEX(binderfs_minors_mutex);
>  static DEFINE_IDA(binderfs_minors);
>  
> +/**
> + * binderfs_mount_opts - mount options for binderfs
> + * @max: maximum number of allocatable binderfs binder devices
> + */
> +struct binderfs_mount_opts {
> + int max;
> +};
> +
> +enum {
> + Opt_max,
> + Opt_err
> +};
> +
> +static const match_table_t tokens = {
> + { Opt_max, "max=%d" },
> + { Opt_err, NULL }
> +};
> +
>  /**
>   * binderfs_info - information about a binderfs mount
>   * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
>   *  created.
>   * @root_gid:   gid that needs to be used when a new binder device is
>   *  created.
> + * @mount_opts: The mount options in use.
> + * @device_count:   The current number of allocated binder devices.
>   */
>  struct binderfs_info {
>   struct ipc_namespace *ipc_ns;
>   struct dentry *control_dentry;
>   kuid_t root_uid;
>   kgid_t root_gid;
> -
> + struct binderfs_mount_opts mount_opts;
> + atomic_t device_count;
>  };
>  
>  static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
> @@ -107,13 +134,22 @@ static int binderfs_binder_device_create(struct inode 
> *ref_inode,
>   struct inode *inode = NULL;
>   struct super_block *sb = ref_inode->i_sb;
>   struct binderfs_info *info = sb->s_fs_info;
> + bool use_reserve = (info->ipc_ns == _ipc_ns);
>  
>   /* Reserve new minor number for the new device. */
>   mutex_lock(_minors_mutex);
> - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> + if (atomic_inc_return(>device_count) < info->mount_opts.max)
> + minor = ida_alloc_max(_minors,
> +   use_reserve ? BINDERFS_MAX_MINOR :
> + BINDERFS_MAX_MINOR_CAPPED,
> +   GFP_KERNEL);
> + else
> + minor = -ENOSPC;
>   mutex_unlock(_minors_mutex);
> - if (minor < 0)
> + if (minor < 0) {
> + atomic_dec(>device_count);
>   return minor;
> + }
>  
>   ret = -ENOMEM;
>   device = kzalloc(sizeof(*device), GFP_KERNEL);
> @@ -187,6 +223,7 @@ static 

[PATCH v1 1/2] binderfs: implement "max" mount option

[Christian Brauner]

Since binderfs can be mounted by userns root in non-initial user namespaces
some precautions are in order. First, a way to set a maximum on the number
of binder devices that can be allocated per binderfs instance and second, a
way to reserve a reasonable chunk of binderfs devices for the initial ipc
namespace.
A first approach as seen in [1] used sysctls similiar to devpts but was
shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
is an alternative approach which avoids sysctls completely and instead
switches to a single mount option.

Starting with this commit binderfs instances can be mounted with a limit on
the number of binder devices that can be allocated. The max= mount
option serves as a per-instance limit. If max= is set then only
 number of binder devices can be allocated in this binderfs
instance.

This allows to safely bind-mount binderfs instances into unprivileged user
namespaces since userns root in a non-initial user namespace cannot change
the mount option as long as it does not own the mount namespace the
binderfs mount was created in and hence cannot drain the host of minor
device numbers

[1]: https://lore.kernel.org/lkml/20181221133909.18794-1-christ...@brauner.io/
[2]; https://lore.kernel.org/lkml/20181221163316.ga8...@kroah.com/
[3]: 
https://lore.kernel.org/lkml/cahrssex+gdvw4fkkk8oznair9g5icjlyodo8hykv3o0o1jt...@mail.gmail.com/
[4]: https://lore.kernel.org/lkml/20181221192044.5yvfnuri7gdop...@brauner.io/

Cc: Todd Kjos 
Cc: Greg Kroah-Hartman 
Signed-off-by: Christian Brauner 
---
v1:
- split reserving devices for the binderfs instance in the initial ipc
  namespace into a separate patch (cf. [1])
- s/
- use simple int instead of atomic_t for counting devices since we're
  incrementing and decrementing under a mutex anyway (cf. [1])
- correctly use match_int() (cf. [2])
v0:
- patch introduced

[1]: https://lore.kernel.org/lkml/20181223112944.gc27...@kroah.com/
[2]: https://lore.kernel.org/lkml/20181223135755.sqnv5ave62jtj...@brauner.io/
---
 drivers/android/binderfs.c | 101 +++--
 1 file changed, 96 insertions(+), 5 deletions(-)

diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 7496b10532aa..873adda064ac 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,24 @@ static dev_t binderfs_dev;
 static DEFINE_MUTEX(binderfs_minors_mutex);
 static DEFINE_IDA(binderfs_minors);
 
+/**
+ * binderfs_mount_opts - mount options for binderfs
+ * @max: maximum number of allocatable binderfs binder devices
+ */
+struct binderfs_mount_opts {
+   int max;
+};
+
+enum {
+   Opt_max,
+   Opt_err
+};
+
+static const match_table_t tokens = {
+   { Opt_max, "max=%d" },
+   { Opt_err, NULL }
+};
+
 /**
  * binderfs_info - information about a binderfs mount
  * @ipc_ns: The ipc namespace the binderfs mount belongs to.
@@ -55,13 +74,16 @@ static DEFINE_IDA(binderfs_minors);
  *  created.
  * @root_gid:   gid that needs to be used when a new binder device is
  *  created.
+ * @mount_opts: The mount options in use.
+ * @device_count:   The current number of allocated binder devices.
  */
 struct binderfs_info {
struct ipc_namespace *ipc_ns;
struct dentry *control_dentry;
kuid_t root_uid;
kgid_t root_gid;
-
+   struct binderfs_mount_opts mount_opts;
+   int device_count;
 };
 
 static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
@@ -110,10 +132,16 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
 
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
-   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
+   if (++info->device_count <= info->mount_opts.max)
+   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR,
+ GFP_KERNEL);
+   else
+   minor = -ENOSPC;
mutex_unlock(_minors_mutex);
-   if (minor < 0)
+   if (minor < 0) {
+   --info->device_count;
return minor;
+   }
 
ret = -ENOMEM;
device = kzalloc(sizeof(*device), GFP_KERNEL);
@@ -187,6 +215,7 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
kfree(name);
kfree(device);
mutex_lock(_minors_mutex);
+   --info->device_count;
ida_free(_minors, minor);
mutex_unlock(_minors_mutex);
iput(inode);
@@ -232,6 +261,7 @@ static long binder_ctl_ioctl(struct file *file, unsigned 
int cmd,
 static void binderfs_evict_inode(struct inode *inode)
 {
struct binder_device *device = inode->i_private;
+   struct binderfs_info *info = BINDERFS_I(inode);
 
clear_inode(inode);
 
@@ -239,6 +269,7 @@ static void binderfs_evict_inode(struct inode 

[PATCH v1 2/2] binderfs: reserve devices for initial mount

[Christian Brauner]

The binderfs instance in the initial ipc namespace will always have a
reserve of 4 binder devices unless explicitly capped by specifying a lower
value via the "max" mount option.
This ensures when binder devices are removed (on accident or on purpose)
they can always be recreated without risking that all minor numbers have
already been used up.

Cc: Todd Kjos 
Cc: Greg Kroah-Hartman 
Signed-off-by: Christian Brauner 
---
v1:
- patch introduced
v0:
- patch not present
---
 drivers/android/binderfs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 873adda064ac..aa635c7ea727 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -40,6 +40,8 @@
 #define INODE_OFFSET 3
 #define INTSTRLEN 21
 #define BINDERFS_MAX_MINOR (1U << MINORBITS)
+/* Ensure that the initial ipc namespace always has a devices available. */
+#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4)
 
 static struct vfsmount *binderfs_mnt;
 
@@ -129,11 +131,14 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
struct inode *inode = NULL;
struct super_block *sb = ref_inode->i_sb;
struct binderfs_info *info = sb->s_fs_info;
+   bool use_reserve = (info->ipc_ns == _ipc_ns);
 
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
if (++info->device_count <= info->mount_opts.max)
-   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR,
+   minor = ida_alloc_max(_minors,
+ use_reserve ? BINDERFS_MAX_MINOR :
+   BINDERFS_MAX_MINOR_CAPPED,
  GFP_KERNEL);
else
minor = -ENOSPC;
-- 
2.19.1

Re: [PATCH] RISC-V: Make BSS section as the last section in vmlinux.lds.S

[Anup Patel]

On Fri, Dec 21, 2018 at 2:10 AM Palmer Dabbelt  wrote:
>
> On Mon, 17 Dec 2018 01:36:45 PST (-0800), a...@brainfault.org wrote:
> > On Mon, Nov 26, 2018 at 11:42 AM Anup Patel  wrote:
> >>
> >> The objcopy only emits loadable sections when creating flat kernel
> >> Image. To have minimal possible size of flat kernel Image, we should
> >> have all non-loadable sections after loadable sections.
> >>
> >> Currently, execption table section (loadable section) is after BSS
> >> section (non-loadable section) in the RISC-V vmlinux.lds.S. This
> >> is not optimal for having minimal flat kernel Image size hence this
> >> patch makes BSS section as the last section in RISC-V vmlinux.lds.S.
> >>
> >> In addition, we make BSS section aligned to 16byte instead of PAGE
> >> aligned which further reduces flat kernel Image size by few KBs.
> >>
> >> The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is
> >> 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to
> >> 7991740 bytes with this patch applied using GCC 8.2.0. In summary,
> >> this patch reduces Linux-4.20-rc4 flat kernel Image size by 809 KB.
> >>
> >> Signed-off-by: Anup Patel 
> >> ---
> >>  arch/riscv/kernel/vmlinux.lds.S | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/riscv/kernel/vmlinux.lds.S 
> >> b/arch/riscv/kernel/vmlinux.lds.S
> >> index 65df1dfdc303..cc99eed44931 100644
> >> --- a/arch/riscv/kernel/vmlinux.lds.S
> >> +++ b/arch/riscv/kernel/vmlinux.lds.S
> >> @@ -74,8 +74,6 @@ SECTIONS
> >> *(.sbss*)
> >> }
> >>
> >> -   BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0)
> >> -
> >> EXCEPTION_TABLE(0x10)
> >> NOTES
> >>
> >> @@ -83,6 +81,8 @@ SECTIONS
> >> *(.rel.dyn*)
> >> }
> >>
> >> +   BSS_SECTION(0x10, 0x10, 0x10)
> >> +
> >> _end = .;
> >>
> >> STABS_DEBUG
> >> --
> >> 2.17.1
> >>
> >
> > Hi All,
> >
> > Any comment on this patch?
>
> Sorry, I haven't had a chance to look at it yet.  Aside from the macro issue
> mentioned by Nick it seems OK.

I have send v2 to address Nick's comment.

Regards,
Anup

[PATCH v2 0/5] Introduced new Cadence USBSS DRD Driver.

[Pawel Laszczak]

This patch set introduce new Cadence USBSS DRD driver
to linux kernel.

The Cadence USBSS DRD Driver s a highly
configurable IP Core which can be
instantiated as Dual-Role Device (DRD),
Peripheral Only and Host Only (XHCI)
configurations.

The current driver has been validated with
FPGA burned. We have support for PCIe
bus, which is used on FPGA prototyping.

The host site of USBSS controller is compliance
with XHCI specification, so it works with
standard XHCI linux driver.

Changes since v1:
 - Removed not implemented Susped/Resume functions.
 - Fixed some issues in debugging related functions.
 - Added trace_cdns3_request_handled marker.
 - Added support for Isochronouse transfer. 
 - Added some additional descriptions.
 - Fixed compilation error in cdns3_gadget_ep_disable.
 - Added detection of device controller version at runtime.
 - Upgraded dt-binding documentation.
 - Deleted ENOSYS from phy initialization section. It should be also removed
   from generic PHY driver.
 - added ep0_stage flag used during enumeration process.
 - Fixed issue with TEST MODE.
 - Added one common function for finish control transfer.
 - Separated some decoding function from dwc3 driver to common library file,
   and removed equivalents function from debug.h file as suggested  by Felipe.
 - replaced function name cdns3_gadget_unconfig with cdns3_hw_reset_eps_config.
 - Improved algorithm fixing hardware issue related to blocking endpoints.
   This issue is related to on-chip shared FIFO buffers for OUT packets. 
   Problem was reported by Peter Chan.
 - Changed organization of endpoint array in cdns3_device object.  
  - added ep0 to common eps array
  - removed cdns3_free_trb_pool and cdns3_ep_addr_to_bit_pos macros.
  - removed ep0_trb_dma, ep0_trb fields from cdns3_device.
 - Removed ep0_request and ep_nums fields from cdns3_device.
 - Other minor changes according with Felipe suggestion.

---

Pawel Laszczak (5):
  dt-bindings: add binding for USBSS-DRD controller.
  usb:common Separated decoding functions from dwc3 driver.
  usb:common Patch simplify usb_decode_set_clear_feature function.
  usb:common Simplify usb_decode_get_set_descriptor function.
  usb:cdns3 Add Cadence USB3 DRD Driver

 .../devicetree/bindings/usb/cdns3-usb.txt |   30 +
 drivers/usb/Kconfig   |2 +
 drivers/usb/Makefile  |2 +
 drivers/usb/cdns3/Kconfig |   44 +
 drivers/usb/cdns3/Makefile|   16 +
 drivers/usb/cdns3/cdns3-pci-wrap.c|  157 ++
 drivers/usb/cdns3/core.c  |  406 
 drivers/usb/cdns3/core.h  |  116 +
 drivers/usb/cdns3/debug.h |  166 ++
 drivers/usb/cdns3/debugfs.c   |  168 ++
 drivers/usb/cdns3/drd.c   |  350 +++
 drivers/usb/cdns3/drd.h   |  162 ++
 drivers/usb/cdns3/ep0.c   |  896 +++
 drivers/usb/cdns3/gadget-export.h |   28 +
 drivers/usb/cdns3/gadget.c| 2102 +
 drivers/usb/cdns3/gadget.h| 1206 ++
 drivers/usb/cdns3/host-export.h   |   28 +
 drivers/usb/cdns3/host.c  |   72 +
 drivers/usb/cdns3/trace.c |   11 +
 drivers/usb/cdns3/trace.h |  389 +++
 drivers/usb/common/Makefile   |2 +-
 drivers/usb/common/debug.c|  265 +++
 drivers/usb/dwc3/debug.h  |  243 --
 drivers/usb/dwc3/trace.h  |2 +-
 include/linux/usb/ch9.h   |   19 +
 25 files changed, 6637 insertions(+), 245 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/cdns3-usb.txt
 create mode 100644 drivers/usb/cdns3/Kconfig
 create mode 100644 drivers/usb/cdns3/Makefile
 create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c
 create mode 100644 drivers/usb/cdns3/core.c
 create mode 100644 drivers/usb/cdns3/core.h
 create mode 100644 drivers/usb/cdns3/debug.h
 create mode 100644 drivers/usb/cdns3/debugfs.c
 create mode 100644 drivers/usb/cdns3/drd.c
 create mode 100644 drivers/usb/cdns3/drd.h
 create mode 100644 drivers/usb/cdns3/ep0.c
 create mode 100644 drivers/usb/cdns3/gadget-export.h
 create mode 100644 drivers/usb/cdns3/gadget.c
 create mode 100644 drivers/usb/cdns3/gadget.h
 create mode 100644 drivers/usb/cdns3/host-export.h
 create mode 100644 drivers/usb/cdns3/host.c
 create mode 100644 drivers/usb/cdns3/trace.c
 create mode 100644 drivers/usb/cdns3/trace.h
 create mode 100644 drivers/usb/common/debug.c

-- 
2.17.1

[PATCH v2 1/5] dt-bindings: add binding for USBSS-DRD controller.

[Pawel Laszczak]

This patch aim at documenting USB related dt-bindings for the
Cadence USBSS-DRD controller.

Signed-off-by: Pawel Laszczak 
---
 .../devicetree/bindings/usb/cdns3-usb.txt | 30 +++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/cdns3-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/cdns3-usb.txt 
b/Documentation/devicetree/bindings/usb/cdns3-usb.txt
new file mode 100644
index ..cf93bd0de5cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cdns3-usb.txt
@@ -0,0 +1,30 @@
+Binding for the Cadence USBSS-DRD controller
+
+Required properties:
+  - reg: Physical base address and size of the controller's register areas.
+Controller has 3 different regions:
+region 1 - HOST registers area
+region 2 - DEVICE registers area
+region 3 - OTG/DRD registers area
+  - compatible: Should contain: "cdns,usb3-1.0.0" or "cdns,usb3-1.0.1"
+  - interrupts: Interrupt specifier. Refer to interrupt bindings.
+   Driver supports only single interrupt line.
+This single interrupt is shared between Device,
+   host and OTG/DRD part of driver.
+
+Optional properties:
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - dr_mode: Should be one of "host", "peripheral" or "otg".
+ - phys: reference to the USB PHY
+ - phy-names: name of the USB PHY, should be "cdns3,usbphy"
+
+
+Example:
+   usb@f300 {
+   compatible = "cdns,usb3";
+   interrupts = ;
+   reg = <0xf300 0x1   /* memory area for HOST 
registers */
+   0xf301 0x1  /* memory area for DEVICE 
registers */
+   0xf302 0x1>;/* memory area for OTG/DRD 
registers */
+   };
-- 
2.17.1

[PATCH v2 4/5] usb:common Simplify usb_decode_get_set_descriptor function.

[Pawel Laszczak]

Patch moves switch responsible for decoding descriptor type
outside snprintf. It's little improves code readability.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/common/debug.c | 111 +++--
 1 file changed, 57 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
index 77e565a38f29..c15fa066339c 100644
--- a/drivers/usb/common/debug.c
+++ b/drivers/usb/common/debug.c
@@ -104,62 +104,65 @@ static void usb_decode_get_set_descriptor(__u8 
bRequestType, __u8 bRequest,
  __u16 wValue, __u16 wIndex,
  __u16 wLength, char *str)
 {
+   char *s;
+
+   switch (wValue >> 8) {
+   case USB_DT_DEVICE:
+   s = "Device";
+   break;
+   case USB_DT_CONFIG:
+   s = "Configuration";
+   break;
+   case USB_DT_STRING:
+   s = "String";
+   break;
+   case USB_DT_INTERFACE:
+   s = "Interface";
+   break;
+   case USB_DT_ENDPOINT:
+   s = "Endpoint";
+   break;
+   case USB_DT_DEVICE_QUALIFIER:
+   s = "Device Qualifier";
+   break;
+   case USB_DT_OTHER_SPEED_CONFIG:
+   s = "Other Speed Config";
+   break;
+   case USB_DT_INTERFACE_POWER:
+   s = "Interface Power";
+   break;
+   case USB_DT_OTG:
+   s = "OTG";
+   break;
+   case USB_DT_DEBUG:
+   s = "Debug";
+   break;
+   case USB_DT_INTERFACE_ASSOCIATION:
+   s = "Interface Association";
+   break;
+   case USB_DT_BOS:
+   s = "BOS";
+   break;
+   case USB_DT_DEVICE_CAPABILITY:
+   s = "Device Capability";
+   break;
+   case USB_DT_PIPE_USAGE:
+   s = "Pipe Usage";
+   break;
+   case USB_DT_SS_ENDPOINT_COMP:
+   s = "SS Endpoint Companion";
+   break;
+   case USB_DT_SSP_ISOC_ENDPOINT_COMP:
+   s = "SSP Isochronous Endpoint Companion";
+   break;
+   default:
+   s = "UNKNOWN";
+   break;
+   }
+
sprintf(str, "%s %s Descriptor(Index = %d, Length = %d)",
bRequest == USB_REQ_GET_DESCRIPTOR ? "Get" : "Set",
-   ({ char *s;
-   switch (wValue >> 8) {
-   case USB_DT_DEVICE:
-   s = "Device";
-   break;
-   case USB_DT_CONFIG:
-   s = "Configuration";
-   break;
-   case USB_DT_STRING:
-   s = "String";
-   break;
-   case USB_DT_INTERFACE:
-   s = "Interface";
-   break;
-   case USB_DT_ENDPOINT:
-   s = "Endpoint";
-   break;
-   case USB_DT_DEVICE_QUALIFIER:
-   s = "Device Qualifier";
-   break;
-   case USB_DT_OTHER_SPEED_CONFIG:
-   s = "Other Speed Config";
-   break;
-   case USB_DT_INTERFACE_POWER:
-   s = "Interface Power";
-   break;
-   case USB_DT_OTG:
-   s = "OTG";
-   break;
-   case USB_DT_DEBUG:
-   s = "Debug";
-   break;
-   case USB_DT_INTERFACE_ASSOCIATION:
-   s = "Interface Association";
-   break;
-   case USB_DT_BOS:
-   s = "BOS";
-   break;
-   case USB_DT_DEVICE_CAPABILITY:
-   s = "Device Capability";
-   break;
-   case USB_DT_PIPE_USAGE:
-   s = "Pipe Usage";
-   break;
-   case USB_DT_SS_ENDPOINT_COMP:
-   s = "SS Endpoint Companion";
-   break;
-   case USB_DT_SSP_ISOC_ENDPOINT_COMP:
-   s = "SSP Isochronous Endpoint Companion";
-   break;
-   default:
-   s = "UNKNOWN";
-   break;
-   } s; }), wValue & 0xff, wLength);
+   s, wValue & 0xff, 

[PATCH v2 2/5] usb:common Separated decoding functions from dwc3 driver.

[Pawel Laszczak]

Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
to driver/usb/common/debug.c file. These moved functions include:
dwc3_decode_get_status
dwc3_decode_set_clear_feature
dwc3_decode_set_address
dwc3_decode_get_set_descriptor
dwc3_decode_get_configuration
dwc3_decode_set_configuration
dwc3_decode_get_intf
dwc3_decode_set_intf
dwc3_decode_synch_frame
dwc3_decode_set_sel
dwc3_decode_set_isoch_delay
dwc3_decode_ctrl

These functions are used also in inroduced cdns3 driver.

All functions prefixes were changed from dwc3 to usb.
Also, function's parameters has been extended according to the name
of fields in standard SETUP packet.
Additionally, patch adds usb_decode_ctrl function to
include/linux/usb/ch9.h file.

mend

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/common/Makefile |   2 +-
 drivers/usb/common/debug.c  | 265 
 drivers/usb/dwc3/debug.h| 243 -
 drivers/usb/dwc3/trace.h|   2 +-
 include/linux/usb/ch9.h |  19 +++
 5 files changed, 286 insertions(+), 245 deletions(-)
 create mode 100644 drivers/usb/common/debug.c

diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index fb4d5ef4165c..3d3d2962ea4b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,7 +4,7 @@
 #
 
 obj-$(CONFIG_USB_COMMON) += usb-common.o
-usb-common-y += common.o
+usb-common-y += common.o debug.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
new file mode 100644
index ..374fb9e94f37
--- /dev/null
+++ b/drivers/usb/common/debug.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Common USB debugging functions
+ *
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Felipe Balbi ,
+ * Sebastian Andrzej Siewior 
+ */
+
+#ifndef __LINUX_USB_COMMON_DEBUG
+#define __LINUX_USB_COMMON_DEBUG
+
+#include 
+
+static void usb_decode_get_status(__u8 bRequestType, __u16 wIndex,
+ __u16 wLength, char *str)
+{
+   switch (bRequestType & USB_RECIP_MASK) {
+   case USB_RECIP_INTERFACE:
+   sprintf(str, "Get Interface Status(Intf = %d, Length = %d)",
+   wIndex, wLength);
+   break;
+   case USB_RECIP_ENDPOINT:
+   sprintf(str, "Get Endpoint Status(ep%d%s)",
+   wIndex & ~USB_DIR_IN,
+   wIndex & USB_DIR_IN ? "in" : "out");
+   break;
+   }
+}
+
+static void usb_decode_set_clear_feature(__u8 bRequestType,
+__u8 bRequest, __u16 wValue,
+__u16 wIndex, char *str)
+{
+   switch (bRequestType & USB_RECIP_MASK) {
+   case USB_RECIP_DEVICE:
+   sprintf(str, "%s Device Feature(%s%s)",
+   bRequest == USB_REQ_CLEAR_FEATURE ? "Clear" : "Set",
+   ({char *s;
+   switch (wValue) {
+   case USB_DEVICE_SELF_POWERED:
+   s = "Self Powered";
+   break;
+   case USB_DEVICE_REMOTE_WAKEUP:
+   s = "Remote Wakeup";
+   break;
+   case USB_DEVICE_TEST_MODE:
+   s = "Test Mode";
+   break;
+   case USB_DEVICE_U1_ENABLE:
+   s = "U1 Enable";
+   break;
+   case USB_DEVICE_U2_ENABLE:
+   s = "U2 Enable";
+   break;
+   case USB_DEVICE_LTM_ENABLE:
+   s = "LTM Enable";
+   break;
+   default:
+   s = "UNKNOWN";
+   } s; }),
+   wValue == USB_DEVICE_TEST_MODE ?
+   ({ char *s;
+   switch (wIndex) {
+   case TEST_J:
+   s = ": TEST_J";
+   break;
+   case TEST_K:
+   s = ": TEST_K";
+   break;
+   case TEST_SE0_NAK:
+   s = ": TEST_SE0_NAK";
+   break;
+   case 

[PATCH v2 3/5] usb:common Patch simplify usb_decode_set_clear_feature function.

[Pawel Laszczak]

Patch adds usb_decode_test_mode and usb_decode_device_feature functions,
which allow to make more readable and simplify the
usb_decode_set_clear_feature function.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/common/debug.c | 83 ++
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
index 374fb9e94f37..77e565a38f29 100644
--- a/drivers/usb/common/debug.c
+++ b/drivers/usb/common/debug.c
@@ -29,6 +29,44 @@ static void usb_decode_get_status(__u8 bRequestType, __u16 
wIndex,
}
 }
 
+static const char *usb_decode_device_feature(u16 wValue)
+{
+   switch (wValue) {
+   case USB_DEVICE_SELF_POWERED:
+   return "Self Powered";
+   case USB_DEVICE_REMOTE_WAKEUP:
+   return "Remote Wakeup";
+   case USB_DEVICE_TEST_MODE:
+   return "Test Mode";
+   case USB_DEVICE_U1_ENABLE:
+   return "U1 Enable";
+   case USB_DEVICE_U2_ENABLE:
+   return "U2 Enable";
+   case USB_DEVICE_LTM_ENABLE:
+   return "LTM Enable";
+   default:
+   return "UNKNOWN";
+   }
+}
+
+static const char *usb_decode_test_mode(u16 wIndex)
+{
+   switch (wIndex) {
+   case TEST_J:
+   return ": TEST_J";
+   case TEST_K:
+   return ": TEST_K";
+   case TEST_SE0_NAK:
+   return ": TEST_SE0_NAK";
+   case TEST_PACKET:
+   return ": TEST_PACKET";
+   case TEST_FORCE_EN:
+   return ": TEST_FORCE_EN";
+   default:
+   return ": UNKNOWN";
+   }
+}
+
 static void usb_decode_set_clear_feature(__u8 bRequestType,
 __u8 bRequest, __u16 wValue,
 __u16 wIndex, char *str)
@@ -37,50 +75,9 @@ static void usb_decode_set_clear_feature(__u8 bRequestType,
case USB_RECIP_DEVICE:
sprintf(str, "%s Device Feature(%s%s)",
bRequest == USB_REQ_CLEAR_FEATURE ? "Clear" : "Set",
-   ({char *s;
-   switch (wValue) {
-   case USB_DEVICE_SELF_POWERED:
-   s = "Self Powered";
-   break;
-   case USB_DEVICE_REMOTE_WAKEUP:
-   s = "Remote Wakeup";
-   break;
-   case USB_DEVICE_TEST_MODE:
-   s = "Test Mode";
-   break;
-   case USB_DEVICE_U1_ENABLE:
-   s = "U1 Enable";
-   break;
-   case USB_DEVICE_U2_ENABLE:
-   s = "U2 Enable";
-   break;
-   case USB_DEVICE_LTM_ENABLE:
-   s = "LTM Enable";
-   break;
-   default:
-   s = "UNKNOWN";
-   } s; }),
+   usb_decode_device_feature(wValue),
wValue == USB_DEVICE_TEST_MODE ?
-   ({ char *s;
-   switch (wIndex) {
-   case TEST_J:
-   s = ": TEST_J";
-   break;
-   case TEST_K:
-   s = ": TEST_K";
-   break;
-   case TEST_SE0_NAK:
-   s = ": TEST_SE0_NAK";
-   break;
-   case TEST_PACKET:
-   s = ": TEST_PACKET";
-   break;
-   case TEST_FORCE_EN:
-   s = ": TEST_FORCE_EN";
-   break;
-   default:
-   s = ": UNKNOWN";
-   } s; }) : "");
+   usb_decode_test_mode(wIndex) : "");
break;
case USB_RECIP_INTERFACE:
sprintf(str, "%s Interface Feature(%s)",
-- 
2.17.1

[PATCH] x86/trace: set TRACE_INCLUDE_PATH instead of include path

[Masahiro Yamada]

Set TRACE_INCLUDE_PATH correctly for exceptions.h and irq_vectors.h
This is consistent with fpu.h, hyperv.h, mpx.h in the same directory.
The ugly include paths will go away.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/include/asm/trace/exceptions.h  | 2 +-
 arch/x86/include/asm/trace/irq_vectors.h | 2 +-
 arch/x86/kernel/Makefile | 2 --
 arch/x86/mm/Makefile | 2 --
 4 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/trace/exceptions.h 
b/arch/x86/include/asm/trace/exceptions.h
index 69615e3..3d1f138 100644
--- a/arch/x86/include/asm/trace/exceptions.h
+++ b/arch/x86/include/asm/trace/exceptions.h
@@ -45,7 +45,7 @@ DEFINE_PAGE_FAULT_EVENT(page_fault_user);
 DEFINE_PAGE_FAULT_EVENT(page_fault_kernel);
 
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH asm/trace/
 #define TRACE_INCLUDE_FILE exceptions
 #endif /*  _TRACE_PAGE_FAULT_H */
 
diff --git a/arch/x86/include/asm/trace/irq_vectors.h 
b/arch/x86/include/asm/trace/irq_vectors.h
index 0af81b5..e38a76e 100644
--- a/arch/x86/include/asm/trace/irq_vectors.h
+++ b/arch/x86/include/asm/trace/irq_vectors.h
@@ -389,7 +389,7 @@ TRACE_EVENT(vector_free_moved,
 #endif /* CONFIG_X86_LOCAL_APIC */
 
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH asm/trace/
 #define TRACE_INCLUDE_FILE irq_vectors
 #endif /*  _TRACE_IRQ_VECTORS_H */
 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index da0b6bc..e581734 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -42,8 +42,6 @@ endif
 # non-deterministic coverage.
 KCOV_INSTRUMENT:= n
 
-CFLAGS_irq.o := -I$(src)/../include/asm/trace
-
 obj-y  := process_$(BITS).o signal.o
 obj-$(CONFIG_COMPAT)   += signal_compat.o
 obj-y  += traps.o idt.o irq.o irq_$(BITS).o dumpstack_$(BITS).o
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 4b101dd..6d474d9 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -21,8 +21,6 @@ CFLAGS_physaddr.o := $(nostackp)
 CFLAGS_setup_nx.o  := $(nostackp)
 CFLAGS_mem_encrypt_identity.o  := $(nostackp)
 
-CFLAGS_fault.o := -I$(src)/../include/asm/trace
-
 obj-$(CONFIG_X86_PAT)  += pat_rbtree.o
 
 obj-$(CONFIG_X86_32)   += pgtable_32.o iomap_32.o
-- 
2.7.4

[PATCH] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw

[Ivan Mironov]

This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):

BUG: unable to handle kernel NULL pointer dereference at 

PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G  I   
4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010:  (null)
Code: Bad RIP value.
RSP: 0018:a47ccdc9fbe0 EFLAGS: 00010246
RAX:  RBX: 03e8 RCX: a47ccdc9fbf8
RDX: a47ccdc9fc00 RSI: 97d9ee7b01f8 RDI: 97d9f0150b80
RBP: 97d9f0150b80 R08:  R09: 
R10:  R11:  R12: 0003
R13: 97d9ef1e53e8 R14: 0009 R15: 97d9f0ac6730
FS:  7f4d224ef700() GS:97d9fa20() 
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: ffd6 CR3: 0011ece52006 CR4: 000206e0
Call Trace:
 ? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
 ? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
 ? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
 ? bnx2x_set_features+0x79/0xa0 [bnx2x]
 ? __netdev_update_features+0x244/0x9e0
 ? netlink_broadcast_filtered+0x136/0x4b0
 ? netdev_update_features+0x22/0x60
 ? dev_disable_lro+0x1c/0xe0
 ? devinet_sysctl_forward+0x1c6/0x211
 ? proc_sys_call_handler+0xab/0x100
 ? __vfs_write+0x36/0x1a0
 ? rcu_read_lock_sched_held+0x79/0x80
 ? rcu_sync_lockdep_assert+0x2e/0x60
 ? __sb_start_write+0x14c/0x1b0
 ? vfs_write+0x159/0x1c0
 ? vfs_write+0xba/0x1c0
 ? ksys_write+0x52/0xc0
 ? do_syscall_64+0x60/0x1f0
 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe

After some investigation I figured out that recently added cleanup code
tries to call VLAN filtering de-initialization function which exist only
for newer hardware. Corresponding function pointer is not
initialized (== 0) for older hardware, namely these chips:

#define CHIP_NUM_57710  0x164e
#define CHIP_NUM_57711  0x164f
#define CHIP_NUM_57711E 0x1650

And I have one of those in my test system:

02:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries 
NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]
02:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries 
NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]

Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to
initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not.

This regression was introduced after v4.20-rc7.

Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload 
sequence.")
Signed-off-by: Ivan Mironov 
---
 .../net/ethernet/broadcom/bnx2x/bnx2x_main.c  | 22 +--
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b164f705709d..0e37c2484ac2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -8504,15 +8504,23 @@ int bnx2x_set_vlan_one(struct bnx2x *bp, u16 vlan,
 static int bnx2x_del_all_vlans(struct bnx2x *bp)
 {
struct bnx2x_vlan_mac_obj *vlan_obj = >sp_objs[0].vlan_obj;
-   unsigned long ramrod_flags = 0, vlan_flags = 0;
struct bnx2x_vlan_entry *vlan;
-   int rc;
 
-   __set_bit(RAMROD_COMP_WAIT, _flags);
-   __set_bit(BNX2X_VLAN, _flags);
-   rc = vlan_obj->delete_all(bp, vlan_obj, _flags, _flags);
-   if (rc)
-   return rc;
+   /* The whole *vlan_obj structure may be not initialized if VLAN
+* filtering offload is not supported by hardware. Currently this is
+* true for all hardware covered by CHIP_IS_E1x().
+*/
+   if (vlan_obj->delete_all) {
+   unsigned long ramrod_flags = 0, vlan_flags = 0;
+   int rc;
+
+   __set_bit(RAMROD_COMP_WAIT, _flags);
+   __set_bit(BNX2X_VLAN, _flags);
+   rc = vlan_obj->delete_all(bp, vlan_obj, _flags,
+ _flags);
+   if (rc)
+   return rc;
+   }
 
/* Mark that hw forgot all entries */
list_for_each_entry(vlan, >vlan_reg, link)
-- 
2.20.1

[RESNED] mfd: convert to DEFINE_SHOW_ATTRIBUTE

[Yangtao Li]

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
Acked-for-MFD-by: Lee Jones 
Acked-by: Linus Walleij 
---
 drivers/mfd/ab3100-core.c | 15 ++-
 drivers/mfd/ab3100-otp.c  | 16 +++-
 drivers/mfd/tps65010.c| 14 ++
 3 files changed, 7 insertions(+), 38 deletions(-)

diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 099635bed188..3fe448a29389 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -451,7 +451,7 @@ static irqreturn_t ab3100_irq_handler(int irq, void *data)
 /*
  * Some debugfs entries only exposed if we're using debug
  */
-static int ab3100_registers_print(struct seq_file *s, void *p)
+static int ab3100_registers_show(struct seq_file *s, void *p)
 {
struct ab3100 *ab3100 = s->private;
u8 value;
@@ -466,18 +466,7 @@ static int ab3100_registers_print(struct seq_file *s, void 
*p)
return 0;
 }
 
-static int ab3100_registers_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, ab3100_registers_print, inode->i_private);
-}
-
-static const struct file_operations ab3100_registers_fops = {
-   .open = ab3100_registers_open,
-   .read = seq_read,
-   .llseek = seq_lseek,
-   .release = single_release,
-   .owner = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRIBUTE(ab3100_registers);
 
 struct ab3100_get_set_reg_priv {
struct ab3100 *ab3100;
diff --git a/drivers/mfd/ab3100-otp.c b/drivers/mfd/ab3100-otp.c
index 55b207a4b336..24873e1ae865 100644
--- a/drivers/mfd/ab3100-otp.c
+++ b/drivers/mfd/ab3100-otp.c
@@ -96,7 +96,7 @@ static int __init ab3100_otp_read(struct ab3100_otp *otp)
  * the contents of the OTP.
  */
 #ifdef CONFIG_DEBUG_FS
-static int ab3100_show_otp(struct seq_file *s, void *v)
+static int ab3100_otp_show(struct seq_file *s, void *v)
 {
struct ab3100_otp *otp = s->private;
 
@@ -110,24 +110,14 @@ static int ab3100_show_otp(struct seq_file *s, void *v)
return 0;
 }
 
-static int ab3100_otp_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, ab3100_show_otp, inode->i_private);
-}
-
-static const struct file_operations ab3100_otp_operations = {
-   .open   = ab3100_otp_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ab3100_otp);
 
 static int __init ab3100_otp_init_debugfs(struct device *dev,
  struct ab3100_otp *otp)
 {
otp->debugfs = debugfs_create_file("ab3100_otp", S_IFREG | S_IRUGO,
   NULL, otp,
-  _otp_operations);
+  _otp_fops);
if (!otp->debugfs) {
dev_err(dev, "AB3100 debugfs OTP file registration failed!\n");
return -ENOENT;
diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index 2ab67386b4ef..4202b5c40f18 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -192,7 +192,7 @@ static inline void show_chgconfig(int por, const char 
*label, u8 chgconfig) { }
 
 #ifdef CONFIG_DEBUG_FS
 
-static int dbg_show(struct seq_file *s, void *_)
+static int debug_show(struct seq_file *s, void *_)
 {
struct tps65010 *tps = s->private;
u8  value, v2;
@@ -296,17 +296,7 @@ static int dbg_show(struct seq_file *s, void *_)
return 0;
 }
 
-static int dbg_tps_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, dbg_show, inode->i_private);
-}
-
-static const struct file_operations debug_fops = {
-   .open   = dbg_tps_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(debug);
 
 #defineDEBUG_FOPS  _fops
 
-- 
2.17.0

Re: [PATCH] dma-buf: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Frank Lee]

ping..

Re: [PATCH] scsi: convert to DEFINE_SHOW_ATTRIBUTE

[Frank Lee]

ping..

Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver

[Tony Lindgren]

* Pavel Machek  [181223 11:11]:
> I added some printks to motmdm_probe, and they don't appear to be
> called. I wonder if I'm missing something else in the config? I do
> have serial
> 
> root@devuan:/my/ko# ls -al /dev/ttyS0
> crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0
> 
> but not gsm multiplex:
> 
> root@devuan:/my/ko# ls -al /dev/gsm*
> ls: cannot access '/dev/gsm*': No such file or directory

Hmm with serdev you should not get /dev/ttyS0, so maybe you're missing:

CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

Probably the Kconfig dependency should be for SERIAL_DEV_CTRL_TTYPORT
instead of SERIAL_DEV_BUS in these patches if that helps.

Or else you're missing the serdev related dts changes?

Regards,

Tony

Re: [PATCH 12/14] media: wl128x-radio: move from TI_ST to hci_ll driver

[Marcel Holtmann]

Hi Sebastian,

> This updates the wl128x-radio driver to be used with hci_ll
> instead of the deprecated TI_ST driver.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> drivers/bluetooth/hci_ll.c| 115 --
> drivers/media/radio/wl128x/Kconfig|   2 +-
> drivers/media/radio/wl128x/fmdrv.h|   1 +
> drivers/media/radio/wl128x/fmdrv_common.c | 101 ++-
> include/linux/ti_wilink_st.h  |   2 +
> 5 files changed, 117 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 3e767f245ed5..6bcba57e9c9c 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -49,6 +49,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> #include 
> @@ -62,6 +63,7 @@
> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE   0xff36
> 
> /* HCILL commands */
> +#define HCILL_FM_RADIO   0x08
> #define HCILL_GO_TO_SLEEP_IND 0x30
> #define HCILL_GO_TO_SLEEP_ACK 0x31
> #define HCILL_WAKE_UP_IND 0x32
> @@ -81,6 +83,10 @@ struct ll_device {
>   struct gpio_desc *enable_gpio;
>   struct clk *ext_clk;
>   bdaddr_t bdaddr;
> +
> + struct platform_device *fmdev;
> + void (*fm_handler) (void *, struct sk_buff *);
> + void *fm_drvdata;
> };
> 
> struct ll_struct {
> @@ -161,6 +167,35 @@ static int ll_flush(struct hci_uart *hu)
>   return 0;
> }
> 
> +static int ll_register_fm(struct ll_device *lldev)
> +{
> + struct device *dev = >serdev->dev;
> + int err;
> +
> + if (!of_device_is_compatible(dev->of_node, "ti,wl1281-st") &&
> + !of_device_is_compatible(dev->of_node, "ti,wl1283-st") &&
> + !of_device_is_compatible(dev->of_node, "ti,wl1285-st"))
> + return -ENODEV;

do we really want to hardcode this here? Isn't there some HCI vendor command or 
some better DT description that we can use to decide when to register this 
platform device.

> +
> + lldev->fmdev = platform_device_register_data(dev, "wl128x-fm",
> + PLATFORM_DEVID_AUTO, NULL, 0);

Fix the indentation please to following networking coding style.

> + err = PTR_ERR_OR_ZERO(lldev->fmdev);
> + if (err) {
> + dev_warn(dev, "cannot register FM radio subdevice: %d\n", err);
> + lldev->fmdev = NULL;
> + }
> +
> + return err;
> +}
> +
> +static void ll_unregister_fm(struct ll_device *lldev)
> +{
> + if (!lldev->fmdev)
> + return;
> + platform_device_unregister(lldev->fmdev);
> + lldev->fmdev = NULL;
> +}
> +
> /* Close protocol */
> static int ll_close(struct hci_uart *hu)
> {
> @@ -178,6 +213,8 @@ static int ll_close(struct hci_uart *hu)
>   gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> 
>   clk_disable_unprepare(lldev->ext_clk);
> +
> + ll_unregister_fm(lldev);
>   }
> 
>   hu->priv = NULL;
> @@ -313,18 +350,11 @@ static void ll_device_woke_up(struct hci_uart *hu)
>   hci_uart_tx_wakeup(hu);
> }
> 
> -/* Enqueue frame for transmittion (padding, crc, etc) */
> -/* may be called from two simultaneous tasklets */
> -static int ll_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> +static int ll_enqueue_prefixed(struct hci_uart *hu, struct sk_buff *skb)
> {
>   unsigned long flags = 0;
>   struct ll_struct *ll = hu->priv;
> 
> - BT_DBG("hu %p skb %p", hu, skb);
> -
> - /* Prepend skb with frame type */
> - memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> -
>   /* lock hcill state */
>   spin_lock_irqsave(>hcill_lock, flags);
> 
> @@ -361,6 +391,18 @@ static int ll_enqueue(struct hci_uart *hu, struct 
> sk_buff *skb)
>   return 0;
> }
> 
> +/* Enqueue frame for transmittion (padding, crc, etc) */
> +/* may be called from two simultaneous tasklets */
> +static int ll_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> +{
> + BT_DBG("hu %p skb %p", hu, skb);
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> +
> + return ll_enqueue_prefixed(hu, skb);
> +}
> +
> static int ll_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
>   struct hci_uart *hu = hci_get_drvdata(hdev);
> @@ -390,6 +432,32 @@ static int ll_recv_frame(struct hci_dev *hdev, struct 
> sk_buff *skb)
>   return 0;
> }
> 
> +static int ll_recv_radio(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct hci_uart *hu = hci_get_drvdata(hdev);
> + struct serdev_device *serdev = hu->serdev;
> + struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> +
> + if (!lldev->fm_handler) {
> + kfree_skb(skb);
> + return -EINVAL;
> + }
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> +
> + lldev->fm_handler(lldev->fm_drvdata, skb);

So I have no idea why we bother adding the frame type here. What is the 
purpose. I think this is useless and we 

Reason for RedHat purchase 30 pct over market cap (and some thoughts on Bradly Kuhn's recent public denouncement of RMS)

[visionsofalice]

Redhat has achieved "governance" over the Linux(TM), via systemd and the 
Code of Conduct.


You, contributors, are now treated as employees.

They are confident that you will not assert your property rights, since 
you attack those who do (See: Netfiter saga), and take it as an honour 
to sign documents pledging that you will not assert your property rights 
(prepared for you by your now-masters).


They know that you are psychologically bound to behave as hirelings - 
servants, and not as property owners.


Thus they can rest easy knowing the ground is, though made of sand, not 
in seeming danger of a tempest.


Because of you.
Because of your history of supplication.
Your enuich-like nature.

A nice example is Bradly Kuhn's recent blog posts 1) Excoriating RMS and 
2) showing how he himself is submissive to a woman he hired.


He's even angry that others still treat him with respect rather than 
transferring all the good will to the female figurehead everyone is 
supposed to now respect (for what reason? No, being an actual programmer 
is not required: sufficent is being a member of the "better" species 
that rules over the males under the anglo-american system that Bradly 
Kuhn and his kind uphold )


If I were them I would never donate another cent to the SFConservancy, 
and I would seek a claw-back of the funds that I did donate for improper 
use (yes this is possible under both California and New York law). 
Especially since they seem to have no in-house lawyers what-so-ever (so 
what is their purpose?).


We are supposed to be proud that his mind is as innocent as his visage 
(perhaps why he had to hire outside counsel to give him an incorrect and 
abundantly couched opinion)



[1] 
http://ebb.org/bkuhn/blog/2018/11/22/gnu-kind-communication-guidelines.html

[2] http://ebb.org/bkuhn/blog/2018/06/21/everyday-sexism.html

The CoC regime is a License violation - Additional restrictive terms

[visionsofalice]

Version 2 of the GPL forbids the incorporation of additional
restrictive terms, relating to the distribution, modification, etc of
the article licensed under the terms.

Those that violate this section are declared, by operation of the
terms, to have their grant automatically revoked.

An additional term need-not be present in the same writing. Such terms
simply need to be present to or made known to the taker(sub-licensee) by
the distributor. They may be proffered in writing, orally, or
implied in the course of doing business dealings. They simply must
relate back or involve the article in question (the licensed code or
product.)

The proffering of additional restrictive terms is a violation of the
text of the license grant in and of itself.

Here we have a situation where an additional writing has been
proffered. The additional writing promises both in it's own text and
by implication consequences against those who violate the terms of
this additional writing.

The additional writing restricts those subject to it from expressing
certain views publicly - promising retribution against those who do.

No consideration is paid to those subject to the additional writing
for their assent; it is simply imposed unilaterally against the
subjects.

The violators of the additional writing are promised:
Additional, unwanted, public scrutiny (to which they were not subject
to prior)
Public ridicule.
Loss of public standing.
as-well as an implied loss of future income.

These are the enforcement mechanisms of the additional writing to
enforce its restrictions against those who publish derivative works of
the kernel.

The additional writing is activated when (with the prerequisite of
being a derivative work of the linux kernel) the work of a rights-holder
is incorporated into the kernel, when such a work is made known to the
kernel-team to exist where any one person on this earth has seen fit
to present it for inclusion, or by simple prior-inclusion into the
kernel.

Thus all current and past rights-holders who have code in, or have
published for distribution, derivative works of the kernel are subject
to the retributive promises made to them in the additional writing,
drafted to restrict their actions and utterances.

This is tantamount to an additional restrictive term regarding the
modification and distribution of works under the linux kernel license
grant.

It is a violation of the license terms of the rights-holders past
incorporated works in much the same way that GRSecurity's
Contributor Access Agreement was and is.

2 months and no response from Eben Moglen - Yes you can rescind your grant.

[visionsofalice]

It has been 2 months. Eben Moglen has published no research.

Because there is nothing more to say: The GPLv2, as used by linux, is a 
bare license. It can be rescinded at the will of the grantor.


The regime that the FSF used, vis-a-vis the GPLv2, is essential: 
copyright transfers to a central repository entity that is sure not to 
rescind.


Linus chose not to adopt this regime.
He benefited by greatly increased developer contribution.
The price for that windfall was and is the retention of their 
traditional property rights by the property holders.


They can rescind at will.
They made no promise nor utterance to the contrary that can be relied 
upon.

They were paid no consideration.
There was no meeting of the minds.

Additionally the CoC regime itself is a license terms violation, being 
an additional restrictive term, as explained in the other analysis. 
(Similar to the GRSecurity license violation)


On 2018-10-26 18:31, Eben Moglen wrote:

On Friday, 26 October 2018, visionsofal...@redchan.it wrote:

  You are conflating case law dealing with commercial software and
  non-gratuitous licenses with the present situation, which would 
likely

  be a case of first-impression in nearly any jurisdiction.

I think the best procedure would be for me to publish my analysis and
for you then to tell me what is wrong with it.  What you say here
sounds like what a lawyer might say, but isn't.  I have been teaching
this stuff for about thirty years, so if I am conflating or confusing
anything I will be grateful for help in seeing my mistake.

  The rule for gratuitous licenses is that they are revocable at the 
will

  of the grantor.

That's not actually "the rule."  It sounds like it might be the rule,
but it so happens that it's not.  When I have given the explanation as
I have learned, taught and depended on it, you will be able to show me
what I am wrong about.

  Raymond Nimmer (God rest his soul) was in agreement on this point,
  vis-a-vis the GPL and similar licenses.

You have your Nimmers confused.  The primary author of the treatise
Nimmer on Copyright (a book about the law, not in itself an authority)
was Melville Nimmer.  The treatise is continued by his son, David, a
fine lawyer with whom I do from time to time politely disagree about
something.  Ray Nimmer is quite another person.

Eben

Re: [PATCH] MIPS: math-emu: Write-protect delay slot emulation pages

[Paul Burton]

Hello,

Paul Burton wrote:
> Mapping the delay slot emulation page as both writeable & executable
> presents a security risk, in that if an exploit can write to & jump into
> the page then it can be used as an easy way to execute arbitrary code.
> 
> Prevent this by mapping the page read-only for userland, and using
> access_process_vm() with the FOLL_FORCE flag to write to it from
> mips_dsemul().
> 
> This will likely be less efficient due to copy_to_user_page() performing
> cache maintenance on a whole page, rather than a single line as in the
> previous use of flush_cache_sigtramp(). However this delay slot
> emulation code ought not to be running in any performance critical paths
> anyway so this isn't really a problem, and we can probably do better in
> copy_to_user_page() anyway in future.
> 
> A major advantage of this approach is that the fix is small & simple to
> backport to stable kernels.
> 
> Reported-by: Andy Lutomirski 
> Signed-off-by: Paul Burton 
> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 
> instructions")
> Cc: sta...@vger.kernel.org # v4.8+

Applied to mips-fixes.

Thanks,
Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.bur...@mips.com to report it. ]

Yes: The linux devs can rescind their license grant.

[visionsofalice]

Your new explanation was refuted 5 hours after it was published.

---

Yes they can, greg.

The GPL v2, is a bare license. It is not a contract. It lacks 
consideration between the licensee and the grantor.


(IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen 
to bestow a benefit upon them where they suffer no detriment and you, in 
fact, gain no bargained-for benefit)


As a bare license, (read: property license), the standard rules 
regarding the alienation of property apply.


Therein: a gratuitous license is revocable at the will of the grantor.

The licensee then may ATTEMPT, as an affirmative defense against your 
as-of-right action to claim promissory estoppel in state court, and 
"keep you to your word". However you made no such promise disclaiming 
your right to rescind the license.


Remeber: There is no utterance disclaiming this right within the GPL 
version 2. Linus, furthermore, has chosen both to exclude the "or any 
later version" codicil, to reject the GPL version 3, AND to publicly 
savage GPL version 3 (he surely has his reasons, perhaps this is one of 
them, left unstated). (GPLv3 which has such promises listed (not to say 
that they would be effective against the grantor, but it is an attempt 
at the least)).





The Software Freedom Conservancy has attempted to mis-construe clause 4 
of the GPL version 2 as a "no-revocation by grantor" clause.


However, reading said clause, using plain construction, leads a 
reasonable person to understand that said clause is speaking 
specifically about the situation where an upstream licensee loses their 
permission under the terms due to a violation of the terms; in that case 
the down-stream licensee does not in-turn also lose their permission 
under the terms.


Additionally, clause 0 makes it crystal clear that "You" is defined as 
the licensee, not the grantor. Another issue the SFConservancy's public 
service announcement chooses to ignore.


Thirdly, the SFConservancy banks on the ignorance of both the public and 
the developers regarding property alienation. A license does not impinge 
the rights of the party granting the license in a quid-pro-quo manner 
vis a vis the licensee's taking. A license merely grants permission, 
extended from the grantor, to the licensee, regarding the article of 
property that is being impinged. A license is NOT a full nor is it a 
permanent alienation of the article(property) in question. The impinged 
property, being under a non bargained-for temporary grant, can be taken 
back into the sole dominion of the owner - at his election to do so.




Now as to the 9th circuit appellate court's decision in Jacobsen v. 
Katzer . While the court waxes eloquently about opensource licenses, 
even mentioning the word "consideration" in it's long dicta, when it 
comes time to make the binding decision the court found that the lower 
(district) court was in _ERROR_ regarding the application of 
contract-law principals to the Artistic License, regarding the case, and 
instructed the lower court to instead construe said license as a 
Copyright License.


The SFConservancy, and Bruce Perens have chosen to:
1) Rely on the dicta. (non-binding - "some things could be contracts - 
opensource is great")
2) Ignore the actual ruling. (Binding - Copyright License - Not 
Contract)

3) Ignore that this case was about the AL, not the GPLv2
4) Ignore the existence of different jurisdictions.
(Why file in the roll-the-dice 9th district if you can file in a 
district that has personal-juristicion over the defendant and is much 
more consistent in it's rulings?)
5) Ignore all established law regard property licensing, contract 
formation, meeting of the minds, what consideration is etc.


Which is not surprising considering the desire of people like Bruce 
Perens is to rob MEN of EVERY benefit of their Labour and every speck of 
happiness in life and to transfer those benefits to WOMEN and those who 
support women.


(This is why people who are like Bruce Perens, the SFConservancy 
menbers, and the CoC supporters, banned men from taking female children 
as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - 
verse 28 (na'ar (LXX: padia)), and continue to uphold that ban 
world-wide, and seek to destroy ALL cultures that do no bend to their 
will who are not idolators of Women)





Look, you may love your users, you may love the people who edit your 
code in their home or office; but the fact of the matter is...


They have done nothing for you, they have promised nothing to you. They 
CANNOT hold YOU.


You have the right to rescind at any time, and remove your work from any 
future versions of Linux. And you might consider doing so if YOU are 
done harm.


Don't let the insatiable, never-satisfied, public fool you into thinking 
otherwise.


And, yes, I am a lawyer.
And, no, unlike the SFConservancy, I did not have to call upon outside 
counsel to analyze the fact pattern. (And even then all they 

Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST

[Tony Lindgren]

* Sebastian Reichel  [181222 02:48]:
> On Fri, Dec 21, 2018 at 10:02:05AM -0800, Tony Lindgren wrote:
> > Hmm so looks like nothing to configure for the clocks or
> > CPCAP_BIT_ST_L_TIMESLOT bits for cap for the EXT? So the
> > wl12xx audio is wired directly to cpcap EXT then and not a
> > TDM slot on the mcbsp huh?
> 
> For FM radio it's directly wired to EXT with no DAI being required.
> I think that EXT is only used by FM radio and not by bluetooth. BT
> seems to use TDM.

OK then it sounds like we just need a diff -u of the cpcap regs
from Android with cpcaprw --all before and after using a bluetooth
headset during a voice call to configure it for voice calls for the
TDM. I think snd-soc-motmd just needs the voice output specified
in the mixer in addition to the cpcap configuration.

I don't think have any bluetooth audio gear though, maybe somebody
using a headset can post the diff.

Regards,

Tony