Re: [PATCH 5/5] vmlinux.lds.h: replace config_enabled() with IS_ENABLED()

[Arnd Bergmann]

On Tuesday, June 21, 2016 8:20:10 AM CEST Masahiro Yamada wrote:
> 2016-06-21 5:45 GMT+09:00 Michal Marek :
> > Dne 14.6.2016 v 07:58 Masahiro Yamada napsal(a):
> >> The use of config_enabled() against config options is ambiguous.
> >>
> >> Now, IS_ENABLED() is implemented purely with macro expansion, so
> >> let's replace config_enabled() with IS_ENABLED().
> >>
> >> Signed-off-by: Masahiro Yamada 
> >
> > I applied the whole series to kbuild.git#kbuild.
> >
> 
> This series was applied by Andrew Morton last week.
> 
> I do not want to double it.  Could you drop it?

Andrew usually drops patches from his tree when they show up in
another maintainer tree.

Arnd

[PATCH 1/1] sound: Fix one compile error of seq_device.c

[fgao]

From: Gao Feng 

The gcc reports the following compile error on CentOS7.
include/linux/init.h:216:2: error: expected ',' or ';' before 'static'
  static exitcall_t __exitcall_##fn __exit_call = fn
  ^
include/linux/init.h:279:24: note: in expansion of macro '__exitcall'
 #define module_exit(x) __exitcall(x);
^
sound/core/seq/seq_device.c:315:1: note: in expansion of macro 'module_exit'
 module_exit(alsa_seq_device_exit)
 ^
make[3]: *** [sound/core/seq/seq_device.o] Error 1
make[2]: *** [sound/core/seq] Error 2
make[1]: *** [sound/core] Error 2
make: *** [sound] Error 2

Signed-off-by: Gao Feng 
---
 sound/core/seq/seq_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/core/seq/seq_device.c b/sound/core/seq/seq_device.c
index c4acf17..4e859e4 100644
--- a/sound/core/seq/seq_device.c
+++ b/sound/core/seq/seq_device.c
@@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
bus_unregister(_seq_bus_type);
 }
 
-subsys_initcall(alsa_seq_device_init)
-module_exit(alsa_seq_device_exit)
+subsys_initcall(alsa_seq_device_init);
+module_exit(alsa_seq_device_exit);
-- 
1.9.1

Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

[Arnd Bergmann]

On Tuesday, June 21, 2016 1:46:11 AM CEST th...@altera.com wrote:
> diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt 
> b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> index 72d82d6..dd10f2f 100644
> --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> @@ -17,9 +17,26 @@ Required properties:
>  Optional properties:
>  altr,emac-splitter: Should be the phandle to the emac splitter soft IP node 
> if
>   DWMAC controller is connected emac splitter.
> +phy-mode: The phy mode the ethernet operates in
> +altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
> +

Please use '-' instead of '_' in the property names.

Can you explain in the patch description why you can't reference
the converter using the normal "phy-handle" property and implement
the converter as a phy driver?

Arnd

Re: [PATCH v2 04/15] clk: sunxi-ng: Add fixed factor clock support

[Maxime Ripard]

Hi Stephen,

On Mon, Jun 20, 2016 at 06:15:37PM -0700, Stephen Boyd wrote:
> On 06/07, Maxime Ripard wrote:
> > +
> > +#include 
> > +
> > +#include "ccu_common.h"
> > +
> > +struct ccu_fixed_factor {
> > +   u16 div;
> > +   u16 mult;
> > +
> > +   struct ccu_common   common;
> 
> Does this use the common structure although we have no usage for
> the members of struct ccu_common except struct clk_hw? I suppose
> this is done so registering a bunch of clks is easy?

Yes, when we discussed this with Mike back at the ELC, he said that he
really liked the approach you had the qualcomm clocks where you have a
single array with all the clocks, so I tried to follow that as much as
possible.

Even though it doesn't really make much sense here, indeed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Lorenzo Pieralisi]

On Mon, Jun 20, 2016 at 12:12:24PM -0700, Duc Dang wrote:
> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
>  wrote:
> > Hi Duc,
> >
> > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
> >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
> >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
> >>>  wrote:
>  On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
> > From: Tomasz Nowicki 
> >
> > pci_generic_ecam_ops is used by default. Since there are platforms
> > which have non-compliant ECAM space we need to overwrite these
> > accessors prior to PCI buses enumeration. In order to do that
> > we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
> > we can use proper PCI config space accessors and bus_shift.
> >
> > pci_generic_ecam_ops is still used for platforms free from quirks.
> >
> > Signed-off-by: Tomasz Nowicki 
> > ---
> >  arch/arm64/kernel/pci.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > index 94cd43c..a891bda 100644
> > --- a/arch/arm64/kernel/pci.c
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> > *root)
> >   struct pci_config_window *cfg;
> >   struct resource cfgres;
> >   unsigned int bsz;
> > + struct pci_ecam_ops *ops;
> >
> >   /* Use address from _CBA if present, otherwise lookup MCFG */
> >   if (!root->mcfg_addr)
> > @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> > *root)
> >   return NULL;
> >   }
> >
> > - bsz = 1 << pci_generic_ecam_ops.bus_shift;
> > + ops = pci_mcfg_get_ops(root);
> > + bsz = 1 << ops->bus_shift;
> >   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
> >   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
> >   cfgres.flags = IORESOURCE_MEM;
> > - cfg = pci_ecam_create(>device->dev, , bus_res,
> > -   _generic_ecam_ops);
> > + cfg = pci_ecam_create(>device->dev, , bus_res, ops);
> 
>  Arnd pointed this out already, I think that's the only pending question
>  here.
> 
>  pci_ecam_create() maps ECAM space for config regions retrieved from
>  the MCFG, which are *supposed* to be ECAM compliant.
> 
>  Do we think that's *always* correct/safe regardless of the kind
>  of quirk we are currently fixing up ?
> 
>  Or we do think that configuration space regions should come from
>  a different resource declared in the ACPI namespace if the regions
>  are not MCFG/ECAM compliant (ie config space is not defined through
>  MCFG at all - possibly through a _CRS method for a vendor specific
>  _HID under the PNP0A03 node ?)
> >>>
> >>> Hi Lorenzo,
> >>>
> >>> For X-Gene: the ECAM space is used to access the configuration space
> >>> of PCIe devices, with additional help from controller register to
> >>> specify the bus, device and function number. Below is the RFC patch
> >>> that implements ECAM fixup for X-Gene PCIe controller on top of this
> >>> RFC ECAM quirk v3 for your and others reference.
> >>
> >> Yes, you have an additional resource in the PNP0A03 _CRS to describe
> >> your register that is a deliberate abuse of the ACPI standard in
> >> that the _CRS is meant to describe resources that are passed on
> >> to secondary buses
> >
> > A potential alternative came up in an off-list discussion: Would it be
> > better to hard code the information in the quirk workaround than look it
> > up from a repurposed ACPI resource?
> 
> Hi Chris, Lorenzo,
> 
> Thanks for looking into this.
> 
> Yes, I am open for this approach and I think it may work. I can +
> check the pci_config_window resource start address (cfg->res.start) to
> figure out the controller and then get the fixed controller register
> address or + using the domain number to identify the controller.

First thing to do is to remove config space entry from PNP0A03
_CRS, that's a FW bug.

You could use the {bus-range, domain} to get that register address,
anyway, that's not the main concern here.

Thanks,
Lorenzo

> Regards,
> Duc Dang.
> >
> > Supporting quirk workarounds for early, non-compliant hardware is
> > helpful and perhaps necessary for bootstrapping the ecosystem in a
> > timely manner. But we don't really want to provide an expandable or
> > reusable interface that would make it easy for new hardware to remain
> > non-compliant.
> >
> > Regards,
> > Cov
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> 

[PATCH 1/2] ACPI / EC: Cleanup boot EC code using acpi_ec_alloc()

[Lv Zheng]

Failure handling of the boot EC code is not tidy. This patch cleans
them up with acpi_ec_alloc().
This patch also changes acpi_ec_dsdt_probe(), always switches the boot EC
from the ECDT one to the DSDT one in this function.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   85 ++---
 1 file changed, 48 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 73c76d6..f63a43a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1348,13 +1348,9 @@ static void ec_remove_handlers(struct acpi_ec *ec)
}
 }
 
-static int acpi_ec_add(struct acpi_device *device)
+static struct acpi_ec *acpi_ec_alloc(void)
 {
-   struct acpi_ec *ec = NULL;
-   int ret;
-
-   strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
-   strcpy(acpi_device_class(device), ACPI_EC_CLASS);
+   struct acpi_ec *ec;
 
/* Check for boot EC */
if (boot_ec) {
@@ -1365,9 +1361,21 @@ static int acpi_ec_add(struct acpi_device *device)
first_ec = NULL;
} else {
ec = make_acpi_ec();
-   if (!ec)
-   return -ENOMEM;
}
+   return ec;
+}
+
+static int acpi_ec_add(struct acpi_device *device)
+{
+   struct acpi_ec *ec = NULL;
+   int ret;
+
+   strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
+   strcpy(acpi_device_class(device), ACPI_EC_CLASS);
+
+   ec = acpi_ec_alloc();
+   if (!ec)
+   return -ENOMEM;
if (ec_parse_device(device->handle, 0, ec, NULL) !=
AE_CTRL_TERMINATE) {
kfree(ec);
@@ -1454,27 +1462,31 @@ static const struct acpi_device_id ec_device_ids[] = {
 int __init acpi_ec_dsdt_probe(void)
 {
acpi_status status;
+   struct acpi_ec *ec;
+   int ret;
 
-   if (boot_ec)
-   return 0;
-
+   ec = acpi_ec_alloc();
+   if (!ec)
+   return -ENOMEM;
/*
 * Finding EC from DSDT if there is no ECDT EC available. When this
 * function is invoked, ACPI tables have been fully loaded, we can
 * walk namespace now.
 */
-   boot_ec = make_acpi_ec();
-   if (!boot_ec)
-   return -ENOMEM;
status = acpi_get_devices(ec_device_ids[0].id,
- ec_parse_device, boot_ec, NULL);
-   if (ACPI_FAILURE(status) || !boot_ec->handle)
-   return -ENODEV;
-   if (!ec_install_handlers(boot_ec)) {
-   first_ec = boot_ec;
-   return 0;
+ ec_parse_device, ec, NULL);
+   if (ACPI_FAILURE(status) || !ec->handle) {
+   ret = -ENODEV;
+   goto error;
}
-   return -EFAULT;
+   ret = ec_install_handlers(ec);
+
+error:
+   if (ret)
+   kfree(ec);
+   else
+   first_ec = boot_ec = ec;
+   return ret;
 }
 
 #if 0
@@ -1548,12 +1560,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = 
{
 
 int __init acpi_ec_ecdt_probe(void)
 {
-   int ret = 0;
+   int ret;
acpi_status status;
struct acpi_table_ecdt *ecdt_ptr;
+   struct acpi_ec *ec;
 
-   boot_ec = make_acpi_ec();
-   if (!boot_ec)
+   ec = acpi_ec_alloc();
+   if (!ec)
return -ENOMEM;
/*
 * Generate a boot ec context
@@ -1583,22 +1596,20 @@ int __init acpi_ec_ecdt_probe(void)
 * MSI MS-171F
 * https://bugzilla.kernel.org/show_bug.cgi?id=12461
 */
-   boot_ec->command_addr = ecdt_ptr->data.address;
-   boot_ec->data_addr = ecdt_ptr->control.address;
+   ec->command_addr = ecdt_ptr->data.address;
+   ec->data_addr = ecdt_ptr->control.address;
} else {
-   boot_ec->command_addr = ecdt_ptr->control.address;
-   boot_ec->data_addr = ecdt_ptr->data.address;
+   ec->command_addr = ecdt_ptr->control.address;
+   ec->data_addr = ecdt_ptr->data.address;
}
-   boot_ec->gpe = ecdt_ptr->gpe;
-   boot_ec->handle = ACPI_ROOT_OBJECT;
-   ret = ec_install_handlers(boot_ec);
-   if (!ret)
-   first_ec = boot_ec;
+   ec->gpe = ecdt_ptr->gpe;
+   ec->handle = ACPI_ROOT_OBJECT;
+   ret = ec_install_handlers(ec);
 error:
-   if (ret) {
-   kfree(boot_ec);
-   boot_ec = NULL;
-   }
+   if (ret)
+   kfree(ec);
+   else
+   first_ec = boot_ec = ec;
return ret;
 }
 
-- 
1.7.10

[PATCH 2/2] ACPI / EC: Remove wrong ECDT correction quirks

[Lv Zheng]

Our Windows probe result shows that EC._REG is evaluated after evaluating
all _INI/_STA control methods.

With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as
long as there is no EC opregion accesses in the MLC (module level code, AML
code out of any control methods) and in _INI/_STA, there is no need to make
sure that ECDT must be correct.

Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA
evaluations contain EC accesses while the ECDT setting is wrong.

>From the acpidump output posted on bug 9399, we can see that it is actually
a different issue. In this table, if EC._REG is not executed, EC accesses
will be done in a platform specific manner. As we've already ensured not to
execute EC._REG during the eary stage, we can remove the quirks for bug
9399.

>From the acpidump output posted on bug 12461, we can see that it still
needs the quirk. In this table, EC._REG flags a named object whose default
value is One, thus BAT1._STA surely should invoke EC accesses whatever we
invoke EC._REG or not. We have to keep the quirk for it before we can root
cause the issue.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index f63a43a..b1050a0 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1530,6 +1530,11 @@ static int ec_clear_on_resume(const struct dmi_system_id 
*id)
return 0;
 }
 
+/*
+ * Some ECDTs contain wrong register addresses.
+ * MSI MS-171F
+ * https://bugzilla.kernel.org/show_bug.cgi?id=12461
+ */
 static int ec_correct_ecdt(const struct dmi_system_id *id)
 {
pr_debug("Detected system needing ECDT address correction.\n");
@@ -1539,16 +1544,6 @@ static int ec_correct_ecdt(const struct dmi_system_id 
*id)
 
 static struct dmi_system_id ec_dmi_table[] __initdata = {
{
-   ec_correct_ecdt, "Asus L4R", {
-   DMI_MATCH(DMI_BIOS_VERSION, "1008.006"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),
-   DMI_MATCH(DMI_BOARD_NAME, "L4R") }, NULL},
-   {
-   ec_correct_ecdt, "Asus M6R", {
-   DMI_MATCH(DMI_BIOS_VERSION, "0207"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "M6R"),
-   DMI_MATCH(DMI_BOARD_NAME, "M6R") }, NULL},
-   {
ec_correct_ecdt, "MSI MS-171F", {
DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star"),
DMI_MATCH(DMI_PRODUCT_NAME, "MS-171F"),}, NULL},
@@ -1590,12 +1585,6 @@ int __init acpi_ec_ecdt_probe(void)
 
pr_info("EC description table is found, configuring boot EC\n");
if (EC_FLAGS_CORRECT_ECDT) {
-   /*
-* Asus L4R, Asus M6R
-* https://bugzilla.kernel.org/show_bug.cgi?id=9399
-* MSI MS-171F
-* https://bugzilla.kernel.org/show_bug.cgi?id=12461
-*/
ec->command_addr = ecdt_ptr->data.address;
ec->data_addr = ecdt_ptr->control.address;
} else {
-- 
1.7.10

Re: [PATCH v3 04/13] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

[Vladimir Davydov]

On Mon, Jun 20, 2016 at 04:43:34PM -0700, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone.  This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
> 
> Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
> allocations in a unit that divides both THREAD_SIZE and PAGE_SIZE on
> all architectures.  Keep it simple and use KiB.
> 
> Cc: Vladimir Davydov 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: linux...@kvack.org
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Vladimir Davydov 

RE: [Query] mwifiex: few observations to reduce number of endian conversions

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 17, 2016 6:42 PM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: Linux Kernel; Linux Next; WiFi Mailing List; Johannes Berg
> Subject: [Query] mwifiex: few observations to reduce number of endian
> conversions
> 
> Hi Amitkumar,
> 
> I have two observations:
> 
> 1. I have found that in the command response path for host command
> "HostCmd_CMD_802_11_EEPROM_ACCESS", a "0" value has been endian
> converted. It can only be a safe futuristic approach for any non-zero
> value there however! Otherwise, the endian conversion can be removed.
> 
> 2. For multiple Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS
> etc.) "cpu_to_leX"-converted values are saved to driver. So "leX_to_cpu"
> conversion is required too many times afterwards in driver.
> On the contrary, we can save the values to driver without any
> conversion, and only command buffer(s) are prepared with endian
> converted values. In this way we can gain some efficiency [code size /
> time] by reducing the number of endian conversion considerably.
> 

I agree with your observations. We'll prepare a cleanup patch to address this.

Regards,
Amitkumar

Re: Using irq-crossbar.c

[Marc Zyngier]

[been away for a while, catching up...]

On 16/06/16 13:39, Sebastian Frias wrote:
> Hi Marc,
> 
> On 06/14/2016 06:39 PM, Sebastian Frias wrote:
>> On 06/14/2016 06:37 PM, Sebastian Frias wrote:
>> Also, without seeing the code,
>> it is pretty difficult to make any meaningful comment...
>
> Base code is either 4.7rc1 or 4.4.
> The irq-crossbar code is not much different from TI, but you can find it 
> attached.

 Please post it separately (and inline), the email client I have here
 makes it hard to review attached patches.
>>>
>>> Ok, I'll post it in a separate email and inline.
>>>
>>
>> Here it goes:
>>
>>
> 
>  
> 
>> IRQCHIP_DECLARE(tangox_intc, "sigma,smp-irq-mux", tangox_of_irq_mux_init);
>>
>>
> 
> I have tested the code, and aside from the missing #interrupt-cells
> in the DT that you pointed out, it seems it is working (devices using
> IRQ appear functional), here's some log:
> 
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 1 (0x1) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 18 (0x12) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 18 (0x12) hwirq 1 (0x1)
> tangox_setup_irq_route(): route irq  1 (@ 0xf006f804) => irq 23
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 38 (0x26) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 19 (0x13) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 19 (0x13) hwirq 38 (0x26)
> tangox_setup_irq_route(): route irq 38 (@ 0xf006f898) => irq 22
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 67 (0x43) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 20 (0x14) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 20 (0x14) hwirq 67 (0x43)
> tangox_setup_irq_route(): route irq 67 (@ 0xf006f90c) => irq 21
> 
> Since irq-tango_v2.c is similar to irq-crossbar.c from TI (since it
> is based on it), I was wondering what is the policy or recommendation
> in such cases?
> Should I attempt to merge the code (mainly the way to set up the
> registers) on irq-crossbar.c or should we consider irq-tango_v2.c to
> live its own life?

If the HW is significantly different, I'd rather have a separate driver.
We can always share some things later on by having a small library of
"stuff".

> NOTE: IMHO, irq-crossbar.c could benefit from clearer names for some
> DT properties, because "max_irqs" and "max-crossbar-sources" are not
> straight forward names for "mux_outputs" and "mux_inputs"
> (respectively)

Maybe, but this ship has sailed a long time ago. This is an ABI now, and
it is not going to change unless proven to be broken. On the other hand,
you can name your own properties as you see fit.

> NOTE2: current irq-tango_v2.c code still has a 24 IRQ limitation
> since it is not using any API that would allow it to setup IRQ
> sharing.

Unless you limit your mux level interrupts only, I cannot see how you
could deal with cascaded interrupts. By the time you receive an edge,
the line will have dropped, and you won't be able to identify the source
interrupt.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] Staging: comedi: pcmuio: fix bare use of 'unsigned'

[Ravishankar Karkala Mallikarjunayya]

This fixes up a WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/pcmuio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/pcmuio.c 
b/drivers/staging/comedi/drivers/pcmuio.c
index 7ea8130..8ad64f2 100644
--- a/drivers/staging/comedi/drivers/pcmuio.c
+++ b/drivers/staging/comedi/drivers/pcmuio.c
@@ -307,7 +307,7 @@ static void pcmuio_stop_intr(struct comedi_device *dev,
 
 static void pcmuio_handle_intr_subdev(struct comedi_device *dev,
  struct comedi_subdevice *s,
- unsigned triggered)
+ unsigned int triggered)
 {
struct pcmuio_private *devpriv = dev->private;
int asic = pcmuio_subdevice_to_asic(s);
-- 
1.9.1

Re: [PATCH 2/3] iio: potentiometer: mcp4531: Add device tree binding documentation

[Peter Rosin]

On 2016-06-21 08:55, Florian Vaussard wrote:
> Add the device tree documentation for all the supported parts. Apart the
> compatible string and standard I2C binding, no other binding is currently
> needed.
> 
> Signed-off-by: Florian Vaussard 
> ---
>  .../bindings/iio/potentiometer/mcp4531.txt | 84 
> ++
>  1 file changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt 
> b/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> new file mode 100644
> index 000..b052299
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> @@ -0,0 +1,84 @@
> +* Microchip MCP453X/454X/455X/456X/463X/464X/465X/466X Digital Potentiometer
> +  driver
> +
> +The node for this driver must be a child node of a I2C controller, hence
> +all mandatory properties for your controller must be specified. See 
> directory:
> +
> +Documentation/devicetree/bindings/i2c
> +
> +for more details.
> +
> +Required properties:
> + - compatible:   Must be one of the following, depending on the
> + model:
> + "microchip,mcp4531-502"
> + "microchip,mcp4531-103"
> + "microchip,mcp4531-503"

*snip*

I'm not directly opposed, but I have used the following and DT booting
works like a charm here.

mcp4651-104@28 {
compatible = "mcp4651-104";
reg = <0x28>;
};

But, I suppose some DT documentation is not bad, and my understanding of
the device instantiation process and the i2c/dt interactions are not
complete, so my DT snippet might be an abomination? I'll leave the
decision if this is needed to someone with more experience on how other
drivers handle this.

Cheers,
Peter

答复: 答复: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[高峰]

OK.
It is good news that there is no real issue on upstream.

But it is bad news that my commit would not be accepted :)

Best Regards
Feng

-邮件原件-
发件人: Takashi Iwai [mailto:ti...@suse.de] 
发送时间: 2016年6月21日 18:05
收件人: 高峰 
抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; 
gfree.w...@gmail.com
主题: Re: 答复: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

On Tue, 21 Jun 2016 11:57:28 +0200,
高峰 wrote:
> 
> Oh, I get it.
> 
> I met the compile error when compile the kernel 3.10 on CentOS7 and fix it, 
> then I find the seq_device of upstream is same.
> So I thought it should be fixed.
> 
> OK. Let me compile the upstream codes on CentOS7 again.

Well, I see a potential problem even in the upstream, but it's only when 
CONFIG_LTO is set.  However, CONFIG_LTO isn't used any other places (or even 
set) in the upstream tree yet, so the issue must not happen there.

And yet, even if CONFIG_LTO is enabled, the first place to be fixed is rather 
in include/linux/init.h, not each code calling module_init() without a 
terminator semicolon.  There are lots of such codes in the tree, and calls of 
init/exit without semicolon are official ways.

Though, having semicolons looks nicer nowadays, so it'd make sense to add 
semicolons in the end.  If so, we may fix all of them in a shot by a script.


Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de]
> 发送时间: 2016年6月21日 17:54
> 收件人: 高峰 
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> 主题: Re: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 11:35:39 +0200,
> 高峰 wrote:
> > 
> > I have sent the new commit with the compile errors.
> > Is it ok now?
> > 
> > BTW, I think the compile error is caused by that "subsys_initcall" 
> > statement losts the semicolon. 
> 
> Does this happen with the latest upstream kernel code at all...?
> 
> 
> Takashi
> 
> > 
> > -邮件原件-
> > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > 发送时间: 2016年6月21日 17:20
> > 收件人: 高峰 
> > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> > linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> > 主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > 
> > On Tue, 21 Jun 2016 10:48:30 +0200,
> > 高峰 wrote:
> > > 
> > > The lastest CentOS7 platform, and the gcc version is gcc version
> > > 4.8.5
> > > 20150623 (Red Hat 4.8.5-4) (GCC).
> > > It could pass compilation after append the lost semicolon. 
> > > 
> > > from sound/core/seq/seq_device.c:39:
> > > include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
> > >   static exitcall_t __exitcall_##fn __exit_call = fn
> > >   ^
> > > include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
> > >  #define module_exit(x) __exitcall(x);
> > > ^
> > > sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> > > ‘module_exit’
> > >  module_exit(alsa_seq_device_exit)  ^
> > > make[3]: *** [sound/core/seq/seq_device.o] Error 1
> > > make[2]: *** [sound/core/seq] Error 2
> > > make[1]: *** [sound/core] Error 2
> > > make: *** [sound] Error 2
> > 
> > It's a RH specific issue.  The upstream code has a different definition of 
> > module_init(), thus no such an error would occur.
> > 
> > Note that I'm fine to apply the patch, it's a trivial change.
> > But you need to give the clear reason why to apply it.  In this case, it's 
> > no fault of the upstream code.  But if it would make someone's life a bit 
> > easier, it's OK to apply such a change.
> > 
> > That being said, please resubmit the patch with a more explanation.
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > 
> > > -邮件原件-
> > > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > > 发送时间: 2016年6月21日 16:45
> > > 收件人: f...@ikuai8.com
> > > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> > > org; gfree.w...@gmail.com
> > > 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > > 
> > > On Tue, 21 Jun 2016 10:34:25 +0200,  wrote:
> > > > 
> > > > From: Gao Feng 
> > > > 
> > > > Signed-off-by: Gao Feng 
> > > 
> > > What compile error did you get?
> > > 
> > > 
> > > Takashi
> > > 
> > > > ---
> > > >  sound/core/seq/seq_device.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/sound/core/seq/seq_device.c 
> > > > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > > > --- a/sound/core/seq/seq_device.c
> > > > +++ b/sound/core/seq/seq_device.c
> > > > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > > > bus_unregister(_seq_bus_type);
> > > >  }
> > > >  
> > > > -subsys_initcall(alsa_seq_device_init)
> > > > -module_exit(alsa_seq_device_exit)
> > > > +subsys_initcall(alsa_seq_device_init);
> > > > +module_exit(alsa_seq_device_exit);
> > > > --
> > > > 

Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

[kbuild test robot]

Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   net/ieee802154/nl-mac.c: In function 'llsec_parse_dev':
>> net/ieee802154/nl-mac.c:1003:5: error: 'struct ieee802154_llsec_device' has 
>> no member named 'hwaddr'
 dev->hwaddr = nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
^
   net/ieee802154/nl-mac.c: In function 'ieee802154_nl_fill_dev':
