Re: [PATCH 0/6] mm: make movable onlining suck less

[Michal Hocko]

On Wed 05-04-17 09:53:05, Reza Arbab wrote:
[...]
> I hope this made sense. :/

yes it certainly helped me to make some picture of your setup. I will
keep thinking about that. But one thing that is really bugging me is
how could you see low pfns in the previous oops. Please drop the last
patch and sprinkle printks down the remove_memory path to see where this
all go south. I believe that there is something in the initialization
code lurking in my code. Please also scratch the pfn_valid check in
online_pages diff. It will not help here.

I suspect I broke some hidden expectation that made add_memory vs.
remove_memory more symetric before. I will keep digging.
-- 
Michal Hocko
SUSE Labs

[PATCH v6 06/23] Documentation: PCI: Add specification for the *PCI test* function device

[Kishon Vijay Abraham I]

Add specification for the *PCI test* virtual function device. The endpoint
function driver and the host PCI driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
---
 Documentation/PCI/00-INDEX   |  2 +
 Documentation/PCI/endpoint/pci-test-function.txt | 66 
 2 files changed, 68 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-function.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index bf8223a1bf08..ab35e4bbdb1c 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -16,3 +16,5 @@ endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
 endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the PCI endpoint function.
+endpoint/pci-test-function.txt
+   - specification of *PCI test* function device.
diff --git a/Documentation/PCI/endpoint/pci-test-function.txt 
b/Documentation/PCI/endpoint/pci-test-function.txt
new file mode 100644
index ..0c519c9bf94a
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -0,0 +1,66 @@
+   PCI TEST
+   Kishon Vijay Abraham I 
+
+Traditionally PCI RC has always been validated by using standard
+PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
+However with the addition of EP-core in linux kernel, it is possible
+to configure a PCI controller that can operate in EP mode to work as
+a test device.
+
+The PCI endpoint test device is a virtual device (defined in software)
+used to test the endpoint functionality and serve as a sample driver
+for other PCI endpoint devices (to use the EP framework).
+
+The PCI endpoint test device has the following registers:
+
+   1) PCI_ENDPOINT_TEST_MAGIC
+   2) PCI_ENDPOINT_TEST_COMMAND
+   3) PCI_ENDPOINT_TEST_STATUS
+   4) PCI_ENDPOINT_TEST_SRC_ADDR
+   5) PCI_ENDPOINT_TEST_DST_ADDR
+   6) PCI_ENDPOINT_TEST_SIZE
+   7) PCI_ENDPOINT_TEST_CHECKSUM
+
+*) PCI_ENDPOINT_TEST_MAGIC
+
+This register will be used to test BAR0. A known pattern will be written
+and read back from MAGIC register to verify BAR0.
+
+*) PCI_ENDPOINT_TEST_COMMAND:
+
+This register will be used by the host driver to indicate the function
+that the endpoint device must perform.
+
+Bitfield Description:
+  Bit 0: raise legacy IRQ
+  Bit 1: raise MSI IRQ
+  Bit 2 - 7: MSI interrupt number
+  Bit 8: read command (read data from RC buffer)
+  Bit 9: write command (write data to RC buffer)
+  Bit 10   : copy command (copy data from one RC buffer to another
+ RC buffer)
+
+*) PCI_ENDPOINT_TEST_STATUS
+
+This register reflects the status of the PCI endpoint device.
+
+Bitfield Description:
+  Bit 0: read success
+  Bit 1: read fail
+  Bit 2: write success
+  Bit 3: write fail
+  Bit 4: copy success
+  Bit 5: copy fail
+  Bit 6: IRQ raised
+  Bit 7: source address is invalid
+  Bit 8: destination address is invalid
+
+*) PCI_ENDPOINT_TEST_SRC_ADDR
+
+This register contains the source address (RC buffer address) for the
+COPY/READ command.
+
+*) PCI_ENDPOINT_TEST_DST_ADDR
+
+This register contains the destination address (RC buffer address) for
+the COPY/WRITE command.
-- 
2.11.0

[PATCH v6 15/23] dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access

[Kishon Vijay Abraham I]

Update device tree binding documentation of TI's dra7xx PCI controller to
include property for enabling unaligned mem access.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Rob Herring 
Signed-off-by: Bjorn Helgaas 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60c3cccefabc..6a07c96227e0 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -39,6 +39,11 @@ DEVICE MODE
  - interrupts : one interrupt entries must be specified for main interrupt.
  - num-ib-windows : number of inbound address translation windows
  - num-ob-windows : number of outbound address translation windows
+ - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
+  should contain the register offset within syscon
+  and the 2nd argument should contain the bit field
+  for setting the bit to enable unaligned
+  access.
 
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
-- 
2.11.0

[PATCH v1 4/5] platform/x86: intel_scu_ipc: Introduce SCU_DEVICE() macro

[Andy Shevchenko]

For better maintainability and readability introduce a macro
for device ID table.

No functional change intended.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_scu_ipc.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/platform/x86/intel_scu_ipc.c 
b/drivers/platform/x86/intel_scu_ipc.c
index 6d626a8878c7..f9d3eb505a0b 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -609,22 +609,14 @@ static int ipc_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
return 0;
 }
 
+#define SCU_DEVICE(id, pdata)  {PCI_VDEVICE(INTEL, id), (kernel_ulong_t)}
+
 static const struct pci_device_id pci_ids[] = {
-   {
-   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_LINCROFT),
-   (kernel_ulong_t)_scu_ipc_lincroft_pdata,
-   }, {
-   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL),
-   (kernel_ulong_t)_scu_ipc_penwell_pdata,
-   }, {
-   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_CLOVERVIEW),
-   (kernel_ulong_t)_scu_ipc_penwell_pdata,
-   }, {
-   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER),
-   (kernel_ulong_t)_scu_ipc_tangier_pdata,
-   }, {
-   0,
-   }
+   SCU_DEVICE(PCI_DEVICE_ID_LINCROFT,  intel_scu_ipc_lincroft_pdata),
+   SCU_DEVICE(PCI_DEVICE_ID_PENWELL,   intel_scu_ipc_penwell_pdata),
+   SCU_DEVICE(PCI_DEVICE_ID_CLOVERVIEW,intel_scu_ipc_penwell_pdata),
+   SCU_DEVICE(PCI_DEVICE_ID_TANGIER,   intel_scu_ipc_tangier_pdata),
+   {}
 };
 
 static struct pci_driver ipc_driver = {
-- 
2.11.0

[PATCH v1 5/5] platform/x86: intel_scu_ipc: Introduce intel_scu_ipc_raw_command()

[Andy Shevchenko]

A new call to SCU intel_scu_ipc_raw_command() writes SPTR and DPTR
registers before sending a command.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/include/asm/intel_scu_ipc.h |  8 -
 drivers/platform/x86/intel_scu_ipc.c | 63 
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/intel_scu_ipc.h 
b/arch/x86/include/asm/intel_scu_ipc.h
index 4fb1d0abef95..81d3d8776fd9 100644
--- a/arch/x86/include/asm/intel_scu_ipc.h
+++ b/arch/x86/include/asm/intel_scu_ipc.h
@@ -3,6 +3,9 @@
 
 #include 
 
+#define IPCMSG_INDIRECT_READ   0x02
+#define IPCMSG_INDIRECT_WRITE  0x05
+
 #define IPCMSG_COLD_OFF0x80/* Only for Tangier */
 
 #define IPCMSG_WARM_RESET  0xF0
@@ -45,7 +48,10 @@ int intel_scu_ipc_update_register(u16 addr, u8 data, u8 
mask);
 /* Issue commands to the SCU with or without data */
 int intel_scu_ipc_simple_command(int cmd, int sub);
 int intel_scu_ipc_command(int cmd, int sub, u32 *in, int inlen,
-   u32 *out, int outlen);
+ u32 *out, int outlen);
+int intel_scu_ipc_raw_command(int cmd, int sub, u8 *in, int inlen,
+ u32 *out, int outlen, u32 dptr, u32 sptr);
+
 /* I2C control api */
 int intel_scu_ipc_i2c_cntrl(u32 addr, u32 *data);
 
diff --git a/drivers/platform/x86/intel_scu_ipc.c 
b/drivers/platform/x86/intel_scu_ipc.c
index f9d3eb505a0b..f7cf981502cd 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -491,6 +491,69 @@ int intel_scu_ipc_command(int cmd, int sub, u32 *in, int 
inlen,
 }
 EXPORT_SYMBOL(intel_scu_ipc_command);
 
+#define IPC_SPTR   0x08
+#define IPC_DPTR   0x0C
+
+/**
+ * intel_scu_ipc_raw_command() - IPC command with data and pointers
+ * @cmd:   IPC command code.
+ * @sub:   IPC command sub type.
+ * @in:input data of this IPC command.
+ * @inlen: input data length in dwords.
+ * @out:   output data of this IPC command.
+ * @outlen:output data length in dwords.
+ * @sptr:  data writing to SPTR register.
+ * @dptr:  data writing to DPTR register.
+ *
+ * Send an IPC command to SCU with input/output data and source/dest pointers.
+ *
+ * Return: an IPC error code or 0 on success.
+ */
+int intel_scu_ipc_raw_command(int cmd, int sub, u8 *in, int inlen,
+ u32 *out, int outlen, u32 dptr, u32 sptr)
+{
+   struct intel_scu_ipc_dev *scu = 
+   int inbuflen = DIV_ROUND_UP(inlen, 4);
+   u32 inbuf[4];
+   int i, err;
+
+   /* Up to 16 bytes */
+   if (inbuflen > 4)
+   return -EINVAL;
+
+   mutex_lock();
+   if (scu->dev == NULL) {
+   mutex_unlock();
+   return -ENODEV;
+   }
+
+   writel(dptr, scu->ipc_base + IPC_DPTR);
+   writel(sptr, scu->ipc_base + IPC_SPTR);
+
+   /*
+* SRAM controller doesn't support 8-bit writes, it only
+* supports 32-bit writes, so we have to copy input data into
+* the temporary buffer, and SCU FW will use the inlen to
+* determine the actual input data length in the temporary
+* buffer.
+*/
+   memcpy(inbuf, in, inlen);
+
+   for (i = 0; i < inbuflen; i++)
+   ipc_data_writel(scu, inbuf[i], 4 * i);
+
+   ipc_command(scu, (inlen << 16) | (sub << 12) | cmd);
+   err = intel_scu_ipc_check_status(scu);
+   if (!err) {
+   for (i = 0; i < outlen; i++)
+   *out++ = ipc_data_readl(scu, 4 * i);
+   }
+
+   mutex_unlock();
+   return err;
+}
+EXPORT_SYMBOL_GPL(intel_scu_ipc_raw_command);
+
 /* I2C commands */
 #define IPC_I2C_WRITE 1 /* I2C Write command */
 #define IPC_I2C_READ  2 /* I2C Read command */
-- 
2.11.0

[PATCH v1 1/5] platform/x86: intel_scu_ipc: Platform data is mandatory

[Andy Shevchenko]

Fail ->probe() if there is no platform data supplied.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_scu_ipc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/intel_scu_ipc.c 
b/drivers/platform/x86/intel_scu_ipc.c
index e81daff65f62..d789fe1baf17 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -579,6 +579,8 @@ static int ipc_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
return -EBUSY;
 
pdata = (struct intel_scu_ipc_pdata_t *)id->driver_data;
+   if (!pdata)
+   return -ENODEV;
 
scu->dev = >dev;
scu->irq_mode = pdata->irq_mode;
-- 
2.11.0

[PATCH v1 2/5] platform/x86: intel_scu_ipc: Rearrange init sequence

[Andy Shevchenko]

Device pointer is used as a flag that everything is prepared.
Nevertheless the assignment happened quite before and there is a window
when a caller can get weird results or even crashes since not all fields
are initialized yet.

Rearrange initialization sequence in ->probe() to prepare everything
before use.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_scu_ipc.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/intel_scu_ipc.c 
b/drivers/platform/x86/intel_scu_ipc.c
index d789fe1baf17..8a34c1e7536f 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -582,7 +582,6 @@ static int ipc_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
if (!pdata)
return -ENODEV;
 
-   scu->dev = >dev;
scu->irq_mode = pdata->irq_mode;
 
err = pcim_enable_device(pdev);
@@ -595,17 +594,20 @@ static int ipc_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
init_completion(>cmd_complete);
 
-   err = devm_request_irq(>dev, pdev->irq, ioc, 0, "intel_scu_ipc",
-  scu);
-   if (err)
-   return err;
-
scu->ipc_base = pcim_iomap_table(pdev)[0];
 
scu->i2c_base = ioremap_nocache(pdata->i2c_base, pdata->i2c_len);
if (!scu->i2c_base)
return -ENOMEM;
 
+   err = devm_request_irq(>dev, pdev->irq, ioc, 0, "intel_scu_ipc",
+  scu);
+   if (err)
+   return err;
+
+   /* Assign device at last */
+   scu->dev = >dev;
+
intel_scu_devices_create();
 
pci_set_drvdata(pdev, scu);
-- 
2.11.0

Re: [RFC][PATCH v2 5/5] signal: Don't allow accessing signal_struct by old threads after exec

[Oleg Nesterov]

On 04/02, Eric W. Biederman wrote:
>
> Add exec_id to signal_struct and compare it at a few choice moments.

I really dislike this change no matter what, sorry.

Firstly, task_struct->*_exec_id should simply die (I already have the
patch), or at least they should be moved into signal_struct simply
because this is per-process thing.

> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -995,6 +995,10 @@ static int __send_signal(int sig, struct siginfo *info, 
> struct task_struct *t,
>   from_ancestor_ns || (info == SEND_SIG_FORCED)))
>   goto ret;
>
> + /* Don't allow thread group signals after exec */
> + if (group && (t->signal->exec_id != t->self_exec_id))
> + goto ret;

Hmm. Either we do not need this exec_id check at all, or we should not
take "group" into account; a fatal signal (say SIGKILL) will kill the
whole thread-group.

