Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith]

On Tue, 2015-10-27 at 14:46 +0900, Tejun Heo wrote:
> Hello,
> 
> On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote:
> > Sure, sounds fine, I just fervently hope that the below is foul swamp
> > gas having nothing what so ever to do with your definition of "saner".
> 
> lol, idk, you keep taking things in weird directions.  Let's just stay
> technical, okay?
> 
> > http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
> > 
> > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> > 
> > I'm not into begging.  I really don't want to have to ask anyone to
> > pretty please do for me what I can currently do all by my little self
> > without having to give a rats ass less whether what I want to do fits in
> > the world view of this or that obnoxious little control freak.
> 
> Well, if you think certain things are being missed, please speak up.
> Not in some media campaign way but with technical reasoning and
> justifications.

Inserting a middle-man is extremely unlikely to improve performance.

-Mike

--
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/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Alexey Kardashevskiy]

On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote:

When DDW (Dynamic DMA Windows) are present for a device, we have stored
the TCE (Translation Control Entry) size in a special device tree
property. Check if we have enabled DDW for the device and return the TCE
size from that property if present. If the property isn't present,
fallback to looking the value up in struct iommu_table. If we don't find
a iommu_table, fallback to the kernel's page size.

Signed-off-by: Nishanth Aravamudan 
---
  arch/powerpc/platforms/pseries/iommu.c | 36 ++
  1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index 0946b98..1bf6471 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1292,6 +1292,40 @@ static u64 dma_get_required_mask_pSeriesLP(struct device 
*dev)
return dma_iommu_ops.get_required_mask(dev);
  }

+static unsigned long dma_get_page_shift_pSeriesLP(struct device *dev)
+{
+   struct iommu_table *tbl;
+
+   if (!disable_ddw && dev_is_pci(dev)) {
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct device_node *dn;
+
+   dn = pci_device_to_OF_node(pdev);
+
+   /* search upwards for ibm,dma-window */
+   for (; dn && PCI_DN(dn) && !PCI_DN(dn)->table_group;
+   dn = dn->parent)
+   if (of_get_property(dn, "ibm,dma-window", NULL))
+   break;
+   /*
+* if there is a DDW configuration, the TCE shift is stored in
+* the property
+*/
+   if (dn && PCI_DN(dn)) {
+   const struct dynamic_dma_window_prop *direct64 =
+   of_get_property(dn, DIRECT64_PROPNAME, NULL);



This DIRECT64_PROPNAME property is only present under pHyp, QEMU/KVM does 
not set it as 64bit windows are dynamic there so something like 
find_existing_ddw() needs to be used here.





+   if (direct64)
+   return be32_to_cpu(direct64->tce_shift);
+   }
+   }
+
+   tbl = get_iommu_table_base(dev);
+   if (tbl)
+   return tbl->it_page_shift;
+
+   return PAGE_SHIFT;
+}
+
  #else  /* CONFIG_PCI */
  #define pci_dma_bus_setup_pSeries NULL
  #define pci_dma_dev_setup_pSeries NULL
@@ -1299,6 +1333,7 @@ static u64 dma_get_required_mask_pSeriesLP(struct device 
*dev)
  #define pci_dma_dev_setup_pSeriesLP   NULL
  #define dma_set_mask_pSeriesLPNULL
  #define dma_get_required_mask_pSeriesLP   NULL
+#define dma_get_page_shift_pSeriesLP   NULL
  #endif /* !CONFIG_PCI */

  static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
@@ -1395,6 +1430,7 @@ void iommu_init_early_pSeries(void)
pseries_pci_controller_ops.dma_dev_setup = 
pci_dma_dev_setup_pSeriesLP;
ppc_md.dma_set_mask = dma_set_mask_pSeriesLP;
ppc_md.dma_get_required_mask = dma_get_required_mask_pSeriesLP;
+   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
} else {
pseries_pci_controller_ops.dma_bus_setup = 
pci_dma_bus_setup_pSeries;
pseries_pci_controller_ops.dma_dev_setup = 
pci_dma_dev_setup_pSeries;




--
Alexey
--
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] libata: add support for NCQ commands for SG interface

[vinayak . kale]

From: Vinayak Kale 

This patch is needed to make NCQ commands with FPDMA protocol value
(eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface.

Signed-off-by: Vinayak Kale 
---
Changes in v2:
 - Decoupled tf->flags changes in ata_scsi_pass_thru() from this patch
   as per Tejun's suggestion. A separate patch will be sent for that change.

 drivers/ata/libata-scsi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 0d7f0da..c2af592 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2914,12 +2914,14 @@ ata_scsi_map_proto(u8 byte1)
case 5: /* PIO Data-out */
return ATA_PROT_PIO;
 
+   case 12:/* FPDMA */
+   return ATA_PROT_NCQ;
+
case 0: /* Hard Reset */
case 1: /* SRST */
case 8: /* Device Diagnostic */
case 9: /* Device Reset */
case 7: /* DMA Queued */
-   case 12:/* FPDMA */
case 15:/* Return Response Info */
default:/* Reserved */
break;
@@ -2992,6 +2994,10 @@ static unsigned int ata_scsi_pass_thru(struct 
ata_queued_cmd *qc)
tf->command = cdb[9];
}
 
+   /* For NCQ commands with FPDMA protocol, copy the tag value */
+   if (tf->protocol == ATA_PROT_NCQ)
+   tf->nsect = qc->tag << 3;
+
/* enforce correct master/slave bit */
tf->device = dev->devno ?
tf->device | ATA_DEV1 : tf->device & ~ATA_DEV1;
-- 
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 v2] iov: restore NumVFs register to 0 before return from virtfn_max_buses()

[Alexander Duyck]

On 10/15/2015 10:16 AM, Bjorn Helgaas wrote:

Hi Ethan,

On Wed, Sep 16, 2015 at 12:19:53PM +0900, Ethan Zhao wrote:

After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was left to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch restore the NumVFs register to zero after the
calculation of max_VF_buses was done and before return from
virtfn_max_buses().

Tested on stable 4.1 and passed building on stable 4.3-rc1

Signed-off-by: Ethan Zhao 
Tested-by: Sriharsha Yadagudde 

Can you test the patch below?  I'm trying to avoid touching
PCI_SRIOV_NUM_VF in more than one place, and I think it's OK to set it
and test offset/stride at the end, instead of setting NUM_VF to zero,
testing offset/stride, computing max_bus, then setting NUM_VF to zero
again.

Bjorn


commit 8e20e89658f23b8d16b1e21810e9f63c8625129c
Author: Bjorn Helgaas 
Date:   Thu Oct 15 11:31:21 2015 -0500

 PCI: Set SR-IOV NumVFs to zero after enumeration
 
 The enumeration path should leave NumVFs set to zero.  But after

 4449f079722c ("PCI: Calculate maximum number of buses required for VFs"),
 we call virtfn_max_buses() in the enumeration path, which changes NumVFs.
 This NumVFs change is visible via lspci and sysfs until a driver enables
 SR-IOV.
 
 Set NumVFs to zero after virtfn_max_buses() computes the maximum number of

 buses.
 
 Fixes: 4449f079722c ("PCI: Calculate maximum number of buses required for VFs")

 Based-on-patch-by: Ethan Zhao 
 Signed-off-by: Bjorn Helgaas 

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..0202ab0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -384,7 +384,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
int rc;
int nres;
u32 pgsz;
-   u16 ctrl, total, offset, stride;
+   u16 ctrl, total;
struct pci_sriov *iov;
struct resource *res;
struct pci_dev *pdev;
@@ -414,11 +414,6 @@ static int sriov_init(struct pci_dev *dev, int pos)
  
  found:

pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
-   pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, 0);
-   pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, );
-   pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, );
-   if (!offset || (total > 1 && !stride))
-   return -EIO;
  
  	pci_read_config_dword(dev, pos + PCI_SRIOV_SUP_PGSIZE, );

i = PAGE_SHIFT > 12 ? PAGE_SHIFT - 12 : 0;
@@ -456,8 +451,6 @@ found:
iov->nres = nres;
iov->ctrl = ctrl;
iov->total_VFs = total;
-   iov->offset = offset;
-   iov->stride = stride;
iov->pgsz = pgsz;
iov->self = dev;
pci_read_config_dword(dev, pos + PCI_SRIOV_CAP, >cap);
@@ -475,6 +468,11 @@ found:
dev->sriov = iov;
dev->is_physfn = 1;
iov->max_VF_buses = virtfn_max_buses(dev);
+   pci_iov_set_numvfs(dev, 0);
+   if (!iov->offset || (total > 1 && !iov->stride)) {
+   rc = -EIO;
+   goto failed;
+   }
  
  	return 0;
  


You might want to reorder this a bit.  The problem is offset and stride 
can be 0 if numvfs is 0.  So you should probably test offset and stride 
first, and then reset numvfs to 0.


- 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 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello,

On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote:
> Sure, sounds fine, I just fervently hope that the below is foul swamp
> gas having nothing what so ever to do with your definition of "saner".

lol, idk, you keep taking things in weird directions.  Let's just stay
technical, okay?

> http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
> 
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> 
> I'm not into begging.  I really don't want to have to ask anyone to
> pretty please do for me what I can currently do all by my little self
> without having to give a rats ass less whether what I want to do fits in
> the world view of this or that obnoxious little control freak.

Well, if you think certain things are being missed, please speak up.
Not in some media campaign way but with technical reasoning and
justifications.

Thanks.

-- 
tejun
--
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] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith]

On Tue, 2015-10-27 at 12:16 +0900, Tejun Heo wrote:
> Hello, Mike.
> 
> On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote:
> > I don't think it's weird, it's just a thought wrt where pigeon holing
> > could lead:  If you filter out current users who do so in a manner you
> > consider to be in some way odd, when all the filtering is done, you may
> > find that you've filtered out the vast majority of current deployment.
> 
> I think you misunderstood what I wrote.  It's not about excluding
> existing odd use cases.  It's about examining the usages and
> extracting the required capabilities and building an interface which
> is well defined and blends well with the rest of programming interface
> provided by the kernel so that those can be achieved in a saner way.

Sure, sounds fine, I just fervently hope that the below is foul swamp
gas having nothing what so ever to do with your definition of "saner".

http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign

http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

I'm not into begging.  I really don't want to have to ask anyone to
pretty please do for me what I can currently do all by my little self
without having to give a rats ass less whether what I want to do fits in
the world view of this or that obnoxious little control freak.

-Mike

--
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/5] staging: fsl-mc: bus rescan attribute to sync kernel with MC

[Greg KH]

On Sun, Oct 25, 2015 at 05:41:22PM -0500, Lijun Pan wrote:
> Introduce the rescan attribute as a bus attribute to
> synchronize the fsl-mc bus objects and the MC firmware.
> 
> To rescan the fsl-mc bus, e.g.,
> echo 1 > /sys/bus/fsl-mc/rescan
> 
> Signed-off-by: Lijun Pan 
> ---
>  drivers/staging/fsl-mc/bus/mc-bus.c | 46 
> +
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
> b/drivers/staging/fsl-mc/bus/mc-bus.c
> index 33a56ad..f1baad7 100644
> --- a/drivers/staging/fsl-mc/bus/mc-bus.c
> +++ b/drivers/staging/fsl-mc/bus/mc-bus.c
> @@ -144,11 +144,57 @@ static const struct attribute_group 
> *fsl_mc_dev_groups[] = {
>   NULL,
>  };
>  
> +static int scan_fsl_mc_bus(struct device *dev, void *data)
> +{
> + struct fsl_mc_device *root_mc_dev;
> + struct fsl_mc_bus *root_mc_bus;
> +
> + if (is_root_dprc(dev)) {
> + root_mc_dev = to_fsl_mc_device(dev);
> + root_mc_bus = to_fsl_mc_bus(root_mc_dev);
> + mutex_lock(_mc_bus->scan_mutex);
> + dprc_scan_objects(root_mc_dev);
> + mutex_unlock(_mc_bus->scan_mutex);
> + }
> +
> + return 0;
> +}
> +
> +static ssize_t bus_rescan_store(struct bus_type *bus,
> + const char *buf, size_t count)
> +{
> + unsigned long val;
> +
> + if (kstrtoul(buf, 0, ) < 0)
> + return -EINVAL;
> +
> + if (val)
> + bus_for_each_dev(bus, NULL, NULL, scan_fsl_mc_bus);
> +
> + return count;
> +}
> +static BUS_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, bus_rescan_store);
> +
> +static struct attribute *fsl_mc_bus_attrs[] = {
> + _attr_rescan.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group fsl_mc_bus_group = {
> + .attrs = fsl_mc_bus_attrs,
> +};
> +
> +static const struct attribute_group *fsl_mc_bus_groups[] = {
> + _mc_bus_group,
> + NULL,
> +};
> +
>  struct bus_type fsl_mc_bus_type = {
>   .name = "fsl-mc",
>   .match = fsl_mc_bus_match,
>   .uevent = fsl_mc_bus_uevent,
>   .dev_groups = fsl_mc_dev_groups,
> + .bus_groups = fsl_mc_bus_groups,
>  };
>  EXPORT_SYMBOL_GPL(fsl_mc_bus_type);

No documentation update as well?

--
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/5] mfd: sec: Add support for S2MPS15 PMIC

[Alim Akhtar]

Hello

On 10/26/2015 07:59 PM, Lee Jones wrote:

On Mon, 26 Oct 2015, Alim Akhtar wrote:


Hi Lee,
Thanks for looking into this.

On 10/26/2015 04:36 PM, Lee Jones wrote:

On Mon, 26 Oct 2015, Alim Akhtar wrote:


From: Thomas Abraham 

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski 
---
  drivers/mfd/sec-core.c  |   31 +++
  drivers/mfd/sec-irq.c   |8 ++
  include/linux/mfd/samsung/core.h|1 +
  include/linux/mfd/samsung/s2mps15.h |  161 +++
  4 files changed, 201 insertions(+)
  create mode 100644 include/linux/mfd/samsung/s2mps15.h

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
  };

+static const struct mfd_cell s2mps15_devs[] = {
+   {
+   .name = "s2mps15-pmic",
+   }, {
+   .name = "s2mps15-rtc",
+   }, {


Why don't these have compatibles?


s2mps15-pmic does have compatible below in sec_dt_match[].


Woah!!  What's going on here?  You're matching the MFD and Regulator
drivers with the same compatible string.  And then registering the
Regulator device as an MFD.  That's a bit confusing don't you think?


Sorry for the confusion, as explained in the binding documentation,
S2MPS15 is a multi-function device which has rtc, regulator and clk 
provider as a sub-blocks. And each of these sub-blocks are represented
as child node of parent MFD node. Out of these only clk controller child 
node needs its own compatible string to populate of_node structure of 
the device so that it can access properties of this sub-node in 
drivers/clk/clk-s2mps11.c.

I just followed "Documentation/devicetree/bindings/mfd/s2mps11.txt"
to implement s2mps15.



s2mps15-rtc does not need one as rtc driver does not support OF yet.
So no DT node for this as of now.


[...]


--
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/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()

[Paul E. McKenney]

On Tue, Oct 27, 2015 at 02:19:39PM +0900, Tejun Heo wrote:
> Hello,
> 
> On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> > > I believe that the above should instead be:
> > >
> > > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
> 
> I should have just used list_entry() here.  It's just offseting the
> pointer to set up the initial iteration point.

OK, that sounds much better!

> ...
> > That said, I'm not sure why it doesn't just do the normal
> > 
> > rcu_read_lock();
> > list_for_each_entry_rcu(wb, >wb_list, bdi_node) {
> > 
> > }
> > rcu_read_unlock();
> > 
> > like the other places do. It looks like it wants that
> > "list_for_each_entry_continue_rcu()" because it does that odd "pin
> > entry and drop rcu lock and retake it and continue where you left
> > off", but I'm not sure why the continue version would be so
> > different.. It's going to do that "follow next entry" regardless, and
> > the "goto restart" doesn't look like it actually adds anything. If
> > following the next pointer is ok even after having released the RCU
> > read lock, then I'm not seeing why the end of the loop couldn't just
> > do
> > 
> > rcu_read_unlock();
> > wb_wait_for_completion(bdi, _work_done);
> > rcu_read_lock();
> > 
> > and just continue the loop (and the pinning of "wb" and releasing the
> > "last_wb" thing in the *next* iteration should make it all work the
> > same).
> > 
> > Adding Tejun to the cc, because this is his code and there's probably
> > something subtle I'm missing. Tejun, can you take a look? It's
> > bdi_split_work_to_wbs() in fs/fs-writeback.c.
> 
> Yeah, just releasing and regrabbing should work too as the iterator
> doesn't depend on anything other than the current entry (e.g. as
> opposed to imaginary list_for_each_entry_safe_rcu()).  It's slightly
> icky to meddle with locking behind the iterator's back tho.  Either
> way should be fine but how about something like the following?
> 
> Subject: writeback: don't use list_entry_rcu() for pointer offsetting in 
> bdi_split_work_to_wbs()
> 
> bdi_split_work_to_wbs() uses list_for_each_entry_rcu_continue() to
> walk @bdi->wb_list.  To set up the initial iteration condition, it
> uses list_entry_rcu() to calculate the entry pointer corresponding to
> the list head; however, this isn't an actual RCU dereference and using
> list_entry_rcu() for it ended up breaking a proposed list_entry_rcu()
> change because it was feeding an non-lvalue pointer into the macro.
> 
> Don't use the RCU variant for simple pointer offsetting.  Use
> list_entry() instead.
> 
> Signed-off-by: Tejun Heo 

Acked-by: Paul E. McKenney 

> ---
>  fs/fs-writeback.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 29e4599..7378169 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -779,8 +779,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info 
> *bdi,
> bool skip_if_busy)
>  {
>   struct bdi_writeback *last_wb = NULL;
> - struct bdi_writeback *wb = list_entry_rcu(>wb_list,
> - struct bdi_writeback, bdi_node);
> + struct bdi_writeback *wb = list_entry(>wb_list,
> +   struct bdi_writeback, bdi_node);
> 
>   might_sleep();
>  restart:
> 

--
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/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()

[Paul E. McKenney]

On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> On Mon, Oct 26, 2015 at 11:55 PM, Paul E. McKenney
>  wrote:
> >> struct bdi_writeback *last_wb = NULL;
> >> struct bdi_writeback *wb = list_entry_rcu(>wb_list,
> >
> > I believe that the above should instead be:
> >
> > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
> 
> I don't think you can do that.
> 
> You haven't even taken the RCU read lock yet at this point.
> 
> What the code seems to try to do is to get the "head pointer" of the
> list before taking the read lock (since _that_ is stable), and then
> follow the list under the lock.
> 
> You're making it actually follow the first RCU pointer too early.

Good point, color me dazed and confused.  :-/

Thanx, Paul

> That said, I'm not sure why it doesn't just do the normal
> 
> rcu_read_lock();
> list_for_each_entry_rcu(wb, >wb_list, bdi_node) {
> 
> }
> rcu_read_unlock();
> 
> like the other places do. It looks like it wants that
> "list_for_each_entry_continue_rcu()" because it does that odd "pin
> entry and drop rcu lock and retake it and continue where you left
> off", but I'm not sure why the continue version would be so
> different.. It's going to do that "follow next entry" regardless, and
> the "goto restart" doesn't look like it actually adds anything. If
> following the next pointer is ok even after having released the RCU
> read lock, then I'm not seeing why the end of the loop couldn't just
> do
> 
> rcu_read_unlock();
> wb_wait_for_completion(bdi, _work_done);
> rcu_read_lock();
> 
> and just continue the loop (and the pinning of "wb" and releasing the
> "last_wb" thing in the *next* iteration should make it all work the
> same).
> 
> Adding Tejun to the cc, because this is his code and there's probably
> something subtle I'm missing. Tejun, can you take a look? It's
> bdi_split_work_to_wbs() in fs/fs-writeback.c.
> 
> Linus
> 

--
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] dt-bindings: add document of mediatek efuse driver

[andrew-ct chen]

On Mon, 2015-10-26 at 10:55 +, Srinivas Kandagatla wrote:
> 
> On 26/10/15 10:23, Sascha Hauer wrote:
> > On Mon, Oct 26, 2015 at 09:56:14AM +, Srinivas Kandagatla wrote:
> >>
> >>
> >> On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote:
> >>> From: Andrew-CT Chen 
> >>>
> >>> Add Mediatek MT8173 EFUSE Devicetree binding file
> >>>
> >>> Signed-off-by: Andrew-CT Chen 
> >>
> >> Looks good to me, minor comment below.
> >>
> >> Will queue this for v4.5 once v4.4-rc1 is released.
> >>
> >>
> >>> ---
> >>>   .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 
> >>> ++
> >>>   1 file changed, 36 insertions(+)
> >>>   create mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt 
> >>> b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> >>> new file mode 100644
> >>> index 000..92edc3d
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> >>> @@ -0,0 +1,36 @@
> >>> += Mediatek MTK-EFUSE device tree bindings =
> >>> +
> >>> +This binding is intended to represent MTK-EFUSE which is found in most 
> >>> Mediatek SOCs.
> >>> +
> >>> +Required properties:
> >>> +- compatible: should be "mediatek,mt8173-efuse" or 
> >>> "mediatek,mt8135-efuse"
> >>
> >> Can we make the compatible more generic for mediatek socs? Like
> >> "mediatek,efuse"  Or are they different in each SOC?
> >
> > While we can add an additional "mediatek,efuse" compatible we should
> > always add the most specific compatible first. Otherwise we cannot
> > differentiate between SoCs later without changing the device tree.
> Yes, that’s correct.
> 
> AFAIK, Ideally the driver should have more generic compatible string 
> unless there is any SOC specific thing, and DT can still use the order 
> of specific, generic compatible strings. If not we would end up adding 
> compatible strings into the driver for every new SOC.

We will modify for generic compatible string like "mediatek,efuse" and
rebase it to v4.4-rc1.

> 
> --srini
> 
> >
> > Sascha
> >


--
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 2/3] nvmem: mediatek: Add Mediatek EFUSE driver

[andrew-ct chen]

On Mon, 2015-10-26 at 09:56 +, Srinivas Kandagatla wrote:
> On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote:
> > From: Andrew-CT Chen 
> >
> > Add Mediatek EFUSE driver to access hardware data like
> > thermal sensor calibration or HDMI impedance.
> >
> > Signed-off-by: Andrew-CT Chen 
> 
> Dirver looks pretty simple, below are few minor nits.
> 
> Please rebase this patch on top of v4.4-rc1 once its released in few 
> weeks, so that I can queue this driver for v4.5.

We will rebase it.

> 
> > ---
> >   drivers/nvmem/Kconfig | 11 ++
> >   drivers/nvmem/Makefile|  1 +
> >   drivers/nvmem/mtk-efuse.c | 89 
> > +++
> >   3 files changed, 101 insertions(+)
> >   create mode 100644 drivers/nvmem/mtk-efuse.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 8db2978..1bd5badc 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -14,6 +14,17 @@ menuconfig NVMEM
> >
> >   if NVMEM
> >
> > +config MTK_EFUSE
> > +   tristate "Mediatek SoCs EFUSE support"
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   select REGMAP_MMIO
> > +   help
> > + This is a driver to access hardware related data like sensor
> > + calibration, HDMI impedance etc.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called efuse-mtk.
> > +
> >   config QCOM_QFPROM
> > tristate "QCOM QFPROM Support"
> > depends on ARCH_QCOM || COMPILE_TEST
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index 4328b93..916b727 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_NVMEM) += nvmem_core.o
> >   nvmem_core-y  := core.o
> >
> >   # Devices
> > +obj-$(CONFIG_MTK_EFUSE)+= mtk-efuse.o
> 
> For consistency reasons, could you do this similar to other drivers.
> 
> >   obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
> >   nvmem_qfprom-y:= qfprom.o
> >   obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
> > diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> > new file mode 100644
> > index 000..9021c0b
> > --- /dev/null
> > +++ b/drivers/nvmem/mtk-efuse.c
> > @@ -0,0 +1,89 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Andrew-CT Chen 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static struct regmap_config mtk_regmap_config = {
> > +   .reg_bits = 32,
> > +   .val_bits = 32,
> > +   .reg_stride = 4,
> > +};
> > +
> > +static int mtk_efuse_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct resource *res;
> > +   struct nvmem_device *nvmem;
> > +   struct nvmem_config *econfig;
> > +   struct regmap *regmap;
> > +   void __iomem *base;
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   base = devm_ioremap_resource(dev, res);
> > +   if (IS_ERR(base))
> > +   return PTR_ERR(base);
> > +
> > +   econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
> > +   if (!econfig)
> > +   return -ENOMEM;
> Why not use static econfig variable?
> 
> > +
> > +   mtk_regmap_config.max_register = resource_size(res) - 1;
> > +
> > +   regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
> > +   if (IS_ERR(regmap)) {
> > +   dev_err(dev, "regmap init failed\n");
> > +   return PTR_ERR(regmap);
> > +   }
> > +
> > +   econfig->dev = dev;
> > +   econfig->owner = THIS_MODULE;
> > +   nvmem = nvmem_register(econfig);
> > +   if (IS_ERR(nvmem))
> > +   return PTR_ERR(nvmem);
> > +
> > +   platform_set_drvdata(pdev, nvmem);
> > +
> > +   return 0;
> > +}
> > +
> > +static int mtk_efuse_remove(struct platform_device *pdev)
> > +{
> > +   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
> > +
> > +   return nvmem_unregister(nvmem);
> > +}
> > +
> > +static const struct of_device_id mtk_efuse_of_match[] = {
> > +   { .compatible = "mediatek,mt8135-efuse",},
> > +   { .compatible = "mediatek,mt8173-efuse",},
> > +   {/* sentinel */},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
> > +
> > +static struct platform_driver mtk_efuse_driver = {
> > +   .probe = mtk_efuse_probe,
> > +   .remove = mtk_efuse_remove,
> > +   .driver = {
> > +   .name = "mediatek,efuse",
> > +   .of_match_table = mtk_efuse_of_match,
> > +   },
> > +};
> > 

Re: [PATCH] clk: qcom: msm8960: Fix dsi1/2 halt bits

[Archit Taneja]

On 10/27/2015 06:53 AM, Stephen Boyd wrote:

The halt bits for these clocks seem wrong. I get the following
warning while booting on an msm8960-cdp:

WARNING: CPU: 0 PID: 1 at drivers/clk/qcom/clk-branch.c:97 
clk_branch_toggle+0xd0/0x138()
dsi1_clk status stuck at 'on'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc3-00113-g5532cfb567fe #110
Hardware name: Qualcomm (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] 
(clk_branch_toggle+0xd0/0x138)
[] (clk_branch_toggle) from [] 
(clk_disable_unused_subtree+0x98/0x1b0)
[] (clk_disable_unused_subtree) from [] 
(clk_disable_unused_subtree+0x20/0x1b0)
[] (clk_disable_unused_subtree) from [] 
(clk_disable_unused+0x58/0xd8)
[] (clk_disable_unused) from [] (do_one_initcall+0xac/0x1ec)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x11c/0x1e8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)

Fix the status bits and the errors go away.