>> net/ieee802154/nl-mac.c:1069:55: error: 'const struct 
>> ieee802154_llsec_device' has no member named 'hwaddr'
 nla_put_hwaddr(msg, IEEE802154_ATTR_HW_ADDR, desc->hwaddr,
  ^
   net/ieee802154/nl-mac.c: In function 'llsec_iter_devkeys':
   net/ieee802154/nl-mac.c:1208:17: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'
dpos->hwaddr, kpos,
^

vim +1003 net/ieee802154/nl-mac.c

3e9c156e Phoebe Buckheister 2014-05-16   997dev->pan_id = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_PAN_ID]);
3e9c156e Phoebe Buckheister 2014-05-16   998dev->short_addr = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_SHORT_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16   999} else {
3e9c156e Phoebe Buckheister 2014-05-16  1000dev->short_addr = 
cpu_to_le16(IEEE802154_ADDR_UNDEF);
3e9c156e Phoebe Buckheister 2014-05-16  1001}
3e9c156e Phoebe Buckheister 2014-05-16  1002  
3e9c156e Phoebe Buckheister 2014-05-16 @1003dev->hwaddr = 
nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16  1004dev->frame_counter = 
nla_get_u32(info->attrs[IEEE802154_ATTR_LLSEC_FRAME_COUNTER]);
3e9c156e Phoebe Buckheister 2014-05-16  1005dev->seclevel_exempt = 
!!nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_OVERRIDE]);
3e9c156e Phoebe Buckheister 2014-05-16  1006dev->key_mode = 
nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_KEY_MODE]);
3e9c156e Phoebe Buckheister 2014-05-16  1007  
3e9c156e Phoebe Buckheister 2014-05-16  1008if (dev->key_mode >= 
__IEEE802154_LLSEC_DEVKEY_MAX)
3e9c156e Phoebe Buckheister 2014-05-16  1009return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1010  
3e9c156e Phoebe Buckheister 2014-05-16  1011return 0;
3e9c156e Phoebe Buckheister 2014-05-16  1012  }
3e9c156e Phoebe Buckheister 2014-05-16  1013  
3e9c156e Phoebe Buckheister 2014-05-16  1014  static int llsec_add_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1015  {
3e9c156e Phoebe Buckheister 2014-05-16  1016struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1017struct ieee802154_llsec_device 
desc;
3e9c156e Phoebe Buckheister 2014-05-16  1018  
3e9c156e Phoebe Buckheister 2014-05-16  1019if (llsec_parse_dev(info, 
))
3e9c156e Phoebe Buckheister 2014-05-16  1020return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1021  
3e9c156e Phoebe Buckheister 2014-05-16  1022return ops->llsec->add_dev(dev, 
);
3e9c156e Phoebe Buckheister 2014-05-16  1023  }
3e9c156e Phoebe Buckheister 2014-05-16  1024  
3e9c156e Phoebe Buckheister 2014-05-16  1025  int 
ieee802154_llsec_add_dev(struct sk_buff *skb, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1026  {
3e9c156e Phoebe Buckheister 2014-05-16  1027if ((info->nlhdr->nlmsg_flags & 
(NLM_F_CREATE | NLM_F_EXCL)) !=
3e9c156e Phoebe Buckheister 2014-05-16  1028(NLM_F_CREATE | NLM_F_EXCL))
3e9c156e Phoebe Buckheister 2014-05-16  1029return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1030  
3e9c156e Phoebe Buckheister 2014-05-16  1031return 
ieee802154_nl_llsec_change(skb, info, llsec_add_dev);
3e9c156e Phoebe Buckheister 2014-05-16  1032  }
3e9c156e Phoebe Buckheister 2014-05-16  1033  
3e9c156e Phoebe Buckheister 2014-05-16  1034  static int llsec_del_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1035  {
3e9c156e Phoebe Buckheister 2014-05-16  1036struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1037__le64 devaddr;
3e9c156e Phoebe Buckheister 2014-05-16  1038  
3e9c156e Phoebe Buckheister 2014-05-16  1039if 
(!info->attrs[IEEE802154_ATTR_HW_ADDR])
3e9c156e Phoebe Buckheister 2014-05-16  1040return -EINVAL;
3e9c156e Phoeb

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

[Leon Romanovsky]

On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/20 21:33, Leon Romanovsky wrote:
> >On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:
> >>This patch added the operation for cmd, and added some functions
> >>for initializing eq table and selecting cmd mode.
> >>
> >>Signed-off-by: Wei Hu 
> >>Signed-off-by: Nenglong Zhao 
> >>Signed-off-by: Lijun Ou 
> >>---
> >>PATCH v9/v8/v7/v6:
> >>- No change over the PATCH v5
> >>
> >>PATCH v5:
> >>- The initial patch which was redesigned based on the second patch
> >>   in PATCH v4
> >>---
> ><...>
> >
> >>+#define CMD_MAX_NUM32
> >>+
> >>+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> >>+{
> >>+   struct device *dev = _dev->pdev->dev;
> >>+
> >>+   mutex_init(_dev->cmd.hcr_mutex);
> >>+   sema_init(_dev->cmd.poll_sem, 1);
> >>+   hr_dev->cmd.use_events = 0;
> >>+   hr_dev->cmd.toggle = 1;
> >>+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;
> ><...>
> >
> >>+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
> >>+hr_cmd->token_mask <<= 1)
> >>+   ;
> >>+   --hr_cmd->token_mask;
> >It doesn't look that you dynamically change max_cmds supported.
> >Why do you need to calculate token_mask dynamically?
> Hi, Leon
> 
> 1. The four lines above are in the function named
> hns_roce_cmd_use_events.
>  and now this function is only called once in hns_roce_probe.
> 2. In hns_roce_cmd_use_events,
> we use these 4 lines to achieve the value of hr_cmd->token_mask
> according to hr_cmd->max_cmds dynamically,
> then we only define one marco for hr_cmd->max_cmds as below:
> 
>   #define CMD_MAX_NUM 32
> 
>And it looks more flexible.

It is called over engineering.
I would recommend to you to remove it.

We don't need over complicated code which is executed
once with need to maintain with zero benefit.

The other places need such simplification too.

> 
> Regards
> Wei Hu
> 
> 
> 


signature.asc
Description: Digital signature

[PATCH 00/27] Move LRU page reclaim from zones to nodes v7

[Mel Gorman]

The bulk of the updates are in response to review from Vlastimil Babka
and received a lot more testing than v6.

Changelog since v6
o Correct reclaim_idx when direct reclaiming for memcg
o Also account LRU pages per zone for compaction/reclaim
o Add page_pgdat helper with more efficient lookup
o Init pgdat LRU lock only once
o Slight optimisation to wake_all_kswapds
o Always wake kcompactd when kswapd is going to sleep
o Rebase to mmotm as of June 15th, 2016

Changelog since v5
o Rebase and adjust to changes

Changelog since v4
o Rebase on top of v3 of page allocator optimisation series

Changelog since v3
o Rebase on top of the page allocator optimisation series
o Remove RFC tag

This is the latest version of a series that moves LRUs from the zones to
the node that is based upon 4.6-rc3 plus the page allocator optimisation
series. Conceptually, this is simple but there are a lot of details. Some
of the broad motivations for this are;

1. The residency of a page partially depends on what zone the page was
   allocated from.  This is partially combatted by the fair zone allocation
   policy but that is a partial solution that introduces overhead in the
   page allocator paths.

2. Currently, reclaim on node 0 behaves slightly different to node 1. For
   example, direct reclaim scans in zonelist order and reclaims even if
   the zone is over the high watermark regardless of the age of pages
   in that LRU. Kswapd on the other hand starts reclaim on the highest
   unbalanced zone. A difference in distribution of file/anon pages due
   to when they were allocated results can result in a difference in 
   again. While the fair zone allocation policy mitigates some of the
   problems here, the page reclaim results on a multi-zone node will
   always be different to a single-zone node.
   it was scheduled on as a result.

3. kswapd and the page allocator scan zones in the opposite order to
   avoid interfering with each other but it's sensitive to timing.  This
   mitigates the page allocator using pages that were allocated very recently
   in the ideal case but it's sensitive to timing. When kswapd is allocating
   from lower zones then it's great but during the rebalancing of the highest
   zone, the page allocator and kswapd interfere with each other. It's worse
   if the highest zone is small and difficult to balance.

4. slab shrinkers are node-based which makes it harder to identify the exact
   relationship between slab reclaim and LRU reclaim.

The reason we have zone-based reclaim is that we used to have
large highmem zones in common configurations and it was necessary
to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
less of a concern as machines with lots of memory will (or should) use
64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
rare. Machines that do use highmem should have relatively low highmem:lowmem
ratios than we worried about in the past.

Conceptually, moving to node LRUs should be easier to understand. The
page allocator plays fewer tricks to game reclaim and reclaim behaves
similarly on all nodes. 

The series has been tested on a 16 core UMA machine and a 2-socket 48 core
NUMA machine. The UMA results are presented in most cases as the NUMA machine
behaved similarly.

pagealloc
-

This is a microbenchmark that shows the benefit of removing the fair zone
allocation policy. It was tested uip to order-4 but only orders 0 and 1 are
shown as the other orders were comparable.

   4.7.0-rc3  4.7.0-rc3
  mmotm-20160615  nodelru-v7r17
Min  total-odr0-1   485.00 (  0.00%)   462.00 (  4.74%)
Min  total-odr0-2   354.00 (  0.00%)   341.00 (  3.67%)
Min  total-odr0-4   285.00 (  0.00%)   277.00 (  2.81%)
Min  total-odr0-8   249.00 (  0.00%)   240.00 (  3.61%)
Min  total-odr0-16  230.00 (  0.00%)   224.00 (  2.61%)
Min  total-odr0-32  222.00 (  0.00%)   215.00 (  3.15%)
Min  total-odr0-64  216.00 (  0.00%)   210.00 (  2.78%)
Min  total-odr0-128 214.00 (  0.00%)   208.00 (  2.80%)
Min  total-odr0-256 248.00 (  0.00%)   233.00 (  6.05%)
Min  total-odr0-512 277.00 (  0.00%)   270.00 (  2.53%)
Min  total-odr0-1024294.00 (  0.00%)   284.00 (  3.40%)
Min  total-odr0-2048308.00 (  0.00%)   298.00 (  3.25%)
Min  total-odr0-4096318.00 (  0.00%)   307.00 (  3.46%)
Min  total-odr0-8192322.00 (  0.00%)   308.00 (  4.35%)
Min  total-odr0-16384   324.00 (  0.00%)   309.00 (  4.63%)
Min  total-odr1-1   729.00 (  0.00%)   686.00 (  5.90%)
Min  total-odr1-2   533.00 (  0.00%) 

Re: Using DT overlays for adding virtual hardware

[Jan Kiszka]

On 2016-06-21 13:45, Pantelis Antoniou wrote:
> Hi Jan,
> 
>> On Jun 21, 2016, at 14:43 , Jan Kiszka  wrote:
>>
>> On 2016-06-21 13:35, Pantelis Antoniou wrote:
>>> Hi Jan,
>>>
 On Jun 21, 2016, at 14:22 , Jan Kiszka  wrote:

 On 2016-06-21 12:24, Pantelis Antoniou wrote:
> Hi Jan,
>
>> On Jun 21, 2016, at 13:13 , Jan Kiszka  wrote:
>>
>> Hi Pantelis,
>>
>> coming back to this topic:
>>
>> On 2016-06-09 08:03, Jan Kiszka wrote:
>>> OK, trial and error, and some interesting insights: I've played with DT
>>> fragments and the overlay configfs patch of Pantelis [1] to have a
>>> convenient start. Interestingly, I wasn't able to load a fragment that
>>> followed the format specification for overlays ("Failed to resolve
>>> tree"). By chance, I got this one working:
>>>
>>> /dts-v1/;
>>> / {
>>> fragment {
>>> target-path = "/soc@01c0";
>>> __overlay__ {
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>
>>> vpci@0x200 {
>>> compatible = "pci-host-cam-generic";
>>> device_type = "pci";
>>> #address-cells = <3>;
>>> #size-cells = <2>;
>>> reg = <0 0x200 0 0x100>;
>>> ranges =
>>> <0x0200 0x00 0x1000 
>>> 0x00 0x1000 0x00 0x3000>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> It successfully makes a BananaPi kernel add a pci host with the
>>> specified config space and MMIO window.
>>>
>>> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
>>> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, 
>>> using [bus 00-ff]
>>> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
>>> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
>>> 0x0200-0x02ff] for [bus 00-ff]
>>> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus 
>>> :00
>>> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
>>> [   81.620814] pci_bus :00: root bus resource [mem 
>>> 0x1000-0x3fff]
>>> [   81.620851] PCI: bus0: Fast back to back transfers enabled
>>>
>>> So, no /plugin/ statement, no phandles resolution. This format even
>>> builds with the in-kernel dtc. Any explanations? Does the code make
>>> sense (at least it builds without warnings)?
>>>
>>> Now I need to back this with some code in Jailhouse.
>>
>> Meanwhile I got a virtual PCI device recognized by Linux when running
>> over Jailhouse. However, my hack above doesn't get me to proper
>> interrupt mapping yet. This is what I was trying with upstream dtc:
>>
>> /dts-v1/;
>> / {
>>  compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
>>
>>  fragment@0 {
>>  target-path = "/soc@01c0";
>>  __overlay__ {
>>  #address-cells = <2>;
>>  #size-cells = <2>;
>>
>>  vpci@200 {
>>  compatible = "pci-host-ecam-generic";
>>  device_type = "pci";
>>  bus-range = <0 0>;
>>  #address-cells = <3>;
>>  #size-cells = <2>;
>>  #interrupt-cells = <1>;
>>  interrupt-map-mask = <0 0 0 7>;
>>  interrupt-map = <0 0 0 1  0 0 0 123 4>,
>>  <0 0 0 2  0 0 0 124 4>,
>>  <0 0 0 3  0 0 0 125 4>,
>>  <0 0 0 4  0 0 0 126 4>;
>>  reg = <0 0x200 0 0x10>;
>>  ranges =
>>  <0x0200 0x00 0x1000 0x00 
>> 0x1000 0x00 0x3000>;
>>  };
>>  };
>>  };
>>
>>  gic: fragment@1 {
>>  target-path = "/soc@01c0/interrupt-controller@01c81000";
>>  __overlay__ {
>>  };
>>  };
>> };
>>
>
> ^ This is not going to work: You need the reference to the real gic not 
> the empty fragment
> here that has a target there.
>
> You need to compile with the correct dtc, and you also need to compile 
> the base dts
> with dtc too, using the -@ flag. You can hack around it by adding 
> something like
>

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

[Andrew F. Davis]

On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
> Hi Andrew,
> 
> This patch doesn't apply, please rebase onto recent LED tree.
> 
> On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
>> Some systems use 'gpio_led_register_device' to make an in-memory copy of
>> their LED device table so the original can be removed as .init.rodata.
>> When the LED subsystem is not enabled source in the led directory is not
>> built and so this function may be undefined. Fix this here.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>   include/linux/leds.h | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index d2b1306..a4a3da6 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -386,8 +386,16 @@ struct gpio_led_platform_data {
>>  unsigned long *delay_off);
> 
> Currently there is some stuff here, and in fact it has been for
> a long time.
> 
> Patch "[PATCH 12/12] leds: Only descend into leds directory when
> CONFIG_NEW_LEDS is set" also doesn't apply.
> What repository are you using?
> 

v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.

A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.

>>   };
>>
>> +#ifdef CONFIG_NEW_LEDS
>>   struct platform_device *gpio_led_register_device(
>>  int id, const struct gpio_led_platform_data *pdata);
>> +#else
>> +static inline struct platform_device *gpio_led_register_device(
>> +   int id, const struct gpio_led_platform_data *pdata)
>> +{
>> +   return 0;
>> +}
>> +#endif
>>
>>   enum cpu_led_event {
>>  CPU_LED_IDLE_START, /* CPU enters idle */
>>
> 
> 

Re: [PATCH] tracing: Fix oops caused by graph notrace filter

[kbuild test robot]

Hi,

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Chunyu-Hu/tracing-Fix-oops-caused-by-graph-notrace-filter/20160621-191210
config: i386-randconfig-a0-201625 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `wakeup_tracer_reset':
>> trace_sched_wakeup.c:(.text+0xc5282): undefined reference to 
>> `ftrace_graph_ignore_notrace'
   kernel/built-in.o: In function `__wakeup_tracer_init':
   trace_sched_wakeup.c:(.text+0xc547d): undefined reference to 
`ftrace_graph_ignore_notrace'

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


.config.gz
Description: Binary data

[PATCH v1 2/3] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds a per-device debugfile "drm_crc_control" that allows selecting a
source for frame checksums in each CRTC that supports them.

The checksums for each subsequent frame can be read from the per-CRTC
file "drm_crtc_N_crc".

The code is taken from the i915 driver and other drivers can now provide
frame CRCs by implementing the set_crc_source callback in
drm_crtc_funcs.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/drm_crtc.c |  28 ++-
 drivers/gpu/drm/drm_debugfs.c  | 506 -
 drivers/gpu/drm/drm_internal.h |  10 +
 include/drm/drmP.h |   5 +
 include/drm/drm_crtc.h |  72 ++
 5 files changed, 611 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7c862bd2f19..4dae42b122d9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -657,8 +657,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
   drm_num_crtcs(dev));
}
if (!crtc->name) {
-   drm_mode_object_unregister(dev, >base);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_unregister;
}
 
crtc->base.properties = >properties;
@@ -673,12 +673,30 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
 
+#ifdef CONFIG_DEBUG_FS
+   spin_lock_init(>crc.lock);
+   init_waitqueue_head(>crc.wq);
+   crtc->crc.debugfs_entries = kmalloc_array(DRM_MINOR_CNT,
+ sizeof(*crtc->crc.debugfs_entries),
+ GFP_KERNEL);
+
+   ret = drm_debugfs_crtc_add(crtc);
+   if (ret)
+   goto err_free_name;
+#endif
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, config->prop_active, 0);
drm_object_attach_property(>base, config->prop_mode_id, 
0);
}
 
return 0;
+
+err_free_name:
+   kfree(crtc->name);
+err_unregister:
+   drm_mode_object_unregister(dev, >base);
+   return ret;
 }
 EXPORT_SYMBOL(drm_crtc_init_with_planes);
 
@@ -699,6 +717,12 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 * the indices on the drm_crtc after us in the crtc_list.
 */
 
+#ifdef CONFIG_DEBUG_FS
+   drm_debugfs_crtc_remove(crtc);
+   kfree(crtc->crc.debugfs_entries);
+   kfree(crtc->crc.source);
+#endif
+
kfree(crtc->gamma_store);
crtc->gamma_store = NULL;
 
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index fa10cef2ba37..cdc8836bc22a 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -30,6 +30,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +129,259 @@ fail:
 }
 EXPORT_SYMBOL(drm_debugfs_create_files);
 
+static int
+drm_add_fake_info_node(struct drm_minor *minor,
+  struct dentry *ent,
+  const void *key)
+{
+   struct drm_info_node *node;
+
+   node = kmalloc(sizeof(*node), GFP_KERNEL);
+   if (node == NULL) {
+   debugfs_remove(ent);
+   return -ENOMEM;
+   }
+
+   node->minor = minor;
+   node->dent = ent;
+   node->info_ent = (void *) key;
+
+   mutex_lock(>debugfs_lock);
+   list_add(>list, >debugfs_list);
+   mutex_unlock(>debugfs_lock);
+
+   return 0;
+}
+
+static int crc_control_show(struct seq_file *m, void *data)
+{
+   struct drm_device *dev = m->private;
+   struct drm_crtc *crtc;
+
+   drm_for_each_crtc(crtc, dev)
+   seq_printf(m, "crtc %d %s\n", crtc->index,
+  crtc->crc.source ? crtc->crc.source : "none");
+
+   return 0;
+}
+
+static int crc_control_open(struct inode *inode, struct file *file)
+{
+   struct drm_device *dev = inode->i_private;
+
+   return single_open(file, crc_control_show, dev);
+}
+
+static int crc_control_update_crtc(struct drm_crtc *crtc, const char *source)
+{
+   struct drm_crtc_crc *crc = >crc;
+   struct drm_crtc_crc_entry *entries;
+   int ret;
+
+   if (!strcmp(source, "none"))
+   source = NULL;
+
+   if (!crc->source && !source)
+   return 0;
+
+   if (crc->source && source && !strcmp(crc->source, source))
+   return 0;
+
+   /* Forbid changing the source without going back to "none". */
+   if (crc->source && source)
+   return -EINVAL;
+
+   if (!crtc->funcs->set_crc_source)
+   return -ENOTSUPP;
+
+   if (source) {
+   entries = kcalloc(DRM_CRTC_CRC_ENTRIES_NR,
+ sizeof(crc->entries[0]),
+ GFP_KERNEL);
+

Re: linux-next: manual merge of the net-next tree with the arm-soc tree

[Arnd Bergmann]

On Tuesday, June 21, 2016 11:18:39 AM CEST Stephen Rothwell wrote:
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   arch/arm64/boot/dts/broadcom/ns2-svk.dts
>   arch/arm64/boot/dts/broadcom/ns2.dtsi
> 
> between commits:
> 
>   97b1504a30b3 ("arm64: dts: enable pinctrl for Broadcom NS2 SoC")
>   5dcc9c7618df ("arm64: dts: NS2: Add CCI-400 PMU support")
> 
> from the arm-soc tree and commit:
> 
>   5f1a067bfa0a ("dt: mdio-mux: Add mdio multiplexer driver node")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good to me, thanks!

I don't see a good way to resolve the conflict before the merge window,
but it's simple enough that we can just send it this way and let
Linus handle it.

Arnd

[PATCH 1/2] PCI: altera: check link status before retrain link

[Ley Foon Tan]

Checking for link up status before retrain link.

Note, moves altera_pcie_link_is_up() and its dependency functions
to top of file.

Signed-off-by: Ley Foon Tan 
---
 drivers/pci/host/pcie-altera.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index dbac6fb..78f77e1 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -81,9 +81,29 @@ struct tlp_rp_regpair_t {
u32 reg1;
 };
 
+static inline void cra_writel(struct altera_pcie *pcie, const u32 value,
+ const u32 reg)
+{
+   writel_relaxed(value, pcie->cra_base + reg);
+}
+
+static inline u32 cra_readl(struct altera_pcie *pcie, const u32 reg)
+{
+   return readl_relaxed(pcie->cra_base + reg);
+}
+
+static bool altera_pcie_link_is_up(struct altera_pcie *pcie)
+{
+   return !!((cra_readl(pcie, RP_LTSSM) & RP_LTSSM_MASK) == LTSSM_L0);
+}
+
 static void altera_pcie_retrain(struct pci_dev *dev)
 {
u16 linkcap, linkstat;
+   struct altera_pcie *pcie = dev->bus->sysdata;
+
+   if(!altera_pcie_link_is_up(pcie))
+   return;
 
/*
 * Set the retrain bit if the PCIe rootport support > 2.5GB/s, but
@@ -120,17 +140,6 @@ static bool altera_pcie_hide_rc_bar(struct pci_bus *bus, 
unsigned int  devfn,
return false;
 }
 
-static inline void cra_writel(struct altera_pcie *pcie, const u32 value,
- const u32 reg)
-{
-   writel_relaxed(value, pcie->cra_base + reg);
-}
-
-static inline u32 cra_readl(struct altera_pcie *pcie, const u32 reg)
-{
-   return readl_relaxed(pcie->cra_base + reg);
-}
-
 static void tlp_write_tx(struct altera_pcie *pcie,
 struct tlp_rp_regpair_t *tlp_rp_regdata)
 {
@@ -139,11 +148,6 @@ static void tlp_write_tx(struct altera_pcie *pcie,
cra_writel(pcie, tlp_rp_regdata->ctrl, RP_TX_CNTRL);
 }
 
-static bool altera_pcie_link_is_up(struct altera_pcie *pcie)
-{
-   return !!((cra_readl(pcie, RP_LTSSM) & RP_LTSSM_MASK) == LTSSM_L0);
-}
-
 static bool altera_pcie_valid_config(struct altera_pcie *pcie,
 struct pci_bus *bus, int dev)
 {
-- 
1.8.2.1

Re: [PATCH net-next 00/19] net: hns: fix some bugs in hns driver

[David Miller]

From: Yisen Zhuang 
Date: Tue, 21 Jun 2016 11:56:20 +0800

> This series includes some bugs fixed. All these patches needs to be
> applied after the patchset about ACPI support, so this series is 
> floated to net-next list.

Series applied, thanks.

Re: [PATCH] ARM: sun8i: Add Parrot Board DTS

[Chen-Yu Tsai]

On Tue, Jun 21, 2016 at 2:35 AM, Maxime Ripard
 wrote:
> On Tue, Jun 21, 2016 at 12:30:25AM +0800, Chen-Yu Tsai wrote:
>> >> >>> +_aldo1 {
>> >> >>> +   regulator-always-on;
>> >> >>> +   regulator-min-microvolt = <300>;
>> >> >>> +   regulator-max-microvolt = <300>;
>> >> >>> +   regulator-name = "aldo1";
>> >> >>
>> >> >> What is this for exactly? Would turning it off render the system 
>> >> >> inoperable?
>> >> >> How was it referenced in the fex file?
>> >> >>
>> >> >> If this is for WiFi I/O VCC, then you should specify it in mmc1 with
>> >> >> vqmmc-supply.
>> >> >>
>> >> >
>> >> > In the fex, aldo1 is one of the three power inputs for the WiFi (the
>> >> > others being dldo1 and dldo2) and in the schematics it is linked to
>> >> > both VCC-USB and VCC-IO-WIFI.
>> >> >
>> >> > I tried to turn it off and, indeed, the system becomes inoperable.
>> >> >
>> >> > I'll add vqmmc-supply in mmc1 with aldo1 regulator. However, I am
>> >> > wondering what to put in vmmc-supply for mmc1 since the WiFi module has
>> >> > three power inputs: dldo1, dldo2 and aldo1. In the fex, they are
>> >> > referenced as, respectively, module_power1, module_power2 and
>> >> > module_power3 and in the schematics dldo1 and dldo2 are named VCC-WIFI
>> >> > while aldo1 is used for VCC-IO-WIFI (if it can help in any way).
>> >> >
>> >> > VCC-WIFI is connected to pin VBAT of the Broadcom AP6212 WiFi chip.
>> >> > VCC-IO-WIFI is connected to pin VDDIO of the chip.
>> >>
>> >> VCC-IO-WIFI is vqmmc, and VCC-WIFI is vmmc.
>> >
>> > Isn't vmmc supposed to be always powered at 3.3v, and vqmmc the one
>> > used to drop to 1.8V with the UHS cards?
>>
>> For eMMC, vmmc and vqmmc correspond to the pins on the eMMC chip.
>> vmmc provides power to the internals, while vqmmc provides power to the
>> I/O buffers on both sides. With SD this is a bit less clear. IIUC the SD
>> card itself supplies I/O voltage, dropping it to 1.8V if necessary, from
>> VDD (vmmc). vqmmc only affects the host side, and whatever external pull-ups
>> that might exist.
>
> Ok.
>
>> > In which case, VCC-IO-WIFI is vmmc, and VCC-WIFI is just one of the
>> > wifi chip power rail, to be handled by a power sequence.
>>
>> For the WiFi chip, there is a separate IO-VCC rail, which is VCC-IO-WIFI.
>> This, from what I understand of the datasheet, is for I/O signaling, and
>> thus vqmmc. VCC-WIFI is what powers the chip, which is what vmmc is.
>
> Ok. but there's still the issue of the two regulators that needs to be
> kept in sync. Before, that, I'd rather stice to not tying them to the
> MMC bus, and putting a comment on top.

OK. Let's do that for now.

ChenYu

Re: [PATCH 04/27] [AARCH64] Add PTR_REG, PTR_LOG_SIZE, and PTR_SIZE. Use it in LDST_PCREL and LDST_GLOBAL.

[Yury Norov]

On Tue, Jun 21, 2016 at 09:54:47AM +0200, Andreas Schwab wrote:
> Yury Norov  writes:
> 
> > diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h
> > index 4cb028f..f2ea821 100644
> > --- a/sysdeps/aarch64/sysdep.h
> > +++ b/sysdeps/aarch64/sysdep.h
> > @@ -23,10 +23,16 @@
> >  
> >  #ifdef __LP64__
> >  #define AARCH64_R(NAME)R_AARCH64_ ## NAME
> > +#define PTR_REG(n) x##n
> > +#define PTR_LOG_SIZE   3
> >  #else
> >  #define AARCH64_R(NAME)R_AARCH64_P32_ ## NAME
> > +#define PTR_REG(n) w##n
> > +#define PTR_LOG_SIZE   2
> >  #endif
> >  
> > +#define PTR_SIZE   (1< > +
> >  #ifdef __ASSEMBLER__
> >  
> >  /* Syntactic details of assembler.  */
> > @@ -87,16 +93,18 @@
> >  # define L(name) .L##name
> >  #endif
> >  
> > -/* Load or store to/from a pc-relative EXPR into/from R, using T.  */
> > -#define LDST_PCREL(OP, R, T, EXPR)  \
> > -   adrpT, EXPR;\
> > -   OP  R, [T, #:lo12:EXPR];\
> > -
> > -/* Load or store to/from a got-relative EXPR into/from R, using T.  */
> > -#define LDST_GLOBAL(OP, R, T, EXPR) \
> > -   adrpT, :got:EXPR;   \
> > -   ldr T, [T, #:got_lo12:EXPR];\
> > -   OP  R, [T];
> > +/* Load or store to/from a pc-relative EXPR into/from R, using T.
> > +   Note R and T are register numbers and not register names.  */
> > +#define LDST_PCREL(OP, R, T, EXPR) \
> > +   adrpx##T, EXPR; \
> > +   OP  PTR_REG (R), [x##T, #:lo12:EXPR];   \
> > +
> > +/* Load or store to/from a got-relative EXPR into/from R, using T.
> > +   Note R and T are register numbers and not register names.  */
> > +#define LDST_GLOBAL(OP, R, T,  EXPR)   \
> > +   adrpx##T, :got:EXPR;\
> > +   ldr PTR_REG (T), [x##T, #:got_lo12:EXPR];   \
> > +   OP  x##R, [x##T];
> 
> I think this needs to be PTR_REG(x).
> 
> Andreas.

Hi Andreas,

Thanks a lot for review. I will handle your comments and send new
version soon, maybe tomorrow.

[PATCH 0/2] PCI: altera: fix link retrain

[Ley Foon Tan]

This 2 patches fix the issue before and after retrain link.

Ley Foon Tan (2):
  PCI: altera: check link status before retrain link
  PCI: altera: Polling for link up status after retrain the link

 drivers/pci/host/pcie-altera.c | 48 +++---
 1 file changed, 31 insertions(+), 17 deletions(-)

-- 
1.8.2.1

Re: [PATCH 1/1] HID: multitouch: enable palm rejection if device implements confidence usage

[Allen Hung]

Hi Benjamin,

On 01/04/2016 04:35 PM, Benjamin Tissoires wrote:
> Hi Allen,
> 
> On Mon, Dec 21, 2015 at 10:45 AM, Allen Hung  wrote:
>> On 12/18/2015 05:52 AM, Benjamin Tissoires wrote:
>>> On Thu, Nov 26, 2015 at 3:21 PM, Jiri Kosina  wrote:
 On Fri, 20 Nov 2015, Allen Hung wrote:

> The usage Confidence is mandary to Windows Precision Touchpad devices. The
> appearance of this usage is checked in hidinput_connect but the quirk
> MT_QUIRK_VALID_IS_CONFIDENCE is not applied to device accordingly.
> Apply this quirk and also remove quirk MT_QUIRK_ALWAYS_VALID to enable 
> palm
> rejection for the WIN 8 touchpad devices which have implemented usage
> Confidence in its input reports.
>
> Tested on Dell XPS 13 laptop.
>
> Signed-off-by: Allen Hung 
 Applied to for-4.5/multitouch. Thanks,

>>> Allen, looks like the Dell XPS13 2015 (or was it the 2014?) has
>>> problems with your patch:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1292583 (we backported
>>> this change in the Fedora kernel 4.2.7).
>>>
>>> Would you mind checking that this patch does not create regressions on
>>> older series of laptops?
>>>
>>> Thanks in advance.
>>>
>>> Cheers,
>>> Benjamin
>> Hi Benjamin,
>>
>> It looks like a XPS13 2014 but I can confirm this with my colleagues who are 
>> in charge of this product line. I don't mind checking this patch with more 
>> older series of laptops. I will do it and let you know the status. Should I 
>> also test the machines with Fedora 23, or just go with Ubuntu OS? The XPS 
>> machines are shipped with Ubuntu.
>> Btw, the issue reporter said she/he cannot reproduce the issue (posted on 
>> Dec. 18).
>>
> 
> [Sorry for the late answer, but you guessed the holiday season did not help 
> :)]
> 
> I think I'll just ask the reporter to confirm he can not reproduce and
> then close the downstream bug.
> Unless other people complains, I think we can just keep the current
> state and wait :)
> 
> Cheers,
> Benjamin
> 
My this patch 25a84db15b3f3a24d3ea7d2baf90693bcff34b0c (HID: multitouch: enable 
palm rejection if device implements confidence usage) brings side effect as
someone reported it on https://bugzilla.kernel.org/show_bug.cgi?id=112791
My fix is attached in the thread and please have a look at it and my reply in
comment #5 as the root cause.
Let me try to explain my fix here - the quirk MT_QUIRK_VALID_IS_CONFIDENCE 
is implemented in hid-multitouch and I see it was only applied to some
particular touchpad devices (see my list in the end) before my earlier patch
applies it to Windows 8 precision touchpad. I believe the quirk is working 
very well for the devices in list, and it must have some stories behind that
made the quirk designed in this way - simply dropped the reports with
[confidence = 0]. 
However, this quirk isn't working very properly for the Win8 precise touchpad.
I think when a touch is initially detected as finger then
later detected as a palm, the driver has to send the latter detections
to input/mt as calling input_mt_report_slot_state(input, MT_TOOL_FINGER, 
active=0). In order not to break the devices in list, I add a new quirk
MT_QUIRK_CONFIDENCE to do the work. Please provide your comments :)

Device list: 
MT_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M1968)   
MT_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M2256) 
MT_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M3266) 
MT_USB_DEVICE(USB_VENDOR_ID_ASUS, USB_DEVICE_ID_ASUS_T91MT)
MT_USB_DEVICE(USB_VENDOR_ID_ASUS, USB_DEVICE_ID_ASUSTEK_MULTITOUCH_YFO) 
MT_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_TOUCHSCREEN_MOSART) 
MT_USB_DEVICE(USB_VENDOR_ID_QUANTA, 
USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001) 
MT_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM, USB_DEVICE_ID_MTP_STM)

