[PATCH v2 1/2] scsi: lpfc: Use kzalloc instead of kmalloc

[Punit Vara]

This patch is to the lpfc_els.c which resolves following warning
reported by coccicheck:

WARNING: kzalloc should be used for rdp_context, instead of
kmalloc/memset

Signed-off-by: Punit Vara 
---
 drivers/scsi/lpfc/lpfc_els.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 36bf58b..9729ab1 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -4990,13 +4990,12 @@ lpfc_els_rcv_rdp(struct lpfc_vport *vport, struct 
lpfc_iocbq *cmdiocb,
if (RDP_NPORT_ID_SIZE !=
be32_to_cpu(rdp_req->nport_id_desc.length))
goto rjt_logerr;
-   rdp_context = kmalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
+   rdp_context = kzalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
if (!rdp_context) {
rjt_err = LSRJT_UNABLE_TPC;
goto error;
}
 
-   memset(rdp_context, 0, sizeof(struct lpfc_rdp_context));
cmd = &cmdiocb->iocb;
rdp_context->ndlp = lpfc_nlp_get(ndlp);
rdp_context->ox_id = cmd->unsli3.rcvsli3.ox_id;
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet

[Maxime Ripard]

Hi,

On Fri, Oct 23, 2015 at 11:56:35PM +0800, Chen-Yu Tsai wrote:
> >> as described in
> >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> >> here, as the display is in portrait mode while the touchscreen is
> >> in landscape mode and needs to have the x and y axes swapped to
> >> work in the same coordinate system as the display.
> >>
> >> Regarding the driver side: the goodix driver in kernel 4.3
> >> doesn't yet support this property, but patches to add support for
> >> it are on the linux-input list and should hopefully make it into
> >> kernel 4.4.
> >
> > The DTS is already in Maxime's tree, and in sunxi-next. Feel free to
> > send a follow-up patch adding them. I was waiting for those patches
> > to be merged.
> 
> Sorry, spoke too soon. Maxime hasn't pushed it out yet. Could you send
> a patch adding touchscreen-swapped-x-y for Maxime to squash in?

I did the last DT pull request for 4.4 yesterday, so I won't squash
any patches.

Maxime

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


signature.asc
Description: Digital signature

Re: [PATCH v2 4/4] Staging: rtl8712: fix warning for placing constant on the right side of test

[punit vara]

On Fri, Oct 23, 2015 at 2:04 AM, Dan Carpenter  wrote:
> First fetch the changes, then check them out.
>
> $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-next
> $ git checkout FETCH_HEAD
>
> regards,
> dan carpenter
>
Thank you very much Dan.
Problem is solved :-)

@Greg I haven't found any warnings in your tree .You might applied
this patch before. So I am forward to create other patches
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Maxime Ripard]

On Fri, Oct 23, 2015 at 09:20:13PM +0200, Jean-Francois Moine wrote:
> On Fri, 23 Oct 2015 20:14:06 +0200
> Maxime Ripard  wrote:
> 
> > On Wed, Oct 21, 2015 at 06:20:27PM +0200, Jens Kuske wrote:
> > > + bus_gates: clk@01c20060 {
> > > + #clock-cells = <1>;
> > > + compatible = "allwinner,sun8i-h3-bus-gates-clk";
> > > + reg = <0x01c20060 0x14>;
> > > + clock-indices = <5>, <6>, <8>,
> > > + <9>, <10>, <13>,
> > > + <14>, <17>, <18>,
> > > + <19>, <20>,
> > > + <21>, <23>,
> > > + <24>, <25>,
> > > + <26>, <27>,
> > > + <28>, <29>,
> > > + <30>, <31>, <32>,
> > > + <35>, <36>, <37>,
> > > + <40>, <41>, <43>,
> > > + <44>, <52>, <53>,
> > > + <54>, <64>,
> > > + <65>, <69>, <72>,
> > > + <76>, <77>, <78>,
> > > + <96>, <97>, <98>,
> > > + <112>, <113>,
> > > + <114>, <115>, <116>,
> > > + <128>, <135>;
> > > + clocks = <&ahb1>, <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb2>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb2>,
> > > +  <&ahb2>, <&ahb2>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&ahb1>, <&ahb1>,
> > > +  <&ahb1>, <&apb1>,
> > > +  <&apb1>, <&apb1>, <&apb1>,
> > > +  <&apb1>, <&apb1>, <&apb1>,
> > > +  <&apb2>, <&apb2>, <&apb2>,
> > > +  <&apb2>, <&apb2>,
> > > +  <&apb2>, <&apb2>, <&apb2>,
> > > +  <&ahb1>, <&ahb1>;  
> > 
> > This is not really what I had in mind...
> > 
> > This IP has 2 parents, and only two parents. The mapping between the
> > IPs should be done in the driver itself, not in the DT where it is
> > very error prone and barely readable.
> > 
> > And note that I never have expected you to use clk-simple-gates
> > either. This is a complicated clock, unlike the other we've seen so
> > far, it definitely deserves a driver of its own.
> 
> It seems that Allwinner puts the gate definitions anywhere in the array
> of registers, so, I think that the H3 scheme will not be the last
> complicated one,

Maybe, but that's the first one. It doesn't prevent us from reusing
the driver later if it happens.

> and if the parent clocks are in the code instead of in the DT, we
> will have more and more code to develop.

I never asked that either.

> An other way to describe the gates would be to add containers per parent
> (with still a small patch in the clk-simple-gates):
> 
>   bus_gates: clk@01c20060 {
>   #clock-cells = <1>;
>   compatible = "allwinner,sun8i-h3-bus-gates-clk";
>   reg = <0x01c20060 0x14>;
>   ahb1_gates {
>   clocks = <&ahb1>;
>   clock-indices = <5>, <6>, <8>,
>   <9>, <10>, <13>,
>   <14>, <18>,
>   <19>, <20>,
>   ...;
>   };
>   clock-output-names = "ahb1_ce", "ahb1_dma", "ahb1_mmc0",
>   "ahb1_mmc1", "ahb1_mmc2", "ahb1_nand",
>   "ahb1_sdram", "ahb1_ts",
>   "ahb1_hstimer", "ahb1_spi0",
>   ...;
>   };
>   ahb2_gates {
>   clocks = <&ahb2>;
>   clock-indices = <17>, <29>,
>   <30>, <31>, <32>,
>   ...;
>   clock-output-names = "ahb2_gmac", "ahb2_ohic1",
>   "ahb2_ohic2", "ahb2_ohic3", "ahb1_ve",
>   ...;
>   };
>   apb1_gates {
>   ...
>   };
>   apb2_gates {
>   ...
>   };
>   };

Or simply

bus_gates {
 

[PATCH] lustre: obdclass: fix sparse warning

[Paul Davies C]

This patch fixes the following warnings given by the sparse:

drivers/staging/lustre/lustre/obdclass/linux/linux-module.c:424:5: warning: 
symbol 'class_procfs_init' was not declared. Should it be static?
drivers/staging/lustre/lustre/obdclass/linux/linux-module.c:460:5: warning: 
symbol 'class_procfs_clean' was not declared. Should it be static?
drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c:161:5: warning: 
symbol 'obd_sysctl_init' was not declared. Should it be static?
drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c:166:6: warning: 
symbol 'obd_sysctl_clean' was not declared. Should it be static?

Signed-off-by: Paul Davies C 
---
 drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 4 ++--
 drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c 
b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 6218ef3..45d92c2 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -421,7 +421,7 @@ static struct attribute_group lustre_attr_group = {
.attrs = lustre_attrs,
 };
 
-int class_procfs_init(void)
+static int class_procfs_init(void)
 {
int rc = -ENOMEM;
struct dentry *file;
@@ -457,7 +457,7 @@ out:
return rc;
 }
 
-int class_procfs_clean(void)
+static int class_procfs_clean(void)
 {
if (debugfs_lustre_root != NULL)
debugfs_remove_recursive(debugfs_lustre_root);
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c 
b/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
index 1515163..6f13f21 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
@@ -158,11 +158,11 @@ static struct attribute_group lustre_attr_group = {
.attrs = lustre_attrs,
 };
 
-int obd_sysctl_init(void)
+static int obd_sysctl_init(void)
 {
return sysfs_create_group(lustre_kobj, &lustre_attr_group);
 }
 
-void obd_sysctl_clean(void)
+static void obd_sysctl_clean(void)
 {
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 7/8] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

[Hanjun Guo]

Hi Suravee,

Some minor comments  below:

On 2015/10/21 23:52, Suravee Suthikulpanit wrote:
[...]
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index eea8b42..09264f8 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -6,12 +6,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 

Seems it's needed for GICv2m patch but not this one?

>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 

I think acpi.h should be introduced by the next patch.

> +#include 

And property.h is also not needed for this patch set.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 8/8] PCI: ACPI: Add support for PCI device DMA coherency

[Hanjun Guo]

On 2015/10/21 23:52, Suravee Suthikulpanit wrote:
> This patch adds support for setting up PCI device DMA coherency from
> ACPI _CCA object that should normally be specified in the DSDT node
> of its PCI host bridge.
>
> Signed-off-by: Suravee Suthikulpanit 
> CC: Bjorn Helgaas 
> CC: Catalin Marinas 
> CC: Rob Herring 
> CC: Will Deacon 
> CC: Rafael J. Wysocki 
> CC: Murali Karicheri 
> ---
>  drivers/pci/probe.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 09264f8..6e9f7e6 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1642,17 +1642,26 @@ static void pci_set_msi_domain(struct pci_dev *dev)
>   * @dev: ptr to pci_dev struct of the PCI device
>   *
>   * Function to update PCI devices's DMA configuration using the same
> - * info from the OF node of host bridge's parent (if any).
> + * info from the OF node or ACPI node of host bridge's parent (if any).
>   */
>  static void pci_dma_configure(struct pci_dev *dev)
>  {
>   struct device *bridge = pci_get_host_bridge_device(dev);
>  
>   if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node) {
> - if (!bridge->parent)
> - return;
> -
> - of_dma_configure(&dev->dev, bridge->parent->of_node);
> + if (bridge->parent)
> + of_dma_configure(&dev->dev,
> +  bridge->parent->of_node);
> + } else if (has_acpi_companion(bridge)) {
> + struct acpi_device *adev = to_acpi_node(bridge->fwnode);

It's to_acpi_device_node() now in Rafael's tree.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 0/8] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute

[Hanjun Guo]

On 2015/10/21 23:52, Suravee Suthikulpanit wrote:
> This patch series adds support to setup DMA coherency for PCI device using
> the ACPI _CCA attribute. According to the ACPI spec, the _CCA attribute
> is required for ARM64. Therefore, this patch is a pre-req for ACPI PCI
> support for ARM64 which is currently in development.  Also, this should
> not affect other architectures that does not define 
> CONFIG_ACPI_CCA_REQUIRED, since the default value is coherent.
>
> In the process, this series also introduces enum dev_dma_attr and a set
> of APIs to query device DMA attribute. These APIs replace the obsolete
> device_dma_is_coherent(), and acpi_check_dma().
>
> I have also included a patch from Jeremy posted here:
> http://www.spinics.net/lists/linux-usb/msg128582.html
>
> This patch series  has been tested on AMD Seattle RevB platform.
> The git tree containing tested code and pre-req patches are posted here:
>
> http://github.com/ssuthiku/linux.git pci-cca-v4
>
> Changes from V3: (https://lkml.org/lkml/2015/8/26/389)
> * Clean up suggested by Bjorn
> * Introduce enum dev_dma_attr
> * Replace device_dma_is_coherent() and acpi_check_dma() with
>   new APIs.
>
> Changes from V2: (https://lkml.org/lkml/2015/8/25/549)
> * Return -ENOSUPP instead of -1 (per Rafael's suggestion)
> * Add WARN() when fail to setup DMA for PCI device when booting
>   ACPI (per Arnd's suggestion)
> * Added Acked-by from Rob.
> * Minor clean up
>
> Changes from V1: (https://lkml.org/lkml/2015/8/13/182)
> * Include patch 1 from Jeremy to enable support for _CCA=0
> * Clean up acpi_check_dma() per Bjorn suggestions
> * Split the original V1 patch into two patches (patch 3 and 4)
>
> Jeremy Linton (1):
>   Honor ACPI _CCA attribute setting
>
> Suravee Suthikulpanit (7):
>   device property: Introducing enum dev_dma_attr
>   acpi: Adding DMA Attribute APIs for ACPI Device
>   device property: Adding DMA Attribute APIs for Generic Devices
>   device property: acpi: Make use of the new DMA Attribute APIs
>   device property: acpi: Remove unused DMA APIs
>   PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()
>   PCI: ACPI: Add support for PCI device DMA coherency

If the minor comments for patch 7,8 are addressed,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Hans de Goede]

Hi,

On 10/23/2015 08:14 PM, Maxime Ripard wrote:

On Wed, Oct 21, 2015 at 06:20:27PM +0200, Jens Kuske wrote:

+   bus_gates: clk@01c20060 {
+   #clock-cells = <1>;
+   compatible = "allwinner,sun8i-h3-bus-gates-clk";
+   reg = <0x01c20060 0x14>;
+   clock-indices = <5>, <6>, <8>,
+   <9>, <10>, <13>,
+   <14>, <17>, <18>,
+   <19>, <20>,
+   <21>, <23>,
+   <24>, <25>,
+   <26>, <27>,
+   <28>, <29>,
+   <30>, <31>, <32>,
+   <35>, <36>, <37>,
+   <40>, <41>, <43>,
+   <44>, <52>, <53>,
+   <54>, <64>,
+   <65>, <69>, <72>,
+   <76>, <77>, <78>,
+   <96>, <97>, <98>,
+   <112>, <113>,
+   <114>, <115>, <116>,
+   <128>, <135>;
+   clocks = <&ahb1>, <&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb2>, <&ahb1>,
+<&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb2>,
+<&ahb2>, <&ahb2>, <&ahb1>,
+<&ahb1>, <&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>, <&ahb1>,
+<&ahb1>, <&ahb1>, <&ahb1>,
+<&ahb1>, <&apb1>,
+<&apb1>, <&apb1>, <&apb1>,
+<&apb1>, <&apb1>, <&apb1>,
+<&apb2>, <&apb2>, <&apb2>,
+<&apb2>, <&apb2>,
+<&apb2>, <&apb2>, <&apb2>,
+<&ahb1>, <&ahb1>;


This is not really what I had in mind...


I came to the same solution independently, I took my inspiration from
the rockchip clocks driver which is dealing with this problem in the
same way, so there is precedent for doing things this way, and this
does give us lot of flexibility. Given that I expect other new allwinnner
SoCs to have the same problem I believe it is good to have that
flexibility.


This IP has 2 parents, and only two parents.


Nope it has 4: apb1, apb2, ahb1 and ahb2.


The mapping between the
IPs should be done in the driver itself, not in the DT where it is
very error prone and barely readable.


It is just as error prone and barely readable in C-code, see Jens original
patchset, he did an array of clock indices there (range 0-3 with an index
into the parent clocks array), which is arguably even more unreadable since
there is an extra level of indirection here.

The problem with the unreadability simply comes from allwinner's decision
to no longer have a gates register per bus but instead shove everything
in a single bit-array in random order, there is nothing we can do to fix
that.

Also the argument "this belongs in the driver not in the DT" is a bit
inconsistent with the moving of the mask of valid gates from the
driver into the clock-indices in devicetree. The way things are done
here actually are doing pretty much the same thing, putting info which
could be derived from the compatible string into devicetree.

Last as said already there is precedent for doing things this way
in the rockchip driver, and given that 2 people have come up
with this approach independently of of each other this clearly
seems to be the most straight-foward / logical way to deal with
this.


And note that I never have expected you to use clk-simple-gates
either. This is a complicated clock


No it is not complicated, have you looked at the changes to the
simple-clk-gates driver which Jean Francois Moine suggested?

Those 5 extra lines (4 new lines) are all that is needed when
going with the approach of listing a parent per gate. This is
actually still a quite simple clock, we only need to find a way
to specify a parent per gate, preferably via DT since this gives
us greater flexibility which will be quite useful when adding
support for other SoCs.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] VFIO: platform: reset: AMD xgbe reset module

[kbuild test robot]

Hi Eric,

[auto build test ERROR on asm-generic/master -- if it's inappropriate base, 
please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Eric-Auger/VFIO-platform-reset-AMD-xgbe-reset-module/20151024-000245
config: arm-allyesconfig (attached as .config)
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=arm 

All errors (new ones prefixed by >>):

>> drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:27: error: expected 
>> declaration specifiers or '...' before string constant
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
>> drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:51: error: expected 
>> declaration specifiers or '...' before 'vfio_platform_amdxgbe_reset'
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
--
>> /kbuild/src/defs/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:27: 
>> error: expected declaration specifiers or '...' before string constant
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
>> /kbuild/src/defs/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:51: 
>> error: expected declaration specifiers or '...' before 
>> 'vfio_platform_amdxgbe_reset'
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^

vim +122 drivers/vfio/platform/reset/vfio_platform_amdxgbe.c

   116  if (!count)
   117  pr_warn("%s MAC SW reset failed\n", __func__);
   118  
   119  return 0;
   120  }
   121  
 > 122  module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
 > vfio_platform_amdxgbe_reset);
   123  
   124  MODULE_VERSION("0.1");
   125  MODULE_LICENSE("GPL v2");

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


.config.gz
Description: Binary data

Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jean-Francois Moine]

On Sat, 24 Oct 2015 09:13:28 +0200
Maxime Ripard  wrote:

> Or simply
> 
> bus_gates {
>   clocks = <&ahb1>, <&ahb2>;
>   clock-indices = <5>, <6>, <8>, ...
>   clock-output-names = "bus_ce", "bus_dma", "bus_mmc0"
> };

I don't understand: the apb1, apb2, ahb1 and ahb2 clocks may be
programmed independently to different frequencies and you have to know
which of them is the parent of each leaf clock.

So, either you hard-code the parents as Jens did in a first proposal,
or you define the full list of parents in the DT as in the last
proposal, or you use a container per parent in the DT as I proposed.

There could be an other solution using the output clock name to define
the parent clock:

bus_gates {
clocks = <&ahb1>, <&ahb2>, <&apb1>, <&apb2>;
clock-indices = <5>, <6>, <8>, ...
clock-output-names = "ahb1_ce", "ahb1_dma", "ahb1_mmc0"
};

with the documentation:

"the clocks MUST be defined in order: ahb1, ahb2, apb1, apb2."

and the code

if (strncmp(clock_name, "ahb1", 4) == 0)
clk_parent = of_clk_get_parent_name(node, 0);
else if (..)

but it seems a bit hacky.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Matt Ranostay]

Tested-by: Matt Ranostay 

On Fri, Oct 23, 2015 at 5:32 AM, Daniel Baluta  wrote:
> This patch registers a new IIO software trigger interrupt source
> based on high resolution timers.
>
> Notice that if configfs is enabled we create sampling_frequency
> attribute allowing users to change hrtimer period (1/sampling_frequency).
>
> The IIO hrtimer trigger has a long history, this patch is based on
> an older version from Marten and Lars-Peter.
>
> Signed-off-by: Marten Svanfeldt 
> Signed-off-by: Lars-Peter Clausen 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/trigger/Kconfig|  10 ++
>  drivers/iio/trigger/Makefile   |   2 +
>  drivers/iio/trigger/iio-trig-hrtimer.c | 193 
> +
>  3 files changed, 205 insertions(+)
>  create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
>
> diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
> index 7999612..519e677 100644
> --- a/drivers/iio/trigger/Kconfig
> +++ b/drivers/iio/trigger/Kconfig
> @@ -5,6 +5,16 @@
>
>  menu "Triggers - standalone"
>
> +config IIO_HRTIMER_TRIGGER
> +   tristate "High resolution timer trigger"
> +   depends on IIO_SW_TRIGGER
> +   help
> + Provides a frequency based IIO trigger using high resolution
> + timers as interrupt source.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called iio-trig-hrtimer.
> +
>  config IIO_INTERRUPT_TRIGGER
> tristate "Generic interrupt trigger"
> help
> diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
> index 0694dae..fe06eb5 100644
> --- a/drivers/iio/trigger/Makefile
> +++ b/drivers/iio/trigger/Makefile
> @@ -3,5 +3,7 @@
>  #
>
>  # When adding new entries keep the list in alphabetical order
> +
> +obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
>  obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
>  obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
> diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c 
> b/drivers/iio/trigger/iio-trig-hrtimer.c
> new file mode 100644
> index 000..5e6d451
> --- /dev/null
> +++ b/drivers/iio/trigger/iio-trig-hrtimer.c
> @@ -0,0 +1,193 @@
> +/**
> + * The industrial I/O periodic hrtimer trigger driver
> + *
> + * Copyright (C) Intuitive Aerial AB
> + * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
> + * Copyright (C) 2012, Analog Device Inc.
> + * Author: Lars-Peter Clausen 
> + * Copyright (C) 2015, Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* default sampling frequency - 100Hz */
> +#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
> +
> +struct iio_hrtimer_info {
> +   struct iio_sw_trigger swt;
> +   struct hrtimer timer;
> +   unsigned long sampling_frequency;
> +   ktime_t period;
> +};
> +
> +static struct config_item_type iio_hrtimer_type = {
> +   .ct_owner = THIS_MODULE,
> +};
> +
> +static
> +ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> +   struct iio_trigger *trig = to_iio_trigger(dev);
> +   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
> +
> +   return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
> +}
> +
> +static
> +ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t len)
> +{
> +   struct iio_trigger *trig = to_iio_trigger(dev);
> +   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
> +   unsigned long val;
> +   int ret;
> +
> +   ret = kstrtoul(buf, 10, &val);
> +   if (ret)
> +   return ret;
> +
> +   if (!val || val > NSEC_PER_SEC)
> +   return -EINVAL;
> +
> +   info->sampling_frequency = val;
> +   info->period = ktime_set(0, NSEC_PER_SEC / val);
> +
> +   return len;
> +}
> +
> +static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
> +  iio_hrtimer_show_sampling_frequency,
> +  iio_hrtimer_store_sampling_frequency);
> +
> +static struct attribute *iio_hrtimer_attrs[] = {
> +   &dev_attr_sampling_frequency.attr,
> +   NULL
> +};
> +
> +static const struct attribute_group iio_hrtimer_attr_group = {
> +   .attrs = iio_hrtimer_attrs,
> +};
> +
> +static const struct attribute_group *iio_hrtimer_attr_groups[] = {
> +   &iio_hrtimer_attr_group,
> +   NULL
> +};
> +
> +static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)

Re: [PATCH v10 2/5] iio: core: Introduce IIO configfs support

[Matt Ranostay]

Tested-by: Matt Ranostay 