Fixes: 5532cfb567fe ("clk: qcom: mmcc-8960: Add DSI related clocks")
Cc: Archit Taneja 
Signed-off-by: Stephen Boyd 
---


Acked-by: Archit Taneja 

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

--
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] Staging: wilc1000: Fix warning prefer eth_broadcast_addr over memset()

[Greg KH]

On Tue, Oct 27, 2015 at 01:21:46AM +0530, Punit Vara wrote:
> This patch is to the host_interface.c that fixes up following
> warning by checkpatch.pl:
> 
> -Prefer eth_broadcast_addr() over memset()
> 
> Signed-off-by: Punit Vara 
> ---
>  drivers/staging/wilc1000/host_interface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 09a6c98..87b4eb8 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -4688,7 +4688,7 @@ s32 host_int_del_station(struct host_if_drv *hif_drv, 
> const u8 *pu8MacAddr)
>   msg.drv = hif_drv;
>  
>   if (pu8MacAddr == NULL)
> - memset(pstrDelStationMsg->mac_addr, 255, ETH_ALEN);
> + eth_broadcast_addr(pstrDelStationMsg->mac_addr);
>   else
>   memcpy(pstrDelStationMsg->mac_addr, pu8MacAddr, ETH_ALEN);
>  

Doesn't apply to my staging.git tree at all :(
--
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/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()

[Tejun Heo]

Hello,

On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> > I believe that the above should instead be:
> >
> > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,

I should have just used list_entry() here.  It's just offseting the
pointer to set up the initial iteration point.

...
> That said, I'm not sure why it doesn't just do the normal
> 
> rcu_read_lock();
> list_for_each_entry_rcu(wb, >wb_list, bdi_node) {
> 
> }
> rcu_read_unlock();
> 
> like the other places do. It looks like it wants that
> "list_for_each_entry_continue_rcu()" because it does that odd "pin
> entry and drop rcu lock and retake it and continue where you left
> off", but I'm not sure why the continue version would be so
> different.. It's going to do that "follow next entry" regardless, and
> the "goto restart" doesn't look like it actually adds anything. If
> following the next pointer is ok even after having released the RCU
> read lock, then I'm not seeing why the end of the loop couldn't just
> do
> 
> rcu_read_unlock();
> wb_wait_for_completion(bdi, _work_done);
> rcu_read_lock();
> 
> and just continue the loop (and the pinning of "wb" and releasing the
> "last_wb" thing in the *next* iteration should make it all work the
> same).
> 
> Adding Tejun to the cc, because this is his code and there's probably
> something subtle I'm missing. Tejun, can you take a look? It's
> bdi_split_work_to_wbs() in fs/fs-writeback.c.

Yeah, just releasing and regrabbing should work too as the iterator
doesn't depend on anything other than the current entry (e.g. as
opposed to imaginary list_for_each_entry_safe_rcu()).  It's slightly
icky to meddle with locking behind the iterator's back tho.  Either
way should be fine but how about something like the following?

Subject: writeback: don't use list_entry_rcu() for pointer offsetting in 
bdi_split_work_to_wbs()

bdi_split_work_to_wbs() uses list_for_each_entry_rcu_continue() to
walk @bdi->wb_list.  To set up the initial iteration condition, it
uses list_entry_rcu() to calculate the entry pointer corresponding to
the list head; however, this isn't an actual RCU dereference and using
list_entry_rcu() for it ended up breaking a proposed list_entry_rcu()
change because it was feeding an non-lvalue pointer into the macro.

Don't use the RCU variant for simple pointer offsetting.  Use
list_entry() instead.

Signed-off-by: Tejun Heo 
---
 fs/fs-writeback.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 29e4599..7378169 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -779,8 +779,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info 
*bdi,
  bool skip_if_busy)
 {
struct bdi_writeback *last_wb = NULL;
-   struct bdi_writeback *wb = list_entry_rcu(>wb_list,
-   struct bdi_writeback, bdi_node);
+   struct bdi_writeback *wb = list_entry(>wb_list,
+ struct bdi_writeback, bdi_node);
 
might_sleep();
 restart:
--
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] staging: fsl-mc: Management Complex restool driver

[Scott Wood]

On Sun, 2015-10-25 at 17:41 -0500, Lijun Pan wrote:
> The kernel support for the restool (a user space resource management
> tool) is a driver for the /dev/dprc.N device file.
> Its purpose is to provide an ioctl interface,
> which the restool uses to interact with the MC bus driver
> and with the MC firmware.
> We allocate a dpmcp at driver initialization,
> and keep that dpmcp until driver exit.
> We use that dpmcp by default.
> If that dpmcp is in use, we create another portal at run time
> and destroy the newly created portal after use.
> The ioctl RESTOOL_SEND_MC_COMMAND sends user space command to fsl-mc
> bus and utilizes the fsl-mc bus to communicate with MC firmware.
> The ioctl RESTOOL_DPRC_SYNC request the mc-bus launch
> objects scan under root dprc.
> In order to support multiple root dprc, we utilize the bus notify
> mechanism to scan fsl_mc_bus_type for the newly added root dprc.
> After discovering the root dprc, it creates a miscdevice
> /dev/dprc.N to associate with this root dprc.
> 
> Signed-off-by: Lijun Pan 
> ---
>  drivers/staging/fsl-mc/bus/Kconfig  |   7 +-
>  drivers/staging/fsl-mc/bus/Makefile |   3 +
>  drivers/staging/fsl-mc/bus/mc-ioctl.h   |  24 ++
>  drivers/staging/fsl-mc/bus/mc-restool.c | 488 
> 
>  4 files changed, 521 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-ioctl.h
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-restool.c
> 
> diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-
> mc/bus/Kconfig
> index 0d779d9..39c6ef9 100644
> --- a/drivers/staging/fsl-mc/bus/Kconfig
> +++ b/drivers/staging/fsl-mc/bus/Kconfig
> @@ -21,4 +21,9 @@ config FSL_MC_BUS
> Only enable this option when building the kernel for
> Freescale QorQIQ LS2 SoCs.
>  
> -
> +config FSL_MC_RESTOOL
> +tristate "Freescale Management Complex (MC) restool driver"
> +depends on FSL_MC_BUS
> +help
> +  Driver that provides kernel support for the Freescale Management
> +   Complex resource manager user-space tool.
> diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-
> mc/bus/Makefile
> index 25433a9..28b5fc0 100644
> --- a/drivers/staging/fsl-mc/bus/Makefile
> +++ b/drivers/staging/fsl-mc/bus/Makefile
> @@ -15,3 +15,6 @@ mc-bus-driver-objs := mc-bus.o \
> mc-allocator.o \
> dpmcp.o \
> dpbp.o
> +
> +# MC restool kernel support
> +obj-$(CONFIG_FSL_MC_RESTOOL) += mc-restool.o
> diff --git a/drivers/staging/fsl-mc/bus/mc-ioctl.h b/drivers/staging/fsl-
> mc/bus/mc-ioctl.h
> new file mode 100644
> index 000..e52f907
> --- /dev/null
> +++ b/drivers/staging/fsl-mc/bus/mc-ioctl.h
> @@ -0,0 +1,24 @@
> +/*
> + * Freescale Management Complex (MC) ioclt interface

ioctl

> + *
> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
> + * Author: Lijun Pan 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +#ifndef _FSL_MC_IOCTL_H_
> +#define _FSL_MC_IOCTL_H_
> +
> +#include 
> +
> +#define RESTOOL_IOCTL_TYPE   'R'
> +
> +#define RESTOOL_DPRC_SYNC \
> + _IO(RESTOOL_IOCTL_TYPE, 0x2)
> +
> +#define RESTOOL_SEND_MC_COMMAND \
> + _IOWR(RESTOOL_IOCTL_TYPE, 0x4, struct mc_command)

Look at Documentation/ioctl/ioctl-number.txt and reserve a range within 'R' 
that doesn't conflict.

Add thorough documentation of this API.  

I'm not sure how it's usually handled with staging drivers, but eventually 
this will need to move to an appropriate uapi header.  Is this functionality 
even needed before the driver comes out of staging?  I don't see "userspace 
restool support" in drivers/staging/fsl-mc/TODO.

Don't reference struct mc_command without including the header that defines 
it.

> +#endif /* _FSL_MC_IOCTL_H_ */
> diff --git a/drivers/staging/fsl-mc/bus/mc-restool.c b/drivers/staging/fsl-
> mc/bus/mc-restool.c
> new file mode 100644
> index 000..a219172
> --- /dev/null
> +++ b/drivers/staging/fsl-mc/bus/mc-restool.c
> @@ -0,0 +1,488 @@
> +/*
> + * Freescale Management Complex (MC) restool driver
> + *
> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
> + * Author: Lijun Pan 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include "../include/mc-private.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "mc-ioctl.h"
> +#include "../include/mc-sys.h"
> +#include "../include/mc-cmd.h"
> +#include "../include/dpmng.h"
> +
> +/**
> + * Maximum number of DPRCs that can be opened at the same time
> + */
> +#define MAX_DPRC_HANDLES 64
> +
> +/**
> + * restool_misc - information 

Guten Tag.

[zhongjun]

Guten Tag,

Ich brauche einen ausländischen Partner für einen gemeinsamen Geschäfts 
Vorschlag, der auf die Übertragung von einer großen Geldsumme an einem 
ausländischen Konto bezieht, als Empfänger der Mittel. Alles an dieser 
Transaktion rechtlich ohne Brücke der Finanzbehörde sowohl in meinem Land und 
yours.I wil gönnen Sie höchste Diskretion in allen Fragen rund um dieses 
Problem zu beobachten, durchgeführt werden. Wenn Sie interessiert sind, 
antworten Sie bitte zurück über meine private E-Mail-Adresse unten geschrieben, 
gebe ich Ihnen mehr über mich selbst mit dem Finanzinstitut I dargestellt und 
tatsächlichen Beträge beinhaltet zum Projekt, sobald ich Ihre positive Antwort 
erhalten.

Private E-Mail: fu.zh...@fuzhongjun.net


Freundlichen Gruß,

Geschäftsführer.

China-Bank.
--
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] get_maintainer: Don't fallback to git by default

[Laura Abbott]

On 10/26/15 9:57 PM, j...@perches.com wrote:

On 2015-10-26 19:47, Theodore Ts'o wrote:

What if we have a git_fallback "auto" mode which only falls back to
using git if there is no entry in the MAINTAINERS file?  That might
address the concern which Laura raised, without blocking this
change until the MAINTAINERS file is fully populated.


That's what happens already right now.


Not with the change proposed though

--
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] get_maintainer: Don't fallback to git by default

[joe]

On 2015-10-26 19:47, Theodore Ts'o wrote:

What if we have a git_fallback "auto" mode which only falls back to
using git if there is no entry in the MAINTAINERS file?  That might
address the concern which Laura raised, without blocking this
change until the MAINTAINERS file is fully populated.


That's what happens already right now.
--
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 0/5] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

> This patch set adds the AF_ALG user space API to externalize the
> asymmetric cipher API recently added to the kernel crypto API.
> 
> The patch set is tested with the user space library of libkcapi [1].
> Use [1] test/test.sh for a full test run. The test covers the
> following scenarios:
> 
>   * sendmsg of one IOVEC
> 
>   * sendmsg of 16 IOVECs with non-linear buffer
> 
>   * vmsplice of one IOVEC
> 
>   * vmsplice of 15 IOVECs with non-linear buffer
> 
>   * invoking multiple separate cipher operations with one
> open cipher handle
> 
>   * encryption with private key (using vector from testmgr.h)
> 
>   * encryption with public key (using vector from testmgr.h)
> 
>   * decryption with private key (using vector from testmgr.h)

after having discussions with David Howells and David Woodhouse, I don't think 
we should expose akcipher via AF_ALG at all. I think the akcipher operations 
for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first 
place. With akcipher you are pretty much bound to public and private keys and 
the key is the important part and not the akcipher itself. Especially since we 
want to support private keys in hardware (like TPM for example).

It seems more appropriate to use keyctl to derive the symmetric session key 
from your asymmetric key. And then use the symmetric session key id with 
skcipher via AF_ALG. Especially once symmetric key type has been introduced 
this seems to be trivial then.

I am not really in favor of having two userspace facing APIs for asymmetric 
cipher usage. And we need to have an API that is capable to work with hardware 
keys.

Regards

Marcel

--
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/8] add missing of_node_put

[David Miller]

From: Julia Lawall 
Date: Sun, 25 Oct 2015 14:56:59 +0100

> 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):
 ...

Series applied, thanks a lot Julia.
--
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 v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram

[Scott Wood]

On Sun, 2015-10-25 at 22:15 -0500, Zhao Qiang-B45475 wrote:
> On Sat, 2015-10-24 at 04:59 AM, Wood Scott-B07421  
> wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Saturday, October 24, 2015 4:59 AM
> > To: Zhao Qiang-B45475 
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > pau...@samba.org
> > Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
> > 
> > Don't send HTML e-mail.
> > 
> > On Fri, 2015-10-23 at 02:06 -0500, Zhao Qiang-B45475 wrote:
> > > On Fri, 2015-10-23 at 11:00 AM, Wood Scott-B07421
> > > 
> > > wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, October 23, 2015 11:00 AM
> > > > To: Zhao Qiang-B45475 
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > > pau...@samba.org
> > > > Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE
> > > > muram
> > > > 
> > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > > -/**
> > > > > +/*
> > > > >   * cpm_muram_alloc - allocate the requested size worth of
> > > > > multi-user
> > > ram
> > > > >   * @size: number of bytes to allocate
> > > > >   * @align: requested alignment, in bytes @@ -141,59 +151,102 @@ 
> > > > > out:
> > > > >   */
> > > > >  unsigned long cpm_muram_alloc(unsigned long size, unsigned long
> > > > > align)  {
> > > > > - unsigned long start;
> > > > >   unsigned long flags;
> > > > > -
> > > > > + unsigned long start;
> > > > > + static struct genpool_data_align muram_pool_data;
> > > > >   spin_lock_irqsave(_muram_lock, flags);
> > > > > - cpm_muram_info.alignment = align;
> > > > > - start = rh_alloc(_muram_info, size, "commproc");
> > > > > - memset(cpm_muram_addr(start), 0, size);
> > > > > + muram_pool_data.align = align;
> > > > > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> > > > > +   _pool_data);
> > > > > + start = cpm_muram_alloc_common(size, _pool_data);
> > > > >   spin_unlock_irqrestore(_muram_lock, flags);
> > > > > -
> > > > >   return start;
> > > > >  }
> > > > >  EXPORT_SYMBOL(cpm_muram_alloc);
> > > > 
> > > > Why is muram_pool_data static?  Why is it being passed to
> > > > gen_pool_set_algo()?
> > > Cpm_muram use both align algo and fixed algo, so we need to set
> > > corresponding algo and Algo data.
> > 
> > The data gets passed in via gen_pool_alloc_data().  The point was to 
> > allow it to
> > be on the caller's stack, not a long-lived data structure shared by all 
> > callers and
> > needing synchronization.
> 
> You mean it is not necessary to point pool->data to data, just passing the 
> data to gen_pool_alloc_data()?
> However, the algo it needed to be set.
> 
> > 
> > > > The whole reason we're adding gen_pool_alloc_data()  is to avoid
> > > > that.  Do we need gen_pool_alloc_algo() too?
> > > 
> > > We add gen_pool_alloc_data() to pass data to algo, because align algo
> > > and fixed algo, Because align and fixed algos need specific data.
> > 
> > And my point is that because of that, it seems like we need a version that
> > accepts an algorithm as well.
> 
> It the user just use only one algo, it doesn’t need to set algo, 
> However, qe_muram use two algos with alloc_align function
> And alloc_fixed function.

Yes.  That is why gen_pool_alloc_data() does not accomplish what we want.  
When we were discussing gen_pool_alloc_data(), you had not yet mentioned the 
need for fixed allocations.

-Scott

--
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 v12 4/6] QE/CPM: move muram management functions to qe_common

[Scott Wood]

On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote:
> On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Saturday, October 24, 2015 4:56 AM
> > To: Zhao Qiang-B45475 
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > pau...@samba.org
> > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> > qe_common
> > 
> > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> > > 
> > > wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, October 23, 2015 11:10 AM
> > > > To: Zhao Qiang-B45475 
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > > pau...@samba.org
> > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > functions
> > > > to qe_common
> > > > 
> > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > > QE and CPM have the same muram, they use the same management
> > > > > functions. Now QE support both ARM and PowerPC, it is necessary to
> > > > > move QE to "driver/soc", so move the muram management functions
> > > > > from cpm_common to qe_common for preparing to move QE code to
> > "driver/soc"
> > > > > 
> > > > > Signed-off-by: Zhao Qiang 
> > > > > ---
> > > > > Changes for v2:
> > > > >   - no changes
> > > > > Changes for v3:
> > > > >   - no changes
> > > > > Changes for v4:
> > > > >   - no changes
> > > > > Changes for v5:
> > > > >   - no changes
> > > > > Changes for v6:
> > > > >   - using genalloc instead rheap to manage QE MURAM
> > > > >   - remove qe_reset from platform file, using
> > > > >   - subsys_initcall to call qe_init function.
> > > > > Changes for v7:
> > > > >   - move this patch from 3/3 to 2/3
> > > > >   - convert cpm with genalloc
> > > > >   - check for gen_pool allocation failure Changes for v8:
> > > > >   - rebase
> > > > >   - move BD_SC_* macro instead of copy Changes for v9:
> > > > >   - doesn't modify CPM, add a new patch to modify.
> > > > >   - rebase
> > > > > Changes for v10:
> > > > >   - rebase
> > > > > Changes for v11:
> > > > >   - remove renaming
> > > > >   - delete removing qe_reset and delete adding qe_init.
> > > > > Changes for v12:
> > > > >   - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for it.
> > > > 
> > > > Why is the SPI change part of this patch?  Why is it even part of
> > > > this patchset, rather than an independent patch sent to the SPI list
> > > > and maintainer?  If it's tied to other changes you're making,
> > > > explain that.  As is, there is zero mention of the SPI change in the
> > > > part of the e-mail that will become the git changelog.
> > > > 
> > > This SPI_FSL_CPM is cpm-spi, it is part of CPM.
> > 
> > So then why are you selecting QUICC_ENGINE?  And again, what does it have
> > to do with this patch?
> 
> Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will failed to 
> build.

Why QUICC_ENGINE and not CPM?

-Scott

--
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 net-next] bpf: make tracing helpers gpl only

[David Miller]

From: Alexei Starovoitov 
Date: Fri, 23 Oct 2015 14:58:19 -0700

> exported perf symbols are GPL only, mark eBPF helper functions
> used in tracing as GPL only as well.
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Alexei Starovoitov 

Applied.
--
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 3/5] mtd: ofpart: update devicetree binding specification

[Rob Herring]

On Sun, Oct 11, 2015 at 3:04 PM, Brian Norris
 wrote:
> Hi DT maintainers,
>
> It's a bit hypocritical of me, since I've been a slow reviewer as well,
> but... can we get some review on this one? Usually, I'm comfortable
> taking driver DT bindings without your review, but this one is a bit
> more generic and is more far-reaching than the average driver.

Sorry, missed this one. This would be a good one to send to
devicetree-spec to BTW.

> I'm not a big fan of this change, and I don't quite understand why the
> bus driver (the SPI bus, which is a level up from the SPI device / MTD
> node) can specify its grandchildren (see spi-samsung.txt). But given the

That's just an example. I just would change it.

> constraints, I think Michal's solution is OK. And I do agree that MTD's
> ofpart should be bit more specific.
>
> Anyway, a quick look and an Ack/Nak would be appreciated.

Looks fine to me:

Acked-by: Rob Herring 

>
> Thanks,
> Brian
>
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
>> To avoid conflict with other drivers using subnodes of the mtd device
>> create only one ofpart-specific node rather than any number of
>> arbitrary partition subnodes.
>>
>> Signed-off-by: Michal Suchanek 
>> ---
>> v3:
>>
>>  - rename DT node ofpart -> partitions
>> ---
>>  .../devicetree/bindings/mtd/partition.txt  | 68 
>> +-
>>  1 file changed, 40 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
>> b/Documentation/devicetree/bindings/mtd/partition.txt
>> index 8e5557d..8c2aff7 100644
>> --- a/Documentation/devicetree/bindings/mtd/partition.txt
>> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
>> @@ -4,10 +4,16 @@ Partitions can be represented by sub-nodes of an mtd 
>> device. This can be used
>>  on platforms which have strong conventions about which portions of a flash 
>> are
>>  used for what purposes, but which don't use an on-flash partition table such
>>  as RedBoot.
>> +
>> +The partition table should be partitions subnode of the mtd node. 
>> Partitions are
>> +defined in subnodes of the partitions node.
>> +
>> +For backwards compatibility partitions as direct subnodes of the mtd device 
>> are
>> +supported. This use is discouraged.
>>  NOTE: if the sub-node has a compatible string, then it is not a partition.
>>
>> -#address-cells & #size-cells must both be present in the mtd device. There 
>> are
>> -two valid values for both:
>> +#address-cells & #size-cells must both be present in the partitions subnode 
>> of the
>> +mtd device. There are two valid values for both:
>>  <1>: for partitions that require a single 32-bit cell to represent their
>>   size/address (aka the value is below 4 GiB)
>>  <2>: for partitions that require two 32-bit cells to represent their
>> @@ -28,44 +34,50 @@ Examples:
>>
>>
>>  flash@0 {
>> - #address-cells = <1>;
>> - #size-cells = <1>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>>
>> - partition@0 {
>> - label = "u-boot";
>> - reg = <0x000 0x10>;
>> - read-only;
>> - };
>> + partition@0 {
>> + label = "u-boot";
>> + reg = <0x000 0x10>;
>> + read-only;
>> + };
>>
>> - uimage@10 {
>> - reg = <0x010 0x20>;
>> + uimage@10 {
>> + reg = <0x010 0x20>;
>> + };
>>   };
>>  };
>>
>>  flash@1 {
>> - #address-cells = <1>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <2>;
>>
>> - /* a 4 GiB partition */
>> - partition@0 {
>> - label = "filesystem";
>> - reg = <0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@0 {
>> + label = "filesystem";
>> + reg = <0x 0x1 0x>;
>> + };
>>   };
>>  };
>>
>>  flash@2 {
>> - #address-cells = <2>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>>
>> - /* an 8 GiB partition */
>> - partition@0 {
>> - label = "filesystem #1";
>> - reg = <0x0 0x 0x2 0x>;
>> - };
>> + /* an 8 GiB partition */
>> + partition@0 {
>> + label = "filesystem #1";
>> + reg = <0x0 0x 0x2 0x>;
>> + };
>>
>> - /* a 4 GiB partition */
>> - partition@2 {
>> - label = "filesystem #2";
>> - reg = <0x2 0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@2 {
>> + label = "filesystem #2";
>> + reg = <0x2 

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

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 v3 net-next] bpf: fix bpf_perf_event_read() helper

[David Miller]

From: Alexei Starovoitov 
Date: Thu, 22 Oct 2015 17:10:14 -0700

> Fix safety checks for bpf_perf_event_read():
> - only non-inherited events can be added to perf_event_array map
>   (do this check statically at map insertion time)
> - dynamically check that event is local and !pmu->count
> Otherwise buggy bpf program can cause kernel splat.
> 
> Also fix error path after perf_event_attrs()
> and remove redundant 'extern'.
> 
> Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get 
> the selected hardware PMU conuter")
> Signed-off-by: Alexei Starovoitov 

Applied, although my tendancy is to agree with the sentiment that you must
respect the entire universe of valid 64-bit counter values.  I do not buy
the arguments about values overlapping error codes being unlikely or not
worth worrying about.

Just FYI...
--
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] kernel: power: replacing printk

[Saurabh Sengar]

replacing prink(s) with appropriate pr_info and pr_err

Signed-off-by: Saurabh Sengar 
---
 kernel/power/suspend.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7e4cda4..2597a96 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -245,7 +245,7 @@ static int suspend_test(int level)
 {
 #ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
-   printk(KERN_INFO "suspend debug: Waiting for %d second(s).\n",
+   pr_info("suspend debug: Waiting for %d second(s).\n",
pm_test_delay);
mdelay(pm_test_delay * 1000);
return 1;
@@ -317,7 +317,7 @@ static int suspend_enter(suspend_state_t state, bool 
*wakeup)
 
error = dpm_suspend_late(PMSG_SUSPEND);
if (error) {
-   printk(KERN_ERR "PM: late suspend of devices failed\n");
+   pr_err("PM: late suspend of devices failed\n");
goto Platform_finish;
}
error = platform_suspend_prepare_late(state);
@@ -326,7 +326,7 @@ static int suspend_enter(suspend_state_t state, bool 
*wakeup)
 
error = dpm_suspend_noirq(PMSG_SUSPEND);
if (error) {
-   printk(KERN_ERR "PM: noirq suspend of devices failed\n");
+   pr_err("PM: noirq suspend of devices failed\n");
goto Platform_early_resume;
}
error = platform_suspend_prepare_noirq(state);
@@ -486,9 +486,9 @@ static int enter_state(suspend_state_t state)
 
 #ifndef CONFIG_SUSPEND_SKIP_SYNC
trace_suspend_resume(TPS("sync_filesystems"), 0, true);
-   printk(KERN_INFO "PM: Syncing filesystems ... ");
+   pr_info("PM: Syncing filesystems ... ");
sys_sync();
-   printk("done.\n");
+   pr_info("done.\n");
trace_suspend_resume(TPS("sync_filesystems"), 0, false);
 #endif
 
-- 
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 v3] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

Thanks for your review.
I did the test and it seems that it should be ok when CONFIG_PM is not defined.
So I removed the protection code to make it more readable.
Do you think is it ok?

Best Regards,
Yuan Yao

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, October 27, 2015 10:01 AM
> To: Yuan Yao-B46683 
> Cc: ste...@agner.ch; a...@arndb.de; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume
> support
> 
> On Mon, Oct 19, 2015 at 04:31:05PM +0800, Yuan Yao wrote:
> 
> The patch overall looks fine, but
> >
> > +static int fsl_edma_suspend_late(struct device *dev)
> 
> This needs protection and will have build failure when CONFIG_PM is not
> defined
> 
> > +{
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   unsigned long flags;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   spin_lock_irqsave(_chan->vchan.lock, flags);
> > +   /* Make sure chan is idle or will force disable. */
> > +   if (unlikely(!fsl_chan->idle)) {
> > +   dev_warn(dev, "WARN: There is non-idle channel.");
> > +   fsl_edma_disable_request(fsl_chan);
> > +   fsl_edma_chan_mux(fsl_chan, 0, false);
> > +   }
> > +
> > +   fsl_chan->pm_state = SUSPENDED;
> > +   spin_unlock_irqrestore(_chan->vchan.lock, flags);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int fsl_edma_resume_early(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   fsl_chan->pm_state = RUNNING;
> > +   edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> > +   if (fsl_chan->slave_id != 0)
> > +   fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id,
> true);
> > +   }
> > +
> > +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > +   fsl_edma->membase + EDMA_CR);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct dev_pm_ops fsl_edma_pm_ops = {
> > +   .suspend_late   = fsl_edma_suspend_late,
> > +   .resume_early   = fsl_edma_resume_early,
> > +};
> 
> This one too, also why use late and early, pls add the note here
> 
> >  static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -969,6 +1042,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name   = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > +   .pm = _edma_pm_ops,
> This will fail too if CONFIG_PM is not defined
> 
> --
> ~Vinod
--
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/5] mm: simplify reclaim path for MADV_FREE