Regards,
Allen Hung

答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[高峰]

I have sent the new commit with the compile errors.
Is it ok now?

BTW, I think the compile error is caused by that "subsys_initcall" statement 
losts the semicolon. 

-邮件原件-
发件人: Takashi Iwai [mailto:ti...@suse.de] 
发送时间: 2016年6月21日 17:20
收件人: 高峰 
抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; 
gfree.w...@gmail.com
主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

On Tue, 21 Jun 2016 10:48:30 +0200,
高峰 wrote:
> 
> The lastest CentOS7 platform, and the gcc version is gcc version 4.8.5
> 20150623 (Red Hat 4.8.5-4) (GCC).
> It could pass compilation after append the lost semicolon. 
> 
> from sound/core/seq/seq_device.c:39:
> include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
>   static exitcall_t __exitcall_##fn __exit_call = fn
>   ^
> include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
>  #define module_exit(x) __exitcall(x);
> ^
> sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> ‘module_exit’
>  module_exit(alsa_seq_device_exit)
>  ^
> make[3]: *** [sound/core/seq/seq_device.o] Error 1
> make[2]: *** [sound/core/seq] Error 2
> make[1]: *** [sound/core] Error 2
> make: *** [sound] Error 2

It's a RH specific issue.  The upstream code has a different definition of 
module_init(), thus no such an error would occur.

Note that I'm fine to apply the patch, it's a trivial change.
But you need to give the clear reason why to apply it.  In this case, it's no 
fault of the upstream code.  But if it would make someone's life a bit easier, 
it's OK to apply such a change.

That being said, please resubmit the patch with a more explanation.


thanks,

Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de]
> 发送时间: 2016年6月21日 16:45
> 收件人: f...@ikuai8.com
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> org; gfree.w...@gmail.com
> 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 10:34:25 +0200,
>  wrote:
> > 
> > From: Gao Feng 
> > 
> > Signed-off-by: Gao Feng 
> 
> What compile error did you get?
> 
> 
> Takashi
> 
> > ---
> >  sound/core/seq/seq_device.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/sound/core/seq/seq_device.c 
> > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > --- a/sound/core/seq/seq_device.c
> > +++ b/sound/core/seq/seq_device.c
> > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > bus_unregister(_seq_bus_type);
> >  }
> >  
> > -subsys_initcall(alsa_seq_device_init)
> > -module_exit(alsa_seq_device_exit)
> > +subsys_initcall(alsa_seq_device_init);
> > +module_exit(alsa_seq_device_exit);
> > --
> > 1.9.1
> > 
> > 
> > 
> > 
> > 
> 
> 
> 

[PATCH] ARM: AM33xx: PRM: Remove wrongly defined RSTST offset for PER Domain

[Keerthy]

As per the TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
offset 0x4 is reserved for PRM_PER. Hence removing the wrongly
defined address offset.

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/prm33xx.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 2bc4ec5..66302c6 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -52,8 +52,6 @@
 /* PRM.PER_PRM register offsets */
 #define AM33XX_RM_PER_RSTCTRL_OFFSET   0x
 #define AM33XX_RM_PER_RSTCTRL  
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x)
-#define AM33XX_RM_PER_RSTST_OFFSET 0x0004
-#define AM33XX_RM_PER_RSTST
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004)
 #define AM33XX_PM_PER_PWRSTST_OFFSET   0x0008
 #define AM33XX_PM_PER_PWRSTST  
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008)
 #define AM33XX_PM_PER_PWRSTCTRL_OFFSET 0x000c
-- 
1.9.1

Re: [GIT PULL 00/10] perf/core improvements and fixes

[Paolo Bonzini]

On 21/06/2016 05:11, Brendan Gregg wrote:
>>> > > - Add stackcollapse.py script to help generating flame graphs (Paolo 
>>> > > Bonzini)
>> >
>> > I think this is already done by '-g folded'.  Please see:
>> >
>> >   http://www.brendangregg.com/blog/2016-04-30/linux-perf-folded.html
>> >
> Pretty much. Two similar solutions were developed around the same
> time. Although I have to use some awk to get "perf -g folded" in the
> exact right format, and stackcollapse-perf.py does that directly.

Yes, the idea for stackcollapse-perf.py was:

- to do everything directly and emit "the right" format for the
flamegraph tools.  This however is a very minimal output, and it's not
necessarily the best for perf in general.

- to provide an example of visiting callgraphs from the scripting
interface, since it's not really documented.  From the commit message:
"Add stackcollapse.py script as an example of parsing call chains, and
also of using optparse to access command line options".

Paolo

Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

[kbuild test robot]

Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   net/mac802154/llsec.c: In function 'llsec_dev_find_long':
>> net/mac802154/llsec.c:333:15: error: 'struct ieee802154_llsec_device' has no 
>> member named 'hwaddr'
  if (dev->dev.hwaddr == hwaddr)
  ^
   net/mac802154/llsec.c: In function 'llsec_lookup_dev':
   net/mac802154/llsec.c:799:16: error: 'struct ieee802154_llsec_device' has no 
member named 'hwaddr'
   if (dev->dev.hwaddr == devaddr.extended_addr)
   ^
   net/mac802154/llsec.c: In function 'mac802154_llsec_decrypt':
   net/mac802154/llsec.c:1037:21: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'
 dev_addr = dev->dev.hwaddr;
^

vim +333 net/mac802154/llsec.c