On Fri, Oct 23, 2015 at 8:33 AM, Daniel Baluta  wrote:
> This patch creates the IIO configfs root group. The group
> will appear under /iio/, usually /config/iio.
>
> We introduce configfs support in IIO in order to be able to easily
> create IIO objects from userspace. The first supported IIO objects
> are triggers introduced with next patches.
>
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/Kconfig |  8 ++
>  drivers/iio/Makefile|  1 +
>  drivers/iio/industrialio-configfs.c | 50 
> +
>  3 files changed, 59 insertions(+)
>  create mode 100644 drivers/iio/industrialio-configfs.c
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 66792e7..d0f1ddb 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -22,6 +22,14 @@ if IIO_BUFFER
> source "drivers/iio/buffer/Kconfig"
>  endif # IIO_BUFFER
>
> +config IIO_CONFIGFS
> +   tristate "Enable IIO configuration via configfs"
> +   select CONFIGFS_FS
> +   help
> + This allows configuring various IIO bits through configfs
> + (e.g. software triggers). For more info see
> + Documentation/iio/iio_configfs.txt.
> +
>  config IIO_TRIGGER
> bool "Enable triggered sampling support"
> help
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index aeca726..4e8ac82 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -7,6 +7,7 @@ industrialio-y := industrialio-core.o industrialio-event.o 
> inkern.o
>  industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
>  industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
>
> +obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
>  obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
>
>  obj-y += accel/
> diff --git a/drivers/iio/industrialio-configfs.c 
> b/drivers/iio/industrialio-configfs.c
> new file mode 100644
> index 000..83563dd
> --- /dev/null
> +++ b/drivers/iio/industrialio-configfs.c
> @@ -0,0 +1,50 @@
> +/*
> + * Industrial I/O configfs bits
> + *
> + * Copyright (c) 2015 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static struct config_item_type iio_root_group_type = {
> +   .ct_owner   = THIS_MODULE,
> +};
> +
> +struct configfs_subsystem iio_configfs_subsys = {
> +   .su_group = {
> +   .cg_item = {
> +   .ci_namebuf = "iio",
> +   .ci_type = &iio_root_group_type,
> +   },
> +   },
> +   .su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
> +};
> +EXPORT_SYMBOL(iio_configfs_subsys);
> +
> +static int __init iio_configfs_init(void)
> +{
> +   config_group_init(&iio_configfs_subsys.su_group);
> +
> +   return configfs_register_subsystem(&iio_configfs_subsys);
> +}
> +module_init(iio_configfs_init);
> +
> +static void __exit iio_configfs_exit(void)
> +{
> +   configfs_unregister_subsystem(&iio_configfs_subsys);
> +}
> +module_exit(iio_configfs_exit);
> +
> +MODULE_AUTHOR("Daniel Baluta ");
> +MODULE_DESCRIPTION("Industrial I/O configfs support");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v8 06/14] task_isolation: provide strict mode configurable signal

[Gilad Ben Yossef]

Hi Andy,

Thank for the feedback.


> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Wednesday, October 21, 2015 9:53 PM
> To: Gilad Ben Yossef
> Cc: Chris Metcalf; Steven Rostedt; Ingo Molnar; Peter Zijlstra; Andrew
> Morton; Rik van Riel; Tejun Heo; Frederic Weisbecker; Thomas Gleixner; Paul
> E. McKenney; Christoph Lameter; Viresh Kumar; Catalin Marinas; Will Deacon;
> linux-...@vger.kernel.org; Linux API; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v8 06/14] task_isolation: provide strict mode
> configurable signal
> 


> >> >> On Tue, 20 Oct 2015 16:36:04 -0400
> >> >> Chris Metcalf  wrote:
> >> >>
> >> >>> Allow userspace to override the default SIGKILL delivered
> >> >>> when a task_isolation process in STRICT mode does a syscall
> >> >>> or otherwise synchronously enters the kernel.
> >> >>>
> > 
> >> >
> >> > It doesn't map SIGKILL to some other signal unconditionally.  It just 
> >> > allows
> >> > the "hey, you broke the STRICT contract and entered the kernel" signal
> >> > to be something besides the default SIGKILL.
> >> >
> >>
> >
> > 
> >>
> >> I still dislike this thing.  It seems like a debugging feature being
> >> implemented using signals instead of existing APIs.  I *still* don't
> >> see why perf can't be used to accomplish your goal.
> >>
> >
> > It is not (just) a debugging feature. There are workloads were not
> performing an action is much preferred to being late.
> >
> > Consider the following artificial but representative scenario: a task 
> > running
> in strict isolation is controlling a radiotherapy alpha emitter.
> > The code runs in a tight event loop, reading an MMIO register with location
> data, making some calculation and in response writing an
> > MMIO register that triggers the alpha emitter. As a safety measure, each
> trigger is for a specific very short time frame - the alpha emitter
> > auto stops.
> >
> > The code has a strict assumption that no more than X cycles pass between
> reading the value and the response and the system is built in
> > such a way that as long as the code has mastery of the CPU the assumption
> holds true. If something breaks this assumption (unplanned
> > context switch to kernel), what you want to do is just stop place
> > rather than fire the alpha emitter X nanoseconds too late.
> >
> > This feature lets you say: if the "contract" of isolation is broken, 
> > notify/kill
> me at once.
> 
> That's a fair point.  It's risky, though, for quite a few reasons.
> 
> 1. If someone builds an alpha emitter like this, they did it wrong.
> The kernel should write a trigger *and* a timestamp to the hardware
> and the hardware should trigger at the specified time if the time is
> in the future and throw an error if it's in the past.  If you need to
> check that you made the deadline, check the actual desired condition
> (did you meat the deadline?) not a proxy (did the signal fire?).
> 

As I wrote above it is an *artificial* scenario. 

Yes, hardware and systems can be designed better, but they are not
always are and in these kind of systems, you really do want to have
double or triple checks.

Knowing such systems, even IF the hardware was designed as you 
specified (and I agree it should!) you would still add the software
protection.

> 2. This strict mode thing isn't exhaustive.  It's missing, at least,
> coverage for NMI, MCE, and SMI.  Sure, you can think that you've
> disabled all NMI sources, you can try to remember to set the
> appropriate boot flag that panics on MCE (and hope that you don't get
> screwed by broadcast MCE on Intel systems before it got fixed
> (Skylake?  Is the fix even available in a released chip?), and, for
> SMI, good luck...

You are right - it isn't exhaustive. It is one piece in a bigger puzzle.
Many of the other bits are platform specific and some of them have
been dealt with on the platform that care about these things.

Yes, we don't have dark magic to detect SMIs. Is that a reason to penalize
platforms where there is no such thing as SMI? 
 
 
> 3. You haven't dealt with IPIs.  The TLB flush code in particular
> seems like it will break all your assumptions.
>

But we have - in the general context. Consider this patch set from 2012 -
https://lwn.net/Articles/479510/

Not finished for sure. But what we have is now useful enough that it is used
in the real world for different workloads on different platforms, from packet
 processing, through HPC to high frequency trading.

> Maybe it would make sense to whack more of the moles before adding a
> big assertion that there aren't any moles any more.
> 

hm... maybe you are reading too much into this specific feature - its a 
"notify me, the application, if I asked you to do something that violates 
my previous request to be isolated", rather than "notify me whenever isolation 
is broken".

Does that make more sense?

Thanks,
Gilad--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke

Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet

[Siarhei Siamashka]

Hello,

On Fri, 23 Oct 2015 23:46:59 +0800
Chen-Yu Tsai  wrote:

> On Fri, Oct 23, 2015 at 10:53 PM, Karsten Merker  wrote:
> > On Fri, Oct 23, 2015 at 11:50:41AM +0800, Chen-Yu Tsai wrote:
> >
> >> From: Karsten Merker 
> >>
> >> The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
> >> 768x1024 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
> >> rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
> >> and rtl8188etv usb wifi. Has "power", "volume+" and "volume-" buttons
> >> (both volume buttons are also connected to the UBOOT_SEL pin). The
> >
> > Hello Chen-Yu,
> >
> > the volume button function is something that I wanted to confirm
> > again but forgot to ask previously: Siarhei had pointed out that
> > only the volume+ button triggers UBOOT_SEL, but for me actually
> > both volume buttons work as described above.  Could you
> > cross-check that on your Primo81?
> 
> IIRC both work. I can test next week.

Both buttons work this way because the Allwinner's firmware
additionally checks the buttons state via LRADC and switches
into the FEL mode in a software way. But if somebody flashes a
broken bootloader to NAND (something that is recognized by the
BROM, but dies instead of booting) then we may potentially have
a bricked device because booting from NAND has the highest
priority on A31s.

The UBOOT_SEL pin on the SoC can be used to change the default
boot order and allow to boot from the SD card or USB first
regardless of what is in NAND. So if at least one of the hardware
buttons is connected to the UBOOT_SEL pin, then we have an
unbrickable device.

Checking whether the hardware button is really connected to the
UBOOT_SEL pin can be done by reading the SRAM_VER_REG hardware
register and looking at the BOOT_SEL_PAD_STA bits:
http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG

And this can be done, for example, via using the devmem2 tool:
"devmem2 0x01c00024"

Alternatively, it is also possible to use a modified variant of the
dialog tool, which is additionally polling the state of the FEL
button and interpreting long FEL button press as KEY_ENTER and
short press as KEY_DOWN:
https://github.com/ssvb/dialog-sunxi

This patched dialog tool is a part of the board type selection stub,
used for creating universal board-independent SD card based installers
for Allwinner devices, which has been available for Linux distribution
maintainers since a while ago:
http://lists.denx.de/pipermail/u-boot/2015-January/202306.html

Regarding the UBOOT_SEL pin in the MSI Primo81 tablet. After
buying this tablet, I was happy to confirm that at least the
"volume+" button is connected to the UBOOT_SEL pin, making the
tablet unbrickable. However appears that it was not just some sane
decision made by MSI engineers, but in fact connecting both LRADC
and UBOOT_SEL to tablet buttons is a part of the standard Allwinner's
reference schematics. One can search for "a20_pad_std_v1_1.pdf",
"a13-sch.pdf", "A31_PAD_STD_V1_90_130225.pdf" documents on the
Internet to find this information. Basically, we should expect
the majority of Allwinner A31(s) tablets to have a hardware FEL
button and be perfectly unbrickable :-)

-- 
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 1/6] integrity: define '.evm' as a builtin 'trusted' keyring

[Petko Manolov]

On 15-10-23 14:43:53, Mimi Zohar wrote:
> On Fri, 2015-10-23 at 16:05 +0300, Petko Manolov wrote:
> > On 15-10-22 21:49:25, Dmitry Kasatkin wrote:
> 
> > > diff --git a/security/integrity/ima/Kconfig 
> > > b/security/integrity/ima/Kconfig
> > > index df30334..a292b88 100644
> > > --- a/security/integrity/ima/Kconfig
> > > +++ b/security/integrity/ima/Kconfig
> > > @@ -123,14 +123,17 @@ config IMA_APPRAISE
> > > If unsure, say N.
> > >  
> > >  config IMA_TRUSTED_KEYRING
> > > - bool "Require all keys on the .ima keyring be signed"
> > > + bool "Require all keys on the .ima keyring be signed (deprecated)"
> > >   depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING
> > >   depends on INTEGRITY_ASYMMETRIC_KEYS
> > > + select INTEGRITY_TRUSTED_KEYRING
> > >   default y
> > >   help
> > >  This option requires that all keys added to the .ima
> > >  keyring be signed by a key on the system trusted keyring.
> > >  
> > > +This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
> > > +
> > >  config IMA_LOAD_X509
> > >   bool "Load X509 certificate onto the '.ima' trusted keyring"
> > >   depends on IMA_TRUSTED_KEYRING
> > 
> > 
> > I guess we may as well remove this switch.  Otherwise somebody have to 
> > remember 
> > to post a patch that does so a few kernel releases after this one goes 
> > mainline.
> 
> There's no harm in leaving the "IMA_TRUSTED_KEYRING" Kconfig option for a 
> couple of releases (or perhaps until it is enabled in a long term release), 
> so 
> that the INTEGRITY_TRUSTED_KEYRING Kconfig option is enabled automatically.

I have no strong opinion either way.  Just saying.  Let it be for the moment.


Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem about CPU stalling in hrtimer_intterrupts()

[Thomas Gleixner]

On Thu, 22 Oct 2015, Yang Yingliang wrote:

> But I found out when the cpu is stalling, basenow.tv64(7676664221321) is
> bigger than ktime_get().tv64(7336008904750) in hrtimer_interrupt() and
> the timer->_softexpires is 733628800. This makes it can not finish
> the while loop until ktime_get().tv64 arrives basenow.tv64.
> 
> Is it correct that basenow bigger than ktime_get() ?

You only can compare basenow and ktime_get() for the clock monotonic
base. If you are actually observing this on clock monotonic base then
base->offset of clock monotonic is not 0, which should never happen.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

[Neil Armstrong]

Hi,

2015-10-24 3:21 GMT+02:00 Tony Lindgren :
>
> Hi,
>
> * Neil Armstrong  [151022 02:19]:
> > Add missing HWMOD_NO_IDLEST hwmod flag for entries no
> > having omap4 clkctrl values.
>
> Have you checked this is the case both in dm814x and dm816x TRM?
> Also the documentation may not be complete FYI, might be also
> worth checking the legacy TI kernel tree to be sure.
>
> Regards,
>
> Tony
>
> > Cc: Brian Hutchinson 
> > Signed-off-by: Neil Armstrong 
> > ---
> >  arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
> > b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> > index b1288f5..6256052 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> > @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
> >   .name   = "l4_ls",
> >   .clkdm_name = "alwon_l3s_clkdm",
> >   .class  = &l4_hwmod_class,
> > + .flags  = HWMOD_NO_IDLEST,
> >  };
In DM814x TRM, the CM_ALWON_L3_SLOW_CLKSTCTRL does not have IDLEST field.
Same in DM816x TRM.

> >
> >  /*
> > @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
> >   .name   = "l4_hs",
> >   .clkdm_name = "alwon_l3_med_clkdm",
> >   .class  = &l4_hwmod_class,
> > + .flags  = HWMOD_NO_IDLEST,
> >  };
In DM814x TRM, the CM_ALWON_L3_MED_CLKSTCTRL does not have IDLEST field.
Same in DM816x TRM.

> >
> >  /* L3 slow -> L4 ls peripheral interface running at 125MHz */
> > @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
> >   .name   = "emac0",
> >   .clkdm_name = "alwon_ethernet_clkdm",
> >   .class  = &dm816x_emac_hwmod_class,
> > + .flags  = HWMOD_NO_IDLEST,
> >  };
In this particular case, the IDLEST is handled in the MDIO hwmod.

> >
> >  static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = {
> > --
> > 1.9.1

I'll check the TI tree to be sure...

Regards,
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V1 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization.

[Hanjun Guo]

On 2015/10/15 22:05, Tomasz Nowicki wrote:
> After refactoring DT code, we let ACPI to build ITS PCI MSI domain
> and do requester ID to device ID translation using IORT table.
>
> We have now full PCI MSI domain stack, thus we can enable ITS initialization
> from GICv3 core driver for ACPI scenario.
>
> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 48 
> ++--
>  drivers/irqchip/irq-gic-v3.c |  3 +-
>  2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index cfd35da..09ae2d8 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -15,6 +15,8 @@
>   * along with this program.  If not, see .
>   */
>  
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,8 +61,10 @@ static int its_pci_msi_vec_count(struct pci_dev *pdev)
>  static int its_get_pci_alias(struct pci_dev *pdev, u16 alias, void *data)
>  {
>   struct its_pci_alias *dev_alias = data;
> + u32 dev_id;
>  
> - dev_alias->dev_id = alias;
> + dev_alias->dev_id = iort_find_pci_id(pdev, alias, &dev_id) == 0 ?
> + dev_id : alias;

Hi tomasz, I think we need to re work this patch on top of tip/irq/core
which has support for "msi-map" and "mai-parent" property support.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

[Peter Zijlstra]

On Thu, Oct 22, 2015 at 08:07:16PM +0800, Boqun Feng wrote:
> On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> > > > > > > I ask this because I recall Peter once bought up a discussion:
> > > > > > > 
> > > > > > > https://lkml.org/lkml/2015/8/26/596
> > 
> > > > So a full barrier on one side of these operations is enough, I think.
> > > > IOW, there is no need to strengthen these operations.
> > > 
> > > Do we need to also worry about other futex use cases?
> > 
> > Worry, always!
> > 
> > But yes, there is one more specific usecase, which is that of a
> > condition variable.
> > 
> > When we go sleep on a futex, we might want to assume visibility of the
> > stores done by the thread that woke us by the time we wake up.
> > 
> 
> But the thing is futex atomics in PPC are already RELEASE(pc)+ACQUIRE
> and imply a full barrier, is an RELEASE(sc) semantics really needed
> here?

For this, no, the current code should be fine I think.

> Further more, is this condition variable visibility guaranteed by other
> part of futex? Because in futex_wake_op:
> 
>   futex_wake_op()
> ...
> double_unlock_hb(hb1, hb2);  <- RELEASE(pc) barrier here.
> wake_up_q(&wake_q);
> 
> and in futex_wait():
> 
>   futex_wait()
> ...
> futex_wait_queue_me(hb, &q, to); <- schedule() here
> ...
> unqueue_me(&q)
>   drop_futex_key_refs(&q->key);
>   iput()/mmdrop(); <- a full barrier
> 
> 
> The RELEASE(pc) barrier pairs with the full barrier, therefore the
> userspace wakee can observe the condition variable modification.

Right, futexes are a pain; and I think we all agreed we didn't want to
go rely on implementation details unless we absolutely _have_ to.

> > And.. aside from the thoughts I outlined in the email referenced above,
> > there is always the chance people accidentally rely on the strong
> > ordering on their x86 CPU and find things come apart when ran on their
> > ARM/MIPS/etc..
> > 
> > There are a fair number of people who use the raw futex call and we have
> > 0 visibility into many of them. The assumed and accidental ordering
> > guarantees will forever remain a mystery.
> > 
> 
> Understood. That's truely a potential problem. Considering not all the
> architectures imply a full barrier at user<->kernel boundries, maybe we
> can use one bit in the opcode of the futex system call to indicate
> whether userspace treats futex as fully ordered. Like:
> 
> #define FUTEX_ORDER_SEQ_CST  0
> #define FUTEX_ORDER_RELAXED  64 (bit 7 and bit 8 are already used)

Not unless there's an actual performance problem with any of this.
Futexes are painful enough as is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

[Including Rafael who also asked about what being a TAB member means]

On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> Is there a good description of what is expected of a TAB member? How much time
> is involved? What makes a great TAB member?
>
> I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
>
> I've read the charter and scanned some of the minutes, but I'd still like to
> hear from some of the "incumbants". Specifically, what makes you successful 
> as a
> member of the TAB?

I've been asked several versions of the same question, and also the
annual "what does the TAB actually do?" question, so I'm going to try
and answer them all in one email:

As the name implies, the primary job of the TAB is to advise the Linux
Foundation board of directors on technical, social and political
issues regarding Linux and Open Source. Our job is to represent the
views of Linux developers and to foster constructive communication
between the Linux Foundation leadership and our community.

A natural by-product of this is that the TAB also acts in the
background to identify and resolve issues for the Linux community
before they become a problem. The TAB tends to be composed of well
respected individuals with good connections throughout our community,
and so we're in a good place to recognize who to talk to when an issue
is raised.

Finally, there are a few projects that the TAB is directly responsible
for. We make sure there is a planning committee for the Linux Plumbers
conference every year. We run a 'buddy' program to help new Linux
Foundation member companies learn how to be fine upstanding Linux
citizens. We are the response team for any issues of harassment or
abuse within the kernel community. In past years we coordinated the
response to UEFI Secure Boot to ensure that Linux would not be locked
out of the consumer PC market, and been active in helping member
companies understand and be comfortable with the licencing obligations
associated with Linux.

A good TAB member is well respected by the community, is a ready
listener, is comfortable discussing both technical and social issues,
and has a good understanding of how the Linux community works. Since
the TAB deals with a wide range of issues, the ideal TAB candidate
should be prepared to consider issues outside of their own area of
expertise. Sometime the most important characteristic of a TAB member
is recognizing when an issue is beyond their depth and go looking for
the right person to consult.

Time commitment wise, The TAB meets once a month for a conference
call, plus any additional time required to deal with TAB business.
Once a year (6 months after the TAB general election) the TAB elects
one member to serve as the chair, and the chair of the TAB is proposed
to the Linux Foundation to serve as a Linux Foundation Director which
has additional time requirements.

One last point, some issues addressed by the TAB are highly sensitive
and any member can request a topic to be kept strictly confidential.
We do this to protect the working relationship we have with industry
bodies, and to protect the companies and individuals involved. Any
prospective TAB member must be comfortable abiding by our
confidentiality rules.

I hope this answers your questions.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/8] Build and support rk3036 SoC platform

[Xing Zheng]

Hi,
  We need to support rk3036 soc platform via upstream, there are
3 primary parts for the initial release of minimum system: dts,
pinctrl, and clock tree for rk3036, and additional, we can use
these startup and run to init processs.

Thanks.

Changed in v4:
- add some basic IP modules on rk3036.dtsi
- optimized supporting smp codes

Changed in v3:
- optimized some codes based on v2
- removed the patch "initial set time for rtc-hym8563" (useless)
- removed the patch "pinctrl" (approved)

Changed in v2:
- based on v1, add clock controller documentation
- enable timer5 startup
- add smp for cpu1
- initial set time for rtc-hym8563

Changes in v1:
- add dts, pinctrl and clock tree for rk3036 soc platform

The patchset (8):
8) rockchip: make sure timer5 is enabled on rk3036 platforms
7) ARM: dts: enable smp for rk3036
6) ARM: rockchip: add support smp for rk3036
5) ARM: dts: rockchip: add core rk3036 dts
4) clk: rockchip: add new pll-type for rk3036 and similar socs
3) clk: rockchip: add clock controller for rk3036
2) clk: rockchip: add dt-binding header for rk3036
1) dt-bindings: add documentation of rk3036 clock controller


Changes in v4:
Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 

Heiko Stuebner (1):
  ARM: rockchip: add support smp for rk3036

Xing Zheng (7):
  dt-bindings: add documentation of rk3036 clock controller
  clk: rockchip: add dt-binding header for rk3036
  clk: rockchip: add clock controller for rk3036
  clk: rockchip: add new pll-type for rk3036 and similar socs
  ARM: dts: rockchip: add core rk3036 dts
  ARM: dts: enable smp for rk3036
  rockchip: make sure timer5 is enabled on rk3036 platforms

 Documentation/devicetree/bindings/arm/cpus.txt |1 +
 .../bindings/clock/rockchip,rk3036-cru.txt |   56 ++
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/rk3036-evb.dts   |   64 +++
 arch/arm/boot/dts/rk3036.dtsi  |  541 
 arch/arm/mach-rockchip/platsmp.c   |   45 +-
 arch/arm/mach-rockchip/rockchip.c  |   44 +-
 drivers/clk/rockchip/Makefile  |1 +
 drivers/clk/rockchip/clk-pll.c |  243 -
 drivers/clk/rockchip/clk-rk3036.c  |  500 ++
 drivers/clk/rockchip/clk.h |   30 ++
 include/dt-bindings/clock/rk3036-cru.h |  195 +++
 12 files changed, 1691 insertions(+), 30 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/8] clk: rockchip: add dt-binding header for rk3036