[yalin wang]

> On Oct 27, 2015, at 10:09, Hugh Dickins  wrote:
> 
> On Mon, 19 Oct 2015, Minchan Kim wrote:
> 
>> I made reclaim path mess to check and free MADV_FREEed page.
>> This patch simplify it with tweaking add_to_swap.
>> 
>> So far, we mark page as PG_dirty when we add the page into
>> swap cache(ie, add_to_swap) to page out to swap device but
>> this patch moves PG_dirty marking under try_to_unmap_one
>> when we decide to change pte from anon to swapent so if
>> any process's pte has swapent for the page, the page must
>> be swapped out. IOW, there should be no funcional behavior
>> change. It makes relcaim path really simple for MADV_FREE
>> because we just need to check PG_dirty of page to decide
>> discarding the page or not.
>> 
>> Other thing this patch does is to pass TTU_BATCH_FLUSH to
>> try_to_unmap when we handle freeable page because I don't
>> see any reason to prevent it.
>> 
>> Cc: Hugh Dickins 
>> Cc: Mel Gorman 
>> Signed-off-by: Minchan Kim 
> 
> Acked-by: Hugh Dickins 
> 
> This is sooo much nicer than the code it replaces!  Really good.
> Kudos also to Hannes for suggesting this approach originally, I think.
> 
> I hope this implementation satisfies a good proportion of the people
> who have been wanting MADV_FREE: I'm not among them, and have long
> lost touch with those discussions, so won't judge how usable it is.
> 
> I assume you'll refactor the series again before it goes to Linus,
> so the previous messier implementations vanish?  I notice Andrew
> has this "mm: simplify reclaim path for MADV_FREE" in mmotm as
> mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch:
> I guess it all got much too messy to divide up in a hurry.
> 
> I've noticed no problems in testing (unlike the first time you moved
> to working with pte_dirty); though of course I've not been using
> MADV_FREE itself at all.
> 
> One aspect has worried me for a while, but I think I've reached the
> conclusion that it doesn't matter at all.  The swap that's allocated
> in add_to_swap() would normally get freed again (after try_to_unmap
> found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom
> of shrink_page_list(), in __remove_mapping(), yes?
> 
> The bit that worried me is that on rare occasions, something unknown
> might take a speculative reference to the page, and __remove_mapping()
> fail to freeze refs for that reason.  Much too rare to worry over not
> freeing that page immediately, but it leaves us with a PageUptodate
> PageSwapCache !PageDirty page, yet its contents are not the contents
> of that location on swap.
> 
> But since this can only happen when you have *not* inserted the
> corresponding swapent anywhere, I cannot think of anything that would
> have a legitimate interest in its contents matching that location on swap.
> So I don't think it's worth looking for somewhere to add a SetPageDirty
> (or a delete_from_swap_cache) just to regularize that case.
> 
>> ---
>> include/linux/rmap.h |  6 +
>> mm/huge_memory.c |  5 
>> mm/rmap.c| 42 ++
>> mm/swap_state.c  |  5 ++--
>> mm/vmscan.c  | 64 
>> 
>> 5 files changed, 30 insertions(+), 92 deletions(-)
>> 
>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
>> index 6b6233fafb53..978f65066fd5 100644
>> --- a/include/linux/rmap.h
>> +++ b/include/linux/rmap.h
>> @@ -193,8 +193,7 @@ static inline void page_dup_rmap(struct page *page, bool 
>> compound)
>>  * Called from mm/vmscan.c to handle paging out
>>  */
>> int page_referenced(struct page *, int is_locked,
>> -struct mem_cgroup *memcg, unsigned long *vm_flags,
>> -int *is_pte_dirty);
>> +struct mem_cgroup *memcg, unsigned long *vm_flags);
>> 
>> #define TTU_ACTION(x) ((x) & TTU_ACTION_MASK)
>> 
>> @@ -272,11 +271,8 @@ int rmap_walk(struct page *page, struct 
>> rmap_walk_control *rwc);
>> static inline int page_referenced(struct page *page, int is_locked,
>>struct mem_cgroup *memcg,
>>unsigned long *vm_flags,
>> -  int *is_pte_dirty)
>> {
>>  *vm_flags = 0;
>> -if (is_pte_dirty)
>> -*is_pte_dirty = 0;
>>  return 0;
>> }
>> 
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 269ed99493f0..adccfb48ce57 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -1753,11 +1753,6 @@ pmd_t *page_check_address_pmd(struct page *page,
>>  return NULL;
>> }
>> 
>> -int pmd_freeable(pmd_t pmd)
>> -{
>> -return !pmd_dirty(pmd);
>> -}
>> -
>> #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
>> 
>> int hugepage_madvise(struct vm_area_struct *vma,
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 94ee372e238b..fd64f79c87c4 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -797,7 +797,6 @@ int page_mapped_in_vma(struct page *page, struct 
>> vm_area_struct 

Re: [net-next PATCHv2] bpf: Output error message to logbuf when loading failure

[Wangnan (F)]

On 2015/10/27 11:26, Alexei Starovoitov wrote:

On Mon, Oct 26, 2015 at 07:13:08AM +, Wang Nan wrote:

Many reasons can make bpf_prog_load() return EINVAL. This patch utilizes
logbuf to deliver the actual reason of the failure.

Without this patch, it is very easy for user to pass an object with
"version" section not match the kernel version code, and the problem
is hard to determine from return code (EINVAL).

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Arnaldo Carvalho de Melo 
Cc: David S. Miller 
Cc: Wu Fengguang 

NACK
for both implementation and design.

OK. Let perf to report error message.

Thank you.

--
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] drivers: of: removing assignment of 0 to static variable

[Saurabh Sengar]

no need to initialise static variable with 0, hence correcting it.

Signed-off-by: Saurabh Sengar 
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..63699dd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob,
struct property *pp, **prev_pp = NULL;
const char *pathp;
unsigned int l, allocl;
-   static int depth = 0;
+   static int depth;
int old_depth;
int offset;
int has_name = 0;
-- 
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 v2 07/10] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm

[Huang Rui]

On Fri, Oct 23, 2015 at 10:20:59PM +0800, Guenter Roeck wrote:
> On 10/19/2015 07:28 PM, Huang Rui wrote:
> > This patch introduces an algorithm that computes the average power by
> > reading a delta value of “core power accumulator” register during
> > measurement interval, and then dividing delta value by the length of
> > the time interval.
> >
> > User is able to use power1_average entry to measure the processor power
> > consumption and power1_average_interval entry to set the interval.
> >
> > A simple example:
> >
> > ray@hr-ub:~/tip$ sensors
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1:   23.73 mW (avg = 634.63 mW, interval =   0.01 s)
> > (crit =  15.00 W)
> >
> > ...
> >
> > The result is current average processor power consumption in 10
> > millisecond. The unit of the result is uWatt.
> >
> > Suggested-by: Guenter Roeck 
> > Signed-off-by: Huang Rui 
> > Cc: Borislav Petkov 
> > Cc: Peter Zijlstra 
> > Cc: Ingo Molnar 
> > ---
> >   drivers/hwmon/fam15h_power.c | 120 
> > +++
> >   1 file changed, 120 insertions(+)
> >
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index 6321f73..a5a539e 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -26,6 +26,9 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> >
> > @@ -64,6 +67,10 @@ struct fam15h_power_data {
> > u64 cu_acc_power[MAX_CUS];
> > /* performance timestamp counter */
> > u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > +   /* online/offline status of current compute unit */
> > +   int cu_on[MAX_CUS];
> > +   unsigned long power_period;
> > +   struct mutex acc_pwr_mutex;
> 
> Can you elaborate a bit about what this mutex is supposed to protect ?
> To me it seems that it doesn't really protect anything.
> 

My orignal intention is to avoid race condition from user space.
Actually you know, show_power_acc, acc_set_power_period will expose to
application layer.

> >   };
> >
> >   static ssize_t show_power(struct device *dev,
> > @@ -132,11 +139,15 @@ static void do_read_registers_on_cu(void *_data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu = cpu / cores_per_cu;
> >
> > +   mutex_lock(>acc_pwr_mutex);
> > WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
> > >cu_acc_power[cu]));
> >
> > WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
> > >cpu_sw_pwr_ptsc[cu]));
> > +
> > +   data->cu_on[cu] = 1;
> > +   mutex_unlock(>acc_pwr_mutex);
> 
> ... for example, while this protects cu_on[cu],
> 
> >   }
> >
> >   static int read_registers(struct fam15h_power_data *data)
> > @@ -148,6 +159,10 @@ static int read_registers(struct fam15h_power_data 
> > *data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >
> > +   mutex_lock(>acc_pwr_mutex);
> > +   memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
> > +   mutex_unlock(>acc_pwr_mutex);
> 
> ... this code may well overwrite that same value.
> 

Yes, but I only need the compute unit status of the "sencond" time of 
read_registers.
Then ignore the offline compute unit to avoid hotplug issue.

> > +
> > WARN_ON_ONCE(cu_num > MAX_CUS);
> >
> > ret = zalloc_cpumask_var(, GFP_KERNEL);
> > @@ -184,18 +199,113 @@ static int read_registers(struct fam15h_power_data 
> > *data)
> > return 0;
> >   }
> >
> > +static ssize_t acc_show_power(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > +   struct fam15h_power_data *data = dev_get_drvdata(dev);
> > +   u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
> > +   jdelta[MAX_CUS];
> > +   u64 tdelta, avg_acc;
> > +   int cu, cu_num, cores_per_cu, ret;
> > +   signed long leftover;
> > +
> > +   cores_per_cu = amd_get_cores_per_cu();
> > +   cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +   ret = read_registers(data);
> > +   if (ret)
> > +   return 0;

The first time of read_registers

> > +
> > +   cu = 0;
> > +   while(cu++ < cu_num) {
> > +   prev_cu_acc_power[cu] = data->cu_acc_power[cu];
> > +   prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
> > +   }
> 
> ... and multiple parallel reads on the power attribute must produce
> pretty random values, unless I am really missing something.
> 
> > +
> > +   leftover = schedule_timeout_interruptible(
> > +   msecs_to_jiffies(data->power_period)
> > +  );
> > +   if (leftover)
> > +   return 0;
> > +
> > +   ret = read_registers(data);

The second time of read_registers

> > +   if (ret)
> > +   return 0;
> > +
> With a 10ms period, I wonder how accurate this really is.
> 

According to the HW description, the measurement interval could be on
the order of several milliseconds. That should get a 

Re: [PATCH net-next] seccomp, ptrace: add support for dumping seccomp filters

[Alexei Starovoitov]

On Tue, Oct 27, 2015 at 09:23:59AM +0900, Tycho Andersen wrote:
> This patch adds support for dumping a process' (classic BPF) seccomp
> filters via ptrace.
> 
> PTRACE_SECCOMP_GET_FILTER allows the tracer to dump the user's classic BPF
> seccomp filters. addr should be an integer which represents the ith seccomp
> filter (0 is the most recently installed filter). data should be a struct
> sock_filter * with enough room for the ith filter, or NULL, in which case
> the filter is not saved. The return value for this command is the number of
> BPF instructions the program represents, or negative in the case of errors.
> Command specific errors are ENOENT: which indicates that there is no ith
> filter in this seccomp tree, and EMEDIUMTYPE, which indicates that the ith
> filter was not installed as a classic BPF filter.
> 
> A caveat with this approach is that there is no way to get explicitly at
> the heirarchy of seccomp filters, and users need to memcmp() filters to
> decide which are inherited. This means that a task which installs two of
> the same filter can potentially confuse users of this interface.
> 
> v2: * make save_orig const
> * check that the orig_prog exists (not necessary right now, but when
>grows eBPF support it will be)
> * s/n/filter_off and make it an unsigned long to match ptrace
> * count "down" the tree instead of "up" when passing a filter offset
> 
> v3: * don't take the current task's lock for inspecting its seccomp mode
> * use a 0x42** constant for the ptrace command value
> 
> v4: * don't copy to userspace while holding spinlocks
> 
> v5: * add another condition to WARN_ON
> 
> v6: * rebase on net-next
> 
> Signed-off-by: Tycho Andersen 
> Acked-by: Kees Cook 
> CC: Will Drewry 
> Reviewed-by: Oleg Nesterov 
> CC: Andy Lutomirski 
> CC: Pavel Emelyanov 
> CC: Serge E. Hallyn 
> CC: Alexei Starovoitov 
> CC: Daniel Borkmann 

Looks fine.
Acked-by: Alexei Starovoitov 

--
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] VFIO: Add a parameter to force nonthread IRQ

[Alex Williamson]

On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> assigning a device to a guest with low latency requirement since it
> reduce the context switch to/from the IRQ thread.

Is there any way we can do this automatically?  Perhaps detecting that
we're on a RT kernel or maybe that the user is running with RT priority?
I find that module options are mostly misunderstood and misused.

> An experiment was conducted on a HSW platform for 1 minutes, with the
> guest vCPU bound to isolated pCPU. The assigned device triggered the
> interrupt every 1ms. The average EXTERNAL_INTERRUPT exit handling time
> is dropped from 5.3us to 2.2us.
> 
> Another choice is to change VFIO_DEVICE_SET_IRQS ioctl, to apply this
> option only to specific devices when in kernel irq_chip is enabled. It
> provides more flexibility but is more complex, not sure if we need go
> through that way.

Allowing the user to decide whether or not to use a threaded IRQ seems
like a privilege violation; a chance for the user to game the system and
give themselves better latency, maybe at the cost of others.  I think
we're better off trying to infer the privilege from the task priority or
kernel config or, if we run out of options, make a module option as you
have here requiring the system admin to provide the privilege.  Thanks,

Alex