5d637d5a Phoebe Buckheister 2014-05-16  327  llsec_dev_find_long(struct 
mac802154_llsec *sec, __le64 hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  328  {
5d637d5a Phoebe Buckheister 2014-05-16  329 struct mac802154_llsec_device 
*dev;
5d637d5a Phoebe Buckheister 2014-05-16  330 u64 key = 
llsec_dev_hash_long(hwaddr);
5d637d5a Phoebe Buckheister 2014-05-16  331  
5d637d5a Phoebe Buckheister 2014-05-16  332 
hash_for_each_possible_rcu(sec->devices_hw, dev, bucket_hw, key) {
5d637d5a Phoebe Buckheister 2014-05-16 @333 if (dev->dev.hwaddr == 
hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  334 return dev;
5d637d5a Phoebe Buckheister 2014-05-16  335 }
5d637d5a Phoebe Buckheister 2014-05-16  336  

:: The code at line 333 was first introduced by commit
:: 5d637d5aabd85132bd85779677d8acb708e0ed90 mac802154: add llsec structures 
and mutators

:: TO: Phoebe Buckheister <phoebe.buckheis...@itwm.fraunhofer.de>
:: 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: Binary data

Re: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Mika Westerberg]

On Mon, Jun 20, 2016 at 12:38:58PM +0100, Adam Thomson wrote:
> For device nodes in both DT and ACPI, it possible to have named
> child nodes which contain properties (an existing example being
> gpio-leds). This adds a function to find a named child node for
> a device which can be used by drivers for property retrieval.
> 
> For DT data node name matching, of_node_cmp() and similar functions
> are made available outside of CONFIG_OF block so the new function
> can reference these for DT and non-DT builds.
> 
> For ACPI data node name matching, a helper function is also added
> which returns false if CONFIG_ACPI is not set, otherwise it
> performs a string comparison on the data node name. This avoids
> using the acpi_data_node struct for non CONFIG_ACPI builds,
> which would otherwise cause a build failure.
> 
> Signed-off-by: Adam Thomson 
> Tested-by: Sathyanarayana Nujella 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v3:
>  - Move of_*_cmp() functions in of.h outside of CONFIG_OF block so they are
>available for non-DT builds
>  - In device_get_named_child_node(), use of_node_cmp() helper macro instead of
>strcasecmp() (node names not alway case insensitive, depending on 
> platform).
> 
> Changes in v2:
>  - Rebase to v4.7-rc1
> 
>  drivers/base/property.c  | 28 
>  include/acpi/acpi_bus.h  |  7 +++
>  include/linux/acpi.h |  6 ++
>  include/linux/of.h   | 14 +++---
>  include/linux/property.h |  3 +++
>  5 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f38c21d..43a36d6 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -888,6 +888,34 @@ struct fwnode_handle *device_get_next_child_node(struct 
> device *dev,
>  EXPORT_SYMBOL_GPL(device_get_next_child_node);
> 
>  /**
> + * device_get_named_child_node - Return first matching named child node 
> handle
> + * @dev: Device to find the named child node for.
> + * @childname: String to match child node name against.
> + */
> +struct fwnode_handle *device_get_named_child_node(struct device *dev,
> +   const char *childname)
> +{
> + struct fwnode_handle *child;
> +
> + /*
> +  * Find first matching named child node of this device.
> +  * For ACPI this will be a data only sub-node.
> +  */
> + device_for_each_child_node(dev, child) {
> + if (is_of_node(child)) {
> + if (!of_node_cmp(to_of_node(child)->name, childname))
> + return child;
> + } else if (is_acpi_data_node(child)) {
> + if (acpi_data_node_match(child, childname))
> + return child;
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(device_get_named_child_node);
> +
> +/**
>   * fwnode_handle_put - Drop reference to a device node
>   * @fwnode: Pointer to the device node to drop the reference to.
>   *
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 788c6c3..993bdd0 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -420,6 +420,13 @@ static inline struct acpi_data_node 
> *to_acpi_data_node(struct fwnode_handle *fwn
>   container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return is_acpi_data_node(fwnode) ?
> + (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
> +}

Looks fine to me.

One question - is it expected that matching ACPI data nodes is always
case insensitive?

Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

[Josh Boyer]

On Sun, Jun 19, 2016 at 10:52 AM, Thorsten Leemhuis
 wrote:
> Description:BUG: unable to handle kernel NULL pointer dereference […] 
> qla24xx_process_response_queue+0x49/0x4b0 [qla2xxx]
> Report: https://bugzilla.kernel.org/show_bug.cgi?id=120201
> Latest status:  n/a
> Date rep/stat:  2016-06-14 / n/a
> Notes:  poked bugzilla, a bit unsure how to proceed

We have two bug reports against 4.5.5 - 4.5.7 of this as well.  So
whatever commit caused this in 4.7 seems to have been pulled into the
4.5.y stable tree.  I suspect it is in the 4.6.y stable tree as well,
but we don't have that pushed out yet.

https://bugzilla.redhat.com/show_bug.cgi?id=1348342
https://bugzilla.redhat.com/show_bug.cgi?id=1346753

josh

Re: [PATCH 03/27] Add dynamic ILP32 AARCH64 relocations to elf.h

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> From: Andrew Pinski 
> 
> elf/elf.h (R_AARCH64_P32_ABS32, R_AARCH64_P32_COPY,
> R_AARCH64_P32_GLOB_DAT, R_AARCH64_P32_JUMP_SLOT,
> R_AARCH64_P32_RELATIVE, R_AARCH64_P32_TLS_DTPMOD,
> R_AARCH64_P32_TLS_DTPREL, R_AARCH64_P32_TLS_TPREL,
> R_AARCH64_P32_TLSDESC, R_AARCH64_P32_IRELATIVE): Define.
> 
> [AARCH64] Use ELFW and ElfW macros instead of ELF64 and Elf64 names.
> 
> * sysdeps/aarch64/dl-machine.h
> (elf_machine_runtime_setup): Use ElfW(Addr).
> (elf_machine_rela): Use ELFW(R_TYPE).
> (elf_machine_lazy_rel): Likewise.
> 
> [AARCH64] Introduce AARCH64_R so we can reuse the reloc code between ILP32 
> and LP64.
> 
> * sysdeps/aarch64/sysdep.h (AARCH64_R): Define.
> * sysdeps/aarch64/dl-irel.h: Include sysdep.h
> (elf_irela): Use reloc names based on AARCH64_R.
> * sysdeps/aarch64/dl-machine.h: Include sysdep.h
> (elf_machine_type_class): Use reloc names based on AARCH64_R.
> (elf_machine_rela): Likewise.
> (elf_machine_lazy_rel): Likewise.

The patch subject appears to have no relation to its contents.  Any patch 
submission should have a unified ChangeLog stanza, not three stanzas like 
here; if there are logically separate pieces, submit them separately.

> diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h
> index 594ab0b..4cb028f 100644
> --- a/sysdeps/aarch64/sysdep.h
> +++ b/sysdeps/aarch64/sysdep.h
> @@ -21,6 +21,12 @@
>  
>  #include 
>  
> +#ifdef __LP64__
> +#define AARCH64_R(NAME)  R_AARCH64_ ## NAME
> +#else
> +#define AARCH64_R(NAME)  R_AARCH64_P32_ ## NAME
> +#endif

glibc uses "# " indentation for nested preprocessor directives.  Check for 
and fix this issue throughout the patch series.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 10/27] [AARCH64] Detect ILP32 in configure scripts.

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> diff --git a/sysdeps/aarch64/preconfigure b/sysdeps/aarch64/preconfigure
> index d9bd1f8..4bcd8e3 100644
> --- a/sysdeps/aarch64/preconfigure
> +++ b/sysdeps/aarch64/preconfigure
> @@ -1,6 +1,15 @@
>  case "$machine" in
>  aarch64*)
>   base_machine=aarch64
> - machine=aarch64
> + case "$CC $CFLAGS $CPPFLAGS " in
> + *" -mabi=ilp32 "*) aarch64_config_abi=ilp32 ;;
> + *" -mabi=lp64 "*) aarch64_config_abi=lp64 ;;
> + *) aarch64_config_abi=default ;;

My comments in 
 still apply: 
test how the compiler behaves instead.

> +if test $aarch64_config_abi = ilp32; then
> +  arch_minimum_kernel=3.19.0

My comments in 
 still apply: 
use 10.0.0 until the corresponding kernel support is in, then change to 
the actual kernel version with the support.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] ipmi: set si_trydefaults=0 for ARM64

[Tony Camuso]

On 06/20/2016 04:57 PM, Corey Minyard wrote:

On 06/20/2016 01:26 PM, Tony Camuso wrote:

Port I/O space does not exist in ARM64 and is not mapped. Attempts to
access it on ARM systems cause stack traces and worse.


At this point, I think it is best to just completely pull out all concept
of "default addresses" in the IPMI driver.  The defaults were disabled
by default in 3.16, this is as good an impetus as any to just get rid
of them.

If you want, you can do a patch, or I can pull them out if you would
prefer that.


I'll give it a go. Should have something later today.

Regards,
Tony




Thanks,

-corey


Signed-off-by: Tony Camuso 
---
  drivers/char/ipmi/ipmi_si_intf.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 615abbf..85dcc86 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -3841,6 +3841,11 @@ static int init_ipmi_si(void)
  spmi_find_bmc();
  #endif
  +#ifdef CONFIG_ARM64
+/* Don't touch port io space */
+si_trydefaults = 0;
+#endif
+
  #ifdef CONFIG_PARISC
  register_parisc_driver(_parisc_driver);
  parisc_registered = true;

Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

[kbuild test robot]

Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   net/ieee802154/nl-mac.c: In function 'llsec_parse_dev':
>> net/ieee802154/nl-mac.c:1003:5: error: 'struct ieee802154_llsec_device' has 
>> no member named 'hwaddr'; did you mean 'short_addr'?
 dev->hwaddr = nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
^~
   net/ieee802154/nl-mac.c: In function 'ieee802154_nl_fill_dev':
>> net/ieee802154/nl-mac.c:1069:55: error: 'const struct 
>> ieee802154_llsec_device' has no member named 'hwaddr'; did you mean 
>> 'short_addr'?
 nla_put_hwaddr(msg, IEEE802154_ATTR_HW_ADDR, desc->hwaddr,
  ^~
   net/ieee802154/nl-mac.c: In function 'llsec_iter_devkeys':
   net/ieee802154/nl-mac.c:1208:17: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'; did you mean 'short_addr'?
dpos->hwaddr, kpos,
^~

vim +1003 net/ieee802154/nl-mac.c

3e9c156e Phoebe Buckheister 2014-05-16   997dev->pan_id = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_PAN_ID]);
3e9c156e Phoebe Buckheister 2014-05-16   998dev->short_addr = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_SHORT_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16   999} else {
3e9c156e Phoebe Buckheister 2014-05-16  1000dev->short_addr = 
cpu_to_le16(IEEE802154_ADDR_UNDEF);
3e9c156e Phoebe Buckheister 2014-05-16  1001}
3e9c156e Phoebe Buckheister 2014-05-16  1002  
3e9c156e Phoebe Buckheister 2014-05-16 @1003dev->hwaddr = 
nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16  1004dev->frame_counter = 
nla_get_u32(info->attrs[IEEE802154_ATTR_LLSEC_FRAME_COUNTER]);
3e9c156e Phoebe Buckheister 2014-05-16  1005dev->seclevel_exempt = 
!!nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_OVERRIDE]);
3e9c156e Phoebe Buckheister 2014-05-16  1006dev->key_mode = 
nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_KEY_MODE]);
3e9c156e Phoebe Buckheister 2014-05-16  1007  
3e9c156e Phoebe Buckheister 2014-05-16  1008if (dev->key_mode >= 
__IEEE802154_LLSEC_DEVKEY_MAX)
3e9c156e Phoebe Buckheister 2014-05-16  1009return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1010  
3e9c156e Phoebe Buckheister 2014-05-16  1011return 0;
3e9c156e Phoebe Buckheister 2014-05-16  1012  }
3e9c156e Phoebe Buckheister 2014-05-16  1013  
3e9c156e Phoebe Buckheister 2014-05-16  1014  static int llsec_add_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1015  {
3e9c156e Phoebe Buckheister 2014-05-16  1016struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1017struct ieee802154_llsec_device 
desc;
3e9c156e Phoebe Buckheister 2014-05-16  1018  
3e9c156e Phoebe Buckheister 2014-05-16  1019if (llsec_parse_dev(info, 
))
3e9c156e Phoebe Buckheister 2014-05-16  1020return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1021  
3e9c156e Phoebe Buckheister 2014-05-16  1022return ops->llsec->add_dev(dev, 
);
3e9c156e Phoebe Buckheister 2014-05-16  1023  }
3e9c156e Phoebe Buckheister 2014-05-16  1024  
3e9c156e Phoebe Buckheister 2014-05-16  1025  int 
ieee802154_llsec_add_dev(struct sk_buff *skb, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1026  {
3e9c156e Phoebe Buckheister 2014-05-16  1027if ((info->nlhdr->nlmsg_flags & 
(NLM_F_CREATE | NLM_F_EXCL)) !=
3e9c156e Phoebe Buckheister 2014-05-16  1028(NLM_F_CREATE | NLM_F_EXCL))
3e9c156e Phoebe Buckheister 2014-05-16  1029return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1030  
3e9c156e Phoebe Buckheister 2014-05-16  1031return 
ieee802154_nl_llsec_change(skb, info, llsec_add_dev);
3e9c156e Phoebe Buckheister 2014-05-16  1032  }
3e9c156e Phoebe Buckheister 2014-05-16  1033  
3e9c156e Phoebe Buckheister 2014-05-16  1034  static int llsec_del_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1035  {
3e9c156e Phoebe Buckheister 2014-05-16  1036struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1037__le64 devaddr;
3e9c156e Phoebe Buckheister 2014-05-16  1038  
3e9c156e Phoebe Buckheister 2014-05-16  1039if 
(!info->attrs[I

Re: [PATCH] irqchip: fix the config HISILICON_IRQ_MBIGEN dependency error.

[Jiancheng Xue]

On 2016/6/21 19:30, Jiancheng Xue wrote:
> Hi Marc，
> 
> On 2016/6/21 18:36, Marc Zyngier wrote:
>> On 21/06/16 10:26, Jiancheng Xue wrote:
>>> This patch fixes the compiling error caused when
>>> config HISILICON_IRQ_MBIGEN is selected but
>>> PCI_MSI is not seleted.
>>>
>>> Signed-off-by: Jiancheng Xue 
>>> ---
>>>  drivers/irqchip/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index fa33c50..23dcf3e 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -110,7 +110,7 @@ config DW_APB_ICTL
>>>  config HISILICON_IRQ_MBIGEN
>>> bool
>>> select ARM_GIC_V3
>>> -   select ARM_GIC_V3_ITS
>>> +   select ARM_GIC_V3_ITS if PCI_MSI
>>> select GENERIC_MSI_IRQ_DOMAIN
>>
>> How can this be correct? The MBIGEN uses platform MSI (not PCI) and
>> relies on the ITS (it doesn't work without it). It seems that you're
>> papering over another issue.
>>
> Sorry. I am not familiar with this part. But I encountered errors when
> I compiled. I think there may be some problems about dependency.
> 
> In this Kconfig file
> 
> config ARM_GIC_V3_ITS
> bool
> select PCI_MSI_IRQ_DOMAIN
> 
> config HISILICON_IRQ_MBIGEN
>   bool
>   select ARM_GIC_V3
>   select ARM_GIC_V3_ITS
>   select GENERIC_MSI_IRQ_DOMAIN
> 
> In the file drivers/pci/Kconfig
> 
> config PCI_MSI_IRQ_DOMAIN
> bool
> depends on PCI_MSI
> select GENERIC_MSI_IRQ_DOMAIN
> 
> We can see if the HISILICON_IRQ_MBIGEN is selected, the ARM_GIC_V3_ITS and
> PCI_MSI_IRQ_DOMAIN will be selected. But PCI_MSI_IRQ_DOMAIN depends on
> PCI_MSI. If PCI_MSI is not selected, it will cause a compiling error like this
> "drivers/irqchip/irq-gic-v3-its-pci-msi.c:52:12: error: implicit declaration 
> of function 'pci_msi_vec_count' [-Werror=implicit-function-declaration]
>   msi = max(pci_msi_vec_count(pdev), 0);"
> 
> I found many other options which need ARM_GIC_V3_ITS or PCI_MSI_IRQ_DOMAIN
> were configured like below:
> select ARM_GIC_V3_ITS if PCI_MSI
> or
> select GENERIC_MSI_IRQ_DOMAIN if PCI_MSI
> 

This patch is really not correct. It will cause new problems.

In drivers/irqchip/Makefile

obj-$(CONFIG_ARM_GIC_V3_ITS)+= irq-gic-v3-its.o 
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o

if CONFIG_ARM_GIC_V3_ITS is selected, irq-gic-v3-its-pci-msi.c will be 
compiled. But it depends on config PCI_MSI.

if irq-gic-v3-its-pci-msi.c is not relied on by irq-gic-v3-its.c, maybe it 
should be controlled by another config
item instead of CONFIG_ARM_GIC_V3_ITS. Otherwise, CONFIG_ARM_GIC_V3_ITS should 
depend on PCI_MSI.

> Regards,
> Jiancheng
> 
> 
> 

[PATCHv3] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage and puts the wilink chip into wspi mode.

Signed-off-by: Eyal Reizer 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle, which achieves the same hardware purpose.
update device tree bindings docucmentation accordingly

 .../bindings/net/wireless/ti,wlcore,spi.txt|  47 ++--
 drivers/net/wireless/ti/wlcore/spi.c   | 124 +
 2 files changed, 145 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..35467cf 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +32,15 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
  {
-   wl1271@1 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
clock-xtal;
@@ -34,3 +50,20 @@ Examples:
vwlan-supply = <_fixed>;
};
 };
+
+For wl18xx family:
+  {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   vwlan-supply = <_en_reg>;
+   spi-max-frequency = <4800>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..bd1253d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+   struct spi_device *spi = to_spi_device(glue->dev);
u8 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >> 
> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> when they say OTG. Usually they just mean "a method for swapping between
> >> host and peripheral roles, but we really don't want all the extra cost
> >> of the OTG specification".
> >> 
> >
> > That's what I thought before, but the request from the Marketing guy is
> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> > see the SoC reference manual say "it supports HNP and SRP"?
> >
> > If there is no request, who else wants to implement so complicated FSM
> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> 
> I stand corrected :-)
> 
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
> 

You mean chipidea or dwc3? I have more comments below.

> >> > For the real use case, some Carplay platforms need it.
> >> 
> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> specification which is not OTG-compliant.
> >> 
> >
> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> > states to finish role swap.
> 
> What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

> 
> > Notice, it needs to swap role without disconnect cable.
> 
> right, I can swap role without changing cable, but that's not OTG. The
> mechanism for that, AFAICT, is not HNP. I don't know details about
> CarPlay because the spec isn't public, but my understanding is that
> CarPlay doesn't rely on anything from OTG spec.

Since it is non-public, I can't say much. Some flows of its role-swap
refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification. 

But OTG FSM is not the only way, the platform which can do role-swap
without disconnection can support it too.

> 
> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> >> > index f4fc0aa..1d74fb8 100644
> >> >> > --- a/include/linux/usb/gadget.h
> >> >> > +++ b/include/linux/usb/gadget.h
> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >> >   * @in_epnum: last used in ep number
> >> >> >   * @mA: last set mA value
> >> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
> >> >> > core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > It may not be a real separate OTG controller. It can be a hardware part
> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
> >> > vbus
> >> > ,id and other signals which are used for role swap.
> >> 
> >> That's already solved. EXTCON solved that years back and OMAP has been
> >> using EXTCON to program its UTMI mailbox.
> >> 
> >
> > No, that's not the same thing, it does not include the swap role.
> 
> Read your original comment:
> 
> "handle vbus, id and other signals which are *used for* role swap"
> 
> You didn't include role swap in your original comment. Semantics aside...
> 
> > Consider the use case the host driver is at host/ and udc driver is
> > at gadget/udc, how to finish to role swap?
> 
> ... why does the source code placement matter? And what do you mean by
> "finish role swap"?
> 

Well, it depends on your driver design, do you want the host driver's
API is still be called when current role is peripheral? One typical
problem you can refer below:

commit 11c011a5e777c83819078a18672543f04482b3ec
Author: Srinivas Kandagatla 
Date:   Thu May 19 11:12:56 2016 +0100

usb: echi-hcd: Add ehci_setup check before echi_shutdown



In some cases, the USB code (gadget/hcd->start/stop) needs to be called
during the role swap. For example, if you have mux driver, you may
need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
how can we do that?

-- 

Best Regards,
Peter Chen

Re: [PATCH 03/10] proc, oom_adj: extract oom_score_adj setting into a helper

[Hillf Danton]

> 
> From: Michal Hocko 
> 
> Currently we have two proc interfaces to set oom_score_adj. The legacy
> /proc//oom_adj and /proc//oom_score_adj which both have their
> specific handlers. Big part of the logic is duplicated so extract the
> common code into __set_oom_adj helper. Legacy knob still expects some
> details slightly different so make sure those are handled same way - e.g.
> the legacy mode ignores oom_score_adj_min and it warns about the usage.
> 
> This patch shouldn't introduce any functional changes.
> 
> Acked-by: Oleg Nesterov 
> Signed-off-by: Michal Hocko 
> ---
>  fs/proc/base.c | 94 
> +++---
>  1 file changed, 43 insertions(+), 51 deletions(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 968d5ea06e62..a6a8fbdd5a1b 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1037,7 +1037,47 @@ static ssize_t oom_adj_read(struct file *file, char 
> __user *buf, size_t count,
>   return simple_read_from_buffer(buf, count, ppos, buffer, len);
>  }
> 
> -static DEFINE_MUTEX(oom_adj_mutex);
> +static int __set_oom_adj(struct file *file, int oom_adj, bool legacy)
> +{
> + static DEFINE_MUTEX(oom_adj_mutex);

Writers are not excluded for readers!
Is this a hot path?

> + struct task_struct *task;
> + int err = 0;
> +
> + task = get_proc_task(file_inode(file));
> + if (!task)
> + return -ESRCH;
> +
> + mutex_lock(_adj_mutex);
> + if (legacy) {
> + if (oom_adj < task->signal->oom_score_adj &&
> + !capable(CAP_SYS_RESOURCE)) {
> + err = -EACCES;
> + goto err_unlock;
> + }
> + /*
> +  * /proc/pid/oom_adj is provided for legacy purposes, ask users 
> to use
> +  * /proc/pid/oom_score_adj instead.
> +  */
> + pr_warn_once("%s (%d): /proc/%d/oom_adj is deprecated, please 
> use /proc/%d/oom_score_adj instead.\n",
> +   current->comm, task_pid_nr(current), 
> task_pid_nr(task),
> +   task_pid_nr(task));
> + } else {
> + if ((short)oom_adj < task->signal->oom_score_adj_min &&
> + !capable(CAP_SYS_RESOURCE)) {
> + err = -EACCES;
> + goto err_unlock;
> + }
> + }
> +
> + task->signal->oom_score_adj = oom_adj;
> + if (!legacy && has_capability_noaudit(current, CAP_SYS_RESOURCE))
> + task->signal->oom_score_adj_min = (short)oom_adj;
> + trace_oom_score_adj_update(task);
> +err_unlock:
> + mutex_unlock(_adj_mutex);
> + put_task_struct(task);
> + return err;
> +}
> 
>  /*
>   * /proc/pid/oom_adj exists solely for backwards compatibility with previous
> @@ -1052,7 +1092,6 @@ static DEFINE_MUTEX(oom_adj_mutex);
>  static ssize_t oom_adj_write(struct file *file, const char __user *buf,
>size_t count, loff_t *ppos)
>  {
> - struct task_struct *task;
>   char buffer[PROC_NUMBUF];
>   int oom_adj;
>   int err;
> @@ -1074,12 +1113,6 @@ static ssize_t oom_adj_write(struct file *file, const 
> char __user *buf,
>   goto out;
>   }
> 
> - task = get_proc_task(file_inode(file));
> - if (!task) {
> - err = -ESRCH;
> - goto out;
> - }
> -
>   /*
>* Scale /proc/pid/oom_score_adj appropriately ensuring that a maximum
>* value is always attainable.
> @@ -1089,26 +1122,7 @@ static ssize_t oom_adj_write(struct file *file, const 
> char __user *buf,
>   else
>   oom_adj = (oom_adj * OOM_SCORE_ADJ_MAX) / -OOM_DISABLE;
> 
> - mutex_lock(_adj_mutex);
> - if (oom_adj < task->signal->oom_score_adj &&
> - !capable(CAP_SYS_RESOURCE)) {
> - err = -EACCES;
> - goto err_unlock;
> - }
> -
> - /*
> -  * /proc/pid/oom_adj is provided for legacy purposes, ask users to use
> -  * /proc/pid/oom_score_adj instead.
> -  */
> - pr_warn_once("%s (%d): /proc/%d/oom_adj is deprecated, please use 
> /proc/%d/oom_score_adj instead.\n",
> -   current->comm, task_pid_nr(current), task_pid_nr(task),
> -   task_pid_nr(task));
> -
> - task->signal->oom_score_adj = oom_adj;
> - trace_oom_score_adj_update(task);
> -err_unlock:
> - mutex_unlock(_adj_mutex);
> - put_task_struct(task);
> + err = __set_oom_adj(file, oom_adj, true);
>  out:
>   return err < 0 ? err : count;
>  }
> @@ -1138,7 +1152,6 @@ static ssize_t oom_score_adj_read(struct file *file, 
> char __user *buf,
>  static ssize_t oom_score_adj_write(struct file *file, const char __user *buf,
>   size_t count, loff_t *ppos)
>  {
> - struct task_struct *task;
>   char buffer[PROC_NUMBUF];
>   int oom_score_adj;
>   int err;
> @@ 

Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

Hi Heiko,

On 2016/6/21 17:05, Heiko Stübner wrote:

Hi Frank,

Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang:

On 2016/6/20 12:56, Guenter Roeck wrote:

On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang 

wrote:

Turns out my problem was one of terminology. Using "suspend" and
"resume" to me suggested the common use of suspend and resume
functions. That is not the case here. After mentally replacing
"suspend" with "power_off" and "resume" with "power_on", you are
right, no problem exists. Sorry for the noise.

Maybe it would be useful to replace "resume" with "power_on" and
"suspend" with "power_off" in the function and variable names to
reduce confusion and misunderstandings.

Thanks,
Guenter

Well, it does have a bits confusion, however, the phy-port always just
goes
to suspend and resume mode (Not power off and power on) in a fact. So
must
it be renamed?

Other phy drivers name the functions _power_off and _power_on and
avoid the confusion. The callbacks are named .power_off and .power_on,
which gives a clear indication of its intended purpose. Other drivers
implementing suspend/resume (such as the omap usb phy driver) tie
those functions not into the power_off/power_on callbacks, but into
the driver's suspend/resume callbacks. At least the omap driver has
separate power management functions.

Do the functions _have_ to be renamed ? Surely not. But, if the
functions are really suspend/resume functions and not
power_off/power_on functions, maybe they should tie to the
suspend/resume functions and not register themselves as
power_off/power_on functions ?

As Guenter mentioned above,  I doped out two solutions, one is that keep
current process but renaming *_resume/*_suspend to
*_power_on/*_power_off;

in a way, naming stuff "power_off", "power_on" actually matches. For one, the
phy-block goes from unusable to usable by usb-devices and also will power-on a
phy-supply regulator (often named vcc_host* on Rockchip boards) from the phy-
core.


another is that do not assign power_on/power_off
functions for phy_ops at phy creating time, then, shorten
_SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port
suspend/resume mechanism depend on _sm_work_ completely.

Which in turn would mean that we would always depend on a fully controllable
phy block. Right now it seems, rk3036, rk3228, rk3368 (probably forgot some)
have the same type of phy, but with at least the unplug-detection missing.
In its current form the driver can very well support those (later on) by
simply working statically (only acting on phy_power callbacks and not going to
suspend on its own).

Also having the work running in 10-second intervall seems wasteful.


So which is the better way from your view? or would you like to give
other unique perceptions please?

As obvious from the above, I would prefer just renaming the functions :-)

Heiko



Got it, thanks for your comments. I am going to correct and send out a 
new version later today, so sorry for trouble you to sign 'Reviewed-by' 
again if no any other issues.



BR.
Frank

Warning when compiling DTB on X-Gene platform with dtc 1.4.1-g53bf130b

[Duc Dang]

Hi Rob,

I got warning on unit_address_vs_reg similar to this
https://lkml.org/lkml/2016/3/7/43 when using v4.7-rc2 dtc to build dtb
for X-Gene Mustang:

dhdang@xgene-next=>./scripts/dtc/dtc -O dtb -R 16 -o mustang.dtb
arch/arm64/boot/dts/apm/apm-mustang.dts
  Warning (unit_address_vs_reg): Node /soc/reboot@1714 has a unit
name, but no reg property
  Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
  Warning (unit_address_vs_reg): Node /gpio-keys/button@1 has a unit
name, but no reg property

There are nodes that I cannot change the node-name due to backward
compatible with old firmware reason (/soc/reboot@1714 as an
example). Is there any other way to avoid the warning?

Regards,
Duc Dang.

Re: cross compilers [was build failure of sorts]

[Vineet Gupta]

On Tuesday 21 June 2016 01:13 PM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 05:29:28AM +, Vineet Gupta wrote:
>> > On Saturday 18 June 2016 03:47 PM, Peter Zijlstra wrote:
>>> > > As you can see, arc doesn't even build upstream binutils :/
>>> > > (binutils-2_26-branch as of today).
>> > 
>> > Hmm - we are still in fight w.r.t. upstreaming gcc fully (ARCv2 gcc 
>> > support)
>> > although ARCompact has been there for some time. binutils upstream should 
>> > work -
>> > I'll check why the buildall stuff fails.
> I can run that build again and send you the resulting log files in
> private.

Thx for the off-list log. The issue is gdb not yet upstream. So it seems we will
have to wait for things on upstreaming to settle down before I can formally 
update
segher's scripts to support ARC.

-Vineet

Re: [RFC PATCH 2/2] xfs: map KM_MAYFAIL to __GFP_RETRY_HARD

[Vlastimil Babka]

On 06/21/2016 06:22 AM, Johannes Weiner wrote:

I think whether the best-effort behavior should be opt-in or opt-out,
or how fine-grained the latency/success control over the allocator
should be is a different topic. I'd prefer defaulting to reliability
and annotating low-latency requirements, but I can see TRY_HARD work
too. It just shouldn't imply MAY_FAIL.


It is always hard to change the default behavior without breaking
anything. Up to now we had opt-in and as you can see there are not that
many users who really wanted to have higher reliability. I guess this is
because they just do not care and didn't see too many failures. The
opt-out has also a disadvantage that we would need to provide a flag
to tell to try less hard and all we have is NORETRY and that is way too
easy. So to me it sounds like the opt-in fits better with the current
usage.


For costly allocations, the presence of __GFP_NORETRY is exactly the
same as the absence of __GFP_REPEAT. So if we made __GFP_REPEAT the
default (and deleted the flag), the opt-outs would use __GFP_NORETRY
to restore their original behavior.


Just FYI, this argument distorts my idea how to get rid of hacky checks 
for GFP_TRANSHUGE and PF_KTHREAD (patches 05 and 06 in [1]), where I 
observed the mentioned no difference between __GFP_NORETRY presence and 
__GFP_REPEAT absence, and made use of it. Without __GFP_REPEAT I'd have 
two options for khugepaged and madvise(MADV_HUGEPAGE) allocations. 
Either pass __GFP_NORETRY and make them fail more, or don't and then 
they become much more disruptive (if the default becomes best-effort, 
i.e. what __GFP_REPEAT used to do).


[1] http://thread.gmane.org/gmane.linux.kernel.mm/152313


As for changing the default - remember that we currently warn about
allocation failures as if they were bugs, unless they are explicitely
allocated with the __GFP_NOWARN flag. We can assume that the current
__GFP_NOWARN sites are 1) commonly failing but 2) prefer to fall back
rather than incurring latency (otherwise they would have added the
__GFP_REPEAT flag). These sites would be a good list of candidates to
annotate with __GFP_NORETRY. If we made __GFP_REPEAT then the default,
the sites that would then try harder are the same sites that would now
emit page allocation failure warnings. These are rare, and the only
times I have seen them is under enough load that latency is shot to
hell anyway. So I'm not really convinced by the regression argument.

But that would *actually* clean up the flags, not make them even more
confusing:

Allocations that can't ever handle failure would use __GFP_NOFAIL.

Callers like XFS would use __GFP_MAYFAIL specifically to disable the
implicit __GFP_NOFAIL of !costly allocations.

Callers that would prefer falling back over killing and looping would
use __GFP_NORETRY.

Wouldn't that cover all usecases and be much more intuitive, both in
the default behavior as well as in the names of the flags?

[RFC PATCH] irqdomain: Fix disposal of mappings for interrupt hierarchies

[Jon Hunter]

The function irq_create_of_mapping() is used to create an interrupt
mapping. However, depending on whether the irqdomain, to which the
interrupt belongs, is part of a hierarchy, determines whether the
mapping is created via calling irq_domain_alloc_irqs() or
irq_create_mapping().

To dispose of the interrupt mapping, drivers call irq_dispose_mapping().
However, this function does not check to see if the irqdomain is part
of a hierarchy or not and simply assumes that it was mapped via calling
irq_create_mapping() so calls irq_domain_disassociate() to unmap the
interrupt.

Fix this by checking to see if the irqdomain is part of a hierarchy and
if so call irq_domain_free_irqs() to free/unmap the interrupt.

Signed-off-by: Jon Hunter 
---

Please note that I have not observed issues with this, but something
that did not make sense to me from looking at the code.

 kernel/irq/irqdomain.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index caa6a63d26f0..5d89d724a02a 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -680,8 +680,12 @@ void irq_dispose_mapping(unsigned int virq)
if (WARN_ON(domain == NULL))
return;
 
-   irq_domain_disassociate(domain, virq);
-   irq_free_desc(virq);
+   if (irq_domain_is_hierarchy(domain)) {
+   irq_domain_free_irqs(virq, 1);
+   } else {
+   irq_domain_disassociate(domain, virq);
+   irq_free_desc(virq);
+   }
 }
 EXPORT_SYMBOL_GPL(irq_dispose_mapping);
 
-- 
2.1.4

RE: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

[Zheng, Lv]

Hi, Mika

> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Subject: Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC
> support triggers dead lock in dynamic table loading
> 
> On Tue, Jun 21, 2016 at 12:34:15PM +0800, Lv Zheng wrote:
> > The new MLC approach invokes MLC per-table basis. But the dynamic
> loading
> > support of this is incorrect because of the lock order:
> >  acpi_ns_evaluate
> >acpi_ex_enter_intperter
> >  acpi_ns_load_table (triggered by Load opcode)
> >acpi_ns_exec_module_code_list
> >  acpi_ex_enter_intperter
> > The regression is introduced by the following commit:
> >   Commit: 2785ce8d0da1cac9d8f78615e116cf929e9a9123
> >   ACPICA Commit: 071eff738c59eda1792ac24b3b688b61691d7e7c
> >   Subject: ACPICA: Add per-table execution of module-level code
> > This patch fixes this regression by unlocking the interpreter lock before
> > invoking MLC. However the unlocking is done to the
> acpi_ns_load_table(), in
> > which, the interpreter lock should be locked by acpi_ns_parse_table()
> but
> > wasn't. Reported by Mika Westerberg. Fixed by Lv Zheng.
> >
> > Fixes: 2785ce8d0da1 ("ACPICA: Add per-table execution of module-level
> code")
> > Cc: Mika Westerberg 
> > Reported-by: Mika Westerberg 
> 
> Now builds fine and fixes the hang, thanks :)
> 
> Tested-by: Mika Westerberg 
[Lv Zheng] 
Great! :)
I'll leave the SOB correction for Rafael in order not to bother others by 
re-sending an update.

Thanks and best regards
-Lv

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Honghui Zhang]

On Tue, 2016-06-21 at 11:41 +0200, Joerg Roedel wrote:
> On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Add the dtsi node of iommu and smi for mt2701.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 51 
> > +++
> >  1 file changed, 51 insertions(+)
> 
> Applied the series, except this last patch. It didn't apply cleanly and
> I was not sure how to correctly fix that. Can you please resubmit the
> patch based on my arm/mediatek branch once I pushed it?
> 

I will rebase this one later after your push.
Thanks.

> Thanks,
> 
>   Joerg
> 

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

[Netanel Belgazal]

On 06/21/2016 01:43 AM, Francois Romieu wrote:
> Netanel Belgazal  :
> [...]
>>> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h 
>>> b/drivers/net/ethernet/amazon/ena/ena_com.h
>>> new file mode 100644
>>> index 000..e49ba43
>>> --- /dev/null
>>> [...]
>>> +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg 
>>> *intr_reg,
>>> +  u32 rx_delay_interval,
>>> +  u32 tx_delay_interval,
>>> +  bool unmask)
>>> +{
>>> +   intr_reg->intr_control = 0;
>>> +   intr_reg->intr_control |= rx_delay_interval &
>>> +   ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>> +
>>> +   intr_reg->intr_control |=
>>> +   (tx_delay_interval << ENA_ETH_IO_INTR_REG_TX_INTR_DELAY_SHIFT)
>>> +   & ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>>   ^^ TX ?
>>>
>>> Extra: you should not return NETDEV_TX_BUSY in the xmit handler while
>>> queueing is still enabled. Please drop packet and return NETDEV_TX_OK.
>> Ack.
>>
>> Thanks for your review.
> Ack/nack regarding use of ..._RX_INTR_DELAY_MASK with ..._TX_INTR_DELAY_SHIFT 
> ?
You are right, it should have been TX_INTR_DELAY_SHIFT.
I'll fix that.

Re: [PATCH v3 03/13] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

[Matt Fleming]

On Mon, 20 Jun, at 04:43:33PM, Andy Lutomirski wrote:
> kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in
> init_mm.pgd were to be cleared, callers would need to ensure that
> the pgd entry hadn't been propagated to any other pgd.
> 
> Its only caller was efi_cleanup_page_tables(), and that, in turn,
> was unused, so just delete both functions.  This leaves a couple of
> other helpers unused, so delete them, too.
> 
> Cc: Matt Fleming 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/efi.h   |  1 -
>  arch/x86/include/asm/pgtable_types.h |  2 --
>  arch/x86/mm/pageattr.c   | 28 
>  arch/x86/platform/efi/efi.c  |  2 --
>  arch/x86/platform/efi/efi_32.c   |  3 ---
>  arch/x86/platform/efi/efi_64.c   |  5 -
>  6 files changed, 41 deletions(-)

Looks fine.

Reviewed-by: Matt Fleming 

RE: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Opensource [Adam Thomson]]

On 20 June 2016 12:39, Adam Thomson wrote:

> For device nodes in both DT and ACPI, it possible to have named
> child nodes which contain properties (an existing example being
> gpio-leds). This adds a function to find a named child node for
> a device which can be used by drivers for property retrieval.
> 
> For DT data node name matching, of_node_cmp() and similar functions
> are made available outside of CONFIG_OF block so the new function
> can reference these for DT and non-DT builds.
> 
> For ACPI data node name matching, a helper function is also added
> which returns false if CONFIG_ACPI is not set, otherwise it
> performs a string comparison on the data node name. This avoids
> using the acpi_data_node struct for non CONFIG_ACPI builds,
> which would otherwise cause a build failure.
> 
> Signed-off-by: Adam Thomson 
> Tested-by: Sathyanarayana Nujella 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v3:
>  - Move of_*_cmp() functions in of.h outside of CONFIG_OF block so they are
>available for non-DT builds
>  - In device_get_named_child_node(), use of_node_cmp() helper macro instead of
>strcasecmp() (node names not alway case insensitive, depending on 
> platform).
> 
> Changes in v2:
>  - Rebase to v4.7-rc1
> 
>  drivers/base/property.c  | 28 
>  include/acpi/acpi_bus.h  |  7 +++
>  include/linux/acpi.h |  6 ++
>  include/linux/of.h   | 14 +++---
>  include/linux/property.h |  3 +++
>  5 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f38c21d..43a36d6 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -888,6 +888,34 @@ struct fwnode_handle *device_get_next_child_node(struct
> device *dev,
>  EXPORT_SYMBOL_GPL(device_get_next_child_node);
> 
>  /**
> + * device_get_named_child_node - Return first matching named child node 
> handle
> + * @dev: Device to find the named child node for.
> + * @childname: String to match child node name against.
> + */
> +struct fwnode_handle *device_get_named_child_node(struct device *dev,
> +   const char *childname)
> +{
> + struct fwnode_handle *child;
> +
> + /*
> +  * Find first matching named child node of this device.
> +  * For ACPI this will be a data only sub-node.
> +  */
> + device_for_each_child_node(dev, child) {
> + if (is_of_node(child)) {
> + if (!of_node_cmp(to_of_node(child)->name, childname))
> + return child;
> + } else if (is_acpi_data_node(child)) {
> + if (acpi_data_node_match(child, childname))
> + return child;
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(device_get_named_child_node);
> +
> +/**
>   * fwnode_handle_put - Drop reference to a device node
>   * @fwnode: Pointer to the device node to drop the reference to.
>   *
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 788c6c3..993bdd0 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -420,6 +420,13 @@ static inline struct acpi_data_node
> *to_acpi_data_node(struct fwnode_handle *fwn
>   container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return is_acpi_data_node(fwnode) ?
> + (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
> +}
> +
>  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
> *adev)
>  {
>   return >fwnode;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 288fac5..03039c4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -568,6 +568,12 @@ static inline struct acpi_data_node
> *to_acpi_data_node(struct fwnode_handle *fwn
>   return NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return false;
> +}
> +
>  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
> *adev)
>  {
>   return NULL;
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 74eb28c..310e32f 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -238,13 +238,6 @@ static inline unsigned long of_read_ulong(const __be32
> *cell, int size)
>  #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>  #endif
> 
> -/* Default string compare functions, Allow arch asm/prom.h to override */
> -#if !defined(of_compat_cmp)
> -#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
> -#define of_prop_cmp(s1, s2)  strcmp((s1), (s2))
> -#define of_node_cmp(s1, s2)  strcasecmp((s1), (s2))
> 

Re: [PATCH] regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()

[Keerthy]

On Tuesday 21 June 2016 12:29 PM, Axel Lin wrote:

No need to pass _nlr to LP873X_REGULATOR(), use ARRAY_SIZE to calculate it.


Looks good to me.

Acked-by: Keerthy 



Signed-off-by: Axel Lin 
---
  drivers/regulator/lp873x-regulator.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/lp873x-regulator.c 
b/drivers/regulator/lp873x-regulator.c
index b4ffd11..e504b91 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -20,7 +20,7 @@
  #include 

  #define LP873X_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, _er, _em, \
-_delay, _lr, _nlr, _cr)\
+_delay, _lr, _cr)  \
[_id] = {   \
.desc = {   \
.name   = _name,\
@@ -37,7 +37,7 @@
.enable_mask= _em,  \
.ramp_delay = _delay,   \
.linear_ranges  = _lr,  \
-   .n_linear_ranges= _nlr, \
+   .n_linear_ranges= ARRAY_SIZE(_lr),  \
},  \
.ctrl2_reg = _cr,   \
}
@@ -175,22 +175,20 @@ static const struct lp873x_regulator regulators[] = {
 256, LP873X_REG_BUCK0_VOUT,
 LP873X_BUCK0_VOUT_BUCK0_VSET, LP873X_REG_BUCK0_CTRL_1,
 LP873X_BUCK0_CTRL_1_BUCK0_EN, 1,
-buck0_buck1_ranges, 4, LP873X_REG_BUCK0_CTRL_2),
+buck0_buck1_ranges, LP873X_REG_BUCK0_CTRL_2),
LP873X_REGULATOR("BUCK1", LP873X_BUCK_1, "buck1", lp873x_buck01_ops,
 256, LP873X_REG_BUCK1_VOUT,
 LP873X_BUCK1_VOUT_BUCK1_VSET, LP873X_REG_BUCK1_CTRL_1,
 LP873X_BUCK1_CTRL_1_BUCK1_EN, 1,
-buck0_buck1_ranges, 4, LP873X_REG_BUCK1_CTRL_2),
+buck0_buck1_ranges, LP873X_REG_BUCK1_CTRL_2),
LP873X_REGULATOR("LDO0", LP873X_LDO_0, "ldo0", lp873x_ldo01_ops, 26,
 LP873X_REG_LDO0_VOUT, LP873X_LDO0_VOUT_LDO0_VSET,
 LP873X_REG_LDO0_CTRL,
-LP873X_LDO0_CTRL_LDO0_EN, 0, ldo0_ldo1_ranges, 1,
-0xFF),
+LP873X_LDO0_CTRL_LDO0_EN, 0, ldo0_ldo1_ranges, 0xFF),
LP873X_REGULATOR("LDO1", LP873X_LDO_1, "ldo1", lp873x_ldo01_ops, 26,
 LP873X_REG_LDO1_VOUT, LP873X_LDO1_VOUT_LDO1_VSET,
 LP873X_REG_LDO1_CTRL,
-LP873X_LDO1_CTRL_LDO1_EN, 0, ldo0_ldo1_ranges, 1,
-0xFF),
+LP873X_LDO1_CTRL_LDO1_EN, 0, ldo0_ldo1_ranges, 0xFF),
  };

  static int lp873x_regulator_probe(struct platform_device *pdev)

[[PATCH v2] 09/11] irqchip/s3c24xx: fixup IO accessors for big endian

[Ben Dooks]

Instead of using the __raw accesors, use the _relaxed versions
to deal with any issues due to endian-ness of the CPU.

Signed-off-by: Ben Dooks 

---
CC: Thomas Gleixner  (maintainer:IRQCHIP DRIVERS)
CC: Jason Cooper  (maintainer:IRQCHIP DRIVERS)
CC: Marc Zyngier  (maintainer:IRQCHIP DRIVERS)
CC: linux-kernel@vger.kernel.org (open list:IRQCHIP DRIVERS)
CC: linux-arm-ker...@lists.infradead.org
---
 drivers/irqchip/irq-s3c24xx.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 5dc5a76..c25ce5a 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -92,9 +92,9 @@ static void s3c_irq_mask(struct irq_data *data)
unsigned long mask;
unsigned int irqno;
 
-   mask = __raw_readl(intc->reg_mask);
+   mask = readl_relaxed(intc->reg_mask);
mask |= (1UL << irq_data->offset);
-   __raw_writel(mask, intc->reg_mask);
+   writel_relaxed(mask, intc->reg_mask);
 
if (parent_intc) {
parent_data = _intc->irqs[irq_data->parent_irq];
@@ -119,9 +119,9 @@ static void s3c_irq_unmask(struct irq_data *data)
unsigned long mask;
unsigned int irqno;
 
-   mask = __raw_readl(intc->reg_mask);
+   mask = readl_relaxed(intc->reg_mask);
mask &= ~(1UL << irq_data->offset);
-   __raw_writel(mask, intc->reg_mask);
+   writel_relaxed(mask, intc->reg_mask);
 
if (parent_intc) {
irqno = irq_find_mapping(parent_intc->domain,
@@ -136,9 +136,9 @@ static inline void s3c_irq_ack(struct irq_data *data)
struct s3c_irq_intc *intc = irq_data->intc;
unsigned long bitval = 1UL << irq_data->offset;
 
-   __raw_writel(bitval, intc->reg_pending);
+   writel_relaxed(bitval, intc->reg_pending);
if (intc->reg_intpnd)
-   __raw_writel(bitval, intc->reg_intpnd);
+   writel_relaxed(bitval, intc->reg_intpnd);
 }
 
 static int s3c_irq_type(struct irq_data *data, unsigned int type)
@@ -172,9 +172,9 @@ static int s3c_irqext_type_set(void __iomem *gpcon_reg,
unsigned long newvalue = 0, value;
 
/* Set the GPIO to external interrupt mode */
-   value = __raw_readl(gpcon_reg);
+   value = readl_relaxed(gpcon_reg);
value = (value & ~(3 << gpcon_offset)) | (0x02 << gpcon_offset);
-   __raw_writel(value, gpcon_reg);
+   writel_relaxed(value, gpcon_reg);
 
/* Set the external interrupt to pointed trigger type */
switch (type)
@@ -208,9 +208,9 @@ static int s3c_irqext_type_set(void __iomem *gpcon_reg,
return -EINVAL;
}
 
-   value = __raw_readl(extint_reg);
+   value = readl_relaxed(extint_reg);
value = (value & ~(7 << extint_offset)) | (newvalue << extint_offset);
-   __raw_writel(value, extint_reg);
+   writel_relaxed(value, extint_reg);
 
return 0;
 }
@@ -315,8 +315,8 @@ static void s3c_irq_demux(struct irq_desc *desc)
 
chained_irq_enter(chip, desc);
 
-   src = __raw_readl(sub_intc->reg_pending);
-   msk = __raw_readl(sub_intc->reg_mask);
+   src = readl_relaxed(sub_intc->reg_pending);
+   msk = readl_relaxed(sub_intc->reg_mask);
 
src &= ~msk;
src &= irq_data->sub_bits;
@@ -337,7 +337,7 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc 
*intc,
int pnd;
int offset;
 
-   pnd = __raw_readl(intc->reg_intpnd);
+   pnd = readl_relaxed(intc->reg_intpnd);
if (!pnd)
return false;
 
@@ -352,7 +352,7 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc 
*intc,
 *
 * Thanks to Klaus, Shannon, et al for helping to debug this problem
 */
-   offset = __raw_readl(intc->reg_intpnd + 4);
+   offset = readl_relaxed(intc->reg_intpnd + 4);
 
/* Find the bit manually, when the offset is wrong.
 * The pending register only ever contains the one bit of the next
@@ -406,7 +406,7 @@ int s3c24xx_set_fiq(unsigned int irq, bool on)
intmod = 0;
}
 
-   __raw_writel(intmod, S3C2410_INTMOD);
+   writel_relaxed(intmod, S3C2410_INTMOD);
return 0;
 }
 
@@ -508,14 +508,14 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc *intc)
 
last = 0;
for (i = 0; i < 4; i++) {
-   pend = __raw_readl(reg_source);
+   pend = readl_relaxed(reg_source);
 
if (pend == 0 || pend == last)
break;
 
-   __raw_writel(pend, intc->reg_pending);
+   writel_relaxed(pend, intc->reg_pending);
if (intc->reg_intpnd)
-   __raw_writel(pend, intc->reg_intpnd);
+   writel_relaxed(pend, intc->reg_intpnd);
 
pr_info("irq: clearing 

Re: Using DT overlays for adding virtual hardware

[Jan Kiszka]

Hi Pantelis,

coming back to this topic:

On 2016-06-09 08:03, Jan Kiszka wrote:
> OK, trial and error, and some interesting insights: I've played with DT
> fragments and the overlay configfs patch of Pantelis [1] to have a
> convenient start. Interestingly, I wasn't able to load a fragment that
> followed the format specification for overlays ("Failed to resolve
> tree"). By chance, I got this one working:
> 
> /dts-v1/;
> / {
>   fragment {
>   target-path = "/soc@01c0";
>   __overlay__ {
>   #address-cells = <2>;
>   #size-cells = <2>;
> 
>   vpci@0x200 {
>   compatible = "pci-host-cam-generic";
>   device_type = "pci";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   reg = <0 0x200 0 0x100>;
>   ranges =
>   <0x0200 0x00 0x1000 0x00 
> 0x1000 0x00 0x3000>;
>   };
>   };
>   };
> };
> 
> It successfully makes a BananaPi kernel add a pci host with the
> specified config space and MMIO window.
> 
> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, using 
> [bus 00-ff]
> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
> 0x0200-0x02ff] for [bus 00-ff]
> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus :00
> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
> [   81.620814] pci_bus :00: root bus resource [mem 0x1000-0x3fff]
> [   81.620851] PCI: bus0: Fast back to back transfers enabled
> 
> So, no /plugin/ statement, no phandles resolution. This format even
> builds with the in-kernel dtc. Any explanations? Does the code make
> sense (at least it builds without warnings)?
> 
> Now I need to back this with some code in Jailhouse.

Meanwhile I got a virtual PCI device recognized by Linux when running
over Jailhouse. However, my hack above doesn't get me to proper
interrupt mapping yet. This is what I was trying with upstream dtc:

/dts-v1/;
/ {
compatible = "lemaker,bananapi", "allwinner,sun7i-a20";

fragment@0 {
target-path = "/soc@01c0";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;

vpci@200 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1  0 0 0 123 4>,
<0 0 0 2  0 0 0 124 4>,
<0 0 0 3  0 0 0 125 4>,
<0 0 0 4  0 0 0 126 4>;
reg = <0 0x200 0 0x10>;
ranges =
<0x0200 0x00 0x1000 0x00 
0x1000 0x00 0x3000>;
};
};
};

gic: fragment@1 {
target-path = "/soc@01c0/interrupt-controller@01c81000";
__overlay__ {
};
};
};

And this is what Linux detects on that PCI bus:

00:0f.0 RAM memory: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- ;
#size-cells = <2>;

vpci@200 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1  0 0 0 123 4>,
<0 0 0 2  0 0 0 124 4>,
<0 0 0 3  0 0 0 125 4>,
<0 0 0 4  0 0 0 126 4>;
reg = <0 0x200 0 0x10>;
ranges =

Re: [PATCH v2 3/3] Staging: comedi: s626: fix line over 80 characters issue

[Ian Abbott]

On 21/06/16 07:44, Ravishankar Karkala Mallikarjunayya wrote:

This fixes up a line over 80 characters issues found by
the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
Change log v1->v2
- No Change
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index f6806ae..73196c7 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2500,7 +2500,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL,
+NULL, s626_i2c_handshake_eoc, 0);
if (ret)
return ret;
}



Thanks!  This one applies cleanly without the other two patches in the 
series.


Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[PATCH v1 0/3] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are expected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Thanks,

Tomeu


Tomeu Vizoso (3):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API

 drivers/gpu/drm/drm_crtc.c|  28 +-
 drivers/gpu/drm/drm_debugfs.c | 506 ++-
 drivers/gpu/drm/drm_internal.h|  10 +
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 892 +-
 drivers/gpu/drm/i915/i915_dma.c   |   2 -
 drivers/gpu/drm/i915/i915_drv.h   |  21 -
 drivers/gpu/drm/i915/i915_irq.c   |  39 +-
 drivers/gpu/drm/i915/intel_display.c  |   3 +
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 556 +
 include/drm/drmP.h|   5 +
 include/drm/drm_crtc.h|  72 +++
 13 files changed, 1181 insertions(+), 960 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

-- 
2.5.5

Re: [PATCH v2 2/3] Staging: comedi: s626: Fix Warning issues.

[Ian Abbott]

On 21/06/16 07:38, Ravishankar Karkala Mallikarjunayya wrote:

This fixes up a WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
Change log v1->v2
- No Change
---
 drivers/staging/comedi/drivers/s626.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)



This one no longer applies, as it has already been fixed in Greg's 
"staging-testing" and "staging-next" branches, and in the "linux-next" 
repository.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [PATCH 0/5] Input: alps - cleanup

[Pali Rohár]

On Monday 20 June 2016 17:31:13 Dmitry Torokhov wrote:
> Hi Pali,
> 
> On Mon, Jun 06, 2016 at 01:23:56PM +0200, Pali Rohár wrote:
> > This patch series cleanup usage of alps_model_data table.
> > 
> > Pali Rohár (5):
> >   Input: alps - move ALPS_PROTO_V6 out of alps_model_data table
> >   Input: alps - move ALPS_PROTO_V4 out of alps_model_data table
> >   Input: alps - move ALPS_PROTO_V1 out of alps_model_data table
> >   Input: alps - warn about unsupported ALPS V9 touchpad
> >   Input: alps - cleanup ALPS_PROTO_V2 detection
> 
> Frankly, I do not quite like this series. The rule of thumb we had: if
> we can use e7 data to identify the device it should go into table,
> if we need to have more elaborate logic - then implement it in
> __alps_indentify(). I would understand if we got rid of the table
> completely, but we didn't.

Hans and me agreed that alps_model_data array is for old touchpads
defined as quirks table. So in this patch series I'm trying to eliminate
using that array. And it is possible for V1, V4 and V6 touchpads because
each protocol has only one entry in table. And last user is just V2
protocol which is I think better...

So this is my motivation for this patch series.

> I think the patch removing ALPS_PROTO_V4 and subsequent patch removing
> command_mode_resp from alps_model_info are good, the rest are not so
> much.
> 
> Thanks.
> 

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH v2 5/6] x86: Pass kernel thread parameters in fork_frame

[Borislav Petkov]

On Mon, Jun 20, 2016 at 11:01:02AM -0400, Brian Gerst wrote:
> The idea was to put the uncommon case (kernel thread) out of line for
> performance reasons.

A comment saying so wouldn't hurt...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: Using DT overlays for adding virtual hardware

[Jan Kiszka]

On 2016-06-21 13:35, Pantelis Antoniou wrote:
> Hi Jan,
> 
>> On Jun 21, 2016, at 14:22 , Jan Kiszka  wrote:
>>
>> On 2016-06-21 12:24, Pantelis Antoniou wrote:
>>> Hi Jan,
>>>
 On Jun 21, 2016, at 13:13 , Jan Kiszka  wrote:

 Hi Pantelis,

 coming back to this topic:

 On 2016-06-09 08:03, Jan Kiszka wrote:
> OK, trial and error, and some interesting insights: I've played with DT
> fragments and the overlay configfs patch of Pantelis [1] to have a
> convenient start. Interestingly, I wasn't able to load a fragment that
> followed the format specification for overlays ("Failed to resolve
> tree"). By chance, I got this one working:
>
> /dts-v1/;
> / {
>   fragment {
>   target-path = "/soc@01c0";
>   __overlay__ {
>   #address-cells = <2>;
>   #size-cells = <2>;
>
>   vpci@0x200 {
>   compatible = "pci-host-cam-generic";
>   device_type = "pci";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   reg = <0 0x200 0 0x100>;
>   ranges =
>   <0x0200 0x00 0x1000 0x00 
> 0x1000 0x00 0x3000>;
>   };
>   };
>   };
> };
>
> It successfully makes a BananaPi kernel add a pci host with the
> specified config space and MMIO window.
>
> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, 
> using [bus 00-ff]
> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
> 0x0200-0x02ff] for [bus 00-ff]
> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus 
> :00
> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
> [   81.620814] pci_bus :00: root bus resource [mem 
> 0x1000-0x3fff]
> [   81.620851] PCI: bus0: Fast back to back transfers enabled
>
> So, no /plugin/ statement, no phandles resolution. This format even
> builds with the in-kernel dtc. Any explanations? Does the code make
> sense (at least it builds without warnings)?
>
> Now I need to back this with some code in Jailhouse.

 Meanwhile I got a virtual PCI device recognized by Linux when running
 over Jailhouse. However, my hack above doesn't get me to proper
 interrupt mapping yet. This is what I was trying with upstream dtc:

 /dts-v1/;
 / {
compatible = "lemaker,bananapi", "allwinner,sun7i-a20";

fragment@0 {
target-path = "/soc@01c0";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;

vpci@200 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1  0 0 0 123 4>,
<0 0 0 2  0 0 0 124 4>,
<0 0 0 3  0 0 0 125 4>,
<0 0 0 4  0 0 0 126 4>;
reg = <0 0x200 0 0x10>;
ranges =
<0x0200 0x00 0x1000 0x00 
 0x1000 0x00 0x3000>;
};
};
};

gic: fragment@1 {
target-path = "/soc@01c0/interrupt-controller@01c81000";
__overlay__ {
};
};
 };

>>>
>>> ^ This is not going to work: You need the reference to the real gic not the 
>>> empty fragment
>>> here that has a target there.
>>>
>>> You need to compile with the correct dtc, and you also need to compile the 
>>> base dts
>>> with dtc too, using the -@ flag. You can hack around it by adding something 
>>> like
>>>
>>> __symbols__ {
>>> gic = "/soc@01c0/interrupt-controller@01c81000”;
>>> };
>>>
>>> But you really need the __symbols__ node of the base dts generated by the 
>>> dtc proper cause
>>> the above is a dirty hack.
>>>
>>
>> OK, re-building the kernel with DTC="/your/dtc -@", thus building the
>> base dtb with symbols, fixes proper overlay format loading.
>>
>> However, no luck yet with the 

[PATCH 02/27] mm, vmscan: Move lru_lock to the node

[Mel Gorman]

Node-based reclaim requires node-based LRUs and locking. This is a
preparation patch that just moves the lru_lock to the node so later patches
are easier to review. It is a mechanical change but note this patch makes
contention worse because the LRU lock is hotter and direct reclaim and kswapd
can contend on the same lock even when reclaiming from different zones.

Signed-off-by: Mel Gorman 
Acked-by: Johannes Weiner 
Acked-by: Vlastimil Babka 
---
 Documentation/cgroup-v1/memcg_test.txt |  4 +--
 Documentation/cgroup-v1/memory.txt |  4 +--
 include/linux/mm_types.h   |  2 +-
 include/linux/mmzone.h | 10 +--
 mm/compaction.c| 10 +++
 mm/filemap.c   |  4 +--
 mm/huge_memory.c   |  4 +--
 mm/memcontrol.c|  6 ++---
 mm/mlock.c | 10 +++
 mm/page_alloc.c|  4 +--
 mm/page_idle.c |  4 +--
 mm/rmap.c  |  2 +-
 mm/swap.c  | 30 ++---
 mm/vmscan.c| 48 +-
 14 files changed, 74 insertions(+), 68 deletions(-)

diff --git a/Documentation/cgroup-v1/memcg_test.txt 
b/Documentation/cgroup-v1/memcg_test.txt
index 8870b0212150..78a8c2963b38 100644
--- a/Documentation/cgroup-v1/memcg_test.txt
+++ b/Documentation/cgroup-v1/memcg_test.txt
@@ -107,9 +107,9 @@ Under below explanation, we assume 
CONFIG_MEM_RES_CTRL_SWAP=y.
 
 8. LRU
 Each memcg has its own private LRU. Now, its handling is under global
-   VM's control (means that it's handled under global zone->lru_lock).
+   VM's control (means that it's handled under global zone_lru_lock).
Almost all routines around memcg's LRU is called by global LRU's
-   list management functions under zone->lru_lock().
+   list management functions under zone_lru_lock().
 
A special function is mem_cgroup_isolate_pages(). This scans
memcg's private LRU and call __isolate_lru_page() to extract a page
diff --git a/Documentation/cgroup-v1/memory.txt 
b/Documentation/cgroup-v1/memory.txt
index b14abf217239..946e69103cdd 100644
--- a/Documentation/cgroup-v1/memory.txt
+++ b/Documentation/cgroup-v1/memory.txt
@@ -267,11 +267,11 @@ When oom event notifier is registered, event will be 
delivered.
Other lock order is following:
PG_locked.
mm->page_table_lock
-   zone->lru_lock
+   zone_lru_lock
  lock_page_cgroup.
   In many cases, just lock_page_cgroup() is called.
   per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
-  zone->lru_lock, it has no lock of its own.
+  zone_lru_lock, it has no lock of its own.
 
 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
 
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index e093e1d3285b..ca2ed9a6c8d8 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -118,7 +118,7 @@ struct page {
 */
union {
struct list_head lru;   /* Pageout list, eg. active_list
-* protected by zone->lru_lock !
+* protected by zone_lru_lock !
 * Can be used as a generic list
 * by the page owner.
 */
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index ccd59af5e961..5ab137edf328 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -93,7 +93,7 @@ struct free_area {
 struct pglist_data;
 
 /*
- * zone->lock and zone->lru_lock are two of the hottest locks in the kernel.
+ * zone->lock and the zone lru_lock are two of the hottest locks in the kernel.
  * So add a wild amount of padding here to ensure that they fall into separate
  * cachelines.  There are very few zone structures in the machine, so space
  * consumption is not a concern here.
@@ -494,7 +494,6 @@ struct zone {
/* Write-intensive fields used by page reclaim */
 
/* Fields commonly accessed by the page reclaim scanner */
-   spinlock_t  lru_lock;
struct lruvec   lruvec;
 
/*
@@ -688,6 +687,9 @@ typedef struct pglist_data {
/* Number of pages migrated during the rate limiting time interval */
unsigned long numabalancing_migrate_nr_pages;
 #endif
+   /* Write-intensive fields used from the page allocator */
+   ZONE_PADDING(_pad1_)
+   spinlock_t  lru_lock;
 
 #ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
/*
@@ -719,6 +721,10 @@ typedef struct pglist_data {
 
 #define node_start_pfn(nid)(NODE_DATA(nid)->node_start_pfn)
 #define node_end_pfn(nid) pgdat_end_pfn(NODE_DATA(nid))
+static inline spinlock_t *zone_lru_lock(struct zone *zone)
+{
+   

Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

[Peter Zijlstra]

On Mon, Jun 20, 2016 at 11:23:39AM +0200, Vincent Guittot wrote:

> Don't we have to do a complete attach with attach_task_cfs_rq instead
> of just the load_avg ? to set also depth ?

Hmm, yes, your sched_set_group() change seems to have munged this.

Previously we'd call task_move_group_fair() which would indeed setup
depth.

I've changed it thus (all smaller edits just didn't look right):


--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7743,7 +7743,7 @@ void sched_offline_group(struct task_gro
  * group pointers. The task will be attached to the runqueue during its wake
  * up.
  */
-static void sched_set_group(struct task_struct *tsk, bool move)
+static void sched_change_group(struct task_struct *tsk, int type)
 {
struct task_group *tg;
 
@@ -7758,8 +7758,8 @@ static void sched_set_group(struct task_
tsk->sched_task_group = tg;
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
-   if (move && tsk->sched_class->task_move_group)
-   tsk->sched_class->task_move_group(tsk);
+   if (tsk->sched_class->task_change_group)
+   tsk->sched_class->task_change_group(tsk, type);
else
 #endif
set_task_rq(tsk, task_cpu(tsk));
@@ -7788,7 +7788,7 @@ void sched_move_task(struct task_struct
if (unlikely(running))
put_prev_task(rq, tsk);
 
-   sched_set_group(tsk, true);
+   sched_change_group(tsk, TASK_MOVE_GROUP);
 
if (unlikely(running))
tsk->sched_class->set_curr_task(rq);
@@ -8227,7 +8227,7 @@ static void cpu_cgroup_fork(struct task_
 
rq = task_rq_lock(task, );
 
-   sched_set_group(task, false);
+   sched_change_group(task, TASK_SET_GROUP);
 
task_rq_unlock(rq, task, );
 }
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8443,6 +8443,14 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
 }
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
+static void task_set_group_fair(struct task_struct *p)
+{
+   struct sched_entity *se = >se;
+
+   set_task_rq(p, task_cpu(p));
+   se->depth = se->parent ? se->parent->depth + 1 : 0;
+}
+
 static void task_move_group_fair(struct task_struct *p)
 {
detach_task_cfs_rq(p);
@@ -8455,6 +8463,19 @@ static void task_move_group_fair(struct
attach_task_cfs_rq(p);
 }
 
+static void task_change_group_fair(struct task_struct *p, int type)
+{
+   switch (type) {
+   case TASK_SET_GROUP:
+   task_set_group_fair(p);
+   break;
+
+   case TASK_MOVE_GROUP:
+   task_move_group_fair(p);
+   break;
+   }
+}
+
 void free_fair_sched_group(struct task_group *tg)
 {
int i;
@@ -8683,7 +8704,7 @@ const struct sched_class fair_sched_clas
.update_curr= update_curr_fair,
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
-   .task_move_group= task_move_group_fair,
+   .task_change_group  = task_change_group_fair,
 #endif
 };
 
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1247,7 +1247,10 @@ struct sched_class {
void (*update_curr) (struct rq *rq);
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
-   void (*task_move_group) (struct task_struct *p);
+#define TASK_SET_GROUP  0
+#define TASK_MOVE_GROUP1
+
+   void (*task_change_group) (struct task_struct *p, int type);
 #endif
 };
 

Re: Using DT overlays for adding virtual hardware

[Pantelis Antoniou]

Hi Jan,

> On Jun 21, 2016, at 14:22 , Jan Kiszka  wrote:
> 
> On 2016-06-21 12:24, Pantelis Antoniou wrote:
>> Hi Jan,
>> 
>>> On Jun 21, 2016, at 13:13 , Jan Kiszka  wrote:
>>> 
>>> Hi Pantelis,
>>> 
>>> coming back to this topic:
>>> 
>>> On 2016-06-09 08:03, Jan Kiszka wrote:
 OK, trial and error, and some interesting insights: I've played with DT
 fragments and the overlay configfs patch of Pantelis [1] to have a
 convenient start. Interestingly, I wasn't able to load a fragment that
 followed the format specification for overlays ("Failed to resolve
 tree"). By chance, I got this one working:
 
 /dts-v1/;
 / {
fragment {
target-path = "/soc@01c0";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;
 
vpci@0x200 {
compatible = "pci-host-cam-generic";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
reg = <0 0x200 0 0x100>;
ranges =
<0x0200 0x00 0x1000 0x00 
 0x1000 0x00 0x3000>;
};
};
};
 };
 
 It successfully makes a BananaPi kernel add a pci host with the
 specified config space and MMIO window.
 
 [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
 [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, 
 using [bus 00-ff]
 [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
 [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
 0x0200-0x02ff] for [bus 00-ff]
 [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus 
 :00
 [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
 [   81.620814] pci_bus :00: root bus resource [mem 
 0x1000-0x3fff]
 [   81.620851] PCI: bus0: Fast back to back transfers enabled
 
 So, no /plugin/ statement, no phandles resolution. This format even
 builds with the in-kernel dtc. Any explanations? Does the code make
 sense (at least it builds without warnings)?
 
 Now I need to back this with some code in Jailhouse.
>>> 
>>> Meanwhile I got a virtual PCI device recognized by Linux when running
>>> over Jailhouse. However, my hack above doesn't get me to proper
>>> interrupt mapping yet. This is what I was trying with upstream dtc:
>>> 
>>> /dts-v1/;
>>> / {
>>> compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
>>> 
>>> fragment@0 {
>>> target-path = "/soc@01c0";
>>> __overlay__ {
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> 
>>> vpci@200 {
>>> compatible = "pci-host-ecam-generic";
>>> device_type = "pci";
>>> bus-range = <0 0>;
>>> #address-cells = <3>;
>>> #size-cells = <2>;
>>> #interrupt-cells = <1>;
>>> interrupt-map-mask = <0 0 0 7>;
>>> interrupt-map = <0 0 0 1  0 0 0 123 4>,
>>> <0 0 0 2  0 0 0 124 4>,
>>> <0 0 0 3  0 0 0 125 4>,
>>> <0 0 0 4  0 0 0 126 4>;
>>> reg = <0 0x200 0 0x10>;
>>> ranges =
>>> <0x0200 0x00 0x1000 0x00 
>>> 0x1000 0x00 0x3000>;
>>> };
>>> };
>>> };
>>> 
>>> gic: fragment@1 {
>>> target-path = "/soc@01c0/interrupt-controller@01c81000";
>>> __overlay__ {
>>> };
>>> };
>>> };
>>> 
>> 
>> ^ This is not going to work: You need the reference to the real gic not the 
>> empty fragment
>> here that has a target there.
>> 
>> You need to compile with the correct dtc, and you also need to compile the 
>> base dts
>> with dtc too, using the -@ flag. You can hack around it by adding something 
>> like
>> 
>> __symbols__ {
>>  gic = "/soc@01c0/interrupt-controller@01c81000”;
>> };
>> 
>> But you really need the __symbols__ node of the base dts generated by the 
>> dtc proper cause
>> the above is a dirty hack.
>> 
> 
> OK, re-building the kernel with DTC="/your/dtc -@", thus building the
> base dtb with symbols, fixes proper overlay format loading.
> 
> However, no luck yet with the interrupt topic - maybe a different issue.
> Digging deeper…
> 
Remove the gic: fragment and build both the 

Re: [PATCH 11/27] [AARCH64] Syscalls for ILP32 are passed always via 64bit values.

[Zhangjian (Bamvor)]

Hi,

On 2016/6/21 15:56, Andreas Schwab wrote:

Yury Norov  writes:


diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
index 1ffabc2..42f89c8 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
@@ -161,11 +161,11 @@
 call.  */
  # undef INLINE_SYSCALL
  # define INLINE_SYSCALL(name, nr, args...)\
-  ({ unsigned long _sys_result = INTERNAL_SYSCALL (name, , nr, args);  \
+  ({ unsigned long long _sys_result = INTERNAL_SYSCALL (name, , nr, args); 
\
   if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (_sys_result, ), 0))\
 {  \
 __set_errno (INTERNAL_SYSCALL_ERRNO (_sys_result, ));  \
-_sys_result = (unsigned long) -1;  \
+_sys_result = (unsigned long long) -1; \
 }  \
   (long) _sys_result; })


The cast should be (long long).

My understanding that we need more conversion, reference the follow patch:

From a0780d286277bf70bacfc0b20fe909a46b990f6e Mon Sep 17 00:00:00 2001
From: gaoyongliang 
Date: Thu, 19 May 2016 18:19:05 +0800
Subject: [PATCH] ilp32 fix syscall return value to use long long

Signed-off-by: Yongliang Gao 
Signed-off-by: Bamvor Jian Zhang 

---
 sysdeps/unix/sysdep.h| 2 +-
 sysdeps/unix/sysv/linux/aarch64/sysdep.h | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/sysdeps/unix/sysdep.h b/sysdeps/unix/sysdep.h
index 71db7f8..09b6e75 100644
--- a/sysdeps/unix/sysdep.h
+++ b/sysdeps/unix/sysdep.h
@@ -31,7 +31,7 @@

 #define SYSCALL_CANCEL(name, ...) \
   ({ \
-long int sc_ret; \
+long long sc_ret; \
 if (SINGLE_THREAD_P) \
   sc_ret = INLINE_SYSCALL (name, __SYSCALL_NARGS(__VA_ARGS__),   \
__VA_ARGS__); \
diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
index fbf76c1..a696cc2 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
@@ -173,7 +173,7 @@
   {
  \
   iserr: \
 __set_errno (INTERNAL_SYSCALL_ERRNO (sc_ret, sc_err));   \
-sc_ret = -1L;\
+sc_ret = -1LL;   \
   }
  \
   out:   \
 sc_ret;  \
@@ -216,7 +216,7 @@
  : "=r" (_x0)\
  : "r" (funcptr) ASM_ARGS_##nr   \
  : "x30", "memory");   \
-(long) _x0;\
+(long long) _x0;   \
   })


@@ -230,7 +230,7 @@
 __set_errno (INTERNAL_SYSCALL_ERRNO (_sys_result, ));  \
 _sys_result = (unsigned long long) -1; \
}   \
- (long) _sys_result; })
+ (long long) _sys_result; })

 # undef INTERNAL_SYSCALL_DECL
 # define INTERNAL_SYSCALL_DECL(err) do { } while (0)
@@ -257,7 +257,7 @@

 # undef INTERNAL_SYSCALL_ERROR_P
 # define INTERNAL_SYSCALL_ERROR_P(val, err) \
-  ((unsigned long) (val) >= (unsigned long) -4095)
+  ((unsigned long long) (val) >= (unsigned long long) -4095)

 # undef INTERNAL_SYSCALL_ERRNO
 # define INTERNAL_SYSCALL_ERRNO(val, err)  (-(val))
--
1.8.4.5



Andreas.

Re: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[Takashi Iwai]

On Tue, 21 Jun 2016 11:35:39 +0200,
高峰 wrote:
> 
> I have sent the new commit with the compile errors.
> Is it ok now?
> 
> BTW, I think the compile error is caused by that "subsys_initcall" statement 
> losts the semicolon. 

Does this happen with the latest upstream kernel code at all...?


Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de] 
> 发送时间: 2016年6月21日 17:20
> 收件人: 高峰 
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> 主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 10:48:30 +0200,
> 高峰 wrote:
> > 
> > The lastest CentOS7 platform, and the gcc version is gcc version 4.8.5
> > 20150623 (Red Hat 4.8.5-4) (GCC).
> > It could pass compilation after append the lost semicolon. 
> > 
> > from sound/core/seq/seq_device.c:39:
> > include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
> >   static exitcall_t __exitcall_##fn __exit_call = fn
> >   ^
> > include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
> >  #define module_exit(x) __exitcall(x);
> > ^
> > sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> > ‘module_exit’
> >  module_exit(alsa_seq_device_exit)
> >  ^
> > make[3]: *** [sound/core/seq/seq_device.o] Error 1
> > make[2]: *** [sound/core/seq] Error 2
> > make[1]: *** [sound/core] Error 2
> > make: *** [sound] Error 2
> 
> It's a RH specific issue.  The upstream code has a different definition of 
> module_init(), thus no such an error would occur.
> 
> Note that I'm fine to apply the patch, it's a trivial change.
> But you need to give the clear reason why to apply it.  In this case, it's no 
> fault of the upstream code.  But if it would make someone's life a bit 
> easier, it's OK to apply such a change.
> 
> That being said, please resubmit the patch with a more explanation.
> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > -邮件原件-
> > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > 发送时间: 2016年6月21日 16:45
> > 收件人: f...@ikuai8.com
> > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> > org; gfree.w...@gmail.com
> > 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > 
> > On Tue, 21 Jun 2016 10:34:25 +0200,
> >  wrote:
> > > 
> > > From: Gao Feng 
> > > 
> > > Signed-off-by: Gao Feng 
> > 
> > What compile error did you get?
> > 
> > 
> > Takashi
> > 
> > > ---
> > >  sound/core/seq/seq_device.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/sound/core/seq/seq_device.c 
> > > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > > --- a/sound/core/seq/seq_device.c
> > > +++ b/sound/core/seq/seq_device.c
> > > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > >   bus_unregister(_seq_bus_type);
> > >  }
> > >  
> > > -subsys_initcall(alsa_seq_device_init)
> > > -module_exit(alsa_seq_device_exit)
> > > +subsys_initcall(alsa_seq_device_init);
> > > +module_exit(alsa_seq_device_exit);
> > > --
> > > 1.9.1
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 

RE: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Opensource [Adam Thomson]]

21 June 2016 12:42, Rafael J. Wysocki wrote:

> > > +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> > > + const char *name)
> > > +{
> > > + return is_acpi_data_node(fwnode) ?
> > > + (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
> > > +}
> >
> > Looks fine to me.
> >
> > One question - is it expected that matching ACPI data nodes is always
> > case insensitive?
> 
> That would not be a correct expectation in theory, although I don't think it
> really matters in practice.

From my reading of the Hierarchical Data Extension and ACPI Spec, I thought
that was the case (section 19.3.1 ASL Names - ASL names are not case-sensitive
and will be converted to upper case). Am I misreading the documents/missing
something else?

Re: [PATCH 11/27] [AARCH64] Syscalls for ILP32 are passed always via 64bit values.

[Zhangjian (Bamvor)]

Hi,

On 2016/6/21 19:42, Zhangjian (Bamvor) wrote:

Hi,

On 2016/6/21 15:56, Andreas Schwab wrote:

Yury Norov  writes:


diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
index 1ffabc2..42f89c8 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
@@ -161,11 +161,11 @@
 call.  */
  # undef INLINE_SYSCALL
  # define INLINE_SYSCALL(name, nr, args...)\
-  ({ unsigned long _sys_result = INTERNAL_SYSCALL (name, , nr, args);\
+  ({ unsigned long long _sys_result = INTERNAL_SYSCALL (name, , nr, args);\
   if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (_sys_result, ), 0))\
 {\
   __set_errno (INTERNAL_SYSCALL_ERRNO (_sys_result, ));\
- _sys_result = (unsigned long) -1;\
+ _sys_result = (unsigned long long) -1;\
 }\
   (long) _sys_result; })


The cast should be (long long).

My understanding that we need more conversion, reference the follow patch:

Sorry, I used the wrong version of patch, here is the version could apply on 
yury'.
For vdso part, maybe we should fix in this patch instead of "[PATCH 19/27]
[AARCH64] Add typesizes.h for ILP32".

From 8c5f27c19407ba3ba8c400f0645cb51f91a5b379 Mon Sep 17 00:00:00 2001
From: gaoyongliang 
Date: Thu, 19 May 2016 18:19:05 +0800
Subject: [PATCH] ilp32 fix syscall return value to use long long

Signed-off-by: Yongliang Gao 
Signed-off-by: Bamvor Jian Zhang 
---
 sysdeps/unix/sysdep.h| 2 +-
 sysdeps/unix/sysv/linux/aarch64/sysdep.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sysdeps/unix/sysdep.h b/sysdeps/unix/sysdep.h
index 94a2ce0..a12456b 100644
--- a/sysdeps/unix/sysdep.h
+++ b/sysdeps/unix/sysdep.h
@@ -53,7 +53,7 @@

 #define SYSCALL_CANCEL(...) \
   ({\
-long int sc_ret;\
+long long sc_ret;   \
 if (SINGLE_THREAD_P)\
   sc_ret = __SYSCALL_CALL (__VA_ARGS__);   
 \
 else\
diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
index 42f89c8..82de012 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
@@ -167,7 +167,7 @@
 __set_errno (INTERNAL_SYSCALL_ERRNO (_sys_result, ));  \
 _sys_result = (unsigned long long) -1; \
}   \
- (long) _sys_result; })
+ (long long) _sys_result; })

 # undef INTERNAL_SYSCALL_DECL
 # define INTERNAL_SYSCALL_DECL(err) do { } while (0)
@@ -194,7 +194,7 @@

 # undef INTERNAL_SYSCALL_ERROR_P
 # define INTERNAL_SYSCALL_ERROR_P(val, err) \
-  ((unsigned long) (val) >= (unsigned long) -4095)
+  ((unsigned long long) (val) >= (unsigned long long) -4095)

 # undef INTERNAL_SYSCALL_ERRNO
 # define INTERNAL_SYSCALL_ERRNO(val, err)  (-(val))
--
1.8.4.5



 From a0780d286277bf70bacfc0b20fe909a46b990f6e Mon Sep 17 00:00:00 2001
From: gaoyongliang 
Date: Thu, 19 May 2016 18:19:05 +0800
Subject: [PATCH] ilp32 fix syscall return value to use long long

Signed-off-by: Yongliang Gao 
Signed-off-by: Bamvor Jian Zhang 

---
  sysdeps/unix/sysdep.h| 2 +-
  sysdeps/unix/sysv/linux/aarch64/sysdep.h | 8 
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/sysdeps/unix/sysdep.h b/sysdeps/unix/sysdep.h
index 71db7f8..09b6e75 100644
--- a/sysdeps/unix/sysdep.h
+++ b/sysdeps/unix/sysdep.h
@@ -31,7 +31,7 @@

  #define SYSCALL_CANCEL(name, ...) \
({ \
-long int sc_ret; \
+long long sc_ret; \
  if (SINGLE_THREAD_P) \
sc_ret = INLINE_SYSCALL (name, __SYSCALL_NARGS(__VA_ARGS__),   \
 __VA_ARGS__); \
diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
index fbf76c1..a696cc2 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
@@ -173,7 +173,7 @@
{  \
iserr:  \
  

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[wangyijing]

Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
what about do the similar change for x86, now we request host bridge resource
in pci_acpi_root_add_resources() in x86, and we would release the host bridge
resource when host bridge device refcount reach 0. This logic may introduce 
issue,
E.g.
If we try to remove a pci host bridge, but there is a child pci device which 
refcount
cannot decrease to 0 after remove the device, in this case, its parent pci_bus 
and
parent device, all their refcount cannot reach to 0, the result is pci host 
bridge
refcount can not reach 0, so its .release_fn() won't be called, and host bridge
resouces can not release. If we want to add the pci host bridge again, all pci 
devices
can not work because the resource is conflict with the old.

devm resource would be released when the driver detach, this is better than 
what we do now, I think.

Thanks!
Yijing.

在 2016/6/19 2:07, Bjorn Helgaas 写道:
> On Mon, Jun 06, 2016 at 06:04:44PM -0500, Bjorn Helgaas wrote:
>> Several host bridge drivers (designware and all derivatives, iproc,
>> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
>> windows they forward downstream to the PCI bus.
>>
>> That means the PCI core can't request resources for PCI bridge
>> windows and PCI BARs.
>>
>> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
>> the windows, but use some duplicated code to do it.
>>
>> This adds a new devm_request_pci_bus_resources() interface and changes
>> these drivers to use it.  It also fixes several error paths where we failed
>> to free the resource list allocated by of_pci_get_host_bridge_resources().
>>
>> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
>> from hierarchy" in particular.  Removing the top-level resource definitely
>> makes /proc/iomem look uglier (although it will look more like that of
>> other drivers).  A short-term fix could be to include device information in
>> the resource name.  I think a better long-term fix would be to make the DT
>> or platform device core request all the resources from the DT.
>>
>> Comments welcome.  I expect we'll trip over something here, so I marked
>> this "v1" and I don't plan to put it into -next for a while.
>>
>> This is on my pci/host-request-windows branch, which you can pull or view
>> at 
>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> 
> I merged this to my -next branch, so it should show up in linux-next
> in a couple days.  Let me know if you see any problems.
> 
>> Bjorn Helgaas (25):
>>   PCI: Add devm_request_pci_bus_resources()
>>   PCI: designware: Free bridge resource list on failure
>>   PCI: designware: Request host bridge window resources
>>   PCI: designware: Simplify host bridge window iteration
>>   PCI: iproc: Request host bridge window resources
>>   PCI: xgene: Free bridge resource list on failure
>>   PCI: xgene: Request host bridge window resources
>>   PCI: xilinx: Free bridge resource list on failure
>>   PCI: xilinx: Request host bridge window resources
>>   PCI: xilinx-nwl: Free bridge resource list on failure
>>   PCI: xilinx-nwl: Request host bridge window resources
>>   PCI: xilinx-nwl: Use dev_printk() when possible
>>   PCI: altera: Request host bridge window resources with core function
>>   PCI: altera: Simplify host bridge window iteration
>>   PCI: generic: Free resource list close to where it's allocated
>>   PCI: generic: Request host bridge window resources with core function
>>   PCI: generic: Simplify host bridge window iteration
>>   PCI: mvebu: Request host bridge window resources with core function
>>   PCI: rcar Gen2: Request host bridge window resources
>>   PCI: rcar: Request host bridge window resources with core function
>>   PCI: rcar: Simplify host bridge window iteration
>>   PCI: tegra: Remove top-level resource from hierarchy
>>   PCI: tegra: Request host bridge window resources with core function
>>   PCI: versatile: Request host bridge window resources with core function
>>   PCI: versatile: Simplify host bridge window iteration
>>
>>
>>  drivers/pci/bus.c  |   29 +
>>  drivers/pci/host/pci-host-common.c |   61 
>> +++-
>>  drivers/pci/host/pci-mvebu.c   |   17 --
>>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>>  drivers/pci/host/pci-tegra.c   |   35 +++--
>>  drivers/pci/host/pci-versatile.c   |   29 ++---
>>  drivers/pci/host/pci-xgene.c   |   16 -
>>  drivers/pci/host/pcie-altera.c |   35 ++---
>>  drivers/pci/host/pcie-designware.c |   34 +---
>>  drivers/pci/host/pcie-iproc.c  |4 ++
>>  drivers/pci/host/pcie-rcar.c   |   33 +--
>>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>>  

Re: [PATCH 20/27] [AARCH64] Make lp64 and ilp32 directories.

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> From: Andrew Pinski 
> 
> The patch makes the ilp32 and lp64 have their own directory under aarch64.
> Since ILP32 uses most of the same system calls as LP64 and has a 64bit
> off_t, we need make the functions that end in 64 the same as the ones without.
> We also need not to special case ioctl or use the already provided mmap.c 
> file.

My previous comments at 
 apply.  Where 
are your ABI test baselines?

> diff --git a/sysdeps/aarch64/ilp32/Implies b/sysdeps/aarch64/ilp32/Implies
> new file mode 100644
> index 000..705bc5b
> --- /dev/null
> +++ b/sysdeps/aarch64/ilp32/Implies
> @@ -0,0 +1,6 @@
> +aarch64
> +wordsize-32
> +ieee754/ldbl-128
> +ieee754/dbl-64
> +ieee754/flt-32
> +aarch64/soft-fp

You can use ieee754/dbl-64/wordsize-64 here.  See my commit 
b75bc69cdfe5247b2156ce249518f1c1df4d797d.

> diff --git a/sysdeps/unix/sysv/linux/aarch64/ilp32/getdents.c 
> b/sysdeps/unix/sysv/linux/aarch64/ilp32/getdents.c

The formatting in this file is thoroughly wrong.

> diff --git a/sysdeps/unix/sysv/linux/aarch64/ilp32/preadv.c 
> b/sysdeps/unix/sysv/linux/aarch64/ilp32/preadv.c
> new file mode 100644
> index 000..b5b9994
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/aarch64/ilp32/preadv.c
> @@ -0,0 +1 @@
> +/* See preadv.c */
> \ No newline at end of file

All files should have final newlines (but with Adhemerval's preadv 
unification, you shouldn't need this; make the unified version more 
general if necessary).

> diff --git a/sysdeps/unix/sysv/linux/aarch64/ilp32/shlib-versions 
> b/sysdeps/unix/sysv/linux/aarch64/ilp32/shlib-versions
> new file mode 100644
> index 000..17db764
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/aarch64/ilp32/shlib-versions
> @@ -0,0 +1,7 @@
> +DEFAULT  GLIBC_2.21

No, GLIBC_2.24 if this gets in by the end of June, GLIBC_2.25 otherwise 
(since glibc is frozen for release during July).  The symbol version is 
always the version of the first release with the new port.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

On 21 June 2016 at 19:53, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> On 21 June 2016 at 19:03, Mark Brown  wrote:
>>> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
 Baolin Wang  writes:
 > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct 
 > platform_device *pdev)
 > }
 > }
>>>
 > +   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
 > +   power->usb_charger =
 > +   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
>>>
 the fact that you rely on strings and pass them via pdata is an
 indication that you don't have enough description of the HW. Seems like
 we need to come up with a set of DT properties which tie a charger to a
 UDC.
>>>
 I'm thinking a phandle would be enough?
>>>
>>> The wm831x has no DT support currently.
>>
>> Another hand I suppose the usb charger is one virtual device and does
>> not need be described from DT.
>
> Right, I don't think that should be a device at all. But you can pass a
> phandle to the UDC controller and use that to get to struct usb_gadget
> from which you could reach ->charger.

Ah, make sense.

-- 
Baolin.wang
Best Regards

Re: [PATCH] MAINTAINERS: update STi maintainer list

[Patrice Chotard]

On 06/21/2016 11:35 AM, Maxime Coquelin wrote:

Remove myself as STi maintainer as I will no longer have access to
STi platforms, and remove Srini too, who now works on other
platforms.

Patrice will manage the pull requests.

Signed-off-by: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Srinivas Kandagatla 
Cc: Arnd Bergmann 
---
  MAINTAINERS | 2 --
  1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..1ea14565d9d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1689,8 +1689,6 @@ S:Maintained
  F:drivers/edac/altera_edac.
  
  ARM/STI ARCHITECTURE

-M: Srinivas Kandagatla 
-M: Maxime Coquelin 
  M:Patrice Chotard 
  L:linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
  L:ker...@stlinux.com

Acked-by: Patrice Chotard 

[PATCH v3 2/2] clk: fixed-rate: Convert into a module platform driver

[Ricardo Ribalda Delgado]

Adds support for fixed-rate clock providers which have not been
enabled via of_clk_init().

This is required by Device trees overlays that introduce clocks
providers.

Signed-off-by: Ricardo Ribalda Delgado 
---
v3: Changes proposed by: Stephen Boyd 
-Use OF_POPULATED flag

v2: Changes proposed by: Stephen Boyd 
-Add error check
-CodeStyle on of_device_ide
-Use builtin_platform_driver()
 drivers/clk/clk-fixed-rate.c | 70 +---
 1 file changed, 66 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 8e4453eb54e8..d5f9aa086acc 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * DOC: basic fixed-rate clock that cannot gate
@@ -149,15 +150,16 @@ EXPORT_SYMBOL_GPL(clk_unregister_fixed_rate);
 /**
  * of_fixed_clk_setup() - Setup function for simple fixed rate clock
  */
-void of_fixed_clk_setup(struct device_node *node)
+struct clk *_of_fixed_clk_setup(struct device_node *node)
 {
struct clk *clk;
const char *clk_name = node->name;
u32 rate;
u32 accuracy = 0;
+   int ret;
 
if (of_property_read_u32(node, "clock-frequency", ))
-   return;
+   return ERR_PTR(-EIO);
 
of_property_read_u32(node, "clock-accuracy", );
 
@@ -165,9 +167,69 @@ void of_fixed_clk_setup(struct device_node *node)
 
clk = clk_register_fixed_rate_with_accuracy(NULL, clk_name, NULL,
0, rate, accuracy);
-   if (!IS_ERR(clk))
-   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (IS_ERR(clk))
+   return clk;
+
+   ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (ret) {
+   clk_unregister(clk);
+   return ERR_PTR(ret);
+   }
+
+   return clk;
+}
+
+void of_fixed_clk_setup(struct device_node *node)
+{
+   if (!_of_fixed_clk_setup(node))
+   of_node_set_flag(node, OF_POPULATED);
 }
 EXPORT_SYMBOL_GPL(of_fixed_clk_setup);
 CLK_OF_DECLARE(fixed_clk, "fixed-clock", of_fixed_clk_setup);
+
+static int of_fixed_clk_remove(struct platform_device *pdev)
+{
+   struct clk *clk = platform_get_drvdata(pdev);
+
+   if (clk)
+   clk_unregister_fixed_rate(clk);
+
+   return 0;
+}
+
+static int of_fixed_clk_probe(struct platform_device *pdev)
+{
+   struct clk *clk;
+
+   /*
+* This function is not executed when of_fixed_clk_setup
+* succeeded.
+*/
+
+   clk = _of_fixed_clk_setup(pdev->dev.of_node);
+
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   platform_set_drvdata(pdev, clk);
+
+   return 0;
+}
+
+static const struct of_device_id of_fixed_clk_ids[] = {
+   { .compatible = "fixed-clock" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_fixed_clk_ids);
+
+static struct platform_driver of_fixed_clk_driver = {
+   .driver = {
+   .name = "of_fixed_clk",
+   .of_match_table = of_fixed_clk_ids,
+   },
+   .probe = of_fixed_clk_probe,
+   .remove = of_fixed_clk_remove,
+};
+
+builtin_platform_driver(of_fixed_clk_driver);
 #endif
-- 
2.8.1

[PATCH v3 1/2] clk: fixed-factor: Convert into a module platform driver

[Ricardo Ribalda Delgado]

Adds support for fixed-factor clock providers which have not been
enabled via of_clk_init().

This is required by Device trees overlays that introduce clocks
providers.

Signed-off-by: Ricardo Ribalda Delgado 
---
v3: Changes proposed by: Stephen Boyd 
-Use OF_POPULATED flag

v2: Changes proposed by: Stephen Boyd 
-Add error check
-CodeStyle on of_device_ide
-Use builtin_platform_driver()

 drivers/clk/clk-fixed-factor.c | 73 +++---
 1 file changed, 68 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 75cd6c792cb8..80b9e440f2c3 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -145,23 +146,24 @@ EXPORT_SYMBOL_GPL(clk_hw_unregister_fixed_factor);
 /**
  * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
  */
-void __init of_fixed_factor_clk_setup(struct device_node *node)
+struct clk *_of_fixed_factor_clk_setup(struct device_node *node)
 {
struct clk *clk;
const char *clk_name = node->name;
const char *parent_name;
u32 div, mult;
+   int ret;
 
if (of_property_read_u32(node, "clock-div", )) {
pr_err("%s Fixed factor clock <%s> must have a clock-div 
property\n",
__func__, node->name);
-   return;
+   return ERR_PTR(-EIO);
}
 
if (of_property_read_u32(node, "clock-mult", )) {
pr_err("%s Fixed factor clock <%s> must have a clock-mult 
property\n",
__func__, node->name);
-   return;
+   return ERR_PTR(-EIO);
}
 
of_property_read_string(node, "clock-output-names", _name);
@@ -169,10 +171,71 @@ void __init of_fixed_factor_clk_setup(struct device_node 
*node)
 
clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
mult, div);
-   if (!IS_ERR(clk))
-   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (IS_ERR(clk))
+   return clk;
+
+   ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (ret) {
+   clk_unregister(clk);
+   return ERR_PTR(ret);
+   }
+
+   return clk;
+}
+
+void __init of_fixed_factor_clk_setup(struct device_node *node)
+{
+   if (!_of_fixed_factor_clk_setup(node))
+   of_node_set_flag(node, OF_POPULATED);
 }
 EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
 CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
of_fixed_factor_clk_setup);
+
+static int of_fixed_factor_clk_remove(struct platform_device *pdev)
+{
+   struct clk *clk = platform_get_drvdata(pdev);
+
+   if (clk)
+   clk_unregister_fixed_factor(clk);
+
+   return 0;
+}
+
+static int of_fixed_factor_clk_probe(struct platform_device *pdev)
+{
+   struct clk *clk;
+
+   /*
+* This function is not executed when of_fixed_factor_clk_setup
+* succeeded.
+*/
+
+   clk = _of_fixed_factor_clk_setup(pdev->dev.of_node);
+
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   platform_set_drvdata(pdev, clk);
+
+   return 0;
+}
+
+static const struct of_device_id of_fixed_factor_clk_ids[] = {
+   { .compatible = "fixed-factor-clock" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_fixed_factor_clk_ids);
+
+static struct platform_driver of_fixed_factor_clk_driver = {
+   .driver = {
+   .name = "of_fixed_factor_clk",
+   .of_match_table = of_fixed_factor_clk_ids,
+   },
+   .probe = of_fixed_factor_clk_probe,
+   .remove = of_fixed_factor_clk_remove,
+};
+
+builtin_platform_driver(of_fixed_factor_clk_driver);
+
 #endif
-- 
2.8.1

Re: [PATCH 1/1] sound: Fix compile error of seq_device.c

[Takashi Iwai]

On Tue, 21 Jun 2016 10:34:25 +0200,
 wrote:
> 
> From: Gao Feng 
> 
> Signed-off-by: Gao Feng 

What compile error did you get?


Takashi

> ---
>  sound/core/seq/seq_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/core/seq/seq_device.c b/sound/core/seq/seq_device.c
> index c4acf17..4e859e4 100644
> --- a/sound/core/seq/seq_device.c
> +++ b/sound/core/seq/seq_device.c
> @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
>   bus_unregister(_seq_bus_type);
>  }
>  
> -subsys_initcall(alsa_seq_device_init)
> -module_exit(alsa_seq_device_exit)
> +subsys_initcall(alsa_seq_device_init);
> +module_exit(alsa_seq_device_exit);
> -- 
> 1.9.1
> 
> 
> 
> 
> 

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Johannes Berg]

On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
> 
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)