[Xing Zheng]

Add the dt-bindings header for the rk3036, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 include/dt-bindings/clock/rk3036-cru.h |  195 
 1 file changed, 195 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/include/dt-bindings/clock/rk3036-cru.h 
b/include/dt-bindings/clock/rk3036-cru.h
new file mode 100644
index 000..b0da216
--- /dev/null
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+
+/* core clocks */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_GPLL   3
+#define ARMCLK 4
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU   64
+#define SCLK_SPI   65
+#define SCLK_SDMMC 68
+#define SCLK_SDIO  69
+#define SCLK_EMMC  71
+#define SCLK_NANDC 76
+#define SCLK_UART0 77
+#define SCLK_UART1 78
+#define SCLK_UART2 79
+#define SCLK_I2S   82
+#define SCLK_SPDIF 83
+#define SCLK_TIMER085
+#define SCLK_TIMER186
+#define SCLK_TIMER287
+#define SCLK_TIMER388
+#define SCLK_OTGPHY0   93
+#define SCLK_LCDC  100
+#define SCLK_HDMI  109
+#define SCLK_HEVC  111
+#define SCLK_I2S_OUT   113
+#define SCLK_SDMMC_DRV 114
+#define SCLK_SDIO_DRV  115
+#define SCLK_EMMC_DRV  117
+#define SCLK_SDMMC_SAMPLE  118
+#define SCLK_SDIO_SAMPLE   119
+#define SCLK_EMMC_SAMPLE   121
+#define SCLK_PVTM_CORE  123
+#define SCLK_PVTM_GPU   124
+#define SCLK_PVTM_VIDEO 125
+#define SCLK_MAC   151
+#define SCLK_MACREF152
+#define SCLK_SFC   160
+
+#define DCLK_LCDC  190
+
+/* aclk gates */
+#define ACLK_DMAC2 194
+#define ACLK_LCDC  197
+#define ACLK_VIO   203
+#define ACLK_VCODEC208
+#define ACLK_CPU   209
+#define ACLK_PERI  210
+
+/* pclk gates */
+#define PCLK_GPIO0 320
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GRF   329
+#define PCLK_I2C0  332
+#define PCLK_I2C1  333
+#define PCLK_I2C2  334
+#define PCLK_SPI   338
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_PWM   350
+#define PCLK_TIMER 353
+#define PCLK_HDMI  360
+#define PCLK_CPU   362
+#define PCLK_PERI  363
+#define PCLK_DDRUPCTL  364
+#define PCLK_WDT   368
+#define PCLK_ACODEC369
+
+/* hclk gates */
+#define HCLK_OTG0  449
+#define HCLK_OTG1  450
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO  457
+#define HCLK_EMMC  459
+#define HCLK_I2S   462
+#define HCLK_LCDC  465
+#define HCLK_ROM   467
+#define HCLK_VIO_BUS   472
+#define HCLK_VCODEC476
+#define HCLK_CPU   477
+#define HCLK_PERI  478
+
+#define CLK_NR_CLKS(HCLK_PERI + 1)
+
+/* soft-reset indices */
+#define SRST_CORE0 0
+#define SRST_CORE1 1
+#define SRST_CORE0_DBG 4
+#define SRST_CORE1_DBG 5
+#define SRST_CORE0_POR 8
+#define SRST_CORE1_POR 9
+#define SRST_L2C   12
+#define SRST_TOPDBG13
+#define SRST_STRC_SYS_A14
+#define SRST_PD_CORE_NIU   15
+
+#define SRST_TIMER216
+#define SRST_CPUSYS_H  17
+#define SRST_AHB2APB_H 19
+#define SRST_TIMER320
+#define SRST_INTMEM21
+#define SRST_ROM   22
+#define SRST_PERI_NIU  23
+#define SRST_I2S   24
+#define SRST_DDR_PLL   25
+#define SRST_GPU_DLL   26
+#define SRST_TIMER027
+#define SRST_TIMER128
+#define SRST_CORE_DLL  29
+#define SRST_EFUSE_P   

[PATCH v4 4/8] clk: rockchip: add new pll-type for rk3036 and similar socs

[Xing Zheng]

The rk3036's pll and clock are different with base on the rk3066(rk3188,
rk3288, rk3368 use it), there are different adjust foctors and control
registers, so these should be independent and separate from the series
of rk3066s.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 drivers/clk/rockchip/clk-pll.c |  243 +++-
 1 file changed, 242 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 4881eb8..a435503 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
  * Copyright (c) 2014 MundoReader S.L.
  * Author: Heiko Stuebner 
  *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
  * 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
@@ -19,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "clk.h"
 
 #define PLL_MODE_MASK  0x3