> Signed-off-by: Yunhong Jiang 
> ---
>  drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
> b/drivers/vfio/pci/vfio_pci_intrs.c
> index 1f577b4..ca1f95a 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -22,9 +22,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "vfio_pci_private.h"
>  
> +static bool nonthread_msi = 1;
> +module_param(nonthread_msi, bool, 0444);
> +
>  /*
>   * INTx
>   */
> @@ -313,6 +317,7 @@ static int vfio_msi_set_vector_signal(struct 
> vfio_pci_device *vdev,
>   char *name = msix ? "vfio-msix" : "vfio-msi";
>   struct eventfd_ctx *trigger;
>   int ret;
> + unsigned long irqflags = 0;
>  
>   if (vector >= vdev->num_ctx)
>   return -EINVAL;
> @@ -352,7 +357,10 @@ static int vfio_msi_set_vector_signal(struct 
> vfio_pci_device *vdev,
>   pci_write_msi_msg(irq, );
>   }
>  
> - ret = request_irq(irq, vfio_msihandler, 0,
> + if (nonthread_msi)
> + irqflags = IRQF_NO_THREAD;
> +
> + ret = request_irq(irq, vfio_msihandler, irqflags,
> vdev->ctx[vector].name, trigger);
>   if (ret) {
>   kfree(vdev->ctx[vector].name);



--
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/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()

[Linus Torvalds]

On Mon, Oct 26, 2015 at 11:55 PM, Paul E. McKenney
 wrote:
>> struct bdi_writeback *last_wb = NULL;
>> struct bdi_writeback *wb = list_entry_rcu(>wb_list,
>
> I believe that the above should instead be:
>
> struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,

I don't think you can do that.

You haven't even taken the RCU read lock yet at this point.

What the code seems to try to do is to get the "head pointer" of the
list before taking the read lock (since _that_ is stable), and then
follow the list under the lock.

You're making it actually follow the first RCU pointer too early.

That said, I'm not sure why it doesn't just do the normal

rcu_read_lock();
list_for_each_entry_rcu(wb, >wb_list, bdi_node) {

}
rcu_read_unlock();

like the other places do. It looks like it wants that
"list_for_each_entry_continue_rcu()" because it does that odd "pin
entry and drop rcu lock and retake it and continue where you left
off", but I'm not sure why the continue version would be so
different.. It's going to do that "follow next entry" regardless, and
the "goto restart" doesn't look like it actually adds anything. If
following the next pointer is ok even after having released the RCU
read lock, then I'm not seeing why the end of the loop couldn't just
do

rcu_read_unlock();
wb_wait_for_completion(bdi, _work_done);
rcu_read_lock();

and just continue the loop (and the pinning of "wb" and releasing the
"last_wb" thing in the *next* iteration should make it all work the
same).

Adding Tejun to the cc, because this is his code and there's probably
something subtle I'm missing. Tejun, can you take a look? It's
bdi_split_work_to_wbs() in fs/fs-writeback.c.

Linus
--
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: [net-next PATCHv2] bpf: Output error message to logbuf when loading failure

[Alexei Starovoitov]

On Mon, Oct 26, 2015 at 07:13:08AM +, Wang Nan wrote:
> Many reasons can make bpf_prog_load() return EINVAL. This patch utilizes
> logbuf to deliver the actual reason of the failure.
> 
> Without this patch, it is very easy for user to pass an object with
> "version" section not match the kernel version code, and the problem
> is hard to determine from return code (EINVAL).
> 
> Signed-off-by: Wang Nan 
> Cc: Alexei Starovoitov 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David S. Miller 
> Cc: Wu Fengguang 

NACK
for both implementation and design.

> + /* Don't need care the copying result too much */
> + WARN(copy_to_user(log_ubuf, log_buf, log_size),
> +  KERN_WARNING "Failed to copy BPF error note '%s' to log buffer\n",
> +  log_buf);

unprivilged user will be spamming kernel logs?!

> - if (attr->insn_cnt >= BPF_MAXINSNS)
> + if (attr->insn_cnt >= BPF_MAXINSNS) {
> + bpf_prog_load_note(attr, "Too many instructions: %d > %d\n",
> +attr->insn_cnt, BPF_MAXINSNS);
>   return -EINVAL;

if user space did that, it's wrong and can detect it
on its own.

>   if (type == BPF_PROG_TYPE_KPROBE &&
> - attr->kern_version != LINUX_VERSION_CODE)
> + attr->kern_version != LINUX_VERSION_CODE) {
> + bpf_prog_load_note(attr,
> +"Kernel version mismatch: 0x%x != 0x%x\n",
> +attr->kern_version, LINUX_VERSION_CODE);
>   return -EINVAL;

user space (perf) could have checked that on its own
without kernel changes.

>   /* find program type: socket_filter vs tracing_filter */
>   err = find_prog_type(type, prog);
> - if (err < 0)
> + if (err < 0) {
> + bpf_prog_load_note(attr, "Invalid program type: %d\n", type);
>   goto free_prog;

same here.

In general syscalls muxing different error conditions into EINVAL
is a kernel wide problem and should be solved for all.

--
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 v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording

[Wangnan (F)]

On 2015/10/26 21:02, Adrian Hunter wrote:

On 26/10/15 14:39, Wangnan (F) wrote:


On 2015/10/26 20:24, Adrian Hunter wrote:

On 26/10/15 13:41, Wang Nan wrote:

evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837
(perf evlist: Add 'system_wide' option), which is used for mixing evsels
that aren't system-wide with ones that are [1]. However, for global
system wide recording (perf record -a ...), evsel->system_wide is set
to false, which is confusion.

This patch set evsel->system_wide to true if the target.system_wide is
set, which makes evsel->system_wide a reliable way to describe whether
itself is system_wide or not.

[1] http://lkml.kernel.org/r/562df19b.2080...@intel.com

Signed-off-by: Wang Nan 
Cc: Adrian Hunter 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: Peter Zijlstra 
Cc: Li Zefan 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org
---
   tools/perf/util/evsel.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3ac4ee9c..36ecf0e 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel,
struct record_opts *opts)
   int track = evsel->tracking;
   bool per_cpu = opts->target.default_per_cpu &&
!opts->target.per_thread;
   +evsel->system_wide = opts->target.system_wide;

Well that breaks the way evsel->system_wide is used i.e. it is a parameter
to the evsel and here you just overwrote it.

Currently the only user of evsel->system_wide is IPT:

auxtrace_record__options -> intel_pt_recording_options

and it only set it to true.

So I think changing to this should make it safe:

evsel->system_wide = (evsel->system_wide || opt->target.system_wide);

Thought?

That would work although it looks like a kludge.

Have you looked at properly validating opts->no_inherit ?

Also, aren't you neglecting target->cpu_list ?


I need this because Alexei's bpf_perf_event_output() helper needs perf side
support, and it only accept no-inherit perf event. I have already made a
patch[1] to support setting inherit bit per-event, so even without this and
next patch I can continue my work on bpf output. I'd like to rethink this
patch after I finish perf support for bpf output.

Thank you.

[1] 
http://lkml.kernel.org/g/1445847884-143981-1-git-send-email-wangn...@huawei.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: [RFC PATCH] x86/cpu: Move sparsely used bit leafs into scattered features (was: Re: [PATCH 2/2] x86/cpufeature: Add CLZERO feature)

[Borislav Petkov]

On Mon, Oct 26, 2015 at 07:56:06PM -0700, Andy Lutomirski wrote:
> How few features in one leaf do we need before calling it scattered
> makes sense?  These four might make sense to keep as is...

Actually, according to hpa, all those leafs will be filled out gradually
as they're apparently going to be used for hw features. And it looks
like the AMD leaf is of the same type. So those all will be fleshed out
with time and we can keep them here, in cpufeature.h.

> ...whereas this looks totally reasonable.
> 
> FWIW, we have a ton of thses things.  Would it make sense to convert
> this to a text file giving features and their CPUID positions that
> generates the defines and the code to enumerate them?

Yeah, maybe. I'm not that really bothered by the current form too,
though.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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] bpf: sample: define aarch64 specific registers

[Alexei Starovoitov]

On Mon, Oct 26, 2015 at 05:02:19PM -0700, Yang Shi wrote:
> Define aarch64 specific registers for building bpf samples correctly.
> 
> Signed-off-by: Yang Shi 

looks good to me.
Acked-by: Alexei Starovoitov 

--
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] ARM: dts: uniphier: add system-bus-controller nodes

[Masahiro Yamada]

The System Bus Controller block has two register regions,
but having only the second one in a separate node was not nice.

Replace it with a new node with two register regions in it.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 7 +++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 7 +++
 6 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index ae13469..af49381 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 85377b2..254642f 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -232,10 +232,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb2: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 96da01e..11eb762 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -241,10 +241,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
pinctrl: pinctrl@5f801000 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 945b37f..691a17d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -216,10 +216,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index c98428c..e88559b 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi 
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ad5fb39..259f1a9 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -251,10 +251,9 @@
clock-frequency = <40>;
   

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello, Mike.

On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote:
> I don't think it's weird, it's just a thought wrt where pigeon holing
> could lead:  If you filter out current users who do so in a manner you
> consider to be in some way odd, when all the filtering is done, you may
> find that you've filtered out the vast majority of current deployment.

I think you misunderstood what I wrote.  It's not about excluding
existing odd use cases.  It's about examining the usages and
extracting the required capabilities and building an interface which
is well defined and blends well with the rest of programming interface
provided by the kernel so that those can be achieved in a saner way.

If doing acrobatics with the current interface is necessary to acheive
certain capabilities, we need to come up with a better interface for
those.  If fringe usages can be satisfied using better constructs, we
should implement that and encourage transition to a better mechanism.

> I'm not at all sure of this, but I suspect that SUSE's gigabuck size
> cgroup power user will land in the same "fringe" pigeon hole.  If so,
> that would be another sizeable dent in volume.
> 
> My point is that these power users likely _are_ your general audience.

Sure, that doesn't mean we shouldn't scrutinize the interface we
implement to support those users.  Also, cgroup also definitely had
some negative spiral effect where eccentric mechanisms and interfaces
discouraged general wider usages fortifying the argument that "we're
the main users" which in turn fed back to even weirder things being
added.  Everybody including the "heavy" users suffers from such
failures in the long term.

We sure want to support all the valid use cases from heavy users in a
reasonable way but that doesn't mean we say yes to everything.

> Sure, it was just a thought wrt "actively filter those out" and who all
> "those" may end up being.

I hope what I meant is clearer now.

Thanks.

-- 
tejun
--
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] blktrace: re-write setting q->blk_trace

[Davidlohr Bueso]

This is really about simplifying the double xchg patterns into
a single cmpxchg, with the same logic. Other than the immediate
cleanup, there are some subtleties this change deals with:

(i) While the load of the old bt is fully ordered wrt everything,
ie:

  old_bt = xchg(>blk_trace, bt); [barrier]
  if (old_bt)
 (void) xchg(>blk_trace, old_bt);[barrier]

blk_trace could still be changed between the xchg and the old_bt
load. Note that this description is merely theoretical and afaict
very small, but doing everything in a single context with cmpxchg
closes this potential race.

(ii) Ordering guarantees are obviously kept with cmpxchg.

Signed-off-by: Davidlohr Bueso 
---

v2: sorry I sent a stale version which didn't set EBUSY when the structure is
already initialized.

 kernel/trace/blktrace.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 90e72a0..e3a2618 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -437,7 +437,7 @@ int do_blk_trace_setup(struct request_queue *q, char *name, 
dev_t dev,
   struct block_device *bdev,
   struct blk_user_trace_setup *buts)
 {
-   struct blk_trace *old_bt, *bt = NULL;
+   struct blk_trace *bt = NULL;
struct dentry *dir = NULL;
int ret;
 
@@ -519,11 +519,8 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,

bt->trace_state = Blktrace_setup;
 
 	ret = -EBUSY;

-   old_bt = xchg(>blk_trace, bt);
-   if (old_bt) {
-   (void) xchg(>blk_trace, old_bt);
+   if (cmpxchg(>blk_trace, NULL, bt))
goto err;
-   }
 
 	if (atomic_inc_return(_probes_ref) == 1)

blk_register_tracepoints();
@@ -1481,7 +1478,7 @@ static int blk_trace_remove_queue(struct request_queue *q)
 static int blk_trace_setup_queue(struct request_queue *q,
 struct block_device *bdev)
 {
-   struct blk_trace *old_bt, *bt = NULL;
+   struct blk_trace *bt = NULL;
int ret = -ENOMEM;
 
 	bt = kzalloc(sizeof(*bt), GFP_KERNEL);

@@ -1497,12 +1494,9 @@ static int blk_trace_setup_queue(struct request_queue *q,
 
 	blk_trace_setup_lba(bt, bdev);
 
-	old_bt = xchg(>blk_trace, bt);

-   if (old_bt != NULL) {
-   (void)xchg(>blk_trace, old_bt);
-   ret = -EBUSY;
+   ret = -EBUSY;
+   if (cmpxchg(>blk_trace, NULL, bt))
goto free_bt;
-   }
 
 	if (atomic_inc_return(_probes_ref) == 1)

blk_register_tracepoints();
--
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/

[PATCH] perf tools: Allow BPF program attach to modules

[Wang Nan]

By extending the syntax of BPF object section names, this patch allows
user to attach BPF programs to symbol in modules. For example:

 SEC("module=i915\n"
 "parse_cmds=i915_parse_cmds")
 int parse_cmds(void *ctx)
 {
 return 1;
 }

Implementation is very simple: like what 'perf probe' does, for module,
fill 'uprobe' field in 'struct perf_probe_event'. Other parts would be
done automatically.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Brendan Gregg 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Kaixu Xia 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Zefan Li 
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo 
Link: http://lkml.kernel.org/n/ebpf-x1mxko3tby054o573zd57...@git.kernel.org
---

This patch is based on commit ad14ba45236a496a7ce25f4ea947d245b1406e40
in my git tree[1], and will be appear in the next pull request of this
perf eBPF support patchset.

[1] https://git.kernel.org/cgit/linux/kernel/git/pi3orama/linux.git

---
 tools/perf/util/bpf-loader.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index b14aff4..a85caae 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -120,10 +120,17 @@ do_config(const char *key, const char *value,
pev->target = strdup(value);
return 0;
}
+   if (strcmp(key, "module") == 0) {
+   pev->uprobes = false;
+   pev->target = strdup(value);
+   return 0;
+   }
 
pr_warning("BPF: WARNING: invalid config option in object: %s=%s\n",
   key, value);
-   pr_warning("\tHint: Currently only valid option is 'exec='\n");
+   pr_warning("\tHint: Currently valid options are:\n");
+   pr_warning("\t  'exec='\n");
+   pr_warning("\t  'module='\n");
return 0;
 }
 
-- 
1.8.3.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: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

[Boqun Feng]

On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > This patch fixes two problems to make value-returning atomics and
> > {cmp}xchg fully ordered on PPC.
> 
> Hi Boqun,
> 
> Can you please split this into two patches. One that does the cmpxchg change
> and one that changes PPC_ATOMIC_ENTRY_BARRIER.
> 

OK, make sense ;-)

> Also given how pervasive this change is I'd like to take it via the powerpc
> next tree, so can you please send this patch (which will be two after you 
> split
> it) as powerpc patches. And the rest can go via tip?
> 

One problem is that patch 5 will remove __xchg_u32 and __xchg_64
entirely, which are modified in this patch(patch 1), so there will be
some conflicts if two branch get merged, I think.

Alternative way is that all this series go to powerpc next tree as most
of the dependent patches are already there. I just need to remove
inc/dec related code and resend them when appropriate. Besides, I can
pull patch 2 out and send it as a tip patch because it's general code
and no one depends on this in this series.

To summerize:

patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.

Peter and Michael, this works for you both?

Regards,


signature.asc
Description: PGP signature

[PATCH] blktrace: re-write setting q->blk_trace

[Davidlohr Bueso]

This is really about simplifying the double xchg patterns into
a single cmpxchg, with the same logic. Other than the immediate
cleanup, there are some subtleties this change deals with:

(i) While the load of the old bt is fully ordered wrt everything,
ie:

  old_bt = xchg(>blk_trace, bt); [barrier]
  if (old_bt)
 (void) xchg(>blk_trace, old_bt);[barrier]

blk_trace could still be changed between the xchg and the old_bt
load. Note that this description is merely theoretical and afaict
very small, but doing everything in a single context with cmpxchg
closes this potential race.

(ii) Ordering guarantees are obviously kept with cmpxchg.

Signed-off-by: Davidlohr Bueso 
---
 kernel/trace/blktrace.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 90e72a0..4a30229 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -437,7 +437,7 @@ int do_blk_trace_setup(struct request_queue *q, char *name, 
dev_t dev,
   struct block_device *bdev,
   struct blk_user_trace_setup *buts)
 {
-   struct blk_trace *old_bt, *bt = NULL;
+   struct blk_trace *bt = NULL;
struct dentry *dir = NULL;
int ret;

@@ -519,11 +519,8 @@ int do_blk_trace_setup(struct request_queue *q, char 
*name, dev_t dev,
bt->trace_state = Blktrace_setup;

ret = -EBUSY;
-   old_bt = xchg(>blk_trace, bt);
-   if (old_bt) {
-   (void) xchg(>blk_trace, old_bt);
+   if (cmpxchg(>blk_trace, NULL, bt))
goto err;
-   }

if (atomic_inc_return(_probes_ref) == 1)
blk_register_tracepoints();
@@ -1481,7 +1478,7 @@ static int blk_trace_remove_queue(struct request_queue *q)
 static int blk_trace_setup_queue(struct request_queue *q,
 struct block_device *bdev)
 {
-   struct blk_trace *old_bt, *bt = NULL;
+   struct blk_trace *bt = NULL;
int ret = -ENOMEM;

bt = kzalloc(sizeof(*bt), GFP_KERNEL);
@@ -1497,12 +1494,8 @@ static int blk_trace_setup_queue(struct request_queue *q,

blk_trace_setup_lba(bt, bdev);

-   old_bt = xchg(>blk_trace, bt);
-   if (old_bt != NULL) {
-   (void)xchg(>blk_trace, old_bt);
-   ret = -EBUSY;
+   if (cmpxchg(>blk_trace, NULL, bt))
goto free_bt;
-   }

if (atomic_inc_return(_probes_ref) == 1)
blk_register_tracepoints();
--
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 net] macvtap: unbreak receiving of gro skb with frag list

[Jason Wang]

On 10/26/2015 04:30 PM, Michael S. Tsirkin wrote:
> On Mon, Oct 26, 2015 at 02:53:38PM +0800, Jason Wang wrote:
>>
>> On 10/26/2015 02:09 PM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 26, 2015 at 11:15:57AM +0800, Jason Wang wrote:
 On 10/23/2015 09:37 PM, Michael S. Tsirkin wrote:
> On Fri, Oct 23, 2015 at 12:57:05AM -0400, Jason Wang wrote:
>> We don't have fraglist support in TAP_FEATURES. This will lead
>> software segmentation of gro skb with frag list. Fixes by having
>> frag list support in TAP_FEATURES.
>>
>> With this patch single session of netperf receiving were restored from
>> about 5Gb/s to about 12Gb/s on mlx4.
>>
>> Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
>> Cc: Vlad Yasevich 
>> Cc: Michael S. Tsirkin 
>> Signed-off-by: Jason Wang 
> Thanks!
> Does this mean we should look at re-adding NETIF_F_FRAGLIST
> to virtio-net as well?
 Not sure I get the point, but probably not. This is for receiving and
 skb_copy_datagram_iter() can deal with frag list.
>>> Point is:
>>> - bridge within guest
>>> - assigned device creating gro skbs with frag list bridged to virtio
>> I see, but this problem looks not specific to virtio. Most cards does
>> not support frag list.
> These will be slower when used with a bridge then, won't they?

For forwarding, not sure. GRO has latency and cpu overhead anyway.

Anyway I can try to add the support for this.
--
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] arm: kernel: utilize hrtimer based broadcast

[Huan Wang]

Hi, Mark,

Could you comment this patch? It is based on your suggestion in 
https://patchwork.kernel.org/patch/6764231/ .

Thanks.

Best Regards,
Alison Wang

> -Original Message-
> From: Alison Wang [mailto:b18...@freescale.com]
> Sent: Friday, July 17, 2015 5:12 PM
> To: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Cc: Wang Huan-B18965
> Subject: [PATCH] arm: kernel: utilize hrtimer based broadcast
> 
> Hrtimer based broadcast is used on ARM platform. It can be registered as
> the tick broadcast device in the absence of a real external clock device.
> 
> Signed-off-by: Alison Wang 
> ---
>  arch/arm/kernel/time.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> a66e37e..a9bc73c 100644
> --- a/arch/arm/kernel/time.c
> +++ b/arch/arm/kernel/time.c
> @@ -12,6 +12,7 @@
>   *  reading the RTC at bootup, etc...
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -121,5 +122,7 @@ void __init time_init(void)
>   of_clk_init(NULL);
>  #endif
>   clocksource_of_init();
> +
> + tick_setup_hrtimer_broadcast();
>   }
>  }
> --
> 2.1.0.27.g96db324

--
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] x86/cpu: Move sparsely used bit leafs into scattered features (was: Re: [PATCH 2/2] x86/cpufeature: Add CLZERO feature)

[Andy Lutomirski]

On Mon, Oct 26, 2015 at 2:01 PM, Borislav Petkov  wrote:
> On Mon, Oct 26, 2015 at 09:22:50PM +0100, Borislav Petkov wrote:
>> And btw, those Intel QoS single bit defines and the XSAVE stuff there
>> should move to that function too - that's a pure waste having them in
>> the cap_flags array. I'll fix that.
>
> I.e., something like that (I'm jetlagged and I can't sleep, bah :-\).
>
> So this one builds but no further guarantees. It looks straightforward
> though.
>
> Not-yet-signed-off-by: Borislav Petkov 
>
> ---
> diff --git a/arch/x86/include/asm/cpufeature.h 
> b/arch/x86/include/asm/cpufeature.h
> index 9727b3b48bd1..ea109b58a864 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -12,7 +12,7 @@
>  #include 
>  #endif
>
> -#define NCAPINTS   13  /* N 32-bit words worth of info */
> +#define NCAPINTS   10  /* N 32-bit words worth of info */
>  #define NBUGINTS   1   /* N 32-bit bug flags */
>
>  /*
> @@ -198,6 +198,15 @@
>  #define X86_FEATURE_HWP_EPP( 7*32+13) /* Intel HWP_EPP */
>  #define X86_FEATURE_HWP_PKG_REQ ( 7*32+14) /* Intel HWP_PKG_REQ */
>  #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
> +/* Extended state features, CPUID level 0x000d:1 (eax) */
> +#define X86_FEATURE_XSAVEOPT   (7*32+ 16) /* XSAVEOPT */
> +#define X86_FEATURE_XSAVEC (7*32+ 17) /* XSAVEC */
> +#define X86_FEATURE_XGETBV1(7*32+ 18) /* XGETBV with ECX = 1 */
> +#define X86_FEATURE_XSAVES (7*32+ 19) /* XSAVES/XRSTORS */

How few features in one leaf do we need before calling it scattered
makes sense?  These four might make sense to keep as is...

> +/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:0 (edx) */
> +#define X86_FEATURE_CQM_LLC(7*32+ 20) /* LLC QoS if 1 */
> +/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx) */
> +#define X86_FEATURE_CQM_OCCUP_LLC (7*32+ 21) /* LLC occupancy monitoring if 
> 1 */
>

...whereas this looks totally reasonable.

FWIW, we have a ton of thses things.  Would it make sense to convert
this to a text file giving features and their CPUID positions that
generates the defines and the code to enumerate them?

--Andy
--
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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Fri, Oct 23, 2015 at 03:27:02PM +0200, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 10:28:24AM +0800, Huang Rui wrote:
> > This patch adds a member in fam15h_power_data which specifies the
> > compute unit accumulated power. It adds do_read_registers_on_cu to do
> > all the read to all MSRs and run it on one of the online cores on each
> > compute unit with smp_call_function_many(). This behavior can decrease
> > IPI numbers.
> > 
> > Suggested-by: Borislav Petkov 
> > Signed-off-by: Huang Rui 
> > Cc: Guenter Roeck 
> > Cc: Peter Zijlstra 
> > Cc: Ingo Molnar 
> > ---
> >  drivers/hwmon/fam15h_power.c | 68 
> > +++-
> >  1 file changed, 67 insertions(+), 1 deletion(-)
> > 



> > +
> > +static int read_registers(struct fam15h_power_data *data)
> > +{
> > +   int this_cpu, ret;
> > +   int cu_num, cores_per_cu, cpu, cu;
> > +   cpumask_var_t mask;
> > +
> > +   cores_per_cu = amd_get_cores_per_cu();
> > +   cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +   WARN_ON_ONCE(cu_num > MAX_CUS);
> > +
> > +   ret = zalloc_cpumask_var(, GFP_KERNEL);
> > +   if (!ret)
> > +   return -ENOMEM;
> > +
> > +   this_cpu = get_cpu();
> 
> This should be get_online_cpus() and its counterpart below should be
> put_online_cpus().
> 

Preemption must be disabled when calling smp_call_function_many,
get_cpu would did that. Will get_online_cpus have the same behavior
like that?

> > +
> > +   /*
> > +* Choose the first online core of each compute unit, and then
> > +* read their MSR value of power and ptsc in one time of IPI,
> 
>   in a single IPI.
> 
> > +* because the MSR value of cpu core represent the compute
> 
> s/cpu/CPU/
> 
> do that in *all* your text.
> 
> > +* unit's. This behavior can decrease IPI numbers between the
> 
> unit's ?
> 
> What does that sentence even mean?
> 

That means "the value(cu_acc_power) of the compute unit", which does
not represent the value of one CPU core.

> > +* cores.
> > +*/
> > +   cpu = cpumask_first(cpu_online_mask);
> > +   cu = cpu / cores_per_cu;
> > +   while (cpu < boot_cpu_data.x86_max_cores) {
> > +   if (cu <= cpu / cores_per_cu) {
> > +   cu = cpu / cores_per_cu + 1;
> > +   cpumask_set_cpu(cpu, mask);
> > +   }
> > +   cpu = cpumask_next(cu * cores_per_cu - 1, cpu_online_mask);
> > +   }
> 
> This is hard to parse - I *think* you're setting a bit in mask for a
> core in each CU...
> 

Yes, that's right.

My codes' behavior is below:

Assumed cores_per_cu is 4 and cu_number is 6, and the online cpumask
is:

cu5  cu4  cu3  cu2  cu1  cu0
1000_1100_0110_1011__

After setting bits of the mask:

1000_0100_0010_0001__0001
on   on   on   on   off  on

> If so, I think you can simplify it by generating a tmp mask which
> contains the cores of CU0, i.e. something like that:
> 
>   11_00_00_...
> 
> and then do cpumask_and(res, ...) to find the online cores on that CU
> and then do cpumask_set_cpu(cpumask_any(res), mask) to select one CPU on
> that CU.
> 
> And then shift to the next CU:
> 
>   cpumask_shift_right(dst, src_mask, cores_per_cu);
> 
> I think this should be cleaner and less error prone, without the
> conditionals...
> 

OK, how about below codes:

---
for (i = 0; i <= cores_per_cu / BITS_PER_LONG; i++) {
offset = cores_per_cu % BITS_PER_LONG;
if (i == cores_per_cu / BITS_PER_LONG) {
cpumask_bits(src_mask)[i] = GENMASK(offset -1, 0);
break;
}
cpumask_bits(src_mask)[i] = GENMASK(BITS_PER_LONG - 1, 0);
}

for (i = 0; i < cu_num; i++) {
cpumask_shift_left(dst, src_mask, cores_per_cu * i);
cpumask_and(res, dst, cpu_online_mask);
cpumask_set_cpu(cpumask_any(res), mask);
}
---

Thanks,
Rui
--
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] perf, tools, stat: Implement --metric-only mode

[Andi Kleen]

Here's a v2 that fixes a problem in --per-core mode.

---

Add a new mode to only print metrics. Sometimes we don't care about
the raw values, just want the computed metrics. This allows more
compact printing, so with -I each sample is only a single line.
This also allows easier plotting and processing with other tools.

The main target is with using --topdown, but it also works with
-T and standard perf stat. A few metrics are not supported.

To avoiding having to hardcode all the metrics in the code it uses
a two pass approach: first compute dummy metrics and only
print the headers in the print_metric callback. Then use the callback
to print the actual values. There are some additional changes
in the stat printout code to handle all metrics being on a single line.

Example:

% perf stat -a -I 1000 --metric-only
 1.000604977 frontend cycles idle backend cycles idle  insn per 
cycle   stalled cycles per insn  branch-misses of all branches
 1.0006049770.76
 2.35%
 2.0009246800.72
 2.34%
 3.0011395920.76
 2.57%
 4.0013584520.73
 2.44%

The output is fairly wide, but that's a trade off for the concise format.

v2: Fix --per-socket/core extra prefix printing.
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-stat.txt |   4 +
 tools/perf/builtin-stat.c  | 201 +++--
 2 files changed, 196 insertions(+), 9 deletions(-)

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index 079b141..58296e7 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -132,6 +132,10 @@ Print count deltas every N milliseconds (minimum: 10ms)
 The overhead percentage could be high in some cases, for instance with small, 
sub 100ms intervals.  Use with caution.
example: 'perf stat -I 1000 -e cycles -a sleep 5'
 
+--metric-only::
+Only print computed metrics. Print them in a single line.
+Don't show any raw values. Not supported with -A or --per-thread.
+
 --per-socket::
 Aggregate counts per processor socket for system-wide mode measurements.  This
 is a useful mode to detect imbalance between sockets.  To enable this mode,
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 4042b97..6b3e89a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -117,6 +117,7 @@ static bool sync_run
= false;
 static unsigned intinitial_delay   = 0;
 static unsigned intunit_width  = 4; /* 
strlen("unit") */
 static boolforever = false;
+static boolmetric_only = false;
 static struct timespec ref_time;
 static struct cpu_map  *aggr_map;
 static int (*aggr_get_id)(struct cpu_map *m, int cpu);
@@ -572,6 +573,99 @@ static void print_metric_csv(void *ctx,
fprintf(out, "%s%s%s", vals, csv_sep, unit);
 }
 
+#define METRIC_ONLY_LEN 24
+
+/* Filter out some columns that don't work well in metrics only mode */
+
+static bool valid_only_metric(const char *unit)
+{
+   if (!unit)
+   return false;
+   if (strstr(unit, "/sec") ||
+   strstr(unit, "hz") ||
+   strstr(unit, "Hz") ||
+   strstr(unit, "CPUs utilized"))
+   return false;
+   return true;
+}
+
+static const char *fixunit(char *buf, struct perf_evsel *evsel,
+  const char *unit)
+{
+   if (!strncmp(unit, "of all", 6)) {
+   snprintf(buf, 1024, "%s %s", perf_evsel__name(evsel),
+unit);
+   return buf;
+   }
+   return unit;
+}
+
+static void print_metric_only(void *ctx, const char *color, const char *fmt,
+ const char *unit, double val)
+{
+   struct outstate *os = ctx;
+   FILE *out = os->fh;
+   int n;
+   char buf[1024];
+   unsigned mlen = METRIC_ONLY_LEN;
+
+   if (!valid_only_metric(unit))
+   return;
+   unit = fixunit(buf, os->evsel, unit);
+   if (color)
+   n = color_fprintf(out, color, fmt, val);
+   else
+   n = fprintf(out, fmt, val);
+   if (n > METRIC_ONLY_LEN)
+   n = METRIC_ONLY_LEN;
+   if (mlen < strlen(unit))
+   mlen = strlen(unit) + 1;
+   fprintf(out, "%*s", mlen - n, "");
+}
+
+static void print_metric_only_csv(void *ctx, const char *color __maybe_unused,
+ 

Re: [PATCH] get_maintainer: Don't fallback to git by default

[Theodore Ts'o]

What if we have a git_fallback "auto" mode which only falls back to
using git if there is no entry in the MAINTAINERS file?  That might
address the concern which Laura raised, without blocking this
change until the MAINTAINERS file is fully populated.

Cheers,

- Ted
--
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] ARM: multi_v7_defconfig: enable UniPhier I2C drivers

[Masahiro Yamada]

These two drivers were merged into the I2C sub-system by
commit dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
and commit 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C
driver").

Enable them from arch/arm/configs/multi_v7_defconfig.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index bfd74fe..90e2b68 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -308,6 +308,8 @@ CONFIG_I2C_SIRF=y
 CONFIG_I2C_ST=y
 CONFIG_I2C_SUN6I_P2WI=y
 CONFIG_I2C_TEGRA=y
+CONFIG_I2C_UNIPHIER=y
+CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_XILINX=y
 CONFIG_I2C_RCAR=y
 CONFIG_I2C_CROS_EC_TUNNEL=m
-- 
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 5/9] perf, tools, stat: Move noise/running printing into printout

[Andi Kleen]

On Mon, Oct 26, 2015 at 04:32:06PM +0100, Jiri Olsa wrote:
> On Fri, Oct 23, 2015 at 04:59:33PM -0700, Andi Kleen wrote:
> > From: Andi Kleen 
> > 
> > Move the running/noise printing into printout to avoid
> > duplicated code in the callers.
> > 
> > v2: Merged with other patches. Remove unnecessary hunk.
> > Readd hunk that ended in earlier patch.
> > Signed-off-by: Andi Kleen 
> 
> hit the same issue as in previous version described in here:
> 
> http://marc.info/?l=linux-kernel=144308533308176=2
> 
> on your perf/stat-metrics-9

Here's an updated patch and I pushed perf/stat-metrics-10

---

Move the running/noise printing into printout to avoid
duplicated code in the callers.

v2: Merged with other patches. Remove unnecessary hunk.
Readd hunk that ended in earlier patch.
v3: Fix noise/running output in CSV mode
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-stat.c | 50 ---
 1 file changed, 8 insertions(+), 42 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f78af2a..f995911 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -586,7 +586,7 @@ static void abs_printout(int id, int nr, struct perf_evsel 
*evsel, double avg)
 }
 
 static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix)
+char *prefix, u64 run, u64 ena, double noise)
 {
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -612,6 +612,9 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
);
+
+   print_noise(counter, noise);
+   print_running(run, ena);
 }
 
 static void print_aggr(char *prefix)
@@ -667,11 +670,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
-   printout(id, nr, counter, uval, prefix);
-   if (!csv_output)
-   print_noise(counter, 1.0);
-
-   print_running(run, ena);
+   printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -698,12 +697,7 @@ static void print_aggr_thread(struct perf_evsel *counter, 
char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(thread, 0, counter, uval, prefix);
-
-   if (!csv_output)
-   print_noise(counter, 1.0);
-
-   print_running(run, ena);
+   printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
 }
@@ -717,7 +711,6 @@ static void print_counter_aggr(struct perf_evsel *counter, 
char *prefix)
FILE *output = stat_config.output;
struct perf_stat_evsel *ps = counter->priv;
double avg = avg_stats(>res_stats[0]);
-   int scaled = counter->counts->scaled;
double uval;
double avg_enabled, avg_running;
 
@@ -727,32 +720,8 @@ static void print_counter_aggr(struct perf_evsel *counter, 
char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
 
-   if (scaled == -1 || !counter->supported) {
-   fprintf(output, "%*s%s",
-   csv_output ? 0 : 18,
-   counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
-   csv_sep);
-   fprintf(output, "%-*s%s",
-   csv_output ? 0 : unit_width,
-   counter->unit, csv_sep);
-   fprintf(output, "%*s",
-   csv_output ? 0 : -25,
-   perf_evsel__name(counter));
-
-   if (counter->cgrp)
-   fprintf(output, "%s%s", csv_sep, counter->cgrp->name);
-
-   print_running(avg_running, avg_enabled);
-   fputc('\n', output);
-   return;
-   }
-
uval = avg * counter->scale;
-   printout(-1, 0, counter, uval, prefix);
-
-   print_noise(counter, avg);
-
-   print_running(avg_running, avg_enabled);
+   printout(-1, 0, counter, uval, prefix, avg_running, avg_enabled, avg);
fprintf(output, "\n");
 }
 
@@ -801,10 +770,7 @@ static void print_counter(struct perf_evsel *counter, char 
*prefix)
}
 
uval = val * counter->scale;
-   printout(cpu, 0, counter, uval, prefix);
-   if (!csv_output)
-   print_noise(counter, 1.0);
-   print_running(run, ena);
+   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
 
fputc('\n', output);
}
-- 

[PATCH] mtd: blkdevs: fix potential deadlock + lockdep warnings

[Brian Norris]

Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.

The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.

 -> blktrans_open()
->  mutex_lock(>lock);
->  mutex_lock(_table_mutex);

 -> del_mtd_device()
->  mutex_lock(_table_mutex);
->  blktrans_notify_remove() -> del_mtd_blktrans_dev()
   ->  mutex_lock(>lock);

This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired >lock:

if (mutex_trylock(_table_mutex)) {
mutex_unlock(_table_mutex);
BUG();
}

So, reverse the ordering of acquisition of >lock and _table_mutex so
we always acquire mtd_table_mutex first.

Snippets of the lockdep output follow:

  # modprobe -r m25p80
  [   53.419251]
  [   53.420838] ==
  [   53.427300] [ INFO: possible circular locking dependency detected ]
  [   53.433865] 4.3.0-rc6 #96 Not tainted
  [   53.437686] ---
  [   53.444220] modprobe/372 is trying to acquire lock:
  [   53.449320]  (>lock){+.+...}, at: [] 