Agree with that, yeah, that'd be confusing.

> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and I believe we should stick with that.
> 
> But small problem might be polarity. You may need both "::rfkill" and
> "::not-rfkill".

I'd argue that "airplane" matches better what you're likely to find on
the chassis of the system.

In either case I think the suffixes should be documented, for both
future kernel and application developers.

johannes

Re: [PATCH v9 2/4] power: reset: add reboot mode driver

[Krzysztof Kozlowski]

On 06/21/2016 08:16 AM, Andy Yan wrote:
>   I will remove the module related stuff in the next version.
>>> Following his rationale, I think either this should be a tristate or the
>>> module stuff should be removed.

How about making it tristate? I think there isn't any obstacles for this
driver being a module. Some distros like modules.

Best regards.
Krzysztof

Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Joerg Roedel]

On Wed, Jun 08, 2016 at 07:31:10PM +0100, Matthew Leach wrote:
> From: Ben Dooks 
> 
> Add initial support for big endian by always writing the pte
> in le32. Note, revisit if hardware capable of doing big endian
> fetches.
> 
> Signed-off-by: Ben Dooks 
> ---
> Cc: Marek Szyprowski 
> Cc: Joerg Roedel 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: io...@lists.linux-foundation.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org (open list)
> ---
>  drivers/iommu/exynos-iommu.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied, thanks.