@@ -108,6 +112,237 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll 
*pll)
 }
 
 /**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLLCON(i)   (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK  0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK   0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT  12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK   0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT  6
+#define RK3036_PLLCON1_DSMPD_MASK  0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK   0xff
+#define RK3036_PLLCON2_FRAC_SHIFT  0
+
+#define RK3036_PLLCON1_PWRDOWN (1 << 13)
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+   struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+   unsigned int fbdiv, postdiv1, refdiv, postdiv2, dsmpd, frac;
+   u64 rate64 = prate;
+   u32 pllcon;
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(0));
+   fbdiv = ((pllcon >> RK3036_PLLCON0_FBDIV_SHIFT) & 
RK3036_PLLCON0_FBDIV_MASK);
+   postdiv1 = ((pllcon >> RK3036_PLLCON0_POSTDIV1_SHIFT) & 
RK3036_PLLCON0_POSTDIV1_MASK);
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+   refdiv = ((pllcon >> RK3036_PLLCON1_REFDIV_SHIFT) & 
RK3036_PLLCON1_REFDIV_MASK);
+   postdiv2 = ((pllcon >> RK3036_PLLCON1_POSTDIV2_SHIFT) & 
RK3036_PLLCON1_POSTDIV2_MASK);
+   dsmpd = ((pllcon >> RK3036_PLLCON1_DSMPD_SHIFT) & 
RK3036_PLLCON1_DSMPD_MASK);
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(2));
+   frac = ((pllcon >> RK3036_PLLCON2_FRAC_SHIFT) & 
RK3036_PLLCON2_FRAC_MASK);
+
+   rate64 *= fbdiv;
+   do_div(rate64, refdiv);
+
+   if (dsmpd == 0) {
+   /* fractional mode */
+   u64 frac_rate64 = prate * frac;
+
+   do_div(frac_rate64, refdiv);
+   rate64 += frac_rate64 >> 24;
+   }
+
+   do_div(rate64, postdiv1);
+   do_div(rate64, postdiv2);
+
+   return (unsigned long)rate64;
+}
+
+static int rockchip_rk3036_pll_set_rate(struct clk_hw *hw, unsigned long drate,
+   unsigned long prate)
+{
+   struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+   const struct rockchip_pll_rate_table *rate;
+   unsigned long old_rate = rockchip_rk3036_pll_recalc_rate(hw, prate);
+   struct regmap *grf = rockchip_clk_get_grf();
+   struct clk_mux *pll_mux = &pll->pll_mux;
+   const struct clk_ops *pll_mux_ops = pll->pll_mux_ops;
+   u32 pllcon;
+   int rate_change_remuxed = 0;
+   int cur_parent;
+   int ret;
+
+   if (IS_ERR(grf)) {
+   pr_debug("%s: grf regmap not available, aborting rate change\n",
+__func__);
+   return PTR_ERR(grf);
+   }
+
+   pr_debug("%s: changing %s from %lu to %lu with a parent rate of %lu\n",
+__func__, __clk_get_name(hw->clk), old_rate, drate, prate);
+
+   /* Get required rate settings from table */
+   rate = rockchip_get_pll_settings(pll, drate);
+   if (!rate) {
+   pr_err("%s: Invalid rate : %lu for pll clk %s\n", __func__,
+   drate, __clk_get_name(hw->clk));
+   return -EINVAL;
+   }
+
+   pr_debug("%s: rate settings for %lu fbdiv: %d, postdiv1: %d, refdiv: 
%d, postdiv2: %d, dsmpd: %d, frac: %d\n",
+   __func__, rate->rate,
+   rate->fbdiv, rate->postdiv1, rate->refdiv, rate->postdiv2, 
rate->dsmpd, rate->frac);
+
+   cur_parent =

[PATCH v4 3/8] clk: rockchip: add clock controller for rk3036

[Xing Zheng]

Add the clock tree definition for the new rk3036 SoC.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 drivers/clk/rockchip/Makefile |1 +
 drivers/clk/rockchip/clk-rk3036.c |  500 +
 drivers/clk/rockchip/clk.h|   30 +++
 3 files changed, 531 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
 obj-y  += clk-mmc-phase.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
 
+obj-y  += clk-rk3036.o
 obj-y  += clk-rk3188.o
 obj-y  += clk-rk3288.o
 obj-y  += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
new file mode 100644
index 000..6f49df3
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner 
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
+ * 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 "clk.h"
+
+#define RK3036_GRF_SOC_STATUS0 0x14c
+
+enum rk3036_plls {
+   apll, dpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk3036_pll_rates[] = {
+   /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+   RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+   RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+   RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+   RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+   RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+   RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+   RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+   RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+   RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+   RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+   RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+   RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+   RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+   RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+   RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+   RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+   RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+   RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+   RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+   RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+   RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+   RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 98400, 1, 82, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 96000, 1, 80, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 93600, 1, 78, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 91200, 1, 76, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 9, 4, 300, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 88800, 1, 74, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 86400, 1, 72, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 84000, 1, 70, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 81600, 1, 68, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 8, 6, 400, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 7, 6, 350, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 69600, 1, 58, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 6, 1, 75, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 59400, 2, 99, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 50400, 1, 63, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 5, 6, 250, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 40800, 1, 68, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 31200, 1, 52, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 21600, 1, 72, 4, 2, 1, 0),
+   RK3036_PLL_RATE(  9600, 1, 64, 4, 4, 1, 0),
+   { /* sentinel */ },
+};
+
+#define RK3036_DIV_CPU_MASK0x1f
+#define RK3036_DIV_CPU_SHIFT   8
+
+#define RK3036_DIV_PERI_MASK   0xf
+#define RK3036_DIV_PERI_SHIFT  0
+#define RK3036_DIV_ACLK_MASK   0x7
+#define RK3036_DIV_ACLK_SHIFT  4
+#define RK3036_DIV_HCLK_MASK   0x3
+#define RK3036_DIV_HCLK_SHIFT  8
+#define RK3036_DIV_PCLK_MASK   0x7
+#define RK3036_DIV_PCLK_SHIFT  12
+
+#define RK3036_CLKSEL1(_core_periph_div)   
\
+   {   
\
+   .reg = RK2928_CLKSEL_CON(

[PATCH v4 1/8] dt-bindings: add documentation of rk3036 clock controller

[Xing Zheng]

Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 .../bindings/clock/rockchip,rk3036-cru.txt |   56 
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt 
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
new file mode 100644
index 000..ace0599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,56 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+   cru: cru@2000 {
+   compatible = "rockchip,rk3036-cru";
+   reg = <0x2000 0x1000>;
+   rockchip,grf = <&grf>;
+
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+   uart0: serial@2006 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x2006 0x100>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = <&cru SCLK_UART0>;
+   };
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 5/8] ARM: dts: rockchip: add core rk3036 dts

[Xing Zheng]

Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3036-evb.dts |   64 +
 arch/arm/boot/dts/rk3036.dtsi|  536 ++
 3 files changed, 601 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d3e495..3e4e089 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+   rk3036-evb.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
new file mode 100644
index 000..28a0336
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -0,0 +1,64 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+   model = "Rockchip RK3036 Evaluation board";
+   compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
+};
+
+&i2c1 {
+   status = "okay";
+
+   hym8563: hym8563@51 {
+   compatible = "haoyu,hym8563";
+   reg = <0x51>;
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "xin32k";
+   };
+};
+
+&uart2 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..8f3a069
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,536 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the fol

[PATCH v4 6/8] ARM: rockchip: add support smp for rk3036

[Xing Zheng]

From: Heiko Stuebner 

The dual-core Cortex A7 rk3036 is a bit special in that it does not allow
to control the actual powerdomain of the cpu cores, while the rest of the
smp-bringup like reset control and entry address handling stays the same.
Its bigger sibling, the quad-core rk3128 again allows powerdomain control.

So allow that case by introducing a separate smp-enable-method, that simply
disables powerdomain handling in the common code.

Signed-off-by: Heiko Stuebner 
Tested-by: Xing Zheng 
Signed-off-by: Xing Zheng 
---

Changes in v4: None

 Documentation/devicetree/bindings/arm/cpus.txt |1 +
 arch/arm/mach-rockchip/platsmp.c   |   45 +---
 2 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..261cc27 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -198,6 +198,7 @@ nodes to be present and contain the properties described 
below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
+   "rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
 
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 3e7a4b7..5c138f9 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -42,6 +42,7 @@ static int ncores;
 #define PMU_PWRDN_SCU  4
 
 static struct regmap *pmu;
+static int has_pmu = true;
 
 static int pmu_power_domain_is_on(int pd)
 {
@@ -89,20 +90,23 @@ static int pmu_set_power_domain(int pd, bool on)
if (!IS_ERR(rstc) && !on)
reset_control_assert(rstc);
 
-   ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
-   if (ret < 0) {
-   pr_err("%s: could not update power domain\n", __func__);
-   return ret;
-   }
-
-   ret = -1;
-   while (ret != on) {
-   ret = pmu_power_domain_is_on(pd);
+   if (has_pmu) {
+   ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
if (ret < 0) {
-   pr_err("%s: could not read power domain state\n",
+   pr_err("%s: could not update power domain\n",
   __func__);
return ret;
}
+
+   ret = -1;
+   while (ret != on) {
+   ret = pmu_power_domain_is_on(pd);
+   if (ret < 0) {
+   pr_err("%s: could not read power domain 
state\n",
+  __func__);
+   return ret;
+   }
+   }
}
 
if (!IS_ERR(rstc)) {
@@ -122,7 +126,7 @@ static int rockchip_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 {
int ret;
 
-   if (!sram_base_addr || !pmu) {
+   if (!sram_base_addr || (has_pmu && !pmu)) {
pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
return -ENXIO;
}
@@ -275,7 +279,7 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
return;
}
 
-   if (rockchip_smp_prepare_pmu())
+   if (has_pmu && rockchip_smp_prepare_pmu())
return;
 
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
@@ -318,6 +322,13 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
pmu_set_power_domain(0 + i, false);
 }
 
+static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus)
+{
+   has_pmu = false;
+
+   rockchip_smp_prepare_cpus(max_cpus);
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 static int rockchip_cpu_kill(unsigned int cpu)
 {
@@ -340,6 +351,15 @@ static void rockchip_cpu_die(unsigned int cpu)
 }
 #endif
 
+static struct smp_operations rk3036_smp_ops __initdata = {
+   .smp_prepare_cpus   = rk3036_smp_prepare_cpus,
+   .smp_boot_secondary = rockchip_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+   .cpu_kill   = rockchip_cpu_kill,
+   .cpu_die= rockchip_cpu_die,
+#endif
+};
+
 static struct smp_operations rockchip_smp_ops __initdata = {
.smp_prepare_cpus   = rockchip_smp_prepare_cpus,
.smp_boot_secondary = rockchip_boot_secondary,
@@ -349,4 +369,5 @@ static struct smp_operations rockchip_smp_ops __initdata = {
 #endif
 };
 
+CPU_METHOD_OF_DECLARE(rk3036_smp, "rockchip,rk3036-smp", &rk3036_smp_ops);
 CPU_METHOD_OF_DECLARE(rk3066_smp, "rockchip,rk3066-smp", &rockchip_smp_ops);
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.or

[PATCH v4 7/8] ARM: dts: enable smp for rk3036

[Xing Zheng]

Enable smp for rk3036, and add the smp sram name for adapting.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v4: None

 arch/arm/boot/dts/rk3036.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 8f3a069..61352be 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -72,6 +72,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "rockchip,rk3036-smp";
 
cpu0: cpu@f00 {
device_type = "cpu";
@@ -146,6 +147,10 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1008 0x2000>;
+   smp-sram@0 {
+   compatible = "rockchip,rk3066-smp-sram";
+   reg = <0x00 0x10>;
+   };
};
 
cru: clock-controller@2000 {
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 8/8] rockchip: make sure timer5 is enabled on rk3036 platforms

[Xing Zheng]

The timer5 supplies the architected timer and thus as has to run when
the system clocksource and clockevents drivers are registered.

---

Changes in v4:
Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 

 arch/arm/mach-rockchip/rockchip.c |   44 +++--
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-rockchip/rockchip.c 
b/arch/arm/mach-rockchip/rockchip.c
index 251c7b9..608b31c 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -29,31 +29,38 @@
 #include "core.h"
 #include "pm.h"
 
+#define RK3036_TIMER_PHYS 0x20044000
+
 #define RK3288_GRF_SOC_CON0 0x244
 #define RK3288_TIMER6_7_PHYS 0xff81
 
+static void rockchip_init_arch_timer_supply(resource_size_t phys, int offs)
+{
+   void __iomem *reg_base = ioremap(phys, SZ_16K);
+
+   /*
+* Most/all uboot versions for Rockchip SoCs don't enable
+* timer which is needed for the architected timer to work.
+* So make sure it is running during early boot.
+*/
+   if (reg_base) {
+   writel(0, reg_base + offs + 0x10);
+   writel(0x, reg_base + offs);
+   writel(0x, reg_base + offs + 0x04);
+   writel(1, reg_base + offs + 0x10);
+   dsb();
+   iounmap(reg_base);
+   } else {
+   pr_err("rockchip: could not map timer registers\n");
+   }
+}
+
 static void __init rockchip_timer_init(void)
 {
if (of_machine_is_compatible("rockchip,rk3288")) {
struct regmap *grf;
-   void __iomem *reg_base;
 
-   /*
-* Most/all uboot versions for rk3288 don't enable timer7
-* which is needed for the architected timer to work.
-* So make sure it is running during early boot.
-*/
-   reg_base = ioremap(RK3288_TIMER6_7_PHYS, SZ_16K);
-   if (reg_base) {
-   writel(0, reg_base + 0x30);
-   writel(0x, reg_base + 0x20);
-   writel(0x, reg_base + 0x24);
-   writel(1, reg_base + 0x30);
-   dsb();
-   iounmap(reg_base);
-   } else {
-   pr_err("rockchip: could not map timer7 registers\n");
-   }
+   rockchip_init_arch_timer_supply(RK3288_TIMER6_7_PHYS, 0x20);
 
/*
 * Disable auto jtag/sdmmc switching that causes issues
@@ -64,6 +71,8 @@ static void __init rockchip_timer_init(void)
regmap_write(grf, RK3288_GRF_SOC_CON0, 0x1000);
else
pr_err("rockchip: could not get grf syscon\n");
+   } else if (of_machine_is_compatible("rockchip,rk3036")) {
+   rockchip_init_arch_timer_supply(RK3036_TIMER_PHYS, 0xa0);
}
 
of_clk_init(NULL);
@@ -79,6 +88,7 @@ static void __init rockchip_dt_init(void)
 
 static const char * const rockchip_board_dt_compat[] = {
"rockchip,rk2928",
+   "rockchip,rk3036",
"rockchip,rk3066a",
"rockchip,rk3066b",
"rockchip,rk3188",
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] ARM: dts: Exynos for v4.4 (3rd)

[Krzysztof Kozlowski]

2015-10-24 4:35 GMT+09:00 Kukjin Kim :
> On 10/16/15 14:42, Krzysztof Kozlowski wrote:
>> Dear Kukjin,
>>
>> Last batch of changes to DT for Exynos for v4.4.
>> Includes dependency - clock driver changes.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 9aaf43d9b59d6b5d8daeb3a4b9d894ea88fc34c5:
>>
>>   clk: samsung: exynos5250: Add DISP1 clocks (2015-10-16 08:49:53 +0900)
>>
>> are available in the git repository at:
>>
>>   https://github.com/krzk/linux.git tags/samsung-dt-4.4-3
>>
>> for you to fetch changes up to 1967da5699e660957737ec6c4015cfd8e428f0ff:
>>
>>   ARM: dts: Add clocks to DISP1 domain in exynos5250 (2015-10-16 14:20:03 
>> +0900)
>>
>> 
>> Last round (from my side) of v4.4 Device Tree improvements for Exynos
>> based boards:
>> 1. Fix USB OTG on Exynos3250 (Monk and Rinato), Exynos4210 (Trats
>>and Universal) and Exynos4412 (Trats2).
>> 2. Fix HDMI and LVDS display on Snow (Exynos5250) after second Suspend to 
>> RAM.
>> 3. Minor cleanups and fixes.
>>
>> 
>> Krzysztof Kozlowski (2):
>>   Merge tag 'samsung-clk-exynos5250-4.4' into dt-for-next
>
> Since there is no the branch(tags/samsung-clk-exynos5250-4.4) in clk
> tree, I think we don't need to keep the branch as a topic and we can
> just take the patch with Stephen's ack...
>
>>   dt-bindings: Correct the example for Exynos power domain clocks
>>
>> Laurent Pinchart (2):
>>   ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-aquila
>>   ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-goni
>>
>> Marek Szyprowski (1):
>>   ARM: dts: Add vbus regulator to USB2 phy nodes on exynos3250, 
>> exynos4210 and exynos4412 boards
>>
>> Tomeu Vizoso (1):
>>   ARM: dts: Add clocks to DISP1 domain in exynos5250
>>
>>  Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
>>  arch/arm/boot/dts/exynos3250-monk.dts | 1 +
>>  arch/arm/boot/dts/exynos3250-rinato.dts   | 1 +
>>  arch/arm/boot/dts/exynos4210-trats.dts| 2 +-
>>  arch/arm/boot/dts/exynos4210-universal_c210.dts   | 2 +-
>>  arch/arm/boot/dts/exynos4412-trats2.dts   | 1 +
>>  arch/arm/boot/dts/exynos5250.dtsi | 4 
>>  arch/arm/boot/dts/s5pv210-aquila.dts  | 2 +-
>>  arch/arm/boot/dts/s5pv210-goni.dts| 4 ++--
>>  9 files changed, 14 insertions(+), 8 deletions(-)
>
> In this case, please show all of diff status including merge branch ;-)

Right, thanks for catching this!

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/8] clk: rockchip: add new pll-type for rk3036 and similar socs

[Heiko Stübner]

Hi,

Am Samstag, 24. Oktober 2015, 18:30:25 schrieb Xing Zheng:
> The rk3036's pll and clock are different with base on the rk3066(rk3188,
> rk3288, rk3368 use it), there are different adjust foctors and control
> registers, so these should be independent and separate from the series
> of rk3066s.
> 
> Signed-off-by: Xing Zheng 
> Reviewed-by: Heiko Stuebner 
> ---
> 

> +static void rockchip_rk3036_pll_init(struct clk_hw *hw)
> +{

In the previous version, Stephen requested that we don't use regular clock
APIs in the init-callback. I did a modification for the already present pll-
type in [0], which got already accepted. So you should probably also modify
your pll-type in this fashion :-) .

Oh and I guess patches 3 and 4 should switch places ... adding the pll-type
before the code in the clock-controller using it.


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=8334c0e7b983fb27e0d8788901e9621d1946ba93

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC net-next 0/2] tcp: Redundant Data Bundling (RDB)

[Jonas Markussen]

> On 24 Oct 2015, at 08:11, Yuchung Cheng  wrote:
> 
> On Fri, Oct 23, 2015 at 1:50 PM, Bendik Rønning Opstad
>  wrote:
>> 
>> This is a request for comments.
>> 
>> Redundant Data Bundling (RDB) is a mechanism for TCP aimed at reducing
>> the latency for applications sending time-dependent data.
>> Latency-sensitive applications or services, such as online games and
>> remote desktop, produce traffic with thin-stream characteristics,
>> characterized by small packets and a relatively high ITT. By bundling
>> already sent data in packets with new data, RDB alleviates head-of-line
>> blocking by reducing the need to retransmit data segments when packets
>> are lost. RDB is a continuation on the work on latency improvements for
>> TCP in Linux, previously resulting in two thin-stream mechanisms in the
>> Linux kernel
>> (https://github.com/torvalds/linux/blob/master/Documentation/networking/tcp-thin.txt).
>> 
>> The RDB implementation has been thoroughly tested, and shows
>> significant latency reductions when packet loss occurs[1]. The tests
>> show that, by imposing restrictions on the bundling rate, it can be made
>> not to negatively affect competing traffic in an unfair manner.
>> 
>> Note: Current patch set depends on a recently submitted patch for
>> tcp_skb_cb (tcp: refactor struct tcp_skb_cb: 
>> http://patchwork.ozlabs.org/patch/510674)
>> 
>> These patches have been tested with as set of packetdrill scripts located at
>> https://github.com/bendikro/packetdrill/tree/master/gtests/net/packetdrill/tests/linux/rdb
>> (The tests require patching packetdrill with a new socket option:
>> https://github.com/bendikro/packetdrill/commit/9916b6c53e33dd04329d29b7d8baf703b2c2ac1b)
>> 
>> Detailed info about the RDB mechanism can be found at
>> http://mlab.no/blog/2015/10/redundant-data-bundling-in-tcp, as well as in 
>> the paper
> 
> What's the difference between RDB and TCP repacketization
> (http://flylib.com/books/en/3.223.1.226/1/) ?
> 
> Reading the blog page, I am concerned the amount of
> change (esp on fast path) just to bundle new writes during timeout &
> retransmit, for a specific type of application? why not just send X
> packets with total bytes < MSS on timeout..

Repacketization is only on retransmissions; RDB bundles previously sent 
segments with the next “normal” transmission instead. 

This makes the flow recover the lost segment  before a retransmission is 
triggered by an RTO or fast retransmit.

>> "Latency and Fairness Trade-Off for Thin Streams using Redundant Data
>> Bundling in TCP"[2].
>> 
>> [1] http://home.ifi.uio.no/paalh/students/BendikOpstad.pdf
>> [2] http://home.ifi.uio.no/bendiko/rdb_fairness_tradeoff.pdf
>> 
>> 
>> Bendik Rønning Opstad (2):
>>  tcp: Add DPIFL thin stream detection mechanism
>>  tcp: Add Redundant Data Bundling (RDB)
>> 
>> Documentation/networking/ip-sysctl.txt |  23 +++
>> include/linux/skbuff.h |   1 +
>> include/linux/tcp.h|   9 +-
>> include/net/tcp.h  |  34 
>> include/uapi/linux/tcp.h   |   1 +
>> net/core/skbuff.c  |   3 +-
>> net/ipv4/Makefile  |   3 +-
>> net/ipv4/sysctl_net_ipv4.c |  35 
>> net/ipv4/tcp.c |  19 ++-
>> net/ipv4/tcp_input.c   |   3 +
>> net/ipv4/tcp_output.c  |  11 +-
>> net/ipv4/tcp_rdb.c | 281 
>> +
>> 12 files changed, 415 insertions(+), 8 deletions(-)
>> create mode 100644 net/ipv4/tcp_rdb.c
>> 
>> --
>> 1.9.1

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

[Boqun Feng]

On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 22, 2015 at 08:07:16PM +0800, Boqun Feng wrote:
> > On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> > > > > > > > I ask this because I recall Peter once bought up a discussion:
> > > > > > > > 
> > > > > > > > https://lkml.org/lkml/2015/8/26/596
> > > 
> > > > > So a full barrier on one side of these operations is enough, I think.
> > > > > IOW, there is no need to strengthen these operations.
> > > > 
> > > > Do we need to also worry about other futex use cases?
> > > 
> > > Worry, always!
> > > 
> > > But yes, there is one more specific usecase, which is that of a
> > > condition variable.
> > > 
> > > When we go sleep on a futex, we might want to assume visibility of the
> > > stores done by the thread that woke us by the time we wake up.
> > > 
> > 
> > But the thing is futex atomics in PPC are already RELEASE(pc)+ACQUIRE
> > and imply a full barrier, is an RELEASE(sc) semantics really needed
> > here?
> 
> For this, no, the current code should be fine I think.
> 
> > Further more, is this condition variable visibility guaranteed by other
> > part of futex? Because in futex_wake_op:
> > 
> > futex_wake_op()
> >   ...
> >   double_unlock_hb(hb1, hb2);  <- RELEASE(pc) barrier here.
> >   wake_up_q(&wake_q);
> > 
> > and in futex_wait():
> > 
> > futex_wait()
> >   ...
> >   futex_wait_queue_me(hb, &q, to); <- schedule() here
> >   ...
> >   unqueue_me(&q)
> > drop_futex_key_refs(&q->key);
> > iput()/mmdrop(); <- a full barrier
> >   
> > 
> > The RELEASE(pc) barrier pairs with the full barrier, therefore the
> > userspace wakee can observe the condition variable modification.
> 
> Right, futexes are a pain; and I think we all agreed we didn't want to
> go rely on implementation details unless we absolutely _have_ to.
> 

Agreed.

Besides, after I have read why futex_wake_op(the caller of
futex_atomic_op_inuser()) is introduced, I think your worries are quite
reasonable. I thought the futex_atomic_op_inuser() only operated on
futex related variables, but it turns out it can actually operate any
userspace variable if userspace code likes, therefore we don't have
control of all memory ordering guarantee of the variable. So if PPC
doesn't provide a full barrier at user<->kernel boundries, we should
make futex_atomic_op_inuser() fully ordered.


Still looking into futex_atomic_cmpxchg_inatomic() ...

> > > And.. aside from the thoughts I outlined in the email referenced above,
> > > there is always the chance people accidentally rely on the strong
> > > ordering on their x86 CPU and find things come apart when ran on their
> > > ARM/MIPS/etc..
> > > 
> > > There are a fair number of people who use the raw futex call and we have
> > > 0 visibility into many of them. The assumed and accidental ordering
> > > guarantees will forever remain a mystery.
> > > 
> > 
> > Understood. That's truely a potential problem. Considering not all the
> > architectures imply a full barrier at user<->kernel boundries, maybe we
> > can use one bit in the opcode of the futex system call to indicate
> > whether userspace treats futex as fully ordered. Like:
> > 
> > #define FUTEX_ORDER_SEQ_CST  0
> > #define FUTEX_ORDER_RELAXED  64 (bit 7 and bit 8 are already used)
> 
> Not unless there's an actual performance problem with any of this.
> Futexes are painful enough as is.

Make sense, and we still have choices like modifying the userspace code
if there is actually a performance problem ;-)

Regards,
Boqun


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] staging: rtl8712: Remove boolean comparisons

[Luis de Bethencourt]

On 22/10/15 20:05, Dan Carpenter wrote:
> On Mon, Oct 19, 2015 at 06:14:29PM +0100, Luis de Bethencourt wrote:
>> Boolean tests do not need explicit comparison to true or false.
>>
>> Signed-off-by: Luis de Bethencourt 
>> ---
>> diff --git a/drivers/staging/rtl8712/usb_ops_linux.c 
>> b/drivers/staging/rtl8712/usb_ops_linux.c
>> index c940722..e33eeed 100644
>> --- a/drivers/staging/rtl8712/usb_ops_linux.c
>> +++ b/drivers/staging/rtl8712/usb_ops_linux.c
>> @@ -266,7 +266,7 @@ u32 r8712_usb_read_port(struct intf_hdl *pintfhdl, u32 
>> addr, u32 cnt, u8 *rmem)
>>  if (adapter->bDriverStopped || adapter->bSurpriseRemoved ||
>>  adapter->pwrctrlpriv.pnp_bstop_trx)
>>  return _FAIL;
>> -if (!precvbuf->reuse == false || !precvbuf->pskb) {
>> +if (precvbuf->reuse || !precvbuf->pskb) {
>>  precvbuf->pskb = skb_dequeue(&precvpriv->free_recv_skb_queue);
>>  if (precvbuf->pskb != NULL)
>>  precvbuf->reuse = true;
> 
> You have transformed this faithfully, but my instinct says that the
> original code is wrong.  It should be:
> 
>   if (!precvbuf->reuse || !precvbuf->pskb) {
> 
> I checked and usb_read_port() is implemented this way in
> drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c.  Again I am going on
> instinct and not a full understanding of the code, but I'm probably
> correct.
> 
> Anyway, this is not related to the patch so we should fix it in a later
> patch, but let's not forget.
> 
> TODO: rtl8712: fix a reversed condition in r8712_usb_read_port()
> 
> regards,
> dan carpenter
> 

Hi Dan,

Thank you for the review. I will study the code and make sure that your
intuition is correct, which initially it sounds to be.

Thanks,
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] block: remove useless casting value returned by kmalloc to structure

[Punit Vara]

This is the patch to the cciss_scsi.c file that resolves following warning
reported by coccicheck:

WARNING: casting value returned by memory allocation function to (struct
cciss_scsi_adapter_data_t *) is useless.

Signed-off-by: Punit Vara 
---
 drivers/block/cciss_scsi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
index 1537302..4c27032 100644
--- a/drivers/block/cciss_scsi.c
+++ b/drivers/block/cciss_scsi.c
@@ -703,8 +703,7 @@ cciss_scsi_setup(ctlr_info_t *h)
struct cciss_scsi_adapter_data_t * shba;
 
ccissscsi[h->ctlr].ndevices = 0;
-   shba = (struct cciss_scsi_adapter_data_t *)
-   kmalloc(sizeof(*shba), GFP_KERNEL); 
+   shba = kmalloc(sizeof(*shba), GFP_KERNEL);
if (shba == NULL)
return;
shba->scsi_host = NULL;
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 11:28:07 schrieb Douglas Anderson:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup.  It appears that the "port reset" bit that's in the USB
> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
> 
> This series of patches exports the "port reset" from the PHY and then
> hooks it up to dwc2 through a quirk.
> 
> I've tested this series atop a bit of a conglomeration of Heiko's github
> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
> usb-next merged in.

I've been involved in the earlier revisions already, so this version already 
implements the review-comments I had. I've also gave this a spin on 4.3-rc6 
with usb-next merged in on a rk3288-firefly, so

Reviewed-by: Heiko Stuebner 
Tested-by: Heiko Stuebner 


If the first two patches get picked up, I'll pick the two dts patches 
afterwards.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] keys, trusted: select TPM2 hash algorithm

[Jarkko Sakkinen]

Added 'hashalg=' option for selecting the hash algorithm.

Currently available options are:

* sha1
* sha256
* sha384
* sha512
* sm3_256

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h  |  5 -
 drivers/char/tpm/tpm2-cmd.c | 34 ++
 include/keys/trusted-type.h |  2 ++
 security/keys/trusted.c |  8 +++-
 4 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a4257a3..4c18f46 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -92,7 +92,10 @@ enum tpm2_algorithms {
TPM2_ALG_SHA1   = 0x0004,
TPM2_ALG_KEYEDHASH  = 0x0008,
TPM2_ALG_SHA256 = 0x000B,
-   TPM2_ALG_NULL   = 0x0010
+   TPM2_ALG_SHA384 = 0x000C,
+   TPM2_ALG_SHA512 = 0x000D,
+   TPM2_ALG_NULL   = 0x0010,
+   TPM2_ALG_SM3_256= 0x0012,
 };
 
 enum tpm2_command_codes {
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index bd7039f..0704bd6 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -104,6 +104,22 @@ struct tpm2_cmd {
union tpm2_cmd_params   params;
 } __packed;
 
+struct tpm2_hashalg {
+   charname[MAX_HASHALG_SIZE];
+   u32 id;
+};
+
+struct tpm2_hashalg tpm2_hashalg_map[] = {
+   {"sha1", TPM2_ALG_SHA1},
+   {"sha256", TPM2_ALG_SHA256},
+   {"sm3_256", TPM2_ALG_SM3_256},
+   {"sha384", TPM2_ALG_SHA384},
+   {"sha512", TPM2_ALG_SHA512},
+};
+
+#define TPM2_HASHALG_COUNT \
+   (sizeof(tpm2_hashalg_map) / sizeof(tpm2_hashalg_map[1]))
+
 /*
  * Array with one entry per ordinal defining the maximum amount
  * of time the chip could take to return the result. The values
@@ -429,8 +445,26 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
 {
unsigned int blob_len;
struct tpm_buf buf;
+   u32 hashalg = TPM2_ALG_SHA256;
+   int i;
int rc;
 
+   if (strlen(options->hashalg) > 0) {
+   for (i = 0; i < TPM2_HASHALG_COUNT; i++) {
+   if (!strcmp(options->hashalg,
+   tpm2_hashalg_map[i].name)) {
+   hashalg = tpm2_hashalg_map[i].id;
+   dev_dbg(chip->pdev, "%s: hashalg: %s 0x%08X\n",
+   __func__, tpm2_hashalg_map[i].name,
+   hashalg);
+   break;
+   }
+   }
+
+   if (i == TPM2_HASHALG_COUNT)
+   return -EINVAL;
+   }
+
rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_CREATE);
if (rc)
return rc;
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index f91ecd9..a545733 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -18,6 +18,7 @@
 #define MAX_KEY_SIZE   128
 #define MAX_BLOB_SIZE  512
 #define MAX_PCRINFO_SIZE   64
+#define MAX_HASHALG_SIZE   16
 
 struct trusted_key_payload {
struct rcu_head rcu;
@@ -36,6 +37,7 @@ struct trusted_key_options {
uint32_t pcrinfo_len;
unsigned char pcrinfo[MAX_PCRINFO_SIZE];
int pcrlock;
+   unsigned char hashalg[MAX_HASHALG_SIZE];
 };
 
 extern struct key_type key_type_trusted;
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index d3633cf..9e7564d 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -710,7 +710,8 @@ enum {
Opt_err = -1,
Opt_new, Opt_load, Opt_update,
Opt_keyhandle, Opt_keyauth, Opt_blobauth,
-   Opt_pcrinfo, Opt_pcrlock, Opt_migratable
+   Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
+   Opt_hashalg,
 };
 
 static const match_table_t key_tokens = {
@@ -723,6 +724,7 @@ static const match_table_t key_tokens = {
{Opt_pcrinfo, "pcrinfo=%s"},
{Opt_pcrlock, "pcrlock=%s"},
{Opt_migratable, "migratable=%s"},
+   {Opt_hashalg, "hashalg=%s"},
{Opt_err, NULL}
 };
 
@@ -787,6 +789,10 @@ static int getoptions(char *c, struct trusted_key_payload 
*pay,
return -EINVAL;
opt->pcrlock = lock;
break;
+   case Opt_hashalg:
+   strncpy(opt->hashalg, args[0].from,
+   MAX_HASHALG_SIZE - 1);
+   break;
default:
return -EINVAL;
}
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] hwmon: ina2xx: port to using remap, improve bandwidth.

[Guenter Roeck]

On 10/23/2015 01:35 PM, Marc Titinger wrote:

Hi Guenter

thanks for the review, answers bellow.


[ ... ]


  /* shunt voltage */
-static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_value, NULL,
+static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_shunt, NULL,
INA2XX_SHUNT_VOLTAGE);


If you no longer use the register parameter, there is no need to provide it.
But then I'll have to spend some time trying to understand _why_ you don't
use it anymore and why you introduced separate show functions.
Some explanation might help.


The interval value is no longer needed to compute a read "gard" delay, but the 
client Application may still need to set a different averaging value through this 
interval setting, based on the DUT characteristics.


I don't really understand what you are saying here, sorry, and what it has
to do with the switch from a single to multiple show functions.


As of using separate functions, it fits better in the new logic of 
"per-register" accesses. It does not bloat the code either.


"It does not bloat the code" is not a valid reason for making such a change,
nor "it fits better" (because that is an opinion). Reducing code size,
or simplifying the code, could be valid reasons.
The change is also technically unrelated to the switch to regmap.
Also, while it may not bloat the code, it definitely bloats the patch size
and makes it much more difficult to review the patch.

Please make only one logical change per patch. So far, we have identified
three independent sets of changes:
- switch to regmap
- switch to separate show functions
- switch to prioritize devicetree data over platform data

and I am not sure if there are more, given the complexity of the patch.

I would expect separate patches to address those changes. Please split
the patch accordingly.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC net-next 0/2] tcp: Redundant Data Bundling (RDB)

[Eric Dumazet]

On Sat, 2015-10-24 at 08:00 +, Jonas Markussen wrote:

> Repacketization is only on retransmissions; RDB bundles previously sent 
> segments with the next “normal” transmission instead. 
> 
> This makes the flow recover the lost segment  before a retransmission is 
> triggered by an RTO or fast retransmit.

Thank you for this very high quality patch submission.

Please give us a few days for proper evaluation.

Thanks !


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] ACPI: Using correct irq when uninstalling acpi irq handler

[Rafael J. Wysocki]

On Thursday, October 22, 2015 08:03:08 PM Chen Yu wrote:
> Currently when system is trying to uninstall the acpi irq
> handler, it uses the acpi_gbl_FADT.sci_interrupt directly.
> But acpi irq handler is actually installed by mapped irq
> in acpi_os_install_interrupt_handler, so this patch fixes
> this problem by using the mapped irq returned from acpi_gsi_to_irq.
> 
> Cc:  # 2.6.39+
> Acked-by: Lv Zheng 
> Signed-off-by: Chen Yu 
> ---
>  drivers/acpi/osl.c   | 10 +++---
>  include/linux/acpi.h |  3 +++
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 739a4a6..2e9eccf 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -81,6 +81,7 @@ static struct workqueue_struct *kacpid_wq;
>  static struct workqueue_struct *kacpi_notify_wq;
>  static struct workqueue_struct *kacpi_hotplug_wq;
>  static bool acpi_os_initialized;
> +unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
>  
>  /*
>   * This list of permanent mappings is for memory that may be accessed from
> @@ -856,17 +857,20 @@ acpi_os_install_interrupt_handler(u32 gsi, 
> acpi_osd_handler handler,
>   acpi_irq_handler = NULL;
>   return AE_NOT_ACQUIRED;
>   }
> + acpi_sci_irq = irq;
>  
>   return AE_OK;
>  }
>  
> -acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler 
> handler)
> +acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler 
> handler)
>  {
> - if (irq != acpi_gbl_FADT.sci_interrupt)
> + if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
> + IS_INVALID_ACPI_IRQ(acpi_sci_irq))

The white space doesn't follow the kernel coding style, should be something
like

if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
IS_INVALID_ACPI_IRQ(acpi_sci_irq))

(spaces instead of the second tab).

Another minor nit is that this probably is the only place you check the
IS_INVALID_ACPI_IRQ(acpi_sci_irq) thing without logical negation and you
only pass acpi_sci_irq to IS_INVALID_ACPI_IRQ() AFAICS.

It would be more straightforward to define something like acpi_sci_irq_valid()
instead (see below) IMO.

>   return AE_BAD_PARAMETER;
>  
> - free_irq(irq, acpi_irq);
> + free_irq(acpi_sci_irq, acpi_irq);
>   acpi_irq_handler = NULL;
> + acpi_sci_irq = INVALID_ACPI_IRQ;
>  
>   return AE_OK;
>  }
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 43856d1..bad159c 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -193,6 +193,9 @@ int acpi_ioapic_registered(acpi_handle handle, u32 
> gsi_base);
>  void acpi_irq_stats_init(void);
>  extern u32 acpi_irq_handled;
>  extern u32 acpi_irq_not_handled;
> +extern unsigned int acpi_sci_irq;
> +#define INVALID_ACPI_IRQ ((unsigned)-1)

#define INVALID_ACPI_IRQ((unsigned int)-1)

> +#define IS_INVALID_ACPI_IRQ(x) unlikely((x) == INVALID_ACPI_IRQ)

Maybe something like:

static inline bool acpi_sci_irq_valid(void)
{
return acpi_sci_irq != INVALID_ACPI_IRQ;
}

>  
>  extern int sbf_port;
>  extern unsigned long acpi_realmode_flags;
> 

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: dwc2: host: Fix ahbcfg for rk3066

[Heiko Stübner]

Am Dienstag, 20. Oktober 2015, 16:33:53 schrieb Douglas Anderson:
> The comment for ahbcfg for rk3066 parameters (also used for rk3288)
> claimed that ahbcfg was INCR16, but it wasn't.  Since the bits weren't
> shifted properly, the 0x7 ended up being masked and we ended up
> programming 0x3 for the HBstLen.  Let's set it to INCR16 properly.
> 
> As per Wu Liang Feng at Rockchip this may increase transmission
> efficiency.  I did blackbox tests with writing 0s to a USB-based SD
> reader (forcefully capping CPU Freq to try to measure efficiency):
>   cd /sys/devices/system/cpu/cpu0/cpufreq
>   echo userspace > scaling_governor
>   echo 126000 > scaling_setspeed
>   for i in $(seq 10); do
> dd if=/dev/zero of=/dev/sdb bs=1M count=750
>   done
> 
> With the above tests I found that speeds went from ~15MB/s to ~18MB/s.
> Note that most other tests I did (including reading from the same USB
> reader) didn't show any difference in performance.
> 
> Signed-off-by: Douglas Anderson 

I gave this a spin on a rk3288-firefly, runs fine and doesn't have any 
negative effects, so

Tested-by: Heiko Stuebner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/46] 4.1.12-stable review

[Greg Kroah-Hartman]

On Fri, Oct 23, 2015 at 08:15:09PM -0700, Guenter Roeck wrote:
> On 10/23/2015 10:45 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.1.12 release.
> >There are 46 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Oct 25 17:46:11 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 137 pass: 135 fail: 2
> Failed builds:
>   powerpc:defconfig
>   powerpc:allmodconfig
> 
> Qemu test results:
>   total: 93 pass: 92 fail: 1
> Failed tests:
>   powerpc:pseries_defconfig
> 
> Applying c56dadf39761 ("sched/preempt, powerpc, kvm: Use need_resched()
> instead of should_resched()") should fix the problem.
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing, and for the git commit id, yeah, we did this already
for 4.2...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 00/54] 4.2.5-stable review

[Greg Kroah-Hartman]

On Fri, Oct 23, 2015 at 07:04:21PM -0700, Guenter Roeck wrote:
> On 10/23/2015 10:44 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.2.5 release.
> >There are 54 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Oct 25 17:45:07 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 144 pass: 144 fail: 0
> Qemu test results:
>   total: 93 pass: 93 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing all of these and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

[Rafael J. Wysocki]

On Thursday, October 22, 2015 04:27:10 PM Scott Wood wrote:
> On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 00:51, Scott Wood  wrote:
> > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
> > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood 
> > > > wrote:
> > > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> > > > > > Instead of trying to match and probe platform and AMBA devices right
> > > > > > after each is registered, delay their probes until 
> > > > > > device_initcall_sync.
> > > > > > 
> > > > > > This means that devices will start probing once all built-in drivers
> > > > > > have registered, and after all platform and AMBA devices from the DT
> > > > > > have been registered already.
> > > > > > 
> > > > > > This allows us to prevent deferred probes by probing dependencies on
> > > > > > demand.
> > > > > > 
> > > > > > Signed-off-by: Tomeu Vizoso 
> > > > > > ---
> > > > > > 
> > > > > > Changes in v4:
> > > > > > - Also defer probes of AMBA devices registered from the DT as they 
> > > > > > can
> > > > > >   also request resources.
> > > > > > 
> > > > > >  drivers/of/platform.c | 11 ---
> > > > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > > 
> > > > > This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF 
> > > > > platform
> > > > > device, and it must be probed before pcibios_init() which is a
> > > > > subsys_initcall(), or else the PCI bus never gets scanned.
> > > > 
> > > > Thanks for the report. This is probably getting dropped, but it could
> > > > be disabled for PPC.
> > > 
> > > I don't think that adding another arbitrary arch difference would be the
> > > right solution.
> > 
> > I think Rob meant temporarily disable it while things get fixed. At
> > least, 
> 
> So, what is the permanent fix for the swiotlb issue (or more generally, the 
> inability to have a late_initcall that runs after non-module, non-hotplug 
> platform devices have been probed)?
> 
> > I don't see any reason why PPC wouldn't benefit from this
> > series.
> 
> It's not clear to me what the benefit of this is at all, much less for PPC.   
> What is the fundamental problem with deferred probes?  In the cover letter 
> you say this change saves 2.3 seconds, but where is that time being consumed? 
>  Are the drivers taking too long in their probe function trying to initialize 
> and then deferring, rather than checking for dependencies up front?  Or are 
> there really so many devices and such a pessimal ordering that most of the 
> time is spent iterating through and reordering the list, with each defer 
> happening quickly?
> 
> Even if something different does need to be done at this level, forcing all 
> OF platform devices to be probed at the late_initcall level seems quite 
> intrusive.

Totally agreed.

> You limited it to OF because people complained that other things 
> will break.

Right.

And I'm not sure why that was regarded as a good enough reason to do it.

> Things still broke.

Yes, they did.

> Surely there's a better way to address the 
> problem.  Can't the delay be requested by drivers that might otherwise need 
> to defer (which could be done incrementally, focusing on the worst 
> performance problems), rather than enabling it for everything?

Well, I was suggesting to use an opt-in flag there, but I'm not sure if Tomeu
took that into consideration.

In any case, probing is just one aspect of a deeper issue, which is that
we have no way to represent functional dependencies between devices.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Rafael J. Wysocki]

On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:06, Rafael J. Wysocki  wrote:
> > On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
> >> Walks the OF tree up and finds the closest ancestor that has a struct
> >> device associated with it, probing it if isn't bound to a driver yet.
> >>
> >> The above should ensure that the dependency represented by the passed OF
> >> node is available, because probing a device should cause its descendants
> >> to be probed as well (when they get registered).
> >>
> >> Subsystems can use this when looking up resources for drivers, to reduce
> >> the chances of deferred probes because of the probing order of devices.
> >>
> >> Signed-off-by: Tomeu Vizoso 
> >> ---
> >>
> >> Changes in v5:
> >> - Move the assignment to device_node->device for AMBA devices to another
> >>   commit.
> >> - Hold a reference to the struct device while it's in use in
> >>   of_device_probe().
> >>
> >> Changes in v4:
> >> - Rename of_platform_probe to of_device_probe
> >> - Use device_node.device instead of device_node.platform_dev
> >>
> >> Changes in v3:
> >> - Set and use device_node.platform_dev instead of reversing the logic to
> >>   find the platform device that encloses a device node.
> >> - Drop the fwnode API to probe firmware nodes and add OF-only API for
> >>   now. I think this same scheme could be used for machines with ACPI,
> >>   but I haven't been able to find one that had to defer its probes because
> >>   of the device probe order.
> >>
> >>  drivers/of/device.c   | 61 
> >> +++
> >>  include/linux/of_device.h |  3 +++
> >>  2 files changed, 64 insertions(+)
> >>
> >> diff --git a/drivers/of/device.c b/drivers/of/device.c
> >> index 8b91ea241b10..836be71fc90e 100644
> >> --- a/drivers/of/device.c
> >> +++ b/drivers/of/device.c
> >> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, 
> >> struct kobj_uevent_env *env)
> >>
> >>   return 0;
> >>  }
> >> +
> >> +/**
> >> + * of_device_probe() - Probe device associated with OF node
> >> + * @np: node to probe
> >> + *
> >> + * Probe the device associated with the passed device node.
> >> + */
> >> +void of_device_probe(struct device_node *np)
> >
> > Same question as from Greg: How does a subsystem know whether or not to use
> > this function?
> 
> Maybe I don't understand the comment, but as the commit message says,
> subsystems can use this when looking up resources for drivers. Or you
> mean that this information should be in the API docs?

I'm not really sure this is the only case.

Most likely, you'd end up with that being called by every subsystem using DT
just in case.

And then each of those subsystems would need to call acpi_device_probe(), and
then another_platform_firmware_interface_device_probe() and so on.

Don't you see a problem here?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 03/22] of/platform: Point to struct device from device node

[Rafael J. Wysocki]

On Thursday, October 22, 2015 03:01:45 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:02, Rafael J. Wysocki  wrote:
> > On Monday, September 21, 2015 04:02:43 PM Tomeu Vizoso wrote:
> >> When adding platform and AMBA devices, set the device node's device
> >> member to point to it.
> >>
> >> This speeds lookups considerably and is safe because we only create one
> >> of these devices for any given device node.
> >>
> >> Signed-off-by: Tomeu Vizoso 
> >> ---
> >>
> >> Changes in v5:
> >> - Set the pointer to struct device also for AMBA devices
> >> - Unset the pointer to struct device when the platform device is about
> >>   to be unregistered
> >> - Increase the reference count of the device before returning from
> >>   of_find_device_by_node()
> >>
> >>  drivers/of/platform.c | 19 ++-
> >>  include/linux/of.h|  1 +
> >>  2 files changed, 11 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index 1001efaedcb8..408d89f1d124 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -32,11 +32,6 @@ const struct of_device_id of_default_bus_match_table[] 
> >> = {
> >>   {} /* Empty terminated list */
> >>  };
> >>
> >> -static int of_dev_node_match(struct device *dev, void *data)
> >> -{
> >> - return dev->of_node == data;
> >> -}
> >> -
> >>  /**
> >>   * of_find_device_by_node - Find the platform_device associated with a 
> >> node
> >>   * @np: Pointer to device tree node
> >> @@ -45,10 +40,10 @@ static int of_dev_node_match(struct device *dev, void 
> >> *data)
> >>   */
> >>  struct platform_device *of_find_device_by_node(struct device_node *np)
> >>  {
> >> - struct device *dev;
> >> -
> >> - dev = bus_find_device(&platform_bus_type, NULL, np, 
> >> of_dev_node_match);
> >> - return dev ? to_platform_device(dev) : NULL;
> >> + if (np->device && np->device->bus == &platform_bus_type &&
> >> + get_device(np->device))
> >> + return to_platform_device(np->device);
> >> + return NULL;
> >>  }
> >>  EXPORT_SYMBOL(of_find_device_by_node);
> >>
> >> @@ -192,6 +187,8 @@ static struct platform_device 
> >> *of_platform_device_create_pdata(
> >>   goto err_clear_flag;
> >>   }
> >>
> >> + np->device = &dev->dev;
> >> +
> >>   return dev;
> >>
> >>  err_clear_flag:
> >> @@ -272,6 +269,8 @@ static struct amba_device 
> >> *of_amba_device_create(struct device_node *node,
> >>   goto err_free;
> >>   }
> >>
> >> + node->device = &dev->dev;
> >> +
> >>   return dev;
> >>
> >>  err_free:
> >> @@ -476,6 +475,8 @@ static int of_platform_device_destroy(struct device 
> >> *dev, void *data)
> >>   if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
> >>   device_for_each_child(dev, NULL, of_platform_device_destroy);
> >>
> >> + dev->of_node->device = NULL;
> >> +
> >>   if (dev->bus == &platform_bus_type)
> >>   platform_device_unregister(to_platform_device(dev));
> >>  #ifdef CONFIG_ARM_AMBA
> >> diff --git a/include/linux/of.h b/include/linux/of.h
> >> index 2194b8ca41f9..eb091be0f8ee 100644
> >> --- a/include/linux/of.h
> >> +++ b/include/linux/of.h
> >> @@ -52,6 +52,7 @@ struct device_node {
> >>   phandle phandle;
> >>   const char *full_name;
> >>   struct fwnode_handle fwnode;
> >> + struct device *device;
> >
> > There are cases in which multiple device objects point to the same 
> > device_node,
> > so is the single struct device pointer here really sufficient?
> 
> Only one struct device is registered for a given DT device node when
> the DT is scanned (otherwise, of_find_device_by_node wouldn't be
> safe).
> 
> If some driver makes a struct device to point to a device_node that
> already has a struct device associated with it, that's fine.

Well, once that has happened, your new device pointer in the given device_node
becomes useless.  Why exactly is that fine?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird  wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> 
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>  But that's moot currently because Greg believes that the time spent
>  probing devices at boot time could be reduced enough so that the order
>  in which devices are probed becomes irrelevant. IME that would have to
>  be under 200ms so that the user doesn't notice and that's unicorn-far
>  from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent?  What driver is causing long
> >>> delays?  Why is the long-delay-drivers not being done in their own
> >>> thread?  And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
>  Given that downstreams are already carrying as many hacks as they
>  could think of to speed total boot up, I think this is effectively
>  telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time.  But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot 
> >> sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >>With this series I get the kernel to output to the panel in 0.5s,
> >>instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system.  So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
> 
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timeconst: update path in comment

[Nicholas Mc Guire]

On Thu, Oct 22, 2015 at 05:31:17PM +0200, Jason A. Donenfeld wrote:
> It's understandable nobody really cares about applying this patch,
> since it's mostly just cosmetic. But it would be nice to know that
> somebody out there cares about consistency like I do. It would also
> help out the next person who's debugging time things and says "where
> is that darn .bc file?".
>

seems like this was missed when things got moved into kernel/time
thanks for fixing this.
 
> On Tue, Jul 14, 2015 at 7:24 PM, Jason A. Donenfeld  wrote:
> > Signed-off-by: Jason A. Donenfeld 
> > ---
> >  kernel/time/timeconst.bc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc
> > index c7388de..c486889 100644
> > --- a/kernel/time/timeconst.bc
> > +++ b/kernel/time/timeconst.bc
> > @@ -39,7 +39,7 @@ define fmuls(b,n,d) {
> >  }
> >
> >  define timeconst(hz) {
> > -   print "/* Automatically generated by kernel/timeconst.bc */\n"
> > +   print "/* Automatically generated by kernel/time/timeconst.bc */\n"
> > print "/* Time conversion constants for HZ == ", hz, " */\n"
> > print "\n"
> >
> > --
> > 2.4.5
> >

thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: sun4i-codec: use consistent names for PA controls

[Adam Sampson]

The power amplifier for the headphone output is called "the PA" and "the
headphone amplifier" in Allwinner's documentation for the A10 and A20.
sun4i-codec calls it "PA" in some places and "Pre-Amplifier" (which
isn't really accurate) in others, leading to user-visible controls with
different names referring to the same device.

When this driver implements audio input, it'll also need to expose
controls for the line and mic input preamps, so just referring to "the
Pre-Amplifier" will be ambiguous.

Change it to use "PA" consistently for the power amplifier.

Signed-off-by: Adam Sampson 
---
 sound/soc/sunxi/sun4i-codec.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index bcbf4da..ff3304d 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -2,6 +2,7 @@
  * Copyright 2014 Emilio López 
  * Copyright 2014 Jon Smirl 
  * Copyright 2015 Maxime Ripard 
+ * Copyright 2015 Adam Sampson 
  *
  * Based on the Allwinner SDK driver, released under the GPL.
  *
@@ -452,12 +453,12 @@ static const struct snd_soc_dapm_widget 
sun4i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("Mixer Enable", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_MIXEN, 0, NULL, 0),
 
-   /* Pre-Amplifier */
-   SND_SOC_DAPM_MIXER("Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
+   /* Headphone output power amplifier */
+   SND_SOC_DAPM_MIXER("PA", SUN4I_CODEC_ADC_ACTL,
   SUN4I_CODEC_ADC_ACTL_PA_EN, 0,
   sun4i_codec_pa_mixer_controls,
   ARRAY_SIZE(sun4i_codec_pa_mixer_controls)),
-   SND_SOC_DAPM_SWITCH("Pre-Amplifier Mute", SND_SOC_NOPM, 0, 0,
+   SND_SOC_DAPM_SWITCH("PA Mute", SND_SOC_NOPM, 0, 0,
&sun4i_codec_pa_mute),
 
SND_SOC_DAPM_OUTPUT("HP Right"),
@@ -480,16 +481,16 @@ static const struct snd_soc_dapm_route 
sun4i_codec_dapm_routes[] = {
{ "Left Mixer", NULL, "Mixer Enable" },
{ "Left Mixer", "Left DAC Playback Switch", "Left DAC" },
 
-   /* Pre-Amplifier Mixer Routes */
-   { "Pre-Amplifier", "Mixer Playback Switch", "Left Mixer" },
-   { "Pre-Amplifier", "Mixer Playback Switch", "Right Mixer" },
-   { "Pre-Amplifier", "DAC Playback Switch", "Left DAC" },
-   { "Pre-Amplifier", "DAC Playback Switch", "Right DAC" },
+   /* PA Mixer Routes */
+   { "PA", "Mixer Playback Switch", "Left Mixer" },
+   { "PA", "Mixer Playback Switch", "Right Mixer" },
+   { "PA", "DAC Playback Switch", "Left DAC" },
+   { "PA", "DAC Playback Switch", "Right DAC" },
 
/* PA -> HP path */
-   { "Pre-Amplifier Mute", "Switch", "Pre-Amplifier" },
-   { "HP Right", NULL, "Pre-Amplifier Mute" },
-   { "HP Left", NULL, "Pre-Amplifier Mute" },
+   { "PA Mute", "Switch", "PA" },
+   { "HP Right", NULL, "PA Mute" },
+   { "HP Left", NULL, "PA Mute" },
 };
 
 static struct snd_soc_codec_driver sun4i_codec_codec = {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V1 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization.

[Tomasz Nowicki]

On 10/24/2015 12:20 PM, Hanjun Guo wrote:

On 2015/10/15 22:05, Tomasz Nowicki wrote:

After refactoring DT code, we let ACPI to build ITS PCI MSI domain
and do requester ID to device ID translation using IORT table.

We have now full PCI MSI domain stack, thus we can enable ITS initialization
from GICv3 core driver for ACPI scenario.

Signed-off-by: Tomasz Nowicki 
---
  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 48 ++--
  drivers/irqchip/irq-gic-v3.c |  3 +-
  2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cfd35da..09ae2d8 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -15,6 +15,8 @@
   * along with this program.  If not, see .
   */

+#include 
+#include 
  #include 
  #include 
  #include 
@@ -59,8 +61,10 @@ static int its_pci_msi_vec_count(struct pci_dev *pdev)
  static int its_get_pci_alias(struct pci_dev *pdev, u16 alias, void *data)
  {
struct its_pci_alias *dev_alias = data;
+   u32 dev_id;

-   dev_alias->dev_id = alias;
+   dev_alias->dev_id = iort_find_pci_id(pdev, alias, &dev_id) == 0 ?
+   dev_id : alias;


Hi tomasz, I think we need to re work this patch on top of tip/irq/core
which has support for "msi-map" and "mai-parent" property support.



Indeed, I will rebase after some more comments related to other patches 
in this series.


Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Rafael J. Wysocki]

On Friday, October 23, 2015 08:54:19 AM Mark Brown wrote:
> 
> --7cm2iqirTL37Ot+N
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 03:06, Rafael J. Wysocki  wrote:
> 
> > > Same question as from Greg: How does a subsystem know whether or not to 
> > > use
> > > this function?
> 
> > Maybe I don't understand the comment, but as the commit message says,
> > subsystems can use this when looking up resources for drivers. Or you
> > mean that this information should be in the API docs?
> 
> I'm pretty sure what he's suggesting here is changing to "should always"
> (ie, explain the situations when a subsystem would do this, including
> decision criteria if it's optional).

Right.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[David Miller]

From: Mans Rullgard 
Date: Thu, 22 Oct 2015 17:28:50 +0100

> +static void nb8800_mac_tx(struct net_device *dev, int enable)
 ...
> +static void nb8800_mac_rx(struct net_device *dev, int enable)
 ...
> +static void nb8800_mac_af(struct net_device *dev, int enable)

Please use 'bool' and true/false for 'enable'.

> +static int nb8800_alloc_rx(struct net_device *dev, int i, int napi)

Likewise here for 'napi'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] block: enable dax for raw block devices

[Jan Kara]

On Thu 22-10-15 23:41:27, Williams, Dan J wrote:
> On Thu, 2015-10-22 at 23:08 +0200, Jan Kara wrote:
> > On Thu 22-10-15 16:05:46, Williams, Dan J wrote:
> > > On Thu, 2015-10-22 at 11:35 +0200, Jan Kara wrote:
> > > > On Thu 22-10-15 02:42:11, Dan Williams wrote:
> > > > > If an application wants exclusive access to all of the persistent 
> > > > > memory
> > > > > provided by an NVDIMM namespace it can use this raw-block-dax facility
> > > > > to forgo establishing a filesystem.  This capability is targeted
> > > > > primarily to hypervisors wanting to provision persistent memory for
> > > > > guests.
> > > > > 
> > > > > Cc: Jan Kara 
> > > > > Cc: Jeff Moyer 
> > > > > Cc: Christoph Hellwig 
> > > > > Cc: Dave Chinner 
> > > > > Cc: Andrew Morton 
> > > > > Cc: Ross Zwisler 
> > > > > Signed-off-by: Dan Williams 
> > > > > ---
> > > > >  fs/block_dev.c |   54 
> > > > > +-
> > > > >  1 file changed, 53 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/fs/block_dev.c b/fs/block_dev.c
> > > > > index 3255dcec96b4..c27cd1a21a13 100644
> > > > > --- a/fs/block_dev.c
> > > > > +++ b/fs/block_dev.c
> > > > > @@ -1687,13 +1687,65 @@ static const struct address_space_operations 
> > > > > def_blk_aops = {
> > > > >   .is_dirty_writeback = buffer_check_dirty_writeback,
> > > > >  };
> > > > >  
> > > > > +#ifdef CONFIG_FS_DAX
> > > > > +/*
> > > > > + * In the raw block case we do not need to contend with truncation 
> > > > > nor
> > > > > + * unwritten file extents.  Without those concerns there is no need 
> > > > > for
> > > > > + * additional locking beyond the mmap_sem context that these routines
> > > > > + * are already executing under.
> > > > > + *
> > > > > + * Note, there is no protection if the block device is dynamically
> > > > > + * resized (partition grow/shrink) during a fault. A stable block 
> > > > > device
> > > > > + * size is already not enforced in the blkdev_direct_IO path.
> > > > > + *
> > > > > + * For DAX, it is the responsibility of the block device driver to
> > > > > + * ensure the whole-disk device size is stable while requests are in
> > > > > + * flight.
> > > > > + *
> > > > > + * Finally, these paths do not synchronize against freezing
> > > > > + * (sb_start_pagefault(), etc...) since bdev_sops does not support
> > > > > + * freezing.
> > > > 
> > > > Well, for devices freezing is handled directly in the block layer code
> > > > (blk_stop_queue()) since there's no need to put some metadata structures
> > > > into a consistent state. So the comment about bdev_sops is somewhat
> > > > strange.
> > > 
> > > This text was aimed at the request from Ross to document the differences
> > > vs the generic_file_mmap() path.  Is the following incremental change
> > > more clear?
> > 
> > Well, not really. I thought you'd just delete that paragraph :) The thing
> > is: When doing IO directly to the block device, it makes no sense to look
> > at a filesystem on top of it - hopefully there is none since you'd be
> > corrupting it. So the paragraph that would make sense to me would be:
> > 
> >  * Finally, in contrast to filemap_page_mkwrite(), we don't bother calling
> >  * sb_start_pagefault(). There is no filesystem which could be frozen here
> >  * and when bdev gets frozen, IO gets blocked in the request queue.
> > 
> > But when spelled out like this, I've realized that with DAX, this blocking
> > of requests in the request queue doesn't really block the IO to the device.
> > So block device freezing (aka blk_queue_stop()) doesn't work reliably with
> > DAX. That should be fixed but it's not easy as the only way to do that
> > would be to hook into blk_stop_queue() and unmap (or at least
> > write-protect) all the mappings of the device. Ugh...
> > 
> > Ugh2: Now I realized that DAX mmap isn't safe wrt fs freezing even for
> > filesystems since there's nothing which writeprotects pages that are
> > writeably mapped. In normal path, page writeback does this but that doesn't
> > happen for DAX. I remember we once talked about this but it got lost.
> > We need something like walk all filesystem inodes during fs freeze and
> > writeprotect all pages that are mapped. But that's going to be slow...
> 
> This sounds suspiciously like what I'm planning to do for the device
> teardown path when we've dynamically allocated struct page.  The backing
> memory for those pages is freed when the driver runs its ->remove()
> path, so we have to be sure there are no outstanding references to them.
> 
> My current proposal for the teardown case, that we might re-purpose for
> this freeze case, is below.  It relies on the percpu_ref in the
> request_queue to block new faults and then uses truncate_pagecache() to
> teardown mappings.  However, this assumes we've inserted pages into the
> address_space radix at fault, which we don't currently do...

Well, for the freeze case it is enough to call unmap_mapping_range() for
each inode->i

BUSINESS VORSCHLAG

[Mr chin sang]

BUSINESS VORSCHLAG



 Ich bin mit diesem Medium, um Sie über die Transaktion zur Abgabe
von $ 2150 (einundzwanzig Millionen fünfhunderttausend US-Dollar) auf
meinem Bank in China, Sie als Empfänger zu informieren. Es ist 100%
sicher, wobei der Finanzvorstand des verstorbenen Kunden.



 Bitte auf meine private E-Mail kontaktieren unter Für Fragen und
weitere Informationen.



 Mit freundlichen Grüßen,



 sang Chin

 e-mail: chinsan...@gmail.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtc: ds1307: Fix alarm programming for mcp794xx

[Nishanth Menon]

On 10/23/2015 01:29 AM, Tero Kristo wrote:
> mcp794xx alarm registers must be written in BCD format. However, the
> alarm programming logic neglected this by adding one to the value
> after bin2bcd conversion has been already done, writing bad values
> to month register in case the alarm being set is in October. In this
> case, the alarm month value becomes 0x0a instead of the expected 0x10.
> 
> Fix by moving the +1 addition within the bin2bcd call also.
> 
> Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for 
> mcp7941x chips")
> 
> Signed-off-by: Tero Kristo 

Nice catch.
Acked-by: Nishanth Menon 
> ---
>  drivers/rtc/rtc-ds1307.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index a705e64..188006c 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -718,9 +718,9 @@ static int mcp794xx_set_alarm(struct device *dev, struct 
> rtc_wkalrm *t)
>   regs[3] = bin2bcd(t->time.tm_sec);
>   regs[4] = bin2bcd(t->time.tm_min);
>   regs[5] = bin2bcd(t->time.tm_hour);
> - regs[6] = bin2bcd(t->time.tm_wday) + 1;
> + regs[6] = bin2bcd(t->time.tm_wday + 1);
>   regs[7] = bin2bcd(t->time.tm_mday);
> - regs[8] = bin2bcd(t->time.tm_mon) + 1;
> + regs[8] = bin2bcd(t->time.tm_mon + 1);
>  
>   /* Clear the alarm 0 interrupt flag. */
>   regs[6] &= ~MCP794XX_BIT_ALMX_IF;
> 


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch 01/12] PCI: Add virtfn_index for struct pci_device

[Lan, Tianyu]

On 10/22/2015 2:07 AM, Alexander Duyck wrote:

On 10/21/2015 09:37 AM, Lan Tianyu wrote:

Add "virtfn_index" member in the struct pci_device to record VF sequence
of PF. This will be used in the VF sysfs node handle.

Signed-off-by: Lan Tianyu 
---
  drivers/pci/iov.c   | 1 +
  include/linux/pci.h | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..065b6bb 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -136,6 +136,7 @@ static int virtfn_add(struct pci_dev *dev, int id,
int reset)
  virtfn->physfn = pci_dev_get(dev);
  virtfn->is_virtfn = 1;
  virtfn->multifunction = 0;
+virtfn->virtfn_index = id;
  for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
  res = &dev->resource[i + PCI_IOV_RESOURCES];
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..85c5531 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -356,6 +356,7 @@ struct pci_dev {
  unsigned intio_window_1k:1;/* Intel P2P bridge 1K I/O
windows */
  unsigned intirq_managed:1;
  pci_dev_flags_t dev_flags;
+unsigned intvirtfn_index;
  atomic_tenable_cnt;/* pci_enable_device has been called */
  u32saved_config_space[16]; /* config space saved at
suspend time */



Can't you just calculate the VF index based on the VF BDF number
combined with the information in the PF BDF number and VF
offset/stride?  Seems kind of pointless to add a variable that is only
used by one driver and is in a slowpath when you can just calculate it
pretty quickly.


Good suggestion. Will try it.



- Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] block: enable dax for raw block devices

[Jan Kara]

On Fri 23-10-15 16:32:57, Dan Williams wrote:
> On Thu, Oct 22, 2015 at 2:08 PM, Jan Kara  wrote:
> > On Thu 22-10-15 16:05:46, Williams, Dan J wrote:
> [..]
> >> This text was aimed at the request from Ross to document the differences
> >> vs the generic_file_mmap() path.  Is the following incremental change
> >> more clear?
> >
> > Well, not really. I thought you'd just delete that paragraph :) The thing
> > is: When doing IO directly to the block device, it makes no sense to look
> > at a filesystem on top of it - hopefully there is none since you'd be
> > corrupting it. So the paragraph that would make sense to me would be:
> >
> >  * Finally, in contrast to filemap_page_mkwrite(), we don't bother calling
> >  * sb_start_pagefault(). There is no filesystem which could be frozen here
> >  * and when bdev gets frozen, IO gets blocked in the request queue.
> 
> I'm not following this assertion that "IO gets blocked in the request
> queue" when the device is frozen in the code.  As far as I can see
> outside of tracking the freeze depth count the request_queue does not
> check if the device is frozen.   freeze_bdev() is moot when no
> filesystem is a present.

Yes, how e.g. dm freezes devices when it wants to do a snapshot is that it
first calls freeze_bdev() (to stop fs when there is one) and then calls
blk_stop_queue() to block all the IO requests in the request queue. In this
sense freeze_bdev() is somewhat a misnomer since it doesn't make sure no IO
is submitted to the bdev.

> > But when spelled out like this, I've realized that with DAX, this blocking
> > of requests in the request queue doesn't really block the IO to the device.
> > So block device freezing (aka blk_queue_stop()) doesn't work reliably with
> > DAX. That should be fixed but it's not easy as the only way to do that
> > would be to hook into blk_stop_queue() and unmap (or at least
> > write-protect) all the mappings of the device. Ugh...
> 
> Again I'm missing how this is guaranteed in the non-DAX case.
> freeze_bdev() will sync_blockdev(), but it does nothing to prevent
> re-dirtying through raw device mmaps while the fs in frozen.  Should
> it?  That's at least a separate patch.

It doesn't have to - after blk_stop_queue() is called no IO is submitted to
the device and snapshotting happens in the level below bdev page cache so
we don't care about modifications happening there. But with DAX things are
different as we directly map device pages into page cache so we have to
make sure no modifications of page cache happen.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/9] soc: ti: knav_qmss_queue: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/soc/ti/knav_qmss_queue.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 89789e2..6f3d12b 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1074,6 +1074,7 @@ static int knav_queue_setup_regions(struct knav_device 
*kdev,
region = devm_kzalloc(dev, sizeof(*region), GFP_KERNEL);
if (!region) {
dev_err(dev, "out of memory allocating region\n");
+   of_node_put(child);
return -ENOMEM;
}
 
@@ -1373,6 +1374,7 @@ static int knav_queue_init_qmgrs(struct knav_device *kdev,
qmgr = devm_kzalloc(dev, sizeof(*qmgr), GFP_KERNEL);
if (!qmgr) {
dev_err(dev, "out of memory allocating qmgr\n");
+   of_node_put(child);
return -ENOMEM;
}
 
@@ -1450,6 +1452,7 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
pdsp = devm_kzalloc(dev, sizeof(*pdsp), GFP_KERNEL);
if (!pdsp) {
dev_err(dev, "out of memory allocating pdsp\n");
+   of_node_put(child);
return -ENOMEM;
}
pdsp->name = knav_queue_find_name(child);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/9] powerpc/powernv: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-powernv.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index 2c5c5b1..1e75e1f 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -262,15 +262,19 @@ static int powernv_led_classdev(struct platform_device 
*pdev,
while ((cur = of_prop_next_string(p, cur)) != NULL) {
powernv_led = devm_kzalloc(dev, sizeof(*powernv_led),
   GFP_KERNEL);
-   if (!powernv_led)
+   if (!powernv_led) {
+   of_node_put(np);
return -ENOMEM;
+   }
 
powernv_led->common = powernv_led_common;
powernv_led->loc_code = (char *)np->name;
 
rc = powernv_led_create(dev, powernv_led, cur);
-   if (rc)
+   if (rc) {
+   of_node_put(np);
return rc;
+   }
} /* while end */
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/9] Bluetooth: btmrvl: add missing of_node_put

[Julia Lawall]

for_each_compatible_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression e;
local idexpression n;
@@

 for_each_compatible_node(n, ...) {
   ... when != of_node_put(n)
   when != e = n
(
   return n;
|
+  of_node_put(n);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/bluetooth/btmrvl_main.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 6ba2286..6af9173 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -516,14 +516,17 @@ static int btmrvl_check_device_tree(struct btmrvl_private 
*priv)
ret = of_property_read_u8_array(dt_node, "btmrvl,cal-data",
cal_data + BT_CAL_HDR_LEN,
BT_CAL_DATA_SIZE);
-   if (ret)
+   if (ret) {
+   of_node_put(dt_node);
return ret;
+   }
 
BT_DBG("Use cal data from device tree");
ret = btmrvl_download_cal_data(priv, cal_data,
   BT_CAL_DATA_SIZE);
if (ret) {
BT_ERR("Fail to download calibrate data");
+   of_node_put(dt_node);
return ret;
}
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 9/9] pinctrl: at91: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/pinctrl/pinctrl-at91.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index ce6e589..0d2fc0c 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1122,8 +1122,10 @@ static int at91_pinctrl_parse_functions(struct 
device_node *np,
func->groups[i] = child->name;
grp = &info->groups[grp_index++];
ret = at91_pinctrl_parse_groups(child, grp, info, i++);
-   if (ret)
+   if (ret) {
+   of_node_put(child);
return ret;
+   }
}
 
return 0;
@@ -1196,6 +1198,7 @@ static int at91_pinctrl_probe_dt(struct platform_device 
*pdev,
ret = at91_pinctrl_parse_functions(child, info, i++);
if (ret) {
dev_err(&pdev->dev, "failed to parse function\n");
+   of_node_put(child);
return ret;
}
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/9] gpu: host1x: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/host1x/bus.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 4a99c64..c1795a2 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -82,8 +82,10 @@ static int host1x_device_parse_dt(struct host1x_device 
*device,
if (of_match_node(driver->subdevs, np) &&
of_device_is_available(np)) {
err = host1x_subdev_add(device, np);
-   if (err < 0)
+   if (err < 0) {
+   of_node_put(np);
return err;
+   }
}
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/9] leds: bcm6328: add missing of_node_put

[Julia Lawall]

for_each_available_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_available_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-bcm6328.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
index 18de094..c7ea5c6 100644
--- a/drivers/leds/leds-bcm6328.c
+++ b/drivers/leds/leds-bcm6328.c
@@ -403,8 +403,10 @@ static int bcm6328_leds_probe(struct platform_device *pdev)
rc = bcm6328_led(dev, child, reg, mem, lock,
 blink_leds, blink_delay);
 
-   if (rc < 0)
+   if (rc < 0) {
+   of_node_put(child);
return rc;
+   }
}
 
return 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] ACPI/APEI/EINJ: Allow memory error injection to NVDIMM

[Rafael J. Wysocki]

On Friday, October 23, 2015 12:53:59 PM Toshi Kani wrote:
> In the case of memory error injection, einj_error_inject() checks
> if a target address is regular RAM.  Update this check to add a call
> to region_intersects_pmem() to verify if a target address range is
> NVDIMM.  This allows injecting a memory error to both RAM and NVDIMM
> for testing.
> 
> Also, the current RAM check, page_is_ram(), is replaced with
> region_intersects_ram() so that it can verify a target address
> range with the requested size.
> 
> Signed-off-by: Toshi Kani 

This is fine by me, but adding RAS maintainers Tony and Boris.

Thanks,
Rafael


> ---
>  drivers/acpi/apei/einj.c |   12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
> index 0431883..ab55bbe 100644
> --- a/drivers/acpi/apei/einj.c
> +++ b/drivers/acpi/apei/einj.c
> @@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 
> param1, u64 param2,
>u64 param3, u64 param4)
>  {
>   int rc;
> - unsigned long pfn;
> + u64 base_addr, size;
>  
>   /* If user manually set "flags", make sure it is legal */
>   if (flags && (flags &
> @@ -545,10 +545,14 @@ static int einj_error_inject(u32 type, u32 flags, u64 
> param1, u64 param2,
>   /*
>* Disallow crazy address masks that give BIOS leeway to pick
>* injection address almost anywhere. Insist on page or
> -  * better granularity and that target address is normal RAM.
> +  * better granularity and that target address is normal RAM or
> +  * NVDIMM.
>*/
> - pfn = PFN_DOWN(param1 & param2);
> - if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
> + base_addr = param1 & param2;
> + size = (~param2) + 1;
> + if (((region_intersects_ram(base_addr, size) != REGION_INTERSECTS) &&
> +  (region_intersects_pmem(base_addr, size) != REGION_INTERSECTS)) ||
> + ((param2 & PAGE_MASK) != PAGE_MASK))
>   return -EINVAL;
>  
>  inject:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/9] add missing of_node_put

[Julia Lawall]

The various for_each device_node iterators performs an of_node_get on each
iteration, so a break out of the loop requires an of_node_put.

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

// 
@r@
local idexpression n;
expression e1,e2;
iterator name for_each_node_by_name, for_each_node_by_type,
for_each_compatible_node, for_each_matching_node,
for_each_matching_node_and_match, for_each_child_of_node,
for_each_available_child_of_node, for_each_node_with_property;
iterator i;
statement S;
expression list [n1] es;
@@

(
(
for_each_node_by_name(n,e1) S
|
for_each_node_by_type(n,e1) S
|
for_each_compatible_node(n,e1,e2) S
|
for_each_matching_node(n,e1) S
|
for_each_matching_node_and_match(n,e1,e2) S
|
for_each_child_of_node(e1,n) S
|
for_each_available_child_of_node(e1,n) S
|
for_each_node_with_property(n,e1) S
)
&
i(es,n,...) S
)

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
   return n;
|
+  of_node_put(n);
?  return ...;
)
   ...
 }

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n

@@
local idexpression r.n;
iterator r.i;
expression e;
identifier l;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  goto l;
)
   ...
 }
...
l: ... when != n// 

---

 drivers/bluetooth/btmrvl_main.c  |5 -
 drivers/gpu/drm/tegra/dc.c   |4 +++-
 drivers/gpu/host1x/bus.c |4 +++-
 drivers/leds/leds-88pm860x.c |1 +
 drivers/leds/leds-bcm6328.c  |4 +++-
 drivers/leds/leds-bcm6358.c  |4 +++-
 drivers/leds/leds-powernv.c  |8 ++--
 drivers/pinctrl/pinctrl-at91.c   |5 -
 drivers/soc/ti/knav_qmss_queue.c |3 +++
 9 files changed, 30 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/9] drm/tegra: dc: add missing of_node_put

[Julia Lawall]

for_each_matching_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression e;
@@

 for_each_matching_node(n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/tegra/dc.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b4af4ab..f0e6f37 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1945,8 +1945,10 @@ static int tegra_dc_parse_dt(struct tegra_dc *dc)
 * cases where only a single display controller is used.
 */
for_each_matching_node(np, tegra_dc_of_match) {
-   if (np == dc->dev->of_node)
+   if (np == dc->dev->of_node) {
+   of_node_put(np);
break;
+   }
 
value++;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/9] leds: 88pm860x: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression e,r;
@@

 for_each_child_of_node(r,n) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-88pm860x.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/leds/leds-88pm860x.c b/drivers/leds/leds-88pm860x.c
index 1497a09..7870840 100644
--- a/drivers/leds/leds-88pm860x.c
+++ b/drivers/leds/leds-88pm860x.c
@@ -142,6 +142,7 @@ static int pm860x_led_dt_init(struct platform_device *pdev,
of_property_read_u32(np, "marvell,88pm860x-iset",
 &iset);
data->iset = PM8606_LED_CURRENT(iset);
+   of_node_put(np);
break;
}
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[net-next:master 1605/1613] net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   687f079addba1ac7f97ce97080c2291bbe8c8dce
commit: 5266698661401afc5e4a1a521cf9ba10724d10dd [1605/1613] tipc: let 
broadcast packet reception use new link receive function
reproduce:
# apt-get install sparse
git checkout 5266698661401afc5e4a1a521cf9ba10724d10dd
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. 
>> Should it be static?
>> net/tipc/link.c:171:6: sparse: symbol 'link_is_bc_rcvlink' was not declared. 
>> Should it be static?
   net/tipc/link.c:635:6: sparse: symbol 'link_prepare_wakeup' was not 
declared. Should it be static?
   net/tipc/link.c:891:6: sparse: symbol 'tipc_link_advance_backlog' was not 
declared. Should it be static?
   net/tipc/link.c:967:5: sparse: symbol 'tipc_link_retrans' was not declared. 
Should it be static?
>> net/tipc/link.c:1561:6: sparse: symbol 'tipc_link_build_bc_init_msg' was not 
>> declared. Should it be static?
   include/linux/rcupdate.h:305:9: sparse: context imbalance in 
'tipc_link_find_owner' - wrong count at exit
   net/tipc/link.c:1821:5: sparse: context imbalance in 'tipc_nl_link_set' - 
different lock contexts for basic block
   net/tipc/link.c:2058:5: sparse: context imbalance in 'tipc_nl_link_dump' - 
different lock contexts for basic block
   net/tipc/link.c:2129:5: sparse: context imbalance in 'tipc_nl_link_get' - 
different lock contexts for basic block
   net/tipc/link.c:2181:5: sparse: context imbalance in 
'tipc_nl_link_reset_stats' - different lock contexts for basic block
--
   net/tipc/node.c:144:18: sparse: symbol 'tipc_node_create' was not declared. 
Should it be static?
   net/tipc/node.c:831:6: sparse: symbol 'tipc_node_filter_pkt' was not 
declared. Should it be static?
>> net/tipc/node.c:1090:6: sparse: symbol 'tipc_node_bc_rcv' was not declared. 
>> Should it be static?
   net/tipc/node.c:237:5: sparse: context imbalance in 'tipc_node_add_conn' - 
different lock contexts for basic block
   net/tipc/node.c:268:6: sparse: context imbalance in 'tipc_node_remove_conn' 
- different lock contexts for basic block
   net/tipc/node.c:303:9: sparse: context imbalance in 'tipc_node_timeout' - 
different lock contexts for basic block
   net/tipc/node.c:383:13: sparse: context imbalance in 'tipc_node_link_up' - 
wrong count at exit
   net/tipc/node.c:463:13: sparse: context imbalance in 'tipc_node_link_down' - 
wrong count at exit
   net/tipc/node.c:497:6: sparse: context imbalance in 'tipc_node_check_dest' - 
wrong count at exit
   net/tipc/node.c:917:9: sparse: context imbalance in 'tipc_node_get_linkname' 
- different lock contexts for basic block
   net/tipc/node.c:935:9: sparse: context imbalance in 'tipc_node_unlock' - 
unexpected unlock
   net/tipc/node.c:1027:5: sparse: context imbalance in 'tipc_node_xmit' - 
wrong count at exit
>> net/tipc/node.c:1090:6: sparse: context imbalance in 'tipc_node_bc_rcv' - 
>> wrong count at exit
   net/tipc/node.c:1277:6: sparse: context imbalance in 'tipc_rcv' - different 
lock contexts for basic block
   net/tipc/node.c:1348:5: sparse: context imbalance in 'tipc_nl_node_dump' - 
different lock contexts for basic block

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/9] leds: bcm6358: add missing of_node_put

[Julia Lawall]

for_each_available_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_available_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-bcm6358.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-bcm6358.c b/drivers/leds/leds-bcm6358.c
index 7ea3526..82b4ee1 100644
--- a/drivers/leds/leds-bcm6358.c
+++ b/drivers/leds/leds-bcm6358.c
@@ -215,8 +215,10 @@ static int bcm6358_leds_probe(struct platform_device *pdev)
}
 
rc = bcm6358_led(dev, child, reg, mem, lock);
-   if (rc < 0)
+   if (rc < 0) {
+   of_node_put(child);
return rc;
+   }
}
 
return 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] fsnotify: destroy marks with call_srcu instead of dedicated thread

[Jan Kara]

On Fri 23-10-15 15:06:59, Jeff Layton wrote:
> At the time that this code was originally written, call_srcu didn't
> exist, so this thread was required to ensure that we waited for that
> SRCU grace period to settle before finally freeing the object.
> 
> It does exist now however and we can much more efficiently use call_srcu
> to handle this. That also allows us to potentially use srcu_barrier
> to ensure that they are all of the callbacks have run before proceeding.
> In order to conserve space, we union the rcu_head with the g_list.
> 
> This will be necessary for nfsd which will allocate marks from a
> dedicated slabcache. We have to be able to ensure that all of the
> objects are destroyed before destroying the cache. That's fairly
> difficult to ensure with dedicated thread doing the destruction.

The patch looks good. Just one nit below:

> diff --git a/include/linux/fsnotify_backend.h 
> b/include/linux/fsnotify_backend.h
> index 533c4408529a..6b7e89f45aa4 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -220,7 +220,10 @@ struct fsnotify_mark {
>   /* List of marks by group->i_fsnotify_marks. Also reused for queueing
>* mark into destroy_list when it's waiting for the end of SRCU period
>* before it can be freed. [group->mark_mutex] */

Please update this comment to not speak about destroy_list. After that feel
free to add:

Reviewed-by: Jan Kara 

Honza

> - struct list_head g_list;
> + union {
> + struct list_head g_list;
> + struct rcu_head g_rcu;
> + };
>   /* Protects inode / mnt pointers, flags, masks */
>   spinlock_t lock;
>   /* List of marks for inode / vfsmount [obj_lock] */


Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Rafael J. Wysocki]

On Saturday, October 24, 2015 11:28:19 AM Grant Likely wrote:
> [Including Rafael who also asked about what being a TAB member means]
> 
> On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> > Is there a good description of what is expected of a TAB member? How much 
> > time
> > is involved? What makes a great TAB member?
> >
> > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
> >
> > I've read the charter and scanned some of the minutes, but I'd still like to
> > hear from some of the "incumbants". Specifically, what makes you successful 
> > as a
> > member of the TAB?
> 
> I've been asked several versions of the same question, and also the
> annual "what does the TAB actually do?" question, so I'm going to try
> and answer them all in one email:
> 
> As the name implies, the primary job of the TAB is to advise the Linux
> Foundation board of directors on technical, social and political
> issues regarding Linux and Open Source. Our job is to represent the
> views of Linux developers and to foster constructive communication
> between the Linux Foundation leadership and our community.
> 
> A natural by-product of this is that the TAB also acts in the
> background to identify and resolve issues for the Linux community
> before they become a problem. The TAB tends to be composed of well
> respected individuals with good connections throughout our community,
> and so we're in a good place to recognize who to talk to when an issue
> is raised.
> 
> Finally, there are a few projects that the TAB is directly responsible
> for. We make sure there is a planning committee for the Linux Plumbers
> conference every year. We run a 'buddy' program to help new Linux
> Foundation member companies learn how to be fine upstanding Linux
> citizens. We are the response team for any issues of harassment or
> abuse within the kernel community. In past years we coordinated the
> response to UEFI Secure Boot to ensure that Linux would not be locked
> out of the consumer PC market, and been active in helping member
> companies understand and be comfortable with the licencing obligations
> associated with Linux.
> 
> A good TAB member is well respected by the community, is a ready
> listener, is comfortable discussing both technical and social issues,
> and has a good understanding of how the Linux community works. Since
> the TAB deals with a wide range of issues, the ideal TAB candidate
> should be prepared to consider issues outside of their own area of
> expertise. Sometime the most important characteristic of a TAB member
> is recognizing when an issue is beyond their depth and go looking for
> the right person to consult.
> 
> Time commitment wise, The TAB meets once a month for a conference
> call, plus any additional time required to deal with TAB business.
> Once a year (6 months after the TAB general election) the TAB elects
> one member to serve as the chair, and the chair of the TAB is proposed
> to the Linux Foundation to serve as a Linux Foundation Director which
> has additional time requirements.
> 
> One last point, some issues addressed by the TAB are highly sensitive
> and any member can request a topic to be kept strictly confidential.
> We do this to protect the working relationship we have with industry
> bodies, and to protect the companies and individuals involved. Any
> prospective TAB member must be comfortable abiding by our
> confidentiality rules.
> 
> I hope this answers your questions.

It certainly does answer mine.

Thanks a lot,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[net-next:master 1610/1613] net/tipc/link.c:176:5: sparse: symbol 'tipc_link_is_active' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   687f079addba1ac7f97ce97080c2291bbe8c8dce
commit: c72fa872a23f03b2b9c17e88f3b0a8070924e5f1 [1610/1613] tipc: eliminate 
link's reference to owner node
reproduce:
# apt-get install sparse
git checkout c72fa872a23f03b2b9c17e88f3b0a8070924e5f1
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. 
Should it be static?
   net/tipc/link.c:171:6: sparse: symbol 'link_is_bc_rcvlink' was not declared. 
Should it be static?
>> net/tipc/link.c:176:5: sparse: symbol 'tipc_link_is_active' was not 
>> declared. Should it be static?
   net/tipc/link.c:648:6: sparse: symbol 'link_prepare_wakeup' was not 
declared. Should it be static?
   net/tipc/link.c:904:6: sparse: symbol 'tipc_link_advance_backlog' was not 
declared. Should it be static?
   net/tipc/link.c:980:5: sparse: symbol 'tipc_link_retrans' was not declared. 
Should it be static?
   net/tipc/link.c:1573:6: sparse: symbol 'tipc_link_build_bc_init_msg' was not 
declared. Should it be static?
   include/linux/rcupdate.h:305:9: sparse: context imbalance in 
'tipc_link_find_owner' - wrong count at exit
   net/tipc/link.c:1833:5: sparse: context imbalance in 'tipc_nl_link_set' - 
different lock contexts for basic block
   net/tipc/link.c:2070:5: sparse: context imbalance in 'tipc_nl_link_dump' - 
different lock contexts for basic block
   net/tipc/link.c:2141:5: sparse: context imbalance in 'tipc_nl_link_get' - 
different lock contexts for basic block
   net/tipc/link.c:2193:5: sparse: context imbalance in 
'tipc_nl_link_reset_stats' - different lock contexts for basic block

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] printk: prevent userland from spoofing kernel messages

[Mathias Krause]

The following statement of ABI/testing/dev-kmsg is not quite right:

   It is not possible to inject messages from userspace with the
   facility number LOG_KERN (0), to make sure that the origin of the
   messages can always be reliably determined.

Userland actually can inject messages with a facility of 0 by abusing
the fact that the facility is stored in a u8 data type. By using a
facility which is a multiple of 256 the assignment of msg->facility in
log_store() implicitly truncates it to 0, i.e. LOG_KERN, allowing users
of /dev/kmsg to spoof kernel messages as shown below:

The following call...
   # printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
   user  :emerg : [   66.137758] Kernel panic - not syncing: beer empty

However, this call...
   # printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
   kern  :emerg : [   74.177343] Kernel panic - not syncing: beer empty

Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.

Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause 
Cc: Greg Kroah-Hartman 
Cc: Petr Mladek 
Cc: Alex Elder 
Cc: Joe Perches 
Cc: Kay Sievers 
---
Might be worth to apply to stable, too. Don't know. Prior to commit
7ff9554bb578 there was no facility so user injected messages had an implicit
facility for LOG_KERN. But commit 7ff9554bb578 explicitly mentions this
feature, so, dunno :/

 kernel/printk/printk.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f0324ef72ab..9982616ce712 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -269,6 +269,9 @@ static u32 clear_idx;
 #define PREFIX_MAX 32
 #define LOG_LINE_MAX   (1024 - PREFIX_MAX)
 
+#define LOG_LEVEL(v)   ((v) & 0x07)
+#define LOG_FACILITY(v)((v) >> 3 & 0xff)
+
 /* record buffer */
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
 #define LOG_ALIGN 4
@@ -611,7 +614,6 @@ struct devkmsg_user {
 static ssize_t devkmsg_write(struct kiocb *iocb, struct iov_iter *from)
 {
char *buf, *line;
-   int i;
int level = default_message_loglevel;
int facility = 1;   /* LOG_USER */
size_t len = iov_iter_count(from);
@@ -641,12 +643,13 @@ static ssize_t devkmsg_write(struct kiocb *iocb, struct 
iov_iter *from)
line = buf;
if (line[0] == '<') {
char *endp = NULL;
+   unsigned int u;
 
-   i = simple_strtoul(line+1, &endp, 10);
+   u = simple_strtoul(line + 1, &endp, 10);
if (endp && endp[0] == '>') {
-   level = i & 7;
-   if (i >> 3)
-   facility = i >> 3;
+   level = LOG_LEVEL(u);
+   if (LOG_FACILITY(u) != 0)
+   facility = LOG_FACILITY(u);
endp++;
len -= endp - line;
line = endp;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion

[Robert Jarzmik]

Robert Jarzmik  writes:

> This patch attempts to enhance the case of a transfer submitted multiple
> times, and where the cost of creating the descriptors chain is not
> negligible.
>
> This happens with big video buffers (several megabytes, ie. several
> thousands of linked descriptors in one scatter-gather list). In these
> cases, a video driver would want to do :
>  - tx = dmaengine_prep_slave_sg()
>  - dma_engine_submit(tx);
>  - dma_async_issue_pending()
>  - wait for video completion
>  - read video data (or not, skipping a frame is also possible)
>  - dma_engine_submit(tx)
>=> here, the descriptors chain recalculation will take time
>=> the dma coherent allocation over and over might create holes in
>   the dma pool, which is counter-productive.
>  - dma_async_issue_pending()
>  - etc ...
>
> In order to cope with this case, virt-dma is modified to prevent freeing
> the descriptors upon completion if DMA_CTRL_REUSE flag is set in the
> transfer.
>
> This patch is a respin of the former DMA_CTRL_ACK approach, which was
> reverted due to a regression in audio drivers.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: added doxygen commit to vchan_tx_desc_free

Hi Vinod,

Is this serie good for you or do you have remaining comments to be addressed ?

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

[Robert Jarzmik]

Robert Jarzmik  writes:

> Fix the error path where the video buffer wasn't allocated nor
> mapped. In this case, in the driver free path don't try to unmap memory
> which was not mapped in the first place.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v3: take into account the 2 paths possibilities to free_buffer()
Okay Guennadi, it's been enough time.
Could you you have another look at this serie please ?

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch 05/12] IXGBE: Add new sysfs interface of "notify_vf"

[Lan, Tianyu]

On 10/22/2015 4:52 AM, Alexander Duyck wrote:

Also have you even considered the MSI-X configuration on the VF?  I
haven't seen anything anywhere that would have migrated the VF's MSI-X
configuration from BAR 3 on one system to the new system.


MSI-X migration is done by Hypervisor(Qemu).
Following link is my Qemu patch to do that.
http://marc.info/?l=kvm&m=144544706530484&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Florian Fainelli  writes:

 +static void nb8800_set_rx_mode(struct net_device *dev)
 +{
 +  struct nb8800_priv *priv = netdev_priv(dev);
 +  struct netdev_hw_addr *ha;
 +  int af_en;
 +
 +  if ((dev->flags & (IFF_PROMISC | IFF_ALLMULTI)) ||
 +  netdev_mc_count(dev) > 64)
>>>
>>> 64, that's pretty generous for a perfect match filter, nice.
>> 
>> That's bogus; I forgot to delete it.  The hardware uses a 64-entry hash
>> table, and whoever wrote the old driver apparently didn't understand how
>> it works.
>
> Might be best to put the interface in promiscuous mode until you have
> proper multicast support. Since this is for a Set-Top box chip, having
> proper multicast support still seems like something highly desirable.

The code below should work correctly with any number of multicast
addresses.

 +  phydev = phy_find_first(bus);
 +  if (!phydev || phy_read(phydev, MII_BMSR) <= 0) {
>>>
>>> What is this additional MII_MBSR read used for?
>> 
>> On one of my boards, phylib misdetects a phy on the second ethernet port
>> even though there is none.  Perhaps I should revisit that problem and
>> look for a better solution.
>
> I think that would be best, if you are currently using the Generic PHY
> driver, consider writing a specific driver which would take care of
> quirky behavior.

The problem is that there is no PHY, yet for some reason reading the ID
registers appears to succeed.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Fabio Estevam]

On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:

>  /*
> + * R/W functions for big- or little-endian registers:
> + * The qSPI controller's endian is independent of the CPU core's endian.
> + * So far, although the CPU core is little-endian but the qSPI have two
> + * versions for big-endian and little-endian.
> + */
> +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
> +{
> +   if (q->big_endian)
> +   iowrite32be(val, addr);
> +   else
> +   iowrite32(val, addr);
> +}

I suggest you to implement regmap support for this driver instead.

Take a look at drivers/watchdog/imx2_wdt.c for a reference.

Then you only need to pass 'big-endian' as a property for the qspi in
the .dtsi file and regmap core will take care of endianness.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] perf tools: Improve ambiguous option help message

[Namhyung Kim]

Currently if an option name is ambiguous it only prints first two
matched option names but no help.  It'd be better it could show all
possible names and help messages too.

Before:
  $ perf report --show
Error: Ambiguous option: show (could be --show-total-period or
--show-ref-call-graph)
   Usage: perf report []

After:
  $ perf report --show
Error: Ambiguous option: show (could be --show-total-period or
--show-ref-call-graph)
   Usage: perf report []

  -n, --show-nr-samples
  Show a column with the number of samples
  --showcpuutilization
  Show sample percentage for different cpu modes
  -I, --show-info Display extended information about perf.data file
  --show-total-period
  Show a column with the sum of periods
  --show-ref-call-graph
  Show callgraph from reference event

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/parse-options.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 22c2806bda98..b8d98229a8af 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -770,24 +770,23 @@ int parse_options_usage(const char * const *usagestr,
 opt:
for (  ; opts->type != OPTION_END; opts++) {
if (short_opt) {
-   if (opts->short_name == *optstr)
+   if (opts->short_name == *optstr) {
+   print_option_help(opts, 0);
break;
+   }
continue;
}
 
if (opts->long_name == NULL)
continue;
 
-   if (!prefixcmp(optstr, opts->long_name))
-   break;
-   if (!prefixcmp(optstr, "no-") &&
-   !prefixcmp(optstr + 3, opts->long_name))
-   break;
+   if (!prefixcmp(opts->long_name, optstr))
+   print_option_help(opts, 0);
+   if (!prefixcmp("no-", optstr) &&
+   !prefixcmp(opts->long_name, optstr + 3))
+   print_option_help(opts, 0);
}
 
-   if (opts->type != OPTION_END)
-   print_option_help(opts, 0);
-
return PARSE_OPT_HELP;
 }
 
-- 
2.6.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] perf report: Rename to --show-cpu-utilization

[Namhyung Kim]

So that it can be more consistent with other --show-* options.  The old
name (--showcpuutilization) is provided only for compatibility.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-report.txt | 2 +-
 tools/perf/builtin-report.c  | 4 +++-
 tools/perf/util/parse-options.h  | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index ab1fd64e3627..5ce8da1e1256 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -29,7 +29,7 @@ OPTIONS
 --show-nr-samples::
Show the number of samples for each symbol
 
---showcpuutilization::
+--show-cpu-utilization::
 Show sample percentage for different cpu modes.
 
 -T::
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 50dd4d3d8667..2853ad2bd435 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -699,8 +699,10 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   " Please refer the man page for the complete list."),
OPT_STRING('F', "fields", &field_order, "key[,keys...]",
   "output field(s): overhead, period, sample plus all of sort 
keys"),
-   OPT_BOOLEAN(0, "showcpuutilization", &symbol_conf.show_cpu_utilization,
+   OPT_BOOLEAN(0, "show-cpu-utilization", 
&symbol_conf.show_cpu_utilization,
"Show sample percentage for different cpu modes"),
+   OPT_BOOLEAN_FLAG(0, "showcpuutilization", 
&symbol_conf.show_cpu_utilization,
+   "Show sample percentage for different cpu modes", 
PARSE_OPT_HIDDEN),
OPT_STRING('p', "parent", &parent_pattern, "regex",
   "regex filter to identify parent, see: '--sort parent'"),
OPT_BOOLEAN('x', "exclude-other", &symbol_conf.exclude_other,
diff --git a/tools/perf/util/parse-options.h b/tools/perf/util/parse-options.h
index 367d8b816cc7..182c86099330 100644
--- a/tools/perf/util/parse-options.h
+++ b/tools/perf/util/parse-options.h
@@ -111,6 +111,7 @@ struct option {
 #define OPT_GROUP(h){ .type = OPTION_GROUP, .help = (h) }
 #define OPT_BIT(s, l, v, h, b)  { .type = OPTION_BIT, .short_name = (s), 
.long_name = (l), .value = check_vtype(v, int *), .help = (h), .defval = (b) }
 #define OPT_BOOLEAN(s, l, v, h) { .type = OPTION_BOOLEAN, .short_name = 
(s), .long_name = (l), .value = check_vtype(v, bool *), .help = (h) }
+#define OPT_BOOLEAN_FLAG(s, l, v, h, f) { .type = OPTION_BOOLEAN, 
.short_name = (s), .long_name = (l), .value = check_vtype(v, bool *), .help = 
(h), .flags = (f) }
 #define OPT_BOOLEAN_SET(s, l, v, os, h) \
{ .type = OPTION_BOOLEAN, .short_name = (s), .long_name = (l), \
.value = check_vtype(v, bool *), .help = (h), \
-- 
2.6.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] perf tools: Introduce usage_with_options_msg()

[Namhyung Kim]

Now usage_with_options() setup a pager before printing message so normal
printf() or pr_err() will not be shown.  The usage_with_options_msg()
can be used to print some help message before usage strings.

Cc: Masami Hiramatsu 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-evlist.c |  4 ++--
 tools/perf/builtin-probe.c  | 20 
 tools/perf/builtin-record.c | 11 ++-
 tools/perf/builtin-sched.c  |  4 ++--
 tools/perf/builtin-script.c |  8 
 tools/perf/util/parse-options.c | 15 +++
 tools/perf/util/parse-options.h |  4 
 tools/perf/util/strbuf.c| 22 +++---
 tools/perf/util/strbuf.h|  2 ++
 9 files changed, 62 insertions(+), 28 deletions(-)

diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
index 695ec5a50cf2..f4d62510acbb 100644
--- a/tools/perf/builtin-evlist.c
+++ b/tools/perf/builtin-evlist.c
@@ -61,8 +61,8 @@ int cmd_evlist(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(evlist_usage, options);
 
if (details.event_group && (details.verbose || details.freq)) {
-   pr_err("--group option is not compatible with other options\n");
-   usage_with_options(evlist_usage, options);
+   usage_with_options_msg(evlist_usage, options,
+   "--group option is not compatible with other 
options\n");
}
 
return __cmd_evlist(input_name, &details);
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 530c3a28a58c..132afc97676c 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -528,12 +528,12 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 PARSE_OPT_STOP_AT_NON_OPTION);
if (argc > 0) {
if (strcmp(argv[0], "-") == 0) {
-   pr_warning("  Error: '-' is not supported.\n");
-   usage_with_options(probe_usage, options);
+   usage_with_options_msg(probe_usage, options,
+   "'-' is not supported.\n");
}
if (params.command && params.command != 'a') {
-   pr_warning("  Error: another command except --add is 
set.\n");
-   usage_with_options(probe_usage, options);
+   usage_with_options_msg(probe_usage, options,
+   "another command except --add is set.\n");
}
ret = parse_probe_event_argv(argc, argv);
if (ret < 0) {
@@ -562,8 +562,10 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
switch (params.command) {
case 'l':
if (params.uprobes) {
-   pr_warning("  Error: Don't use --list with --exec.\n");
-   usage_with_options(probe_usage, options);
+   pr_err("  Error: Don't use --list with --exec.\n");
+   parse_options_usage(probe_usage, options, "l", true);
+   parse_options_usage(NULL, options, "x", true);
+   return -EINVAL;
}
ret = show_perf_probe_events(params.filter);
if (ret < 0)
@@ -603,8 +605,10 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
case 'a':
/* Ensure the last given target is used */
if (params.target && !params.target_used) {
-   pr_warning("  Error: -x/-m must follow the probe 
definitions.\n");
-   usage_with_options(probe_usage, options);
+   pr_err("  Error: -x/-m must follow the probe 
definitions.\n");
+   parse_options_usage(probe_usage, options, "m", true);
+   parse_options_usage(NULL, options, "x", true);
+   return -EINVAL;
}
 
ret = perf_add_probe_events(params.events, params.nevents);
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2740d7a82ae8..de02267c73d8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1135,14 +1135,15 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(record_usage, record_options);
 
if (nr_cgroups && !rec->opts.target.system_wide) {
-   ui__error("cgroup monitoring only available in"
- " system-wide mode\n");
-   usage_with_options(record_usage, record_options);
+   usage_with_options_msg(record_usage, record_options,
+   "cgroup monitoring only available in system-wide mode");
+
}
if (rec->opts.record_switch_events &&
!perf_can_record_switch_events()) {
-   

[PATCH 3/4] perf tools: Setup pager when printing usage and help

[Namhyung Kim]

It's annoying to see error or help message when command has many options
like in perf record, report or top.  So setup pager when print parser
error or help message - it should be OK since no UI is enabled at the
parsing time.  The usage_with_options() already disables it by calling
exit_browser() anyway.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/parse-options.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index b8d98229a8af..d98eb26d 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -7,6 +7,8 @@
 #define OPT_SHORT 1
 #define OPT_UNSET 2
 
+static struct strbuf error_buf = STRBUF_INIT;
+
 static int opterror(const struct option *opt, const char *reason, int flags)
 {
if (flags & OPT_SHORT)
@@ -540,9 +542,11 @@ int parse_options_subcommand(int argc, const char **argv, 
const struct option *o
exit(130);
default: /* PARSE_OPT_UNKNOWN */
if (ctx.argv[0][1] == '-') {
-   error("unknown option `%s'", ctx.argv[0] + 2);
+   strbuf_addf(&error_buf, "unknown option `%s'",
+   ctx.argv[0] + 2);
} else {
-   error("unknown switch `%c'", *ctx.opt);
+   strbuf_addf(&error_buf, "unknown switch `%c'",
+   *ctx.opt);
}
usage_with_options(usagestr, options);
}
@@ -711,6 +715,13 @@ int usage_with_options_internal(const char * const 
*usagestr,
if (!usagestr)
return PARSE_OPT_HELP;
 
+   setup_pager();
+
+   if (strbuf_avail(&error_buf)) {
+   fprintf(stderr, "  Error: %s\n", error_buf.buf);
+   strbuf_release(&error_buf);
+   }
+
fprintf(stderr, "\n Usage: %s\n", *usagestr++);
while (*usagestr && **usagestr)
fprintf(stderr, "or: %s\n", *usagestr++);
-- 
2.6.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:perf/core] perf tools: Improve call graph documents and help messages

[Namhyung Kim]

Hi Ingo,

On Fri, Oct 23, 2015 at 6:03 PM, Ingo Molnar  wrote:
>
> * tip-bot for Namhyung Kim  wrote:
>
>> Commit-ID:  76a26549eb367f683fbb394b7246bef5dc665f8c
>> Gitweb: 
>> http://git.kernel.org/tip/76a26549eb367f683fbb394b7246bef5dc665f8c
>> Author: Namhyung Kim 
>> AuthorDate: Thu, 22 Oct 2015 23:28:32 +0900
>> Committer:  Arnaldo Carvalho de Melo 
>> CommitDate: Thu, 22 Oct 2015 16:23:19 -0300
>>
>> perf tools: Improve call graph documents and help messages
>>
>> The --call-graph option is complex so we should provide better guide for
>> users.  Also change help message to be consistent with config option
>> names.  Now perf top will show help like below:
>>
>>   $ perf top --call-graph
>> Error: option `call-graph' requires a value
>>
>>Usage: perf top []
>>
>>   --call-graph 
>> 
>>setup and enables call-graph (stack chain/backtrace):
>>
>>   record_mode:call graph recording mode (fp|dwarf|lbr)
>>   record_size:if record_mode is 'dwarf', max size of stack 
>> recording ()
>>   default: 8192 (bytes)
>>   print_type: call graph printing style 
>> (graph|flat|fractal|none)
>>   threshold:  minimum call graph inclusion threshold 
>> ()
>>   print_limit:maximum number of call graph entry ()
>>   order:  call graph order (caller|callee)
>>   sort_key:   call graph sort key (function|address)
>>   branch: include last branch info to call graph (branch)
>
> Btw., how is the last line to be interpreted? Is the 'branch' value 0/1? If 
> yes
> then the text should probably say so? Or does the string 'branch' have to be 
> used?

Yep, the string 'branch' should be used.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

[Michele Baldessari]

The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
to have the two distinct joysticks working.

Before the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
jstest: No such file or directory

After the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...

Signed-off-by: Michele Baldessari 
---
 drivers/hid/usbhid/hid-quirks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0015ba..f69049314a2c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -150,6 +150,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE, 
HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 
{ 0, 0 }
 };
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[John W. Linville]

Good write-up!  We should archive this for reference in future years!

John

On Sat, Oct 24, 2015 at 11:28:19AM +0100, Grant Likely wrote:
> [Including Rafael who also asked about what being a TAB member means]
> 
> On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> > Is there a good description of what is expected of a TAB member? How much 
> > time
> > is involved? What makes a great TAB member?
> >
> > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
> >
> > I've read the charter and scanned some of the minutes, but I'd still like to
> > hear from some of the "incumbants". Specifically, what makes you successful 
> > as a
> > member of the TAB?
> 
> I've been asked several versions of the same question, and also the
> annual "what does the TAB actually do?" question, so I'm going to try
> and answer them all in one email:
> 
> As the name implies, the primary job of the TAB is to advise the Linux
> Foundation board of directors on technical, social and political
> issues regarding Linux and Open Source. Our job is to represent the
> views of Linux developers and to foster constructive communication
> between the Linux Foundation leadership and our community.
> 
> A natural by-product of this is that the TAB also acts in the
> background to identify and resolve issues for the Linux community
> before they become a problem. The TAB tends to be composed of well
> respected individuals with good connections throughout our community,
> and so we're in a good place to recognize who to talk to when an issue
> is raised.
> 
> Finally, there are a few projects that the TAB is directly responsible
> for. We make sure there is a planning committee for the Linux Plumbers
> conference every year. We run a 'buddy' program to help new Linux
> Foundation member companies learn how to be fine upstanding Linux
> citizens. We are the response team for any issues of harassment or
> abuse within the kernel community. In past years we coordinated the
> response to UEFI Secure Boot to ensure that Linux would not be locked
> out of the consumer PC market, and been active in helping member
> companies understand and be comfortable with the licencing obligations
> associated with Linux.
> 
> A good TAB member is well respected by the community, is a ready
> listener, is comfortable discussing both technical and social issues,
> and has a good understanding of how the Linux community works. Since
> the TAB deals with a wide range of issues, the ideal TAB candidate
> should be prepared to consider issues outside of their own area of
> expertise. Sometime the most important characteristic of a TAB member
> is recognizing when an issue is beyond their depth and go looking for
> the right person to consult.
> 
> Time commitment wise, The TAB meets once a month for a conference
> call, plus any additional time required to deal with TAB business.
> Once a year (6 months after the TAB general election) the TAB elects
> one member to serve as the chair, and the chair of the TAB is proposed
> to the Linux Foundation to serve as a Linux Foundation Director which
> has additional time requirements.
> 
> One last point, some issues addressed by the TAB are highly sensitive
> and any member can request a topic to be kept strictly confidential.
> We do this to protect the working relationship we have with industry
> bodies, and to protect the companies and individuals involved. Any
> prospective TAB member must be comfortable abiding by our
> confidentiality rules.
> 
> I hope this answers your questions.
> 
> g.
> ___
> Tech-board mailing list
> tech-bo...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/3] ACPI: Using correct irq when uninstalling acpi irq handler

[Chen, Yu C]

Hi, Rafael

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Saturday, October 24, 2015 9:32 PM
> To: Chen, Yu C
> Cc: l...@kernel.org; Zhang, Rui; Zheng, Lv; linux-a...@vger.kernel.org;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH 1/3] ACPI: Using correct irq when uninstalling acpi irq
> handler
> 
> On Thursday, October 22, 2015 08:03:08 PM Chen Yu wrote:
> > Currently when system is trying to uninstall the acpi irq handler, it
> > uses the acpi_gbl_FADT.sci_interrupt directly.
> > But acpi irq handler is actually installed by mapped irq in
> > acpi_os_install_interrupt_handler, so this patch fixes this problem by
> > using the mapped irq returned from acpi_gsi_to_irq.
> >
> > Cc:  # 2.6.39+
> > Acked-by: Lv Zheng 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/acpi/osl.c   | 10 +++---
> >  include/linux/acpi.h |  3 +++
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index
> > 739a4a6..2e9eccf 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -81,6 +81,7 @@ static struct workqueue_struct *kacpid_wq;  static
> > struct workqueue_struct *kacpi_notify_wq;  static struct
> > workqueue_struct *kacpi_hotplug_wq;  static bool acpi_os_initialized;
> > +unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
> >
> >  /*
> >   * This list of permanent mappings is for memory that may be accessed
> > from @@ -856,17 +857,20 @@ acpi_os_install_interrupt_handler(u32 gsi,
> acpi_osd_handler handler,
> > acpi_irq_handler = NULL;
> > return AE_NOT_ACQUIRED;
> > }
> > +   acpi_sci_irq = irq;
> >
> > return AE_OK;
> >  }
> >
> > -acpi_status acpi_os_remove_interrupt_handler(u32 irq,
> > acpi_osd_handler handler)
> > +acpi_status acpi_os_remove_interrupt_handler(u32 gsi,
> > +acpi_osd_handler handler)
> >  {
> > -   if (irq != acpi_gbl_FADT.sci_interrupt)
> > +   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
> > +   IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> 
> The white space doesn't follow the kernel coding style, should be something
> like
> 
>   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
>   IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> 
> (spaces instead of the second tab).
> 
Ah, got it, thanks.

> Another minor nit is that this probably is the only place you check the
> IS_INVALID_ACPI_IRQ(acpi_sci_irq) thing without logical negation and you
> only pass acpi_sci_irq to IS_INVALID_ACPI_IRQ() AFAICS.
> 
> It would be more straightforward to define something like acpi_sci_irq_valid()
> instead (see below) IMO.
> 
> > return AE_BAD_PARAMETER;
> >
> > -   free_irq(irq, acpi_irq);
> > +   free_irq(acpi_sci_irq, acpi_irq);
> > acpi_irq_handler = NULL;
> > +   acpi_sci_irq = INVALID_ACPI_IRQ;
> >
> > return AE_OK;
> >  }
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h index
> > 43856d1..bad159c 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -193,6 +193,9 @@ int acpi_ioapic_registered(acpi_handle handle, u32
> > gsi_base);  void acpi_irq_stats_init(void);  extern u32
> > acpi_irq_handled;  extern u32 acpi_irq_not_handled;
> > +extern unsigned int acpi_sci_irq;
> > +#define INVALID_ACPI_IRQ ((unsigned)-1)
> 
> #define INVALID_ACPI_IRQ  ((unsigned int)-1)
> 
> > +#define IS_INVALID_ACPI_IRQ(x) unlikely((x) == INVALID_ACPI_IRQ)
> 
> Maybe something like:
> 
>   static inline bool acpi_sci_irq_valid(void)
>   {
>   return acpi_sci_irq != INVALID_ACPI_IRQ;
>   }
> 
OK, will send out a version 2 with both another two patches modified.

Best Regards,
Yu

Re: [RFC Patch 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 8:58 PM, Michael S. Tsirkin wrote:

Do you really need to play the shifting games?
Can't you just reset everything and re-initialize the rings?
It's slower but way less intrusive.
Also removes the need to track writes into rings.


Shift ring is to avoid losing those packets in the ring.
This may cause some race condition and so I introduced a
lock to prevent such cases in the latter patch.
Yes, reset everything after migration can make thing easy.
But just like you said it would affect performance and loss
more packets. I can do a test later to get data about these
two way.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 5:14 AM, Alexander Duyck wrote:

Where is i being initialized?  It was here but you removed it.  Are you
using i without initializing it?


Sorry, the initialization was put into patch 10 by mistake. "i" is
assigned with "tx_ring->next_to_clean".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Rob Herring]

On 10/23/2015 01:28 PM, Douglas Anderson wrote:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup.  It appears that the "port reset" bit that's in the USB
> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
> 
> This series of patches exports the "port reset" from the PHY and then
> hooks it up to dwc2 through a quirk.
> 
> I've tested this series atop a bit of a conglomeration of Heiko's github
> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
> usb-next merged in.
> 
> These patches currently conflict with patches that I posted previously
> to enable USB wakeup from S3, specifically:
> * https://patchwork.kernel.org/patch/6727081/
> * https://patchwork.kernel.org/patch/6727121/
> ...those patches no longer apply anyway, so presumably they need to be
> reposted and I can do so later atop these patches.
> 
> 
> Douglas Anderson (4):
>   phy: rockchip-usb: Support the PHY's "port reset"
>   usb: dwc2: optionally assert phy "port reset" when waking up
>   ARM: dts: rockchip: Enable the USB phys as reset providers on rk3288
>   ARM: dts: rockchip: Point rk3288 dwc2 usb at phy port reset
> 
>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  6 ++
>  Documentation/devicetree/bindings/usb/dwc2.txt |  7 ++
>  arch/arm/boot/dts/rk3288.dtsi  |  8 +++
>  drivers/phy/phy-rockchip-usb.c | 74 
> ++
>  drivers/usb/dwc2/core.h|  5 ++
>  drivers/usb/dwc2/core_intr.c   |  7 ++
>  drivers/usb/dwc2/platform.c| 13 
>  7 files changed, 120 insertions(+)

A DT reset controller seems like a bit of an overkill here. I think this
would be much more simple if we just add a phy reset hook to the phy
subsystem.

Rob

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/2] acpi: add acpi_preset_companion() stub

[Wolfram Sang]

On Fri, Oct 23, 2015 at 12:27:06PM -0700, Dustin Byford wrote:
> Add a stub for acpi_preset_companion().  Fixes build failures when
> acpi_preset_companion() is used and CONFIG_ACPI is not set.
> 
> Acked-by: Mika Westerberg 
> Signed-off-by: Dustin Byford 

Waiting for Rafael's ack here...

> ---
>  include/linux/acpi.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 43856d1..43b55e7 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -477,6 +477,11 @@ static inline bool has_acpi_companion(struct device *dev)
>   return false;
>  }
>  
> +static inline void acpi_preset_companion(struct device *dev,
> +  struct acpi_device *parent, u64 addr)
> +{
> +}
> +
>  static inline const char *acpi_dev_name(struct acpi_device *adev)
>  {
>   return NULL;
> -- 
> 2.1.4
> 


signature.asc
Description: Digital signature

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Dan Williams]

On Tue, Oct 6, 2015 at 3:06 AM, Grant Likely  wrote:
> [Resending because I messed up the first one]
>
> The elections for five of the ten members of the Linux Foundation
> Technical Advisory Board (TAB) are held every year[1]. This year the
> election will be at the 2015 Kernel Summit in Seoul, South Korea
> (probably on the Monday, 26 October) and will be open to all attendees
> of both Kernel Summit and Korea Linux Forum.
>
> Anyone is eligible to stand for election, simply send your nomination to:
>
> tech-board-disc...@lists.linux-foundation.org
>
> We currently have 3 nominees for five places:
> Thomas Gleixner
> Greg Kroah-Hartman
> Stephen Hemminger

I'd like to stand for a TAB seat, please add me to the candidate list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: add tps65218 gpio driver

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on gpio/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Saenz-Julienne/gpio-add-tps65218-gpio-driver/20151024-003657
config: x86_64-randconfig-x002-201543 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpio/gpio-tps65218.c: In function 'tps65218_gpio_probe':
>> drivers/gpio/gpio-tps65218.c:175:26: error: 'struct gpio_chip' has no member 
>> named 'of_node'
 tps65218_gpio->gpio_chip.of_node = pdev->dev.of_node;
 ^

vim +175 drivers/gpio/gpio-tps65218.c

   169  if (!tps65218_gpio)
   170  return -ENOMEM;
   171  
   172  tps65218_gpio->tps65218 = tps65218;
   173  tps65218_gpio->gpio_chip = template_chip;
   174  tps65218_gpio->gpio_chip.dev = &pdev->dev;
 > 175  tps65218_gpio->gpio_chip.of_node = pdev->dev.of_node;
   176  
   177  ret = gpiochip_add(&tps65218_gpio->gpio_chip);
   178  if (ret < 0) {

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


.config.gz
Description: Binary data

[PATCH 0/3][v2] Fix incorrect using of acpi irq

[Chen Yu]

This series of patches are trying to convert codes who use
acpi_gbl_FADT.sci_interrupt incorrectly to use the right irq
mapped by acpi_gsi_to_irq.

Chen Yu (3):
  ACPI: Using correct irq when uninstalling acpi irq handler
  ACPI: Using correct irq when waiting for events
  ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

 drivers/acpi/osl.c   | 14 +-
 drivers/acpi/sleep.c |  6 --
 include/linux/acpi.h |  6 ++
 3 files changed, 19 insertions(+), 7 deletions(-)

-- 
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] leds: bcm6328: Handle default-state of LEDs correctly

[Simon Arlott]

The default-state handler assumes that the LED is active low and omits
use of the shift macro causing "keep" to misdetect the state.

Determine the brightness and then use the led set function to apply it.

Update the documentation to indicate that this driver works for the
BCM63168 (which has many active high LEDs) too.

Signed-off-by: Simon Arlott 
---
 .../devicetree/bindings/leds/leds-bcm6328.txt  |  2 +-
 drivers/leds/leds-bcm6328.c| 23 --
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt 
b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
index f9e36ad..d00260d 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
@@ -1,6 +1,6 @@
 LEDs connected to Broadcom BCM6328 controller
 
-This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
+This controller is present on BCM6318, BCM6328, BCM6362, BCM63168 and BCM63268.
 In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
 However, on some devices there are Serial LEDs (LEDs connected to a 74x164
 controller), which can either be controlled by software (exporting the 74x164
diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
index 1793727..771c171 100644
--- a/drivers/leds/leds-bcm6328.c
+++ b/drivers/leds/leds-bcm6328.c
@@ -259,7 +259,6 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
   unsigned long *blink_leds, unsigned long *blink_delay)
 {
struct bcm6328_led *led;
-   unsigned long flags;
const char *state;
int rc;
 
@@ -282,13 +281,12 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
NULL);
 
if (!of_property_read_string(nc, "default-state", &state)) {
-   spin_lock_irqsave(lock, flags);
if (!strcmp(state, "on")) {
led->cdev.brightness = LED_FULL;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_ON);
} else if (!strcmp(state, "keep")) {
void __iomem *mode;
unsigned long val, shift;
+   unsigned long flags;
 
shift = bcm6328_pin2shift(led->pin);
if (shift / 16)
@@ -296,19 +294,24 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
else
mode = mem + BCM6328_REG_MODE_LO;
 
-   val = bcm6328_led_read(mode) >> (shift % 16);
+   spin_lock_irqsave(lock, flags);
+   val = bcm6328_led_read(mode);
+   spin_unlock_irqrestore(lock, flags);
+
+   val >>= BCM6328_LED_SHIFT(shift % 16);
val &= BCM6328_LED_MODE_MASK;
-   if (val == BCM6328_LED_MODE_ON)
+
+   dev_info(dev, "pin %lu = %08lx\n", led->pin, val);
+   if ((led->active_low && val == BCM6328_LED_MODE_ON) ||
+   (!led->active_low && val == BCM6328_LED_MODE_OFF))
led->cdev.brightness = LED_FULL;
-   else {
+   else
led->cdev.brightness = LED_OFF;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
-   }
} else {
led->cdev.brightness = LED_OFF;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
}
-   spin_unlock_irqrestore(lock, flags);
+
+   bcm6328_led_set(&led->cdev, led->cdev.brightness);
}
 
led->cdev.brightness_set = bcm6328_led_set;
-- 
2.1.4

-- 
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3][v2] ACPI: Using correct irq when uninstalling acpi irq handler

[Chen Yu]

Currently when system is trying to uninstall the acpi irq
handler, it uses the acpi_gbl_FADT.sci_interrupt directly.
But acpi irq handler is actually installed by mapped irq
in acpi_os_install_interrupt_handler, so this patch fixes
this problem by using the mapped irq returned from acpi_gsi_to_irq.

Cc:  # 2.6.39
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/osl.c   | 10 +++---
 include/linux/acpi.h |  6 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 739a4a6..64df9d4 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -81,6 +81,7 @@ static struct workqueue_struct *kacpid_wq;
 static struct workqueue_struct *kacpi_notify_wq;
 static struct workqueue_struct *kacpi_hotplug_wq;
 static bool acpi_os_initialized;
+unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
 
 /*
  * This list of permanent mappings is for memory that may be accessed from
@@ -856,17 +857,20 @@ acpi_os_install_interrupt_handler(u32 gsi, 
acpi_osd_handler handler,
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
}
+   acpi_sci_irq = irq;
 
return AE_OK;
 }
 
-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler)
+acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
 {
-   if (irq != acpi_gbl_FADT.sci_interrupt)
+   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
+   !acpi_sci_irq_valid())
return AE_BAD_PARAMETER;
 
-   free_irq(irq, acpi_irq);
+   free_irq(acpi_sci_irq, acpi_irq);
acpi_irq_handler = NULL;
+   acpi_sci_irq = INVALID_ACPI_IRQ;
 
return AE_OK;
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 43856d1..1ae6ba0 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -193,6 +193,12 @@ int acpi_ioapic_registered(acpi_handle handle, u32 
gsi_base);
 void acpi_irq_stats_init(void);
 extern u32 acpi_irq_handled;
 extern u32 acpi_irq_not_handled;
+extern unsigned int acpi_sci_irq;
+#define INVALID_ACPI_IRQ   ((unsigned)-1)
+static inline bool acpi_sci_irq_valid(void)
+{
+   return acpi_sci_irq != INVALID_ACPI_IRQ;
+}
 
 extern int sbf_port;
 extern unsigned long acpi_realmode_flags;
-- 
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3][v2] ACPI: Using correct irq when waiting for events

[Chen Yu]

When system is waiting for GPE/fixed event handler to finish,
it uses the acpi_gbl_FADT.sci_interrupt directly. However, we
should use mapped irq returned by acpi_gsi_to_irq for synchronize_hardirq.

Cc:  # 3.19+
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/osl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 64df9d4..45243a7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1184,8 +1184,8 @@ void acpi_os_wait_events_complete(void)
 * Make sure the GPE handler or the fixed event handler is not used
 * on another CPU after removal.
 */
-   if (acpi_irq_handler)
-   synchronize_hardirq(acpi_gbl_FADT.sci_interrupt);
+   if (acpi_sci_irq_valid())
+   synchronize_hardirq(acpi_sci_irq);
flush_workqueue(kacpid_wq);
flush_workqueue(kacpi_notify_wq);
 }
-- 
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3][v2] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

[Chen Yu]

For ACPI compatible system, SCI(ACPI System Control
Interrupt) is used to wake the system up from suspend-to-idle.
Once the CPU is woken up by SCI, the interrupt handler will
firstly check if the current interrupt is legal to wake up
the whole system, thus irq_pm_check_wakeup is invoked
to validate the irq number. However, before suspend-to-idle,
acpi_gbl_FADT.sci_interrupt is marked rather than actual
irq number in acpi_freeze_prepare, this might lead to unable
to wake up the system.

This patch fixes this problem by marking the irq number
returned by acpi_gsi_to_irq as IRQD_WAKEUP_STATE, rather than
marking the acpi_gbl_FADT.sci_interrupt.

Cc:  # 3.18+
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/sleep.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 2f0d4db..3fe1fbe 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -632,14 +632,16 @@ static int acpi_freeze_prepare(void)
acpi_enable_wakeup_devices(ACPI_STATE_S0);
acpi_enable_all_wakeup_gpes();
acpi_os_wait_events_complete();
-   enable_irq_wake(acpi_gbl_FADT.sci_interrupt);
+   if (acpi_sci_irq_valid())
+   enable_irq_wake(acpi_sci_irq);
return 0;
 }
 
 static void acpi_freeze_restore(void)
 {
acpi_disable_wakeup_devices(ACPI_STATE_S0);
-   disable_irq_wake(acpi_gbl_FADT.sci_interrupt);
+   if (acpi_sci_irq_valid())
+   disable_irq_wake(acpi_sci_irq);
acpi_enable_all_runtime_gpes();
 }
 
-- 
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

[Andrew F. Davis]

Using constants for pinctrl allows better readability and removes
redundancy with comments. AM33XX_IOPAD allows us to use part of the
pinctrl physical address as in the TRM instead of an offset.

Signed-off-by: Andrew F. Davis 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index eadbba3..346f529 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -36,32 +36,32 @@
 &am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
-   0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
AM33XX_PIN_OUTPUT */
-   0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc8 0x08   /* lcd_data10.lcd_data10, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xcc 0x08   /* lcd_data11.lcd_data11, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd0 0x08   /* lcd_data12.lcd_data12, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd4 0x08   /* lcd_data13.lcd_data13, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd8 0x08   /* lcd_data14.lcd_data14, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xdc 0x08   /* lcd_data15.lcd_data15, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
AM33XX_PIN_OUTPUT */
-   0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
+   AM33XX_IOPAD(0x9b0, (PIN_OUTPUT_PULLDOWN | MUX_MODE3))  
/* xdma_event_intr0 */
+   AM33XX_IOPAD(0x8a0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data0.lcd_data0 */
+   AM33XX_IOPAD(0x8a4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data1.lcd_data1 */
+   AM33XX_IOPAD(0x8a8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data2.lcd_data2 */
+   AM33XX_IOPAD(0x8ac, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data3.lcd_data3 */
+   AM33XX_IOPAD(0x8b0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data4.lcd_data4 */
+   AM33XX_IOPAD(0x8b4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data5.lcd_data5 */
+   AM33XX_IOPAD(0x8b8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data6.lcd_data6 */
+   AM33XX_IOPAD(0x8bc, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data7.lcd_data7 */
+   AM33XX_IOPAD(0x8c0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data8.lcd_data8 */
+   AM33XX_IOPAD(0x8c4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data9.lcd_data9 */
+   AM33XX_IOPAD(0x8c8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data10.lcd_data10 */
+   AM33XX_IOPAD(0x8cc, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data11.lcd_data11 */
+   AM33XX_IOPAD(0x8d0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data12.lcd_data12 */
+   AM33XX_IOPAD(0x8d4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data13.lcd_data13 */
+   AM33XX_IOPAD(0x8d8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data14.lcd_data14 */
+   AM33XX_IOPAD(0x8dc, (PIN_OUTPUT | MUX_MODE0))   
/* lcd

Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events

[kbuild test robot]

Hi Chen,

[auto build test ERROR on pm/linux-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using-correct-irq-when-waiting-for-events/20151025-010210
config: x86_64-randconfig-x015-201543 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/acpi/osl.c:26:
   drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete':
>> drivers/acpi/osl.c:1183:6: error: implicit declaration of function 
>> 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration]
 if (acpi_sci_irq_valid())
 ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if'
 if (acpi_sci_irq_valid())
 ^
>> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared (first use in 
>> this function)
  synchronize_hardirq(acpi_sci_irq);
  ^
   drivers/acpi/osl.c:1184:23: note: each undeclared identifier is reported 
only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c

  1177  void acpi_os_wait_events_complete(void)
  1178  {
  1179  /*
  1180   * Make sure the GPE handler or the fixed event handler is not 
used
  1181   * on another CPU after removal.
  1182   */
> 1183  if (acpi_sci_irq_valid())
> 1184  synchronize_hardirq(acpi_sci_irq);
  1185  flush_workqueue(kacpid_wq);
  1186  flush_workqueue(kacpi_notify_wq);
  1187  }

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


.config.gz
Description: Binary data