del_mtd_blktrans_dev+0x80/0xdc
  [   53.457271]
  [   53.457271] but task is already holding lock:
  [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
  [   53.471321]
  [   53.471321] which lock already depends on the new lock.
  [   53.471321]
  [   53.479856]
  [   53.479856] the existing dependency chain (in reverse order) is:
  [   53.487660]
  -> #1 (mtd_table_mutex){+.+.+.}:
  [   53.492331][] blktrans_open+0x34/0x1a4
  [   53.497879][] __blkdev_get+0xc4/0x3b0
  [   53.503364][] blkdev_get+0x108/0x320
  [   53.508743][] do_dentry_open+0x218/0x314
  [   53.514496][] path_openat+0x4c0/0xf9c
  [   53.519959][] do_filp_open+0x5c/0xc0
  [   53.525336][] do_sys_open+0xfc/0x1cc
  [   53.530716][] ret_fast_syscall+0x0/0x1c
  [   53.536375]
  -> #0 (>lock){+.+...}:
  [   53.540587][] mutex_lock_nested+0x38/0x3cc
  [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
  [   53.552606][] blktrans_notify_remove+0x7c/0x84
  [   53.558891][] del_mtd_device+0x74/0x100
  [   53.564544][] del_mtd_partitions+0x80/0xc8
  [   53.570451][] mtd_device_unregister+0x24/0x48
  [   53.576637][] spi_drv_remove+0x1c/0x34
  [   53.582207][] __device_release_driver+0x88/0x114
  [   53.588663][] device_release_driver+0x20/0x2c
  [   53.594843][] bus_remove_device+0xd8/0x108
  [   53.600748][] device_del+0x10c/0x210
  [   53.606127][] device_unregister+0xc/0x20
  [   53.611849][] __unregister+0x10/0x20
  [   53.617211][] device_for_each_child+0x50/0x7c
  [   53.623387][] spi_unregister_master+0x58/0x8c
  [   53.629578][] release_nodes+0x15c/0x1c8
  [   53.635223][] __device_release_driver+0x90/0x114
  [   53.641689][] driver_detach+0xb4/0xb8
  [   53.647147][] bus_remove_driver+0x4c/0xa0
  [   53.652970][] SyS_delete_module+0x11c/0x1e4
  [   53.658976][] ret_fast_syscall+0x0/0x1c
  [   53.664621]
  [   53.664621] other info that might help us debug this:
  [   53.664621]
  [   53.672979]  Possible unsafe locking scenario:
  [   53.672979]
  [   53.679169]CPU0CPU1
  [   53.683900]
  [   53.688633]   lock(mtd_table_mutex);
  [   53.692383]lock(>lock);
  [   53.698306]lock(mtd_table_mutex);
  [   53.704658]   lock(>lock);
  [   53.707946]
  [   53.707946]  *** DEADLOCK ***

Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing 
mtd->usecount")
Reported-by: Felipe Balbi 
Tested-by: Felipe Balbi 
Signed-off-by: Brian Norris 
Cc: 
---
Resending as a proper patch

Note: I tried to reproduce this lockdep warning myself but couldn't. But I saw
no problem under the new patch either.

 drivers/mtd/mtd_blkdevs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 44dc965a2f7c..e7a02ed9fba8 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -192,8 +192,8 @@ static int blktrans_open(struct block_device *bdev, fmode_t 
mode)
if (!dev)
 

[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

[Brian Norris]

It seems more logical to use a device node directly associated with the
MTD master device (i.e., mtd->dev.of_node field) rather than requiring
auxiliary partition parser information to be passed in by the driver in
a separate struct.

This patch supports the mtd->dev.of_node field, deprecates the parser
data 'of_node' field, and begins using the new convention for nand_base.
Other NAND driver conversions may now follow.

Additional side benefit to assigning mtd->dev.of_node rather than using
parser data: the driver core will automatically create a device -> node
symlink for us.

Signed-off-by: Brian Norris 
---
 drivers/mtd/nand/nand_base.c   |  3 +++
 drivers/mtd/ofpart.c   | 18 ++
 drivers/mtd/spi-nor/spi-nor.c  |  1 +
 include/linux/mtd/partitions.h |  4 +++-
 4 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index cc74142938b0..d2e7fee2ac37 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3990,6 +3990,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
int ret;
 
if (chip->flash_node) {
+   /* MTD can automatically handle DT partitions, etc. */
+   mtd->dev.of_node = chip->flash_node;
+
ret = nand_dt_init(mtd, chip, chip->flash_node);
if (ret)
return ret;
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index aa26c32e1bc2..a5dfd73cfc7d 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -35,10 +35,11 @@ static int parse_ofpart_partitions(struct mtd_info *master,
int nr_parts, i;
 
 
-   if (!data)
-   return 0;
-
-   node = data->of_node;
+   /*
+* of_node can be provided through auxiliary parser data or (preferred)
+* by assigning the master device
+*/
+   node = data && data->of_node ? data->of_node : master->dev.of_node;
if (!node)
return 0;
 
@@ -120,10 +121,11 @@ static int parse_ofoldpart_partitions(struct mtd_info 
*master,
} *part;
const char *names;
 
-   if (!data)
-   return 0;
-
-   dp = data->of_node;
+   /*
+* of_node can be provided through auxiliary parser data or (preferred)
+* by assigning the master device
+*/
+   dp = data && data->of_node ? data->of_node : master->dev.of_node;
if (!dp)
return 0;
 
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 49883905a434..8f9080c6db63 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1258,6 +1258,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
mtd->flags |= MTD_NO_ERASE;
 
mtd->dev.parent = dev;
+   mtd->dev.of_node = np;
nor->page_size = info->page_size;
mtd->writebufsize = nor->page_size;
 
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 6a35e6de5da1..e742f34b67eb 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -56,7 +56,9 @@ struct device_node;
 /**
  * struct mtd_part_parser_data - used to pass data to MTD partition parsers.
  * @origin: for RedBoot, start address of MTD device
- * @of_node: for OF parsers, device node containing partitioning information
+ * @of_node: for OF parsers, device node containing partitioning information.
+ *   This field is deprecated, as the device node should simply be
+ *   assigned to the master struct device.
  */
 struct mtd_part_parser_data {
unsigned long origin;
-- 
2.6.0.rc2.230.g3dd15c0

--
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] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds

[Ard Biesheuvel]

On 27 October 2015 at 06:02, Matt Fleming  wrote:
> On Fri, 23 Oct, at 10:37:46AM, Ard Biesheuvel wrote:
>>
>> After looking at the original (already merged) patch 11/11 again, I
>> realize this is still not right: the problem is that efi_memory_map's
>> phys_map member uses a void* type to hold a physical address, which
>> happens to be correct in the normal case even when phys_addr_t is
>> larger than void* (like on ARM with LPAE enabled) since the address it
>> holds is the address of an allocation performed by the firmware, which
>> only uses 1:1 addressable memory.
>>
>> However, overwriting memmap.phys_map with a value produced my
>> memblock_alloc() is problematic, since the allocation may be above 4
>> GB on 32-bit (L)PAE platforms. So the correct way to do this would be
>> to set the memblock limit to 4GB before memblock_alloc() on 32-bit
>> platforms, and restore it afterwards. This is a bit of a kludge,
>> though, and it would be more correct to change the type of
>> efi_memory_map::phys_map to phys_addr_t, although I don't know what
>> the potential fallout of that change is. Matt?
>
> I think that should be fine. The only potentially tricky situation we
> could encounter is where 32-bit x86 firmware uses PAE but the kernel
> is built without support.
>
> But that's not something I've ever seen enabled in the firmware and
> there's a bunch of assumptions in the kernel already that would break
> in that case.
>

Does UEFI even allow that? Even if it can describe memory over 4 GB,
it uses a flat mapping so allocations done by the stub (which
retrieves the memory map) should never reside at addresses over 4 GB.

-- 
Ard.
--
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: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

[Michael Ellerman]

On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> This patch fixes two problems to make value-returning atomics and
> {cmp}xchg fully ordered on PPC.

Hi Boqun,

Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.

Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?

cheers
--
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/5] mtd: spi-nor: drop unnecessary partition parser data

[Brian Norris]

Now that the SPI-NOR/MTD framework pass the 'flash_node' through to the
partition parsing code, we don't have to do it ourselves.

Also convert to mtd_device_register(), since we don't need the 2nd and
3rd parameters anymore.

Signed-off-by: Brian Norris 
---
 drivers/mtd/devices/m25p80.c  | 8 ++--
 drivers/mtd/spi-nor/fsl-quadspi.c | 4 +---
 drivers/mtd/spi-nor/nxp-spifi.c   | 4 +---
 3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 4b5d7a4655fd..d86fa1ae6d1f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -175,7 +175,6 @@ static int m25p80_erase(struct spi_nor *nor, loff_t offset)
  */
 static int m25p_probe(struct spi_device *spi)
 {
-   struct mtd_part_parser_data ppdata;
struct flash_platform_data  *data;
struct m25p *flash;
struct spi_nor *nor;
@@ -227,11 +226,8 @@ static int m25p_probe(struct spi_device *spi)
if (ret)
return ret;
 
-   ppdata.of_node = spi->dev.of_node;
-
-   return mtd_device_parse_register(>mtd, NULL, ,
-   data ? data->parts : NULL,
-   data ? data->nr_parts : 0);
+   return mtd_device_register(>mtd, data ? data->parts : NULL,
+  data ? data->nr_parts : 0);
 }
 
 
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 7b10ed413983..95991a2197e8 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -927,7 +927,6 @@ static void fsl_qspi_unprep(struct spi_nor *nor, enum 
spi_nor_ops ops)
 static int fsl_qspi_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
-   struct mtd_part_parser_data ppdata;
struct device *dev = >dev;
struct fsl_qspi *q;
struct resource *res;
@@ -1038,8 +1037,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
if (ret)
goto mutex_failed;
 
-   ppdata.of_node = np;
-   ret = mtd_device_parse_register(mtd, NULL, , NULL, 0);
+   ret = mtd_device_register(mtd, NULL, 0);
if (ret)
goto mutex_failed;
 
diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c
index 9e82098ae644..9414495a73cb 100644
--- a/drivers/mtd/spi-nor/nxp-spifi.c
+++ b/drivers/mtd/spi-nor/nxp-spifi.c
@@ -271,7 +271,6 @@ static void nxp_spifi_dummy_id_read(struct spi_nor *nor)
 static int nxp_spifi_setup_flash(struct nxp_spifi *spifi,
 struct device_node *np)
 {
-   struct mtd_part_parser_data ppdata;
enum read_mode flash_read;
u32 ctrl, property;
u16 mode = 0;
@@ -361,8 +360,7 @@ static int nxp_spifi_setup_flash(struct nxp_spifi *spifi,
return ret;
}
 
-   ppdata.of_node = np;
-   ret = mtd_device_parse_register(>nor.mtd, NULL, , NULL, 
0);
+   ret = mtd_device_register(>nor.mtd, NULL, 0);
if (ret) {
dev_err(spifi->dev, "mtd device parse failed\n");
return ret;
-- 
2.6.0.rc2.230.g3dd15c0

--
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/5] mtd: drop 'of_node' partition parser data

[Brian Norris]

This field is no longer used anywhere, as it is superseded by
mtd->dev.of_node.

Signed-off-by: Brian Norris 
---
 drivers/mtd/ofpart.c   | 14 --
 include/linux/mtd/partitions.h |  4 
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index a5dfd73cfc7d..4368badfc653 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -35,11 +35,8 @@ static int parse_ofpart_partitions(struct mtd_info *master,
int nr_parts, i;
 
 
-   /*
-* of_node can be provided through auxiliary parser data or (preferred)
-* by assigning the master device
-*/
-   node = data && data->of_node ? data->of_node : master->dev.of_node;
+   /* Pull of_node from the master device */
+   node = master->dev.of_node;
if (!node)
return 0;
 
@@ -121,11 +118,8 @@ static int parse_ofoldpart_partitions(struct mtd_info 
*master,
} *part;
const char *names;
 
-   /*
-* of_node can be provided through auxiliary parser data or (preferred)
-* by assigning the master device
-*/
-   dp = data && data->of_node ? data->of_node : master->dev.of_node;
+   /* Pull of_node from the master device */
+   dp = master->dev.of_node;
if (!dp)
return 0;
 
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index e742f34b67eb..773975a3c9e6 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -56,13 +56,9 @@ struct device_node;
 /**
  * struct mtd_part_parser_data - used to pass data to MTD partition parsers.
  * @origin: for RedBoot, start address of MTD device
- * @of_node: for OF parsers, device node containing partitioning information.
- *   This field is deprecated, as the device node should simply be
- *   assigned to the master struct device.
  */
 struct mtd_part_parser_data {
unsigned long origin;
-   struct device_node *of_node;
 };
 
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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/5] mtd: drop unnecessary partition parser data

[Brian Norris]

We should assign the MTD dev.of_node instead of the parser data field.
This gets us the equivalent partition parser behavior with fewer special
fields and parameter passing.

Also convert several of these to mtd_device_register(), since we don't
need the 2nd and 3rd parameters anymore.

Signed-off-by: Brian Norris 
---
 drivers/mtd/devices/mtd_dataflash.c | 5 ++---
 drivers/mtd/devices/spear_smi.c | 6 ++
 drivers/mtd/devices/st_spi_fsm.c| 5 ++---
 drivers/mtd/maps/lantiq-flash.c | 5 ++---
 drivers/mtd/maps/physmap_of.c   | 5 ++---
 drivers/mtd/onenand/omap2.c | 8 +++-
 6 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 39666d552682..0de40f5a7509 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -624,7 +624,6 @@ static int add_dataflash_otp(struct spi_device *spi, char 
*name, int nr_pages,
 {
struct dataflash*priv;
struct mtd_info *device;
-   struct mtd_part_parser_data ppdata;
struct flash_platform_data  *pdata = dev_get_platdata(>dev);
char*otp_tag = "";
int err = 0;
@@ -656,6 +655,7 @@ static int add_dataflash_otp(struct spi_device *spi, char 
*name, int nr_pages,
device->priv = priv;
 
device->dev.parent = >dev;
+   device->dev.of_node = spi->dev.of_node;
 
if (revision >= 'c')
otp_tag = otp_setup(device, revision);
@@ -665,8 +665,7 @@ static int add_dataflash_otp(struct spi_device *spi, char 
*name, int nr_pages,
pagesize, otp_tag);
spi_set_drvdata(spi, priv);
 
-   ppdata.of_node = spi->dev.of_node;
-   err = mtd_device_parse_register(device, NULL, ,
+   err = mtd_device_register(device,
pdata ? pdata->parts : NULL,
pdata ? pdata->nr_parts : 0);
 
diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c
index 64c7458344d4..8c41cc82d860 100644
--- a/drivers/mtd/devices/spear_smi.c
+++ b/drivers/mtd/devices/spear_smi.c
@@ -810,7 +810,6 @@ static int spear_smi_setup_banks(struct platform_device 
*pdev,
 u32 bank, struct device_node *np)
 {
struct spear_smi *dev = platform_get_drvdata(pdev);
-   struct mtd_part_parser_data ppdata = {};
struct spear_smi_flash_info *flash_info;
struct spear_smi_plat_data *pdata;
struct spear_snor_flash *flash;
@@ -855,6 +854,7 @@ static int spear_smi_setup_banks(struct platform_device 
*pdev,
flash->mtd.name = flash_devices[flash_index].name;
 
flash->mtd.dev.parent = >dev;
+   flash->mtd.dev.of_node = np;
flash->mtd.type = MTD_NORFLASH;
flash->mtd.writesize = 1;
flash->mtd.flags = MTD_CAP_NORFLASH;
@@ -881,10 +881,8 @@ static int spear_smi_setup_banks(struct platform_device 
*pdev,
count = flash_info->nr_partitions;
}
 #endif
-   ppdata.of_node = np;
 
-   ret = mtd_device_parse_register(>mtd, NULL, , parts,
-   count);
+   ret = mtd_device_register(>mtd, parts, count);
if (ret) {
dev_err(>pdev->dev, "Err MTD partition=%d\n", ret);
return ret;
diff --git a/drivers/mtd/devices/st_spi_fsm.c b/drivers/mtd/devices/st_spi_fsm.c
index 3060025c8af4..16cd44f728c1 100644
--- a/drivers/mtd/devices/st_spi_fsm.c
+++ b/drivers/mtd/devices/st_spi_fsm.c
@@ -2025,7 +2025,6 @@ boot_device_fail:
 static int stfsm_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
-   struct mtd_part_parser_data ppdata;
struct flash_info *info;
struct resource *res;
struct stfsm *fsm;
@@ -2035,7 +2034,6 @@ static int stfsm_probe(struct platform_device *pdev)
dev_err(>dev, "No DT found\n");
return -EINVAL;
}
-   ppdata.of_node = np;
 
fsm = devm_kzalloc(>dev, sizeof(*fsm), GFP_KERNEL);
if (!fsm)
@@ -2106,6 +2104,7 @@ static int stfsm_probe(struct platform_device *pdev)
 
fsm->mtd.name   = info->name;
fsm->mtd.dev.parent = >dev;
+   fsm->mtd.dev.of_node= np;
fsm->mtd.type   = MTD_NORFLASH;
fsm->mtd.writesize  = 4;
fsm->mtd.writebufsize   = fsm->mtd.writesize;
@@ -2124,7 +2123,7 @@ static int stfsm_probe(struct platform_device *pdev)
(long long)fsm->mtd.size, (long long)(fsm->mtd.size >> 20),
fsm->mtd.erasesize, (fsm->mtd.erasesize >> 10));
 
-   return mtd_device_parse_register(>mtd, NULL, , NULL, 0);
+   return mtd_device_register(>mtd, NULL, 0);
 }
 
 static int stfsm_remove(struct platform_device *pdev)
diff --git a/drivers/mtd/maps/lantiq-flash.c b/drivers/mtd/maps/lantiq-flash.c

[PATCH 0/5] mtd: migrate 'of_node' handling to core, not in mtd_part_parser_data

[Brian Norris]

Hi,

I noticed that, for MTD drivers that want to support DT partition parsing
(essentially all recent ones), it's a bit awkward to set the tell MTD which DT
node to use. I also noticed that this info is duplicated in a few places;
namely, some sub-subsystems (like SPI NOR and NAND) need their own field to
track the DT node, so let's have the propagate the 'MTD' DT node down for us.

Besides simplifying the boilerplate throughout MTD, this series also has the
side effect of producing 'of_node' symlinks in sysfs. e.g.:

  # ls -al /sys/class/mtd/mtd0/of_node 
  lrwxrwxrwx 1 root root 0 Oct 26 19:17 /sys/class/mtd/mtd0/of_node -> 
../../../../firmware/devicetree/base/spi@ff13/flash@0

For NAND, this potentially has some other bigger initial side effects, since
nand_dt_init() handles a bit more automagically for drivers that defined their
->flash_node. But these drivers should probably convert anyway. So, please test
your favorite driver!

Thanks,
Brian

Brian Norris (5):
  mtd: ofpart: grab device tree node directly from master device node
  mtd: nand: drop unnecessary partition parser data
  mtd: spi-nor: drop unnecessary partition parser data
  mtd: drop unnecessary partition parser data
  mtd: drop 'of_node' partition parser data

 drivers/mtd/devices/m25p80.c  |  8 ++--
 drivers/mtd/devices/mtd_dataflash.c   |  5 ++---
 drivers/mtd/devices/spear_smi.c   |  6 ++
 drivers/mtd/devices/st_spi_fsm.c  |  5 ++---
 drivers/mtd/maps/lantiq-flash.c   |  5 ++---
 drivers/mtd/maps/physmap_of.c |  5 ++---
 drivers/mtd/nand/atmel_nand.c |  7 +++
 drivers/mtd/nand/brcmnand/brcmnand.c  |  3 +--
 drivers/mtd/nand/davinci_nand.c   | 10 +++---
 drivers/mtd/nand/fsl_elbc_nand.c  |  5 ++---
 drivers/mtd/nand/fsl_ifc_nand.c   |  5 ++---
 drivers/mtd/nand/fsl_upm.c|  5 ++---
 drivers/mtd/nand/fsmc_nand.c  |  7 +++
 drivers/mtd/nand/gpio.c   |  8 +++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c|  5 ++---
 drivers/mtd/nand/hisi504_nand.c   |  5 ++---
 drivers/mtd/nand/lpc32xx_mlc.c|  7 +++
 drivers/mtd/nand/lpc32xx_slc.c|  7 +++
 drivers/mtd/nand/mpc5121_nfc.c|  5 ++---
 drivers/mtd/nand/mxc_nand.c   |  5 ++---
 drivers/mtd/nand/nand_base.c  |  3 +++
 drivers/mtd/nand/ndfc.c   |  5 ++---
 drivers/mtd/nand/omap2.c  |  6 ++
 drivers/mtd/nand/orion_nand.c |  6 ++
 drivers/mtd/nand/plat_nand.c  |  5 ++---
 drivers/mtd/nand/pxa3xx_nand.c| 10 +-
 drivers/mtd/nand/sh_flctl.c   |  6 ++
 drivers/mtd/nand/socrates_nand.c  |  5 ++---
 drivers/mtd/nand/sunxi_nand.c |  4 +---
 drivers/mtd/nand/vf610_nfc.c  |  6 +-
 drivers/mtd/ofpart.c  | 12 
 drivers/mtd/onenand/omap2.c   |  8 +++-
 drivers/mtd/spi-nor/fsl-quadspi.c |  4 +---
 drivers/mtd/spi-nor/nxp-spifi.c   |  4 +---
 drivers/mtd/spi-nor/spi-nor.c |  1 +
 drivers/staging/mt29f_spinand/mt29f_spinand.c |  5 ++---
 include/linux/mtd/partitions.h|  2 --
 37 files changed, 79 insertions(+), 131 deletions(-)

-- 
2.6.0.rc2.230.g3dd15c0

--
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/5] mtd: nand: drop unnecessary partition parser data

[Brian Norris]

All of these drivers set up a parser data struct just to communicate DT
partition data. This field has been deprecated and is instead supported
by telling nand_scan_ident() about the 'flash_node'.

This patch:
 * sets chip->flash_node for those drivers that didn't already (but used
   OF partitioning)
 * drops the parser data
 * switches to the simpler mtd_device_register() where possible, now
   that we've eliminated one of the auxiliary parameters

Now that we've assigned chip->flash_node for these drivers, we can
probably rely on nand_dt_init() to do more of the DT parsing for us, but
for now, I don't want to fiddle with each of these drivers. The parsing
is done in duplicate for now on some drivers. I don't think this should
break things. (Famous last words.)

Signed-off-by: Brian Norris 
---
 drivers/mtd/nand/atmel_nand.c |  7 +++
 drivers/mtd/nand/brcmnand/brcmnand.c  |  3 +--
 drivers/mtd/nand/davinci_nand.c   | 10 +++---
 drivers/mtd/nand/fsl_elbc_nand.c  |  5 ++---
 drivers/mtd/nand/fsl_ifc_nand.c   |  5 ++---
 drivers/mtd/nand/fsl_upm.c|  5 ++---
 drivers/mtd/nand/fsmc_nand.c  |  7 +++
 drivers/mtd/nand/gpio.c   |  8 +++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c|  5 ++---
 drivers/mtd/nand/hisi504_nand.c   |  5 ++---
 drivers/mtd/nand/lpc32xx_mlc.c|  7 +++
 drivers/mtd/nand/lpc32xx_slc.c|  7 +++
 drivers/mtd/nand/mpc5121_nfc.c|  5 ++---
 drivers/mtd/nand/mxc_nand.c   |  5 ++---
 drivers/mtd/nand/ndfc.c   |  5 ++---
 drivers/mtd/nand/omap2.c  |  6 ++
 drivers/mtd/nand/orion_nand.c |  6 ++
 drivers/mtd/nand/plat_nand.c  |  5 ++---
 drivers/mtd/nand/pxa3xx_nand.c| 10 +-
 drivers/mtd/nand/sh_flctl.c   |  6 ++
 drivers/mtd/nand/socrates_nand.c  |  5 ++---
 drivers/mtd/nand/sunxi_nand.c |  4 +---
 drivers/mtd/nand/vf610_nfc.c  |  6 +-
 drivers/staging/mt29f_spinand/mt29f_spinand.c |  5 ++---
 24 files changed, 54 insertions(+), 88 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 583cdd9bb971..dd157b0d8041 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2093,7 +2093,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
struct mtd_info *mtd;
struct nand_chip *nand_chip;
struct resource *mem;
-   struct mtd_part_parser_data ppdata = {};
int res, irq;
 
/* Allocate memory for the device structure (and zero it) */
@@ -2117,6 +2116,7 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip = >nand_chip;
host->dev = >dev;
if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+   mtd->dev.of_node = pdev->dev.of_node;
/* Only when CONFIG_OF is enabled of_node can be parsed */
res = atmel_of_init_port(host, pdev->dev.of_node);
if (res)
@@ -2259,9 +2259,8 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
 
mtd->name = "atmel_nand";
-   ppdata.of_node = pdev->dev.of_node;
-   res = mtd_device_parse_register(mtd, NULL, ,
-   host->board.parts, host->board.num_parts);
+   res = mtd_device_register(mtd, host->board.parts,
+ host->board.num_parts);
if (!res)
return res;
 
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 7c1c306650a4..961a9ee4369c 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1889,7 +1889,6 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
-   struct mtd_part_parser_data ppdata = { .of_node = dn };
 
ret = of_property_read_u32(dn, "reg", >cs);
if (ret) {
@@ -1959,7 +1958,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
if (nand_scan_tail(mtd))
return -ENXIO;
 
-   return mtd_device_parse_register(mtd, NULL, , NULL, 0);
+   return mtd_device_register(mtd, NULL, 0);
 }
 
 static void brcmnand_save_restore_cs_config(struct brcmnand_host *host,
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index c72313d66cf6..a8448d73f56c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -684,6 +684,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
 
info->mtd.priv  = >chip;
info->mtd.dev.parent= >dev;
+   info->mtd.dev.of_node   = pdev->dev.of_node;
 
info->chip.IO_ADDR_R= vaddr;
info->chip.IO_ADDR_W= vaddr;
@@ 

Re: [PATCH 20/31] perf tools: Allow BPF program attach to uprobe events

[Wangnan (F)]

On 2015/10/14 20:41, Wang Nan wrote:

This patch appends new syntax to BPF object section name to support
probing at uprobe event. Now we can use BPF program like this:

  SEC(
  "target=/lib64/libc.so.6\n"
  "libcwrite=__write"
  )
  int libcwrite(void *ctx)
  {
  return 1;
  }

Where, in section name of a program, before the main config string,
we can use 'key=value' style options. Now the only option key "target"
is for uprobe probing.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Brendan Gregg 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Kaixu Xia 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Zefan Li 
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo 
Link: http://lkml.kernel.org/n/ebpf-6yw9eg0ej3l4jnqhinngk...@git.kernel.org
---
  tools/perf/util/bpf-loader.c | 86 
  1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index af549ea..73ff9a9 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -111,6 +111,84 @@ bpf_prog_priv__clear(struct bpf_program *prog 
__maybe_unused,
  }
  
  static int

+do_config(const char *key, const char *value,
+ struct perf_probe_event *pev)
+{
+   pr_debug("config bpf program: %s=%s\n", key, value);
+   if (strcmp(key, "target") == 0) {
+   pev->uprobes = true;
+   pev->target = strdup(value);
+   return 0;
+   }
+
+   pr_warning("BPF: WARNING: invalid config option in object: %s=%s\n",
+  key, value);
+   pr_warning("\tHint: Currently only valid option is 'target='\n");
+   return 0;
+}



This part is very easy to be extended to support probing at modules.
I'd like to change "target" to "exec" to make it unify with perf probe,
then add another patch to support module probing in next pull request.

Thank you.

--
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] scsi_sysfs: Fix queue_ramp_up_period return code

[Bart Van Assche]

On 10/26/15 07:54, Peter Oberparleiter wrote:

Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
returns the value of that number instead of the number of bytes written.
This behavior can confuse programs expecting POSIX write() semantics.
Fix this by returning the number of bytes written instead.

Signed-off-by: Peter Oberparleiter 
---
  drivers/scsi/scsi_sysfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index b89..6b0f292 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -898,7 +898,7 @@ sdev_store_queue_ramp_up_period(struct device *dev,
return -EINVAL;

sdev->queue_ramp_up_period = msecs_to_jiffies(period);
-   return period;
+   return count;
  }

  static DEVICE_ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR,


Hello Peter,

Good catch. But please CC the people who introduced this code and also 
"stable" (see also commit 4a84067dbfce436b81779e585bf712b02ceee552).


Thanks,

Bart.
--
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/2] pinctrl: uniphier: guard uniphier directory with CONFIG_PINCTRL_UNIPHIER

[Masahiro Yamada]

CONFIG_PINCTRL_UNIPHIER is more suitable than CONFIG_ARCH_UNIPHIER
to guard the drivers/pinctrl/uniphier directory.

The current CONFIG_PINCTRL_UNIPHIER_CORE is a bit long
(it would break the indentation in drivers/pinctrl/Makefile),
so rename it into CONFIG_PINCTRL_UNIPHIER.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/Makefile  |  2 +-
 drivers/pinctrl/uniphier/Kconfig  | 14 +++---
 drivers/pinctrl/uniphier/Makefile |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index cad077c..367af9b 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -50,6 +50,6 @@ obj-$(CONFIG_PINCTRL_SAMSUNG) += samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)   += sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)   += spear/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
-obj-$(CONFIG_ARCH_UNIPHIER)+= uniphier/
+obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_VT8500)  += vt8500/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index b1d2f941..7ca72bc 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -1,6 +1,6 @@
 if ARCH_UNIPHIER
 
-config PINCTRL_UNIPHIER_CORE
+config PINCTRL_UNIPHIER
bool
select PINMUX
select GENERIC_PINCONF
@@ -8,31 +8,31 @@ config PINCTRL_UNIPHIER_CORE
 config PINCTRL_UNIPHIER_PH1_LD4
tristate "UniPhier PH1-LD4 SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_PH1_PRO4
tristate "UniPhier PH1-Pro4 SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_PH1_SLD8
tristate "UniPhier PH1-sLD8 SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_PH1_PRO5
tristate "UniPhier PH1-Pro5 SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_PROXSTREAM2
tristate "UniPhier ProXstream2 SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_PH1_LD6B
tristate "UniPhier PH1-LD6b SoC pinctrl driver"
default y
-   select PINCTRL_UNIPHIER_CORE
+   select PINCTRL_UNIPHIER
 
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index e215b10..e7ce967 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_PINCTRL_UNIPHIER_CORE)+= pinctrl-uniphier-core.o
+obj-y  += pinctrl-uniphier-core.o
 
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_LD4) += pinctrl-ph1-ld4.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PH1_PRO4)+= pinctrl-ph1-pro4.o
-- 
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/