> @@ -1247,7 +1251,8 @@ struct sighand_struct *__lock_task_sighand(struct 
> task_struct *tsk,
>* must see ->sighand == NULL.
>*/
>   spin_lock(>siglock);
> - if (likely(sighand == tsk->sighand)) {
> + if (likely((sighand == tsk->sighand) &&
> +(tsk->self_exec_id == tsk->signal->exec_id))) {

Oh, this doesn't look good to me. Yes, with your approach we probably need
this to, say, ensure that posix-cpu-timer can't kill the process after exec,
but I'd rather add the exit_state check into run_posix_timers().

But OK, suppose that we fix the problems with signal-after-exec.


Now lets fix another problem. A mt exec suceeds and apllication does
sys_seccomp(SECCOMP_FILTER_FLAG_TSYNC) which fails because it finds
another (zombie) SECCOMP_MODE_FILTER thread.

And after we fix this problem, what else we will need to fix?


I really think that - whatever we do - there should be no other threads
after exec, even zombies.

Oleg.

Re: [PATCH 1/3] dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 8:58 PM, Kishon Vijay Abraham I  wrote:
>
>
> On Wednesday 05 April 2017 06:20 PM, Icenowy Zheng wrote:
>> From: Icenowy Zheng 
>>
>> Allwinner H3/V3s/A64 SoCs have a special USB PHY0 that can route to two
>> controllers: one is MUSB and the other is a EHCI/OHCI pair.
>>
>> When it's routed to EHCI/OHCI pair, it will needs a "pmu0" regs to
>> tweak, like other EHCI/OHCI pairs in Allwinner SoCs.
>>
>> Add this to the binding of USB PHYs on Allwinner H3/V3s/A64.
>>
>> Signed-off-by: Icenowy Zheng 
>> Acked-by: Chen-Yu Tsai 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>
>> Kishon, could you push this to 4.11?
>
> Is this for the patch titled "phy: sun4i-usb: add support for V3s USB PHY" 
> that
> was added during the last merge window.

Yes. In fact, as the description suggests, this also applies retroactively to
H3 and A64, which were added in the following commits:

4.9  732e35da7b4a ("dt: bindings: add bindings for Allwinner A64 usb phy")
4.5  626a630e003c ("phy-sun4i-usb: Add support for the host usb-phys found
on the H3 SoC")

Though this was missed at the time the binding was added.

ChenYu

> this patch looks simpler enough to be merged in this -rc cycle. However it
> depends on Greg KH.
>
> Thanks
> Kishon
>
>>
>>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
>> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> index e42334258185..005bc22938ff 100644
>> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> @@ -15,6 +15,7 @@ Required properties:
>>  - reg : a list of offset + length pairs
>>  - reg-names :
>>* "phy_ctrl"
>> +  * "pmu0" for H3, V3s and A64
>>* "pmu1"
>>* "pmu2" for sun4i, sun6i or sun7i
>>  - #phy-cells : from the generic phy bindings, must be 1
>>

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

[Mauro Carvalho Chehab]

Em Wed, 5 Apr 2017 11:39:06 -0400
Devin Heitmueller  escreveu:

> > Currently, the driver doesn't support (2), because, at the time
> > I wrote the driver, I didn't find a way to read the interrupts generated
> > by tvp5150 at em28xx[1], due to the lack of em28xx documentation,
> > but adding support for it shoudn't be hard. I may eventually do it
> > when I have some time to play with my ISEE hardware.  
> 
> For what it's worth, I doubt most of the em28xx designs have the
> tvp5150 interrupt request line connected in any way.

True. But, on embedded hardware, such line may be connected into the
SoC. Actually, from the IGEPv3 expansion diagram:


https://www.isee.biz/support/downloads/item/igepv2-expansion-rc-schematics

The INT line is connected to CAM_IRQ. That's connected to GPIO_154 pin
at OMAP3.

So, on a first glance, it seems possible to use it, instead of polling.

> You would likely
> have to poll the FIFO status register via I2C,

Yes, I considered this option when I wrote the driver. It could work, 
although it would likely have some performance drawback, as the driver
would need to poll it at least 60 times per second.

> or use the feature to
> embed the sliced data into as VANC data in the 656 output (as
> described in sec 3.9 of the tvp5150am1 spec).

True, but the bridge driver would need to handle such data. 

I remember I looked on this when I wrote the driver, but I was
unable to find a way for em28xx to parse (or forward) such
data packets.

Thanks,
Mauro

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

[Paul E. McKenney]

On Wed, Apr 05, 2017 at 09:32:07AM -0400, Steven Rostedt wrote:
> Hi Paul,
> 
> My tests are triggering the following when I have lockdep enabled and
> running the stack tracer:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at 
> /work/autotest/nobackup/linux-test.git/kernel/module.c:271 
> module_assert_mutex_or_preempt+0x4f/0x51
> Modules linked in: ppdev parport_pc parport [last unloaded: 
> trace_events_sample]
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc3-test+ #48
> Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
> Call Trace:
> 
> ===
> [ ERR: suspicious RCU usage.  ]
> 4.11.0-rc3-test+ #48 Not tainted
> ---
> /work/autotest/nobackup/linux-test.git/include/linux/rcupdate.h:837 
> rcu_read_lock() used illegally while idle!
> 
> other info that might help us debug this:
> 
> 
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 2, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
>  #0:  (rcu_read_lock){..}, at: [] rcu_read_lock+0x0/0x61
> 
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc3-test+ #48
> Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
> Call Trace:
>  dump_stack+0x68/0x92
>  __warn+0xc2/0xdd
>  ? 0xa0026077
>  warn_slowpath_null+0x1d/0x1f
>  module_assert_mutex_or_preempt+0x4f/0x51
>  __module_address+0x2a/0xac
>  ? 0xa0026077
>  __module_text_address+0x12/0x59
>  ? 0xa0026077
>  is_module_text_address+0xe/0x16
>  __kernel_text_address+0x2b/0x80
>  ? 0xa0026077
>  unwind_get_return_address+0x50/0x5c
>  __save_stack_trace+0x76/0xbf
>  ? rcu_eqs_enter_common.constprop.71+0x5/0x108
>  save_stack_trace+0x1b/0x1d
>  check_stack+0xec/0x24a
>  stack_trace_call+0x40/0x53 <<-- This is the start of the stack tracer
>  0xa0026077
>  ? ftrace_graph_caller+0x78/0xa8
>  ? trace_hardirqs_off+0xd/0xf
>  ? rcu_eqs_enter_common.constprop.71+0x5/0x108
>  rcu_eqs_enter_common.constprop.71+0x5/0x108   <<-- It appears to be testing 
> the rcu internal code
>  rcu_idle_enter+0x51/0x72
>  ? rcu_eqs_enter_common.constprop.71+0x5/0x108
>  ? rcu_idle_enter+0x51/0x72
>  do_idle+0xbb/0x1e5
>  cpu_startup_entry+0x1f/0x21
>  rest_init+0x127/0x12d
>  start_kernel+0x3f5/0x402
>  x86_64_start_reservations+0x2f/0x31
>  x86_64_start_kernel+0x17f/0x192
>  start_cpu+0x14/0x14
>  ? start_cpu+0x14/0x14
> ---[ end trace eeaad31bc52457e7 ]---
> 
> 
> Now the check_stack() function in kernel/trace/trace_stack.c has the
> following:
> 
>   /*
>* RCU may not be watching, make it see us.
>* The stack trace code uses rcu_sched.
>*/
>   rcu_irq_enter();
> 
> 
> What I'm guessing, is that because it is tracing the internals of the
> rcu code, and checking its stack, the stack trace triggered in a
> location where calling rcu_irq_enter() isn't sufficient to have rcu
> become watchable.
> 
> I may add code to check if rcu is indeed watching after the
> rcu_irq_enter() call, and if it still isn't to simply exit out.
> 
> Thoughts?

Ouch!!!

I really blew it telling you that you can use rcu_irq_enter()!!!

RCU's eqs code disables interrupts, but has a call to the trace code
exactly where it cannot handle an interrupt.  Your rcu_irq_enter()
therefore breaks things -- the ->dynticks_nesting has been set to zero,
but ->dynticks still indicates non-idle.  Therefore, rcu_irq_enter() sees
zero nesting, and thus incorrectly increments ->dynticks, which tells RCU
"idle".  The later rcu_is_watching() checks therefore complain bitterly.

I really don't want you to have to hack around this.  So I should adjust
RCU to avoid doing tracing during this period of time, which would allow
you to continue using rcu_irq_enter() as you are now.  (You don't trace
from NMIs, do you?  If you do, I guess I need to somehow disable tracing
during the vulnerable period?)

One simple-and-stupid fix would be for me to move rcu_eqs_enter_common()'s
trace_rcu_dyntick() statement into all its callers.  Another would be to
give rcu_eqs_enter_common() an additional argument that is the amount to
subtract from ->dynticks_nesting, and have rcu_eqs_enter_common() do the
decrment after the tracing.  The latter seems most reasonable at first
glance, especially given that it confines the risky data-inconsistent
period to a single contiguous piece of code.

So how about the following lightly tested patch?

I will check to see if something similar is needed for eqs exit.
Could you please let me know if tracing happens in NMI handlers?
If so, a bit of additional code will be needed.

Thanx, Paul

PS.  Which reminds me, any short-term uses of RCU_TASKS?  This represents
 3 of my 16 test scenarios, which is getting hard to justify for
 something that isn't used.  Especially given that I will need to
 add more scenarios for 

Re: [RFC][PATCH v2 3/5] clone: Disallown CLONE_THREAD with a shared sighand_struct

[Oleg Nesterov]

On 04/02, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1515,6 +1515,13 @@ static __latent_entropy struct task_struct 
> *copy_process(
>   if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
>   return ERR_PTR(-EINVAL);
>
> + /* Disallow CLONE_THREAD with a shared SIGHAND structure.  No
> +  * one cares

Well, can't resists... I won't argue, but we can't know if no one cares
or not. I agree that most probably this won't break something, but who
knows... I am always scared when we add the incompatible changes.

> and supporting it leads to unnecessarily complex
> +  * code.
> +  */
> + if ((clone_flags & CLONE_THREAD) && 
> (atomic_read(>sighand->count) > 1))
> + return ERR_PTR(-EINVAL);

Perhaps the comment should explain why we do this and say that
sighand-unsharing in de_thread() depends on this.

Oleg.

Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

[Sean Paul]

On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:
> After unbinding drm, the userspace may still has a chance to access
> gem buf.
> 
> Add a sanity check for a NULL dev_private to prevent that from
> happening.

I still don't understand how this is happening. You're saying that these hooks
can be called after rockchip_drm_unbind() has finished? 

Sean

> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v3:
> Address Daniel Vetter 's comments.
> Update commit message.
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index df9e570..205a3dc 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
> rockchip_gem_object *rk_obj,
>   struct drm_device *drm = obj->dev;
>   struct rockchip_drm_private *private = drm->dev_private;
>  
> + if (!private)
> + return -ENODEV;
> +
>   if (private->domain)
>   return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
>   else
> @@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
> rockchip_gem_object *rk_obj)
>  
>  static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
>  {
> + struct drm_device *drm = rk_obj->base.dev;
> +
> + if (!drm->dev_private)
> + return;
> +
>   if (rk_obj->pages)
>   rockchip_gem_free_iommu(rk_obj);
>   else
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS

[PATCH] clk: sunxi-ng: Display index when clock registration fails

[Priit Laes]

Add clock index to clock registration failure message. Clock name
is sometimes not available, when things go really wrong.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_common.c 
b/drivers/clk/sunxi-ng/ccu_common.c
index 8a47baf..188fa50 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -63,8 +63,8 @@ int sunxi_ccu_probe(struct device_node *node, void __iomem 
*reg,
 
ret = clk_hw_register(NULL, hw);
if (ret) {
-   pr_err("Couldn't register clock %s\n",
-  clk_hw_get_name(hw));
+   pr_err("Couldn't register clock %d - %s\n",
+  i, clk_hw_get_name(hw));
goto err_clk_unreg;
}
}
-- 
2.9.3

[PATCH 36/38] Annotate hardware config module parameters in sound/isa/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in sound/isa/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Jaroslav Kysela 
cc: Takashi Iwai 
cc: alsa-de...@alsa-project.org
---

 sound/isa/ad1848/ad1848.c  |6 +++---
 sound/isa/adlib.c  |2 +-
 sound/isa/cmi8328.c|   12 ++--
 sound/isa/cmi8330.c|   20 ++--
 sound/isa/cs423x/cs4231.c  |   12 ++--
 sound/isa/cs423x/cs4236.c  |   18 +-
 sound/isa/es1688/es1688.c  |   12 ++--
 sound/isa/es18xx.c |   12 ++--
 sound/isa/galaxy/galaxy.c  |   16 
 sound/isa/gus/gusclassic.c |8 
 sound/isa/gus/gusextreme.c |   16 
 sound/isa/gus/gusmax.c |8 
 sound/isa/gus/interwave.c  |   10 +-
 sound/isa/msnd/msnd_pinnacle.c |   20 ++--
 sound/isa/opl3sa2.c|   16 
 sound/isa/opti9xx/miro.c   |   14 +++---
 sound/isa/opti9xx/opti92x-ad1848.c |   14 +++---
 sound/isa/sb/jazz16.c  |   12 ++--
 sound/isa/sb/sb16.c|   14 +++---
 sound/isa/sb/sb8.c |6 +++---
 sound/isa/sc6000.c |   12 ++--
 sound/isa/sscape.c |   12 ++--
 sound/isa/wavefront/wavefront.c|   18 +-
 23 files changed, 145 insertions(+), 145 deletions(-)

diff --git a/sound/isa/ad1848/ad1848.c b/sound/isa/ad1848/ad1848.c
index a302d1f8d14f..e739b1c85c25 100644
--- a/sound/isa/ad1848/ad1848.c
+++ b/sound/isa/ad1848/ad1848.c
@@ -55,11 +55,11 @@ module_param_array(id, charp, NULL, 0444);
 MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
 module_param_array(enable, bool, NULL, 0444);
 MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
 MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
 MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
 MODULE_PARM_DESC(dma1, "DMA1 # for " CRD_NAME " driver.");
 module_param_array(thinkpad, bool, NULL, 0444);
 MODULE_PARM_DESC(thinkpad, "Enable only for the onboard CS4248 of IBM Thinkpad 
360/750/755 series.");
diff --git a/sound/isa/adlib.c b/sound/isa/adlib.c
index 8d3060fd7ad7..5fb619eca5c8 100644
--- a/sound/isa/adlib.c
+++ b/sound/isa/adlib.c
@@ -27,7 +27,7 @@ module_param_array(id, charp, NULL, 0444);
 MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
 module_param_array(enable, bool, NULL, 0444);
 MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
 MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
 
 static int snd_adlib_match(struct device *dev, unsigned int n)
diff --git a/sound/isa/cmi8328.c b/sound/isa/cmi8328.c
index 787475084f46..8e1756c3b9bb 100644
--- a/sound/isa/cmi8328.c
+++ b/sound/isa/cmi8328.c
@@ -51,18 +51,18 @@ MODULE_PARM_DESC(index, "Index value for CMI8328 
soundcard.");
 module_param_array(id, charp, NULL, 0444);
 MODULE_PARM_DESC(id, "ID string for CMI8328 soundcard.");
 
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
 MODULE_PARM_DESC(port, "Port # for CMI8328 driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
 MODULE_PARM_DESC(irq, "IRQ # for CMI8328 driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
 MODULE_PARM_DESC(dma1, 

[PATCH 31/38] Annotate hardware config module parameters in drivers/tty/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/tty/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Greg Kroah-Hartman 
cc: Jiri Slaby 
cc: linux-ser...@vger.kernel.org
---

 drivers/tty/cyclades.c  |4 ++--
 drivers/tty/moxa.c  |2 +-
 drivers/tty/mxser.c |2 +-
 drivers/tty/rocket.c|   10 +-
 drivers/tty/serial/8250/8250_core.c |4 ++--
 drivers/tty/synclink.c  |6 +++---
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 5e4fa9206861..104f09c58163 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -156,8 +156,8 @@ static unsigned int cy_isa_addresses[] = {
 static long maddr[NR_CARDS];
 static int irq[NR_CARDS];
 
-module_param_array(maddr, long, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(maddr, long, iomem, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 
 #endif /* CONFIG_ISA */
 
diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
index 4caf0c3b1f99..3b251f4e5df0 100644
--- a/drivers/tty/moxa.c
+++ b/drivers/tty/moxa.c
@@ -179,7 +179,7 @@ MODULE_FIRMWARE("c320tunx.cod");
 
 module_param_array(type, uint, NULL, 0);
 MODULE_PARM_DESC(type, "card type: C218=2, C320=4");
-module_param_array(baseaddr, ulong, NULL, 0);
+module_param_hw_array(baseaddr, ulong, ioport, NULL, 0);
 MODULE_PARM_DESC(baseaddr, "base address");
 module_param_array(numports, uint, NULL, 0);
 MODULE_PARM_DESC(numports, "numports (ignored for C218)");
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 7b8f383fb090..8bd6fb6d9391 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -183,7 +183,7 @@ static int ttymajor = MXSERMAJOR;
 
 MODULE_AUTHOR("Casper Yang");
 MODULE_DESCRIPTION("MOXA Smartio/Industio Family Multiport Board Device 
Driver");
-module_param_array(ioaddr, ulong, NULL, 0);
+module_param_hw_array(ioaddr, ulong, ioport, NULL, 0);
 MODULE_PARM_DESC(ioaddr, "ISA io addresses to look for a moxa board");
 module_param(ttymajor, int, 0);
 MODULE_LICENSE("GPL");
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index d66c1edd9892..b51a877da986 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -250,15 +250,15 @@ static int sReadAiopNumChan(WordIO_t io);
 
 MODULE_AUTHOR("Theodore Ts'o");
 MODULE_DESCRIPTION("Comtrol RocketPort driver");
-module_param(board1, ulong, 0);
+module_param_hw(board1, ulong, ioport, 0);
 MODULE_PARM_DESC(board1, "I/O port for (ISA) board #1");
-module_param(board2, ulong, 0);
+module_param_hw(board2, ulong, ioport, 0);
 MODULE_PARM_DESC(board2, "I/O port for (ISA) board #2");
-module_param(board3, ulong, 0);
+module_param_hw(board3, ulong, ioport, 0);
 MODULE_PARM_DESC(board3, "I/O port for (ISA) board #3");
-module_param(board4, ulong, 0);
+module_param_hw(board4, ulong, ioport, 0);
 MODULE_PARM_DESC(board4, "I/O port for (ISA) board #4");
-module_param(controller, ulong, 0);
+module_param_hw(controller, ulong, ioport, 0);
 MODULE_PARM_DESC(controller, "I/O port for (ISA) rocketport controller");
 module_param(support_low_speed, bool, 0);
 MODULE_PARM_DESC(support_low_speed, "1 means support 50 baud, 0 means support 
460400 baud");
diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 76e03a7de9cc..89fde17d9617 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1191,7 +1191,7 @@ module_exit(serial8250_exit);
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Generic 8250/16x50 serial driver");
 
-module_param(share_irqs, uint, 0644);
+module_param_hw(share_irqs, uint, other, 0644);
 MODULE_PARM_DESC(share_irqs, "Share IRQs with other non-8250/16x50 devices 
(unsafe)");
 
 module_param(nr_uarts, uint, 0644);
@@ -1201,7 +1201,7 @@ module_param(skip_txen_test, uint, 

[PATCH 37/38] Annotate hardware config module parameters in sound/oss/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in sound/oss/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Jaroslav Kysela 
cc: Takashi Iwai 
cc: Riccardo Facchetti 
cc: Andrew Veliath 
cc: alsa-de...@alsa-project.org
---

 sound/oss/ad1848.c|8 
 sound/oss/aedsp16.c   |   12 ++--
 sound/oss/mpu401.c|4 ++--
 sound/oss/msnd_pinnacle.c |   20 ++--
 sound/oss/opl3.c  |2 +-
 sound/oss/pas2_card.c |   18 +-
 sound/oss/pss.c   |   14 +++---
 sound/oss/sb_card.c   |   10 +-
 sound/oss/trix.c  |   18 +-
 sound/oss/uart401.c   |4 ++--
 sound/oss/uart6850.c  |4 ++--
 sound/oss/waveartist.c|8 
 12 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index f6156d8169d0..2421f59cf279 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -2805,10 +2805,10 @@ static int __initdata dma = -1;
 static int __initdata dma2 = -1;
 static int __initdata type = 0;
 
-module_param(io, int, 0);  /* I/O for a raw AD1848 card */
-module_param(irq, int, 0); /* IRQ to use */
-module_param(dma, int, 0); /* First DMA channel */
-module_param(dma2, int, 0);/* Second DMA channel */
+module_param_hw(io, int, ioport, 0);   /* I/O for a raw AD1848 card */
+module_param_hw(irq, int, irq, 0); /* IRQ to use */
+module_param_hw(dma, int, dma, 0); /* First DMA channel */
+module_param_hw(dma2, int, dma, 0);/* Second DMA channel */
 module_param(type, int, 0);/* Card type */
 module_param(deskpro_xl, bool, 0); /* Special magic for Deskpro XL boxen */
 module_param(deskpro_m, bool, 0);  /* Special magic for Deskpro M box */
diff --git a/sound/oss/aedsp16.c b/sound/oss/aedsp16.c
index bb477d5c8528..f058ed6bdb69 100644
--- a/sound/oss/aedsp16.c
+++ b/sound/oss/aedsp16.c
@@ -1303,17 +1303,17 @@ static int __initdata mpu_irq = -1;
 static int __initdata mss_base = -1;
 static int __initdata mpu_base = -1;
 
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
 MODULE_PARM_DESC(io, "I/O base address (0x220 0x240)");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ line (5 7 9 10 11)");
-module_param(dma, int, 0);
+module_param_hw(dma, int, dma, 0);
 MODULE_PARM_DESC(dma, "dma line (0 1 3)");
-module_param(mpu_irq, int, 0);
+module_param_hw(mpu_irq, int, irq, 0);
 MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ line (5 7 9 10 0)");
-module_param(mss_base, int, 0);
+module_param_hw(mss_base, int, ioport, 0);
 MODULE_PARM_DESC(mss_base, "MSS emulation I/O base address (0x530 0xE80)");
-module_param(mpu_base, int, 0);
+module_param_hw(mpu_base, int, ioport, 0);
 MODULE_PARM_DESC(mpu_base,"MPU-401 I/O base address (0x300 0x310 0x320 
0x330)");
 MODULE_AUTHOR("Riccardo Facchetti ");
 MODULE_DESCRIPTION("Audio Excel DSP 16 Driver Version " VERSION);
diff --git a/sound/oss/mpu401.c b/sound/oss/mpu401.c
index 862735005b43..20e8fa46f647 100644
--- a/sound/oss/mpu401.c
+++ b/sound/oss/mpu401.c
@@ -1748,8 +1748,8 @@ static struct address_info cfg;
 static int io = -1;
 static int irq = -1;
 
-module_param(irq, int, 0);
-module_param(io, int, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(io, int, ioport, 0);
 
 static int __init init_mpu401(void)
 {
diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
index f34ec01d2239..d2abc2cf3213 100644
--- a/sound/oss/msnd_pinnacle.c
+++ b/sound/oss/msnd_pinnacle.c
@@ -1727,22 +1727,22 @@ static int
 calibrate_signal __initdata =  CONFIG_MSND_CALSIGNAL;
 #endif /* MODULE */
 
-module_param   (io, int, 0);
-module_param   (irq, int, 0);
-module_param   (mem, int, 0);

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

[Devin Heitmueller]

>> For what it's worth, I doubt most of the em28xx designs have the
>> tvp5150 interrupt request line connected in any way.
>
> True. But, on embedded hardware, such line may be connected into the
> SoC. Actually, from the IGEPv3 expansion diagram:
>
> 
> https://www.isee.biz/support/downloads/item/igepv2-expansion-rc-schematics
>
> The INT line is connected to CAM_IRQ. That's connected to GPIO_154 pin
> at OMAP3.
>
> So, on a first glance, it seems possible to use it, instead of polling.

To be clear, I wasn't suggesting that the IRQ request line on the
tvp5150 couldn't be supported in general (for example, for those
embedded targets which have it wired up to a host processor).  I'm
just saying you shouldn't expect it to work on most (perhaps all)
em28xx designs which have the tvp5150.  In fact on some em28xx designs
the pin is used as a GPIO output tied to a mux to control input
selection.  Hence blindly enabling the interrupt request line by
default would do all sorts of bad things.

>> You would likely
>> have to poll the FIFO status register via I2C,
>
> Yes, I considered this option when I wrote the driver. It could work,
> although it would likely have some performance drawback, as the driver
> would need to poll it at least 60 times per second.
>
>> or use the feature to
>> embed the sliced data into as VANC data in the 656 output (as
>> described in sec 3.9 of the tvp5150am1 spec).
>
> True, but the bridge driver would need to handle such data.

Correct.

> I remember I looked on this when I wrote the driver, but I was
> unable to find a way for em28xx to parse (or forward) such
> data packets.

I'm pretty sure it's possible, but I haven't looked at the datasheets
in a number of years and don't recall the details.

Hardware VBI splicing is supported by a number of decoders but it's
rarely used on commodity PCs (the Conexant and NXP decoders support it
as well).  That said, I won't argue there might be some value on
really low end platforms.  All I would ask is that if you do introduce
any such functionality into the tvp5150 driver for some embedded
application that you please not break support for devices such as the
em28xx.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

[PATCH 06/24] Add a sysrq option to exit secure boot mode

[David Howells]

From: Kyle McMartin 

Make sysrq+x exit secure boot mode on x86_64, thereby allowing the running
kernel image to be modified.  This lifts the lockdown.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
---

 arch/x86/Kconfig|   10 ++
 arch/x86/kernel/setup.c |   31 +++
 drivers/input/misc/uinput.c |1 +
 drivers/tty/sysrq.c |   19 +--
 include/linux/input.h   |5 +
 include/linux/sysrq.h   |8 +++-
 kernel/debug/kdb/kdb_main.c |2 +-
 7 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f39855661d..457c04971849 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1829,6 +1829,16 @@ config EFI_SECURE_BOOT_LOCK_DOWN
  image.  Say Y here to automatically lock down the kernel when a
  system boots with UEFI Secure Boot enabled.
 
+config EFI_ALLOW_SECURE_BOOT_EXIT
+   def_bool n
+   depends on EFI_SECURE_BOOT_LOCK_DOWN && MAGIC_SYSRQ
+   select ALLOW_LOCKDOWN_LIFT
+   prompt "Allow secure boot mode to be exited with SysRq+x on a keyboard"
+   ---help---
+ Allow secure boot mode to be exited and the kernel lockdown lifted by
+ typing SysRq+x on a keyboard attached to the system (not permitted
+ through procfs).
+
 config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 85dfa745c442..a415a4817684 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -71,6 +71,11 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #include 
@@ -1330,6 +1335,32 @@ void __init i386_reserve_resources(void)
 
 #endif /* CONFIG_X86_32 */
 
+#ifdef CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT
+
+static void sysrq_handle_secure_boot(int key)
+{
+   if (!efi_enabled(EFI_SECURE_BOOT))
+   return;
+
+   pr_info("Secure boot disabled\n");
+   lift_kernel_lockdown();
+}
+static struct sysrq_key_op secure_boot_sysrq_op = {
+   .handler=   sysrq_handle_secure_boot,
+   .help_msg   =   "unSB(x)",
+   .action_msg =   "Disabling Secure Boot restrictions",
+   .enable_mask=   SYSRQ_DISABLE_USERSPACE,
+};
+static int __init secure_boot_sysrq(void)
+{
+   if (efi_enabled(EFI_SECURE_BOOT))
+   register_sysrq_key('x', _boot_sysrq_op);
+   return 0;
+}
+late_initcall(secure_boot_sysrq);
+#endif /*CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT*/
+
+
 static struct notifier_block kernel_offset_notifier = {
.notifier_call = dump_kernel_offset
 };
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 022be0e22eba..4a054a564636 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -387,6 +387,7 @@ static int uinput_allocate_device(struct uinput_device 
*udev)
if (!udev->dev)
return -ENOMEM;
 
+   udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
udev->dev->event = uinput_dev_event;
input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index c6fc7141d7b2..0c96cf60f1a6 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -481,6 +481,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
/* x: May be registered on mips for TLB dump */
/* x: May be registered on ppc/powerpc for xmon */
/* x: May be registered on sparc64 for global PMU dump */
+   /* x: May be registered on x86_64 for disabling secure boot */
NULL,   /* x */
/* y: May be registered on sparc64 for global register dump */
NULL,   /* y */
@@ -524,7 +525,7 @@ static void __sysrq_put_key_op(int key, struct sysrq_key_op 
*op_p)
 sysrq_key_table[i] = op_p;
 }
 
-void __handle_sysrq(int key, bool check_mask)
+void __handle_sysrq(int key, unsigned int from)
 {
struct sysrq_key_op *op_p;
int orig_log_level;
@@ -544,11 +545,15 @@ void __handle_sysrq(int key, bool check_mask)
 
 op_p = __sysrq_get_key_op(key);
 if (op_p) {
+   /* Ban synthetic events from some sysrq functionality */
+   if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
+   op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
+   printk("This sysrq operation is disabled from 
userspace.\n");
/*
 * Should we check for enabled operations (/proc/sysrq-trigger
 * should not) and is the invoked operation enabled?
 */
-   if (!check_mask || sysrq_on_mask(op_p->enable_mask)) {
+   if (from == SYSRQ_FROM_KERNEL || 
sysrq_on_mask(op_p->enable_mask)) {
pr_cont("%s\n", 

[PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot

[David Howells]

From: Dave Young 

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

Adding a patch to fix this by retain the secure_boot flag in original
kernel.

secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub.  Fixing this issue by copying secure_boot flag across kexec reboot.

Signed-off-by: Dave Young 
Signed-off-by: David Howells 
---

 arch/x86/kernel/kexec-bzimage64.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index d0a814a9d96a..3551bcaa1eaf 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
 
+   params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = current_ei->efi_systab;
ei->efi_systab_hi = current_ei->efi_systab_hi;

[PATCH 07/24] kexec: Disable at runtime if the kernel is locked down

[David Howells]

From: Matthew Garrett 

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.

This does not affect kexec_file_load() which can check for a signature on the
image to be booted.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
---

 kernel/kexec.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..46de8e6b42f4 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -194,6 +194,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned 
long, nr_segments,
return -EPERM;
 
/*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (kernel_is_locked_down())
+   return -EPERM;
+
+   /*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
 */

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

[Ard Biesheuvel]

Hoi Matthias!

On 5 April 2017 at 17:56, Matthias Kaehlcke  wrote:
> From: Greg Hackmann 
>
> The current definition of ASM_EXPORT doesn't work properly with clang,
> according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
> gcc specific behavior. Change the constraint from an intermediate to an
> output expression which works with both gcc and clang.
>
> From: Greg Hackmann 
> Commit-message-by: Matthias Kaehlcke 
> Signed-off-by: Greg Hackmann 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  arch/arm64/crypto/sha1-ce-glue.c | 2 +-
>  arch/arm64/crypto/sha2-ce-glue.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/crypto/sha1-ce-glue.c 
> b/arch/arm64/crypto/sha1-ce-glue.c
> index aefda9868627..c71e94ba0e43 100644
> --- a/arch/arm64/crypto/sha1-ce-glue.c
> +++ b/arch/arm64/crypto/sha1-ce-glue.c
> @@ -18,7 +18,7 @@
>  #include 
>
>  #define ASM_EXPORT(sym, val) \
> -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> +   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>
>  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");
> diff --git a/arch/arm64/crypto/sha2-ce-glue.c 
> b/arch/arm64/crypto/sha2-ce-glue.c
> index 7cd587564a41..381b5fb2dcb2 100644
> --- a/arch/arm64/crypto/sha2-ce-glue.c
> +++ b/arch/arm64/crypto/sha2-ce-glue.c
> @@ -18,7 +18,7 @@
>  #include 
>
>  #define ASM_EXPORT(sym, val) \
> -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> +   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>
>  MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
> Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");

I am fine with this change, although I would really like to add a
better reference to the commit log. It is *very* difficult to find any
documentation regarding non-trivial uses of inline asm constraints,
and if %c0 is the correct syntax, surely we can quote something better
than a LLVM bugzilla entry? Also, where does the distinction between
'intermediate' vs 'output' expression come from?

[PATCH 04/24] Enforce module signatures if the kernel is locked down

[David Howells]

If the kernel is locked down, require that all modules have valid
signatures that we can verify.

Signed-off-by: David Howells 
---

 kernel/module.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index 7eba6dea4f41..3331f2eb9b93 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2756,7 +2756,7 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !sig_enforce && !kernel_is_locked_down())
err = 0;
 
return err;

Re: [RFC 00/10] V4L2 explicit synchronization support

[Javier Martinez Canillas]

Hello Gustavo,

On 04/05/2017 11:09 AM, Gustavo Padovan wrote:
> 2017-04-03 Javier Martinez Canillas :
> 
>> Hello Mauro and Gustavo,
>>
>> On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote:
>>> Hi Gustavo,
>>>
>>> Em Mon, 13 Mar 2017 16:20:25 -0300
>>> Gustavo Padovan  escreveu:
>>>
 From: Gustavo Padovan 

 Hi,

 This RFC adds support for Explicit Synchronization of shared buffers in 
 V4L2.
 It uses the Sync File Framework[1] as vector to communicate the fences
 between kernel and userspace.
>>>
>>> Thanks for your work!
>>>
>>> I looked on your patchset, and I didn't notice anything really weird
>>> there. So, instead on reviewing patch per patch, I prefer to discuss
>>> about the requirements and API, as depending on it, the code base will
>>> change a lot.
>>>
>>
>> Agree that's better to first set on an uAPI and then implement based on that.
>>  
>>> I'd like to do some tests with it on devices with mem2mem drivers.
>>> My plan is to use an Exynos board for such thing, but I guess that
>>> the DRM driver for it currently doesn't. I'm seeing internally if someone
>>> could be sure that Exynos driver upstream will become ready for such
>>> tests.
>>>
>>
>> Not sure if you should try to do testing before agreeing on an uAPI and
>> implementation.
>>
>>> Javier wrote some patches last year meant to implement implicit
>>> fences support. What we noticed is that, while his mechanism worked
>>> fine for pure capture and pure output devices, when we added a mem2mem
>>> device, on a DMABUF+fences pipeline, e. g.:
>>>
>>> sensor -> [m2m] -> DRM
>>>
>>> End everything using fences/DMABUF, the fences mechanism caused dead
>>> locks on existing userspace apps.
>>>
>>> A m2m device has both capture and output devnodes. Both should be
>>> queued/dequeued. The capture queue is synchronized internally at the
>>> driver with the output buffer[1].
>>>
>>> [1] The names here are counter-intuitive: "capture" is a devnode
>>> where userspace receives a video stream; "output" is a devnode where
>>> userspace feeds a video stream.
>>>
>>> The problem is that adding implicit fences changed the behavior of
>>> the ioctls, causing gstreamer to wait forever for buffers to be ready.
>>>
>>
>> The problem was related to trying to make user-space unaware of the implicit
>> fences support, and so it tried to QBUF a buffer that had already a pending
>> fence. A workaround was to block the second QBUF ioctl if the buffer had a
>> pending fence, but this caused the mentioned deadlock since GStreamer wasn't
>> expecting the QBUF ioctl to block.
>>
>>> I suspect that, even with explicit fences, the behavior of Q/DQ
>>> will be incompatible with the current behavior (or will require some
>>> dirty hacks to make it identical). 
> 
> For QBUF the only difference is that we set flags for fences and pass
> and receives in and out fences. For DQBUF the behavior is exactly the
> same. What incompatibles or hacks do you see?
> 
> I had the expectation that the flags would be for userspace to learn
> about any different behavior.
> 
>>>
>>> So, IMHO, the best would be to use a new set of ioctls, when fences are
>>> used (like VIDIOC_QFENCE/DQFENCE).
>>>
>>
>> For explicit you can check if there's an input-fence so is different than
>> implicit, but still I agree that it would be better to have specific ioctls.
> 
> I'm pretty new to v4l2 so I don't know all use cases yet, but what I
> thought was to just add extra flags to QBUF to mark when using fences
> instead of having userspace  to setup completely new ioctls for fences.
> The burden for userspace should be smaller with flags.
>

Yes, you are right. So I guess its better indeed to just extend the current
ioctls as you propose and only move to new ones if really needed.

>>

 I'm sending this to start the discussion on the best approach to implement
 Explicit Synchronization, please check the TODO/OPEN section below.

 Explicit Synchronization allows us to control the synchronization of
 shared buffers from userspace by passing fences to the kernel and/or 
 receiving them from the the kernel.

 Fences passed to the kernel are named in-fences and the kernel should wait
 them to signal before using the buffer. On the other side, the kernel 
 creates
 out-fences for every buffer it receives from userspace. This fence is sent 
 back
 to userspace and it will signal when the capture, for example, has 
 finished.

 Signalling an out-fence in V4L2 would mean that the job on the buffer is 
 done
 and the buffer can be used by other drivers.

 Current RFC implementation
 --

 The current implementation is not intended to be more than a PoC to start
 the discussion on how Explicit Synchronization should be supported in V4L2.

 The first patch proposes an 

[PATCH 19/24] acpi: Disable APEI error injection if the kernel is locked down

[David Howells]

From: Linn Crosetto 

ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features.  If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors.  This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
---

 drivers/acpi/apei/einj.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index ec50c32ea3da..e082718d01c2 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -518,6 +518,9 @@ static int einj_error_inject(u32 type, u32 flags, u64 
param1, u64 param2,
int rc;
u64 base_addr, size;
 
+   if (kernel_is_locked_down())
+   return -EPERM;
+
/* If user manually set "flags", make sure it is legal */
if (flags && (flags &
~(SETWA_FLAGS_APICID|SETWA_FLAGS_MEM|SETWA_FLAGS_PCIE_SBDF)))

[PATCH 15/38] Annotate hardware config module parameters in drivers/mmc/host/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/mmc/host/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Pierre Ossman 
cc: Ulf Hansson 
cc: linux-...@vger.kernel.org
---

 drivers/mmc/host/wbsd.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/wbsd.c b/drivers/mmc/host/wbsd.c
index bd04e8bae010..e15a9733fcfd 100644
--- a/drivers/mmc/host/wbsd.c
+++ b/drivers/mmc/host/wbsd.c
@@ -2001,11 +2001,11 @@ static void __exit wbsd_drv_exit(void)
 module_init(wbsd_drv_init);
 module_exit(wbsd_drv_exit);
 #ifdef CONFIG_PNP
-module_param_named(nopnp, param_nopnp, uint, 0444);
+module_param_hw_named(nopnp, param_nopnp, uint, other, 0444);
 #endif
-module_param_named(io, param_io, uint, 0444);
-module_param_named(irq, param_irq, uint, 0444);
-module_param_named(dma, param_dma, int, 0444);
+module_param_hw_named(io, param_io, uint, ioport, 0444);
+module_param_hw_named(irq, param_irq, uint, irq, 0444);
+module_param_hw_named(dma, param_dma, int, dma, 0444);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Pierre Ossman ");

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

[Mauro Carvalho Chehab]

Em Wed, 5 Apr 2017 13:02:52 -0400
Devin Heitmueller  escreveu:

> > I remember I looked on this when I wrote the driver, but I was
> > unable to find a way for em28xx to parse (or forward) such
> > data packets.  
> 
> I'm pretty sure it's possible, but I haven't looked at the datasheets
> in a number of years and don't recall the details.
> 
> Hardware VBI splicing is supported by a number of decoders but it's
> rarely used on commodity PCs (the Conexant and NXP decoders support it
> as well).  That said, I won't argue there might be some value on
> really low end platforms.  All I would ask is that if you do introduce
> any such functionality into the tvp5150 driver for some embedded
> application that you please not break support for devices such as the
> em28xx.

Yeah, sure. If I write such patchset[1], it will be optional, and
will depend on a DT variable (or platform_data) setup that would
tell what GPIO pin should be used for interrupt.

Not providing it should either disable such feature or enable it
via polling.

[1] Please notice that I don't have any demand of doing it. Yet,
I may do it for fun on my spare time:-)

I added in the past an initial support for sliced VBI API on em28xx, 
with got reverted on changeset 1d179eeedc8cb48712bc236ec82ec6c63af42008, 
mainly due to the lack of such feature on tvp5150. So, such code was never
tested (and likely need fixes/updates), but if I end by adding sliced VBI
support on tvp5150 and on OMAP3, I may add support for it on em28xx too,
using I2C poll. On such case, I'll likely add a modprobe parameter to
enable such feature.

Thanks,
Mauro

[PATCH 19/38] Annotate hardware config module parameters in drivers/net/ethernet/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/ethernet/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Steffen Klassert 
cc: Jaroslav Kysela 
cc: net...@vger.kernel.org
cc: linux-par...@vger.kernel.org
---

 drivers/net/ethernet/3com/3c509.c  |2 +-
 drivers/net/ethernet/3com/3c59x.c  |4 ++--
 drivers/net/ethernet/8390/ne.c |4 ++--
 drivers/net/ethernet/8390/smc-ultra.c  |4 ++--
 drivers/net/ethernet/8390/wd.c |8 
 drivers/net/ethernet/amd/lance.c   |6 +++---
 drivers/net/ethernet/amd/ni65.c|6 +++---
 drivers/net/ethernet/cirrus/cs89x0.c   |6 +++---
 drivers/net/ethernet/dec/tulip/de4x5.c |2 +-
 drivers/net/ethernet/hp/hp100.c|2 +-
 drivers/net/ethernet/realtek/atp.c |4 ++--
 drivers/net/ethernet/smsc/smc9194.c|4 ++--
 12 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/3com/3c509.c 
b/drivers/net/ethernet/3com/3c509.c
index c7f9f2c77da7..db8592d412ab 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -1371,7 +1371,7 @@ el3_resume(struct device *pdev)
 #endif /* CONFIG_PM */
 
 module_param(debug,int, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param(max_interrupt_work, int, 0);
 MODULE_PARM_DESC(debug, "debug level (0-6)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");
diff --git a/drivers/net/ethernet/3com/3c59x.c 
b/drivers/net/ethernet/3com/3c59x.c
index 40196f41768a..e41245a54f8b 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -813,8 +813,8 @@ module_param(global_enable_wol, int, 0);
 module_param_array(enable_wol, int, NULL, 0);
 module_param(rx_copybreak, int, 0);
 module_param(max_interrupt_work, int, 0);
-module_param(compaq_ioaddr, int, 0);
-module_param(compaq_irq, int, 0);
+module_param_hw(compaq_ioaddr, int, ioport, 0);
+module_param_hw(compaq_irq, int, irq, 0);
 module_param(compaq_device_id, int, 0);
 module_param(watchdog, int, 0);
 module_param(global_use_mmio, int, 0);
diff --git a/drivers/net/ethernet/8390/ne.c b/drivers/net/ethernet/8390/ne.c
index c063b410a163..66f47987e2a2 100644
--- a/drivers/net/ethernet/8390/ne.c
+++ b/drivers/net/ethernet/8390/ne.c
@@ -74,8 +74,8 @@ static int bad[MAX_NE_CARDS];
 static u32 ne_msg_enable;
 
 #ifdef MODULE
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(bad, int, NULL, 0);
 module_param_named(msg_enable, ne_msg_enable, uint, (S_IRUSR|S_IRGRP|S_IROTH));
 MODULE_PARM_DESC(io, "I/O base address(es),required");
diff --git a/drivers/net/ethernet/8390/smc-ultra.c 
b/drivers/net/ethernet/8390/smc-ultra.c
index 364b6514f65f..4e02f6a23575 100644
--- a/drivers/net/ethernet/8390/smc-ultra.c
+++ b/drivers/net/ethernet/8390/smc-ultra.c
@@ -561,8 +561,8 @@ static struct net_device *dev_ultra[MAX_ULTRA_CARDS];
 static int io[MAX_ULTRA_CARDS];
 static int irq[MAX_ULTRA_CARDS];
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_named(msg_enable, ultra_msg_enable, uint, 
(S_IRUSR|S_IRGRP|S_IROTH));
 MODULE_PARM_DESC(io, "I/O base address(es)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");
diff --git a/drivers/net/ethernet/8390/wd.c b/drivers/net/ethernet/8390/wd.c
index ad019cbc698f..6efa2722f850 100644
--- a/drivers/net/ethernet/8390/wd.c
+++ b/drivers/net/ethernet/8390/wd.c
@@ -503,10 +503,10 @@ static int irq[MAX_WD_CARDS];
 static int mem[MAX_WD_CARDS];
 static int mem_end[MAX_WD_CARDS];  /* for non std. mem size */
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);

Re: [PATCH 1/4] net: dsa: add support for the SMSC-LAN9303 tagging format

[Andrew Lunn]

On Wed, Apr 05, 2017 at 11:20:21AM +0200, Juergen Borleis wrote:
> To define the outgoing port and to discover the incoming port a regular
> VLAN tag is used by the LAN9303. But its VID meaning is 'special'.
> 
> This tag handler/filter depends on some hardware features which must be
> enabled in the device to provide and make use of this special VLAN tag
> to control the destination and the source of an ethernet packet.
> 
> Signed-off-by: Juergen Borleis 
> ---
>  include/net/dsa.h |   1 +
>  net/dsa/Kconfig   |   3 +
>  net/dsa/Makefile  |   1 +
>  net/dsa/dsa.c |   3 +
>  net/dsa/dsa_priv.h|   3 +
>  net/dsa/tag_lan9303.c | 155 
> ++
>  6 files changed, 166 insertions(+)
>  create mode 100644 net/dsa/tag_lan9303.c
> 
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 4e13e695f0251..4fb1f2b086b05 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -31,6 +31,7 @@ enum dsa_tag_protocol {
>   DSA_TAG_PROTO_EDSA,
>   DSA_TAG_PROTO_BRCM,
>   DSA_TAG_PROTO_QCA,
> + DSA_TAG_PROTO_LAN9303,
>   DSA_TAG_LAST,   /* MUST BE LAST */
>  };
>  
> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index 9649238eef404..22c8bd69ff71c 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -31,4 +31,7 @@ config NET_DSA_TAG_TRAILER
>  config NET_DSA_TAG_QCA
>   bool
>  
> +config NET_DSA_TAG_LAN9303
> + bool
> +
>  endif
> diff --git a/net/dsa/Makefile b/net/dsa/Makefile
> index 31d343796251d..aafc74f2cb193 100644
> --- a/net/dsa/Makefile
> +++ b/net/dsa/Makefile
> @@ -8,3 +8,4 @@ dsa_core-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o
>  dsa_core-$(CONFIG_NET_DSA_TAG_EDSA) += tag_edsa.o
>  dsa_core-$(CONFIG_NET_DSA_TAG_TRAILER) += tag_trailer.o
>  dsa_core-$(CONFIG_NET_DSA_TAG_QCA) += tag_qca.o
> +dsa_core-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index b6d4f6a23f06c..f93f78de23af3 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -53,6 +53,9 @@ const struct dsa_device_ops *dsa_device_ops[DSA_TAG_LAST] = 
> {
>  #ifdef CONFIG_NET_DSA_TAG_QCA
>   [DSA_TAG_PROTO_QCA] = _netdev_ops,
>  #endif
> +#ifdef CONFIG_NET_DSA_TAG_LAN9303
> + [DSA_TAG_PROTO_LAN9303] = _netdev_ops,
> +#endif
>   [DSA_TAG_PROTO_NONE] = _ops,
>  };
>  
> diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
> index 0706a511244e9..a54cfc8aefa83 100644
> --- a/net/dsa/dsa_priv.h
> +++ b/net/dsa/dsa_priv.h
> @@ -85,4 +85,7 @@ extern const struct dsa_device_ops brcm_netdev_ops;
>  /* tag_qca.c */
>  extern const struct dsa_device_ops qca_netdev_ops;
>  
> +/* tag_lan9303.c */
> +extern const struct dsa_device_ops lan9303_netdev_ops;
> +
>  #endif
> diff --git a/net/dsa/tag_lan9303.c b/net/dsa/tag_lan9303.c
> new file mode 100644
> index 0..ad04c6d447f77
> --- /dev/null
> +++ b/net/dsa/tag_lan9303.c
> @@ -0,0 +1,155 @@
> +/*
> + * Copyright (C) 2017 Pengutronix, Juergen Borleis 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2, as published by the Free Software Foundation.
> + *
> + * 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 
> +#include 
> +#include 
> +#include "dsa_priv.h"
> +
> +/* To define the outgoing port and to discover the incoming port a regular
> + * VLAN tag is used by the LAN9303. But its VID meaning is 'special':
> + *
> + *   Dest MAC   Src MACTAGType
> + * ...| 1 2 3 4 5 6 | 1 2 3 4 5 6 | 1 2 3 4 | 1 2 |...
> + *|<--->|
> + * TAG:
> + *|<->|
> + *|  1  2 | 3  4  |
> + *  TPIDVID
> + * 0x8100
> + *
> + * VID bit 3 indicates a request for an ALR lookup.
> + *
> + * If VID bit 3 is zero, then bits 0 and 1 specify the destination port
> + * (0, 1, 2) or broadcast (3) or the source port (1, 2).
> + *
> + * VID bit 4 is used to specify if the STP port state should be overridden.
> + * Required when no forwarding between the external ports should happen.
> + */

Hi Juergen

Nice comment, thanks.

> +
> +#define LAN9303_TAG_LEN 4
> +
> +static struct sk_buff *lan9303_xmit(struct sk_buff *skb, struct net_device 
> *dev)
> +{

...

> + /* make room between MACs and Ether-Type */
> + memmove(skb->data, skb->data + LAN9303_TAG_LEN, 2 * ETH_ALEN);
> +
> + lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN);
> + lan9303_tag[0] = htons(ETH_P_8021Q);
> + lan9303_tag[1] = htons(p->dp->index | BIT(4));

> +static int lan9303_rcv(struct sk_buff *skb, struct net_device *dev,
> +struct packet_type *pt, struct net_device *orig_dev)
> +{
> + u16 *lan9303_tag;

[PATCH 07/38] Annotate hardware config module parameters in drivers/cpufreq/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/cpufreq/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: "Rafael J. Wysocki" 
cc: Viresh Kumar 
cc: linux...@vger.kernel.org
---

 drivers/cpufreq/speedstep-smi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 770a9ae1999a..37b30071c220 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -378,7 +378,7 @@ static void __exit speedstep_exit(void)
cpufreq_unregister_driver(_driver);
 }
 
-module_param(smi_port, int, 0444);
+module_param_hw(smi_port, int, ioport, 0444);
 module_param(smi_cmd,  int, 0444);
 module_param(smi_sig, uint, 0444);
 

Re: [PATCH 2/4] iio: dac: add support for stm32 DAC

[Fabrice Gasnier]

On 04/02/2017 01:32 PM, Jonathan Cameron wrote:
> On 31/03/17 12:45, Fabrice Gasnier wrote:
>> Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage
>> output digital-to-analog converter. It has two output channels, each
>> with its own converter.
>> It supports 8 bits or 12bits left/right aligned data format. Only
>> 12bits right-aligned is used here. It has built-in noise or
>> triangle waveform generator, and supports external triggers for
>> conversions.
>> Each channel can be used independently, with separate trigger, then
>> separate IIO devices are used to handle this. Core driver is intended
>> to share common resources such as clock, reset, reference voltage and
>> registers.
>>
>> Signed-off-by: Fabrice Gasnier 
> Annoyingly my laptop just crashed mid way through reviewing this..
> 
Hi Jonathan,
I hope I have nothing to do with this ;-)

> Ah well, hopefully I'll remember everything (there wasn't much).
> 
> For DACs the 'enable' attribute is not normally used. Rather we
> use the powerdown one.  The reasoning being that we care about what
> the state is when it is powered down.  Even if that isn't controllable
> I would expect to see it exported as powerdown_mode with a fixed value.
> 
Ok, I'll try to use powerdown_mode in V2 as other DACs do. For now,
basically, I'll remap same functionality as 'enable' of this patch.

What do you mean by 'fixed value' ?

But, this also raise me one question:
Current patch use 'enable' to set EN bits in control register. Then, DAC
output goes from Hi-Z to buffered output.
There is also other power modes available. One of them is 'unbuffered':
output buffer can be disabled/bypassed.
This typically can save power, but it only makes sense to use it
depending on output load impedance (This is explained in AN3126 as you
pointed out in later patch).
Current patch uses buffered output (which suits all needs regarding
output load impedance). And the question is...

Should I expose this power modes to userland by using 'powerdown_mode' ?

OR... I'd rather rely on a dt property like st,dac-output-mode to manage
this, because buffered/unbuffered output modes depends on HW output load
impedance. Do you agree with this approach to use:
- powerdown_mode as Hi-Z / enable switch, with dedicated dt property to
set output power mode ?

Please let me know your opinion.

But, I think this can be part of another patchset...

> Other than that - looks pretty good to me.
> 
> Jonathan
> 
>> ---
>>  drivers/iio/dac/Kconfig  |  15 ++
>>  drivers/iio/dac/Makefile |   2 +
>>  drivers/iio/dac/stm32-dac-core.c | 180 
>>  drivers/iio/dac/stm32-dac-core.h |  51 +++
>>  drivers/iio/dac/stm32-dac.c  | 296 
>> +++
>>  5 files changed, 544 insertions(+)
>>  create mode 100644 drivers/iio/dac/stm32-dac-core.c
>>  create mode 100644 drivers/iio/dac/stm32-dac-core.h
>>  create mode 100644 drivers/iio/dac/stm32-dac.c
>>
>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> index d3084028..7198648 100644
>> --- a/drivers/iio/dac/Kconfig
>> +++ b/drivers/iio/dac/Kconfig
>> @@ -274,6 +274,21 @@ config MCP4922
>>To compile this driver as a module, choose M here: the module
>>will be called mcp4922.
>>  
>> +config STM32_DAC
>> +tristate "STMicroelectronics STM32 DAC"
>> +depends on (ARCH_STM32 && OF) || COMPILE_TEST
>> +depends on REGULATOR
>> +select STM32_DAC_CORE
>> +help
>> +  Say yes here to build support for STMicroelectronics STM32 Digital
>> +  to Analog Converter (DAC).
>> +
>> +  This driver can also be built as a module.  If so, the module
>> +  will be called stm32-dac.
>> +
>> +config STM32_DAC_CORE
>> +tristate
>> +
>>  config VF610_DAC
>>  tristate "Vybrid vf610 DAC driver"
>>  depends on OF
>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>> index f01bf4a..afe8ae7 100644
>> --- a/drivers/iio/dac/Makefile
>> +++ b/drivers/iio/dac/Makefile
>> @@ -29,4 +29,6 @@ obj-$(CONFIG_MAX517) += max517.o
>>  obj-$(CONFIG_MAX5821) += max5821.o
>>  obj-$(CONFIG_MCP4725) += mcp4725.o
>>  obj-$(CONFIG_MCP4922) += mcp4922.o
>> +obj-$(CONFIG_STM32_DAC_CORE) += stm32-dac-core.o
>> +obj-$(CONFIG_STM32_DAC) += stm32-dac.o
>>  obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>> diff --git a/drivers/iio/dac/stm32-dac-core.c 
>> b/drivers/iio/dac/stm32-dac-core.c
>> new file mode 100644
>> index 000..75e4878
>> --- /dev/null
>> +++ b/drivers/iio/dac/stm32-dac-core.c
>> @@ -0,0 +1,180 @@
>> +/*
>> + * This file is part of STM32 DAC driver
>> + *
>> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
>> + * Author: Fabrice Gasnier .
>> + *
>> + * License type: GPLv2
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software 

Re: [PATCH 0/6] mm: make movable onlining suck less

[Reza Arbab]

On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:

On Tue 04-04-17 16:43:39, Reza Arbab wrote:
Okay, getting further. With this I can again repeatedly add and 
remove, but now I'm seeing a weird variation of that earlier issue:


1. add_memory(), online_movable
  /sys/devices/system/node/nodeX/memoryY symlinks are created.

2. offline, remove_memory()
  The node is offlined, since all memory has been removed, so all of
  /sys/devices/system/node/nodeX is gone. This is normal.

3. add_memory(), online_movable
  The node is onlined, so /sys/devices/system/node/nodeX is recreated,
  and the memory is added, but just like earlier in this email thread,
  the memoryY links are not there.


Could you add some printks to see why the sysfs creation failed please?


Ah, simple enough. It's this, right at the top of 
register_mem_sect_under_node():


if (!node_online(nid))
return 0;

That being the case, I really don't understand why your patches make any 
difference. Is node_set_online() being called later than before somehow?


--
Reza Arbab

Re: [PATCH] ARM: dts: armada-38x: label USB and SATA nodes

[Gregory CLEMENT]

Hi Andrew,
 
 On ven., mars 31 2017, Andrew Lunn  wrote:

> On Fri, Mar 31, 2017 at 07:39:20PM +0200, Ralph Sennhauser wrote:
>> On Fri, 31 Mar 2017 18:50:15 +0200
>> Andrew Lunn  wrote:
>> 
>> > > -sata@a8000 {
>> > > +satac0: sata@a8000 {  
>> > 
>> > Hi Ralph
>> > 
>> > Why the c in satac0?
>> 
>> For controller and to not conflict with a use case of sata0 for a port,
>> similarly to pciec and pcie1. See armada-385-synology-ds116.dts.
>
> :~/linux/arch/arm/boot/dts$ ls *ds116*
> ls: cannot access '*ds116*': No such file or directory
>
> But anyway, a few boards seem to solve this by calling the controller
> node ahci0: and the port sata0:
>
>> > > -usb3@f {
>> > > +usb3_0: usb3@f {
>> > >  compatible =
>> > > "marvell,armada-380-xhci"; reg = <0xf 0x4000>,<0xf4000 0x4000>;
>> > >  interrupts = > > > IRQ_TYPE_LEVEL_HIGH>; @@ -598,7 +598,7 @@
>> > >  status = "disabled";
>> > >  };
>> > >  
>> > > -usb3@f8000 {
>> > > +usb3_1: usb3@f8000 {
>> > >  compatible =
>> > > "marvell,armada-380-xhci"; reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
>> > >  interrupts = > > > IRQ_TYPE_LEVEL_HIGH>;  
>> > 
>> > I can understand what you are saying. But does anybody else care? Are
>> > there other .dtsi files differentiating between USB 1.1, 2 and 3?
>> 
>> It's handled differently where ever I looked, some do some don't. A
>> case for distinguishing USB 2.0 and USB 3.0 like this is
>> armada-388-gp.dts.

Actually I care and I found confusing calling usb2 the second usb port if
it is controlled by an USB3 controller.

>
> Humm...
>
> /* CON4 */
> usb@58000 {
> vcc-supply = <_usb2_0_vbus>;
> status = "okay";
> };
>
>
>   /* CON5 */
> usb3@f {
> usb-phy = <_1_phy>;
> status = "okay";
> };
>
> /* CON7 */
> usb3@f8000 {
> usb-phy = <_phy>;
> status = "okay";
> };
>
> Is this clear? Is CON5 a USB 3 host, but has a USB 2 PHY connected to
> it? CON7 is the only true USB 3 port? I think some comments written in

I can answer it: CON5 is indeed an USB3 host with a USB2 PHY connected
to it so we can use it only as an USB2. And indeed CON7 is the only true
USB3 port.

> schwiizerdütsch would be clearre.:-)

Actually all your assumption were correct so maybe it is not as
confusing as it looks! :)  But I can add a comment if needed.

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH] remove the obsolete hd driver

[Martin K. Petersen]

Christoph Hellwig  writes:

> This driver is for pre-IDE hardisk that are only found in PC from the
> stoneage of personal computing, and which we don't support elsewhere
> in the kernel these days.
>
> It's also been marked broken forever.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] remove the obsolete hd driver

[Jens Axboe]

On 04/05/2017 07:59 AM, Christoph Hellwig wrote:
> This driver is for pre-IDE hardisk that are only found in PC from the
> stoneage of personal computing, and which we don't support elsewhere
> in the kernel these days.
> 
> It's also been marked broken forever.

Applied for 4.12, who'd trust their data to a driver written by Linus
anyway. Good riddance.

-- 
Jens Axboe

[PATCH v6 21/23] Documentation: PCI: Add userguide for PCI endpoint test function

[Kishon Vijay Abraham I]

Add documentation to help users use pci-epf-test function driver and
pci_endpoint_test host driver for testing PCI.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
---
 Documentation/PCI/00-INDEX|   2 +
 Documentation/PCI/endpoint/pci-test-howto.txt | 179 ++
 2 files changed, 181 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-howto.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 2fc901a1c32e..00c9a90b6f38 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -18,5 +18,7 @@ endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the PCI endpoint function.
 endpoint/pci-test-function.txt
- specification of *PCI test* function device.
+endpoint/pci-test-howto.txt
+   - userguide for PCI endpoint test function.
 endpoint/function/binding/
- binding documentation for PCI endpoint function
diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt 
b/Documentation/PCI/endpoint/pci-test-howto.txt
new file mode 100644
index ..75f48c3bb191
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-howto.txt
@@ -0,0 +1,179 @@
+   PCI TEST USERGUIDE
+   Kishon Vijay Abraham I 
+
+This document is a guide to help users use pci-epf-test function driver
+and pci_endpoint_test host driver for testing PCI. The list of steps to
+be followed in the host side and EP side is given below.
+
+1. Endpoint Device
+
+1.1 Endpoint Controller Devices
+
+To find the list of endpoint controller devices in the system:
+
+   # ls /sys/class/pci_epc/
+ 5100.pcie_ep
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+   # ls /sys/kernel/config/pci_ep/controllers
+ 5100.pcie_ep
+
+1.2 Endpoint Function Drivers
+
+To find the list of endpoint function drivers in the system:
+
+   # ls /sys/bus/pci-epf/drivers
+ pci_epf_test
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+   # ls /sys/kernel/config/pci_ep/functions
+ pci_epf_test
+
+1.3 Creating pci-epf-test Device
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-test device, the following commands can be used
+
+   # mount -t configfs none /sys/kernel/config
+   # cd /sys/kernel/config/pci_ep/
+   # mkdir functions/pci_epf_test/func1
+
+The "mkdir func1" above creates the pci-epf-test function device that will
+be probed by pci_epf_test driver.
+
+The PCI endpoint framework populates the directory with the following
+configurable fields.
+
+   # ls functions/pci_epf_test/func1
+ baseclass_codeinterrupt_pin   revid   subsys_vendor_id
+ cache_line_size   msi_interrupts  subclass_code   vendorid
+ deviceid  progif_code subsys_id
+
+The PCI endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-test driver populates
+vendorid with 0x and interrupt_pin with 0x0001
+
+   # cat functions/pci_epf_test/func1/vendorid
+ 0x
+   # cat functions/pci_epf_test/func1/interrupt_pin
+ 0x0001
+
+1.4 Configuring pci-epf-test Device
+
+The user can configure the pci-epf-test device using configfs entry. In order
+to change the vendorid and the number of MSI interrupts used by the function
+device, the following commands can be used.
+
+   # echo 0x104c > functions/pci_epf_test/func1/vendorid
+   # echo 0xb500 > functions/pci_epf_test/func1/deviceid
+   # echo 16 > functions/pci_epf_test/func1/msi_interrupts
+
+1.5 Binding pci-epf-test Device to EP Controller
+
+In order for the endpoint function device to be useful, it has to be bound to
+a PCI endpoint controller driver. Use the configfs to bind the function
+device to one of the controller driver present in the system.
+
+   # ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
+
+Once the above step is completed, the PCI endpoint is ready to establish a link
+with the host.
+
+1.6 Start the Link
+
+In order for the endpoint device to establish a link with the host, the _start_
+field should be populated with '1'.
+
+   # echo 1 > controllers/5100.pcie_ep/start
+
+2. RootComplex Device
+
+2.1 lspci Output
+
+Note that the devices listed here correspond to the value populated in 1.4 
above
+
+   00:00.0 PCI bridge: Texas Instruments Device  (rev 01)
+   01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
+
+2.2 Using Endpoint Test function Device
+
+pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
+tests. Before pcitest.sh can be used pcitest.c should be compiled using the
+following commands.
+
+   cd 
+   make headers_install ARCH=arm
+   arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
+   cp pcitest  /usr/sbin/

[PATCH v6 16/23] PCI: Add device IDs for DRA74x and DRA72x

[Kishon Vijay Abraham I]

Add device IDs for DRA74x and DRA72x devices. These devices have
configurable PCI endpoint.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index a4f77feecbb0..5f6b71d15393 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -862,6 +862,8 @@
 #define PCI_DEVICE_ID_TI_X620  0xac8d
 #define PCI_DEVICE_ID_TI_X420  0xac8e
 #define PCI_DEVICE_ID_TI_XX20_FM   0xac8f
+#define PCI_DEVICE_ID_TI_DRA74x0xb500
+#define PCI_DEVICE_ID_TI_DRA72x0xb501
 
 #define PCI_VENDOR_ID_SONY 0x104d
 
-- 
2.11.0

Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver

[Vlad Zakharov]

Hi Stephen,

On Tue, 2017-04-04 at 18:35 -0700, Stephen Boyd wrote:
> > + .pll_table = (struct pll_of_table []){
> > + {
> > + .prate = 2700,
> 
> Can this be another clk in the framework instead of hardcoding
> the parent rate?

In fact there is another clk in the framework that represents this parent 
clock. But this field is needed to get
appropriate pll_cfg_table as it depends on parent clock frequency. Below in 
pll_cfg_get function we are searching for
the correct table comparing .parent_node field with real hardware parent clock 
frequency:
-->8
for (i = 0; pll_table[i].prate != 0; i++)
    if (pll_table[i].prate == prate)
        return pll_table[i].pll_cfg_table;
-->8

> 
> > + .pll_cfg_table = (struct pll_cfg []){
> > + { 2520, 1, 84, 90 },
> > + { 5000, 1, 100, 54 },
> > + { 7425, 1, 44, 16 },
> > + { },
> > + },
> > + },
> > + /* Used as list limiter */
> > + { },
> 
> There's only ever one, so I'm confused why we're making a list.

By this patch we only add support of core arc pll and pgu pll and today they 
are clocked by the only parent clocks
introduced here. But other plls on axs10x may be driven by different or 
configurable clocks, so in such cases we will
have more than one entry in this list. And we are going to add more supported 
plls to this driver in the nearest future.

> > +
> > + clk = clk_register(NULL, _clk->hw);
> > + if (IS_ERR(clk)) {
> > + pr_err("failed to register %s clock (%ld)\n",
> > + node->name, PTR_ERR(clk));
> > + kfree(pll_clk);
> > + return;
> > + }
> > +
> > + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> 
> Can you please use the clk_hw based provider and clk registration
> functions?

Sure. Could you be so kind to explain what is the difference between hw and 
non-hw based provider and clk registration
functions please? In which cases they are preferred? 

> 
> > +}
> > +
> > +CLK_OF_DECLARE(axs10x_pll_clock, "snps,axs10x-arc-pll-clock", 
> > of_pll_clk_setup);
> 
> Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the
> driver need to probe and also have this of declare happen? Is the
> PLL special and needs to be used for the timers?

It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On 
the other hand similar pll is used to
drive PGU clock frequency and other subsystems and so we add usual probe func.

-- 
Best regards,
Vlad Zakharov 

Re: [PATCH] fixup! gpu: host1x: Add IOMMU support

[Thierry Reding]

On Wed, Apr 05, 2017 at 10:45:44AM +0300, Mikko Perttunen wrote:
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/gpu/host1x/dev.c | 1 +
>  1 file changed, 1 insertion(+)

Applied this to the drm/tegra tree and pushed it out. Verified that
merging it into linux-next builds fine on various configurations.

Thierry


signature.asc
Description: PGP signature

Re: [RFC][PATCH v2 1/5] ptrace: Don't wait in PTRACE_O_TRACEEXIT for exec or coredump

[Oleg Nesterov]

On 04/02, Eric W. Biederman wrote:
>
> In the case of exec and coredump which have many interesting deadlock
> opportunities

So this patch is very close to my 2/2 one-liner, except

- you removed the current->mm == current->parent->mm check

  I didn't do this on purpose, because even the->core_state
  is not really needed if we check ->group_exit_task, this
  need more changes anyway, but I won't argue.

- With your patch we send the notification to debugger even
  if we are not going to stop.

  This is not wrong, but why? This is pointless, nobody rely
  on SIGCHLD, if nothing else it doesn't queue.

  Again, I won't argue, but this complicates both the patch
  and the code for no reason. Unless I missed something.

> Keep sending the signal to the tracer so that this appears like
> the worst case where someone else sent the process a SIGKILL before
> the tracer could react.  So all non-buggy tracers must support
> this case.

Well, I can't understand the changelog. Sure, debugger must support
this case, but obviously this can break things anyway.

For example. The coredumping thread must stop in PTRACE_EVENT_EXIT.
There is a tool (I don't remember its name) which does
ptrace_attach(PTRACE_SEIZE, PTRACE_O_TRACEEXIT) after the coredump
was already started, closes the pipe, and reads the registers when
this thread actually exits.

This patch or my 2/2 should not break it, ->group_exit_task will be
cleared after do_coredump(), but unfortunately something else can be
broken.

So I think the changelog should mention that yes, this is the user
visible change which _can_ break something anyway.

In short. I will be really happy if this patch comes from you, not me ;)

Oleg.

[for-next][PATCH 5/7] ftrace: Create separate t_func_next() to simplify the function / hash logic

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

I noticed that if I use dd to read the set_ftrace_filter file that the first
hash command is repeated.

 # cd /sys/kernel/debug/tracing
 # echo schedule > set_ftrace_filter
 # echo do_IRQ >> set_ftrace_filter
 # echo schedule:traceoff >> set_ftrace_filter
 # echo do_IRQ:traceoff >> set_ftrace_filter

 # cat set_ftrace_filter
 schedule
 do_IRQ
 schedule:traceoff:unlimited
 do_IRQ:traceoff:unlimited

 # dd if=set_ftrace_filter bs=1
 schedule
 do_IRQ
 schedule:traceoff:unlimited
 schedule:traceoff:unlimited
 do_IRQ:traceoff:unlimited
 98+0 records in
 98+0 records out
 98 bytes copied, 0.00265011 s, 37.0 kB/s

This is due to the way t_start() calls t_next() as well as the seq_file
calls t_next() and the state is slightly different between the two. Namely,
t_start() will call t_next() with a local "pos" variable.

By separating out the function listing from t_next() into its own function,
we can have better control of outputting the functions and the hash of
triggers. This simplifies the code.

Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/ftrace.c | 45 +++--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index d4b18ce9ba88..aff7a2c08387 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3154,22 +3154,12 @@ t_hash_show(struct seq_file *m, struct ftrace_iterator 
*iter)
 }
 
 static void *
-t_next(struct seq_file *m, void *v, loff_t *pos)
+t_func_next(struct seq_file *m, loff_t *pos)
 {
struct ftrace_iterator *iter = m->private;
struct dyn_ftrace *rec = NULL;
 
-   if (unlikely(ftrace_disabled))
-   return NULL;
-
-   if (iter->flags & FTRACE_ITER_HASH)
-   return t_hash_next(m, pos);
-
(*pos)++;
-   iter->pos = iter->func_pos = *pos;
-
-   if (iter->flags & FTRACE_ITER_PRINTALL)
-   return t_hash_start(m, pos);
 
  retry:
if (iter->idx >= iter->pg->index) {
@@ -3192,13 +3182,40 @@ t_next(struct seq_file *m, void *v, loff_t *pos)
}
 
if (!rec)
-   return t_hash_start(m, pos);
+   return NULL;
 
+   iter->pos = iter->func_pos = *pos;
iter->func = rec;
 
return iter;
 }
 
+static void *
+t_next(struct seq_file *m, void *v, loff_t *pos)
+{
+   struct ftrace_iterator *iter = m->private;
+   void *ret;
+
+   if (unlikely(ftrace_disabled))
+   return NULL;
+
+   if (iter->flags & FTRACE_ITER_HASH)
+   return t_hash_next(m, pos);
+
+   if (iter->flags & FTRACE_ITER_PRINTALL) {
+   /* next must increment pos, and t_hash_start does not */
+   (*pos)++;
+   return t_hash_start(m, pos);
+   }
+
+   ret = t_func_next(m, pos);
+
+   if (!ret)
+   return t_hash_start(m, pos);
+
+   return ret;
+}
+
 static void reset_iter_read(struct ftrace_iterator *iter)
 {
iter->pos = 0;
@@ -3250,13 +3267,13 @@ static void *t_start(struct seq_file *m, loff_t *pos)
iter->pg = ftrace_pages_start;
iter->idx = 0;
for (l = 0; l <= *pos; ) {
-   p = t_next(m, p, );
+   p = t_func_next(m, );
if (!p)
break;
}
 
if (!p)
-   return NULL;
+   return t_hash_start(m, pos);
 
return iter;
 }
-- 
2.10.2

[for-next][PATCH 6/7] ftrace: Have init/main.c call ftrace directly to free init memory

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

Relying on free_reserved_area() to call ftrace to free init memory proved to
not be sufficient. The issue is that on x86, when debug_pagealloc is
enabled, the init memory is not freed, but simply set as not present. Since
ftrace was uninformed of this, starting function tracing still tries to
update pages that are not present according to the page tables, causing
ftrace to bug, as well as killing the kernel itself.

Instead of relying on free_reserved_area(), have init/main.c call ftrace
directly just before it frees the init memory. Then it needs to use
__init_begin and __init_end to know where the init memory location is.
Looking at all archs (and testing what I can), it appears that this should
work for each of them.

Reported-by: kernel test robot 
Reported-by: Fengguang Wu 
Signed-off-by: Steven Rostedt (VMware) 
---
 include/linux/ftrace.h | 6 +++---
 init/main.c| 1 +
 kernel/trace/ftrace.c  | 7 ---
 mm/page_alloc.c| 3 ---
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 0276a2c487e6..ef7123219f14 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -147,9 +147,9 @@ struct ftrace_ops_hash {
struct mutexregex_lock;
 };
 
-void ftrace_free_mem(void *start, void *end);
+void ftrace_free_init_mem(void);
 #else
-static inline void ftrace_free_mem(void *start, void *end) { }
+static inline void ftrace_free_init_mem(void) { }
 #endif
 
 /*
@@ -266,7 +266,7 @@ static inline int ftrace_nr_registered_ops(void)
 }
 static inline void clear_ftrace_function(void) { }
 static inline void ftrace_kill(void) { }
-static inline void ftrace_free_mem(void *start, void *end) { }
+static inline void ftrace_free_init_mem(void) { }
 #endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_STACK_TRACER
diff --git a/init/main.c b/init/main.c
index c0137b916aa1..0e8849f74561 100644
--- a/init/main.c
+++ b/init/main.c
@@ -962,6 +962,7 @@ static int __ref kernel_init(void *unused)
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
+   ftrace_free_init_mem();
free_initmem();
mark_readonly();
system_state = SYSTEM_RUNNING;
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index aff7a2c08387..8efd9fe7aec0 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -36,6 +36,7 @@
 
 #include 
 
+#include 
 #include 
 
 #include "trace_output.h"
@@ -5279,10 +5280,10 @@ void ftrace_module_init(struct module *mod)
 }
 #endif /* CONFIG_MODULES */
 
-void ftrace_free_mem(void *start_ptr, void *end_ptr)
+void __init ftrace_free_init_mem(void)
 {
-   unsigned long start = (unsigned long)start_ptr;
-   unsigned long end = (unsigned long)end_ptr;
+   unsigned long start = (unsigned long)(&__init_begin);
+   unsigned long end = (unsigned long)(&__init_end);
struct ftrace_page **last_pg = _pages_start;
struct ftrace_page *pg;
struct dyn_ftrace *rec;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eee82bfb7cd8..178bf9c2a2cb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6606,9 +6606,6 @@ unsigned long free_reserved_area(void *start, void *end, 
int poison, char *s)
void *pos;
unsigned long pages = 0;
 
-   /* This may be .init text, inform ftrace to remove it */
-   ftrace_free_mem(start, end);
-
start = (void *)PAGE_ALIGN((unsigned long)start);
end = (void *)((unsigned long)end & PAGE_MASK);
for (pos = start; pos < end; pos += PAGE_SIZE, pages++) {
-- 
2.10.2

[for-next][PATCH 7/7] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

[Steven Rostedt]

From: Alban Crequy 

When a kretprobe is installed on a kernel function, there is a maximum
limit of how many calls in parallel it can catch (aka "maxactive"). A
kernel module could call register_kretprobe() and initialize maxactive
(see example in samples/kprobes/kretprobe_example.c).

But that is not exposed to userspace and it is currently not possible to
choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events

The default maxactive can be as low as 1 on single-core with a
non-preemptive kernel. This is too low and we need to increase it not
only for recursive functions, but for functions that sleep or resched.

This patch updates the format of the command that can be written to
kprobe_events so that maxactive can be optionally specified.

I need this for a bpf program attached to the kretprobe of
inet_csk_accept, which can sleep for a long time.

This patch includes a basic selftest:

> # ./ftracetest -v  test.d/kprobe/
> === Ftrace unit tests ===
> [1] Kprobe dynamic event - adding and removing[PASS]
> [2] Kprobe dynamic event - busy event check   [PASS]
> [3] Kprobe dynamic event with arguments   [PASS]
> [4] Kprobes event arguments with types[PASS]
> [5] Kprobe dynamic event with function tracer [PASS]
> [6] Kretprobe dynamic event with arguments[PASS]
> [7] Kretprobe dynamic event with maxactive[PASS]
>
> # of passed:  7
> # of failed:  0
> # of unresolved:  0
> # of untested:  0
> # of unsupported:  0
> # of xfailed:  0
> # of undefined(test bug):  0

BugLink: https://github.com/iovisor/bcc/issues/1072
Link: 
http://lkml.kernel.org/r/1491215782-15490-1-git-send-email-al...@kinvolk.io

Acked-by: Masami Hiramatsu 
Signed-off-by: Alban Crequy 
Signed-off-by: Steven Rostedt (VMware) 
---
 Documentation/trace/kprobetrace.txt|  5 ++-
 kernel/trace/trace_kprobe.c| 39 ++
 .../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 ++
 3 files changed, 76 insertions(+), 7 deletions(-)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index 41ef9d8efe95..25f39601a7f7 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via
 Synopsis of kprobe_events
 -
   p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe
-  r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]: Set a return probe
+  r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe
   -:[GRP/]EVENT: Clear a probe
 
  GRP   : Group name. If omitted, use "kprobes" for it.
@@ -32,6 +32,9 @@ Synopsis of kprobe_events
  MOD   : Module name which has given SYM.
  SYM[+offs]: Symbol+offset where the probe is inserted.
  MEMADDR   : Address where the probe is inserted.
+ MAXACTIVE : Maximum number of instances of the specified function that
+ can be probed simultaneously, or 0 for the default value
+ as defined in Documentation/kprobes.txt section 1.3.1.
 
  FETCHARGS : Arguments. Each probe can have up to 128 args.
   %REG : Fetch register REG
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5f688cc724f0..f01d49b576c0 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -25,6 +25,7 @@
 #include "trace_probe.h"
 
 #define KPROBE_EVENT_SYSTEM "kprobes"
+#define KRETPROBE_MAXACTIVE_MAX 4096
 
 /**
  * Kprobe event core functions
@@ -282,6 +283,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
 void *addr,
 const char *symbol,
 unsigned long offs,
+int maxactive,
 int nargs, bool is_return)
 {
struct trace_kprobe *tk;
@@ -309,6 +311,8 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
else
tk->rp.kp.pre_handler = kprobe_dispatcher;
 
+   tk->rp.maxactive = maxactive;
+
if (!event || !is_good_name(event)) {
ret = -EINVAL;
goto error;
@@ -598,8 +602,10 @@ static int create_trace_kprobe(int argc, char **argv)
 {
/*
 * Argument syntax:
-*  - Add kprobe: p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
-*  - Add kretprobe: r[:[GRP/]EVENT] [MOD:]KSYM[+0] [FETCHARGS]
+*  - Add kprobe:
+*  p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
+*  - Add kretprobe:
+*  r[MAXACTIVE][:[GRP/]EVENT] [MOD:]KSYM[+0] 

[PATCH v5 7/7] ARM: sun5i: chip: enable battery power supply subnode

[Quentin Schulz]

The NextThing Co. CHIP has an AXP209 PMIC with battery connector.

This enables the battery power supply subnode.

Signed-off-by: Quentin Schulz 
Acked-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index d078560..879a4b0 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -132,6 +132,10 @@
status = "okay";
 };
 
+_power_supply {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.9.3

[PATCH 16/38] Annotate hardware config module parameters in drivers/net/appletalk/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/appletalk/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
cc: Arnaldo Carvalho de Melo 
cc: net...@vger.kernel.org
---

 drivers/net/appletalk/cops.c |6 +++---
 drivers/net/appletalk/ltpc.c |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/appletalk/cops.c b/drivers/net/appletalk/cops.c
index 1b2e9217ec78..486e1e6997fc 100644
--- a/drivers/net/appletalk/cops.c
+++ b/drivers/net/appletalk/cops.c
@@ -986,9 +986,9 @@ static int cops_close(struct net_device *dev)
 static struct net_device *cops_dev;
 
 MODULE_LICENSE("GPL");
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(board_type, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(board_type, int, other, 0);
 
 static int __init cops_module_init(void)
 {
diff --git a/drivers/net/appletalk/ltpc.c b/drivers/net/appletalk/ltpc.c
index 01e2ac55c137..ac755d2950a6 100644
--- a/drivers/net/appletalk/ltpc.c
+++ b/drivers/net/appletalk/ltpc.c
@@ -1231,9 +1231,9 @@ static struct net_device *dev_ltpc;
 
 MODULE_LICENSE("GPL");
 module_param(debug, int, 0);
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(dma, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(dma, int, dma, 0);
 
 
 static int __init ltpc_module_init(void)

[PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

[Matthias Kaehlcke]

From: Greg Hackmann 

The current definition of ASM_EXPORT doesn't work properly with clang,
according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
gcc specific behavior. Change the constraint from an intermediate to an
output expression which works with both gcc and clang.

From: Greg Hackmann 
Commit-message-by: Matthias Kaehlcke 
Signed-off-by: Greg Hackmann 
Signed-off-by: Matthias Kaehlcke 
---
 arch/arm64/crypto/sha1-ce-glue.c | 2 +-
 arch/arm64/crypto/sha2-ce-glue.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
index aefda9868627..c71e94ba0e43 100644
--- a/arch/arm64/crypto/sha1-ce-glue.c
+++ b/arch/arm64/crypto/sha1-ce-glue.c
@@ -18,7 +18,7 @@
 #include 
 
 #define ASM_EXPORT(sym, val) \
-   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
 
 MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
 MODULE_AUTHOR("Ard Biesheuvel ");
diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
index 7cd587564a41..381b5fb2dcb2 100644
--- a/arch/arm64/crypto/sha2-ce-glue.c
+++ b/arch/arm64/crypto/sha2-ce-glue.c
@@ -18,7 +18,7 @@
 #include 
 
 #define ASM_EXPORT(sym, val) \
-   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
 
 MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
Extensions");
 MODULE_AUTHOR("Ard Biesheuvel ");
-- 
2.12.2.715.g7642488e1d-goog

[PATCH 25/38] Annotate hardware config module parameters in drivers/pci/hotplug/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/pci/hotplug/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: Bjorn Helgaas 
cc: Scott Murray 
cc: linux-...@vger.kernel.org
---

 drivers/pci/hotplug/cpcihp_generic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/hotplug/cpcihp_generic.c 
b/drivers/pci/hotplug/cpcihp_generic.c
index 88a44a707b96..bbf9cf8aeaad 100644
--- a/drivers/pci/hotplug/cpcihp_generic.c
+++ b/drivers/pci/hotplug/cpcihp_generic.c
@@ -220,7 +220,7 @@ module_param(first_slot, byte, 0);
 MODULE_PARM_DESC(first_slot, "Hotswap bus first slot number");
 module_param(last_slot, byte, 0);
 MODULE_PARM_DESC(last_slot, "Hotswap bus last slot number");
-module_param(port, ushort, 0);
+module_param_hw(port, ushort, ioport, 0);
 MODULE_PARM_DESC(port, "#ENUM signal I/O port");
 module_param(enum_bit, uint, 0);
 MODULE_PARM_DESC(enum_bit, "#ENUM signal bit (0-7)");

[PATCH 11/38] Annotate hardware config module parameters in drivers/input/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/input/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: Dmitry Torokhov 
cc: linux-in...@vger.kernel.org
---

 drivers/input/mouse/inport.c  |2 +-
 drivers/input/mouse/logibm.c  |2 +-
 drivers/input/touchscreen/mk712.c |4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/input/mouse/inport.c b/drivers/input/mouse/inport.c
index 3827a22362de..9ce71dfa0de1 100644
--- a/drivers/input/mouse/inport.c
+++ b/drivers/input/mouse/inport.c
@@ -78,7 +78,7 @@ MODULE_LICENSE("GPL");
 #define INPORT_IRQ 5
 
 static int inport_irq = INPORT_IRQ;
-module_param_named(irq, inport_irq, uint, 0);
+module_param_hw_named(irq, inport_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ number (5=default)");
 
 static struct input_dev *inport_dev;
diff --git a/drivers/input/mouse/logibm.c b/drivers/input/mouse/logibm.c
index e2413113df22..6f165e053f4d 100644
--- a/drivers/input/mouse/logibm.c
+++ b/drivers/input/mouse/logibm.c
@@ -69,7 +69,7 @@ MODULE_LICENSE("GPL");
 #define LOGIBM_IRQ 5
 
 static int logibm_irq = LOGIBM_IRQ;
-module_param_named(irq, logibm_irq, uint, 0);
+module_param_hw_named(irq, logibm_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ number (5=default)");
 
 static struct input_dev *logibm_dev;
diff --git a/drivers/input/touchscreen/mk712.c 
b/drivers/input/touchscreen/mk712.c
index 36e57deacd03..bd5352824f77 100644
--- a/drivers/input/touchscreen/mk712.c
+++ b/drivers/input/touchscreen/mk712.c
@@ -50,11 +50,11 @@ MODULE_DESCRIPTION("ICS MicroClock MK712 TouchScreen 
driver");
 MODULE_LICENSE("GPL");
 
 static unsigned int mk712_io = 0x260;  /* Also 0x200, 0x208, 0x300 */
-module_param_named(io, mk712_io, uint, 0);
+module_param_hw_named(io, mk712_io, uint, ioport, 0);
 MODULE_PARM_DESC(io, "I/O base address of MK712 touchscreen controller");
 
 static unsigned int mk712_irq = 10;/* Also 12, 14, 15 */
-module_param_named(irq, mk712_irq, uint, 0);
+module_param_hw_named(irq, mk712_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ of MK712 touchscreen controller");
 
 /* eight 8-bit registers */

Applied "ASoC: sta529: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoC: sta529: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 9abe464821a0e66c0343ce943f3eb343bf8990f3 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:27 -0400
Subject: [PATCH] ASoC: sta529: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-sta529.ko | grep alias
alias:  i2c:sta529

After this patch:

$ modinfo sound/soc/codecs/snd-soc-sta529.ko | grep alias
alias:  of:N*T*Cst,sta529C*
alias:  of:N*T*Cst,sta529
alias:  i2c:sta529

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/sta529.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/codecs/sta529.c b/sound/soc/codecs/sta529.c
index d4b384e4b266..660734359bf3 100644
--- a/sound/soc/codecs/sta529.c
+++ b/sound/soc/codecs/sta529.c
@@ -375,9 +375,16 @@ static const struct i2c_device_id sta529_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, sta529_i2c_id);
 
+static const struct of_device_id sta529_of_match[] = {
+   { .compatible = "st,sta529", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, sta529_of_match);
+
 static struct i2c_driver sta529_i2c_driver = {
.driver = {
.name = "sta529",
+   .of_match_table = sta529_of_match,
},
.probe  = sta529_i2c_probe,
.remove = sta529_i2c_remove,
-- 
2.11.0

Applied "ASoC: ssm4567: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoC: ssm4567: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 71c314d7ef2442cd798584a3dece8151215e1777 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:26 -0400
Subject: [PATCH] ASoC: ssm4567: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-ssm4567.ko | grep alias
alias:  acpi*:INT343B:*
alias:  i2c:ssm4567

After this patch:

$ modinfo sound/soc/codecs/snd-soc-ssm4567.ko | grep alias
alias:  acpi*:INT343B:*
alias:  of:N*T*Cadi,ssm4567C*
alias:  of:N*T*Cadi,ssm4567
alias:  i2c:ssm4567

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/ssm4567.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/sound/soc/codecs/ssm4567.c b/sound/soc/codecs/ssm4567.c
index 2bb5a11c9ba1..a622623e8558 100644
--- a/sound/soc/codecs/ssm4567.c
+++ b/sound/soc/codecs/ssm4567.c
@@ -485,6 +485,14 @@ static const struct i2c_device_id ssm4567_i2c_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ssm4567_i2c_ids);
 
+#ifdef CONFIG_OF
+static const struct of_device_id ssm4567_of_match[] = {
+   { .compatible = "adi,ssm4567", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, ssm4567_of_match);
+#endif
+
 #ifdef CONFIG_ACPI
 
 static const struct acpi_device_id ssm4567_acpi_match[] = {
@@ -498,6 +506,7 @@ MODULE_DEVICE_TABLE(acpi, ssm4567_acpi_match);
 static struct i2c_driver ssm4567_driver = {
.driver = {
.name = "ssm4567",
+   .of_match_table = of_match_ptr(ssm4567_of_match),
.acpi_match_table = ACPI_PTR(ssm4567_acpi_match),
},
.probe = ssm4567_i2c_probe,
-- 
2.11.0

Applied "ASoC: rt5677: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoC: rt5677: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7b87463edf3e2c16d72eeea3d1cf3c12bb5487c6 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:30 -0400
Subject: [PATCH] ASoC: rt5677: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias:  i2c:RT5677CE:00
alias:  i2c:rt5676
alias:  i2c:rt5677

After this patch:

$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias:  of:N*T*Crealtek,rt5677C*
alias:  of:N*T*Crealtek,rt5677
alias:  i2c:RT5677CE:00
alias:  i2c:rt5676
alias:  i2c:rt5677

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/rt5677.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c
index abc802a5a479..65ac4518ad06 100644
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -5035,6 +5035,12 @@ static const struct i2c_device_id rt5677_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);
 
+static const struct of_device_id rt5677_of_match[] = {
+   { .compatible = "realtek,rt5677", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, rt5677_of_match);
+
 static const struct acpi_gpio_params plug_det_gpio = { RT5677_GPIO_PLUG_DET, 
0, false };
 static const struct acpi_gpio_params mic_present_gpio = { 
RT5677_GPIO_MIC_PRESENT_L, 0, false };
 static const struct acpi_gpio_params headphone_enable_gpio = { 
RT5677_GPIO_HP_AMP_SHDN_L, 0, false };
@@ -5294,6 +5300,7 @@ static int rt5677_i2c_remove(struct i2c_client *i2c)
 static struct i2c_driver rt5677_i2c_driver = {
.driver = {
.name = "rt5677",
+   .of_match_table = rt5677_of_match,
},
.probe = rt5677_i2c_probe,
.remove   = rt5677_i2c_remove,
-- 
2.11.0

Applied "ASoC: wm8978: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoC: wm8978: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5cf015d9cb02c360582b624497b0a1716881cf28 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:29 -0400
Subject: [PATCH] ASoC: wm8978: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-wm8978.ko | grep alias
alias:  i2c:wm8978

After this patch:

$ modinfo sound/soc/codecs/snd-soc-wm8978.ko | grep alias
alias:  i2c:wm8978
alias:  of:N*T*Cwlf,wm8978C*
alias:  of:N*T*Cwlf,wm8978

Signed-off-by: Javier Martinez Canillas 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/wm8978.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c
index 90b2d418ef60..cf761e2d7546 100644
--- a/sound/soc/codecs/wm8978.c
+++ b/sound/soc/codecs/wm8978.c
@@ -1071,9 +1071,16 @@ static const struct i2c_device_id wm8978_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, wm8978_i2c_id);
 
+static const struct of_device_id wm8978_of_match[] = {
+   { .compatible = "wlf,wm8978", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, wm8978_of_match);
+
 static struct i2c_driver wm8978_i2c_driver = {
.driver = {
.name = "wm8978",
+   .of_match_table = wm8978_of_match,
},
.probe =wm8978_i2c_probe,
.remove =   wm8978_i2c_remove,
-- 
2.11.0

Applied "ASoC: uda1380: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoC: uda1380: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ea22a26e676ebc39a2ba7836e814864bf85324e7 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:28 -0400
Subject: [PATCH] ASoC: uda1380: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-uda1380.ko | grep alias
alias:  i2c:uda1380

After this patch:

$ modinfo sound/soc/codecs/snd-soc-uda1380.ko | grep alias
alias:  of:N*T*Cnxp,uda1380C*
alias:  of:N*T*Cnxp,uda1380
alias:  i2c:uda1380

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/uda1380.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/codecs/uda1380.c b/sound/soc/codecs/uda1380.c
index 2918fdb95e58..61cdc79840e7 100644
--- a/sound/soc/codecs/uda1380.c
+++ b/sound/soc/codecs/uda1380.c
@@ -791,9 +791,16 @@ static const struct i2c_device_id uda1380_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, uda1380_i2c_id);
 
+static const struct of_device_id uda1380_of_match[] = {
+   { .compatible = "nxp,uda1380", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, uda1380_of_match);
+
 static struct i2c_driver uda1380_i2c_driver = {
.driver = {
.name =  "uda1380-codec",
+   .of_match_table = uda1380_of_match,
},
.probe =uda1380_i2c_probe,
.remove =   uda1380_i2c_remove,
-- 
2.11.0

Applied "ASoC: codec: wm9860: Refactor PLL out freq search" to the asoc tree

[Mark Brown]

The patch

   ASoC: codec: wm9860: Refactor PLL out freq search

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 84fdc00d519ffdf8ae6e34d7841bcc6f38928953 Mon Sep 17 00:00:00 2001
From: Daniel Baluta 
Date: Tue, 4 Apr 2017 19:45:13 +0300
Subject: [PATCH] ASoC: codec: wm9860: Refactor PLL out freq search

Add a separate function for deriving (sysclk, lrclk, bclk)
when the clock is auto or pll.

Signed-off-by: Daniel Baluta 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/wm8960.c | 93 ---
 1 file changed, 64 insertions(+), 29 deletions(-)

diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index ce159f13e7a4..36c84549da23 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -672,10 +672,70 @@ int wm8960_configure_sysclk(struct wm8960_priv *wm8960, 
int mclk,
return *bclk_idx;
 }
 
+/**
+ * wm8960_configure_pll - checks if there is a PLL out frequency available
+ * The PLL out frequency must be chosen such that:
+ * - sysclk  = lrclk * dac_divs
+ * - freq_out= sysclk * sysclk_divs
+ * - 10 * sysclk = bclk * bclk_divs
+ *
+ * @codec: codec structure
+ * @freq_in: input frequency used to derive freq out via PLL
+ * @sysclk_idx: sysclk_divs index for found sysclk
+ * @dac_idx: dac_divs index for found lrclk
+ * @bclk_idx: bclk_divs index for found bclk
+ *
+ * Returns:
+ *  -1, in case no PLL frequency out available was found
+ * >=0, in case we could derive bclk, lrclk, sysclk from PLL out using
+ *  (@sysclk_idx, @dac_idx, @bclk_idx) dividers
+ */
+static
+int wm8960_configure_pll(struct snd_soc_codec *codec, int freq_in,
+int *sysclk_idx, int *dac_idx, int *bclk_idx)
+{
+   struct wm8960_priv *wm8960 = snd_soc_codec_get_drvdata(codec);
+   int sysclk, bclk, lrclk, freq_out;
+   int diff, best_freq_out;
+   int i, j, k;
+
+   bclk = wm8960->bclk;
+   lrclk = wm8960->lrclk;
+
+   *bclk_idx = -1;
+
+   for (i = 0; i < ARRAY_SIZE(sysclk_divs); ++i) {
+   if (sysclk_divs[i] == -1)
+   continue;
+   for (j = 0; j < ARRAY_SIZE(dac_divs); ++j) {
+   sysclk = lrclk * dac_divs[j];
+   freq_out = sysclk * sysclk_divs[i];
+
+   for (k = 0; k < ARRAY_SIZE(bclk_divs); ++k) {
+   if (!is_pll_freq_available(freq_in, freq_out))
+   continue;
+
+   diff = sysclk - bclk * bclk_divs[k] / 10;
+   if (diff == 0) {
+   *sysclk_idx = i;
+   *dac_idx = j;
+   *bclk_idx = k;
+   best_freq_out = freq_out;
+   break;
+   }
+   }
+   }
+   }
+
+   if (*bclk_idx != -1)
+   wm8960_set_pll(codec, freq_in, best_freq_out);
+
+   return *bclk_idx;
+}
 static int wm8960_configure_clocking(struct snd_soc_codec *codec)
 {
struct wm8960_priv *wm8960 = snd_soc_codec_get_drvdata(codec);
-   int sysclk, bclk, lrclk, freq_out, freq_in;
+   int freq_out, freq_in;
u16 iface1 = snd_soc_read(codec, WM8960_IFACE1);
int i, j, k;
int ret;
@@ -692,8 +752,6 @@ static int wm8960_configure_clocking(struct snd_soc_codec 
*codec)
}
 
freq_in = wm8960->freq_in;
-   bclk = wm8960->bclk;
-   lrclk = wm8960->lrclk;
/*
 * If it's sysclk auto mode, check if the MCLK can provide sysclk or
 * not. If MCLK can provide sysclk, using MCLK to provide sysclk
@@ -720,33 +778,10 @@ static int wm8960_configure_clocking(struct snd_soc_codec 
*codec)
return -EINVAL;
}
}
-   /* get a available pll out frequency and set pll */
-

Re: [PATCH 0/6] mm: make movable onlining suck less

[Reza Arbab]

On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
But one thing that is really bugging me is how could you see low pfns 
in the previous oops. Please drop the last patch and sprinkle printks 
down the remove_memory path to see where this all go south. I believe 
that there is something in the initialization code lurking in my code. 
Please also scratch the pfn_valid check in online_pages diff. It will 
not help here.


Got it. 


shrink_pgdat_span: start_pfn=0x1, end_pfn=0x10100, pgdat_start_pfn=0x0, 
pgdat_end_pfn=0x2

The problem is that pgdat_start_pfn here should be 0x1. As you 
suspected, it never got set. This fixes things for me.


diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 623507f..37c1b63 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -884,7 +884,7 @@ static void __meminit resize_pgdat_range(struct pglist_data 
*pgdat, unsigned lon
{
unsigned long old_end_pfn = pgdat_end_pfn(pgdat);

-   if (start_pfn < pgdat->node_start_pfn)
+   if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
pgdat->node_start_pfn = start_pfn;

pgdat->node_spanned_pages = max(start_pfn + nr_pages, old_end_pfn) - 
pgdat->node_start_pfn;
---

Along these lines, maybe we should also do

-   if (start_pfn < zone->zone_start_pfn)
+   if (zone_is_empty(zone) || start_pfn < zone->zone_start_pfn)

in resize_zone_range()?

--
Reza Arbab

Re: [PATCH 02/38] Annotate hardware config module parameters in arch/x86/mm/

[Steven Rostedt]

On Wed, 05 Apr 2017 17:57:08 +0100
David Howells  wrote:

> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
> 
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
> 
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
> 
> This patch annotates drivers in arch/x86/mm/.
> 
> Suggested-by: Alan Cox 
> Signed-off-by: David Howells 

Acked-by: Steven Rostedt (VMware) 

-- Steve

> cc: Ingo Molnar 
> cc: Thomas Gleixner 
> cc: "H. Peter Anvin" 
> cc: x...@kernel.org
> cc: linux-kernel@vger.kernel.org
> cc: nouv...@lists.freedesktop.org
> ---
> 
>  arch/x86/mm/testmmiotrace.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index 38868adf07ea..f6ae6830b341 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -9,7 +9,7 @@
>  #include 
>  
>  static unsigned long mmio_address;
> -module_param(mmio_address, ulong, 0);
> +module_param_hw(mmio_address, ulong, iomem, 0);
>  MODULE_PARM_DESC(mmio_address, " Start address of the mapping of 16 kB "
>   "(or 8 MB if read_far is non-zero).");
>  

Re: [PATCH] ebpf: verify the output of the JIT

[kbuild test robot]

Hi Tycho,

[auto build test WARNING on net/master]
[also build test WARNING on v4.11-rc5 next-20170405]
[cannot apply to tip/x86/core]
[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/Tycho-Andersen/ebpf-verify-the-output-of-the-JIT/20170406-004746
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   arch/x86/net/bpf_jit_comp.c: In function 'do_jit':
>> arch/x86/net/bpf_jit_comp.c:1098:1: warning: the frame size of 13024 bytes 
>> is larger than 8192 bytes [-Wframe-larger-than=]
}
^

vim +1098 arch/x86/net/bpf_jit_comp.c

9383191d Daniel Borkmann2017-02-16  1082
pr_err("bpf_jit: fatal insn size error\n");
e0ee9c12 Alexei Starovoitov 2014-10-10  1083return -EFAULT;
e0ee9c12 Alexei Starovoitov 2014-10-10  1084}
e0ee9c12 Alexei Starovoitov 2014-10-10  1085  
0a14842f Eric Dumazet   2011-04-20  1086if (image) {
0a14842f Eric Dumazet   2011-04-20  1087if 
(unlikely(proglen + ilen > oldproglen)) {
9383191d Daniel Borkmann2017-02-16  1088
pr_err("bpf_jit: fatal error\n");
f3c2af7b Alexei Starovoitov 2014-05-13  1089return 
-EFAULT;
0a14842f Eric Dumazet   2011-04-20  1090}
0a14842f Eric Dumazet   2011-04-20  1091memcpy(image + 
proglen, temp, ilen);
0a14842f Eric Dumazet   2011-04-20  1092}
0a14842f Eric Dumazet   2011-04-20  1093proglen += ilen;
0a14842f Eric Dumazet   2011-04-20  1094addrs[i] = proglen;
0a14842f Eric Dumazet   2011-04-20  1095prog = temp;
0a14842f Eric Dumazet   2011-04-20  1096}
f3c2af7b Alexei Starovoitov 2014-05-13  1097return proglen;
f3c2af7b Alexei Starovoitov 2014-05-13 @1098  }
f3c2af7b Alexei Starovoitov 2014-05-13  1099  
19d23b2d Tycho Andersen 2017-04-04  1100  #ifdef CONFIG_EBPF_JIT_HASH_OUTPUT
19d23b2d Tycho Andersen 2017-04-04  1101  static struct shash_desc 
*bpf_alloc_hash_desc(void)
19d23b2d Tycho Andersen 2017-04-04  1102  {
19d23b2d Tycho Andersen 2017-04-04  1103struct shash_desc *hash;
19d23b2d Tycho Andersen 2017-04-04  1104int sz = sizeof(struct 
shash_desc) + crypto_shash_descsize(tfm);
19d23b2d Tycho Andersen 2017-04-04  1105  
19d23b2d Tycho Andersen 2017-04-04  1106hash = kzalloc(sz, GFP_KERNEL);

:: The code at line 1098 was first introduced by commit
:: f3c2af7ba17a83809806880062c9ad541744fb95 net: filter: x86: split 
bpf_jit_compile()

:: TO: Alexei Starovoitov <a...@plumgrid.com>
:: CC: David S. Miller <da...@davemloft.net>

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


.config.gz
Description: application/gzip

Re: [PATCH v8 3/3] printk: fix double printing with earlycon

[Aleksey Makarov]

On 04/04/2017 02:12 PM, Petr Mladek wrote:

On Thu 2017-03-30 14:55:46, Sergey Senozhatsky wrote:

On (03/28/17 14:56), Petr Mladek wrote:


[..]


Alekesey, any chance to use the global variable to count used or point
to the last element?

I know that you have already spent a lot of time with it. It was great
work. But the current solution of the cycle looks weird to me.


Sorry for the delay.  I will send next version soon.

Thank you
Aleksey Makarov

[PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

[Matthias Kaehlcke]

The operand is an integer constant, make the constness explicit by
adding the modifier. This is needed for clang to generate valid code
and also works with gcc.

Also change the constraint of the operand from 'I' ("Integer constant
that is valid as an immediate operand in an ADD instruction", AArch64)
to 'i' ("An immediate integer operand").

Based-on-patch-from: Greg Hackmann 
Signed-off-by: Greg Hackmann 
Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- Changed operand constraint from I to i
- Updated commit message
- Changed 'From' tag to 'Based-on-patch-from'

 arch/arm64/crypto/sha1-ce-glue.c | 2 +-
 arch/arm64/crypto/sha2-ce-glue.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
index aefda9868627..6b520e3f3ab1 100644
--- a/arch/arm64/crypto/sha1-ce-glue.c
+++ b/arch/arm64/crypto/sha1-ce-glue.c
@@ -18,7 +18,7 @@
 #include 
 
 #define ASM_EXPORT(sym, val) \
-   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+   asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
 
 MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
 MODULE_AUTHOR("Ard Biesheuvel ");
diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
index 7cd587564a41..e3abe11de48c 100644
--- a/arch/arm64/crypto/sha2-ce-glue.c
+++ b/arch/arm64/crypto/sha2-ce-glue.c
@@ -18,7 +18,7 @@
 #include 
 
 #define ASM_EXPORT(sym, val) \
-   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+   asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
 
 MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
Extensions");
 MODULE_AUTHOR("Ard Biesheuvel ");
-- 
2.12.2.715.g7642488e1d-goog

Re: [PATCH 1/2] Alps HID I2C T4 device support

[Nikolaus Rath]

Hi Masaki,

Could you be a little more specific about what you need? I don't like
executing scripts containing several instances of 'sudo rm -rf
[something]'.

It seems that the script is meant to install debugging versions of some
modules. Could you simply send me a patch against the official kernel
that includes your debugging code? I'm perfectly able to compile it and
load the modules on my own :-).

Thanks,
-Nikolaus

On Apr 05 2017, Masaki Ota  wrote:
> Hi, Nikolaus,
>
> If you have a time, please try below debug method.
>
> Download below file, copy it to your system and unpack.
> https://www.filesanywhere.com/fs/v.aspx?v=8b716a8e5b6773baa799
>
> Procedure ex:
> #cd Desktop/LinuxModDebug
> #sudo chmod 755 linux_kr_rebuild_tool_hid.sh
> #sudo ./linux_kr_rebuild_tool_hid.sh /init linux-4.10.tar.gz
> #sudo ./linux_kr_rebuild_tool_hid.sh /build DebugSrc
>
> After that Touchpad all features should work.
> If Touchpad does not work, something error appears on dmesg.
>
> Best Regards,
> Masaki Ota
> -Original Message-
> From: Nikolaus Rath [mailto:nikol...@rath.org] 
> Sent: Wednesday, April 05, 2017 9:01 AM
> To: 太田 真喜 Masaki Ota 
> Cc: linux-kernel ; linux-in...@vger.kernel.org
> Subject: Re: [PATCH 1/2] Alps HID I2C T4 device support
>
> Hi Masaki,
>
> Well, I'd be pleasently surprised if every bug always came together
> with an associated error message :-). No matter if there's a dmesg
> entry or not, at the moment this patch will make life much worse for
> at least some EliteBook owners.
>
> Is there anything I can do to help you debug this?
>
> Best,
> -Nikolaus
>
>
> On Apr 04 2017, Masaki Ota  wrote:
>> Hi, Nikolaus,
>>
>> Um, but demesg log does not have any error of this Touchpad.
>> It's a strange.
>>
>> Best Regards,
>> Masaki Ota
>> -Original Message-
>> From: Nikolaus Rath [mailto:nikol...@rath.org]
>> Sent: Wednesday, April 05, 2017 8:43 AM
>> To: 太田 真喜 Masaki Ota 
>> Cc: linux-kernel ; 
>> linux-in...@vger.kernel.org
>> Subject: Re: [PATCH 1/2] Alps HID I2C T4 device support
>>
>> Hi Masaki,
>>
>> Yes, without your patch the touchpad is mostly working - I just can't 
>> configure it.
>>
>> Please take a look at https://bugs.freedesktop.org/show_bug.cgi?id=100345.
>>
>> Best,
>> -Nikolaus
>>
>> On Apr 04 2017, Masaki Ota  wrote:
>>> Hi, Nikolaus,
>>>
>>> There is no 044E:120C device, but it looks like Alps Touchpad is detected 
>>> as PS/2 Touchpad.
>>>
>>> Actually, this Touchpad has two interfaces. One is I2C, the other is PS/2.
>>> Default setting is I2C, and if the system does not support I2C, Touchpad 
>>> works as PS/2.
>>>
>>> However, both of interface should work properly on Linux.
>>> I tested it on Ubuntu +4.10 kernel.
>>>
>>> If you don't apply my patch, does device work as I2C? (044E:120C
>>> appears?)
>>>
>>> Best Regards,
>>> Masaki Ota
>>> -Original Message-
>>> From: Nikolaus Rath [mailto:nikol...@rath.org]
>>> Sent: Wednesday, April 05, 2017 2:09 AM
>>> To: 太田 真喜 Masaki Ota 
>>> Cc: linux-kernel ; 
>>> linux-in...@vger.kernel.org
>>> Subject: Re: [PATCH 1/2] Alps HID I2C T4 device support
>>>
>>> Hi Masaki,
>>>
>>> Yes, I think I have a 044E:120C. Is there a way to find out for sure?
>>> It's not listed by e.g. lspci.
>>>
>>> The touchpad is definitely not reacting to anything. evemu-record does not 
>>> show any events either.
>>>
>>> I have attached the dmesg output.
>>>
>>> Best,
>>> -Nikolaus
>>>
>>>
>>> On Apr 04 2017, Masaki Ota  wrote:
 Hi, Nikolaus,

 Your Touchpad is 044E:120C, right?

 PATCH 1/2 supports 044E:120C Touchpad device.
 I think you can use all features of this Touchpad.

 PATCH 2/2 supports 044E:1215 Touchpad device.
 You don't need to care about this.

 If Touchpad does not work completely, there is something an error.
 What does dmesg show?

 Best Regards,
 Masaki Ota
 -Original Message-
 From: Nikolaus Rath [mailto:nikol...@rath.org]
 Sent: Tuesday, April 04, 2017 12:09 PM
 To: 太田 真喜 Masaki Ota ; linux-kernel 
 ; linux-in...@vger.kernel.org
 Subject: Re: [PATCH 1/2] Alps HID I2C T4 device support

 Hi Ota,

> -Support Alps HID I2C T4 Touchpad device.
> -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook 
> Folio G1, Elitebook 1030 G1, Elitebook 1040 G3
>
> Signed-off-by: Masaki Ota 
> ---
>  drivers/hid/hid-alps.c | 500 
> +++--
>  drivers/hid/hid-core.c |   3 +-
>  drivers/hid/hid-ids.h  |   1 +
>  3 files changed, 403 insertions(+), 101 deletions(-)
  
 I tried your patch on an HP 

[PATCH v3 2/2] scsi: storvsc: Add support for FC rport.

[Cathy Avery]

Included in the current storvsc driver for Hyper-V is the ability
to access luns on an FC fabric via a virtualized fiber channel
adapter exposed by the Hyper-V host. The driver also attaches to
the FC transport to allow host and port names to be published under
/sys/class/fc_host/hostX. Current customer tools running on the VM
require that these names be available in the well known standard
location under fc_host/hostX.

This patch stubs in an rport per fc_host and sets its rport role
as FC_PORT_ROLE_FCP_DUMMY_INITIATOR to indicate to the fc_transport
that it is a pseudo rport in order to scan the scsi stack via
echo "- - -" > /sys/class/scsi_host/hostX/scan.

Signed-off-by: Cathy Avery 
---
 drivers/scsi/storvsc_drv.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 016639d..1ec8579 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -476,6 +476,9 @@ struct storvsc_device {
 */
u64 node_name;
u64 port_name;
+#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
+   struct fc_rport *rport;
+#endif
 };
 
 struct hv_host_device {
@@ -1823,19 +1826,27 @@ static int storvsc_probe(struct hv_device *device,
target = (device->dev_instance.b[5] << 8 |
 device->dev_instance.b[4]);
ret = scsi_add_device(host, 0, target, 0);
-   if (ret) {
-   scsi_remove_host(host);
-   goto err_out2;
-   }
+   if (ret)
+   goto err_out3;
}
 #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
if (host->transportt == fc_transport_template) {
+   struct fc_rport_identifiers ids = {
+   .roles = FC_PORT_ROLE_FCP_DUMMY_INITIATOR,
+   };
+
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
+   stor_device->rport = fc_remote_port_add(host, 0, );
+   if (!stor_device->rport)
+   goto err_out3;
}
 #endif
return 0;
 
+err_out3:
+   scsi_remove_host(host);
+
 err_out2:
/*
 * Once we have connected with the host, we would need to
@@ -1861,8 +1872,10 @@ static int storvsc_remove(struct hv_device *dev)
struct Scsi_Host *host = stor_device->host;
 
 #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
-   if (host->transportt == fc_transport_template)
+   if (host->transportt == fc_transport_template) {
+   fc_remote_port_delete(stor_device->rport);
fc_remove_host(host);
+   }
 #endif
scsi_remove_host(host);
storvsc_dev_remove(dev);
-- 
2.5.0

[PATCH v3 1/2] scsi: scsi_transport_fc: Add dummy initiator role to rport

[Cathy Avery]

This patch allows scsi drivers that expose virturalized fibre channel
devices but that do not expose rports to successfully rescan the scsi
bus via echo "- - -" > /sys/class/scsi_host/hostX/scan.
Drivers can create a pseudo rport and indicate
FC_PORT_ROLE_FCP_DUMMY_INITIATOR as the rport's role in
fc_rport_identifiers. This insures that a valid scsi_target_id
is assigned to the newly created rport and it can meet the
requirements of fc_user_scan_tgt calling scsi_scan_target.

Signed-off-by: Cathy Avery 
---
 drivers/scsi/scsi_transport_fc.c | 10 ++
 include/scsi/scsi_transport_fc.h |  1 +
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 2d753c9..de85602 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -289,9 +289,10 @@ static const struct {
u32 value;
char*name;
 } fc_port_role_names[] = {
-   { FC_PORT_ROLE_FCP_TARGET,  "FCP Target" },
-   { FC_PORT_ROLE_FCP_INITIATOR,   "FCP Initiator" },
-   { FC_PORT_ROLE_IP_PORT, "IP Port" },
+   { FC_PORT_ROLE_FCP_TARGET,  "FCP Target" },
+   { FC_PORT_ROLE_FCP_INITIATOR,   "FCP Initiator" },
+   { FC_PORT_ROLE_IP_PORT, "IP Port" },
+   { FC_PORT_ROLE_FCP_DUMMY_INITIATOR, "FCP Dummy Initiator" },
 };
 fc_bitfield_name_search(port_roles, fc_port_role_names)
 
@@ -2628,7 +2629,8 @@ fc_remote_port_create(struct Scsi_Host *shost, int 
channel,
spin_lock_irqsave(shost->host_lock, flags);
 
rport->number = fc_host->next_rport_number++;
-   if (rport->roles & FC_PORT_ROLE_FCP_TARGET)
+   if ((rport->roles & FC_PORT_ROLE_FCP_TARGET) ||
+   (rport->roles & FC_PORT_ROLE_FCP_DUMMY_INITIATOR))
rport->scsi_target_id = fc_host->next_target_id++;
else
rport->scsi_target_id = -1;
diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
index b21b8aa5..6e208bb 100644
--- a/include/scsi/scsi_transport_fc.h
+++ b/include/scsi/scsi_transport_fc.h
@@ -162,6 +162,7 @@ enum fc_tgtid_binding_type  {
 #define FC_PORT_ROLE_FCP_TARGET0x01
 #define FC_PORT_ROLE_FCP_INITIATOR 0x02
 #define FC_PORT_ROLE_IP_PORT   0x04
+#define FC_PORT_ROLE_FCP_DUMMY_INITIATOR   0x08
 
 /* The following are for compatibility */
 #define FC_RPORT_ROLE_UNKNOWN  FC_PORT_ROLE_UNKNOWN
-- 
2.5.0

Re: [PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

[Matthias Kaehlcke]

Hi Masahiro,

El Thu, Apr 06, 2017 at 03:08:26AM +0900 Masahiro Yamada ha dit:

> 2017-03-17 9:15 GMT+09:00 Michael Davidson :
> > Unfortunately, while clang generates a warning about these flags
> > being unsupported it still exits with a status of 0 so we have
> > to explicitly disable them instead of just using a cc-option check.
> >
> > Signed-off-by: Michael Davidson 
> 
> 
> Instead, does the following work for you?
> https://patchwork.kernel.org/patch/9657285/

Thanks for the pointer, I was about to give this change (or rather its
ancestor) a rework myself :)

> You need to use
> $(call cc-option, ...)
> for -falign-jumps=1 and -falign-loops=1

I can confirm that this works.

Thanks

Matthias

Re: [PATCH v4] of/pci: Fix memory leak in of_pci_get_host_bridge_resources

[kbuild test robot]

Hi Jeffy,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc5 next-20170405]
[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/Jeffy-Chen/of-pci-Fix-memory-leak-in-of_pci_get_host_bridge_resources/20170406-005941
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//pci/bus.c: In function 'pci_add_resource_offset':
>> drivers//pci/bus.c:36:2: error: expected ';' before 'entry'
 entry->offset = offset;
 ^

vim +36 drivers//pci/bus.c

0efd5aab Bjorn Helgaas 2012-02-23  20  void pci_add_resource_offset(struct 
list_head *resources, struct resource *res,
0efd5aab Bjorn Helgaas 2012-02-23  21resource_size_t 
offset)
45ca9e97 Bjorn Helgaas 2011-10-28  22  {
14d76b68 Jiang Liu 2015-02-05  23   struct resource_entry *entry;
45ca9e97 Bjorn Helgaas 2011-10-28  24  
fa904d0d Jeffy Chen2017-04-05  25   entry = 
resource_list_create_entry(NULL, 0);
14d76b68 Jiang Liu 2015-02-05  26   if (!entry) {
0efd5aab Bjorn Helgaas 2012-02-23  27   printk(KERN_ERR "PCI: can't add 
host bridge window %pR\n", res);
45ca9e97 Bjorn Helgaas 2011-10-28  28   return;
45ca9e97 Bjorn Helgaas 2011-10-28  29   }
45ca9e97 Bjorn Helgaas 2011-10-28  30  
fa904d0d Jeffy Chen2017-04-05  31   if (res->flags & IORESOURCE_AUTO)
fa904d0d Jeffy Chen2017-04-05  32   *entry->res = *res;
fa904d0d Jeffy Chen2017-04-05  33   else
fa904d0d Jeffy Chen2017-04-05  34   entry->res = res
fa904d0d Jeffy Chen2017-04-05  35  
14d76b68 Jiang Liu 2015-02-05 @36   entry->offset = offset;
14d76b68 Jiang Liu 2015-02-05  37   resource_list_add_tail(entry, 
resources);
0efd5aab Bjorn Helgaas 2012-02-23  38  }
0efd5aab Bjorn Helgaas 2012-02-23  39  EXPORT_SYMBOL(pci_add_resource_offset);
0efd5aab Bjorn Helgaas 2012-02-23  40  
0efd5aab Bjorn Helgaas 2012-02-23  41  void pci_add_resource(struct list_head 
*resources, struct resource *res)
0efd5aab Bjorn Helgaas 2012-02-23  42  {
0efd5aab Bjorn Helgaas 2012-02-23  43   pci_add_resource_offset(resources, res, 
0);
45ca9e97 Bjorn Helgaas 2011-10-28  44  }

:: The code at line 36 was first introduced by commit
:: 14d76b68f2819a1d0b50236a7e9e9f2ea69869d9 PCI: Use common resource list 
management code instead of private implementation

:: TO: Jiang Liu <jiang@linux.intel.com>
:: CC: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

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


.config.gz
Description: application/gzip

Re: [PATCH 2/4] net: dsa: add new DSA switch driver for the SMSC-LAN9303

[Andrew Lunn]

On Wed, Apr 05, 2017 at 11:20:22AM +0200, Juergen Borleis wrote:
> The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
> and two external ethernet ports with built-in phys.
> 
> This driver uses the DSA framework, but is currently only capable of
> separating the two external ports. There is no offload support yet.
> 
> Signed-off-by: Juergen Borleis 
> ---
>  drivers/net/phy/lan9303-core.c | 924 
> +
>  drivers/net/phy/lan9303.h  |  21 +

drivers/net/dsa please.

One general comment. I'm assuming parts of this code comes from
openwrt swconfig. In swconfig, i think they consider switches to be
part of the PHY layer. In DSA, switches are switches, PHYs are
PHYs. So the naming in this driver needs to reflect this.

> +static int lan9303_read(struct regmap *regmap, unsigned int offset, u32 *reg)
> +{
> + int ret;
> +
> + /* we can lose arbitration for the I2C case, because the device
> +  * tries to detect and read an external EEPROM after reset and acts as
> +  * a master on the shared I2C bus itself. This conflicts with our
> +  * attempts to access the device as a slave at the same moment.
> +  */
> + do {
> + ret = regmap_read(regmap, offset, reg);
> + if (ret == -EAGAIN)
> + msleep(500);
> + } while (ret == -EAGAIN);

Please limit the number of retires, and return -EIO if you don't get
access.

> +/* virtual phy registers must be read mapped */
> +static int lan9303_virt_phy_reg_read(struct lan9303 *chip, int regnum)
> +{
> + int ret;
> + u32 val;
> +
> + if (regnum > 7)
> + return -EINVAL;
> +
> + ret = lan9303_read(chip->regmap, LAN9303_VIRT_PHY_BASE + regnum, );
> + if (ret != 0)
> + return ret;

Here, and everywhere else, please just use (ret)

> +
> + return val & 0x;
> +}
> +
> +static int lan9303_virt_phy_reg_write(struct lan9303 *chip, int regnum, u16 
> val)
> +{
> + if (regnum > 7)
> + return -EINVAL;
> +
> + return regmap_write(chip->regmap, LAN9303_VIRT_PHY_BASE + regnum, val);

Does this virtual PHY use the usual 10/100/1000 PHY registers?


> +}
> +
> +static int lan9303_port_phy_reg_wait_for_completion(struct lan9303 *chip)
> +{
> + int ret;
> + u32 reg;
> +
> + /* transfer completed? */
> + do {
> + ret = lan9303_read(chip->regmap, LAN9303_PMI_ACCESS, );
> + if (ret != 0)
> + return ret;
> + } while (reg & LAN9303_PMI_ACCESS_MII_BUSY);

Again, no endless looping please. Abort after a while.

> +
> + return 0;
> +}
> +
> +static int lan9303_port_phy_reg_read(struct lan9303 *chip, int addr, int 
> regnum)
> +{
> + int ret;
> + u32 val;
> +
> + val = ((unsigned int)addr) << 11; /* setup phy ID */
> + val |= ((unsigned int)regnum) << 6;
> +
> + mutex_lock(>indirect_mutex);
> +
> + ret = lan9303_port_phy_reg_wait_for_completion(chip);
> + if (ret != 0)
> + goto on_error;
> +
> + /* start the MII read cycle */
> + ret = regmap_write(chip->regmap, LAN9303_PMI_ACCESS, val);
> + if (ret != 0)
> + goto on_error;
> +
> + ret = lan9303_port_phy_reg_wait_for_completion(chip);
> + if (ret != 0)
> + goto on_error;
> +
> + /* read the result of this operation */
> + ret = lan9303_read(chip->regmap, LAN9303_PMI_DATA, );
> + if (ret != 0)
> + goto on_error;
> +
> + mutex_unlock(>indirect_mutex);
> +
> + return val & 0x;
> +
> +on_error:
> + mutex_unlock(>indirect_mutex);
> + return ret;
> +}
> +
> +static int lan9303_phy_reg_write(struct lan9303 *chip, int addr, int regnum,
> +  unsigned int val)
> +{
> + int ret;
> + u32 reg;
> +
> + reg = ((unsigned int)addr) << 11; /* setup phy ID */

Within Linux, PHY ID means the contents of PHY registers 2 and 3. It
would be good not to confuse things by using a different meaning.

> + reg |= ((unsigned int)regnum) << 6;
> + reg |= LAN9303_PMI_ACCESS_MII_WRITE;
> +
> + mutex_lock(>indirect_mutex);
> +
> + ret = lan9303_port_phy_reg_wait_for_completion(chip);
> + if (ret != 0)
> + goto on_error;
> +
> + /* write the data first... */
> + ret = regmap_write(chip->regmap, LAN9303_PMI_DATA, val);
> + if (ret != 0)
> + goto on_error;
> +
> + /* ...then start the MII write cycle */
> + ret = regmap_write(chip->regmap, LAN9303_PMI_ACCESS, reg);
> +
> +on_error:
> + mutex_unlock(>indirect_mutex);
> + return ret;
> +}
> +
> +static int lan9303_switch_wait_for_completion(struct lan9303 *chip)
> +{
> + int ret;
> + u32 reg;
> +
> + /* transfer completed? */
> + do {
> + ret = lan9303_read(chip->regmap, LAN9303_SWITCH_CSR_CMD, );
> + if (ret) {
> + dev_err(chip->dev,
> +  

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[J. Bruce Fields]

On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote:
> 1) Keep i_version as is, make clients also check for i_ctime.

That would be a protocol revision, which we'd definitely rather avoid.

But can't we accomplish the same by using something like

ctime * (some constant) + i_version

?

>Pro: No on-disk format changes.
>Cons: After a crash, i_version can go backwards (but when file changes
>i_version, i_ctime pair should be still different) or not, data can be
>old or not.

This is probably good enough for NFS purposes: typically on an NFS
filesystem, results of a read in the face of a concurrent write open are
undefined.  And writers sync before close.

So after a crash with a dirty inode, we're in a situation where an NFS
client still needs to resend some writes, sync, and close.  I'm OK with
things being inconsistent during this window.

I do expect things to return to normal once that client's has resent its
writes--hence the worry about actually resuing old values after boot
(such as if i_version regresses on boot and then increments back to the
same value after further writes).  Factoring in ctime fixes that.

> 2) Fsync when reporting i_version.
>Pro: No on-disk format changes, strong consistency of i_version and
> data.
>Cons: Difficult to implement for filesystems due to locking constrains.
>  High performance overhead or i_version reporting.

Sounds painful.

> 3) Some variant of crash counter.
>Pro: i_version cannot go backwards.
>Cons: Requires on-disk format changes. After a crash data can be old
>  (however i_version increased).

Also, some unnecessary invalidations.  Which maybe can be mostly avoided
by some variation of Neil's scheme.

It looks to me like option (1) is doable now and introduces no
regressions compared to the current situation.  (2) and (3) are more
copmlicated and involve some tradeoffs.

Also, we can implement (1) and switch to (2) or (3) later.  We'd want to
do it without reported i_versions decreasing on kernel upgrade, but
there are multiple ways of handling that.  (Worst case, just restrict
the change to newly created filesystems.)

--b.

Re: [PATCH 00/14] RDMA/cxgb: Fine-tuning for several function implementations

[Doug Ledford]

On Wed, 2017-02-08 at 22:10 +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 8 Feb 2017 22:00:10 +0100
> 
> Several update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (14):
>   Use kcalloc() in cxio_create_qp()
>   Rename jump labels in cxio_create_qp()
>   Use kcalloc() in two functions
>   Use common error handling code in recover_queues()
>   Return an error code only as a constant in ep_open()
>   Return an error code only as a constant in stag_open()
>   Adjust three checks for null pointers
>   Adjust construction of two error messages in recover_lost_dbs()
>   Use common error handling code in recover_lost_dbs()
>   Use kmalloc_array() in c4iw_id_table_alloc()
>   Use kcalloc() in create_qp()
>   Delete an unnecessary variable initialisation in create_qp()
>   Rename jump labels in c4iw_create_qp()
>   Rename jump labels in rdma_init()
> 
>  drivers/infiniband/hw/cxgb3/cxio_hal.c | 20 
>  drivers/infiniband/hw/cxgb4/device.c   | 83 +++-
> --
>  drivers/infiniband/hw/cxgb4/id_table.c |  5 +-
>  drivers/infiniband/hw/cxgb4/qp.c   | 48 ++--
>  4 files changed, 75 insertions(+), 81 deletions(-)

I didn't see enough value in this series to bother picking it up.
 Steve, if there are any patches out of this series you actually want,
please collect them and forward them on to me.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[PATCH v3 0/2] scsi: storvsc: Add support for FC rport

[Cathy Avery]

The updated patch set provides a way for drivers ( specifically
storvsc in this case ) that expose virturalized fc devices
but that do not expose rports to be manually scanned. This is
done via creating a pseudo rport in storvsc and a
corresponding dummy initiator rport role in the fc transport.

Changes since v2:
- Additional patch adding FC_PORT_ROLE_FCP_DUMMY_INITIATOR role
  to fc_transport
- Changed storvsc rport role to FC_PORT_ROLE_FCP_DUMMY_INITIATOR

Changes since v1:
- Fix fc_rport_identifiers init [Stephen Hemminger]
- Better error checking


Cathy Avery (2):
  scsi: scsi_transport_fc: Add dummy initiator role to rport
  scsi: storvsc: Add support for FC rport.

 drivers/scsi/scsi_transport_fc.c | 10 ++
 drivers/scsi/storvsc_drv.c   | 23 ++-
 include/scsi/scsi_transport_fc.h |  1 +
 3 files changed, 25 insertions(+), 9 deletions(-)

-- 
2.5.0

Re: net/ipv4: use-after-free in ipv4_mtu

[Subash Abhinov Kasiviswanathan]

Interesting. I might had too many beers tonight, but ...

refcount was removed in 2860583fe840 many months later

-static void rt_init_metrics(struct rtable *rt, struct fib_info *fi)
-{
-   if (fi->fib_metrics != (u32 *) dst_default_metrics) {
-   rt->fi = fi;
-   atomic_inc(>fib_clntref);
-   }
-   dst_init_metrics(>dst, fi->fib_metrics, true);
-}
-
 static struct fib_nh_exception *find_exception(struct fib_nh *nh,
__be32 daddr)
 {
struct fnhe_hash_bucket *hash = nh->nh_exceptions;
@@ -1261,7 +1239,7 @@ static void rt_set_nexthop(struct rtable *rt,
__be32 daddr,
rt->rt_gateway = nh->nh_gw;
if (unlikely(fnhe))
rt_bind_exception(rt, fnhe, daddr);
-   rt_init_metrics(rt, fi);
+   dst_init_metrics(>dst, fi->fib_metrics, true);
 #ifdef CONFIG_IP_ROUTE_CLASSID
rt->dst.tclassid = nh->nh_tclassid;
 #endif


Hi Eric

I encountered a crash on 4.4 kernel pointing to ipv4_mtu.
Is the crash similar to this one?
(target is ARM64 Android, was seen on a stability rack, so no reproducer
unfortunately)

<6> Kernel BUG at 05dc [verbose debug info unavailable]
<6> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
<6> CPU: 1 PID: 4649 Comm: iperf Tainted: GW  O4.4.21+ #1
<6> task: ffef02242f00 ti: ffef021b8000 task.ti: 
ffef021b8000

<2> PC is at 0x5dc
<2> LR is at ipv4_mtu+0x70/0x84
<2> pc : [<05dc>] lr : [] pstate: a145
<2> sp : ffef021bb9b0
<2> x29: ffef021bb9b0 x28: 
<2> x27: ffef318122c0 x26: 05be
<2> x25: ffef31812678 x24: ffef31812678
<2> x23: ffef8794c000 x22: ff9bd43f4380
<2> x21: ffef318122c0 x20: ffef6aef6ac0
<2> x19: ffef05026ac0 x18: 01026749
<2> x17: 007fabaf145c x16: ff9bd1fe72bc
<2> x15: 00368fbefea52a8e x14: 3736353433323130
<2> x13: 3938373635343332 x12: 0003
<2> x11: 0028 x10: 0101010101010101
<2> x9 : 0001 x8 : 0098
<2> x7 : ff9bd2c8cbc0 x6 : 
<2> x5 : ffef68481c00 x4 : efbf
<2> x3 :  x2 : 
<2> x1 : ef7f x0 : 01280058
<2>
LR: 0xff9bd2c35a78:
<2> 5a78  b7f80241 f9401661 927ef421 b9400422 2a0203e0 350001a2 f9400e60 
b9400021
<2> 5a98  b9422800 361000c1 39428e61 3481 7109001f 52804801 1a819000 
529fffe1
<2> 5ab8  6b01001f 1a819000 f9400bf3 a8c27bfd d65f03c0 a9ba7bfd 910003fd 
a90153f3
<2> 5ad8  a9025bf5 a90363f7 a9046bf9 aa0003f3 aa1e03e0 f9002fa1 2a0203f8 
2a0303f9

<2>
SP: 0xffef021bb970:
<2> b970  d2c35ab8 ff9b 021bb9b0 ffef 05dc  a145 

<2> b990  6aef6ac0 ffef 6aef6ac0 ffef  0080 d2c015b0 
ff9b
<2> b9b0  021bb9d0 ffef d2c3e4d4 ff9b 6aef6ac0 ffef 021bba18 
ffef
<2> b9d0  021bba20 ffef d2c3f05c ff9b d37d9418 ff9b 6aef6ac0 
ffef

<2>
<6> Process iperf (pid: 4649, stack limit = 0xffef021b8020)
<2> Call trace:
<2> [<05dc>] 0x5dc
<2> [] ip_finish_output+0xbc/0x1dc
<2> [] ip_output+0xe8/0x15c
<2> [] ip_local_out+0x58/0x68
<2> [] ip_send_skb+0x2c/0xa8
<2> [] udp_send_skb+0x194/0x29c
<2> [] udp_sendmsg+0x4e0/0x700
<2> [] inet_sendmsg+0x98/0xc8
<2> [] sock_sendmsg+0x48/0x60
<2> [] sock_write_iter+0x94/0xc0
<2> [] __vfs_write+0xc0/0xf0
<2> [] vfs_write+0xb8/0x150
<2> [] SyS_write+0x58/0x94
<2> [] el0_svc_naked+0x24/0x28
<6> Code: bad PC value
<6> ---[ end trace debf337ba02da94f ]---
<6> Kernel panic - not syncing: Fatal exception

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

[PATCH v7 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.

Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue will be used to wait when the ring is full and
we need to send a new request.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Juergen Gross 
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 281 +
 1 file changed, 281 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 3d07260..fe3d172 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -37,10 +37,54 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
+#define XEN_9PFS_NUM_RINGS 2
+#define XEN_9PFS_RING_ORDER 6
+#define XEN_9PFS_RING_SIZE  XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER)
+
+struct xen_9pfs_header {
+   uint32_t size;
+   uint8_t id;
+   uint16_t tag;
+
+   /* uint8_t sdata[]; */
+} __attribute__((packed));
+
+/* One per ring, more than one per 9pfs share */
+struct xen_9pfs_dataring {
+   struct xen_9pfs_front_priv *priv;
+
+   struct xen_9pfs_data_intf *intf;
+   grant_ref_t ref;
+   int evtchn;
+   int irq;
+   /* protect a ring from concurrent accesses */
+   spinlock_t lock;
+
+   struct xen_9pfs_data data;
+   wait_queue_head_t wq;
+   struct work_struct work;
+};
+
+/* One per 9pfs share */
+struct xen_9pfs_front_priv {
+   struct list_head list;
+   struct xenbus_device *dev;
+   char *tag;
+   struct p9_client *client;
+
+   int num_rings;
+   struct xen_9pfs_dataring *rings;
+};
+
+static LIST_HEAD(xen_9pfs_devs);
+static DEFINE_RWLOCK(xen_9pfs_lock);
+
 static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
 {
return 0;
@@ -60,6 +104,25 @@ static int p9_xen_request(struct p9_client *client, struct 
p9_req_t *p9_req)
return 0;
 }
 
+static void p9_xen_response(struct work_struct *work)
+{
+}
+
+static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
+{
+   struct xen_9pfs_dataring *ring = r;
+
+   if (!ring || !ring->priv->client) {
+   /* ignore spurious interrupt */
+   return IRQ_HANDLED;
+   }
+
+   wake_up_interruptible(>wq);
+   schedule_work(>work);
+
+   return IRQ_HANDLED;
+}
+
 static struct p9_trans_module p9_xen_trans = {
.name = "xen",
.maxsize = 1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT),
@@ -76,25 +139,243 @@ static int p9_xen_request(struct p9_client *client, 
struct p9_req_t *p9_req)
{ "" }
 };
 
+static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
+{
+   int i, j;
+
+   write_lock(_9pfs_lock);
+   list_del(>list);
+   write_unlock(_9pfs_lock);
+
+   for (i = 0; i < priv->num_rings; i++) {
+   if (!priv->rings[i].intf)
+   break;
+   if (priv->rings[i].irq > 0)
+   unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
+   if (priv->rings[i].data.in) {
+   for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++) {
+   grant_ref_t ref;
+
+   ref = priv->rings[i].intf->ref[j];
+   gnttab_end_foreign_access(ref, 0, 0);
+   }
+   free_pages((unsigned long)priv->rings[i].data.in,
+  XEN_9PFS_RING_ORDER -
+  (PAGE_SHIFT - XEN_PAGE_SHIFT));
+   }
+   gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
+   free_page((unsigned long)priv->rings[i].intf);
+   }
+   kfree(priv->rings);
+   kfree(priv->tag);
+   kfree(priv);
+}
+
 static int xen_9pfs_front_remove(struct xenbus_device *dev)
 {
+   struct xen_9pfs_front_priv *priv = dev_get_drvdata(>dev);
+
+   dev_set_drvdata(>dev, NULL);
+   xen_9pfs_front_free(priv);
return 0;
 }
 
+static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
+struct xen_9pfs_dataring *ring)
+{
+   int i = 0;
+   int ret = -ENOMEM;
+   void *bytes = NULL;
+
+   init_waitqueue_head(>wq);
+   spin_lock_init(>lock);
+   INIT_WORK(>work, p9_xen_response);
+
+   ring->intf = (struct xen_9pfs_data_intf *)get_zeroed_page(GFP_KERNEL);
+   if (!ring->intf)
+   return ret;
+   ret = gnttab_grant_foreign_access(dev->otherend_id,
+ virt_to_gfn(ring->intf), 0);
+ 

[PATCH] fpga fr br: fix warning for unexpected version number

[matthew . gerlach]

From: Matthew Gerlach 

The value in the version register of the altera freeze bridge
controller changed from the beta value of 2 to the
value of 0xad03 in the official release of the IP.
This patch supports the old and new version numbers
without printing an warning.

Signed-off-by: Matthew Gerlach 
---
 drivers/fpga/altera-freeze-bridge.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/fpga/altera-freeze-bridge.c 
b/drivers/fpga/altera-freeze-bridge.c
index 8dcd9fb..bdfd5eb 100644
--- a/drivers/fpga/altera-freeze-bridge.c
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -28,6 +28,7 @@
 #define FREEZE_CSR_REG_VERSION 12
 
 #define FREEZE_CSR_SUPPORTED_VERSION   2
+#define FREEZE_CSR_OFFICIAL_VERSION0xad03
 
 #define FREEZE_CSR_STATUS_FREEZE_REQ_DONE  BIT(0)
 #define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONEBIT(1)
@@ -241,10 +242,12 @@ static int altera_freeze_br_probe(struct platform_device 
*pdev)
priv->enable = 1;
 
revision = readl(priv->base_addr + FREEZE_CSR_REG_VERSION);
-   if (revision != FREEZE_CSR_SUPPORTED_VERSION)
+   if ((revision != FREEZE_CSR_SUPPORTED_VERSION) &&
+   (revision != FREEZE_CSR_OFFICIAL_VERSION))
dev_warn(dev,
-"%s Freeze Controller unexpected revision %d != %d\n",
-__func__, revision, FREEZE_CSR_SUPPORTED_VERSION);
+"%s unexpected revision 0x%x != 0x%x != 0x%x\n",
+__func__, revision, FREEZE_CSR_SUPPORTED_VERSION,
+FREEZE_CSR_OFFICIAL_VERSION);
 
return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
_freeze_br_br_ops, priv);
-- 
2.7.4

Re: [PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

[Michael Davidson]

It "works" for the cases that I currently care about but I have to say
that I am uneasy about adding -Werror to the cc-option test in this
way.

Suppose that one of the *other* flags that is implicitly passed to the
compiler by cc-option - eg something that was explicitly specified in
$(KBUILD_CFLAGS) - triggers a warning. In that case all calls to
cc-option will silently fail because of the -Werror and valid options
will not be detected correctly.

If everyone is OK with that because "it shouldn't normally ever
happen" then that is fine, but if does result in a subtle change from
existing behavior (and a trap that I almost immediately fell into
after applying a similar patch).

On Wed, Apr 5, 2017 at 12:01 PM, Matthias Kaehlcke  wrote:
> Hi Masahiro,
>
> El Thu, Apr 06, 2017 at 03:08:26AM +0900 Masahiro Yamada ha dit:
>
>> 2017-03-17 9:15 GMT+09:00 Michael Davidson :
>> > Unfortunately, while clang generates a warning about these flags
>> > being unsupported it still exits with a status of 0 so we have
>> > to explicitly disable them instead of just using a cc-option check.
>> >
>> > Signed-off-by: Michael Davidson 
>>
>>
>> Instead, does the following work for you?
>> https://patchwork.kernel.org/patch/9657285/
>
> Thanks for the pointer, I was about to give this change (or rather its
> ancestor) a rework myself :)
>
>> You need to use
>> $(call cc-option, ...)
>> for -falign-jumps=1 and -falign-loops=1
>
> I can confirm that this works.
>
> Thanks
>
> Matthias

Re: [PATCH 14/24] x86: Restrict MSR access when the kernel is locked down

[Kees Cook]

On Wed, Apr 5, 2017 at 10:12 AM, David Howells  wrote:
> From: Matthew Garrett 
>
> Writing to MSRs should not be allowed if the kernel is locked down, since
> it could lead to execution of arbitrary code in kernel mode.  Based on a
> patch by Kees Cook.
>
> Cc: Kees Cook 
> Signed-off-by: Matthew Garrett 
> Signed-off-by: David Howells 

Acked-by: Kees Cook 

-Kees

> ---
>
>  arch/x86/kernel/msr.c |7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index ef688804f80d..fbcce028e502 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -84,6 +84,9 @@ static ssize_t msr_write(struct file *file, const char 
> __user *buf,
> int err = 0;
> ssize_t bytes = 0;
>
> +   if (kernel_is_locked_down())
> +   return -EPERM;
> +
> if (count % 8)
> return -EINVAL; /* Invalid chunk size */
>
> @@ -131,6 +134,10 @@ static long msr_ioctl(struct file *file, unsigned int 
> ioc, unsigned long arg)
> err = -EBADF;
> break;
> }
> +   if (kernel_is_locked_down()) {
> +   err = -EPERM;
> +   break;
> +   }
> if (copy_from_user(, uregs, sizeof regs)) {
> err = -EFAULT;
> break;
>



-- 
Kees Cook
Pixel Security

Applied "ASoc: rt5645: Add OF device ID table" to the asoc tree

[Mark Brown]

The patch

   ASoc: rt5645: Add OF device ID table

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 9ba2da5f5d18daaa365ab5426b05e16f1d114786 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 4 Apr 2017 15:26:25 -0400
Subject: [PATCH] ASoc: rt5645: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Before this patch:

$ modinfo sound/soc/codecs/snd-soc-rt5645.ko | grep alias
alias:  acpi*:10EC3270:*
alias:  acpi*:10EC5640:*
alias:  acpi*:10EC5650:*
alias:  acpi*:10EC5648:*
alias:  acpi*:10EC5645:*
alias:  i2c:rt5650
alias:  i2c:rt5645

After this patch:

$ modinfo sound/soc/codecs/snd-soc-rt5645.ko | grep alias
alias:  of:N*T*Crealtek,rt5650C*
alias:  of:N*T*Crealtek,rt5650
alias:  of:N*T*Crealtek,rt5645C*
alias:  of:N*T*Crealtek,rt5645
alias:  acpi*:10EC3270:*
alias:  acpi*:10EC5640:*
alias:  acpi*:10EC5650:*
alias:  acpi*:10EC5648:*
alias:  acpi*:10EC5645:*
alias:  i2c:rt5650
alias:  i2c:rt5645

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/rt5645.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 10c2a564a715..f8550ef2261b 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3542,6 +3542,15 @@ static const struct i2c_device_id rt5645_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, rt5645_i2c_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id rt5645_of_match[] = {
+   { .compatible = "realtek,rt5645", },
+   { .compatible = "realtek,rt5650", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, rt5645_of_match);
+#endif
+
 #ifdef CONFIG_ACPI
 static const struct acpi_device_id rt5645_acpi_match[] = {
{ "10EC5645", 0 },
@@ -3901,6 +3910,7 @@ static void rt5645_i2c_shutdown(struct i2c_client *i2c)
 static struct i2c_driver rt5645_i2c_driver = {
.driver = {
.name = "rt5645",
+   .of_match_table = of_match_ptr(rt5645_of_match),
.acpi_match_table = ACPI_PTR(rt5645_acpi_match),
},
.probe = rt5645_i2c_probe,
-- 
2.11.0

Re: [PATCH v6 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

[Catalin Marinas]

On Wed, Apr 05, 2017 at 07:36:17AM -0700, Thomas Garnier wrote:
> On Wed, Apr 5, 2017 at 7:22 AM, Catalin Marinas  
> wrote:
> > On Tue, Apr 04, 2017 at 10:47:27AM -0700, Thomas Garnier wrote:
> >> +
> >>   ldr x1, [tsk, #TSK_TI_FLAGS]
> >>   and x2, x1, #_TIF_WORK_MASK
> >>   cbnzx2, work_pending
> >> @@ -779,6 +788,12 @@ finish_ret_to_user:
> >>   kernel_exit 0
> >>  ENDPROC(ret_to_user)
> >>
> >> +addr_limit_fail:
> >> + stp x0, lr, [sp,#-16]!
> >> + bl  asm_verify_pre_usermode_state
> >> + ldp x0, lr, [sp],#16
> >> + ret lr
> >
> > Where is this supposed to return? What is the value of lr when branching
> > to addr_limit_fail?
> 
> It is not supposed to return. Do you think I should remove stp, ldp,
> ret and jut add a brk 0x100 or jmp/call a break/bug function?

Can you not just make addr_limit_fail a C function which never returns
(similar to what we to with bad_mode() on arm64)? Since addr_limit_fail
is only called when the segment is not the right one, I don't really see
why you need another call to asm_verify_pre_usermode_state() to do a
similar check again. Just panic in addr_limit_fail (unless I
misunderstood what you are trying to achieve).

-- 
Catalin

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[J. Bruce Fields]

On Wed, Apr 05, 2017 at 11:43:32AM +1000, NeilBrown wrote:
> On Tue, Apr 04 2017, J. Bruce Fields wrote:
> 
> > On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote:
> >> On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote:
> >> > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote:
> >> > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote:
> >> > > > Because if above is acceptable we could make reported i_version to 
> >> > > > be a sum
> >> > > > of "superblock crash counter" and "inode i_version". We increment
> >> > > > "superblock crash counter" whenever we detect unclean filesystem 
> >> > > > shutdown.
> >> > > > That way after a crash we are guaranteed each inode will report new
> >> > > > i_version (the sum would probably have to look like "superblock crash
> >> > > > counter" * 65536 + "inode i_version" so that we avoid reusing 
> >> > > > possible
> >> > > > i_version numbers we gave away but did not write to disk but 
> >> > > > still...).
> >> > > > Thoughts?
> >> > 
> >> > How hard is this for filesystems to support?  Do they need an on-disk
> >> > format change to keep track of the crash counter?  Maybe not, maybe the
> >> > high bits of the i_version counters are all they need.
> >> > 
> >> 
> >> Yeah, I imagine we'd need a on-disk change for this unless there's
> >> something already present that we could use in place of a crash counter.
> >
> > We could consider using the current time instead.  So, put the current
> > time (or time of last boot, or this inode's ctime, or something) in the
> > high bits of the change attribute, and keep the low bits as a counter.
> 
> This is a very different proposal.
> I don't think Jan was suggesting that the i_version be split into two
> bit fields, one the change-counter and one the crash-counter.
> Rather, the crash-counter was multiplied by a large-number and added to
> the change-counter with the expectation that while not ever
> change-counter landed on disk, at least 1 in every large-number would.
> So after each crash we effectively add large-number to the
> change-counter, and can be sure that number hasn't been used already.

I was sort of ignoring the distinction between concatenate(A,B) and
A*m+B, but, sure, multiplying's probably better.

> To store the crash-counter in each inode (which does appeal) you would
> need to be able to remove it before adding the new crash counter, and
> that requires bit-fields.  Maybe there are enough bits.

i_version and the NFSv4 change attribute are 64 bits which gives us a
fair amount of flexibility.

> If you want to ensure read-only files can remain cached over a crash,
> then you would have to mark a file in some way on stable storage
> *before* allowing any change.
> e.g. you could use the lsb.  Odd i_versions might have been changed
> recently and crash-count*large-number needs to be added.
> Even i_versions have not been changed recently and nothing need be
> added.
> 
> If you want to change a file with an even i_version, you subtract
>   crash-count*large-number
> to the i_version, then set lsb.  This is written to stable storage before
> the change.
> 
> If a file has not been changed for a while, you can add
>   crash-count*large-number
> and clear lsb.
> 
> The lsb of the i_version would be for internal use only.  It would not
> be visible outside the filesystem.
> 
> It feels a bit clunky, but I think it would work and is the best
> combination of Jan's idea and your requirement.
> The biggest cost would be switching to 'odd' before an changes, and the
> unknown is when does it make sense to switch to 'even'.

I'm not sure how to model the costs.  Something like that might work.

--b.

[PATCH v5 2/7] power: supply: add battery driver for AXP20X and AXP22X PMICs

[Quentin Schulz]

The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.

This patch adds the battery power supply driver to get various data from
the PMIC, such as the battery status (charging, discharging, full,
dead), current max limit, current current, battery capacity (in
percentage), voltage max and min limits, current voltage and battery
capacity (in Ah).

This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
provider.

Signed-off-by: Quentin Schulz 
Acked-by: Jonathan Cameron 
Acked-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
Acked-by: Sebastian Reichel 
---

v5:
 - removed support for constant charge current setting from DT,
 - added a function to compute the constant charge current depending on the
 PMIC variant,

v4:
 - removed useless axp20x_dev variable in struct axp20x_batt_ps,
 - added struct device and maximum constant current charge variables in struct
 axp20x_batt_ps,
 - fixed wrong maximum constant current charge formula for AXP22X (forgot to add
 a custom formula so it was calculated like the AXP209),
 - when a battery node in DT does not have a valid constant current charge or
 there is no battery, the maximum current constant current charge are set to the
 lowest possible value,
 - it is possible to set maximum constant current charge now but a warn message
 is printed when trying to increase it to inform people it is risky,
 - added a check to verify the constant current charge to be set is under the
 maximum allowed,
 - lower the current constant charge current if it is higher than the maximum
 current value to be set,

v3:
 - added axp20x_set_voltage_min_design function so it can be reused,
 - used power_supply_get_battery_info for setting constant charge current
 instead of x-powers,constant-charge-current introduced in v2,
 - used power_supply_get_battery_info for setting voltage min design of
 the battery,

v2:
 - changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
 x or 3 << x exists, to be consistent,
 - switched from POWER_SUPPLY_PROP_CURRENT_MAX to
 POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
 - added POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX to the list of
 readable properties,
 - replaced µ character by a common u for micro units to make checkpatch
 happy,
 - factorized code in axp20x_battery_set_max_voltage,
 - added a axp20x_set_constant_charge_current function to be used when
 setting the value from sysfs and from the DT,
 - removed some dead code,
 - added a DT property to set constant current charge of the battery
 (x-powers,constant-charge-current),
 - migrated to dev_get_regmap instead of manually looking for the regmap
 in the drvdata of the parent,
 - switched from int to uintptr_t cast to make sure the cast is always
 for the same size type (make build on 64bits platforms happy mainly),

 drivers/power/supply/Kconfig  |  12 +
 drivers/power/supply/Makefile |   1 +
 drivers/power/supply/axp20x_battery.c | 502 ++
 3 files changed, 515 insertions(+)
 create mode 100644 drivers/power/supply/axp20x_battery.c

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index cc50e15..7f1ada8 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -232,6 +232,18 @@ config CHARGER_AXP20X
  This driver can also be built as a module. If so, the module will be
  called axp20x_ac_power.
 
+config BATTERY_AXP20X
+   tristate "X-Powers AXP20X battery driver"
+   depends on MFD_AXP20X
+   depends on AXP20X_ADC
+   depends on IIO
+   help
+ Say Y here to enable support for X-Powers AXP20X PMICs' battery power
+ supply.
+
+ This driver can also be built as a module. If so, the module will be
+ called axp20x_battery.
+
 config AXP288_CHARGER
tristate "X-Powers AXP288 Charger"
depends on MFD_AXP20X && EXTCON_AXP288
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 3789a2c..52dd17d 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER)  += test_power.o
 
 obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
 obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
+obj-$(CONFIG_BATTERY_AXP20X)   += axp20x_battery.o
 obj-$(CONFIG_CHARGER_AXP20X)   += axp20x_ac_power.o
 obj-$(CONFIG_BATTERY_DS2760)   += ds2760_battery.o
 obj-$(CONFIG_BATTERY_DS2780)   += ds2780_battery.o
diff --git a/drivers/power/supply/axp20x_battery.c 
b/drivers/power/supply/axp20x_battery.c
new file mode 100644
index 000..5d29b2e
--- /dev/null
+++ b/drivers/power/supply/axp20x_battery.c
@@ -0,0 +1,502 @@
+/*
+ * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
+ *
+ * Copyright 2016 Free Electrons NextThing Co.
+ * Quentin Schulz 
+ *
+ * This 

[PATCHv3] EDAC, altera: Fix peripheral warnings for Cyclone5

[thor . thayer]

From: Thor Thayer 

The peripherals EDACs only exist on the Arria10 SoCFPGA. The Cyclone5
initialization has EDAC warnings when the peripherals aren't found
in the device tree. Fix by checking for Arria10 in the init functions.

Signed-off-by: Thor Thayer 
---
v2  Change valid_model() return value from int to bool
Change valid_model() name to is_a10_model() for clarity.
Simplify expression - remove check for non-zero
v3  Use a simpler of_machine_is_compatible() expression.
Rename is_a10_model() to socfpga_is_a10().
---
 drivers/edac/altera_edac.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index c5a5b91..7717b094 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1023,13 +1023,23 @@ static int __maybe_unused altr_init_memory_port(void 
__iomem *ioaddr, int port)
return ret;
 }
 
+static int socfpga_is_a10(void)
+{
+   return of_machine_is_compatible("altr,socfpga-arria10");
+}
+
 static int validate_parent_available(struct device_node *np);
 static const struct of_device_id altr_edac_a10_device_of_match[];
 static int __init __maybe_unused altr_init_a10_ecc_device_type(char *compat)
 {
int irq;
-   struct device_node *child, *np = of_find_compatible_node(NULL, NULL,
-   "altr,socfpga-a10-ecc-manager");
+   struct device_node *child, *np;
+
+   if (!socfpga_is_a10())
+   return -ENODEV;
+
+   np = of_find_compatible_node(NULL, NULL,
+"altr,socfpga-a10-ecc-manager");
if (!np) {
edac_printk(KERN_ERR, EDAC_DEVICE, "ECC Manager not found\n");
return -ENODEV;
@@ -1545,8 +1555,12 @@ static irqreturn_t altr_edac_a10_ecc_irq_portb(int irq, 
void *dev_id)
 static int __init socfpga_init_sdmmc_ecc(void)
 {
int rc = -ENODEV;
-   struct device_node *child = of_find_compatible_node(NULL, NULL,
-   "altr,socfpga-sdmmc-ecc");
+   struct device_node *child;
+
+   if (!socfpga_is_a10())
+   return -ENODEV;
+
+   child = of_find_compatible_node(NULL, NULL, "altr,socfpga-sdmmc-ecc");
if (!child) {
edac_printk(KERN_WARNING, EDAC_DEVICE, "SDMMC node not 
found\n");
return -ENODEV;
-- 
1.9.1

Re: scope of cred_guard_mutex.

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 04/03, Eric W. Biederman wrote:
>>
>> You have asked why I have problems with your patch and so I am going to
>> try to explain.  Partly I want to see a clean set of patches that we
>> can merge into Linus's tree before we make any compromises.  Because the
>> work preparing a clean patchset may inform us of something better.  Plus
>> we need to make something clean and long term maintainable in any event.
>>
>> Partly I object because your understanding and my understanding of
>> cred_guard_mutex are very different.
>
> And I think there is another problem, your understanding and my understanding
> of "clean" differ too much and it seems that we can not convince each other ;)

We have barely begun.  You have not shown anyone what your idea of a
clean fix actually is.  All I have seen from you is a quick hack that is
a hack that is back-portable.

Focusing on the back port is the wrong order to solve the issue in.  We
need to solve this in an upstream mergable and maintainable way and then
we can worry about backports.

>From a userspace perspective.  I find anything in the kernel blocking on
a zombie to be just wrong.  A zombie is dead.  Waiting for a zombie should
in all cases be optional.  The system should not break if we don't reap
a zombie.

You have made a clear case that the zombies need to exist for strace -f
to wait on.  So since the zombies must exist we should make them follow
normal zombie rules.

With your change exec still blocks waiting for zombies.

Furthermore you have to violate the reasonable rule that:
* pre-exec resources are guarded with the pre-exec process cred.
* post-exec resources are guarded with the post-exec process cred.

So from a userspace perspective I think your semantics are absolutely
insane.

We also need clean code to implement all of this (which I am still
inching towards).  But we need to be implementing something that makes
sense from a userspace perspective.


> The last series looks buggy (I'll send more emails later today), but the
> main problem is that - in my opinion! - your approach is "obviously wrong
> and much less clean". But yes, yes, I understand that this is my opinion,
> and I can be wrong.

How is changing fixing the implementation so that we don't block waiting
for zombies to be reaped wrong?

> Eric, I think we need more CC's. Linus, probably security list, the more
> the better.
>
> I am going to resend my series with more CC's, then you can nack it and
> explain what you think we should do. Perhaps someone else will suggest
> a better solution, or at least review the patches. OK?

I will be happy to look but my primary objectionions to your patch were:

- You implemented a hack for backporting rather than fixing things
  cleanly the first time.

- You made comments about cred_guard_mutex and it's scope that when I
  reviewed the code were false.  cred_guard_mutex although probably the
  wrong locking structure is semantically and fundamentally where it
  needs to be.  We can optimize it but we can't change what is protected
  to make our lives easier.

Eric

Re: [PATCH 1/3] x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid

[Luck, Tony]

On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> That's just wrong.
> 
> The proper behaviour for a new control group is, that at the time when it
> is created it copies the CBM values of the default group and not claiming
> access to ALL of the cache by default.

I don't see that as any more helpful. When you make a new
control group it is because none of the existing groups
provides the QoS that you want.  So the first thing the
user will do is write the schemata file with the values
they do want.

So "all access", or "same as default group" are both the
same to the user ... not what they want.

We do need to make sure that the schemata matches what is
in the registers. We need to make sure that changes to the
schemata file result in the MSRs being written where needed.

-Tony

Re: [RFC][PATCH v2 3/5] clone: Disallown CLONE_THREAD with a shared sighand_struct

[Oleg Nesterov]

On 04/05, Eric W. Biederman wrote:
>
> Oleg Nesterov  writes:
>
> I agree that changing userspace semantics is something to be very
> careful with.  But at least for purposes of discussion I think this is a
> good patch.

I agree that we need it with your approach,

but imo it would be much better to not depend on the subtle changes
like this. My 2/2 or your 1/5 are already bad enough.

> I can avoid this change but it requires moving sighand->siglock
> into signal_struct and introducing a new spinlock into sighand_struct
> to just guard the signal handlers.

Oh, this looks much, much worse to me.

Oleg.

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

[Steven Rostedt]

On Wed, 5 Apr 2017 10:59:25 -0700
"Paul E. McKenney"  wrote:

> > Note, this has nothing to do with trace_rcu_dyntick(). It's the
> > function tracer tracing inside RCU, calling the stack tracer to record
> > a new stack if it sees its larger than any stack before. All I need is
> > a way to tell the stack tracer to not record a stack if it is in this
> > RCU critical section.
> > 
> > If you can add a "in_rcu_critical_section()" function, that the stack
> > tracer can test, and simply exit out like it does if in_nmi() is set,
> > that would work too. Below is my current work around.  
> 
> Except that the rcu_irq_enter() would already have triggered the bug
> that was (allegedly) fixed by my earlier patch.  So, yes, the check for
> rcu_is_watching() would work around this bug, but the hope is that
> with my earlier fix, this workaround would not be needed.

Note, if I had a "in_rcu_critical_section()" I wouldn't need to call
rcu_irq_enter(). I could fall out before that. My current workaround
does the check, even though it breaks things, it would hopefully fix
things as it calls rcu_irq_exit() immediately.

Would I would have is:

if (in_rcu_critical_section())
goto out;

rcu_irq_enter();

which would probably be the easiest fix.


> 
> So could you please test my earlier patch?

I could, but it wouldn't tell me anything immediately. It's a hard race
to hit. Which I never could hit it when I tried, but it would appear to
hit immediately when testing other things :-p

Remember, it only triggers when a new max stack size is hit. The bug
happens when that new max stack size is in the rcu critical section.

I guess I could force it to trigger by inserting a call in your code
that clears the max stack size.

-- Steve

> 
> This patch does not conflict with anything on -rcu, so you could
> carry it if that helps.
> 

[PATCH v7 1/7] xen: import new ring macros in ring.h

[Stefano Stabellini]

Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org

---
NB: The new macros have been committed to Xen. It is OK to apply this
patch now.
---
---
 include/xen/interface/io/ring.h | 143 
 1 file changed, 143 insertions(+)

diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 21f4fbd..c794568 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -283,4 +283,147 @@ struct __name##_back_ring {   
\
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (XEN_FLEX_RING_SIZE() -
+ *   $NAME_queued()).
+ */
+
+#ifndef XEN_PAGE_SHIFT
+/* The PAGE_SIZE for ring protocols and hypercall interfaces is always
+ * 4K, regardless of the architecture, and page granularity chosen by
+ * operating systems.
+ */
+#define XEN_PAGE_SHIFT 12
+#endif
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << ((order) + XEN_PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING(name)\
+static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size)  \
+{ \
+return idx & (ring_size - 1); \
+} \
+  \
+static inline unsigned char *name##_get_ring_ptr(unsigned char *buf,  \
+ RING_IDX idx,\
+ RING_IDX ring_size)  \
+{ \
+return buf + name##_mask(idx, ring_size); \
+} \
+  \
+static inline void name##_read_packet(void *opaque,   \
+  const unsigned char *buf,   \
+  size_t size,\
+  RING_IDX masked_prod,   \
+  RING_IDX *masked_cons,  \
+  RING_IDX ring_size) \
+{ \
+if (*masked_cons < masked_prod || \
+size <= ring_size - *masked_cons) {   \
+memcpy(opaque, buf + *masked_cons, size); \
+} else {  \
+memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \
+memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf,   \
+   size - (ring_size - *masked_cons));\
+} \
+*masked_cons = name##_mask(*masked_cons + size, ring_size);  

[PATCH v7 0/7] Xen transport for 9pfs frontend driver

[Stefano Stabellini]

Hi all,

This patch series implements a new transport for 9pfs, aimed at Xen
systems.

The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the frontend, which typically runs in
a regular unprivileged guest.

I also sent a series that implements the backend in userspace in QEMU,
which typically runs in Dom0 (but could also run in a another guest).

The frontend complies to the Xen transport for 9pfs specification
version 1, available here:

https://xenbits.xen.org/docs/unstable/misc/9pfs.html


The new Xen ring macros pulled in Linux in the first patch of the series
have been committed upstream in Xen, so there is nothing holding back
this series any longer. It could be considered for 4.12 or 4.13. It
should probably go via the Xen tree.


Changes in v7:
- merging the final version of the macros (Xen upstream commit
  f000908276382e1c0a3de359f9bbc7ba83999119)
- fixup argument ordering of the ring/write_packet macros callers

Changes in v6:
- add reviewd-bys
- fix error paths
- make p9_xen_write_todo return bool

Changes in v5:
- test priv->tag instead of ret
- run checkpatch.pl against the whole series, fix all issues
- set intf->ring_order appropriately
- use shorter link to 9pfs spec

Changes in v4:
- code style improvements
- use xenbus_read_unsigned when possible
- do not leak "versions"
- introduce BUILD_BUG_ON
- introduce rwlock to protect the xen_9pfs_devs list
- add review-by

Changes in v3:
- add full copyright header to trans_xen.c
- rename ring->ring to ring->data
- handle gnttab_grant_foreign_access errors
- remove ring->bytes
- wrap long lines
- add reviewed-by

Changes in v2:
- use XEN_PAGE_SHIFT instead of PAGE_SHIFT
- remove unnecessary initializations
- fix error paths
- fix memory allocations for 64K kernels
- simplify p9_xen_create and p9_xen_close
- use virt_XXX barriers
- set status = REQ_STATUS_ERROR inside the p9_xen_response loop
- add in-code comments


Stefano Stabellini (7):
  xen: import new ring macros in ring.h
  xen: introduce the header file for the Xen 9pfs transport protocol
  xen/9pfs: introduce Xen 9pfs transport driver
  xen/9pfs: connect to the backend
  xen/9pfs: send requests to the backend
  xen/9pfs: receive responses
  xen/9pfs: build 9pfs Xen transport driver

 include/xen/interface/io/9pfs.h |  36 +++
 include/xen/interface/io/ring.h | 143 +++
 net/9p/Kconfig  |   8 +
 net/9p/Makefile |   4 +
 net/9p/trans_xen.c  | 545 
 5 files changed, 736 insertions(+)
 create mode 100644 include/xen/interface/io/9pfs.h
 create mode 100644 net/9p/trans_xen.c

Cheers,

Stefano

[PATCH v5 0/7] add support for AXP20X and AXP22X battery power supply driver

[Quentin Schulz]

This is a series for AXP20X and AXP22X battery power supply without the
support for changing constant charge current from the DT. The patches for
supporting the constant charge current from DT are ready and will be sent
once the battery framework required to make this work has been merged.

Quote from v4 cover letter:

The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
information and data of the various power supplies they support such as
ACIN, battery and VBUS. For example, they expose the current battery
voltage, charge or discharge, as well as ACIN and VBUS current voltages
and currents, internal PMIC temperature and ADC on 2 different GPIOs
when in the right mode (for the AXP209 only).

The ACIN power supply driver is added by this patch. The AXP20X and
AXP22X can both read the status and the "usability" of the power supply
but only the AXP209 will be able to tell the current current and voltage
of the power supply by reading ADC channels. It is simply not supported
by the AXP22X PMICs.

The battery power supply driver is also added by this patch. The AXP20X
and AXP22X share most of their behaviour but have slight variations. The
allowed target voltages for battery charging are not the same, the
AXP22X PMIC are able to tell if the battery percentage computed by the
PMIC is trustworthy and they have different formulas for computing max
current for battery power supply. The driver is able to give the current
voltage and current of the battery (be it charging or discharging), the
maximal and minimal voltage and maximal current allowed for the battery,
whether the battery is present and usable and its capacity. It will get
the battery current current and voltage by reading the ADC channels. The
PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
AXP22X) that should not be used with Lithium-based batteries and since
this PMIC is supposed to be used with Lithium-based batteries, they have
been disabled. The values returned by the ADC driver are multipled by
1000 to scale from the mV returned by the ADC to the uV expected by the
power supply framework.

This series of patch adds DT bindings for ACIN power supply, ADC and
battery power supply drivers for AXP20X and AXP22X PMICs and their
documentation. It also enables the supported power supplies for the
Nextthing Co. CHIP and Sinlinx SinA33 boards.

The different drivers are also added to the MFD cells of the AXP20X and
AXP22X cells and the writeable and volatile regs updated to work with
the newly added drivers.

This series of patch is based on a previous upstreaming attempt done by
Bruno Prémont few months ago. It differs in three points: the ADC
driver does not tell the battery temperature (TS_IN) as I do not have a
board to test it with, it does not tell the instantaneous battery power
as it returns crazy values for me and finally no support for OCV curves
for the battery.

You can test these patches from this repo and branch:
https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4

v4:
 - added the ability to set maximum constant charge current from sysfs,
 - added a warning when setting a higher than current maximum constant charge
 current,
 - set default to minimum possible value for current and maximum constant charge
 current when no battery DT is present or invalid battery DT,
 - fixed a forgotten custom formula to compute maximum constant charge current
 for AXP22X,
 - automatically lower the current constant charge current when it is higher
 than the maximum constant charge current about to be set,

v3:
 - Removed DT property for constant charge current in favor of the WIP
 battery framework as requested by Sebastian Reichel,
 - Using a simple if condition instead of a switch in the ADC driver,
 - Fixed error handling in ADC driver's probe,
 - Fixed missing call to iio_map_array_unregister in the ADC driver's
 remove,
 - Removed ADC driver's DT node and documentation,
 - Merged IIO channel mapping patches into the original ADC driver
 patch,
 - Removed `adding V-OFF to writeable reg' patch as it's already in
 writeable reg range,

v2:
 - Some registers' name have been changed to better reflect their
 purpose,
 - Make VBUS power supply driver use IIO channels when AXP ADC driver is
 enabled, but fall back on previous behavior when disabled. This is made
 to avoid the ADC driver overwritting registers for VBUS power supply
 ADC when removed,
 - Removed useless adding of data registers to volatile registers,
 - Reordered IIO channels, now grouped by same part of the PMIC (e.g.
 voltage and current of the battery have the same index in different
 IIO types),
 - Added structures for specific data instead of matching on IDs,
 - Switched from DT IIO channels mapping to iio_map structures IIO
 channels mapping,

Quentin

Quentin Schulz (7):
  dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
  power: supply: add battery driver for AXP20X and AXP22X PMICs
  mfd: axp20x: add MFD cells for AXP20X 

[PATCH 2/2] Revert "f2fs: put allocate_segment after refresh_sit_entry"

[Jaegeuk Kim]

This reverts commit 3436c4bdb30de421d46f58c9174669fbcfd40ce0.

This makes a leak to register dirty segments. I reproduced the issue by
modified postmark which injects a lot of file create/delete/update and
finally triggers huge number of SSR allocations.

Cc:  # v4.10+
[Jaegeuk Kim: Change missing incorrect comment]
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index eedbed62947f..ed81fa5d64bf 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1893,15 +1893,14 @@ void allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
 
stat_inc_block_count(sbi, curseg);
 
+   if (!__has_curseg_space(sbi, type))
+   sit_i->s_ops->allocate_segment(sbi, type, false);
/*
-* SIT information should be updated before segment allocation,
-* since SSR needs latest valid block information.
+* SIT information should be updated after segment allocation,
+* since we need to keep dirty segments precisely under SSR.
 */
refresh_sit_entry(sbi, old_blkaddr, *new_blkaddr);
 
-   if (!__has_curseg_space(sbi, type))
-   sit_i->s_ops->allocate_segment(sbi, type, false);
-
mutex_unlock(_i->sentry_lock);
 
if (page && IS_NODESEG(type))
-- 
2.11.0

Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver

[Pavel Machek]

On Wed 2017-04-05 13:58:39, Lucas Stach wrote:
> Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek:
> > Hi!
> > 
> > > + * video stream multiplexer controlled via gpio or syscon
> > > + *
> > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer 
> > > + * Copyright (C) 2016 Pengutronix, Philipp Zabel 
> > 
> > This is actually quite interesting. Same email address for two
> > people...
> > 
> > Plus, I believe this wants to say that copyright is with Pengutronix,
> > not Sascha and Philipp. In that case you probably want to list
> > copyright and authors separately?
> > 
> Nope, copyright doesn't get transferred to the employer within the rules
> of the German "Urheberrecht", but stays at the original author of the
> code.

Ok, then I guess it should be

Copyright (C) 2013 Sascha Hauer
Work sponsored by Pengutronix, use  as contact address

or something? I know license change is not on the table, but I guess
it is good to get legal stuff right.
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 1/8] Documentation, x86: Intel Memory bandwidth allocation

[Shivappa Vikas]

On Wed, 5 Apr 2017, Thomas Gleixner wrote:


On Mon, 3 Apr 2017, Vikas Shivappa wrote:

+Cache resource(L3/L2)  subdirectory contains the following files:

-"num_closids":  The number of CLOSIDs which are valid for this
-   resource. The kernel uses the smallest number of
-   CLOSIDs of all enabled resources as limit.
+"num_closids":   The number of CLOSIDs which are valid for this
+   resource. The kernel uses the smallest number of
+   CLOSIDs of all enabled resources as limit.

-"cbm_mask": The bitmask which is valid for this resource. This
-   mask is equivalent to 100%.
+"cbm_mask":  The bitmask which is valid for this resource.
+   This mask is equivalent to 100%.

-"min_cbm_bits": The minimum number of consecutive bits which must be
-   set when writing a mask.
+"min_cbm_bits":  The minimum number of consecutive bits which
+   must be set when writing a mask.

+Memory bandwitdh(MB) subdirectory contains the following files:


This has a num_closids file as well, right?


Yes. copy below - just indented same text

 -"num_closids":  The number of CLOSIDs which are valid for this
 -resource. The kernel uses the smallest number of
 -CLOSIDs of all enabled resources as limit.
 +"num_closids":  The number of CLOSIDs which are valid for this
 +resource. The kernel uses the smallest number of
 +CLOSIDs of all enabled resources as limit.

Thanks,
Vikas



Thanks,

tglx

RE: [PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

[Ghannam, Yazen]

> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, April 05, 2017 1:22 PM
> To: Ghannam, Yazen 
> Cc: linux-e...@vger.kernel.org; Tony Luck ;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA
> MCA_DE{STAT,ADDR} registers
> 
> On Wed, Apr 05, 2017 at 05:06:19PM +, Ghannam, Yazen wrote:
> > Checking if we have a valid deferred error. Since we call
> > __log_error() on thresholding interrupts too we would need to tell it
> > which handler is calling it to do the correct check. This is what we 
> > currently
> do.
> 
> That's why I suggested a __log_error_deferred() - a separate function which
> deals with deferred errors.
> 
> > What do you mean " we don't have anything"? We check if we have a
> > valid deferred error in is_deferred_error(). Otherwise, we don't log
> anything.
> 
> So the normal status MSR says whether we have a deferred error or not.
> If it says we don't, then we have to look at the DE* MSRs, correct?
> 

Correct, but only on SMCA systems.

> If yes, then do it exactly like this.
> 
> Not:
> 
>   IF deferred:
>   log
>   ELSE IF SMCA:
>   IF deferred:
>   log
> 

This works so I don't know why it's not okay. Your suggestion also does an
SMCA check. So code that does a check-and-return is preferable to code
using if/else-if statements? If that's the case then I can try to rework it.

> but:
> 
>   IF deferred:
>   log_deferred:
>   log
>   IF cannot log from normal MSRs

How does log_error() know if we can't use the normal MSRs? We check
for MCI_STATUS_VAL in log_error(). We also need to check for
MCI_STATUS_DEFERRED but only if we're coming from the deferred error
handler.

>   log from DE
> 
> Why are we even wasting time with this?!
> 

I don't know. 

Thanks,
Yazen

Re: scope of cred_guard_mutex.

[Oleg Nesterov]

On 04/05, Eric W. Biederman wrote:
>
> Oleg Nesterov  writes:
>
> - You made comments about cred_guard_mutex and it's scope that when I
>   reviewed the code were false.

Too late for me. I'll try to read other emails from you and reply tomorrow.

Oleg.

Re: [PATCH 0/6] mm: make movable onlining suck less

[Michal Hocko]

On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> >But one thing that is really bugging me is how could you see low pfns in
> >the previous oops. Please drop the last patch and sprinkle printks down
> >the remove_memory path to see where this all go south. I believe that
> >there is something in the initialization code lurking in my code. Please
> >also scratch the pfn_valid check in online_pages diff. It will not help
> >here.
> 
> Got it.
> 
> shrink_pgdat_span: start_pfn=0x1, end_pfn=0x10100, pgdat_start_pfn=0x0, 
> pgdat_end_pfn=0x2
> 
> The problem is that pgdat_start_pfn here should be 0x1. As you
> suspected, it never got set. This fixes things for me.
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 623507f..37c1b63 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -884,7 +884,7 @@ static void __meminit resize_pgdat_range(struct 
> pglist_data *pgdat, unsigned lon
> {
>   unsigned long old_end_pfn = pgdat_end_pfn(pgdat);
> 
> - if (start_pfn < pgdat->node_start_pfn)
> + if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
>   pgdat->node_start_pfn = start_pfn;

Dang! You are absolutely right. This explains the issue during the
remove_memory. I still fail to see how this makes any difference for the
sysfs file registration though. If anything the pgdat will be larger and
so try_offline_node would check also unrelated node0 but the code will
handle that and eventually offline the node1 anyway. /me still confused.
 
>   pgdat->node_spanned_pages = max(start_pfn + nr_pages, old_end_pfn) - 
> pgdat->node_start_pfn;
> ---
> 
> Along these lines, maybe we should also do
> 
> - if (start_pfn < zone->zone_start_pfn)
> + if (zone_is_empty(zone) || start_pfn < zone->zone_start_pfn)

yes we should.

Thanks a lot!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

[Borislav Petkov]

On Wed, Apr 05, 2017 at 05:53:57PM +, Ghannam, Yazen wrote:
> Correct, but only on SMCA systems.

On !SMCA systems you log only once anyway - you don't have DE* MSRs.

> This works so I don't know why it's not okay.

So I should take the code just because you have found one way that it
works? Screw readability or future proof design - people should dump the
code on maintainers and maintainers should deal with the stinking pile.
Who cares, it works for you.

> Your suggestion also does an SMCA check.

Why TF does that even matter? Enough with the dumb checks argument
already.

> So code that does a check-and-return is preferable to code using
> if/else-if statements? If that's the case then I can try to rework it.

No, readable code matters. Your suggestion is confusing. I see

if (is_deferred_error(status)) {
__log_error
} else if (mce_flags.smca) {
...
if (is_deferred_error(status))

But then here --->

we still deal with deferred errors. Even though we did the deferred
check in the if-clause. And that is confusing and makes the code hard to
follow.

My suggestion does *exactly* what the commit message says:

if (__log_error(..))
goto out;

when we go to the out label, we know we've succeeded logging the
deferred error and we're done.

if (!mce_flags.smca)
return;

When we return here, we know, we've taken care of the !SMCA systems. Now
here starts the second attempt to read the DE* registers and we *know*
we're on SMCA systems.

> How does log_error() know if we can't use the normal MSRs?

MCI_STATUS_VAL.

> We check for MCI_STATUS_VAL in log_error().

Yes.

> We also need to check for MCI_STATUS_DEFERRED but only if we're coming
> from the deferred error handler.

Why? We *are* coming from the #DF handler so are you expecting a
different type of error in the MSRs?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC][PATCH v2 5/5] signal: Don't allow accessing signal_struct by old threads after exec

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 04/02, Eric W. Biederman wrote:
>>
>> Add exec_id to signal_struct and compare it at a few choice moments.
>
> I really dislike this change no matter what, sorry.
>
> Firstly, task_struct->*_exec_id should simply die (I already have the
> patch), or at least they should be moved into signal_struct simply
> because this is per-process thing.

I am quite happy to find a better way to implement this.  More than
anything this was my proof of concept that it is possible to close
the security holes created if we allow our zombies to be normal zombies.


>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -995,6 +995,10 @@ static int __send_signal(int sig, struct siginfo *info, 
>> struct task_struct *t,
>>  from_ancestor_ns || (info == SEND_SIG_FORCED)))
>>  goto ret;
>>
>> +/* Don't allow thread group signals after exec */
>> +if (group && (t->signal->exec_id != t->self_exec_id))
>> +goto ret;
>
> Hmm. Either we do not need this exec_id check at all, or we should not
> take "group" into account; a fatal signal (say SIGKILL) will kill the
> whole thread-group.

Wow.  Those are crazy semantics for fatal signals.  Sending a tkill
should not affect the entire thread group.  Oleg I think this is a bug
you introduced and likely requires a separate fix.

I really don't understand the logic in:

commit 5fcd835bf8c2cde06404559b1904e2f1dfcb4567
Author: Oleg Nesterov 
Date:   Wed Apr 30 00:52:55 2008 -0700

signals: use __group_complete_signal() for the specific signals too

Based on Pavel Emelyanov's suggestion.

Rename __group_complete_signal() to complete_signal() and use it to process
the specific signals too.  To do this we simply add the "int group" 
argument.

This allows us to greatly simply the signal-sending code and adds a useful
behaviour change.  We can avoid the unneeded wakeups for the private signals
because wants_signal() is more clever than sigismember(blocked), but more
importantly we now take into account the fatal specific signals too.

The latter allows us to kill some subtle checks in handle_stop_signal() and
makes the specific/group signal's behaviour more consistent.  For example,
currently sigtimedwait(FATAL_SIGNAL) behaves differently depending on was 
the
signal sent by kill() or tkill() if the signal was not blocked.

And.  This allows us to tweak/fix the behaviour when the specific signal is
sent to the dying/dead ->group_leader.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Oleg Nesterov 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

>> @@ -1247,7 +1251,8 @@ struct sighand_struct *__lock_task_sighand(struct 
>> task_struct *tsk,
>>   * must see ->sighand == NULL.
>>   */
>>  spin_lock(>siglock);
>> -if (likely(sighand == tsk->sighand)) {
>> +if (likely((sighand == tsk->sighand) &&
>> +   (tsk->self_exec_id == tsk->signal->exec_id))) {
>
> Oh, this doesn't look good to me. Yes, with your approach we probably need
> this to, say, ensure that posix-cpu-timer can't kill the process after exec,
> but I'd rather add the exit_state check into run_posix_timers().

The entire point of lock_task_sighand is to not operate on
tasks/processes that have exited. The fact it even sighand in there is
deceptive because it is all about siglock and nothing to do with
sighand.

> But OK, suppose that we fix the problems with signal-after-exec.
>
> 
> Now lets fix another problem. A mt exec suceeds and apllication does
> sys_seccomp(SECCOMP_FILTER_FLAG_TSYNC) which fails because it finds
> another (zombie) SECCOMP_MODE_FILTER thread.
>
> And after we fix this problem, what else we will need to fix?
>
>
> I really think that - whatever we do - there should be no other threads
> after exec, even zombies.

I see where you are coming from.

I need to stare at this a bit longer.  Because you are right.  Reusing
the signal_struct and leaving zombies around is very prone to bugs.  So
it is not very maintainable.

I suspect the answer here is to simply allocate a new sighand_struct and
a new signal_struct if there we are not single threaded by the time we
get down to the end of de_thread.

However even if it is a case of whack-a-mole semantically
not-blocking-for-zombies looks like the right thing to do and we need to
figure out how to do it maintainably.

Eric

Re: [PATCH v23 06/11] clocksource: arm_arch_timer: refactor MMIO timer probing.

[Mark Rutland]

On Sat, Apr 01, 2017 at 01:51:00AM +0800, fu@linaro.org wrote:
> + arch_timer_mem_freq = arch_timer_mem_get_cntfrq(base);
> + if (!arch_timer_rate && arch_timer_mem_freq) {
> + arch_timer_rate = arch_timer_mem_freq;
> + } else if (!arch_timer_rate || arch_timer_rate != arch_timer_mem_freq) {
> + pr_err(FW_BUG "invalid MMIO frequency.\n");
> + iounmap(base);
> + return -EINVAL;
> + }

I thought I had previously mentioned that this last check has the
potential to break DT systems, which may be inadvertently relying on the
probe order.

I agree we must do this check for ACPI, but I think that for DT it needs
to be relaxed.

I'm happy to rework that locally, if you can address my comments on
patch 9.

Thanks,
Mark.

[PATCH v7 6/7] xen/9pfs: receive responses

[Stefano Stabellini]

Upon receiving a notification from the backend, schedule the
p9_xen_response work_struct. p9_xen_response checks if any responses are
available, if so, it reads them one by one, calling p9_client_cb to send
them up to the 9p layer (p9_client_cb completes the request). Handle the
ring following the Xen 9pfs specification.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
CC: gr...@kaod.org
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 28f30f4..4786424 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -189,6 +189,62 @@ static int p9_xen_request(struct p9_client *client, struct 
p9_req_t *p9_req)
 
 static void p9_xen_response(struct work_struct *work)
 {
+   struct xen_9pfs_front_priv *priv;
+   struct xen_9pfs_dataring *ring;
+   RING_IDX cons, prod, masked_cons, masked_prod;
+   struct xen_9pfs_header h;
+   struct p9_req_t *req;
+   int status;
+
+   ring = container_of(work, struct xen_9pfs_dataring, work);
+   priv = ring->priv;
+
+   while (1) {
+   cons = ring->intf->in_cons;
+   prod = ring->intf->in_prod;
+   virt_rmb();
+
+   if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) <
+   sizeof(h)) {
+   notify_remote_via_irq(ring->irq);
+   return;
+   }
+
+   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+   /* First, read just the header */
+   xen_9pfs_read_packet(, ring->data.in, sizeof(h),
+masked_prod, _cons,
+XEN_9PFS_RING_SIZE);
+
+   req = p9_tag_lookup(priv->client, h.tag);
+   if (!req || req->status != REQ_STATUS_SENT) {
+   dev_warn(>dev->dev, "Wrong req tag=%x\n", h.tag);
+   cons += h.size;
+   virt_mb();
+   ring->intf->in_cons = cons;
+   continue;
+   }
+
+   memcpy(req->rc, , sizeof(h));
+   req->rc->offset = 0;
+
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+   /* Then, read the whole packet (including the header) */
+   xen_9pfs_read_packet(req->rc->sdata, ring->data.in, h.size,
+masked_prod, _cons,
+XEN_9PFS_RING_SIZE);
+
+   virt_mb();
+   cons += h.size;
+   ring->intf->in_cons = cons;
+
+   status = (req->status != REQ_STATUS_ERROR) ?
+   REQ_STATUS_RCVD : REQ_STATUS_ERROR;
+
+   p9_client_cb(priv->client, req, status);
+   }
 }
 
 static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
-- 
1.9.1

Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3

[Rob Herring]

On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng  wrote:
>
>
> 在 2017年04月04日 22:47, Rob Herring 写道:
>>
>> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner H3 features a thermal sensor like the one in A33, but has its
>>> register re-arranged, the clock divider moved to CCU (originally the
>>> clock divider is in ADC) and added a pair of bus clock and reset.
>>>
>>> Update the binding document to cover H3.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  .../devicetree/bindings/mfd/sun4i-gpadc.txt| 23
>>> --
>>>  1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> index badff3611a98..7753133ca0ff 100644
>>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as
>>> a thermal sensor
>>>  and sometimes as a touchscreen controller.
>>>
>>>  Required properties:
>>> -  - compatible: "allwinner,sun8i-a33-ths",
>>> +  - compatible: must contain one of the following compatibles:
>>> +   - "allwinner,sun8i-a33-ths"
>>> +   - "allwinner,sun8i-h3-ths"
>>>- reg: mmio address range of the chip,
>>>- #thermal-sensor-cells: shall be 0,
>>>- #io-channel-cells: shall be 0,
>>>
>>> -Example:
>>> +Required properties for the following compatibles:
>>> +   - "allwinner,sun8i-h3-ths"
>>> +  - clocks: the bus clock and the input clock of the ADC,
>>> +  - clock-names: should be "bus" and "ths",
>>> +  - resets: the bus reset of the ADC,
>>> +
>>> +Example for A33:
>>> ths: ths@01c25000 {
>>> compatible = "allwinner,sun8i-a33-ths";
>>> reg = <0x01c25000 0x100>;
>>> @@ -17,6 +25,17 @@ Example:
>>> #io-channel-cells = <0>;
>>> };
>>>
>>> +Example for H3:
>>> +   ths: ths@01c25000 {
>>
>>
>> adc@...
>
>
> It's a thermal sensor, so I think call it THS is more appropriate
> here. It's implemented as an ADC driver just because the internal
> code reusing of Linux. From device tree binding view I choose to
> call it ths.

There's numerous occurrences in this file and the filename that call it an ADC.

Furthermore, node names are supposed to be generic, not part #'s or
whatever you decide to make up. So pick from adc or temperature-sensor
as those are the standard names .

Rob

[PATCH v7 5/7] xen/9pfs: send requests to the backend

[Stefano Stabellini]

Implement struct p9_trans_module create and close functions by looking
at the available Xen 9pfs frontend-backend connections. We don't expect
many frontend-backend connections, thus walking a list is OK.

Send requests to the backend by copying each request to one of the
available rings (each frontend-backend connection comes with multiple
rings). Handle the ring and notifications following the 9pfs
specification. If there are not enough free bytes on the ring for the
request, wait on the wait_queue: the backend will send a notification
after consuming more requests.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
CC: gr...@kaod.org
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 87 --
 1 file changed, 85 insertions(+), 2 deletions(-)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index fe3d172..28f30f4 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -85,22 +85,105 @@ struct xen_9pfs_front_priv {
 static LIST_HEAD(xen_9pfs_devs);
 static DEFINE_RWLOCK(xen_9pfs_lock);
 
+/* We don't currently allow canceling of requests */
 static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
 {
-   return 0;
+   return 1;
 }
 
 static int p9_xen_create(struct p9_client *client, const char *addr, char 
*args)
 {
-   return 0;
+   struct xen_9pfs_front_priv *priv;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (!strcmp(priv->tag, addr)) {
+   priv->client = client;
+   read_unlock(_9pfs_lock);
+   return 0;
+   }
+   }
+   read_unlock(_9pfs_lock);
+   return -EINVAL;
 }
 
 static void p9_xen_close(struct p9_client *client)
 {
+   struct xen_9pfs_front_priv *priv;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (priv->client == client) {
+   priv->client = NULL;
+   read_unlock(_9pfs_lock);
+   return;
+   }
+   }
+   read_unlock(_9pfs_lock);
+}
+
+static bool p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
+{
+   RING_IDX cons, prod;
+
+   cons = ring->intf->out_cons;
+   prod = ring->intf->out_prod;
+   virt_mb();
+
+   return XEN_9PFS_RING_SIZE -
+   xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) >= size;
 }
 
 static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
 {
+   struct xen_9pfs_front_priv *priv = NULL;
+   RING_IDX cons, prod, masked_cons, masked_prod;
+   unsigned long flags;
+   u32 size = p9_req->tc->size;
+   struct xen_9pfs_dataring *ring;
+   int num;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (priv->client == client)
+   break;
+   }
+   read_unlock(_9pfs_lock);
+   if (!priv || priv->client != client)
+   return -EINVAL;
+
+   num = p9_req->tc->tag % priv->num_rings;
+   ring = >rings[num];
+
+again:
+   while (wait_event_interruptible(ring->wq,
+   p9_xen_write_todo(ring, size)) != 0)
+   ;
+
+   spin_lock_irqsave(>lock, flags);
+   cons = ring->intf->out_cons;
+   prod = ring->intf->out_prod;
+   virt_mb();
+
+   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
+XEN_9PFS_RING_SIZE) < size) {
+   spin_unlock_irqrestore(>lock, flags);
+   goto again;
+   }
+
+   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+   xen_9pfs_write_packet(ring->data.out, p9_req->tc->sdata, size,
+ _prod, masked_cons, XEN_9PFS_RING_SIZE);
+
+   p9_req->status = REQ_STATUS_SENT;
+   virt_wmb(); /* write ring before updating pointer */
+   prod += size;
+   ring->intf->out_prod = prod;
+   spin_unlock_irqrestore(>lock, flags);
+   notify_remote_via_irq(ring->irq);
+
return 0;
 }
 
-- 
1.9.1

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

[Paul E. McKenney]

On Wed, Apr 05, 2017 at 02:54:25PM -0400, Steven Rostedt wrote:
> On Wed, 5 Apr 2017 10:59:25 -0700
> "Paul E. McKenney"  wrote:
> 
> > > Note, this has nothing to do with trace_rcu_dyntick(). It's the
> > > function tracer tracing inside RCU, calling the stack tracer to record
> > > a new stack if it sees its larger than any stack before. All I need is
> > > a way to tell the stack tracer to not record a stack if it is in this
> > > RCU critical section.
> > > 
> > > If you can add a "in_rcu_critical_section()" function, that the stack
> > > tracer can test, and simply exit out like it does if in_nmi() is set,
> > > that would work too. Below is my current work around.  
> > 
> > Except that the rcu_irq_enter() would already have triggered the bug
> > that was (allegedly) fixed by my earlier patch.  So, yes, the check for
> > rcu_is_watching() would work around this bug, but the hope is that
> > with my earlier fix, this workaround would not be needed.
> 
> Note, if I had a "in_rcu_critical_section()" I wouldn't need to call
> rcu_irq_enter(). I could fall out before that. My current workaround
> does the check, even though it breaks things, it would hopefully fix
> things as it calls rcu_irq_exit() immediately.

OK, color me confused.  What would "in_rcu_critical_section()" do?

The rcu_is_watching() function tells you that RCU is not in an extended
quiescent state, though its return value can be iffy in the middle of
rcu_eqs_enter_common() -- which is why interrupts are disabled there.
In preemptible RCU, you can (but shouldn't) use rcu_preempt_depth()
to determine whether you are within an RCU read-side critical section,
which is what in_rcu_critical_section() sounds like to me, but I don't
see how this information would help in this situation.

What am I missing here?

> Would I would have is:
> 
>   if (in_rcu_critical_section())
>   goto out;
> 
>   rcu_irq_enter();
> 
> which would probably be the easiest fix.
> 
> 
> > 
> > So could you please test my earlier patch?
> 
> I could, but it wouldn't tell me anything immediately. It's a hard race
> to hit. Which I never could hit it when I tried, but it would appear to
> hit immediately when testing other things :-p
> 
> Remember, it only triggers when a new max stack size is hit. The bug
> happens when that new max stack size is in the rcu critical section.
> 
> I guess I could force it to trigger by inserting a call in your code
> that clears the max stack size.

I know it is a bit of a hassle, but I would really appreciate the
testing.

Thanx, Paul

> -- Steve
> 
> > 
> > This patch does not conflict with anything on -rcu, so you could
> > carry it if that helps.
> > 
> 

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

[Ard Biesheuvel]

On 5 April 2017 at 18:21, Robin Murphy  wrote:
> On 05/04/17 18:08, Ard Biesheuvel wrote:
>> Hoi Matthias!
>>
>> On 5 April 2017 at 17:56, Matthias Kaehlcke  wrote:
>>> From: Greg Hackmann 
>>>
>>> The current definition of ASM_EXPORT doesn't work properly with clang,
>>> according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
>>> gcc specific behavior. Change the constraint from an intermediate to an
>>> output expression which works with both gcc and clang.
>>>
>>> From: Greg Hackmann 
>>> Commit-message-by: Matthias Kaehlcke 
>>> Signed-off-by: Greg Hackmann 
>>> Signed-off-by: Matthias Kaehlcke 
>>> ---
>>>  arch/arm64/crypto/sha1-ce-glue.c | 2 +-
>>>  arch/arm64/crypto/sha2-ce-glue.c | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/crypto/sha1-ce-glue.c 
>>> b/arch/arm64/crypto/sha1-ce-glue.c
>>> index aefda9868627..c71e94ba0e43 100644
>>> --- a/arch/arm64/crypto/sha1-ce-glue.c
>>> +++ b/arch/arm64/crypto/sha1-ce-glue.c
>>> @@ -18,7 +18,7 @@
>>>  #include 
>>>
>>>  #define ASM_EXPORT(sym, val) \
>>> -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
>>> +   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>>>
>>>  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
>>>  MODULE_AUTHOR("Ard Biesheuvel ");
>>> diff --git a/arch/arm64/crypto/sha2-ce-glue.c 
>>> b/arch/arm64/crypto/sha2-ce-glue.c
>>> index 7cd587564a41..381b5fb2dcb2 100644
>>> --- a/arch/arm64/crypto/sha2-ce-glue.c
>>> +++ b/arch/arm64/crypto/sha2-ce-glue.c
>>> @@ -18,7 +18,7 @@
>>>  #include 
>>>
>>>  #define ASM_EXPORT(sym, val) \
>>> -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
>>> +   asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>>>
>>>  MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
>>> Extensions");
>>>  MODULE_AUTHOR("Ard Biesheuvel ");
>>
>> I am fine with this change, although I would really like to add a
>> better reference to the commit log. It is *very* difficult to find any
>> documentation regarding non-trivial uses of inline asm constraints,
>> and if %c0 is the correct syntax, surely we can quote something better
>> than a LLVM bugzilla entry? Also, where does the distinction between
>> 'intermediate' vs 'output' expression come from?
>
> FWIW, GCC docs do say (under the helpfully-obvious "x86 operand
> modifiers" section[1]):
>
> c   Require a constant operand and print the constant
> expression with no punctuation.
>
> Which more or less makes sense in this this context too. As an aside,
> though, since this is emitting a general integer argument to an
> assembler directive, and not an operand to an ADD instruction, how come
> we're using "I" and not "i" as the constraint in the first place?
>

No reason. "I" came to mind when writing the code, and worked as
expected. Perhaps we should just fix that at the same time.

Re: [RFC][PATCH v2 3/5] clone: Disallown CLONE_THREAD with a shared sighand_struct

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 04/02, Eric W. Biederman wrote:
>>
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1515,6 +1515,13 @@ static __latent_entropy struct task_struct 
>> *copy_process(
>>  if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
>>  return ERR_PTR(-EINVAL);
>>
>> +/* Disallow CLONE_THREAD with a shared SIGHAND structure.  No
>> + * one cares
>
> Well, can't resists... I won't argue, but we can't know if no one cares
> or not. I agree that most probably this won't break something, but who
> knows... I am always scared when we add the incompatible changes.

I agree that changing userspace semantics is something to be very
careful with.  But at least for purposes of discussion I think this is a
good patch.

I can avoid this change but it requires moving sighand->siglock
into signal_struct and introducing a new spinlock into sighand_struct
to just guard the signal handlers.

However I think the change to move siglock would be a distraction from
the larger issues of this patchset.

Once we address the core issues I will be happy to revisit this.

>> and supporting it leads to unnecessarily complex
>> + * code.
>> + */
>> +if ((clone_flags & CLONE_THREAD) && 
>> (atomic_read(>sighand->count) > 1))
>> +return ERR_PTR(-EINVAL);
>
> Perhaps the comment should explain why we do this and say that
> sighand-unsharing in de_thread() depends on this.

That would be a better comment.

Eric