答复: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[高峰]

Oh, I get it.

I met the compile error when compile the kernel 3.10 on CentOS7 and fix it, 
then I find the seq_device of upstream is same.
So I thought it should be fixed.

OK. Let me compile the upstream codes on CentOS7 again.

-邮件原件-
发件人: Takashi Iwai [mailto:ti...@suse.de] 
发送时间: 2016年6月21日 17:54
收件人: 高峰 
抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; 
gfree.w...@gmail.com
主题: Re: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

On Tue, 21 Jun 2016 11:35:39 +0200,
高峰 wrote:
> 
> I have sent the new commit with the compile errors.
> Is it ok now?
> 
> BTW, I think the compile error is caused by that "subsys_initcall" statement 
> losts the semicolon. 

Does this happen with the latest upstream kernel code at all...?


Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de]
> 发送时间: 2016年6月21日 17:20
> 收件人: 高峰 
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> 主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 10:48:30 +0200,
> 高峰 wrote:
> > 
> > The lastest CentOS7 platform, and the gcc version is gcc version 
> > 4.8.5
> > 20150623 (Red Hat 4.8.5-4) (GCC).
> > It could pass compilation after append the lost semicolon. 
> > 
> > from sound/core/seq/seq_device.c:39:
> > include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
> >   static exitcall_t __exitcall_##fn __exit_call = fn
> >   ^
> > include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
> >  #define module_exit(x) __exitcall(x);
> > ^
> > sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> > ‘module_exit’
> >  module_exit(alsa_seq_device_exit)
> >  ^
> > make[3]: *** [sound/core/seq/seq_device.o] Error 1
> > make[2]: *** [sound/core/seq] Error 2
> > make[1]: *** [sound/core] Error 2
> > make: *** [sound] Error 2
> 
> It's a RH specific issue.  The upstream code has a different definition of 
> module_init(), thus no such an error would occur.
> 
> Note that I'm fine to apply the patch, it's a trivial change.
> But you need to give the clear reason why to apply it.  In this case, it's no 
> fault of the upstream code.  But if it would make someone's life a bit 
> easier, it's OK to apply such a change.
> 
> That being said, please resubmit the patch with a more explanation.
> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > -邮件原件-
> > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > 发送时间: 2016年6月21日 16:45
> > 收件人: f...@ikuai8.com
> > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> > org; gfree.w...@gmail.com
> > 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > 
> > On Tue, 21 Jun 2016 10:34:25 +0200,
> >  wrote:
> > > 
> > > From: Gao Feng 
> > > 
> > > Signed-off-by: Gao Feng 
> > 
> > What compile error did you get?
> > 
> > 
> > Takashi
> > 
> > > ---
> > >  sound/core/seq/seq_device.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/sound/core/seq/seq_device.c 
> > > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > > --- a/sound/core/seq/seq_device.c
> > > +++ b/sound/core/seq/seq_device.c
> > > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > >   bus_unregister(_seq_bus_type);
> > >  }
> > >  
> > > -subsys_initcall(alsa_seq_device_init)
> > > -module_exit(alsa_seq_device_exit)
> > > +subsys_initcall(alsa_seq_device_init);
> > > +module_exit(alsa_seq_device_exit);
> > > --
> > > 1.9.1
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 