[PATCH 1/2] pinctrl: uniphier: enable UniPhier SoCs pinctrl drivers by default

[Masahiro Yamada]

Add "default y" to the Kconfig rather than adding entries into
arch/arm/configs/multi_v7_defconfig.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index eab23ef..b1d2f941 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -7,26 +7,32 @@ config PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PH1_LD4
tristate "UniPhier PH1-LD4 SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PH1_PRO4
tristate "UniPhier PH1-Pro4 SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PH1_SLD8
tristate "UniPhier PH1-sLD8 SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PH1_PRO5
tristate "UniPhier PH1-Pro5 SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PROXSTREAM2
tristate "UniPhier ProXstream2 SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 config PINCTRL_UNIPHIER_PH1_LD6B
tristate "UniPhier PH1-LD6b SoC pinctrl driver"
+   default y
select PINCTRL_UNIPHIER_CORE
 
 endif
-- 
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 5/5] staging: fsl-mc: Management Complex restool driver

[Stuart Yoder]

> -Original Message-
> From: Lijun Pan [mailto:lijun@freescale.com]
> Sent: Sunday, October 25, 2015 5:41 PM
> To: gre...@linuxfoundation.org; a...@arndb.de; de...@driverdev.osuosl.org; 
> linux-kernel@vger.kernel.org
> Cc: Yoder Stuart-B08248; katz Itai-RM05202; Rivera Jose-B46482; Li 
> Yang-Leo-R58472; Wood Scott-B07421;
> ag...@suse.de; Hamciuc Bogdan-BHAMCIU1; Marginean Alexandru-R89243; Sharma 
> Bhupesh-B45370; Erez Nir-RM30794;
> Schmitt Richard-B43082; dan.carpen...@oracle.com; Pan Lijun-B44306
> Subject: [PATCH 5/5] staging: fsl-mc: Management Complex restool driver
> 
> The kernel support for the restool (a user space resource management
> tool) is a driver for the /dev/dprc.N device file.
> Its purpose is to provide an ioctl interface,
> which the restool uses to interact with the MC bus driver

Name of the user space tool should be updated to be current:  
s/restool/ls-restool/

> and with the MC firmware.
> We allocate a dpmcp at driver initialization,
> and keep that dpmcp until driver exit.
> We use that dpmcp by default.
> If that dpmcp is in use, we create another portal at run time
> and destroy the newly created portal after use.
> The ioctl RESTOOL_SEND_MC_COMMAND sends user space command to fsl-mc
> bus and utilizes the fsl-mc bus to communicate with MC firmware.
> The ioctl RESTOOL_DPRC_SYNC request the mc-bus launch
> objects scan under root dprc.
> In order to support multiple root dprc, we utilize the bus notify
> mechanism to scan fsl_mc_bus_type for the newly added root dprc.
> After discovering the root dprc, it creates a miscdevice
> /dev/dprc.N to associate with this root dprc.
> 
> Signed-off-by: Lijun Pan 
> ---
>  drivers/staging/fsl-mc/bus/Kconfig  |   7 +-
>  drivers/staging/fsl-mc/bus/Makefile |   3 +
>  drivers/staging/fsl-mc/bus/mc-ioctl.h   |  24 ++
>  drivers/staging/fsl-mc/bus/mc-restool.c | 488 
> 
>  4 files changed, 521 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-ioctl.h
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-restool.c
> 
> diff --git a/drivers/staging/fsl-mc/bus/Kconfig 
> b/drivers/staging/fsl-mc/bus/Kconfig
> index 0d779d9..39c6ef9 100644
> --- a/drivers/staging/fsl-mc/bus/Kconfig
> +++ b/drivers/staging/fsl-mc/bus/Kconfig
> @@ -21,4 +21,9 @@ config FSL_MC_BUS
> Only enable this option when building the kernel for
> Freescale QorQIQ LS2 SoCs.
> 
> -
> +config FSL_MC_RESTOOL
> +tristate "Freescale Management Complex (MC) restool driver"

s/restool/ls-restool/

Thanks,
Stuart
--
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 2/7] dmaengine: mxs: APBH DMA supports deep sleep mode

[Vinod Koul]

On Thu, Oct 22, 2015 at 02:54:31PM -0500, Han Xu wrote:
> +static int mxs_dma_pm_resume(struct device *dev)
> +{
> + struct mxs_dma_engine *mxs_dma = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = mxs_dma_init(mxs_dma);
> + if (ret)
> + return ret;
> + return 0;
> +}

Did you compile this without runtime PM defined, it will give out a warning
of unused symbol which cna be fixed by definig thru under runtime pm config

-- 
~Vinod
--
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] mm: mark stable page dirty in KSM

[Hugh Dickins]

On Mon, 19 Oct 2015, Minchan Kim wrote:

> Stable page could be shared by several processes and last process
> could own the page among them after CoW or zapping for every process
> except last process happens. Then, page table entry of the page
> in last process can have no dirty bit and PG_dirty flag in page->flags.
> In this case, MADV_FREE could discard the page wrongly.
> For preventing it, we mark stable page dirty.

I agree with the change, but found that comment (repeated in the source)
rather hard to follow.  And it doesn't really do justice to the changes
you have made.

This is not now a MADV_FREE thing, it's more general than that, even
if MADV_FREE is the only thing that takes advantage of it.  I like
very much that you've made page reclaim sane, freeing non-dirty
anonymous pages instead of swapping them out, without having to
think of whether it's for MADV_FREE or not.

Would you mind if we replace your patch by a re-commented version?

[PATCH] mm: mark stable page dirty in KSM

The MADV_FREE patchset changes page reclaim to simply free a clean
anonymous page with no dirty ptes, instead of swapping it out; but
KSM uses clean write-protected ptes to reference the stable ksm page.
So be sure to mark that page dirty, so it's never mistakenly discarded.

Signed-off-by: Minchan Kim 
Signed-off-by: Hugh Dickins 
---

 mm/ksm.c |6 ++
 1 file changed, 6 insertions(+)

diff -puN mm/ksm.c~mm-mark-stable-page-dirty-in-ksm mm/ksm.c
--- a/mm/ksm.c~mm-mark-stable-page-dirty-in-ksm
+++ a/mm/ksm.c
@@ -1050,6 +1050,12 @@ static int try_to_merge_one_page(struct
 */
set_page_stable_node(page, NULL);
mark_page_accessed(page);
+   /*
+* Page reclaim just frees a clean page with no dirty
+* ptes: make sure that the ksm page would be swapped.
+*/
+   if (!PageDirty(page))
+   SetPageDirty(page);
err = 0;
} else if (pages_identical(page, kpage))
err = replace_page(vma, page, kpage, orig_pte);
--
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: [RESEND PATCH] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Peter Chen]

On Mon, Oct 26, 2015 at 06:23:25PM -0500, Nathan Sullivan wrote:
> The USB gadget support currently depends on power management

Why you said gadget? The thing you change is for OTG.

> (CONFIG_PM) being enabled, but does not actually need it enabled.
> Remove this dependency.
> 
> Tested on Bay Trail hardware with dwc3 USB.
> 
> Signed-off-by: Nathan Sullivan 
> ---
>  drivers/usb/core/Kconfig |1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index a99c89e..9c5cdf3 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
>  
>  config USB_OTG
>   bool "OTG support"
> - depends on PM
>   default n
>   help
> The most notable feature of USB OTG is support for a
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen
--
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/2] powerpc/512x: add LocalPlus Bus FIFO device driver

[Vinod Koul]

On Thu, Oct 22, 2015 at 01:15:03AM +0300, Alexander Popov wrote:
> On 12.10.2015 00:08, Alexander Popov wrote:
> > This driver for Freescale MPC512x LocalPlus Bus FIFO (called SCLPC
> > in the Reference Manual) allows Direct Memory Access transfers
> > between RAM and peripheral devices on LocalPlus Bus.
> 
> > Changes in v4:
> >  - the race condition is fixed;
> >  - plenty of style fixes are made;
> >  - devm_* functions and EPROBE_DEFER are used in probe().
> 
> Hello,
> 
> I've done my best to fix the issues pointed by Timur Tabi and Vinod Koul.
> Could I have a feedback please?

I dont see to have v4 in my list :( Can you please repost

-- 
~Vinod
--
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 1/3] PCI: iproc: generate proper configuration access cycles

[Jisheng Zhang]

On Mon, 26 Oct 2015 10:18:14 -0700
Ray Jui  wrote:

> Hi Jisheng,
> 
> On 10/26/2015 4:02 AM, Jisheng Zhang wrote:
> > Inspired by Russell King's patch[1], I found current iproc also has the
> > same issue of "reading 32-bits from the command register, modifying the
> > command register, and then writing it back has the effect of clearing
> > any status bits that were indicating at that time" as pointed out by
> > Russell. This patch fix this issue by using the pci_generic_config_write.
> >
> > [1]http://www.spinics.net/lists/linux-pci/msg44869.html
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   drivers/pci/host/pcie-iproc.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> > index fe2efb1..0c423f2 100644
> > --- a/drivers/pci/host/pcie-iproc.c
> > +++ b/drivers/pci/host/pcie-iproc.c
> > @@ -111,7 +111,7 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
> > pci_bus *bus,
> >   static struct pci_ops iproc_pcie_ops = {
> > .map_bus = iproc_pcie_map_cfg_bus,
> > .read = pci_generic_config_read32,
> > -   .write = pci_generic_config_write32,
> > +   .write = pci_generic_config_write,
> >   };
> >
> >   static void iproc_pcie_reset(struct iproc_pcie *pcie)
> >  
> 
> I have already confirmed with the ASIC team that the current iProc PCIe 
> controller requires 32-bit aligned access into the configuration space 
> due to the way how it was integrated into various iProc SoCs including 
> NSP, Cygnus, and NS2.
> 
> This change will prevent the driver from working properly.
> 
> I've informed our ASIC team about this issue and all future iProc based 
> SoCs should be able to support 8-bit, 16-bit access and therefore 
> pci_generic_config_write/read can be used for those SoCs.
> 
> Thanks,
> 
> Ray

Got it. 

Thanks for the information,
Jisheng
--
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/7] clocksource: add missing notrace attribute

[Jisheng Zhang]

Dear Daniel,

On Mon, 26 Oct 2015 18:50:10 +0100
Daniel Lezcano  wrote:

> On 10/20/2015 10:02 AM, Jisheng Zhang wrote:
> > Some clocksource drivers sched_clock implementation either miss notrace
> > attribute or call wasn't notrace function. This series try to fix them.
> >
> > Jisheng Zhang (7):
> >clocksource: arm_global_timer: fix ftrace
> >clocksource: samsung_pwm_timer: fix ftrace
> >clocksource: pistachio: fix ftrace
> >clocksource: prima2: fix ftrace
> >clocksource: vf_pit_timer: don't trace pit_read_sched_clock()
> >clocksource: digicolor: don't trace digicolor_timer_sched_read()
> >clocksource: fsl_ftm_timer: don't trace ftm_read_sched_clock
> >
> >   drivers/clocksource/arm_global_timer.c  | 9 +++--
> >   drivers/clocksource/fsl_ftm_timer.c | 2 +-
> >   drivers/clocksource/samsung_pwm_timer.c | 2 +-
> >   drivers/clocksource/time-pistachio.c| 3 ++-
> >   drivers/clocksource/timer-digicolor.c   | 2 +-
> >   drivers/clocksource/timer-prima2.c  | 2 +-
> >   drivers/clocksource/vf_pit_timer.c  | 2 +-
> >   7 files changed, 14 insertions(+), 8 deletions(-)  
> 
> Hi Jisheng,
> 
> I will apply this series as 4.3 fixes.
> 
> In the future, could you fix the subject by:
> 
> clocksource/drivers/: [first letter uppercase]...;

Got it. Will take care in the future.

Thanks a lot for kind reminding,
Jisheng
--
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.16.y-ckt 072/104] drm/radeon: Restore LCD backlight level on resume (>= R5xx)

[Michel Dänzer]

On 26.10.2015 22:42, Luis Henriques wrote:
> 3.16.7-ckt19 -stable review patch.  If anyone has any objections, please let 
> me know.
> 
> --
> 
> From: =TF-8?q?Michel Dänzer?= 
> 
> commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream.
> 
> Instead of only enabling the backlight (which seems to set it to max
> brightness), just re-set the current backlight level, which also takes
> care of enabling the backlight if necessary.
> 
> Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop,
> the radeon_atom_encoder_dpms_avivo part is only compile tested.
> 
> Signed-off-by: Michel Dänzer 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Luis Henriques 

We're currently investigating a regression which was bisected to this
change. Please hold off on backporting this change until we have a
solution for that.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
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 0/8] Add support for Exynos SROM Controller driver

[Kukjin Kim]

On 10/26/15 15:45, Pavel Fedin wrote:
>  Hello!
> 
Hi,

>> Applied, this whole series.
> 
>  Where can i find the recent code to base my series on? I looked at 
> linux-samsung.git but was unable to find it there.
> 
You may need to fetch again?
Anyway the branch is v4.4-next/driver-samsung or tags/samsung-driver...
Or just for-next should be fine I think.

See below:
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=v4.4-next/driver-samsung

Thanks,
Kukjin
--
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] regulator, dt: add dt support for tps6502x regulator

[Mark Brown]

On Mon, Oct 26, 2015 at 12:25:17PM +0100, Heiko Schocher wrote:
> add DT support for the tps6502x regulators.

Please use subject lines matching the style for the subsystem.

> + regulators = of_get_child_by_name(np, "regulators");
> + if (!regulators) {
> + dev_err(dev, "regulator node not found\n");
> + return NULL;
> + }

Please use the generic support for locating the DT information for
regulators using regulators_node and of_match in the regulator_desc
rather than open coding this.


signature.asc
Description: PGP signature

Re: [PATCH V3 2/2] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Vinod Koul]

On Fri, Oct 16, 2015 at 08:35:19AM +0100, Jon Hunter wrote:
> +static inline void tdma_ch_write(struct tegra_adma_chan *tdc,
> + u32 reg, u32 val)

Coding style issue here

> +static int tegra_adma_alloc_chan_resources(struct dma_chan *dc)
> +{
> + struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc);
> + int ret;
> +
> + ret = pm_runtime_get_sync(tdc2dev(tdc));
> + if (ret)
> + return ret;

pm_runtime_get_sync() return postive values on success too, so this can
fail. This check should be for less than zero case

-- 
~Vinod

--
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/5] mm: simplify reclaim path for MADV_FREE

[Hugh Dickins]

On Mon, 19 Oct 2015, Minchan Kim wrote:

> I made reclaim path mess to check and free MADV_FREEed page.
> This patch simplify it with tweaking add_to_swap.
> 
> So far, we mark page as PG_dirty when we add the page into
> swap cache(ie, add_to_swap) to page out to swap device but
> this patch moves PG_dirty marking under try_to_unmap_one
> when we decide to change pte from anon to swapent so if
> any process's pte has swapent for the page, the page must
> be swapped out. IOW, there should be no funcional behavior
> change. It makes relcaim path really simple for MADV_FREE
> because we just need to check PG_dirty of page to decide
> discarding the page or not.
> 
> Other thing this patch does is to pass TTU_BATCH_FLUSH to
> try_to_unmap when we handle freeable page because I don't
> see any reason to prevent it.
> 
> Cc: Hugh Dickins 
> Cc: Mel Gorman 
> Signed-off-by: Minchan Kim 

Acked-by: Hugh Dickins 

This is sooo much nicer than the code it replaces!  Really good.
Kudos also to Hannes for suggesting this approach originally, I think.

I hope this implementation satisfies a good proportion of the people
who have been wanting MADV_FREE: I'm not among them, and have long
lost touch with those discussions, so won't judge how usable it is.

I assume you'll refactor the series again before it goes to Linus,
so the previous messier implementations vanish?  I notice Andrew
has this "mm: simplify reclaim path for MADV_FREE" in mmotm as
mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch:
I guess it all got much too messy to divide up in a hurry.

I've noticed no problems in testing (unlike the first time you moved
to working with pte_dirty); though of course I've not been using
MADV_FREE itself at all.

One aspect has worried me for a while, but I think I've reached the
conclusion that it doesn't matter at all.  The swap that's allocated
in add_to_swap() would normally get freed again (after try_to_unmap
found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom
of shrink_page_list(), in __remove_mapping(), yes?

The bit that worried me is that on rare occasions, something unknown
might take a speculative reference to the page, and __remove_mapping()
fail to freeze refs for that reason.  Much too rare to worry over not
freeing that page immediately, but it leaves us with a PageUptodate
PageSwapCache !PageDirty page, yet its contents are not the contents
of that location on swap.

But since this can only happen when you have *not* inserted the
corresponding swapent anywhere, I cannot think of anything that would
have a legitimate interest in its contents matching that location on swap.
So I don't think it's worth looking for somewhere to add a SetPageDirty
(or a delete_from_swap_cache) just to regularize that case.

> ---
>  include/linux/rmap.h |  6 +
>  mm/huge_memory.c |  5 
>  mm/rmap.c| 42 ++
>  mm/swap_state.c  |  5 ++--
>  mm/vmscan.c  | 64 
> 
>  5 files changed, 30 insertions(+), 92 deletions(-)
> 
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 6b6233fafb53..978f65066fd5 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -193,8 +193,7 @@ static inline void page_dup_rmap(struct page *page, bool 
> compound)
>   * Called from mm/vmscan.c to handle paging out
>   */
>  int page_referenced(struct page *, int is_locked,
> - struct mem_cgroup *memcg, unsigned long *vm_flags,
> - int *is_pte_dirty);
> + struct mem_cgroup *memcg, unsigned long *vm_flags);
>  
>  #define TTU_ACTION(x) ((x) & TTU_ACTION_MASK)
>  
> @@ -272,11 +271,8 @@ int rmap_walk(struct page *page, struct 
> rmap_walk_control *rwc);
>  static inline int page_referenced(struct page *page, int is_locked,
> struct mem_cgroup *memcg,
> unsigned long *vm_flags,
> -   int *is_pte_dirty)
>  {
>   *vm_flags = 0;
> - if (is_pte_dirty)
> - *is_pte_dirty = 0;
>   return 0;
>  }
>  
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 269ed99493f0..adccfb48ce57 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1753,11 +1753,6 @@ pmd_t *page_check_address_pmd(struct page *page,
>   return NULL;
>  }
>  
> -int pmd_freeable(pmd_t pmd)
> -{
> - return !pmd_dirty(pmd);
> -}
> -
>  #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
>  
>  int hugepage_madvise(struct vm_area_struct *vma,
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 94ee372e238b..fd64f79c87c4 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -797,7 +797,6 @@ int page_mapped_in_vma(struct page *page, struct 
> vm_area_struct *vma)
>  }
>  
>  struct page_referenced_arg {
> - int dirtied;
>   int mapcount;
>   int referenced;
>   unsigned long vm_flags;
> @@ -812,7 +811,6 @@ static int 

Re: Linux 4.2.5

[Greg KH]

diff --git a/Makefile b/Makefile
index a952801a6cd5..96076dcad18e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 2
-SUBLEVEL = 4
+SUBLEVEL = 5
 EXTRAVERSION =
 NAME = Hurr durr I'ma sheep
 
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index 4418a5078833..c8643ac5db71 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_CACHE_L2X0)+= cache-l2x0.o
 obj-$(CONFIG_UX500_SOC_DB8500) += cpu-db8500.o
 obj-$(CONFIG_MACH_MOP500)  += board-mop500-regulators.o \
board-mop500-audio.o
-obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
+obj-$(CONFIG_SMP)  += platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)  += hotplug.o
 obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
 
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 16913800bbf9..ba708ce08616 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -154,7 +154,6 @@ static const char * stericsson_dt_platform_compat[] = {
 };
 
 DT_MACHINE_START(U8500_DT, "ST-Ericsson Ux5x0 platform (Device Tree Support)")
-   .smp= smp_ops(ux500_smp_ops),
.map_io = u8500_map_io,
.init_irq   = ux500_init_irq,
/* we re-use nomadik timer here */
diff --git a/arch/arm/mach-ux500/headsmp.S b/arch/arm/mach-ux500/headsmp.S
deleted file mode 100644
index 9cdea049485d..
--- a/arch/arm/mach-ux500/headsmp.S
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- *  Copyright (c) 2009 ST-Ericsson
- * This file is based  ARM Realview platform
- *  Copyright (c) 2003 ARM Limited
- *  All Rights Reserved
- *
- * 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 
-
-/*
- * U8500 specific entry point for secondary CPUs.
- */
-ENTRY(u8500_secondary_startup)
-   mrc p15, 0, r0, c0, c0, 5
-   and r0, r0, #15
-   adr r4, 1f
-   ldmia   r4, {r5, r6}
-   sub r4, r4, r5
-   add r6, r6, r4
-pen:   ldr r7, [r6]
-   cmp r7, r0
-   bne pen
-
-   /*
-* we've been released from the holding pen: secondary_stack
-* should now contain the SVC stack for this core
-*/
-   b   secondary_startup
-ENDPROC(u8500_secondary_startup)
-
-   .align 2
-1: .long   .
-   .long   pen_release
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 62b1de922bd8..70766b963758 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -28,135 +28,81 @@
 #include "db8500-regs.h"
 #include "id.h"
 
-static void __iomem *scu_base;
-static void __iomem *backupram;
-
-/* This is called from headsmp.S to wakeup the secondary core */
-extern void u8500_secondary_startup(void);
-
-/*
- * Write pen_release in a way that is guaranteed to be visible to all
- * observers, irrespective of whether they're taking part in coherency
- * or not.  This is necessary for the hotplug code to work reliably.
- */
-static void write_pen_release(int val)
-{
-   pen_release = val;
-   smp_wmb();
-   sync_cache_w(_release);
-}
-
-static DEFINE_SPINLOCK(boot_lock);
-
-static void ux500_secondary_init(unsigned int cpu)
-{
-   /*
-* let the primary processor know we're out of the
-* pen, then head off into the C entry point
-*/
-   write_pen_release(-1);
-
-   /*
-* Synchronise with the boot thread.
-*/
-   spin_lock(_lock);
-   spin_unlock(_lock);
-}
+/* Magic triggers in backup RAM */
+#define UX500_CPU1_JUMPADDR_OFFSET 0x1FF4
+#define UX500_CPU1_WAKEMAGIC_OFFSET 0x1FF0
 
-static int ux500_boot_secondary(unsigned int cpu, struct task_struct *idle)
+static void wakeup_secondary(void)
 {
-   unsigned long timeout;
-
-   /*
-* set synchronisation state between this boot processor
-* and the secondary one
-*/
-   spin_lock(_lock);
-
-   /*
-* The secondary processor is waiting to be released from
-* the holding pen - release it, then wait for it to flag
-* that it has been released by resetting pen_release.
-*/
-   write_pen_release(cpu_logical_map(cpu));
-
-   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+   struct device_node *np;
+   static void __iomem *backupram;
 
-   timeout = jiffies + (1 * HZ);
-   while (time_before(jiffies, timeout)) {
-   if (pen_release == -1)
-   break;
+   np = of_find_compatible_node(NULL, NULL, "ste,dbx500-backupram");
+   if (!np) {
+   pr_err("No backupram base address\n");
+   return;
+   }
+   backupram = of_iomap(np, 0);
+   of_node_put(np);
+   if (!backupram) {
+   pr_err("No 

Linux 4.2.5

[Greg KH]

I'm announcing the release of the 4.2.5 kernel.

All users of the 4.2 kernel series must upgrade.

The updated 4.2.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.2.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm/mach-ux500/Makefile|2 
 arch/arm/mach-ux500/cpu-db8500.c|1 
 arch/arm/mach-ux500/headsmp.S   |   37 ---
 arch/arm/mach-ux500/platsmp.c   |  132 
 arch/arm/mach-ux500/setup.h |1 
 arch/arm64/Makefile |2 
 arch/arm64/include/asm/pgtable.h|4 
 arch/sparc/crypto/aes_glue.c|2 
 arch/sparc/crypto/camellia_glue.c   |1 
 arch/sparc/crypto/des_glue.c|2 
 arch/x86/crypto/camellia_aesni_avx_glue.c   |5 +
 arch/x86/kvm/emulate.c  |   10 +-
 arch/x86/kvm/x86.c  |   42 ++--
 crypto/ahash.c  |3 
 drivers/block/rbd.c |1 
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |2 
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c |8 +
 drivers/gpu/drm/amd/amdgpu/cik.c|3 
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c |   10 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |   30 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |   32 ++
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |   30 +-
 drivers/gpu/drm/amd/amdgpu/kv_dpm.c |9 +
 drivers/gpu/drm/amd/amdgpu/vi.c |3 
 drivers/gpu/drm/drm_dp_mst_topology.c   |3 
 drivers/gpu/drm/drm_sysfs.c |   12 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   24 +
 drivers/gpu/drm/qxl/qxl_fb.c|   19 ++--
 drivers/gpu/drm/radeon/radeon_display.c |   14 --
 drivers/gpu/drm/radeon/radeon_dp_mst.c  |1 
 drivers/gpu/drm/radeon/radeon_pm.c  |   63 -
 drivers/i2c/busses/i2c-designware-platdrv.c |   33 +--
 drivers/i2c/busses/i2c-rcar.c   |7 -
 drivers/i2c/busses/i2c-s3c2410.c|8 +
 drivers/md/dm-thin.c|2 
 drivers/mfd/max77843.c  |2 
 drivers/net/ethernet/ibm/emac/core.h|6 -
 drivers/net/ppp/pppoe.c |1 
 drivers/pinctrl/freescale/pinctrl-imx25.c   |4 
 fs/btrfs/backref.c  |8 -
 fs/btrfs/ioctl.c|5 +
 fs/btrfs/volumes.h  |8 +
 fs/nfsd/blocklayout.c   |8 -
 include/drm/drm_dp_mst_helper.h |3 
 include/linux/skbuff.h  |3 
 include/net/af_unix.h   |6 +
 include/net/sock.h  |8 +
 kernel/time/timekeeping.c   |2 
 kernel/workqueue.c  |8 -
 mm/memcontrol.c |1 
 net/core/ethtool.c  |2 
 net/core/filter.c   |7 +
 net/core/skbuff.c   |9 +
 net/dsa/slave.c |   11 +-
 net/ipv4/inet_connection_sock.c |   27 ++---
 net/ipv6/route.c|   12 +-
 net/l2tp/l2tp_core.c|   11 +-
 net/netlink/af_netlink.c|   34 ---
 net/openvswitch/flow_table.c|3 
 net/sched/act_mirred.c  |1 
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |6 -
 net/tipc/msg.h  |4 
 net/unix/af_unix.c  |   17 +++
 64 files changed, 465 insertions(+), 312 deletions(-)

Aaron Conole (2):
  af_unix: Convert the unix_sk macro to an inline function for type safety
  af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

Alex Deucher (4):
  drm/radeon: add pm sysfs files late
  drm/amdgpu: add pm sysfs files late
  drm/amdgpu: fix num_crtc on CZ
  drm/amdgpu: check before checking pci bridge registers

Alexander Couzens (1):
  l2tp: protect tunnel->del_work by ref_count

Alexei Starovoitov (1):
  bpf: clear sender_cpu before xmit

Andrey Vagin (1):
  net/unix: fix logic about sk_peek_offset

Arad, Ronen (1):
  netlink: Trim skb to alloc size to avoid MSG_TRUNC

Ben Hutchings (1):
  crypto: camellia_aesni_avx - Fix CPU feature checks

Ben Skeggs (1):
  drm/nouveau/fbcon: take runpm reference when userspace has an open fd

Chris Mason (1):
  btrfs: fix use after free iterating extrefs

Christoph Hellwig (1):
  nfsd/blocklayout: accept any minlength

Daniel Borkmann (1):
  bpf: fix 

Linux 4.1.12

[Greg KH]

I'm announcing the release of the 4.1.12 kernel.

All users of the 4.1 kernel series must upgrade.

The updated 4.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.1.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm64/Makefile |2 
 arch/arm64/include/asm/pgtable.h|4 -
 arch/powerpc/kvm/book3s_hv.c|2 
 arch/sparc/crypto/aes_glue.c|2 
 arch/sparc/crypto/camellia_glue.c   |1 
 arch/sparc/crypto/des_glue.c|2 
 arch/x86/include/asm/preempt.h  |4 -
 crypto/ahash.c  |3 -
 drivers/block/rbd.c |1 
 drivers/gpu/drm/drm_dp_mst_topology.c   |3 -
 drivers/gpu/drm/drm_sysfs.c |   12 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   24 ++
 drivers/gpu/drm/radeon/radeon_display.c |   14 --
 drivers/gpu/drm/radeon/radeon_dp_mst.c  |1 
 drivers/gpu/drm/radeon/radeon_pm.c  |   63 
 drivers/i2c/busses/i2c-designware-platdrv.c |   33 --
 drivers/i2c/busses/i2c-rcar.c   |7 +--
 drivers/i2c/busses/i2c-s3c2410.c|8 ++-
 drivers/md/dm-thin.c|2 
 drivers/mfd/max77843.c  |2 
 drivers/net/ethernet/ibm/emac/core.h|6 +-
 drivers/net/ppp/pppoe.c |1 
 drivers/pinctrl/freescale/pinctrl-imx25.c   |4 +
 drivers/xen/preempt.c   |2 
 fs/btrfs/backref.c  |8 +--
 fs/btrfs/ioctl.c|5 ++
 fs/btrfs/volumes.h  |8 +++
 fs/locks.c  |   38 
 fs/nfs/nfs4proc.c   |   16 +++
 fs/nfsd/blocklayout.c   |8 ---
 include/asm-generic/preempt.h   |5 +-
 include/drm/drm_dp_mst_helper.h |3 -
 include/linux/fs.h  |   30 -
 include/linux/preempt.h |5 +-
 include/linux/preempt_mask.h|   16 +--
 include/linux/sched.h   |6 --
 include/linux/skbuff.h  |3 +
 include/net/af_unix.h   |6 ++
 include/net/sock.h  |8 +++
 kernel/sched/core.c |6 +-
 kernel/workqueue.c  |8 +--
 mm/memcontrol.c |1 
 net/core/ethtool.c  |2 
 net/core/filter.c   |6 ++
 net/core/skbuff.c   |9 ++--
 net/ipv4/inet_connection_sock.c |   27 ++--
 net/l2tp/l2tp_core.c|   11 
 net/netlink/af_netlink.c|   34 +--
 net/openvswitch/flow_table.c|3 -
 net/sched/act_mirred.c  |1 
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |6 +-
 net/tipc/msg.h  |4 -
 net/unix/af_unix.c  |   16 ++-
 54 files changed, 315 insertions(+), 189 deletions(-)

Aaron Conole (2):
  af_unix: Convert the unix_sk macro to an inline function for type safety
  af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

Alex Deucher (1):
  drm/radeon: add pm sysfs files late

Alexander Couzens (1):
  l2tp: protect tunnel->del_work by ref_count

Andrey Vagin (1):
  net/unix: fix logic about sk_peek_offset

Arad, Ronen (1):
  netlink: Trim skb to alloc size to avoid MSG_TRUNC

Ben Skeggs (1):
  drm/nouveau/fbcon: take runpm reference when userspace has an open fd

Chris Mason (1):
  btrfs: fix use after free iterating extrefs

Christoph Hellwig (1):
  nfsd/blocklayout: accept any minlength

Daniel Borkmann (1):
  bpf: fix panic in SO_GET_FILTER with native ebpf programs

Daniel Vetter (1):
  drm: Fix locking for sysfs dpms file

Dave Airlie (2):
  drm/dp/mst: make mst i2c transfer code more robust.
  drm/radeon: attach tile property to mst connector

Dave Kleikamp (1):
  crypto: sparc - initialize blkcipher.ivsize

David Sterba (1):
  btrfs: check unsupported filters in balance arguments

Eric Dumazet (3):
  inet: fix races in reqsk_queue_hash_req()
  net: add pfmemalloc check in sk_add_backlog()
  inet: fix race in reqsk_queue_unlink()

Frederic Weisbecker (1):
  sched/preempt: Rename PREEMPT_CHECK_OFFSET to PREEMPT_DISABLE_OFFSET

Greg Kroah-Hartman (1):
  Linux 4.1.12

Guillaume Nault (1):
  ppp: don't override 

Re: Linux 4.1.12

[Greg KH]

diff --git a/Makefile b/Makefile
index c7d877b1c248..2320f1911404 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 1
-SUBLEVEL = 11
+SUBLEVEL = 12
 EXTRAVERSION =
 NAME = Series 4800
 
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 81151663ef38..3258174e6152 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -31,7 +31,7 @@ endif
 CHECKFLAGS += -D__aarch64__
 
 ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
-CFLAGS_MODULE  += -mcmodel=large
+KBUILD_CFLAGS_MODULE   += -mcmodel=large
 endif
 
 # Default value
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 56283f8a675c..cf7319422768 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -80,7 +80,7 @@ extern void __pgd_error(const char *file, int line, unsigned 
long val);
 #define PAGE_S2__pgprot(PROT_DEFAULT | 
PTE_S2_MEMATTR(MT_S2_NORMAL) | PTE_S2_RDONLY)
 #define PAGE_S2_DEVICE __pgprot(PROT_DEFAULT | 
PTE_S2_MEMATTR(MT_S2_DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_UXN)
 
-#define PAGE_NONE  __pgprot(((_PAGE_DEFAULT) & ~PTE_TYPE_MASK) | 
PTE_PROT_NONE | PTE_PXN | PTE_UXN)
+#define PAGE_NONE  __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | 
PTE_PROT_NONE | PTE_PXN | PTE_UXN)
 #define PAGE_SHARED__pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | 
PTE_PXN | PTE_UXN | PTE_WRITE)
 #define PAGE_SHARED_EXEC   __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | 
PTE_PXN | PTE_WRITE)
 #define PAGE_COPY  __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | 
PTE_PXN | PTE_UXN)
@@ -460,7 +460,7 @@ static inline pud_t *pud_offset(pgd_t *pgd, unsigned long 
addr)
 static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 {
const pteval_t mask = PTE_USER | PTE_PXN | PTE_UXN | PTE_RDONLY |
- PTE_PROT_NONE | PTE_WRITE | PTE_TYPE_MASK;
+ PTE_PROT_NONE | PTE_VALID | PTE_WRITE;
pte_val(pte) = (pte_val(pte) & ~mask) | (pgprot_val(newprot) & mask);
return pte;
 }
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index df81caab7383..f1e0e5522e3a 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2178,7 +2178,7 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run, 
struct kvm_vcpu *vcpu)
vc->runner = vcpu;
if (n_ceded == vc->n_runnable) {
kvmppc_vcore_blocked(vc);
-   } else if (should_resched()) {
+   } else if (need_resched()) {
vc->vcore_state = VCORE_PREEMPT;
/* Let something else run */
cond_resched_lock(>lock);
diff --git a/arch/sparc/crypto/aes_glue.c b/arch/sparc/crypto/aes_glue.c
index 2e48eb8813ff..c90930de76ba 100644
--- a/arch/sparc/crypto/aes_glue.c
+++ b/arch/sparc/crypto/aes_glue.c
@@ -433,6 +433,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
@@ -452,6 +453,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt= ctr_crypt,
.decrypt= ctr_crypt,
diff --git a/arch/sparc/crypto/camellia_glue.c 
b/arch/sparc/crypto/camellia_glue.c
index 6bf2479a12fb..561a84d93cf6 100644
--- a/arch/sparc/crypto/camellia_glue.c
+++ b/arch/sparc/crypto/camellia_glue.c
@@ -274,6 +274,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= CAMELLIA_MIN_KEY_SIZE,
.max_keysize= CAMELLIA_MAX_KEY_SIZE,
+   .ivsize = CAMELLIA_BLOCK_SIZE,
.setkey = camellia_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
diff --git a/arch/sparc/crypto/des_glue.c b/arch/sparc/crypto/des_glue.c
index dd6a34fa6e19..61af794aa2d3 100644
--- a/arch/sparc/crypto/des_glue.c
+++ b/arch/sparc/crypto/des_glue.c
@@ -429,6 +429,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= DES_KEY_SIZE,
.max_keysize= DES_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
.setkey = des_set_key,
.encrypt= 

Re: Linux 3.14.56

[Greg KH]

diff --git a/Makefile b/Makefile
index 97d18c1d27f2..2a13d9d63880 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 55
+SUBLEVEL = 56
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 0ab1a34dab58..dcc26850727d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -35,7 +35,7 @@ comma = ,
 CHECKFLAGS += -D__aarch64__
 
 ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
-CFLAGS_MODULE  += -mcmodel=large
+KBUILD_CFLAGS_MODULE   += -mcmodel=large
 endif
 
 # Default value
diff --git a/arch/sparc/crypto/aes_glue.c b/arch/sparc/crypto/aes_glue.c
index ded4cee35318..dc78cdd43e0a 100644
--- a/arch/sparc/crypto/aes_glue.c
+++ b/arch/sparc/crypto/aes_glue.c
@@ -433,6 +433,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
@@ -452,6 +453,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt= ctr_crypt,
.decrypt= ctr_crypt,
diff --git a/arch/sparc/crypto/camellia_glue.c 
b/arch/sparc/crypto/camellia_glue.c
index 641f55cb61c3..eb87d6dd86b1 100644
--- a/arch/sparc/crypto/camellia_glue.c
+++ b/arch/sparc/crypto/camellia_glue.c
@@ -274,6 +274,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= CAMELLIA_MIN_KEY_SIZE,
.max_keysize= CAMELLIA_MAX_KEY_SIZE,
+   .ivsize = CAMELLIA_BLOCK_SIZE,
.setkey = camellia_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
diff --git a/arch/sparc/crypto/des_glue.c b/arch/sparc/crypto/des_glue.c
index d11500972994..1359bfc544e4 100644
--- a/arch/sparc/crypto/des_glue.c
+++ b/arch/sparc/crypto/des_glue.c
@@ -429,6 +429,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= DES_KEY_SIZE,
.max_keysize= DES_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
.setkey = des_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
@@ -485,6 +486,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= DES3_EDE_KEY_SIZE,
.max_keysize= DES3_EDE_KEY_SIZE,
+   .ivsize = DES3_EDE_BLOCK_SIZE,
.setkey = des3_ede_set_key,
.encrypt= cbc3_encrypt,
.decrypt= cbc3_decrypt,
diff --git a/arch/x86/include/asm/preempt.h b/arch/x86/include/asm/preempt.h
index b39e194f6c8d..999b4a3e65f5 100644
--- a/arch/x86/include/asm/preempt.h
+++ b/arch/x86/include/asm/preempt.h
@@ -105,9 +105,9 @@ static __always_inline bool 
__preempt_count_dec_and_test(void)
 /*
  * Returns true when we need to resched and can (barring IRQ state).
  */
-static __always_inline bool should_resched(void)
+static __always_inline bool should_resched(int preempt_offset)
 {
-   return unlikely(!__this_cpu_read_4(__preempt_count));
+   return unlikely(__this_cpu_read_4(__preempt_count) == preempt_offset);
 }
 
 #ifdef CONFIG_PREEMPT
diff --git a/crypto/ahash.c b/crypto/ahash.c
index a92dc382f781..865ef923eda6 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -465,7 +465,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
struct crypto_alg *base = >halg.base;
 
if (alg->halg.digestsize > PAGE_SIZE / 8 ||
-   alg->halg.statesize > PAGE_SIZE / 8)
+   alg->halg.statesize > PAGE_SIZE / 8 ||
+   alg->halg.statesize == 0)
return -EINVAL;
 
base->cra_type = _ahash_type;
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index b583773e4ecb..2ea515509ca6 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -4851,7 +4851,6 @@ static int rbd_dev_probe_parent(struct rbd_device 
*rbd_dev)
 out_err:
if (parent) {
rbd_dev_unparent(rbd_dev);
-   kfree(rbd_dev->header_name);
rbd_dev_destroy(parent);
} else {
rbd_put_client(rbdc);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 

Linux 3.14.56

[Greg KH]

I'm announcing the release of the 3.14.56 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm64/Makefile |2 
 arch/sparc/crypto/aes_glue.c|2 
 arch/sparc/crypto/camellia_glue.c   |1 
 arch/sparc/crypto/des_glue.c|2 
 arch/x86/include/asm/preempt.h  |4 -
 crypto/ahash.c  |3 -
 drivers/block/rbd.c |1 
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   24 ++
 drivers/gpu/drm/radeon/radeon_display.c |   14 --
 drivers/gpu/drm/radeon/radeon_pm.c  |   63 
 drivers/i2c/busses/i2c-designware-platdrv.c |   20 
 drivers/i2c/busses/i2c-rcar.c   |7 +--
 drivers/i2c/busses/i2c-s3c2410.c|8 ++-
 drivers/md/dm-thin.c|2 
 drivers/net/ppp/pppoe.c |1 
 drivers/net/usb/asix_devices.c  |   16 ---
 fs/btrfs/backref.c  |8 +--
 include/asm-generic/preempt.h   |5 +-
 include/linux/preempt.h |5 +-
 include/linux/preempt_mask.h|   16 +--
 include/linux/sched.h   |6 --
 include/linux/skbuff.h  |3 +
 include/net/af_unix.h   |6 ++
 include/net/sock.h  |8 +++
 kernel/sched/core.c |6 +-
 kernel/workqueue.c  |8 +--
 net/core/ethtool.c  |2 
 net/core/skbuff.c   |9 ++--
 net/l2tp/l2tp_core.c|   11 
 net/unix/af_unix.c  |   16 ++-
 31 files changed, 181 insertions(+), 100 deletions(-)

Aaron Conole (2):
  af_unix: Convert the unix_sk macro to an inline function for type safety
  af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

Alex Deucher (1):
  drm/radeon: add pm sysfs files late

Alexander Couzens (1):
  l2tp: protect tunnel->del_work by ref_count

Andrey Vagin (1):
  net/unix: fix logic about sk_peek_offset

Ben Skeggs (1):
  drm/nouveau/fbcon: take runpm reference when userspace has an open fd

Charles Keepax (1):
  asix: Do full reset during ax88772_bind

Chris Mason (1):
  btrfs: fix use after free iterating extrefs

Dave Kleikamp (1):
  crypto: sparc - initialize blkcipher.ivsize

Eric Dumazet (1):
  net: add pfmemalloc check in sk_add_backlog()

Frederic Weisbecker (1):
  sched/preempt: Rename PREEMPT_CHECK_OFFSET to PREEMPT_DISABLE_OFFSET

Greg Kroah-Hartman (1):
  Linux 3.14.56

Guillaume Nault (1):
  ppp: don't override sk->sk_state in pppoe_flush_dev()

Ilya Dryomov (1):
  rbd: fix double free on rbd_dev->header_name

Joe Perches (1):
  ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

Konstantin Khlebnikov (1):
  sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()

Michel Stam (1):
  asix: Don't reset PHY on if_up for ASIX 88772

Mika Westerberg (1):
  i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

Mike Snitzer (1):
  dm thin: fix missing pool reference count decrement in pool_ctr error path

Pravin B Shelar (2):
  skbuff: Fix skb checksum flag on skb pull
  skbuff: Fix skb checksum partial check.

Russell King (1):
  crypto: ahash - ensure statesize is non-zero

Shaohua Li (1):
  workqueue: make sure delayed work run in local cpu

Will Deacon (1):
  arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419

Wolfram Sang (2):
  i2c: rcar: enable RuntimePM before registering to the core
  i2c: s3c2410: enable RuntimePM before registering to the core



signature.asc
Description: PGP signature

Re: Linux 3.10.92

[Greg KH]

diff --git a/Makefile b/Makefile
index ba6a94cf354b..25701b67bb6d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 10
-SUBLEVEL = 91
+SUBLEVEL = 92
 EXTRAVERSION =
 NAME = TOSSUG Baby Fish
 
diff --git a/arch/m68k/include/asm/uaccess_mm.h 
b/arch/m68k/include/asm/uaccess_mm.h
index 472c891a4aee..15901db435b9 100644
--- a/arch/m68k/include/asm/uaccess_mm.h
+++ b/arch/m68k/include/asm/uaccess_mm.h
@@ -90,7 +90,7 @@ asm volatile ("\n"\
__put_user_asm(__pu_err, __pu_val, ptr, b, d, -EFAULT); \
break;  \
case 2: \
-   __put_user_asm(__pu_err, __pu_val, ptr, w, d, -EFAULT); \
+   __put_user_asm(__pu_err, __pu_val, ptr, w, r, -EFAULT); \
break;  \
case 4: \
__put_user_asm(__pu_err, __pu_val, ptr, l, r, -EFAULT); \
@@ -158,7 +158,7 @@ asm volatile ("\n"  \
__get_user_asm(__gu_err, x, ptr, u8, b, d, -EFAULT);\
break;  \
case 2: \
-   __get_user_asm(__gu_err, x, ptr, u16, w, d, -EFAULT);   \
+   __get_user_asm(__gu_err, x, ptr, u16, w, r, -EFAULT);   \
break;  \
case 4: \
__get_user_asm(__gu_err, x, ptr, u32, l, r, -EFAULT);   \
@@ -245,7 +245,7 @@ __constant_copy_from_user(void *to, const void __user 
*from, unsigned long n)
__get_user_asm(res, *(u8 *)to, (u8 __user *)from, u8, b, d, 1);
break;
case 2:
-   __get_user_asm(res, *(u16 *)to, (u16 __user *)from, u16, w, d, 
2);
+   __get_user_asm(res, *(u16 *)to, (u16 __user *)from, u16, w, r, 
2);
break;
case 3:
__constant_copy_from_user_asm(res, to, from, tmp, 3, w, b,);
@@ -326,7 +326,7 @@ __constant_copy_to_user(void __user *to, const void *from, 
unsigned long n)
__put_user_asm(res, *(u8 *)from, (u8 __user *)to, b, d, 1);
break;
case 2:
-   __put_user_asm(res, *(u16 *)from, (u16 __user *)to, w, d, 2);
+   __put_user_asm(res, *(u16 *)from, (u16 __user *)to, w, r, 2);
break;
case 3:
__constant_copy_to_user_asm(res, to, from, tmp, 3, w, b,);
diff --git a/arch/m68k/lib/uaccess.c b/arch/m68k/lib/uaccess.c
index 5e97f2ee7c11..35d1442dee89 100644
--- a/arch/m68k/lib/uaccess.c
+++ b/arch/m68k/lib/uaccess.c
@@ -52,7 +52,7 @@ unsigned long __generic_copy_from_user(void *to, const void 
__user *from,
"   .long   3b,30b\n"
"   .long   5b,50b\n"
"   .previous"
-   : "=d" (res), "+a" (from), "+a" (to), "=" (tmp)
+   : "=d" (res), "+a" (from), "+a" (to), "=" (tmp)
: "0" (n / 4), "d" (n & 3));
 
return res;
@@ -96,7 +96,7 @@ unsigned long __generic_copy_to_user(void __user *to, const 
void *from,
"   .long   7b,50b\n"
"   .long   8b,50b\n"
"   .previous"
-   : "=d" (res), "+a" (from), "+a" (to), "=" (tmp)
+   : "=d" (res), "+a" (from), "+a" (to), "=" (tmp)
: "0" (n / 4), "d" (n & 3));
 
return res;
@@ -141,7 +141,7 @@ unsigned long __clear_user(void __user *to, unsigned long n)
"   .long   7b,40b\n"
"   .previous"
: "=d" (res), "+a" (to)
-   : "r" (0), "0" (n / 4), "d" (n & 3));
+   : "d" (0), "0" (n / 4), "d" (n & 3));
 
 return res;
 }
diff --git a/arch/sparc/crypto/aes_glue.c b/arch/sparc/crypto/aes_glue.c
index ded4cee35318..dc78cdd43e0a 100644
--- a/arch/sparc/crypto/aes_glue.c
+++ b/arch/sparc/crypto/aes_glue.c
@@ -433,6 +433,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt= cbc_encrypt,
.decrypt= cbc_decrypt,
@@ -452,6 +453,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize= AES_MIN_KEY_SIZE,
.max_keysize= AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
 

Linux 3.10.92

[Greg KH]

I'm announcing the release of the 3.10.92 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 +-
 arch/m68k/include/asm/uaccess_mm.h |8 
 arch/m68k/lib/uaccess.c|6 +++---
 arch/sparc/crypto/aes_glue.c   |2 ++
 arch/sparc/crypto/camellia_glue.c  |1 +
 arch/sparc/crypto/des_glue.c   |2 ++
 crypto/ahash.c |3 ++-
 drivers/block/rbd.c|1 -
 drivers/i2c/busses/i2c-rcar.c  |7 ---
 drivers/md/dm-thin.c   |2 +-
 drivers/net/ppp/pppoe.c|1 -
 drivers/net/usb/asix_devices.c |   16 ++--
 include/linux/skbuff.h |3 +++
 include/net/af_unix.h  |6 +-
 include/net/sock.h |8 
 kernel/workqueue.c |8 
 net/core/ethtool.c |2 +-
 net/core/skbuff.c  |9 +
 net/l2tp/l2tp_core.c   |   11 +--
 net/unix/af_unix.c |   14 +-
 20 files changed, 70 insertions(+), 42 deletions(-)

Aaron Conole (2):
  af_unix: Convert the unix_sk macro to an inline function for type safety
  af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

Alexander Couzens (1):
  l2tp: protect tunnel->del_work by ref_count

Charles Keepax (1):
  asix: Do full reset during ax88772_bind

Dave Kleikamp (1):
  crypto: sparc - initialize blkcipher.ivsize

Eric Dumazet (1):
  net: add pfmemalloc check in sk_add_backlog()

Geert Uytterhoeven (1):
  m68k/uaccess: Fix asm constraints for userspace access

Greg Kroah-Hartman (1):
  Linux 3.10.92

Guillaume Nault (1):
  ppp: don't override sk->sk_state in pppoe_flush_dev()

Ilya Dryomov (1):
  rbd: fix double free on rbd_dev->header_name

Joe Perches (1):
  ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

Michel Stam (1):
  asix: Don't reset PHY on if_up for ASIX 88772

Mike Snitzer (1):
  dm thin: fix missing pool reference count decrement in pool_ctr error path

Pravin B Shelar (2):
  skbuff: Fix skb checksum flag on skb pull
  skbuff: Fix skb checksum partial check.

Russell King (1):
  crypto: ahash - ensure statesize is non-zero

Shaohua Li (1):
  workqueue: make sure delayed work run in local cpu

Wolfram Sang (1):
  i2c: rcar: enable RuntimePM before registering to the core



signature.asc
Description: PGP signature

Re: [REPOST PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

[John Youn]

On 10/21/2015 9:23 AM, Doug Anderson wrote:
> John,
> 
> On Mon, Jul 6, 2015 at 11:27 AM, Douglas Anderson  
> wrote:
>> This series of patches, together with
>>  from Chris Zhong and a
>> dts change allow us to wake up from a USB device on rk3288 boards.
>> The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
>> The chromeos-3.14 kernel tested included a full set of dwc2 backports
>> from upstream, so this is expected to function upstream once we get
>> everything setup there.
>>
>>
>> Douglas Anderson (3):
>>   USB: Export usb_wakeup_enabled_descendants()
>>   Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
>>   USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
>>
>>  Documentation/devicetree/bindings/usb/dwc2.txt |  4 +++
>>  drivers/usb/core/hub.c |  7 ++--
>>  drivers/usb/dwc2/core.h|  2 ++
>>  drivers/usb/dwc2/platform.c| 45 
>> --
>>  include/linux/usb/hcd.h|  5 +++
>>  5 files changed, 58 insertions(+), 5 deletions(-)
> 
> This series was posted a while ago.  Do you have any comments on it?
> Should I repost it?
> 
> Thanks!
> 
> -Doug
> 


Sorry, I must have missed it earlier.

Could you repost based on latest and I'll review.

Regards,
John


--
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 3/5] mtd: ofpart: update devicetree binding specification

[Brian Norris]

On Sun, Oct 11, 2015 at 01:04:02PM -0700, Brian Norris wrote:
> Hi DT maintainers,

Last call: I'd like a reviewer that
(1) does DT reviews somewhat regularly and
(2) is not me.

If I can't get one soon, I'll take this for 4.4.

Thanks,
Brian