Re: [PATCH v12 2/4] gadget: Support for the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
>
> It will report to the usb charger when the gadget state is changed,
> then the usb charger can do the power things.
>
> Signed-off-by: Baolin Wang 
> Reviewed-by: Li Jun 
> Tested-by: Li Jun 

Before anything, I must say that I really liked this patch. It's
minimaly invasive to udc core and does all the necessary changes. If it
wasn't for the extra charger class, this would've been perfect.

Can't you just tie a charger to a UDC and avoid the charger class
completely?

>  static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned 
> mA)
>  {
> + if (gadget->charger)

I guess you could do this check inside
usb_gadget_set_cur_limit_by_type() itself.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing

[Peter Zijlstra]

On Mon, Jun 20, 2016 at 10:26:30AM +, Odzioba, Lukasz wrote:
> On 08.06.2016 Peter Zijlstra wrote:
> > How does this work in the light of intel_alt_er() ?
> 
> Hi Peter,
> 
> If the constrained bit is valid on only one of the OCR MSRs (like in case of 
> KNL), 
> then OCR valid mask will forbid altering it by the other MSR in intel_alt_er.

Yes, that is the intent, but how is this achieved? I'm not sure I see
how the patch ensure this.

Also, intel_get_event_constraints() has a path where it copies the
constraint, should it not also copy the new field?

[PATCH v7 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

Signed-off-by: Frank Wang 
Suggested-by: Heiko Stuebner 
Suggested-by: Guenter Roeck 
Suggested-by: Doug Anderson 
---

Changes in v7:
 - renamed functions *usb2phy_resume/*usb2phy_suspend to 
*usb2phy_power_on/usb2phy_power_off.

Changes in v6:
 - Fixed the output clock would be disabled more than once while phy-port was 
going to suspend.
 - Improved the driver to avoid the currently empty otg-port would cause 
null-pointer dereferences.

Changes in v5:
 - Added 'reg' in the data block to match the different phy-blocks in dt.

Changes in v4:
 - Removed some processes related to 'vbus_host-supply'.

Changes in v3:
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Optimized 480m output clock register function.
 - Code cleanup.

Changes in v2:
 - Changed vbus_host operation from gpio to regulator in *_probe.
 - Improved the fault treatment relate to 480m clock register.
 - Cleaned up some meaningless codes in *_clk480m_disable.
 - made more clear the comment of *_sm_work.

 drivers/phy/Kconfig  |7 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-inno-usb2.c |  658 ++
 3 files changed, 666 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..29ef15c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_INNO_USB2
+   tristate "Rockchip INNO USB2PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Support for Rockchip USB2.0 PHY with Innosilicon IP block.
+
 config PHY_ROCKCHIP_EMMC
tristate "Rockchip EMMC PHY Driver"
depends on ARCH_ROCKCHIP && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..4963fbc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
new file mode 100644
index 000..299f599
--- /dev/null
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -0,0 +1,658 @@
+/*
+ * Rockchip USB2.0 PHY with Innosilicon IP block driver
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BIT_WRITEABLE_SHIFT16
+#define SCHEDULE_DELAY (60 * HZ)
+
+enum rockchip_usb2phy_port_id {
+   USB2PHY_PORT_OTG,
+   USB2PHY_PORT_HOST,
+   USB2PHY_NUM_PORTS,
+};
+
+enum rockchip_usb2phy_host_state {
+   PHY_STATE_HS_ONLINE = 0,
+   PHY_STATE_DISCONNECT= 1,
+   PHY_STATE_HS_CONNECT= 2,
+   PHY_STATE_FS_CONNECT= 4,
+};
+
+struct usb2phy_reg {
+   unsigned intoffset;
+   unsigned intbitend;
+   unsigned intbitstart;
+   unsigned intdisable;
+   unsigned intenable;
+};
+
+/**
+ * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
+ * @phy_sus: phy suspend register.
+ * @ls_det_en: linestate detection enable register.
+ * @ls_det_st: linestate detection state register.
+ * @ls_det_clr: linestate detection clear register.
+ * @utmi_ls: utmi linestate state register.
+ * @utmi_hstdet: utmi host disconnect register.
+ */
+struct rockchip_usb2phy_port_cfg {
+   struct usb2phy_reg  phy_sus;
+   struct usb2phy_reg  ls_det_en;
+   struct usb2phy_reg  

[PATCH v7 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Frank Wang]

Signed-off-by: Frank Wang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

Changes in v6:
 - Changed '_' to '-' for otg-id and otg-bvalid property.

Changes in v5:
 - Added 'reg' property to identify the different phy-blocks.

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Added 'clocks' and 'clock-names' optional properties.
 - Specified 'otg-port' and 'host-port' as the sub-node name.

Changes in v2:
 - Changed vbus_host optional property from gpio to regulator.
 - Specified vbus_otg-supply optional property.
 - Specified otg_id and otg_bvalid property.

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   64 
 1 file changed, 64 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
new file mode 100644
index 000..3c29c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,64 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+   * "rockchip,rk3366-usb2phy"
+   * "rockchip,rk3399-usb2phy"
+ - reg : the address offset of grf for usb-phy configuration.
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify host or otg port,
+and shall be the following entries:
+   * "otg-port" : the name of otg port.
+   * "host-port" : the name of host port.
+
+Required properties (port (child) node):
+ - #phy-cells : must be 0. See ./phy-bindings.txt for details.
+ - interrupts : specify an interrupt for each entry in interrupt-names.
+ - interrupt-names : a list which shall be the following entries:
+   * "otg-id" : for the otg id interrupt.
+   * "otg-bvalid" : for the otg vbus interrupt.
+   * "linestate" : for the host/otg linestate interrupt.
+
+Optional properties:
+ - phy-supply : phandle to a regulator that provides power to VBUS.
+   See ./phy-bindings.txt for details.
+
+Example:
+
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+...
+
+   u2phy: usb2-phy@700 {
+   compatible = "rockchip,rk3366-usb2phy";
+   reg = <0x700 0x2c>;
+   #clock-cells = <0>;
+   clock-output-names = "sclk_otgphy0_480m";
+
+   u2phy_otg: otg-port {
+   #phy-cells = <0>;
+   interrupts = ,
+,
+;
+   interrupt-names = "otg-id", "otg-bvalid", "linestate";
+   status = "okay";
+   };
+
+   u2phy_host: host-port {
+   #phy-cells = <0>;
+   interrupts = ;
+   interrupt-names = "linestate";
+   status = "okay";
+   };
+   };
+};
-- 
1.7.9.5

Re: [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs

[Vladimir Davydov]

On Fri, Jun 17, 2016 at 12:25:16PM -0400, Johannes Weiner wrote:
> The memory controller has quite a bit of state that usually outlives
> the cgroup and pins its CSS until said state disappears. At the same
> time it imposes a 16-bit limit on the CSS ID space to economically
> store IDs in the wild. Consequently, when we use cgroups to contain
> frequent but small and short-lived jobs that leave behind some page
> cache, we quickly run into the 64k limitations of outstanding CSSs.
> Creating a new cgroup fails with -ENOSPC while there are only a few,
> or even no user-visible cgroups in existence.
> 
> Although pinning CSSs past cgroup removal is common, there are only
> two instances that actually need an ID after a cgroup is deleted:
> cache shadow entries and swapout records.
> 
> Cache shadow entries reference the ID weakly and can deal with the CSS
> having disappeared when it's looked up later. They pose no hurdle.
> 
> Swap-out records do need to pin the css to hierarchically attribute
> swapins after the cgroup has been deleted; though the only pages that
> remain swapped out after offlining are tmpfs/shmem pages. And those
> references are under the user's control, so they are manageable.
> 
> This patch introduces a private 16-bit memcg ID and switches swap and
> cache shadow entries over to using that. This ID can then be recycled
> after offlining when the CSS remains pinned only by objects that don't
> specifically need it.
> 
> This script demonstrates the problem by faulting one cache page in a
> new cgroup and deleting it again:
> 
> set -e
> mkdir -p pages
> for x in `seq 128000`; do
>   [ $((x % 1000)) -eq 0 ] && echo $x
>   mkdir /cgroup/foo
>   echo $$ >/cgroup/foo/cgroup.procs
>   echo trex >pages/$x
>   echo $$ >/cgroup/cgroup.procs
>   rmdir /cgroup/foo
> done
> 
> When run on an unpatched kernel, we eventually run out of possible IDs
> even though there are no visible cgroups:
> 
> [root@ham ~]# ./cssidstress.sh
> [...]
> 65000
> mkdir: cannot create directory '/cgroup/foo': No space left on device
> 
> After this patch, the IDs get released upon cgroup destruction and the
> cache and css objects get released once memory reclaim kicks in.

With 65K cgroups it will take the reclaimer a substantial amount of time
to iterate over all of them, which might result in latency spikes.
Probably, to avoid that, we could move pages from a dead cgroup's lru to
its parent's one on offline while still leaving dead cgroups pinned,
like we do in case of list_lru entries.

> 
> Signed-off-by: Johannes Weiner 

Reviewed-by: Vladimir Davydov 

One nit below.

...
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 75e74408cc8f..dc92b2df2585 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4057,6 +4057,60 @@ static struct cftype mem_cgroup_legacy_files[] = {
>   { },/* terminate */
>  };
>  
> +/*
> + * Private memory cgroup IDR
> + *
> + * Swap-out records and page cache shadow entries need to store memcg
> + * references in constrained space, so we maintain an ID space that is
> + * limited to 16 bit (MEM_CGROUP_ID_MAX), limiting the total number of
> + * memory-controlled cgroups to 64k.
> + *
> + * However, there usually are many references to the oflline CSS after
> + * the cgroup has been destroyed, such as page cache or reclaimable
> + * slab objects, that don't need to hang on to the ID. We want to keep
> + * those dead CSS from occupying IDs, or we might quickly exhaust the
> + * relatively small ID space and prevent the creation of new cgroups
> + * even when there are much fewer than 64k cgroups - possibly none.
> + *
> + * Maintain a private 16-bit ID space for memcg, and allow the ID to
> + * be freed and recycled when it's no longer needed, which is usually
> + * when the CSS is offlined.
> + *
> + * The only exception to that are records of swapped out tmpfs/shmem
> + * pages that need to be attributed to live ancestors on swapin. But
> + * those references are manageable from userspace.
> + */
> +
> +static struct idr mem_cgroup_idr;

static DEFINE_IDR(mem_cgroup_idr);

[PATCH v7 0/2] Add a new Rockchip usb2 phy driver

[Frank Wang]

The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy
IP block than rk3288 and before, and most of phy-related registers are
also different from the past, so a new phy driver is required necessarily.

These series patches add phy-rockchip-inno-usb2.c and the corresponding
documentation.

Changes in v7:
 - renamed functions *usb2phy_resume/*usb2phy_suspend to 
*usb2phy_power_on/usb2phy_power_off.

Changes in v6:
 - Changed '_' to '-' for otg-id and otg-bvalid property in devicetree bindings.
 - Fixed the output clock would be disabled more than once while phy-port was 
going to suspend.
 - Improved the driver to avoid the currently empty otg-port would cause 
null-pointer dereferences.

Changes in v5:
 - Added 'reg' property both in devicetree bindings and driver to match the 
different phy-blocks.

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Supplemented some hardware-description into the devicetree bindings.
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Code cleanup.

Changes in v2:
 - Specified more hardware-description into the devicetree bindings.
 - Optimized some process of driver.

Frank Wang (2):
  Documentation: bindings: add DT documentation for Rockchip USB2PHY
  phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   64 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-rockchip-inno-usb2.c   |  658 
 4 files changed, 730 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

-- 
1.7.9.5

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata->usb_gadget);

the fact that you rely on strings and pass them via pdata is an
indication that you don't have enough description of the HW. Seems like
we need to come up with a set of DT properties which tie a charger to a
UDC.

I'm thinking a phandle would be enough?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

[Wei Hu (Xavier)]

On 2016/6/20 21:33, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:

This patch added the operation for cmd, and added some functions
for initializing eq table and selecting cmd mode.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---
PATCH v9/v8/v7/v6:
- No change over the PATCH v5

PATCH v5:
- The initial patch which was redesigned based on the second patch
   in PATCH v4
---

<...>


+#define CMD_MAX_NUM32
+
+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
+{
+   struct device *dev = _dev->pdev->dev;
+
+   mutex_init(_dev->cmd.hcr_mutex);
+   sema_init(_dev->cmd.poll_sem, 1);
+   hr_dev->cmd.use_events = 0;
+   hr_dev->cmd.toggle = 1;
+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;

<...>


+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
+hr_cmd->token_mask <<= 1)
+   ;
+   --hr_cmd->token_mask;

It doesn't look that you dynamically change max_cmds supported.
Why do you need to calculate token_mask dynamically?

Hi, Leon

1. The four lines above are in the function named 
hns_roce_cmd_use_events.

 and now this function is only called once in hns_roce_probe.
2. In hns_roce_cmd_use_events,
we use these 4 lines to achieve the value of hr_cmd->token_mask 
according to hr_cmd->max_cmds dynamically,

then we only define one marco for hr_cmd->max_cmds as below:

#define CMD_MAX_NUM 32

   And it looks more flexible.

Regards
Wei Hu

Re: [PATCH v6 2/4] power: reset: add reboot mode driver

[Andy Yan]

Hi Krzysztof:

On 2016年03月24日 10:50, Krzysztof Kozlowski wrote:

Cool work! Few comments below.


On Tue, Mar 22, 2016 at 8:37 PM, Andy Yan  wrote:

This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram , which can
be read by the bootloader after system reboot, then the bootloader
can take different action according to the mode stored.

This is commonly used on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Reviewed-by: Matthias Brugger 
Reviewed-by: Moritz Fischer 
Tested-by: John Stultz 
Acked-by: John Stultz 
Signed-off-by: Andy Yan 

---

Changes in v6: None
Changes in v5:
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- scan multi properities
- add mask value for some platform which only use some bits of the register
   to store boot mode magic value

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

  drivers/power/reset/Kconfig  |  13 
  drivers/power/reset/Makefile |   2 +
  drivers/power/reset/reboot-mode.c| 106 +++
  drivers/power/reset/reboot-mode.h|   6 ++
  drivers/power/reset/syscon-reboot-mode.c |  65 +++
  5 files changed, 192 insertions(+)
  create mode 100644 drivers/power/reset/reboot-mode.c
  create mode 100644 drivers/power/reset/reboot-mode.h
  create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..cf50630 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -173,5 +173,18 @@ config POWER_RESET_ZX
 help
   Reboot support for ZTE SoCs.

+config REBOOT_MODE
+   tristate
+
+config SYSCON_REBOOT_MODE
+   bool "Generic SYSCON regmap reboot mode driver"
+   depends on OF
+   select REBOOT_MODE
+   help
+ Say y here will enable reboot mode driver. This will
+ get reboot mode arguments and store it in SYSCON mapped
+ register, then the bootloader can read it to take different
+ action according to the mode.
+
  endif

diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 096fa67..a63865b 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
  obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
  obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
  obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
+obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
+obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
new file mode 100644
index 000..9aa7b80
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "reboot-mode.h"
+
+#define PREFIX "mode-"
+
+struct mode_info {
+   char mode[32];
+   unsigned int magic;
+   struct list_head list;
+};
+
+struct reboot_mode_driver {
+   struct list_head head;
+   int (*write)(int magic);
+   struct notifier_block reboot_notifier;
+};
+
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+const char *cmd)
+{
+   const char *normal = "normal";
+   int magic = 0;
+   struct mode_info *info;
+
+   if (!cmd)
+   cmd = normal;
+
+   list_for_each_entry(info, >head, list) {
+   if (!strcmp(info->mode, cmd)) {
+   magic = info->magic;
+   break;
+   }
+   }
+
+   return magic;

In absence of 'normal' mode (it is not described as required property)
the magic will be '0'. It would be nice to document that in bindings.
Imagine someone forgets about this and will wonder why 0x0 is written
to his precious register on normal reboot...

It would be nice to document that 'mode-normal' has a special
(hard-coded) meaning.


+}
+
+static int 

[PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

[Suzuki K Poulose]

From: Steve Capper 

It can be useful for JIT software to be aware of MIDR_EL1 and
REVIDR_EL1 to ascertain the presence of any core errata that could
affect code generation.

This patch exposes these registers through sysfs:

/sys/devices/system/cpu/cpu$ID/identification/midr
/sys/devices/system/cpu/cpu$ID/identification/revidr

where $ID is the cpu number. For big.LITTLE systems, one can have a
mixture of cores (e.g. Cortex A53 and Cortex A57), thus all CPUs need
to be enumerated.

If the kernel does not have valid information to populate these entries
with, an empty string is returned to userspace.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Signed-off-by: Steve Capper 
[ ABI documentation updates, hotplug notifiers ]
Signed-off-by: Suzuki K Poulose 
---
Changes since V5:
  - Add hotplug notifier to {add/remove} the attributes when the CPU is brought
{online/offline}.
  - Replace cpu_hotplug_{disable,enable} => cpu_notifier_register_{begin/done}
  - Remove redundant check for cpu present, as the sysfs infrastructure does
check already returning -ENODEV, if the CPU goes offline between open() and
read().
Changes since V4:
  - Update comment as suggested by Mark Rutland
Changes since V3:
  - Disable cpu hotplug while we initialise
  - Added a comment to explain why expose 64bit value
  - Update Document/ABI/testing/sysfs-devices-system-cpu
Changes since V2:
  - Fix errno for failures (Spotted-by: Russell King)
  - Roll back, if we encounter a missing cpu device
  - Return error for access to registers of CPUs not present.
---
 Documentation/ABI/testing/sysfs-devices-system-cpu |  13 +++
 arch/arm64/include/asm/cpu.h   |   1 +
 arch/arm64/kernel/cpuinfo.c| 106 +
 3 files changed, 120 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 1650133..8c4607d 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -340,3 +340,16 @@ Description:   POWERNV CPUFreq driver's frequency 
throttle stats directory and
'policyX/throttle_stats' directory and all the attributes are 
same as
the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats 
directory and
attributes which give the frequency throttle information of the 
chip.
+
+What:  /sys/devices/system/cpu/cpuX/identification/
+   /sys/devices/system/cpu/cpuX/identification/midr
+   /sys/devices/system/cpu/cpuX/identification/revidr
+Date:  June 2016
+Contact:   Linux ARM Kernel Mailing list 

+   Linux Kernel mailing list 
+Description:   ARM64 CPU identification registers
+   'identification' directory exposes the CPU ID registers for
+identifying model and revision of the CPU.
+   - midr : This file gives contents of Main ID Register 
(MIDR_EL1).
+   - revidr : This file gives contents of the Revision ID register
+(REVIDR_EL1).
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index 13a6103..116a382 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -29,6 +29,7 @@ struct cpuinfo_arm64 {
u32 reg_cntfrq;
u32 reg_dczid;
u32 reg_midr;
+   u32 reg_revidr;
 
u64 reg_id_aa64dfr0;
u64 reg_id_aa64dfr1;
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index c173d32..44ec263 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -212,6 +212,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
info->reg_ctr = read_cpuid_cachetype();
info->reg_dczid = read_cpuid(DCZID_EL0);
info->reg_midr = read_cpuid_id();
+   info->reg_revidr = read_cpuid(REVIDR_EL1);
 
info->reg_id_aa64dfr0 = read_cpuid(ID_AA64DFR0_EL1);
info->reg_id_aa64dfr1 = read_cpuid(ID_AA64DFR1_EL1);
@@ -264,3 +265,108 @@ void __init cpuinfo_store_boot_cpu(void)
boot_cpu_data = *info;
init_cpu_features(_cpu_data);
 }
+
+/*
+ * The ARM ARM uses the phrase "32-bit register" to describe a register
+ * whose upper 32 bits are RES0 (per C5.1.1, ARM DDI 0487A.i), however
+ * no statement is made as to whether the upper 32 bits will or will not
+ * be made use of in future, and between ARM DDI 0487A.c and ARM DDI
+ * 0487A.d CLIDR_EL1 was expanded from 32-bit to 64-bit.
+ *
+ * Thus, while both MIDR_EL1 and REVIDR_EL1 are described as 32-bit
+ * registers, we expose them both as 64 bit values to cater for possible
+ * future 

Re: Using DT overlays for adding virtual hardware

[Pantelis Antoniou]

Hi Jan,

> On Jun 21, 2016, at 14:43 , Jan Kiszka  wrote:
> 
> On 2016-06-21 13:35, Pantelis Antoniou wrote:
>> Hi Jan,
>> 
>>> On Jun 21, 2016, at 14:22 , Jan Kiszka  wrote:
>>> 
>>> On 2016-06-21 12:24, Pantelis Antoniou wrote:
 Hi Jan,
 
> On Jun 21, 2016, at 13:13 , Jan Kiszka  wrote:
> 
> Hi Pantelis,
> 
> coming back to this topic:
> 
> On 2016-06-09 08:03, Jan Kiszka wrote:
>> OK, trial and error, and some interesting insights: I've played with DT
>> fragments and the overlay configfs patch of Pantelis [1] to have a
>> convenient start. Interestingly, I wasn't able to load a fragment that
>> followed the format specification for overlays ("Failed to resolve
>> tree"). By chance, I got this one working:
>> 
>> /dts-v1/;
>> / {
>>  fragment {
>>  target-path = "/soc@01c0";
>>  __overlay__ {
>>  #address-cells = <2>;
>>  #size-cells = <2>;
>> 
>>  vpci@0x200 {
>>  compatible = "pci-host-cam-generic";
>>  device_type = "pci";
>>  #address-cells = <3>;
>>  #size-cells = <2>;
>>  reg = <0 0x200 0 0x100>;
>>  ranges =
>>  <0x0200 0x00 0x1000 0x00 
>> 0x1000 0x00 0x3000>;
>>  };
>>  };
>>  };
>> };
>> 
>> It successfully makes a BananaPi kernel add a pci host with the
>> specified config space and MMIO window.
>> 
>> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
>> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, 
>> using [bus 00-ff]
>> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
>> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
>> 0x0200-0x02ff] for [bus 00-ff]
>> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus 
>> :00
>> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
>> [   81.620814] pci_bus :00: root bus resource [mem 
>> 0x1000-0x3fff]
>> [   81.620851] PCI: bus0: Fast back to back transfers enabled
>> 
>> So, no /plugin/ statement, no phandles resolution. This format even
>> builds with the in-kernel dtc. Any explanations? Does the code make
>> sense (at least it builds without warnings)?
>> 
>> Now I need to back this with some code in Jailhouse.
> 
> Meanwhile I got a virtual PCI device recognized by Linux when running
> over Jailhouse. However, my hack above doesn't get me to proper
> interrupt mapping yet. This is what I was trying with upstream dtc:
> 
> /dts-v1/;
> / {
>   compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
> 
>   fragment@0 {
>   target-path = "/soc@01c0";
>   __overlay__ {
>   #address-cells = <2>;
>   #size-cells = <2>;
> 
>   vpci@200 {
>   compatible = "pci-host-ecam-generic";
>   device_type = "pci";
>   bus-range = <0 0>;
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
>   interrupt-map-mask = <0 0 0 7>;
>   interrupt-map = <0 0 0 1  0 0 0 123 4>,
>   <0 0 0 2  0 0 0 124 4>,
>   <0 0 0 3  0 0 0 125 4>,
>   <0 0 0 4  0 0 0 126 4>;
>   reg = <0 0x200 0 0x10>;
>   ranges =
>   <0x0200 0x00 0x1000 0x00 
> 0x1000 0x00 0x3000>;
>   };
>   };
>   };
> 
>   gic: fragment@1 {
>   target-path = "/soc@01c0/interrupt-controller@01c81000";
>   __overlay__ {
>   };
>   };
> };
> 
 
 ^ This is not going to work: You need the reference to the real gic not 
 the empty fragment
 here that has a target there.
 
 You need to compile with the correct dtc, and you also need to compile the 
 base dts
 with dtc too, using the -@ flag. You can hack around it by adding 
 something like
 
 __symbols__ {
gic = "/soc@01c0/interrupt-controller@01c81000”;
 };
 
 But you really need the __symbols__ node of the base dts generated by the 
 dtc proper cause
 the above is a dirty hack.

[PATCH 01/27] mm, vmstat: Add infrastructure for per-node vmstats

[Mel Gorman]

VM statistic counters for reclaim decisions are zone-based. If the kernel
is to reclaim on a per-node basis then we need to track per-node statistics
but there is no infrastructure for that. The most notable change is that
the old node_page_state is renamed to sum_zone_node_page_state.  The new
node_page_state takes a pglist_data and uses per-node stats but none exist
yet. There is some renaming such as vm_stat to vm_zone_stat and the addition
of vm_node_stat and the renaming of mod_state to mod_zone_state. Otherwise,
this is mostly a mechanical patch with no functional change. There is a
lot of similarity between the node and zone helpers which is unfortunate
but there was no obvious way of reusing the code and maintaining type safety.

Signed-off-by: Mel Gorman 
Acked-by: Johannes Weiner 
Acked-by: Vlastimil Babka 
---
 drivers/base/node.c|  72 +++--
 include/linux/mm.h |   5 +
 include/linux/mmzone.h |  13 +++
 include/linux/vmstat.h |  92 +---
 mm/page_alloc.c|  10 +-
 mm/vmstat.c| 282 +
 mm/workingset.c|   9 +-
 7 files changed, 409 insertions(+), 74 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 560751bad294..efb81da250a8 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -74,16 +74,16 @@ static ssize_t node_read_meminfo(struct device *dev,
   nid, K(i.totalram),
   nid, K(i.freeram),
   nid, K(i.totalram - i.freeram),
-  nid, K(node_page_state(nid, NR_ACTIVE_ANON) +
-   node_page_state(nid, NR_ACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_INACTIVE_ANON) +
-   node_page_state(nid, NR_INACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_ACTIVE_ANON)),
-  nid, K(node_page_state(nid, NR_INACTIVE_ANON)),
-  nid, K(node_page_state(nid, NR_ACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_INACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_UNEVICTABLE)),
-  nid, K(node_page_state(nid, NR_MLOCK)));
+  nid, K(sum_zone_node_page_state(nid, NR_ACTIVE_ANON) +
+   sum_zone_node_page_state(nid, NR_ACTIVE_FILE)),
+  nid, K(sum_zone_node_page_state(nid, NR_INACTIVE_ANON) +
+   sum_zone_node_page_state(nid, 
NR_INACTIVE_FILE)),
+  nid, K(sum_zone_node_page_state(nid, NR_ACTIVE_ANON)),
+  nid, K(sum_zone_node_page_state(nid, NR_INACTIVE_ANON)),
+  nid, K(sum_zone_node_page_state(nid, NR_ACTIVE_FILE)),
+  nid, K(sum_zone_node_page_state(nid, NR_INACTIVE_FILE)),
+  nid, K(sum_zone_node_page_state(nid, NR_UNEVICTABLE)),
+  nid, K(sum_zone_node_page_state(nid, NR_MLOCK)));
 
 #ifdef CONFIG_HIGHMEM
n += sprintf(buf + n,
@@ -115,28 +115,28 @@ static ssize_t node_read_meminfo(struct device *dev,
   "Node %d AnonHugePages:  %8lu kB\n"
 #endif
,
-  nid, K(node_page_state(nid, NR_FILE_DIRTY)),
-  nid, K(node_page_state(nid, NR_WRITEBACK)),
-  nid, K(node_page_state(nid, NR_FILE_PAGES)),
-  nid, K(node_page_state(nid, NR_FILE_MAPPED)),
-  nid, K(node_page_state(nid, NR_ANON_PAGES)),
+  nid, K(sum_zone_node_page_state(nid, NR_FILE_DIRTY)),
+  nid, K(sum_zone_node_page_state(nid, NR_WRITEBACK)),
+  nid, K(sum_zone_node_page_state(nid, NR_FILE_PAGES)),
+  nid, K(sum_zone_node_page_state(nid, NR_FILE_MAPPED)),
+  nid, K(sum_zone_node_page_state(nid, NR_ANON_PAGES)),
   nid, K(i.sharedram),
-  nid, node_page_state(nid, NR_KERNEL_STACK) *
+  nid, sum_zone_node_page_state(nid, NR_KERNEL_STACK) *
THREAD_SIZE / 1024,
-  nid, K(node_page_state(nid, NR_PAGETABLE)),
-  nid, K(node_page_state(nid, NR_UNSTABLE_NFS)),
-  nid, K(node_page_state(nid, NR_BOUNCE)),
-  nid, K(node_page_state(nid, NR_WRITEBACK_TEMP)),
-  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE) +
-   node_page_state(nid, NR_SLAB_UNRECLAIMABLE)),
-  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE)),
+  nid, K(sum_zone_node_page_state(nid, NR_PAGETABLE)),
+  nid, K(sum_zone_node_page_state(nid, NR_UNSTABLE_NFS)),
+  nid, 

Re: [PATCH 3/3] iio: adc: max1363: Add device tree binding

[kbuild test robot]

Hi,

[auto build test WARNING on iio/togreg]
[cannot apply to v4.7-rc4 next-20160621]
[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/Florian-Vaussard/iio-adc-max1363-Fix-missing-parts-and-add-device-tree/20160621-174542
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/iio/adc/max1363.c: In function 'max1363_probe':
>> drivers/iio/adc/max1363.c:1578:11: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
  devid = (int)of_device_get_match_data(>dev);
  ^

vim +1578 drivers/iio/adc/max1363.c

  1562  };
  1563  #endif
  1564  
  1565  static int max1363_probe(struct i2c_client *client,
  1566   const struct i2c_device_id *id)
  1567  {
  1568  int ret;
  1569  struct max1363_state *st;
  1570  struct iio_dev *indio_dev;
  1571  struct regulator *vref;
  1572  unsigned long devid;
  1573  const struct of_device_id *match;
  1574  
  1575  match = of_match_device(of_match_ptr(max1363_of_match),
  1576  >dev);
  1577  if (match)
> 1578  devid = (int)of_device_get_match_data(>dev);
  1579  else
  1580  devid = id->driver_data;
  1581  
  1582  indio_dev = devm_iio_device_alloc(>dev,
  1583sizeof(struct max1363_state));
  1584  if (!indio_dev)
  1585  return -ENOMEM;
  1586  

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


.config.gz
Description: Binary data

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

[Felipe Balbi]

Hi,

Mark Brown  writes:
> [ Unknown signature status ]
> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
>> Baolin Wang  writes:
>> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device 
>> > *pdev)
>> >}
>> >}
>
>> > +  if (wm831x_pdata && wm831x_pdata->usb_gadget) {
>> > +  power->usb_charger =
>> > +  usb_charger_find_by_name(wm831x_pdata->usb_gadget);
>
>> the fact that you rely on strings and pass them via pdata is an
>> indication that you don't have enough description of the HW. Seems like
>> we need to come up with a set of DT properties which tie a charger to a
>> UDC.
>
>> I'm thinking a phandle would be enough?
>
> The wm831x has no DT support currently.

okay, perhaps its time to add it.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: am335x-bone-common: use stdout-path in Beaglebone boards.

[Tony Lindgren]

* Enric Balletbo i Serra  [160617 04:12]:
> This commit adds the stdout-path propety in /chosen for all Beaglebone
> boards.

Applying into omap-for-v4.8/dt thanks.

Tony

Re: [PATCH v10 08/22] IB/hns: Add icm support

[Leon Romanovsky]

On Tue, Jun 21, 2016 at 12:37:39PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/20 21:04, Leon Romanovsky wrote:
> >On Mon, Jun 20, 2016 at 05:48:15PM +0800, Wei Hu (Xavier) wrote:
> >>
> >>On 2016/6/20 17:27, Leon Romanovsky wrote:
> >>>On Mon, Jun 20, 2016 at 03:49:24PM +0800, Wei Hu (Xavier) wrote:
> On 2016/6/20 14:06, Leon Romanovsky wrote:
> >On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:
> >>On 2016/6/17 17:58, Leon Romanovsky wrote:
> >>>On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:
> This patch mainly added icm support for RoCE. It initializes icm
> which managers the relative memory blocks for RoCE. The data
> structures of RoCE will be located in it. For example, CQ table,
> QP table and MTPT table so on.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> >>><...>
> >>>
> +
> >Another question which you didn't answer [1].
> >
> >"I wonder if you have the same needs for ICM as it is in mlx4 device.
> >Do you have firmware?"
> >
> >[1] http://marc.info/?l=linux-rdma=146545553104913=2
> Hi, Leon
>  Now we haven't firmware.
>  But hardware still need memory for QPC\CQC\MTPT\mtt etc.
> >>>ICM stands for InfiniHost (Interconnect) Context Memory is a specific
> >>>memory place to share between host <-> FW and host <-> HW if HW is
> >>>aware of specific structures.
> >>>
> >>>I assume that in your case, it is enough to allocate memory region and
> >>>supply it to HW. Am I right?
> >>For Our hardware,
> >>1. ICM has a memory management method, It's very good for QPC\CQC\MTPT\mtt
> >>etc. we need it.
> >You need special HW to leverage its. AFAIK it is Mellanox specific.
> For our hardware, we use ICM to memory management, the memory shared with
> host and HW.
> QPC\CQC\MTPT\mtt has specific memory requirement.
> QPC\CQC\MTPT need continuous memory. we use ICM to management the block of
> memory. It's very good！

I wasn't convinced why do you need to copy whole ICM logic which is
specific to Mellanox. Your requirements can be implemented by standard CMA
and/or DMA.

> >>2. The meomry for QPC\CQC\MTPT\mtt only used for RoCE hardware and driver,
> >>we don't want use MR.
> >I didn't mean Infiniband MR, but memory region returned from standard
> >allocation functions (kmalloc, ...).
> >
> >>3. Now we haven't firmware, maybe we need it next version.
> >You are always invited to add support once it will be needed, no need to
> >add it in advance.
> >
> >Thanks
> 
> 


signature.asc
Description: Digital signature

Re: [RFC PATCH 00/27] ARM64: support ILP32

[Zhangjian (Bamvor)]

Hi,


In our test, we need to fix stack pointer in makecontext. Not sure
if it should be a standalone patch:

From 1d51ca34034ef83ea602874a93e26fd158ddd214 Mon Sep 17 00:00:00 2001
From: Jun Ji 
Date: Fri, 29 Apr 2016 17:20:23 +0800
Subject: [PATCH] fix for makecontext error

Signed-off-by: Jun Ji 

---
 sysdeps/unix/sysv/linux/aarch64/makecontext.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/aarch64/makecontext.c 
b/sysdeps/unix/sysv/linux/aarch64/makecontext.c
index 34f91a3..55a26a3 100644
--- a/sysdeps/unix/sysv/linux/aarch64/makecontext.c
+++ b/sysdeps/unix/sysv/linux/aarch64/makecontext.c
@@ -42,18 +42,18 @@ void
 __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...)
 {
   extern void __startcontext (void);
-  unsigned long int *sp;
+  unsigned long long *sp;
   va_list ap;
   int i;

-  sp = (unsigned long int *)
+  sp = (unsigned long long *)
 ((uintptr_t) ucp->uc_stack.ss_sp + ucp->uc_stack.ss_size);

   /* Allocate stack arguments.  */
   sp -= argc < 8 ? 0 : argc - 8;

   /* Keep the stack aligned.  */
-  sp = (unsigned long int *) (((uintptr_t) sp) & -16L);
+  sp = (unsigned long long *) (((uintptr_t) sp) & -16L);

   ucp->uc_mcontext.regs[19] = (uintptr_t) ucp->uc_link;
   ucp->uc_mcontext.sp = (uintptr_t) sp;
@@ -64,9 +64,9 @@ __makecontext (ucontext_t *ucp, void (*func) (void), int 
argc, ...)
   va_start (ap, argc);
   for (i = 0; i < argc; ++i)
 if (i < 8)
-  ucp->uc_mcontext.regs[i] = va_arg (ap, unsigned long int);
+  ucp->uc_mcontext.regs[i] = va_arg (ap, unsigned long long);
 else
-  sp[i - 8] = va_arg (ap, unsigned long int);
+  sp[i - 8] = va_arg (ap, unsigned long long);

   va_end (ap);
 }
--
1.8.4.5

Regards

Bamvor

On 2016/6/21 13:06, Yury Norov wrote:

This series enables aarch64 port with ilp32 mode.

After long discussions in kernel list, we finally got
consensus on how ABI should look. This patchset adds
support for the ABI in GLIBC. It is tested with LTP
with no big regressions comparing to LP64 and AARCH32.

Though it's very raw. Please be patient reviewing it.

ABI details:
  - types are taken from AARCH32, next types turned to 64-bit,
as modern requirement for new APIs tells:
ino_t  is  u64 type
off_t  is  s64 type
blkcnt_t   is  s64 type
fsblkcnt_t is  u64 type
fsfilcnt_t is  u64 type
  - 64-bit arguments are passed in syscall as register pair,
as kernel internally clears top halves for all input regs;
  - standard syscall table is used;
  - 32-bit time_t is used. AARCH64/ILP32 is waiting for general
fix of Y2038 problem just like other 32-bit arches;
  - stat{64}, statfs{64} structures are of the identical layout
with LP64. Corresponding syscalls are taken from 64-bit code.

Links:
This series: https://github.com/norov/glibc/commits/ilp32-2.23
Kernel series: https://github.com/norov/linux/commits/ilp32-nowrap
Kernel in LKML: https://lkml.org/lkml/2016/6/17/990

Please review it. Any comments appreciated.

Yury.

Andrew Pinski (24):
   [AARCH64] Fix utmp struct for compatibility reasons.
   [AARCH64] Add header guards to sysdep.h headers.
   Add dynamic ILP32 AARCH64 relocations to elf.h
   [AARCH64] Add PTR_REG, PTR_LOG_SIZE, and PTR_SIZE.  Use it in
 LDST_PCREL and LDST_GLOBAL.
   [AARCH64] Use PTR_REG in crti.S.
   [AARCH64] Use PTR_REG/PTR_SIZE/PTR_SIZE_LOG in dl-tlsesc.S
   [AARCH64] Use PTR_* macros in dl-trampoline.S
   [AARCH64] Use PTR_* in start.S
   [AARCH64] Use PTR_REG in getcontext.S.
   [AARCH64] Detect ILP32 in configure scripts.
   [AARCH64] Syscalls for ILP32 are passed always via 64bit values.
   [AARCH64] Add ILP32 support to elf_machine_load_address.
   [AARCH64] Set up wordsize for ILP32.
   [AARCH64] Add ILP32 to makefiles
   [AARCH64] Add support to ldconfig for ILP32 and libilp32
   [AARCH64] Add ILP32 ld.so to the known interpreter names.
   [AARCH64] Add ldd-rewrite.sed so that ilp32 ld.so can be found
   [AARCH64] Add kernel_sigaction.h for AARCH64 ILP32
   [AARCH64] Add typesizes.h for ILP32
   [AARCH64] Make lp64 and ilp32 directories.
   Add support for AT_ARM64_MIDR.
   [AARCH64] Fix ILP32 warning
   [AARCH64] Change type of __align to long long
   Fix PTRDIFF_MIN/PTRDIFF_MIN and PTRDIFF_MIN for ILP32.

Yury Norov (3):
   [AARCH64] ILP32: introduce syscalls that pass off_t
   [AARCH64] ILP32: support stat syscall family
   [AARCH64] delouse input arguments in system functions

  elf/cache.c|   2 +
  elf/dl-sysdep.c|   1 +
  elf/elf.h  |   3 +
  sysdeps/aarch64/Implies|   6 -
  sysdeps/aarch64/__longjmp.S|   6 +-
  sysdeps/aarch64/bits/wordsize.h|  28 +++
  sysdeps/aarch64/configure  |  15 +-
  sysdeps/aarch64/configure.ac  

Re: [PATCH 4/9] ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6 enable during suspend

[Tony Lindgren]

* Keerthy  [160620 01:46]:
> dcdc3, dcdc5, dcdc6 supply ddr and rtc respectively. These
> are required to be on during suspend. Hence set the state accordingly.

Are these dts changes safe for me to apply separately?

Regards,

Tony

Re: [PATCH 11/27] [AARCH64] Syscalls for ILP32 are passed always via 64bit values.

[Andreas Schwab]

Yury Norov  writes:

> diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h 
> b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> index 1ffabc2..42f89c8 100644
> --- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> +++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> @@ -161,11 +161,11 @@
> call.  */
>  # undef INLINE_SYSCALL
>  # define INLINE_SYSCALL(name, nr, args...)   \
> -  ({ unsigned long _sys_result = INTERNAL_SYSCALL (name, , nr, args);
> \
> +  ({ unsigned long long _sys_result = INTERNAL_SYSCALL (name, , nr, args);   
> \
>   if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (_sys_result, ), 0))\
> { \
>__set_errno (INTERNAL_SYSCALL_ERRNO (_sys_result, ));  \
> -  _sys_result = (unsigned long) -1;  \
> +  _sys_result = (unsigned long long) -1; \
> } \
>   (long) _sys_result; })

The cast should be (long long).

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] memcg: mem_cgroup_migrate() may be called with irq disabled

[Michal Hocko]

On Mon 20-06-16 14:41:58, Tejun Heo wrote:
> Hello,
> 
> Christian, I *think* this should fix it.  Can you please verify?
> 
> Thanks!
> -- 8< --
> mem_cgroup_migrate() uses local_irq_disable/enable() but can be called
> with irq disabled from migrate_page_copy().  This ends up enabling irq
> while holding a irq context lock triggering the following lockdep
> warning.  Fix it by using irq_save/restore instead.
> 
>   =
>   [ INFO: inconsistent lock state ]
>   4.7.0-rc1+ #52 Tainted: GW  
>   -
>   inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
>   kcompactd0/151 [HC0[0]:SC0[0]:HE1:SE1] takes:
>(&(>completion_lock)->rlock){+.?.-.}, at: [<0038fd96>] 
> aio_migratepage+0x156/0x1e8
>   {IN-SOFTIRQ-W} state was registered at:
> [<001a8366>] __lock_acquire+0x5b6/0x1930
> [<001a9b9e>] lock_acquire+0xee/0x270
> [<00951fee>] _raw_spin_lock_irqsave+0x66/0xb0
> [<00390108>] aio_complete+0x98/0x328
> [<0037c7d4>] dio_complete+0xe4/0x1e0
> [<00650e64>] blk_update_request+0xd4/0x450
> [<0072a1a8>] scsi_end_request+0x48/0x1c8
> [<0072d7e2>] scsi_io_completion+0x272/0x698
> [<0065adb2>] blk_done_softirq+0xca/0xe8
> [<00953f80>] __do_softirq+0xc8/0x518
> [<001495de>] irq_exit+0xee/0x110
> [<0010ceba>] do_IRQ+0x6a/0x88
> [<0095342e>] io_int_handler+0x11a/0x25c
> [<0094fb5c>] __mutex_unlock_slowpath+0x144/0x1d8
> [<0094fb58>] __mutex_unlock_slowpath+0x140/0x1d8
> [<003c6114>] kernfs_iop_permission+0x64/0x80
> [<0033ba86>] __inode_permission+0x9e/0xf0
> [<0033ea96>] link_path_walk+0x6e/0x510
> [<0033f09c>] path_lookupat+0xc4/0x1a8
> [<0034195c>] filename_lookup+0x9c/0x160
> [<00341b44>] user_path_at_empty+0x5c/0x70
> [<00335250>] SyS_readlinkat+0x68/0x140
> [<00952f8e>] system_call+0xd6/0x270
>   irq event stamp: 971410
>   hardirqs last  enabled at (971409): [<0030f982>] 
> migrate_page_move_mapping+0x3ea/0x588
>   hardirqs last disabled at (971410): [<00951fc4>] 
> _raw_spin_lock_irqsave+0x3c/0xb0
>   softirqs last  enabled at (970526): [<00954318>] 
> __do_softirq+0x460/0x518
>   softirqs last disabled at (970519): [<001495de>] irq_exit+0xee/0x110
> 
>   other info that might help us debug this:
>Possible unsafe locking scenario:
> 
>CPU0
>
> lock(&(>completion_lock)->rlock);
> 
>   lock(&(>completion_lock)->rlock);
> 
> *** DEADLOCK ***
> 
>   3 locks held by kcompactd0/151:
>#0:  (&(>private_lock)->rlock){+.+.-.}, at: [<0038fc82>] 
> aio_migratepage+0x42/0x1e8
>#1:  (>ring_lock){+.+.+.}, at: [<0038fc9a>] 
> aio_migratepage+0x5a/0x1e8
>#2:  (&(>completion_lock)->rlock){+.?.-.}, at: [<0038fd96>] 
> aio_migratepage+0x156/0x1e8
> 
>   stack backtrace:
>   CPU: 20 PID: 151 Comm: kcompactd0 Tainted: GW   4.7.0-rc1+ #52
>0001c6cbb730 0001c6cbb7c0 0002  
>0001c6cbb860 0001c6cbb7d8 0001c6cbb7d8 00114496 
> 00b517ec 00b680b6 000b 
>0001c6cbb820 0001c6cbb7c0   
>04000184ad18 00114496 0001c6cbb7c0 0001c6cbb820 
>   Call Trace:
>   ([<001143d2>] show_trace+0xea/0xf0)
>   ([<0011444a>] show_stack+0x72/0xf0)
>   ([<00684522>] dump_stack+0x9a/0xd8)
>   ([<0028679c>] print_usage_bug.part.27+0x2d4/0x2e8)
>   ([<001a71ce>] mark_lock+0x17e/0x758)
>   ([<001a784a>] mark_held_locks+0xa2/0xd0)
>   ([<001a79b8>] trace_hardirqs_on_caller+0x140/0x1c0)
>   ([<00326026>] mem_cgroup_migrate+0x266/0x370)
>   ([<0038fdaa>] aio_migratepage+0x16a/0x1e8)
>   ([<00310568>] move_to_new_page+0xb0/0x260)
>   ([<003111b4>] migrate_pages+0x8f4/0x9f0)
>   ([<002c507c>] compact_zone+0x4dc/0xdc8)
>   ([<002c5e22>] kcompactd_do_work+0x1aa/0x358)
>   ([<002c608a>] kcompactd+0xba/0x2c8)
>   ([<0016b09a>] kthread+0x10a/0x110)
>   ([<0095315a>] kernel_thread_starter+0x6/0xc)
>   ([<00953154>] kernel_thread_starter+0x0/0xc)
>   INFO: lockdep is turned off.
> 
> Signed-off-by: Tejun Heo 
> Reported-by: Christian Borntraeger 
> Link: http://lkml.kernel.org/g/5767cfe5.7080...@de.ibm.com

Acked-by: Michal Hocko 

> ---
>  mm/memcontrol.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 75e7440..d4a33e1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5544,6 +5544,7 @@ void mem_cgroup_migrate(struct page 

Re: [RFC][PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

[Arnd Bergmann]

On Tuesday, June 21, 2016 2:39:05 PM CEST Seung-Woo Kim wrote:
> To enable UBSAN on arm, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL
> from arm confiuration. Basic kernel booting is tested on arm kernel
> enabled CONFIG_UBSAN_SANITIZE_ALL from Exynos5422 based Odroid-XU3
> board.
> 
> Signed-off-by: Seung-Woo Kim 
> ---
> Because I tested only with specific soc board, so I am not sure the ubsan is
> fine for all other cases. So, I send this patch as a RFC.
> 

I've tried this out on my build test box in the past, but ran into
some problems. In particular I ended up disabling 
-fsanitize=signed-integer-overflow and -fsanitize=object-size
and later reverting the whole thing, but don't remember exactly
why (possibly I was hitting internal compiler errors?).'

Let me re-enable it with your patch locally and report back
with whatever build problems I run into.

Arnd

Re: [PATCH 04/27] [AARCH64] Add PTR_REG, PTR_LOG_SIZE, and PTR_SIZE. Use it in LDST_PCREL and LDST_GLOBAL.

[Andreas Schwab]

Yury Norov  writes:

> diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h
> index 4cb028f..f2ea821 100644
> --- a/sysdeps/aarch64/sysdep.h
> +++ b/sysdeps/aarch64/sysdep.h
> @@ -23,10 +23,16 @@
>  
>  #ifdef __LP64__
>  #define AARCH64_R(NAME)  R_AARCH64_ ## NAME
> +#define PTR_REG(n)   x##n
> +#define PTR_LOG_SIZE 3
>  #else
>  #define AARCH64_R(NAME)  R_AARCH64_P32_ ## NAME
> +#define PTR_REG(n)   w##n
> +#define PTR_LOG_SIZE 2
>  #endif
>  
> +#define PTR_SIZE (1< +
>  #ifdef   __ASSEMBLER__
>  
>  /* Syntactic details of assembler.  */
> @@ -87,16 +93,18 @@
>  # define L(name) .L##name
>  #endif
>  
> -/* Load or store to/from a pc-relative EXPR into/from R, using T.  */
> -#define LDST_PCREL(OP, R, T, EXPR)  \
> - adrpT, EXPR;\
> - OP  R, [T, #:lo12:EXPR];\
> -
> -/* Load or store to/from a got-relative EXPR into/from R, using T.  */
> -#define LDST_GLOBAL(OP, R, T, EXPR) \
> - adrpT, :got:EXPR;   \
> - ldr T, [T, #:got_lo12:EXPR];\
> - OP  R, [T];
> +/* Load or store to/from a pc-relative EXPR into/from R, using T.
> +   Note R and T are register numbers and not register names.  */
> +#define LDST_PCREL(OP, R, T, EXPR)   \
> + adrpx##T, EXPR; \
> + OP  PTR_REG (R), [x##T, #:lo12:EXPR];   \
> +
> +/* Load or store to/from a got-relative EXPR into/from R, using T.
> +   Note R and T are register numbers and not register names.  */
> +#define LDST_GLOBAL(OP, R, T,  EXPR) \
> + adrpx##T, :got:EXPR;\
> + ldr PTR_REG (T), [x##T, #:got_lo12:EXPR];   \
> + OP  x##R, [x##T];

I think this needs to be PTR_REG(x).

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."