> It's a bit hypocritical of me, since I've been a slow reviewer as well,
> but... can we get some review on this one? Usually, I'm comfortable
> taking driver DT bindings without your review, but this one is a bit
> more generic and is more far-reaching than the average driver.
> 
> I'm not a big fan of this change, and I don't quite understand why the
> bus driver (the SPI bus, which is a level up from the SPI device / MTD
> node) can specify its grandchildren (see spi-samsung.txt). But given the
> constraints, I think Michal's solution is OK. And I do agree that MTD's
> ofpart should be bit more specific.
> 
> Anyway, a quick look and an Ack/Nak would be appreciated.
> 
> Thanks,
> Brian
> 
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
> > To avoid conflict with other drivers using subnodes of the mtd device
> > create only one ofpart-specific node rather than any number of
> > arbitrary partition subnodes.
> > 
> > Signed-off-by: Michal Suchanek 
> > ---
> > v3:
> > 
> >  - rename DT node ofpart -> partitions
> > ---
> >  .../devicetree/bindings/mtd/partition.txt  | 68 
> > +-
> >  1 file changed, 40 insertions(+), 28 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> > b/Documentation/devicetree/bindings/mtd/partition.txt
> > index 8e5557d..8c2aff7 100644
> > --- a/Documentation/devicetree/bindings/mtd/partition.txt
> > +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> > @@ -4,10 +4,16 @@ Partitions can be represented by sub-nodes of an mtd 
> > device. This can be used
> >  on platforms which have strong conventions about which portions of a flash 
> > are
> >  used for what purposes, but which don't use an on-flash partition table 
> > such
> >  as RedBoot.
> > +
> > +The partition table should be partitions subnode of the mtd node. 
> > Partitions are
> > +defined in subnodes of the partitions node.
> > +
> > +For backwards compatibility partitions as direct subnodes of the mtd 
> > device are
> > +supported. This use is discouraged.
> >  NOTE: if the sub-node has a compatible string, then it is not a partition.
> >  
> > -#address-cells & #size-cells must both be present in the mtd device. There 
> > are
> > -two valid values for both:
> > +#address-cells & #size-cells must both be present in the partitions 
> > subnode of the
> > +mtd device. There are two valid values for both:
> >  <1>: for partitions that require a single 32-bit cell to represent their
> >   size/address (aka the value is below 4 GiB)
> >  <2>: for partitions that require two 32-bit cells to represent their
> > @@ -28,44 +34,50 @@ Examples:
> >  
> >  
> >  flash@0 {
> > -   #address-cells = <1>;
> > -   #size-cells = <1>;
> > +   partitions {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> >  
> > -   partition@0 {
> > -   label = "u-boot";
> > -   reg = <0x000 0x10>;
> > -   read-only;
> > -   };
> > +   partition@0 {
> > +   label = "u-boot";
> > +   reg = <0x000 0x10>;
> > +   read-only;
> > +   };
> >  
> > -   uimage@10 {
> > -   reg = <0x010 0x20>;
> > +   uimage@10 {
> > +   reg = <0x010 0x20>;
> > +   };
> > };
> >  };
> >  
> >  flash@1 {
> > -   #address-cells = <1>;
> > -   #size-cells = <2>;
> > +   partitions {
> > +   #address-cells = <1>;
> > +   #size-cells = <2>;
> >  
> > -   /* a 4 GiB partition */
> > -   partition@0 {
> > -   label = "filesystem";
> > -   reg = <0x 0x1 0x>;
> > +   /* a 4 GiB partition */
> > +   partition@0 {
> > +   label = "filesystem";
> > +   reg = <0x 0x1 0x>;
> > +   };
> > };
> >  };
> >  
> >  flash@2 {
> > -   #address-cells = <2>;
> > -   #size-cells = <2>;
> > +   partitions {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> >  
> > -   /* an 8 GiB partition */
> > -   partition@0 {
> > -   label = "filesystem #1";
> > -   reg = <0x0 0x 0x2 0x>;
> > -   };
> > +   /* an 8 GiB partition */
> > +   partition@0 {
> > +   label = "filesystem #1";
> > +   reg = <0x0 0x 0x2 0x>;
> > +   };
> >  
> > -   /* a 4 GiB partition */
> > -   partition@2 {
> > -   label = "filesystem #2";
> > -   reg = <0x2 0x 0x1 0x>;
> > +   /* a 4 GiB partition */
> > +   partition@2 {
> > +   label = "filesystem #2";
> > +   

Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume support

[Vinod Koul]

On Mon, Oct 19, 2015 at 04:31:05PM +0800, Yuan Yao wrote:

The patch overall looks fine, but
>  
> +static int fsl_edma_suspend_late(struct device *dev)

This needs protection and will have build failure when CONFIG_PM is not
defined

> +{
> + struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> + struct fsl_edma_chan *fsl_chan;
> + unsigned long flags;
> + int i;
> +
> + for (i = 0; i < fsl_edma->n_chans; i++) {
> + fsl_chan = _edma->chans[i];
> + spin_lock_irqsave(_chan->vchan.lock, flags);
> + /* Make sure chan is idle or will force disable. */
> + if (unlikely(!fsl_chan->idle)) {
> + dev_warn(dev, "WARN: There is non-idle channel.");
> + fsl_edma_disable_request(fsl_chan);
> + fsl_edma_chan_mux(fsl_chan, 0, false);
> + }
> +
> + fsl_chan->pm_state = SUSPENDED;
> + spin_unlock_irqrestore(_chan->vchan.lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static int fsl_edma_resume_early(struct device *dev)
> +{
> + struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> + struct fsl_edma_chan *fsl_chan;
> + int i;
> +
> + for (i = 0; i < fsl_edma->n_chans; i++) {
> + fsl_chan = _edma->chans[i];
> + fsl_chan->pm_state = RUNNING;
> + edma_writew(fsl_edma, 0x0, fsl_edma->membase + EDMA_TCD_CSR(i));
> + if (fsl_chan->slave_id != 0)
> + fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id, true);
> + }
> +
> + edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> + fsl_edma->membase + EDMA_CR);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops fsl_edma_pm_ops = {
> + .suspend_late   = fsl_edma_suspend_late,
> + .resume_early   = fsl_edma_resume_early,
> +};

This one too, also why use late and early, pls add the note here

>  static const struct of_device_id fsl_edma_dt_ids[] = {
>   { .compatible = "fsl,vf610-edma", },
>   { /* sentinel */ }
> @@ -969,6 +1042,7 @@ static struct platform_driver fsl_edma_driver = {
>   .driver = {
>   .name   = "fsl-edma",
>   .of_match_table = fsl_edma_dt_ids,
> + .pm = _edma_pm_ops,
This will fail too if CONFIG_PM is not defined

-- 
~Vinod
--
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] f2fs: support file defragment

[Chao Yu]

This patch introduces a new ioctl F2FS_IOC_DEFRAGMENT to support file
defragment in a specified range of regular file.

This ioctl can be used in very limited workload: if user expects high
sequential read performance in randomly written file, this interface
can be used for defragmentation, after that file can be written as
continuous as possible in the device.

Meanwhile, it has side-effect, it will make holes in segments where
blocks located originally, so it's better to trigger GC to eliminate
fragment in segments.

Signed-off-by: Chao Yu 
---
v2:
 - check IPU policy in advance.
 - use get_lock_data_page suggested by Jaegeuk.
 fs/f2fs/data.c |   6 +-
 fs/f2fs/f2fs.h |   8 +++
 fs/f2fs/file.c | 195 +
 3 files changed, 208 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 180cdbf..14a4d24 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -566,7 +566,7 @@ out:
  * b. do not use extent cache for better performance
  * c. give the block addresses to blockdev
  */
-static int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
+int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
int create, int flag)
 {
unsigned int maxblocks = map->m_len;
@@ -1354,6 +1354,10 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
available_free_memory(sbi, DIRTY_DENTS))
goto skip_write;
 
+   /* skip writing during file defragment */
+   if (is_inode_flag_set(F2FS_I(inode), FI_DO_DEFRAG))
+   goto skip_write;
+
/* during POR, we don't need to trigger writepage at all. */
if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
goto skip_write;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9db5500..068813c 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -234,6 +234,7 @@ static inline bool __has_cursum_space(struct 
f2fs_summary_block *sum, int size,
 #define F2FS_IOC_ABORT_VOLATILE_WRITE  _IO(F2FS_IOCTL_MAGIC, 5)
 #define F2FS_IOC_GARBAGE_COLLECT   _IO(F2FS_IOCTL_MAGIC, 6)
 #define F2FS_IOC_WRITE_CHECKPOINT  _IO(F2FS_IOCTL_MAGIC, 7)
+#define F2FS_IOC_DEFRAGMENT_IO(F2FS_IOCTL_MAGIC, 8)
 
 #define F2FS_IOC_SET_ENCRYPTION_POLICY \
_IOR('f', 19, struct f2fs_encryption_policy)
@@ -260,6 +261,11 @@ static inline bool __has_cursum_space(struct 
f2fs_summary_block *sum, int size,
 #define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
 #endif
 
+struct f2fs_defragment {
+   u64 start;
+   u64 len;
+};
+
 /*
  * For INODE and NODE manager
  */
@@ -1416,6 +1422,7 @@ enum {
FI_DROP_CACHE,  /* drop dirty page cache */
FI_DATA_EXIST,  /* indicate data exists */
FI_INLINE_DOTS, /* indicate inline dot dentries */
+   FI_DO_DEFRAG,   /* indicate defragment is running */
 };
 
 static inline void set_inode_flag(struct f2fs_inode_info *fi, int flag)
@@ -1847,6 +1854,7 @@ struct page *find_data_page(struct inode *, pgoff_t);
 struct page *get_lock_data_page(struct inode *, pgoff_t, bool);
 struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
 int do_write_data_page(struct f2fs_io_info *);
+int f2fs_map_blocks(struct inode *, struct f2fs_map_blocks *, int, int);
 int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *, u64, u64);
 void f2fs_invalidate_page(struct page *, unsigned int, unsigned int);
 int f2fs_release_page(struct page *, gfp_t);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index a197215..2f39298 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1646,6 +1646,199 @@ static int f2fs_ioc_write_checkpoint(struct file *filp, 
unsigned long arg)
return 0;
 }
 
+static int f2fs_defragment_range(struct f2fs_sb_info *sbi,
+   struct file *filp,
+   struct f2fs_defragment *range)
+{
+   struct inode *inode = file_inode(filp);
+   struct f2fs_map_blocks map;
+   struct extent_info ei;
+   pgoff_t pg_start, pg_end;
+   unsigned int blk_per_seg = 1 << sbi->log_blocks_per_seg;
+   unsigned int total = 0, sec_num;
+   unsigned int pages_per_sec = sbi->segs_per_sec *
+   (1 << sbi->log_blocks_per_seg);
+   block_t blk_end = 0;
+   bool fragmented = false;
+   int err;
+
+   /* if in-place-update policy is enabled, don't waste time here */
+   if (need_inplace_update(inode))
+   return -EINVAL;
+
+   pg_start = range->start >> PAGE_CACHE_SHIFT;
+   pg_end = (range->start + range->len) >> PAGE_CACHE_SHIFT;
+
+   f2fs_balance_fs(sbi);
+
+   mutex_lock(>i_mutex);
+
+   /* writeback all dirty pages in the range */
+   err = filemap_write_and_wait_range(inode->i_mapping, range->start,
+   

Re: [Linux v4.3-rc6] i915: issues with Skylake integrated graphics

[Eric Biggers]

On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote:
> Please file two separate bugs at [1], one for the above, and another for
> the below. Please add drm.debug=14 module parameter, and attach dmesg
> all the way from boot to the problem.

I have filed https://bugs.freedesktop.org/show_bug.cgi?id=92685 for the second
part.  I did not, however, re-experience the first warning (the
"WARN_ON(p->pixel_rate == 0)") after upgrading to Linux v4.3-rc7 and rebooting
several times.

Eric
--
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 4/5] mtd: ofpart: document the lock flag.

[Brian Norris]

On Sun, Oct 11, 2015 at 01:04:12PM -0700, Brian Norris wrote:
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
> > The lock flag of ofpart is undocumented. Add to binding doc.
> 
> Good catch. There are a lot of small corners of very old code that never
> really got reviewed properly, I expect...
> 
> (And the flag looks very odd. Why exactly is it in the partitions?)
> 
> And now that I'm looking further...does this flag even *do* anything?
> AFAICT, it doesn't set the master device flags -- only the partition
> flags. But MTD drivers currently never see the partition flags -- they
> only see the master struct mtd_info. I think the only way anyone could
> observe the effect of this flag is to read the MTD flags from sysfs. And
> that's pretty useless.
> 
> If my understanding is correct, then I'd rather completely remove the
> code that "handles" this flag, rather than codify it in the docs.

I've tested and confirmed: this only sets the flags for the partition
(*NOT* for the master device), so the only visible effect of this
property is to change sysfs flags. I'll send out a patch to kill this
property entirely.

Brian
--
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] sched: fix incorrect wait time and wait count statistics

[Joonwoo Park]

On 10/25/2015 03:26 AM, Peter Zijlstra wrote:
> On Sat, Oct 24, 2015 at 10:23:14PM -0700, Joonwoo Park wrote:
>> @@ -1069,7 +1069,7 @@ static struct rq *move_queued_task(struct rq *rq, 
>> struct task_struct *p, int new
>>  {
>>  lockdep_assert_held(>lock);
>>  
>> -dequeue_task(rq, p, 0);
>> +dequeue_task(rq, p, DEQUEUE_MIGRATING);
>>  p->on_rq = TASK_ON_RQ_MIGRATING;
>>  set_task_cpu(p, new_cpu);
>>  raw_spin_unlock(>lock);
> 
>> @@ -5656,7 +5671,7 @@ static void detach_task(struct task_struct *p, struct 
>> lb_env *env)
>>  {
>>  lockdep_assert_held(>src_rq->lock);
>>  
>> -deactivate_task(env->src_rq, p, 0);
>> +deactivate_task(env->src_rq, p, DEQUEUE_MIGRATING);
>>  p->on_rq = TASK_ON_RQ_MIGRATING;
>>  set_task_cpu(p, env->dst_cpu);
>>  }
> 
> Also note that on both sites we also set TASK_ON_RQ_MIGRATING -- albeit
> late. Can't you simply set that earlier (and back to QUEUED later) and
> test for task_on_rq_migrating() instead of blowing up the fastpath like
> you did?
> 

Yes it's doable.  I also find it's much simpler.
Please find patch v2.  I verified v2 does same job as v1 by comparing 
sched_stat_wait time with sched_switch - sched_wakeup timestamp.

Thanks,
Joonwoo
>From 98d615d46211a90482a0f9b7204265c54bba8520 Mon Sep 17 00:00:00 2001
From: Joonwoo Park 
Date: Mon, 26 Oct 2015 16:37:47 -0700
Subject: [PATCH v2] sched: fix incorrect wait time and wait count statistics

At present scheduler resets task's wait start timestamp when the task
migrates to another rq.  This misleads scheduler itself into reporting
less wait time than actual by omitting time spent for waiting prior to
migration and also more wait count than actual by counting migration as
wait end event which can be seen by trace or /proc//sched with
CONFIG_SCHEDSTATS=y.

Carry forward migrating task's wait time prior to migration and
don't count migration as a wait end event to fix such statistics error.

In order to determine whether task is migrating mark task->on_rq with
TASK_ON_RQ_MIGRATING while dequeuing and enqueuing due to migration.

To: Ingo Molnar 
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park 
---
Changes in v2: 
 * Set p->on_rq = TASK_ON_RQ_MIGRATING while doing migration dequeue/enqueue
   and check whether task's migrating with task_on_rq_migrating().

 kernel/sched/core.c |  4 ++--
 kernel/sched/fair.c | 17 ++---
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bcd214e..d9e4ad5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1069,8 +1069,8 @@ static struct rq *move_queued_task(struct rq *rq, struct task_struct *p, int new
 {
 	lockdep_assert_held(>lock);
 
-	dequeue_task(rq, p, 0);
 	p->on_rq = TASK_ON_RQ_MIGRATING;
+	dequeue_task(rq, p, 0);
 	set_task_cpu(p, new_cpu);
 	raw_spin_unlock(>lock);
 
@@ -1078,8 +1078,8 @@ static struct rq *move_queued_task(struct rq *rq, struct task_struct *p, int new
 
 	raw_spin_lock(>lock);
 	BUG_ON(task_cpu(p) != new_cpu);
-	p->on_rq = TASK_ON_RQ_QUEUED;
 	enqueue_task(rq, p, 0);
+	p->on_rq = TASK_ON_RQ_QUEUED;
 	check_preempt_curr(rq, p, 0);
 
 	return rq;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9a5e60f..7609576 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -740,7 +740,11 @@ static void update_curr_fair(struct rq *rq)
 static inline void
 update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
-	schedstat_set(se->statistics.wait_start, rq_clock(rq_of(cfs_rq)));
+	schedstat_set(se->statistics.wait_start,
+		task_on_rq_migrating(task_of(se)) &&
+		likely(rq_clock(rq_of(cfs_rq)) > se->statistics.wait_start) ?
+		rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start :
+		rq_clock(rq_of(cfs_rq)));
 }
 
 /*
@@ -759,6 +763,13 @@ static void update_stats_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
 static void
 update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
+	if (task_on_rq_migrating(task_of(se))) {
+		schedstat_set(se->statistics.wait_start,
+			  rq_clock(rq_of(cfs_rq)) -
+			  se->statistics.wait_start);
+		return;
+	}
+
 	schedstat_set(se->statistics.wait_max, max(se->statistics.wait_max,
 			rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start));
 	schedstat_set(se->statistics.wait_count, se->statistics.wait_count + 1);
@@ -5656,8 +5667,8 @@ static void detach_task(struct task_struct *p, struct lb_env *env)
 {
 	lockdep_assert_held(>src_rq->lock);
 
-	deactivate_task(env->src_rq, p, 0);
 	p->on_rq = TASK_ON_RQ_MIGRATING;
+	deactivate_task(env->src_rq, p, 0);
 	set_task_cpu(p, env->dst_cpu);
 }
 
@@ -5790,8 +5801,8 @@ static void attach_task(struct rq *rq, struct task_struct *p)
 	lockdep_assert_held(>lock);
 
 	BUG_ON(task_rq(p) != rq);
-	p->on_rq = TASK_ON_RQ_QUEUED;
 	activate_task(rq, p, 0);
+	p->on_rq = TASK_ON_RQ_QUEUED;
 	check_preempt_curr(rq, p, 0);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the 

Re: [PATCH v3 4/7] PCI: Record an fwnode associated with root PCI buses, optionally

[kbuild test robot]

Hi Jake,

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

url:
https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151027-072118
config: powerpc-defconfig (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=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kernel/pci-common.c: In function 'pcibios_scan_phb':
>> arch/powerpc/kernel/pci-common.c:1621:8: error: too few arguments to 
>> function 'pci_create_root_bus'
 bus = pci_create_root_bus(hose->parent, hose->first_busno,
   ^
   In file included from arch/powerpc/kernel/pci-common.c:20:0:
   include/linux/pci.h:791:17: note: declared here
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
^

vim +/pci_create_root_bus +1621 arch/powerpc/kernel/pci-common.c

be8e60d8 Yinghai Lu2012-05-17  1615 hose->busn.start = 
hose->first_busno;
be8e60d8 Yinghai Lu2012-05-17  1616 hose->busn.end   = 
hose->last_busno;
be8e60d8 Yinghai Lu2012-05-17  1617 hose->busn.flags = 
IORESOURCE_BUS;
be8e60d8 Yinghai Lu2012-05-17  1618 pci_add_resource(, 
>busn);
be8e60d8 Yinghai Lu2012-05-17  1619  
0ed2c722 Grant Likely  2009-08-28  1620 /* Create an empty bus for the 
toplevel */
45a709f8 Bjorn Helgaas 2011-10-28 @1621 bus = 
pci_create_root_bus(hose->parent, hose->first_busno,
45a709f8 Bjorn Helgaas 2011-10-28  1622   
hose->ops, hose, );
0ed2c722 Grant Likely  2009-08-28  1623 if (bus == NULL) {
0ed2c722 Grant Likely  2009-08-28  1624 pr_err("Failed to 
create bus for PCI domain %04x\n",

:: The code at line 1621 was first introduced by commit
:: 45a709f890a7b84930942a5f5f82011312fe727c powerpc/PCI: convert to 
pci_create_root_bus()

:: TO: Bjorn Helgaas 
:: CC: Jesse Barnes 

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


.config.gz
Description: Binary data

Re: [PATCH v3 2/5] mtd: mtdpart: Do not fail mtd probe when parsing partitions fails.

[Brian Norris]

On Sun, Oct 11, 2015 at 01:03:47PM -0700, Brian Norris wrote:
> All in all, I think my suggestions would look something like the
> following alternative patch. I haven't tested it yet.
> 
> Brian
> 
> (git-format-patch pasted below)
> 
> From 53b60f31a2a0f2a7e8220a4aff47457248bccbcf Mon Sep 17 00:00:00 2001
> From: Brian Norris 
> Date: Sun, 11 Oct 2015 10:25:23 -0700
> Subject: [PATCH] mtd: mtdpart: Do not fail mtd probe when parsing partitions
>  fails.
> 
> Due to wrong assumption in ofpart ofpart fails on Exynos on SPI chips
> with no partitions because the subnode containing controller data
> confuses the ofpart parser.
> 
> Thus compiling in ofpart support automatically fails probing any SPI NOR
> flash without partitions on Exynos.
> 
> Compiling in a partitioning scheme should not cause probe of otherwise
> valid device to fail.
> 
> Instead, let's do the following:
>  * try parsers until one succeeds
>  * if no parser succeeds, report the first error we saw
>  * even in the failure case, allow MTD to probe, with fallback
>partitions or no partitions at all -- the master device will still be
>registered
> 
> Issue report and comments initially by Michal Suchanek.
> 
> Reported-by: Michal Suchanek 
> Signed-off-by: Brian Norris 
> ---
>  drivers/mtd/mtdcore.c |  6 --
>  drivers/mtd/mtdpart.c | 14 ++
>  2 files changed, 14 insertions(+), 6 deletions(-)

Tested, and applied this version to l2-mtd.git
--
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

[Doug Anderson]

Hi,

On Mon, Oct 26, 2015 at 4:49 PM, Doug Anderson  wrote:
> One note: the "full" PHY reset is actually not in the register map of
> the PHY.  It is amazingly enough in the CRU (clock reset unit).  So if
> we actually exposed the "full" reset through the PHY framework, the
> PHY would then turn around and pass it off to the reset framework,
> which is how the full PHY reset is exposed from the CRU.

Interestingly enough, it looks like there's a reasonable chance that
we won't be able to use the PHY port reset.  We might have to go back
to the full PHY reset (though it causes de-enumeration and
re-enumeration) for safety, since there might be some side effects of
the "phy port reset".

Probably shouldn't land this series until we can figure that out.
...but in that case we still have the question of how we should export
it.  It would certainly be easy to keep using the reset framework...
--
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/

[RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

[Yunhong Jiang]

An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
assigning a device to a guest with low latency requirement since it
reduce the context switch to/from the IRQ thread.

An experiment was conducted on a HSW platform for 1 minutes, with the
guest vCPU bound to isolated pCPU. The assigned device triggered the
interrupt every 1ms. The average EXTERNAL_INTERRUPT exit handling time
is dropped from 5.3us to 2.2us.

Another choice is to change VFIO_DEVICE_SET_IRQS ioctl, to apply this
option only to specific devices when in kernel irq_chip is enabled. It
provides more flexibility but is more complex, not sure if we need go
through that way.

Signed-off-by: Yunhong Jiang 
---
 drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1f577b4..ca1f95a 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -22,9 +22,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vfio_pci_private.h"
 
+static bool nonthread_msi = 1;
+module_param(nonthread_msi, bool, 0444);
+
 /*
  * INTx
  */
@@ -313,6 +317,7 @@ static int vfio_msi_set_vector_signal(struct 
vfio_pci_device *vdev,
char *name = msix ? "vfio-msix" : "vfio-msi";
struct eventfd_ctx *trigger;
int ret;
+   unsigned long irqflags = 0;
 
if (vector >= vdev->num_ctx)
return -EINVAL;
@@ -352,7 +357,10 @@ static int vfio_msi_set_vector_signal(struct 
vfio_pci_device *vdev,
pci_write_msi_msg(irq, );
}
 
-   ret = request_irq(irq, vfio_msihandler, 0,
+   if (nonthread_msi)
+   irqflags = IRQF_NO_THREAD;
+
+   ret = request_irq(irq, vfio_msihandler, irqflags,
  vdev->ctx[vector].name, trigger);
if (ret) {
kfree(vdev->ctx[vector].name);
-- 
1.8.3.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 3/5] mm: clear PG_dirty to mark page freeable

[Hugh Dickins]

On Mon, 19 Oct 2015, Minchan Kim wrote:

> Basically, MADV_FREE relies on dirty bit in page table entry
> to decide whether VM allows to discard the page or not.
> IOW, if page table entry includes marked dirty bit, VM shouldn't
> discard the page.
> 
> However, as a example, if swap-in by read fault happens,
> page table entry doesn't have dirty bit so MADV_FREE could discard
> the page wrongly.
> 
> For avoiding the problem, MADV_FREE did more checks with PageDirty
> and PageSwapCache. It worked out because swapped-in page lives on
> swap cache and since it is evicted from the swap cache, the page has
> PG_dirty flag. So both page flags check effectively prevent
> wrong discarding by MADV_FREE.
> 
> However, a problem in above logic is that swapped-in page has
> PG_dirty still after they are removed from swap cache so VM cannot
> consider the page as freeable any more even if madvise_free is
> called in future.
> 
> Look at below example for detail.
> 
> ptr = malloc();
> memset(ptr);
> ..
> ..
> .. heavy memory pressure so all of pages are swapped out
> ..
> ..
> var = *ptr; -> a page swapped-in and could be removed from
>swapcache. Then, page table doesn't mark
>dirty bit and page descriptor includes PG_dirty
> ..
> ..
> madvise_free(ptr); -> It doesn't clear PG_dirty of the page.
> ..
> ..
> ..
> .. heavy memory pressure again.
> .. In this time, VM cannot discard the page because the page
> .. has *PG_dirty*
> 
> To solve the problem, this patch clears PG_dirty if only the page
> is owned exclusively by current process when madvise is called
> because PG_dirty represents ptes's dirtiness in several processes
> so we could clear it only if we own it exclusively.
> 
> Cc: Hugh Dickins 
> Signed-off-by: Minchan Kim 

Acked-by: Hugh Dickins 

(and patches 1/5 and 2/5 too if you like)

> ---
>  mm/madvise.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index fdfb14a78c60..5db546431285 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -312,11 +312,19 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   if (!page)
>   continue;
>  
> - if (PageSwapCache(page)) {
> + if (PageSwapCache(page) || PageDirty(page)) {
>   if (!trylock_page(page))
>   continue;
> + /*
> +  * If page is shared with others, we couldn't clear
> +  * PG_dirty of the page.
> +  */
> + if (page_count(page) != 1 + !!PageSwapCache(page)) {
> + unlock_page(page);
> + continue;
> + }
>  
> - if (!try_to_free_swap(page)) {
> + if (PageSwapCache(page) && !try_to_free_swap(page)) {
>   unlock_page(page);
>   continue;
>   }
> -- 
> 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/

[PATCH] arm: dts: qcom: Add board clocks

[Stephen Boyd]

These clocks are fixed rate board sources that should be in DT.
Add them.

Cc: Georgi Djakov 
Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-msm8960.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8960.dtsi 
b/arch/arm/boot/dts/qcom-msm8960.dtsi
index 134cd91d68ec..51a40d84145c 100644
--- a/arch/arm/boot/dts/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8960.dtsi
@@ -49,6 +49,29 @@
qcom,no-pc-write;
};
 
+   clocks {
+   cxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   clock-output-names = "cxo_board";
+   };
+
+   pxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2700>;
+   clock-output-names = "pxo_board";
+   };
+
+   sleep_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "sleep_clk";
+   };
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/