Re: [PATCH resend] staging: lustre: osc: clean up whitespace and align function parameters

[Sudip Mukherjee]

On Tue, Jun 02, 2015 at 11:32:19AM -0400, Chris Hanna wrote:
> Signed-off-by: Chris Hanna 
> 
> Minor changes to remove excessive whitespace and improve
> readability of functions.

this description should come above your Signed-off-by line.

regards
sudip
--
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 0/2] Android style loosening of cgroup attach permissions

[Tejun Heo]

Hello, John.

On Tue, Jun 02, 2015 at 12:07:23PM -0700, John Stultz wrote:
> On Wed, May 20, 2015 at 8:41 PM, John Stultz  wrote:
> > As a heads up, this is just a first RFC and not a submission.
> >
> > Android currently loosens the cgroup attchment permissions, allowing
> > tasks with CAP_SYS_NICE to be able to allow tasks to move arbitrary
> > tasks across cgroups.
> >
> > At first glance, overloading CAP_SYS_NICE seems a bit hackish, but this
> > shows that there is a active and widely deployed use for different cgroup
> > attachment rules then what is currently available.
> >
> > I've tried to rework the patches so this attachment policy is build
> > time configurable, and wanted to send them out for review so folks
> > might give their thoughts on this implementation and what they might
> > see as a better way to go about achieving the same goal.
> >
> > Thoughts and feedback would be appriciated!
> 
> Ping? Not sure if I hit folks at a busy time or if I didn't cc the right 
> folks?

Can you explain why this is necessary?  android's cgroups usage is
pretty weird at this point.  IIRC, it moves tasks between fg and bg
cgroups with memory immigration turned on which basically forces memcg
to walk every single page relabeling them on each fg/bg switch, which
is a pretty silly thing to do and for this android kernel also removes
a rcu sync operation which makes break things on removal of cgroups,
which android doesn't do.

memcg usage came up a while ago and there wasn't anything major which
can't be achieved (usually better) by following more standard cgroup
usage - changing knobs rather than moving tasks around.

Given that, I'm not sure this patchset makes sense for upstream.

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] Fix No space after the declaration

[Sudip Mukherjee]

On Wed, Jun 03, 2015 at 10:22:33AM +0530, aparnak wrote:
> Added a new line
> 
> Signed-off-by: aparnak 
Please use your full name in From header and Signed-off-by.
and subject should have been:
[PATCH] staging: lustre: llite: Fix No space after the declaration

regards
sudip
--
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 3/3] AHCI: Add generic MSI-X interrupt support to SATA PCI driver

[Tejun Heo]

Hello, Robert.

Maybe qualifying the subject that it's only for single IRQ would be a
good idea?

> @@ -52,6 +53,7 @@
>  
>  enum {
>   AHCI_PCI_BAR_STA2X11= 0,
> + AHCI_PCI_BAR_CAVIUM = 0,
>   AHCI_PCI_BAR_ENMOTUS= 2,
>   AHCI_PCI_BAR_STANDARD   = 5,

I thought I already asked but please separate out CAVIUM specific
changes from msix implementation and follow up with why cavium depends
on msix support.

> +static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
> +   struct ahci_host_priv *hpriv)
> +{

Please add a comment describing that it's for single msix only and why
that'd be necessary for certain controllers.

...
> + /*
> +  * Per-port msix interrupts are not supported. Assume single
> +  * port interrupts for:
> +  *
> +  *  n_ports == 1, or
> +  *  nvec < n_ports.
> +  *
> +  * We also need to check for n_ports != 0 which is implicitly
> +  * covered here since nvec > 0.
> +  */
> + if (n_ports != 1 && nvec >= n_ports) {
> + rc = -ENOSYS;
> + goto fail;
> + }

Didn't I ask this one too the last time?  Can you explain why we can't
initialize single IRQ mode if nvec >= n_ports?

> @@ -1260,6 +1339,10 @@ static int ahci_init_interrupts(struct pci_dev *pdev, 
> unsigned int n_ports,
>   if (nvec >= 0)
>   return nvec;
>  
> + nvec = ahci_init_msix(pdev, n_ports, hpriv);
> + if (nvec >= 0)
> + return nvec;

Please add a comment explaining why we're doing msix after msi.

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 3/3] xen/block: add multi-page ring support

[Bob Liu]

Extend xen/block to support multi-page ring, so that more requests can be
issued by using more than one pages as the request ring between blkfront
and backend.
As a result, the performance can get improved significantly.

We got some impressive improvements on our highend iscsi storage cluster
backend. If using 64 pages as the ring, the IOPS increased about 15 times
for the throughput testing and above doubled for the latency testing.

The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical
drives, 32 was really not enough to keep them busy.

Changes in v2:
 - Rebased to 4.0-rc6.
 - Document on how multi-page ring feature working to linux io/blkif.h.

Changes in v3:
 - Remove changes to linux io/blkif.h and follow the protocol defined
   in io/blkif.h of XEN tree.
 - Rebased to 4.1-rc3

Changes in v4:
 - Turn to use 'ring-page-order' and 'max-ring-page-order'.
 - A few comments from Roger.

Changes in v5:
 - Clarify with 4k granularity to comment
 - Address more comments from Roger

Signed-off-by: Bob Liu 
---
 drivers/block/xen-blkback/blkback.c |   13 
 drivers/block/xen-blkback/common.h  |2 +
 drivers/block/xen-blkback/xenbus.c  |   89 +--
 drivers/block/xen-blkfront.c|  135 +--
 4 files changed, 180 insertions(+), 59 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 713fc9f..2126842 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,13 @@ MODULE_PARM_DESC(max_persistent_grants,
  "Maximum number of grants to map persistently");
 
 /*
+ * Maximum order of pages to be used for the shared ring between front and
+ * backend, 4KB page granularity is used.
+ */
+unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, 
S_IRUGO);
+MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used for 
the shared ring");
+/*
  * The LRU mechanism to clean the lists of persistent grants needs to
  * be executed periodically. The time interval between consecutive executions
  * of the purge mechanism is set in ms.
@@ -1438,6 +1445,12 @@ static int __init xen_blkif_init(void)
if (!xen_domain())
return -ENODEV;
 
+   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
+   pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
+   xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
+   xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+   }
+
rc = xen_blkif_interface_init();
if (rc)
goto failed_init;
diff --git a/drivers/block/xen-blkback/common.h 
b/drivers/block/xen-blkback/common.h
index 043f13b..8ccc49d 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
 #include 
 #include 
 
+extern unsigned int xen_blkif_max_ring_order;
 /*
  * This is the maximum number of segments that would be allowed in indirect
  * requests. This value will also be passed to the frontend.
@@ -320,6 +321,7 @@ struct xen_blkif {
struct work_struct  free_work;
/* Thread shutdown wait queue. */
wait_queue_head_t   shutdown_wq;
+   unsigned int nr_ring_pages;
 };
 
 struct seg_buf {
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index c212d41..deb3f00 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@
 
 /* Enlarge the array size in order to fully show blkback name. */
 #define BLKBACK_NAME_LEN (20)
+#define RINGREF_NAME_LEN (20)
 
 struct backend_info {
struct xenbus_device*dev;
@@ -156,8 +157,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
return blkif;
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
-unsigned int evtchn)
+static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t *gref,
+unsigned int nr_grefs, unsigned int evtchn)
 {
int err;
 
@@ -165,7 +166,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, 
grant_ref_t gref,
if (blkif->irq)
return 0;
 
-   err = xenbus_map_ring_valloc(blkif->be->dev, , 1,
+   err = xenbus_map_ring_valloc(blkif->be->dev, gref, nr_grefs,
 >blk_ring);
if (err < 0)
return err;
@@ -175,21 +176,21 @@ static int xen_blkif_map(struct xen_blkif *blkif, 
grant_ref_t gref,
{
struct blkif_sring *sring;
sring = (struct blkif_sring *)blkif->blk_ring;
-   BACK_RING_INIT(>blk_rings.native, sring, PAGE_SIZE);
+   BACK_RING_INIT(>blk_rings.native, sring, 

[PATCH 1/3] drivers: xen-blkback: delay pending_req allocation to connect_ring

[Bob Liu]

This is a pre-patch for multi-page ring feature.
In connect_ring, we can know exactly how many pages are used for the shared
ring, delay pending_req allocation here so that we won't waste too much memory.

Signed-off-by: Bob Liu 
---
 drivers/block/xen-blkback/common.h |2 +-
 drivers/block/xen-blkback/xenbus.c |   82 +---
 2 files changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/block/xen-blkback/common.h 
b/drivers/block/xen-blkback/common.h
index f620b5d..043f13b 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -248,7 +248,7 @@ struct backend_info;
 #define PERSISTENT_GNT_WAS_ACTIVE  1
 
 /* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_BLKIF_REQS_PER_PAGE32
 
 struct persistent_gnt {
struct page *page;
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 6ab69ad..c212d41 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -124,8 +124,6 @@ static void xen_update_blkif_status(struct xen_blkif *blkif)
 static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 {
struct xen_blkif *blkif;
-   struct pending_req *req, *n;
-   int i, j;
 
BUILD_BUG_ON(MAX_INDIRECT_PAGES > BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST);
 
@@ -151,51 +149,11 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 
INIT_LIST_HEAD(>pending_free);
INIT_WORK(>free_work, xen_blkif_deferred_free);
-
-   for (i = 0; i < XEN_BLKIF_REQS; i++) {
-   req = kzalloc(sizeof(*req), GFP_KERNEL);
-   if (!req)
-   goto fail;
-   list_add_tail(>free_list,
- >pending_free);
-   for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++) {
-   req->segments[j] = kzalloc(sizeof(*req->segments[0]),
-  GFP_KERNEL);
-   if (!req->segments[j])
-   goto fail;
-   }
-   for (j = 0; j < MAX_INDIRECT_PAGES; j++) {
-   req->indirect_pages[j] = 
kzalloc(sizeof(*req->indirect_pages[0]),
-GFP_KERNEL);
-   if (!req->indirect_pages[j])
-   goto fail;
-   }
-   }
spin_lock_init(>pending_free_lock);
init_waitqueue_head(>pending_free_wq);
init_waitqueue_head(>shutdown_wq);
 
return blkif;
-
-fail:
-   list_for_each_entry_safe(req, n, >pending_free, free_list) {
-   list_del(>free_list);
-   for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++) {
-   if (!req->segments[j])
-   break;
-   kfree(req->segments[j]);
-   }
-   for (j = 0; j < MAX_INDIRECT_PAGES; j++) {
-   if (!req->indirect_pages[j])
-   break;
-   kfree(req->indirect_pages[j]);
-   }
-   kfree(req);
-   }
-
-   kmem_cache_free(xen_blkif_cachep, blkif);
-
-   return ERR_PTR(-ENOMEM);
 }
 
 static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
@@ -312,7 +270,7 @@ static void xen_blkif_free(struct xen_blkif *blkif)
i++;
}
 
-   WARN_ON(i != XEN_BLKIF_REQS);
+   WARN_ON(i != XEN_BLKIF_REQS_PER_PAGE);
 
kmem_cache_free(xen_blkif_cachep, blkif);
 }
@@ -864,7 +822,8 @@ static int connect_ring(struct backend_info *be)
unsigned int evtchn;
unsigned int pers_grants;
char protocol[64] = "";
-   int err;
+   struct pending_req *req, *n;
+   int err, i, j;
 
pr_debug("%s %s\n", __func__, dev->otherend);
 
@@ -905,6 +864,24 @@ static int connect_ring(struct backend_info *be)
ring_ref, evtchn, be->blkif->blk_protocol, protocol,
pers_grants ? "persistent grants" : "");
 
+   for (i = 0; i < XEN_BLKIF_REQS_PER_PAGE; i++) {
+   req = kzalloc(sizeof(*req), GFP_KERNEL);
+   if (!req)
+   goto fail;
+   list_add_tail(>free_list, >blkif->pending_free);
+   for (j = 0; j < MAX_INDIRECT_SEGMENTS; j++) {
+   req->segments[j] = kzalloc(sizeof(*req->segments[0]), 
GFP_KERNEL);
+   if (!req->segments[j])
+   goto fail;
+   }
+   for (j = 0; j < MAX_INDIRECT_PAGES; j++) {
+   req->indirect_pages[j] = 
kzalloc(sizeof(*req->indirect_pages[0]),
+GFP_KERNEL);
+   if (!req->indirect_pages[j])
+   goto fail;
+   }
+   }
+

[PATCH 2/3] driver: xen-blkfront: move talk_to_blkback to a more suitable place

[Bob Liu]

The major responsibility of talk_to_blkback() is allocate and initialize
the request ring and write the ring info to xenstore.
But this work should be done after backend entered 'XenbusStateInitWait' as
defined in the protocol file.
See xen/include/public/io/blkif.h in XEN git tree:
FrontBack
==
XenbusStateInitialising  XenbusStateInitialising
 o Query virtual device   o Query backend device identification
   properties.  data.
 o Setup OS device instance.  o Open and validate backend device.
  o Publish backend features and
transport parameters.
 |
 |
 V
 XenbusStateInitWait

o Query backend features and
  transport parameters.
o Allocate and initialize the
  request ring.

There is no problem with this yet, but it is an violation of the design and
furthermore it would not allow frontend/backend to negotiate 'multi-page'
and 'multi-queue' features.

Changes in v2:
 - Re-write the commit message to be more clear.

Signed-off-by: Bob Liu 
Acked-by: Roger Pau Monné 
---
 drivers/block/xen-blkfront.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c61cf8..88e23fd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1430,13 +1430,6 @@ static int blkfront_probe(struct xenbus_device *dev,
info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
dev_set_drvdata(>dev, info);
 
-   err = talk_to_blkback(dev, info);
-   if (err) {
-   kfree(info);
-   dev_set_drvdata(>dev, NULL);
-   return err;
-   }
-
return 0;
 }
 
@@ -1906,8 +1899,13 @@ static void blkback_changed(struct xenbus_device *dev,
dev_dbg(>dev, "blkfront:blkback_changed to state %d.\n", 
backend_state);
 
switch (backend_state) {
-   case XenbusStateInitialising:
case XenbusStateInitWait:
+   if (talk_to_blkback(dev, info)) {
+   kfree(info);
+   dev_set_drvdata(>dev, NULL);
+   break;
+   }
+   case XenbusStateInitialising:
case XenbusStateInitialised:
case XenbusStateReconfiguring:
case XenbusStateReconfigured:
-- 
1.7.10.4

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

Re: [PATCH v4 2/3] ahci: Store irq number in struct ahci_host_priv

[Tejun Heo]

On Sun, May 31, 2015 at 01:55:18PM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> Currently, ahci supports only msi and intx. To also support msix the
> handling of the irq number need to be changed. The irq number for msix
> devices is taken from msi_list instead of pci_dev. Thus, the irq
> number of a device needs to be stored in struct ahci_host_priv now.
> This allows the host controller to be activated in a generic way.
> 
> This change is only intended for ahci drivers. For that reason the irq
> number is stored in struct ahci_host_priv used only by ahci drivers.
> Thus, the ABI changes only for ahci_host_activate(), but existing ata
> drivers (about 50) are unaffected and keep unchanged. All users of
> ahci_host_activate() have been updated.
> 
> While touching drivers/ata/libahci.c, doing a small code cleanup in
> ahci_port_start().
> 
> Signed-off-by: Robert Richter 

Applied 1-2 to libata/for-4.2.

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: [GIT PULL] phy: for v4.2 merge window

[Kishon Vijay Abraham I]

Hi Greg,

On Wednesday 03 June 2015 10:44 AM, Greg KH wrote:

On Tue, Jun 02, 2015 at 08:13:31PM +0530, Kishon Vijay Abraham I wrote:

Hi Greg,

Here's the PHY pull request for 4.2 merge window. Please find below
the list of changes that goes in this pull request.

There was a merge conflict in Makefile and Kconfig while trying to merge
with your usb-next branch. It's because one of the PHY drivers (TUSB1210)
went via balbi's tree due to it's dependecy with USB_ULPI_BUS and it
conflicts with BRCMSTB_SATA. The resolution should have both TUSB1210 and
BRCMSTB_SATA present.

Let me know If I have to change something.


Nope, that should be fine.  I've pulled and pushed out the tree now,
please verify I did the merge correctly.


The merge was correct.

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

[PATCH v4] Add TI CDCE925 I2C controlled clock synthesizer driver

[Mike Looijmans]

This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver only supports the following setup,
and uses a fixed setting for the output muxes:
  Y1 is derived from the input clock
  Y2 and Y3 derive from PLL1
  Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.

Signed-off-by: Mike Looijmans 
---
v2: Coding style check
Add devicetree binding documentation
v3: Remove clk-private.h and processed M.Turquette's feedback
Use "ti" prefix. Use of_clk_src_onecell_get to register.
v4: Fix dev_dbg format warning on 64-bit systems (as suggested by Paul Bolle)

 .../devicetree/bindings/clock/ti,cdce925.txt   |  42 ++
 drivers/clk/Kconfig|  17 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-cdce925.c  | 749 +
 4 files changed, 809 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti,cdce925.txt
 create mode 100644 drivers/clk/clk-cdce925.c

diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.txt 
b/Documentation/devicetree/bindings/clock/ti,cdce925.txt
new file mode 100644
index 000..4c7669a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,cdce925.txt
@@ -0,0 +1,42 @@
+Binding for TO CDCE925 programmable I2C clock synthesizers.
+
+Reference
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] http://www.ti.com/product/cdce925
+
+The driver provides clock sources for each output Y1 through Y5.
+
+Required properties:
+ - compatible: Shall be "ti,cdce925"
+ - reg: I2C device address.
+ - clocks: Points to a fixed parent clock that provides the input frequency.
+ - #clock-cells: From common clock bindings: Shall be 1.
+
+Optional properties:
+ - xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
+ board, or to compensate for external influences.
+
+For both PLL1 and PLL2 an optional child node can be used to specify spread
+spectrum clocking parameters for a board.
+  - spread-spectrum: SSC mode as defined in the data sheet.
+  - spread-spectrum-center: Use "centered" mode instead of "max" mode. When
+present, the clock runs at the requested frequency on average. Otherwise
+the requested frequency is the maximum value of the SCC range.
+
+
+Example:
+
+   clockgen: cdce925pw@64 {
+   compatible = "cdce925";
+   reg = <0x64>;
+   clocks = <_27Mhz>;
+   #clock-cells = <1>;
+   xtal-load-pf = <5>;
+   /* PLL options to get SSC 1% centered */
+   PLL2 {
+   spread-spectrum = <4>;
+   spread-spectrum-center;
+   };
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9897f35..1c31704 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -78,6 +78,23 @@ config COMMON_CLK_SI570
  This driver supports Silicon Labs 570/571/598/599 programmable
  clock generators.
 
+config COMMON_CLK_CDCE925
+   tristate "Clock driver for TI CDCE925 devices"
+   depends on I2C
+   depends on OF
+   select REGMAP_I2C
+   help
+   ---help---
+ This driver supports the TI CDCE925 programmable clock synthesizer.
+ The chip contains two PLLs with spread-spectrum clocking support and
+ five output dividers. The driver only supports the following setup,
+ and uses a fixed setting for the output muxes.
+ Y1 is derived from the input clock
+ Y2 and Y3 derive from PLL1
+ Y4 and Y5 derive from PLL2
+ Given a target output frequency, the driver will set the PLL and
+ divider to best approximate the desired output.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3d00c25..49d38de 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_COMMON_CLK_RK808)+= clk-rk808.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11)   += clk-s2mps11.o
 obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
 obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
+obj-$(CONFIG_COMMON_CLK_CDCE925)   += clk-cdce925.o
 obj-$(CONFIG_CLK_TWL6040)  += clk-twl6040.o
 obj-$(CONFIG_ARCH_U300)+= clk-u300.o
 obj-$(CONFIG_ARCH_VT8500)  += clk-vt8500.o
diff --git a/drivers/clk/clk-cdce925.c b/drivers/clk/clk-cdce925.c
new file mode 100644
index 000..56b870d
--- /dev/null
+++ b/drivers/clk/clk-cdce925.c
@@ -0,0 +1,749 @@
+/*
+ * Driver for TI Dual PLL CDCE925 clock synthesizer
+ *
+ * This driver always connects the 

Re: Fwd: [RFC] make kthread_worker_fn to be freezable

[Tejun Heo]

On Tue, Jun 02, 2015 at 11:13:44AM +0800, yalin wang wrote:
> this means i need create kthread like this :
> 
> struct task_struct *kworker_task = kthread_run(kthread_worker_fn,
> , "nvme%d", dev->instance);
> kworker_task->flags &= ~PF_NOFREEZE;
> is it safe to do like this ?

It's not.

> i don't see an API to set other thread to be freezable .
> only set_freezable() , which set the current thread to be freezable .

But you can create a wrapper kthread function which sets freezable and
calls kthread_worker_fn().

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: [GIT PULL] phy: for v4.2 merge window

[Greg KH]

On Tue, Jun 02, 2015 at 08:13:31PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Here's the PHY pull request for 4.2 merge window. Please find below
> the list of changes that goes in this pull request.
> 
> There was a merge conflict in Makefile and Kconfig while trying to merge
> with your usb-next branch. It's because one of the PHY drivers (TUSB1210)
> went via balbi's tree due to it's dependecy with USB_ULPI_BUS and it
> conflicts with BRCMSTB_SATA. The resolution should have both TUSB1210 and
> BRCMSTB_SATA present.
> 
> Let me know If I have to change something.

Nope, that should be fine.  I've pulled and pushed out the tree now,
please verify I did the merge correctly.

thanks,

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

[PATCH] of: clean-up unnecessary libfdt include paths

[Rob Herring]

With the latest dtc import include fixups, it is no longer necessary to
add explicit include paths to use libfdt. Remove these across the
kernel.

Signed-off-by: Rob Herring 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Grant Likely 
Cc: linux-m...@linux-mips.org
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/mips/cavium-octeon/Makefile  | 3 ---
 arch/mips/mti-sead3/Makefile  | 2 --
 arch/powerpc/kernel/Makefile  | 1 -
 drivers/firmware/efi/libstub/Makefile | 2 --
 drivers/of/Makefile   | 3 ---
 5 files changed, 11 deletions(-)

diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile
index 69a8a8d..2a59265 100644
--- a/arch/mips/cavium-octeon/Makefile
+++ b/arch/mips/cavium-octeon/Makefile
@@ -9,9 +9,6 @@
 # Copyright (C) 2005-2009 Cavium Networks
 #
 
-CFLAGS_octeon-platform.o = -I$(src)/../../../scripts/dtc/libfdt
-CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt
-
 obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o
 obj-y += dma-octeon.o
 obj-y += octeon-memcpy.o
diff --git a/arch/mips/mti-sead3/Makefile b/arch/mips/mti-sead3/Makefile
index ecd71db..2e52cbd 100644
--- a/arch/mips/mti-sead3/Makefile
+++ b/arch/mips/mti-sead3/Makefile
@@ -15,5 +15,3 @@ obj-y := sead3-lcd.o sead3-display.o 
sead3-init.o \
 obj-y  += leds-sead3.o
 
 obj-$(CONFIG_EARLY_PRINTK) += sead3-console.o
-
-CFLAGS_sead3-setup.o = -I$(src)/../../../scripts/dtc/libfdt
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index c1ebbda..c16e836 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the linux kernel.
 #
 
-CFLAGS_prom.o  = -I$(src)/../../../scripts/dtc/libfdt
 CFLAGS_ptrace.o+= -DUTS_MACHINE='"$(UTS_MACHINE)"'
 
 subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index 280bc0a..816dbe9 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -24,8 +24,6 @@ KASAN_SANITIZE:= n
 lib-y  := efi-stub-helper.o
 lib-$(CONFIG_EFI_ARMSTUB)  += arm-stub.o fdt.o
 
-CFLAGS_fdt.o   += -I$(srctree)/scripts/dtc/libfdt/
-
 #
 # arm64 puts the stub in the kernel proper, which will unnecessarily retain all
 # code indefinitely unless it is annotated as __init/__initdata/__initconst 
etc.
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index fcacb18..156c072 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -16,6 +16,3 @@ obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
 
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
-
-CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt
-CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt
-- 
2.1.0

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

Re: [GIT PULL] extcon next for 4.2

[Greg KH]

On Wed, Jun 03, 2015 at 10:30:35AM +0900, Chanwoo Choi wrote:
> Dear Greg,
> 
> This is extcon-next full request for v4.2. I add detailed description of this
> pull request on below. Please pull extcon with following updates.
> 
> Best Regards,
> Chanwoo Choi
> 
> The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:
> 
>   Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-next-for-4.2

Pulled and pushed out, thanks.

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

Re: [PATCH v1 0/2] scatterlist: introduce sg_nents_for_len

[Herbert Xu]

On Mon, Jun 01, 2015 at 11:15:19AM -0500, Tom Lendacky wrote:
> This series introduces and makes use of a new scatterlist function named
> sg_nents_for_len. The purpose of this function is determine the number
> of scatterlist entries required to satisify a specified length. The
> resulting count can be used as input to the dma_map_sg function to map
> only the entries needed.
> 
> This function is needed for cases where a supplied scatterlist has not
> marked the last filled sg entry as the end of the scatterlist. In these
> cases, the sg_nents function count includes sg entries that may not have
> been filled in. When using this value in a dma_map_sg call it can result
> in errors/bugs being generated.
> 
> The following patches are included in this series:
> - Introduce the sg_nents_for_len function
> - Update the ccp driver to use the sg_nents_for_len function
> 
> This patch series is based on cryptodev-2.6.

Both applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 00/10] zsmalloc auto-compaction

[Sergey Senozhatsky]

On (05/30/15 00:05), Sergey Senozhatsky wrote:
> RFC
> 
> this is 4.3 material, but I wanted to publish it sooner to gain
> responses and to settle it down before 4.3 merge window opens.
> 
> in short, this series tweaks zsmalloc's compaction and adds
> auto-compaction support. auto-compaction is not aimed to replace
> manual compaction, intead it's supposed to be good enough. yet
> it surely slows down zsmalloc in some scenarious. whilst simple
> un-tar test didn't show any significant performance difference
> 
> 
> quote from commit 0007:
> 
> this test copies a 1.3G linux kernel tar to mounted zram disk,
> and extracts it.
> 

[..]


Hello,

I've a v2:
-- squashed and re-order some of the patches;
-- run iozone with lockdep disabled.

=== quote ===

auto-compaction should not affect read-only tests, so we are interested
in write-only and read-write (mixed) tests, but I'll post complete test
stats:

iozone -t 3 -R -r 16K -s 60M -I +Z
ext4, 2g zram0 device, lzo, 4 compression streams max

   test   base   auto-compact (compacted 67904 objs)
   Initial write   2474943.62  2490551.69
 Rewrite   3656121.38  3002796.31
Read   12068187.50 12044105.25
 Re-read   12009777.25 11930537.50
Reverse Read   10858884.25 10388252.50
 Stride read   10715304.75 10429308.00
 Random read   10597970.50 10502978.75
  Mixed workload   8517269.00  8701298.12
Random write   3595597.00  3465174.38
  Pwrite   2507361.25  2553224.50
   Pread   5380608.28  5340646.03
  Fwrite   6123863.62  6130514.25
   Fread   12006438.50 11936981.25

mm_stat after the test

base:
cat /sys/block/zram0/mm_stat
378834944  5748695  74465280  7450624163180

auto-compaction:
cat /sys/block/zram0/mm_stat
378892288  5754987  73973760  73973761630467904

===

-ss

> 
> 
> Sergey Senozhatsky (10):
>   zsmalloc: drop unused variable `nr_to_migrate'
>   zsmalloc: always keep per-class stats
>   zsmalloc: introduce zs_can_compact() function
>   zsmalloc: cosmetic compaction code adjustments
>   zsmalloc: add `num_migrated' to zs_pool
>   zsmalloc: move compaction functions
>   zsmalloc: introduce auto-compact support
>   zsmalloc: export zs_pool `num_migrated'
>   zram: remove `num_migrated' from zram_stats
>   zsmalloc: lower ZS_ALMOST_FULL waterline
> 
>  drivers/block/zram/zram_drv.c |  12 +-
>  drivers/block/zram/zram_drv.h |   1 -
>  include/linux/zsmalloc.h  |   1 +
>  mm/zsmalloc.c | 578 
> +-
>  4 files changed, 296 insertions(+), 296 deletions(-)
> 
> -- 
> 2.4.2.337.gfae46aa
> 
--
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] crypto: prevent nx 842 load if no hw driver

[Herbert Xu]

On Thu, May 28, 2015 at 04:21:31PM -0400, Dan Streetman wrote:
> Change the nx-842 common driver to wait for loading of both platform
> drivers, and fail loading if the platform driver pointer is not set.
> Add an independent platform driver pointer, that the platform drivers
> set if they find they are able to load (i.e. if they find their platform
> devicetree node(s)).
> 
> The problem is currently, the main nx-842 driver will stay loaded even
> if there is no platform driver and thus no possible way it can do any
> compression or decompression.  This allows the crypto 842-nx driver
> to load even if it won't actually work.  For crypto compression users
> (e.g. zswap) that expect an available crypto compression driver to
> actually work, this is bad.  This patch fixes that, so the 842-nx crypto
> compression driver won't load if it doesn't have the driver and hardware
> available to perform the compression.
> 
> Signed-off-by: Dan Streetman 

Applied.  Though I had to do the Makefile bit by hand because
it contains references to nx-compress-test which doesn't exist
in my tree.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] powerpc/eeh: Fix trivial error in eeh_restore_dev_state()

[Guo Wen Shan]

David Gibson  wrote on 03/06/2015 14:52:59:

> From: David Gibson 
> To: Guo Wen Shan/Australia/IBM@IBMAU, m...@ellerman.id.au
> Cc: b...@kernel.crashing.org, pau...@samba.org, linuxppc-
> d...@lists.ozlabs.org, linux-kernel@vger.kernel.org, David Gibson
> 
> Date: 03/06/2015 14:53
> Subject: [PATCH] powerpc/eeh: Fix trivial error in eeh_restore_dev_state
()
>
> Commit 28158cd "powerpc/eeh: Enhance pcibios_set_pcie_reset_state()"
> introduced a fix for a problem where certain configurations could lead to
> pci_reset_function() destroying the state of PCI devices other than the
one
> specified.
>
> Unfortunately, the fix has a trivial bug - it calls pci_save_state()
again,
> when it should be calling pci_restore_state().  This corrects the
problem.
>
> Cc: Gavin Shan 
> Signed-off-by: David Gibson 

Acked-by: Gavin Shan 

Thanks,
Gavin

> ---
>  arch/powerpc/kernel/eeh.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> index 9ee61d1..ece4181 100644
> --- a/arch/powerpc/kernel/eeh.c
> +++ b/arch/powerpc/kernel/eeh.c
> @@ -719,7 +719,7 @@ static void *eeh_restore_dev_state(void *data,
> void *userdata)
>
> /* The caller should restore state for the specified device */
> if (pdev != dev)
> -  pci_save_state(pdev);
> +  pci_restore_state(pdev);
>
> return NULL;
>  }
> --
> 2.4.2
>

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

Re: [RFC 2/4] mm/balloon: apply driver page migratable into balloon driver

[Gioh Kim]

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim  wrote:

Apply driver page migration into balloon driver.

Signed-off-by: Gioh Kim 
---
  drivers/virtio/virtio_balloon.c|  2 ++
  fs/proc/page.c |  4 +--
  include/linux/balloon_compaction.h | 42 ---
  include/linux/mm.h | 19 ---
  include/uapi/linux/kernel-page-flags.h |  2 +-
  mm/balloon_compaction.c| 61 --
  6 files changed, 94 insertions(+), 36 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 6a356e3..cdd0038 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -496,6 +496,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
 balloon_devinfo_init(>vb_dev_info);
  #ifdef CONFIG_BALLOON_COMPACTION
 vb->vb_dev_info.migratepage = virtballoon_migratepage;
+   vb->vb_dev_info.mapping = balloon_mapping_alloc(>vb_dev_info,
+   _aops);
  #endif

 err = init_vqs(vb);
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8..e741307 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -143,8 +143,8 @@ u64 stable_page_flags(struct page *page)
 if (PageBuddy(page))
 u |= 1 << KPF_BUDDY;

-   if (PageBalloon(page))
-   u |= 1 << KPF_BALLOON;
+   if (PageMigratable(page))
+   u |= 1 << KPF_MIGRATABLE;

 u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);

diff --git a/include/linux/balloon_compaction.h 
b/include/linux/balloon_compaction.h
index 9b0a15d..0989e96 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -48,6 +48,7 @@
  #include 
  #include 
  #include 
+#include 

  /*
   * Balloon device information descriptor.
@@ -62,6 +63,7 @@ struct balloon_dev_info {
 struct list_head pages; /* Pages enqueued & handled to Host */
 int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
 struct page *page, enum migrate_mode mode);
+   struct address_space *mapping;
  };

  extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -73,24 +75,37 @@ static inline void balloon_devinfo_init(struct 
balloon_dev_info *balloon)
 spin_lock_init(>pages_lock);
 INIT_LIST_HEAD(>pages);
 balloon->migratepage = NULL;
+   balloon->mapping = NULL;
  }

  #ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
+extern const struct address_space_operations balloon_aops;
+extern bool balloon_page_isolate(struct page *page,
+isolate_mode_t mode);
  extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
+extern int balloon_page_migrate(struct address_space *mapping,
+   struct page *newpage,
 struct page *page, enum migrate_mode mode);

+extern struct address_space
+*balloon_mapping_alloc(struct balloon_dev_info *b_dev_info,
+  const struct address_space_operations *a_ops);
+
+static inline void balloon_mapping_free(struct address_space *balloon_mapping)
+{
+   kfree(balloon_mapping);
+}
+
  /*
- * __is_movable_balloon_page - helper to perform @page PageBalloon tests
+ * __is_movable_balloon_page - helper to perform @page PageMigratable tests
   */
  static inline bool __is_movable_balloon_page(struct page *page)
  {
-   return PageBalloon(page);
+   return PageMigratable(page);
  }

  /*
- * balloon_page_movable - test PageBalloon to identify balloon pages
+ * balloon_page_movable - test PageMigratable to identify balloon pages
   *   and PagePrivate to check that the page is not
   *   isolated and can be moved by compaction/migration.
   *
@@ -99,7 +114,7 @@ static inline bool __is_movable_balloon_page(struct page 
*page)
   */
  static inline bool balloon_page_movable(struct page *page)
  {
-   return PageBalloon(page) && PagePrivate(page);
+   return PageMigratable(page) && PagePrivate(page);
  }

  /*
@@ -108,7 +123,7 @@ static inline bool balloon_page_movable(struct page *page)
   */
  static inline bool isolated_balloon_page(struct page *page)
  {
-   return PageBalloon(page);
+   return PageMigratable(page);
  }

  /*
@@ -123,7 +138,8 @@ static inline bool isolated_balloon_page(struct page *page)
  static inline void balloon_page_insert(struct balloon_dev_info *balloon,
struct page *page)
  {
-   __SetPageBalloon(page);
+   page->mapping = balloon->mapping;
+   __SetPageMigratable(page);
 SetPagePrivate(page);
 set_page_private(page, (unsigned long)balloon);
 list_add(>lru, >pages);
@@ -139,7 +155,8 @@ static inline void 

Re: [RFC][PATCH 7/7] sched,dl: Convert switched_{from,to}_dl() / prio_changed_dl() to balance callbacks

[Kamalesh Babulal]

* Peter Zijlstra  [2015-06-01 15:58:25]:

[...]

>  
> -static DEFINE_PER_CPU(struct callback_head, dl_balance_head);
> +static DEFINE_PER_CPU(struct callback_head, dl_push_head);
> +static DEFINE_PER_CPU(struct callback_head, dl_pull_head);
>  
>  static void push_dl_tasks(struct rq *);
> +static void pull_dl_task(struct rq *);
>  
>  static inline void queue_push_tasks(struct rq *rq)
>  {
>   if (!has_pushable_dl_tasks(rq))
>   return;
>  
> - queue_balance_callback(rq, _cpu(dl_balance_head, rq->cpu), 
> push_dl_tasks);
> + queue_balance_callback(rq, _cpu(dl_push_head, rq->cpu), 
> push_dl_tasks);
> +}
> +
> +static inline void queue_pull_task(struct rq *rq)
> +{
> + queue_balance_callback(rq, _cpu(dl_pull_head, rq->cpu), 
> pull_dl_task);
>  }

queue_pull_task() is not defined for CONFIG_SMP=n case, following build error
is seen while building the kernel with SMP=n:

  CC  kernel/sched/deadline.o
kernel/sched/deadline.c: In function ‘switched_from_dl’:
kernel/sched/deadline.c:1713:2: error: implicit declaration of function 
‘queue_pull_task’ [-Werror=implicit-function-declaration]
  queue_pull_task(rq);
  ^
cc1: some warnings being treated as errors

Thanks,
Kamalesh.

--
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] powerpc/eeh: Fix trivial error in eeh_restore_dev_state()

[David Gibson]

Commit 28158cd "powerpc/eeh: Enhance pcibios_set_pcie_reset_state()"
introduced a fix for a problem where certain configurations could lead to
pci_reset_function() destroying the state of PCI devices other than the one
specified.

Unfortunately, the fix has a trivial bug - it calls pci_save_state() again,
when it should be calling pci_restore_state().  This corrects the problem.

Cc: Gavin Shan 
Signed-off-by: David Gibson 
---
 arch/powerpc/kernel/eeh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 9ee61d1..ece4181 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -719,7 +719,7 @@ static void *eeh_restore_dev_state(void *data, void 
*userdata)
 
/* The caller should restore state for the specified device */
if (pdev != dev)
-   pci_save_state(pdev);
+   pci_restore_state(pdev);
 
return NULL;
 }
-- 
2.4.2

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

[PATCH] Fix No space after the declaration

[aparnak]

Added a new line

Signed-off-by: aparnak 
---
 drivers/staging/lustre/lustre/llite/llite_capa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lustre/llite/llite_capa.c 
b/drivers/staging/lustre/lustre/llite/llite_capa.c
index aec9a44..a626871 100644
--- a/drivers/staging/lustre/lustre/llite/llite_capa.c
+++ b/drivers/staging/lustre/lustre/llite/llite_capa.c
@@ -140,6 +140,7 @@ static void sort_add_capa(struct obd_capa *ocapa, struct 
list_head *head)
 static inline int obd_capa_open_count(struct obd_capa *oc)
 {
struct ll_inode_info *lli = ll_i2info(oc->u.cli.inode);
+
return atomic_read(>lli_open_count);
 }
 
-- 
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: [RFC][PATCH 1/7] sched: Replace post_schedule with a balance callback list

[Kamalesh Babulal]

* Peter Zijlstra  [2015-06-01 15:58:19]:

[...]

> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -213,9 +213,16 @@ static inline bool need_pull_dl_task(str
>   return dl_task(prev);
>  }
>  
> -static inline void set_post_schedule(struct rq *rq)
> +static DEFINE_PER_CPU(struct callback_head, dl_balance_head);
> +
> +static void push_dl_tasks(struct rq *);
> +
> +static inline void queue_push_tasks(struct rq *rq)
>  {
> - rq->post_schedule = has_pushable_dl_tasks(rq);
> + if (!has_pushable_dl_tasks(rq))
> + return;
> +
> + queue_balance_callback(rq, _cpu(dl_balance_head, rq->cpu), 
> push_dl_tasks);
>  }

When compiling with CONFIG_SMP=n, following build warning is triggered:
  CC  kernel/sched/deadline.o
kernel/sched/deadline.c: In function ‘pick_next_task_dl’:
kernel/sched/deadline.c:1136:2: error: implicit declaration of function 
‘queue_push_tasks’ [-Werror=implicit-function-declaration]
  queue_push_tasks(rq);
  ^
cc1: some warnings being treated as errors

set_post_schedule() exist for CONFIG_SMP=n case, which was not modified to
queue_push_tasks().

[...]
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -624,9 +624,10 @@ struct rq {
>   unsigned long cpu_capacity;
>   unsigned long cpu_capacity_orig;
>  
> + struct callback_head *balance_callback;
> +
>   unsigned char idle_balance;
>   /* For active balancing */
> - int post_schedule;
>   int active_balance;
>   int push_cpu;
>   struct cpu_stop_work active_balance_work;
> @@ -695,6 +696,21 @@ struct rq {
>  #endif
>  };
>  
> +static inline void
> +queue_balance_callback(struct rq *rq,
> +struct callback_head *head,
> +void (*func)(struct rq *rq))
> +{
> + lockdep_assert_held(>lock);
> +
> + if (unlikely(head->next))
> + return;
> +
> + head->func = (void (*)(struct callback_head *))func;
> + head->next = rq->balance_callback;
> + rq->balance_callback = head;
> +}
> +

While compiling with CONFIG_SMP=n, another build error is seen:

In file included from kernel/sched/core.c:86:0:
kernel/sched/sched.h: In function ‘queue_balance_callback’:
kernel/sched/sched.h:710:17: error: ‘struct rq’ has no member named 
‘balance_callback’
  head->next = rq->balance_callback;
 ^
kernel/sched/sched.h:711:4: error: ‘struct rq’ has no member named 
‘balance_callback’
  rq->balance_callback = head;
^

Guarding queue_balance_callback() with #ifdef CONFIG_SMP fixes
the issue, as all of the call sites are also with #ifdef  CONFIG_SMP

Thanks,
Kamalesh

--
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] ASoC: qcom: Remove QCOM dependency from LPASS variants

[Kenneth Westfield]

From: Kenneth Westfield 

Building with the following config options ...

 CONFIG_COMPILE_TEST=y
 # CONFIG_SND_SOC_QCOM is not set
 CONFIG_SND_SOC_LPASS_IPQ806X=m
 CONFIG_SND_SOC_STORM=m

... causes the following build warning:

 warning: (SND_SOC_STORM) selects SND_SOC_LPASS_IPQ806X
 which has unmet direct dependencies (SOUND && !M68K &&
 !UML && SND && SND_SOC && SND_SOC_QCOM)

To fix this, the dependency on SND_SOC_QCOM from the
user-invisible LPASS variant config options has been
removed.  This will allow for successful randconfig
builds that use COMPILE_TEST.

Reported-by: Jim Davis 
Fixes: dc1ebd1811e9 ("ASoC: qcom: Add apq8016 lpass driver support")
Fixes: 9bae4880acee ("ASoC: qcom: move ipq806x specific bits out of lpass
driver")
Signed-off-by: Kenneth Westfield 
---

 Created fix in response to Jim's bug report:
 http://mailman.alsa-project.org/pipermail/alsa-devel/2015-May/092870.html
 
 sound/soc/qcom/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 938144c..290b056 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -14,13 +14,11 @@ config SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on SND_SOC_QCOM
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on SND_SOC_QCOM
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
-- 
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/

Re: [PATCH 03/36] mmu_notifier: pass page pointer to mmu_notifier_invalidate_page()

[John Hubbard]

On Thu, 21 May 2015, j.gli...@gmail.com wrote:

> From: Jérôme Glisse 
> 
> Listener of mm event might not have easy way to get the struct page
> behind and address invalidated with mmu_notifier_invalidate_page()

s/behind and address/behind an address/

> function as this happens after the cpu page table have been clear/
> updated. This happens for instance if the listener is storing a dma
> mapping inside its secondary page table. To avoid complex reverse
> dma mapping lookup just pass along a pointer to the page being
> invalidated.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  drivers/infiniband/core/umem_odp.c | 1 +
>  drivers/iommu/amd_iommu_v2.c   | 1 +
>  drivers/misc/sgi-gru/grutlbpurge.c | 1 +
>  drivers/xen/gntdev.c   | 1 +
>  include/linux/mmu_notifier.h   | 6 +-
>  mm/mmu_notifier.c  | 3 ++-
>  mm/rmap.c  | 4 ++--
>  virt/kvm/kvm_main.c| 1 +
>  8 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/infiniband/core/umem_odp.c 
> b/drivers/infiniband/core/umem_odp.c
> index 8f7f845..d10dd88 100644
> --- a/drivers/infiniband/core/umem_odp.c
> +++ b/drivers/infiniband/core/umem_odp.c
> @@ -166,6 +166,7 @@ static int invalidate_page_trampoline(struct ib_umem 
> *item, u64 start,
>  static void ib_umem_notifier_invalidate_page(struct mmu_notifier *mn,
>struct mm_struct *mm,
>unsigned long address,
> +  struct page *page,
>enum mmu_event event)
>  {
>   struct ib_ucontext *context = container_of(mn, struct ib_ucontext, mn);
> diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
> index 4aa4de6..de3c540 100644
> --- a/drivers/iommu/amd_iommu_v2.c
> +++ b/drivers/iommu/amd_iommu_v2.c
> @@ -385,6 +385,7 @@ static int mn_clear_flush_young(struct mmu_notifier *mn,
>  static void mn_invalidate_page(struct mmu_notifier *mn,
>  struct mm_struct *mm,
>  unsigned long address,
> +struct page *page,
>  enum mmu_event event)
>  {
>   __mn_flush_page(mn, address);
> diff --git a/drivers/misc/sgi-gru/grutlbpurge.c 
> b/drivers/misc/sgi-gru/grutlbpurge.c
> index 44b41b7..c7659b76 100644
> --- a/drivers/misc/sgi-gru/grutlbpurge.c
> +++ b/drivers/misc/sgi-gru/grutlbpurge.c
> @@ -250,6 +250,7 @@ static void gru_invalidate_range_end(struct mmu_notifier 
> *mn,
>  
>  static void gru_invalidate_page(struct mmu_notifier *mn, struct mm_struct 
> *mm,
>   unsigned long address,
> + struct page *page,
>   enum mmu_event event)
>  {
>   struct gru_mm_struct *gms = container_of(mn, struct gru_mm_struct,
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 0e8aa12..90693ce 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -485,6 +485,7 @@ static void mn_invl_range_start(struct mmu_notifier *mn,
>  static void mn_invl_page(struct mmu_notifier *mn,
>struct mm_struct *mm,
>unsigned long address,
> +  struct page *page,
>enum mmu_event event)
>  {
>   struct mmu_notifier_range range;
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index ada3ed1..283ad26 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -172,6 +172,7 @@ struct mmu_notifier_ops {
>   void (*invalidate_page)(struct mmu_notifier *mn,
>   struct mm_struct *mm,
>   unsigned long address,
> + struct page *page,
>   enum mmu_event event);
>  
>   /*
> @@ -290,6 +291,7 @@ extern void __mmu_notifier_change_pte(struct mm_struct 
> *mm,
> enum mmu_event event);
>  extern void __mmu_notifier_invalidate_page(struct mm_struct *mm,
> unsigned long address,
> +   struct page *page,
> enum mmu_event event);
>  extern void __mmu_notifier_invalidate_range_start(struct mm_struct *mm,
> struct mmu_notifier_range 
> *range);
> @@ -338,10 +340,11 @@ static inline void mmu_notifier_change_pte(struct 
> mm_struct *mm,
>  
>  static inline void mmu_notifier_invalidate_page(struct mm_struct *mm,
>   unsigned long address,
> + struct page *page,
>   enum mmu_event event)
>  {
>   if (mm_has_notifiers(mm))
> - __mmu_notifier_invalidate_page(mm, address, 

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Linus Torvalds]

On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner  wrote:
>
> Is there really no smarter way to figure out the TSC frequency on
> modern systems?

Sadly, if there is, we have yet to find it.

I don't think the mentioned intel_pstate thing gets it right either.
Yes, it gets some "theoretical frequency", given the pstate and the
scaling factor, but that assumes the base clock (BCLK) is something
trustworthy. That's a big assumption, and I can pretty much guarantee
it's not a valid assumption.

I'm sure that's the *common* case, but how much do you want to bet
that some motherboard makers noticed that they get good press from
good benchmark numbers, and that they can tweak BCLK a bit higher than
the competition? "Oooh, motherboard from Xyz is really good, it's 1%
faster than the competition".

Or all those overclockers? Yes, some of them buy unlocked CPU's and
leave BCLK alone. Or maybe they do both. Or maybe they just buy locked
CPU's and tweak BCLK.

The only *well-defined* clock in a modern PC seems to still remain the
PIT. Yes, it's very sad.  But all the other clocks tend to be
untrustworthy for various reasons, like "frequency is stated in the
ACPI tables", which we know is basically just a fantasy that may be
right *most* of the time, but I can almost guarantee that some BIOS
guys decided that they can get slightly better random benchmark
numbers by "tweaking" the truth a bit. It's the "BIOS version" of
overclocking by increasing BCLK - lie about the PM frequency, so that
any benchmark that times things that way will give better numbers..

But pretty much nobody messes up the PIT. That will change, just
because it's clearly getting to the point where people are just
emulating it, and it's probably not going to be any more trustworthy
than anything else.

So rather than get a new and truly trustworthy reference clock, the
patch makes me suspect we're losing the old one...

  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: [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses

[Guenter Roeck]

On 06/02/2015 07:31 PM, Chris Healy wrote:

Guenter,

That's a very valid concern.  I have a configuration with a 6352 controlled by 
a low end ARM core with a 100mbps connection on the CPU port.  This switch 
needs to support passing multicast streams that are more than 100mbps on GigE 
links.  (The ARM does not need to consume the multicast, it just manages the 
switch.)



Possibly, but Vivien didn't answer my question (how the local SA address finds
its way into the switch fdb). I'll check it myself.

Thanks,
Guenter


On Jun 3, 2015 3:24 AM, "Guenter Roeck" mailto:li...@roeck-us.net>> wrote:

On Tue, Jun 02, 2015 at 09:06:15PM -0400, Vivien Didelot wrote:
 > Hi Guenter,
 >
 > On Jun 2, 2015, at 10:24 AM, Guenter Roeck li...@roeck-us.net 
 wrote:
 > On 06/01/2015 06:27 PM, Vivien Didelot wrote:
 > >> This commit disables SA learning and refreshing for the CPU port.
 > >>
 > >
 > > Hi Vivien,
 > >
 > > This patch also seems to be unrelated to the rest of the series.
 > >
 > > Can you add an explanation why it is needed ?
 > >
 > > With this in place, how does the CPU port SA find its way into the fdb 
?
 > > Do we assume that it will be configured statically ?
 > > An explanation might be useful.
 >
 > Without this patch, I noticed the CPU port was stealing the SA of a PC
 > behind a switch port. this happened when the port was a bridge member,
 > as the bridge was relaying broadcast coming from one switch port to the
 > other switch ports in the same vlan.
 >
Makes me feel really uncomfortable. I think we may be going into the wrong
direction. The whole point of offloading bridging is to have the switch 
handle
forwarding, and that includes multicasts and broadcasts. Instead of doing 
that,
it looks like we put more and more workarounds in place.

Maybe the software bridge code needs to understand that it isn't support to
forward broadcasts to ports of an offloaded bridge, and we should let the
switch chip handle it ?

Thanks,
Guenter



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

Re: [PATCH 0/3] GPIO support for BRCMSTB

[Gregory Fong]

On Tue, Jun 2, 2015 at 2:05 AM, Linus Walleij  wrote:
> On Wed, May 27, 2015 at 5:26 AM, Gregory Fong  wrote:
>> I've now actually attempted to use the gpiolib irqchip code.  This
>> driver can't directly use gpiochip_irqchip_add() because of the
>> multiple gpiochip : one irqchip map.  At first, I thought it might be
>> possible to simply add a new argument (or break things into a helper
>> function) to allow setting the associated IRQ domain, but then I can't
>> use the generic map and unmap functions which expect the irq_domain
>> host_data member to be struct gpiochip *, which makes no sense in this
>> case.  That puts me right back to implementing a special version of
>> the map and unmap function.
>
> I see.
>

I think I was wrong, it isn't actually necessary to have a single
irq_chip as long as all of the IRQs use the same handler.  I have a
preliminary implementation doing that instead that seems to work fine.
Once I've had a chance to verify that it works in all cases, will post
that as v3.

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

Re: linux-next: manual merge of the drivers-x86 tree with Linus' tree

[Stephen Rothwell]

Hi Darren,

On Tue, 2 Jun 2015 20:27:50 -0700 Darren Hart  wrote:
>
> Thanks for the heads' up. This happens because my -next branch is based on 
> *-rc1
> as I think was recommended at the last kernel summit. Since rc1 I sent Linus 
> the
> G50-30, but by rc6 I didn't feel good about sending the similar G50-30 fix, so
> that is in my rc1 branch.
> 
> I am happy to rebase my -next on rc6 to avoid the conflict, but I believe the
> rebase is considered poor practice.

This is a fairly trivial conflict and Linus will have no trouble fixing
it up as well when he merges your tree in the next window

> You said no action required, but if there is something I can do to avoid this
> kind of manual effort on your part (and a manual merge by Linus in the 
> upcoming
> merge window), I'm happy to update my process to accommodate.

This is fine.  git rerere remembers these conflict resolutions for me,
so I only have to fix them once (usually).

For a more complex conflict, you might consider merging the branch that
you had Linus merge (or a later -rc) with, of course, a nice
explanation in the merge commit message, but in this case that would be
overkill.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpiKDzycOKL1.pgp
Description: OpenPGP digital signature

Re: [PATCH] MAINTAINERS: add zpool

[Sergey Senozhatsky]

On (06/02/15 14:30), Joe Perches wrote:
> > >> +ZPOOL COMPRESSED PAGE STORAGE API
> > >> +M:   Dan Streetman 
> > >> +L:   linux...@kvack.org
> > >> +S:   Maintained
> > >> +F:   mm/zpool.c
> > >> +F:   include/linux/zpool.h
> > >
> > > If zpool.h is only included from files in mm/,
> > > maybe zpool.h should be moved to mm/ ?
> > 
> > It *could* be included by others, e.g. drivers/block/zram.
> > 
> > It currently is only used by zswap though, so yeah it could be moved
> > to mm/.  Should I move it there, until (if ever) anyone outside of mm/
> > wants to use it?
> 
> Up to you.
> 
> I think include/linux is a bit overstuffed and
> whatever can be include local should be.
> 

Hi,

I agree, can be local for now. if zram will ever want to use zpool
then we will move zpool.h to include/linux. just my 5 cents.

-ss
--
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 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Darren Hart]

On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > Until now module dell-laptop registered rfkill device which used i8042
> > filter function for receiving HW switch rfkill events (handling special
> > keycode).
> > 
> > But for some dell laptops there is native ACPI driver dell-rbtn which can
> > receive rfkill events (without i8042 hooks).
> > 
> > So this patch will combine best from both sides. It will use native ACPI
> > driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> > enabling or disabling radio devices. If ACPI driver or device will not be
> > available fallback to i8042 filter function will be used.
> > 
> > Patch also changes module_init() to late_initcall() to ensure that init
> > function will be called after initializing dell-rbtn.c driver.
> > 
> > Signed-off-by: Pali Rohár 
> > Tested-by: Gabriele Mazzotta 
> > Signed-off-by: Darren Hart 
> 
> 
> Several basic checkpatch.pl errors in this one. Please always run 
> checkpatch.pl
> before submitting patches, these sorts of issues should be caught before 
> hitting
> the mailing list.
> 
> Please provide some details on the scenarios you have tested to verify you 
> have
> addressed the build and runtime issues reported.
> 

Checking in so this doesn't fall through the cracks. Do you have a v5 in the
works for the 4.2 merge window?

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
--
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] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

[Pan Xinhui]

hello tianyu
sorry for mistake, this issue did not happened in the latest codes.
thanks for your reply.
I noticed this panic is already fixed, so I port upstream patch into intel's 
branch. see https://android.intel.com/#/c/374113/

thanks,
xinhui

On 2015年06月03日 11:23, Lan Tianyu wrote:

On 2015年05月28日 14:33, Pan, XinhuiX wrote:

acpi_os_wait_semaphore can be called in local/hard irq disabled path. like in 
cpu up/down callback.
So when dirver try to acquire the semaphore, current code may call down_wait 
which might sleep.
Then hit panic as we can't schedule here. So introduce acpi_os_down_wait to 
cover such case.
acpi_os_down_wait use down_trylock, and use cpu_relax to wait the semaphore 
signalled if preempt is disabled.

below is the panic.


Hi Xinhui:

Does this issue happen in the latest upstream kernel?
In the latest code, acpi_cpu_soft_notify() doesn't detail with CPU_DYING
event and return directly. The issue should not take place.



[ 1148.230132, 1]smpboot: CPU 3 is now offline
[ 1148.277288, 0]smpboot: CPU 2 is now offline
[ 1148.322385, 1]BUG: scheduling while atomic: migration/1/13/0x0002
[ 1148.329604, 1]Modules linked in: hid_sensor_hub sens_col_core hid_heci_ish 
heci_ish heci vidt_driver atomisp_css2401a0_v21 lm3642 8723bs(O) cfg80211 
gc2235 bt_lpm videobuf_vmalloc 6lowpan_iphc ip6table_raw iptable_raw 
videobuf_core rfkill_gpio atmel_mxt_ts
[ 1148.355276, 1]CPU: 1 PID: 13 Comm: migration/1 Tainted: GW  O 
3.14.37-x86_64-L1-R409-g73e8207 #25
[ 1148.365983, 1]Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Cherry 
Trail CR, BIOS CH2TCR.X64.0004.R48.1504211851 04/21/2015
[ 1148.379397, 1] 880077801140 880073233a58 819eec6c 
8800732303d0
[ 1148.387914, 1] 880073233a70 819eb0e0 88007ac92240 
880073233ad0
[ 1148.396430, 1] 819f790a 8800732303d0 880073233fd8 
00012240
[ 1148.404948, 1]Call Trace:
[ 1148.407912, 1] [] dump_stack+0x4e/0x7a
[ 1148.413872, 1] [] __schedule_bug+0x58/0x67
[ 1148.420219, 1] [] __schedule+0x67a/0x7b0
[ 1148.426369, 1] [] schedule+0x29/0x70
[ 1148.432123, 1] [] schedule_timeout+0x269/0x310
[ 1148.438860, 1] [] ? update_group_power+0x16c/0x260
[ 1148.445988, 1] [] __down_common+0x91/0xd6
[ 1148.452236, 1] [] ? update_cfs_rq_blocked_load+0xc0/0x130
[ 1148.460036, 1] [] __down_timeout+0x16/0x18
[ 1148.466380, 1] [] down_timeout+0x4c/0x60
[ 1148.472534, 1] [] acpi_os_wait_semaphore+0x43/0x57
[ 1148.479658, 1] [] acpi_ut_acquire_mutex+0x48/0x88
[ 1148.486683, 1] [] ? acpi_match_device+0x4d/0x4d
[ 1148.493516, 1] [] acpi_get_data+0x35/0x77
[ 1148.499761, 1] [] acpi_bus_get_device+0x21/0x3e
[ 1148.506593, 1] [] acpi_cpu_soft_notify+0x3d/0xd3
[ 1148.513522, 1] [] notifier_call_chain+0x53/0xa0
[ 1148.520356, 1] [] ? cpu_stop_park+0x51/0x70
[ 1148.526801, 1] [] __raw_notifier_call_chain+0xe/0x10
[ 1148.534118, 1] [] cpu_notify+0x23/0x50
[ 1148.540075, 1] [] take_cpu_down+0x27/0x40
[ 1148.546322, 1] [] multi_cpu_stop+0xc1/0x110
[ 1148.552763, 1] [] ? cpu_stop_should_run+0x50/0x50
[ 1148.559776, 1] [] cpu_stopper_thread+0x78/0x150
[ 1148.566608, 1] [] ? _raw_spin_unlock_irq+0x1e/0x40
[ 1148.573730, 1] [] ? finish_task_switch+0x57/0xd0
[ 1148.580646, 1] [] ? __schedule+0x37e/0x7b0
[ 1148.586991, 1] [] smpboot_thread_fn+0x17d/0x2b0
[ 1148.593819, 1] [] ? SyS_setgroups+0x160/0x160
[ 1148.600455, 1] [] kthread+0xe4/0x100
[ 1148.606208, 1] [] ? kthread_create_on_node+0x190/0x190
[ 1148.613721, 1] [] ret_from_fork+0x58/0x90
[ 1148.619967, 1] [] ? kthread_create_on_node+0x190/0x190

Signed-off-by: Pan Xinhui 
---
   drivers/acpi/osl.c | 28 +++-
   1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 7ccba39..57a1812 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1195,6 +1195,32 @@ void acpi_os_wait_events_complete(void)
 flush_workqueue(kacpi_notify_wq);
   }

+static int acpi_os_down_wait(struct semaphore *sem, long jiffies_timeout)
+{
+   unsigned long deadline_time;
+   int ret = 0;
+
+   if (down_trylock(sem)) {
+   if (unlikely(preempt_count())) {
+   deadline_time = jiffies + jiffies_timeout;
+   while (true) {
+   cpu_relax();
+
+   if (!down_trylock(sem))
+   break;
+
+   if (time_after(jiffies, deadline_time)) {
+   ret = -ETIME;
+   break;
+   }
+   }
+   } else
+   ret = down_timeout(sem, jiffies_timeout);
+   }
+
+   return ret;
+}
+
   struct acpi_hp_work {
 struct work_struct work;
 struct acpi_device *adev;
@@ -1309,7 +1335,7 @@ acpi_status acpi_os_wait_semaphore(acpi_handle handle, 
u32 units, u16 timeout)
 

[Patch v3 31/36] genirq: Move field 'affinity' from struct irq_data into struct irq_common_data

[Jiang Liu]

Irq affinity mask is per-irq instead of per irqchip, so move it into
struct irq_common_data.

Signed-off-by: Jiang Liu 
---
Hi Thomas,
This version changes the patch to correctly support bisecting.
Thanks!
Gerry
---
 arch/x86/kernel/apic/vector.c |4 +---
 include/linux/irq.h   |   12 ++--
 kernel/irq/irqdesc.c  |9 +
 kernel/irq/manage.c   |   12 ++--
 kernel/irq/proc.c |2 +-
 5 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 7ad911ea4f56..dfa3a5f5b3d3 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -494,10 +494,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
 
err = assign_irq_vector(irq, data, dest);
if (err) {
-   struct irq_data *top = irq_get_irq_data(irq);
-
if (assign_irq_vector(irq, data,
- irq_data_get_affinity_mask(top)))
+ irq_data_get_affinity_mask(irq_data)))
pr_err("Failed to recover vector for irq %d\n", irq);
return err;
}
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 91fbf10bdae0..9d01cd8ca8a2 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -110,8 +110,8 @@ enum {
 /*
  * Return value for chip->irq_set_affinity()
  *
- * IRQ_SET_MASK_OK - OK, core updates irq_data.affinity
- * IRQ_SET_MASK_NOCPY  - OK, chip did update irq_data.affinity
+ * IRQ_SET_MASK_OK - OK, core updates irq_common_data.affinity
+ * IRQ_SET_MASK_NOCPY  - OK, chip did update irq_common_data.affinity
  * IRQ_SET_MASK_OK_DONE- Same as IRQ_SET_MASK_OK for core. Special 
code to
  *   support stacked irqchips, which indicates skipping
  *   all descendent irqchips.
@@ -131,6 +131,7 @@ struct irq_domain;
  * Use accessor functions to deal with it
  * @node:  node index useful for balancing
  * @handler_data:  per-IRQ data for the irq_chip methods
+ * @affinity:  IRQ affinity on SMP
  */
 struct irq_common_data {
unsigned intstate_use_accessors;
@@ -138,6 +139,7 @@ struct irq_common_data {
unsigned intnode;
 #endif
void*handler_data;
+   cpumask_var_t   affinity;
 };
 
 /**
@@ -154,7 +156,6 @@ struct irq_common_data {
  * @chip_data: platform-specific per-chip private data for the chip
  * methods, to allow shared chip implementations
  * @msi_desc:  MSI descriptor
- * @affinity:  IRQ affinity on SMP
  *
  * The fields here need to overlay the ones in irq_desc until we
  * cleaned up the direct references and switched everything over to
@@ -172,7 +173,6 @@ struct irq_data {
 #endif
void*chip_data;
struct msi_desc *msi_desc;
-   cpumask_var_t   affinity;
 };
 
 /*
@@ -660,12 +660,12 @@ static inline struct cpumask *irq_get_affinity_mask(int 
irq)
 {
struct irq_data *d = irq_get_irq_data(irq);
 
-   return d ? d->affinity : NULL;
+   return d ? d->common->affinity : NULL;
 }
 
 static inline struct cpumask *irq_data_get_affinity_mask(struct irq_data *d)
 {
-   return d->affinity;
+   return d->common->affinity;
 }
 
 unsigned int arch_dynirq_lower_bound(unsigned int from);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 7f881792ad5f..2c39a203f78b 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -38,12 +38,13 @@ static void __init init_irq_default_affinity(void)
 #ifdef CONFIG_SMP
 static int alloc_masks(struct irq_desc *desc, gfp_t gfp, int node)
 {
-   if (!zalloc_cpumask_var_node(>irq_data.affinity, gfp, node))
+   if (!zalloc_cpumask_var_node(>irq_common_data.affinity,
+gfp, node))
return -ENOMEM;
 
 #ifdef CONFIG_GENERIC_PENDING_IRQ
if (!zalloc_cpumask_var_node(>pending_mask, gfp, node)) {
-   free_cpumask_var(desc->irq_data.affinity);
+   free_cpumask_var(desc->irq_common_data.affinity);
return -ENOMEM;
}
 #endif
@@ -52,7 +53,7 @@ static int alloc_masks(struct irq_desc *desc, gfp_t gfp, int 
node)
 
 static void desc_smp_init(struct irq_desc *desc, int node)
 {
-   cpumask_copy(desc->irq_data.affinity, irq_default_affinity);
+   cpumask_copy(desc->irq_common_data.affinity, irq_default_affinity);
 #ifdef CONFIG_GENERIC_PENDING_IRQ
cpumask_clear(desc->pending_mask);
 #endif
@@ -124,7 +125,7 @@ static void free_masks(struct irq_desc *desc)
 #ifdef CONFIG_GENERIC_PENDING_IRQ
free_cpumask_var(desc->pending_mask);
 #endif
-   free_cpumask_var(desc->irq_data.affinity);
+   free_cpumask_var(desc->irq_common_data.affinity);
 }
 #else
 static inline void 

[Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

[Jiang Liu]

Use access helper irq_data_get_affinity_mask() to hide implementation
details of struct irq_desc.

Signed-off-by: Jiang Liu 
---
Hi Thomas,
This version changes the patch to correctly support bisecting.
Thanks!
Gerry
---
 arch/x86/kernel/apic/io_apic.c   |2 +-
 arch/x86/kernel/apic/vector.c|3 ++-
 arch/x86/kernel/irq.c|5 +++--
 drivers/xen/events/events_base.c |4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 845dc0df2002..09921de4210f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2541,7 +2541,7 @@ void __init setup_ioapic_dest(void)
 * Honour affinities which have been set in early boot
 */
if (!irqd_can_balance(idata) || irqd_affinity_was_set(idata))
-   mask = idata->affinity;
+   mask = irq_data_get_affinity_mask(idata);
else
mask = apic->target_cpus();
 
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9b62f690b0ff..7ad911ea4f56 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -496,7 +496,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
if (err) {
struct irq_data *top = irq_get_irq_data(irq);
 
-   if (assign_irq_vector(irq, data, top->affinity))
+   if (assign_irq_vector(irq, data,
+ irq_data_get_affinity_mask(top)))
pr_err("Failed to recover vector for irq %d\n", irq);
return err;
}
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 7e10c8b4b318..37685e37550c 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -342,7 +342,8 @@ int check_irq_vectors_for_cpu_disable(void)
continue;
 
data = irq_desc_get_irq_data(desc);
-   cpumask_copy(_new, data->affinity);
+   cpumask_copy(_new,
+irq_data_get_affinity_mask(data));
cpumask_clear_cpu(this_cpu, _new);
 
/* Do not count inactive or per-cpu irqs. */
@@ -420,7 +421,7 @@ void fixup_irqs(void)
raw_spin_lock(>lock);
 
data = irq_desc_get_irq_data(desc);
-   affinity = data->affinity;
+   affinity = irq_data_get_affinity_mask(data);
if (!irq_has_action(irq) || irqd_is_per_cpu(data) ||
cpumask_subset(affinity, cpu_online_mask)) {
raw_spin_unlock(>lock);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2b8553bd8715..d00e0be8e9ea 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -336,7 +336,7 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned 
int cpu)
 
BUG_ON(irq == -1);
 #ifdef CONFIG_SMP
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(cpu));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(cpu));
 #endif
xen_evtchn_port_bind_to_cpu(info, cpu);
 
@@ -373,7 +373,7 @@ static void xen_irq_init(unsigned irq)
struct irq_info *info;
 #ifdef CONFIG_SMP
/* By default all event channels notify CPU#0. */
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(0));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(0));
 #endif
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-- 
1.7.10.4

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

Re: [PATCH v2] drm/rockchip: Add BGR formats to VOP

[Mark yao]

On 2015年05月30日 02:56, Tomasz Figa wrote:

On Mon, May 11, 2015 at 7:55 PM, Tomasz Figa  wrote:

VOP can support BGR formats in all windows thanks to red/blue swap option
provided in WINx_CTRL0 registers. This patch enables support for
ABGR, XBGR, BGR888 and BGR565 formats by using this feature.

Signed-off-by: Tomasz Figa 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 +
  1 file changed, 33 insertions(+)

Changes since v1:
(https://patchwork.kernel.org/patch/6369531/)
  - Fixed register addresses for win2/3 and hwc (reported by Mark Yao).

Gentle ping.

Applied to my drm-next:-)

Best regards,
Tomasz






--
Ｍark Yao


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

Re: [linux-next] please include init-v4.1-rc6 branch for v4.2

[Stephen Rothwell]

Hi Paul,

On Tue, 2 Jun 2015 19:23:18 -0400 Paul Gortmaker  
wrote:
>
> Please include init-v4.1-rc6 branch of:
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git

OK, I will add it in just before I merge Andrew's tree and see how it
goes.

> I've been cross building it and test merging it with next on and off for
> several weeks now, so it should be trouble free (hopefully).  There will
> be two relatively trivial conflicts upon merging to next:
> 
> 1) A removal of a __cpuinit from this tree will conflict with a removal
>of the whole code block contaning the original __cpuinit in the file
>arch/arm/mach-keystone/platsmp.c
> 
> 2) A removal of a __CPUINIT from this tree will conflict with a complete
>file removal (removed, not renamed) of arch/arm/mach-hisi/headsmp.S

Thanks for the heads up on these.

> Assuming I can get Linus to pull the chunks this time, it should be a
> one shot (one version) tree from a linux-next point of view.

If he takes it, please remind me to remove the tree.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au


pgpKh2UsfWuBj.pgp
Description: OpenPGP digital signature

Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()

[Darren Hart]

On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh wrote:
> Test results were sent to me privately, and they are correct, so...
> 

Finn, unless there is some compelling reason not to - like they are MBs worth of
data, please submit these to the list in the future so we have them for
reference.

> Acked-by: Henrique de Moraes Holschuh 

I'm fine with the changes, but they need to be submitted with the other changes
as this one change cannot compile independently in my tree.

Finn, please work with whomever is pulling the series to include this in their
pull request.

Reviewed-by: Darren Hart 

-- 
Darren Hart
Intel Open Source Technology Center
--
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/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
mm/page-writeback.c between commit 464d1387acb9 ("writeback: use |1
instead of +1 to protect against div by zero") from Linus' tree and
commit de1fff37b278 ("writeback: s/bdi/wb/ in mm/page-writeback.c")
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/page-writeback.c
index eb59f7eea508,e1514d5b4e9b..
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -802,27 -990,27 +990,27 @@@ static void wb_position_ratio(struct di
 * threshold, so that the occasional writes won't be blocked and active
 * writes can rampup the threshold quickly.
 */
-   bdi_thresh = max(bdi_thresh, (limit - dirty) / 8);
+   wb_thresh = max(wb_thresh, (limit - dtc->dirty) / 8);
/*
-* scale global setpoint to bdi's:
-*  bdi_setpoint = setpoint * bdi_thresh / thresh
+* scale global setpoint to wb's:
+*  wb_setpoint = setpoint * wb_thresh / thresh
 */
-   x = div_u64((u64)bdi_thresh << 16, thresh | 1);
-   bdi_setpoint = setpoint * (u64)x >> 16;
 -  x = div_u64((u64)wb_thresh << 16, dtc->thresh + 1);
++  x = div_u64((u64)wb_thresh << 16, dtc->thresh | 1);
+   wb_setpoint = setpoint * (u64)x >> 16;
/*
-* Use span=(8*write_bw) in single bdi case as indicated by
-* (thresh - bdi_thresh ~= 0) and transit to bdi_thresh in JBOD case.
+* Use span=(8*write_bw) in single wb case as indicated by
+* (thresh - wb_thresh ~= 0) and transit to wb_thresh in JBOD case.
 *
-*bdi_threshthresh - bdi_thresh
-* span = -- * (8 * write_bw) + --- * bdi_thresh
-*  threshthresh
+*wb_threshthresh - wb_thresh
+* span = - * (8 * write_bw) + -- * wb_thresh
+* thresh   thresh
 */
-   span = (thresh - bdi_thresh + 8 * write_bw) * (u64)x >> 16;
-   x_intercept = bdi_setpoint + span;
+   span = (dtc->thresh - wb_thresh + 8 * write_bw) * (u64)x >> 16;
+   x_intercept = wb_setpoint + span;
  
-   if (bdi_dirty < x_intercept - span / 4) {
-   pos_ratio = div64_u64(pos_ratio * (x_intercept - bdi_dirty),
- (x_intercept - bdi_setpoint) | 1);
+   if (dtc->wb_dirty < x_intercept - span / 4) {
+   pos_ratio = div64_u64(pos_ratio * (x_intercept - dtc->wb_dirty),
 -x_intercept - wb_setpoint + 1);
++(x_intercept - wb_setpoint) | 1);
} else
pos_ratio /= 4;
  


pgpvYkYPlzBu1.pgp
Description: OpenPGP digital signature

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Andi Kleen]

> Then the changelog should say that I think.  The current text says
> "Fast TSC calibration will always fail", which, to me, suggests that
> either the slow calibration will work or that the changelog message
> should be changed.

Ok. No, the slow calibration works I believe.

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

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
include/linux/blkdev.h between commit 336b7e1f2309 ("block: remove
export for blk_queue_bio") from Linus' tree and commit d40f75a06dd6
("writeback, blkcg: restructure blk_{set|clear}_queue_congested()")
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/blkdev.h
index 5d93a6645e88,31cd832cebb7..
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -821,25 -787,8 +787,6 @@@ extern int scsi_cmd_ioctl(struct reques
  extern int sg_scsi_ioctl(struct request_queue *, struct gendisk *, fmode_t,
 struct scsi_ioctl_command __user *);
  
- /*
-  * A queue has just exitted congestion.  Note this in the global counter of
-  * congested queues, and wake up anyone who was waiting for requests to be
-  * put back.
-  */
- static inline void blk_clear_queue_congested(struct request_queue *q, int 
sync)
- {
-   clear_bdi_congested(>backing_dev_info, sync);
- }
- 
- /*
-  * A queue has just entered congestion.  Flag that in the queue's VM-visible
-  * state flags and increment the global gounter of congested queues.
-  */
- static inline void blk_set_queue_congested(struct request_queue *q, int sync)
- {
-   set_bdi_congested(>backing_dev_info, sync);
- }
 -extern void blk_queue_bio(struct request_queue *q, struct bio *bio);
--
  extern void blk_start_queue(struct request_queue *q);
  extern void blk_stop_queue(struct request_queue *q);
  extern void blk_sync_queue(struct request_queue *q);


pgpoLKcEzX8Aw.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/2] Doc:crypto: Fix typo in crypto-API.tmpl

[Herbert Xu]

On Wed, Jun 03, 2015 at 01:39:20AM +0900, Masanari Iida wrote:
> This patch fix some spelling typo found in crypto-API.tmpl
> 
> Signed-off-by: Masanari Iida 

Please resend your patches with a cc to linux-cry...@vger.kernel.org

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the drivers-x86 tree with Linus' tree

[Darren Hart]

On Tue, Jun 02, 2015 at 04:07:23PM +1000, Stephen Rothwell wrote:
> Hi Darren,
> 
> Today's linux-next merge of the drivers-x86 tree got a conflict in
> drivers/platform/x86/ideapad-laptop.c between commit 9b071a43553d
> ("ideapad_laptop: Add Lenovo G40-30 to devices without radio switch")
> from Linus' tree and commit 4fa9dabcffc8 ("ideapad_laptop: Lenovo
> G50-30 fix rfkill reports wireless blocked") from the drivers-x86 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks for the heads' up. This happens because my -next branch is based on *-rc1
as I think was recommended at the last kernel summit. Since rc1 I sent Linus the
G50-30, but by rc6 I didn't feel good about sending the similar G50-30 fix, so
that is in my rc1 branch.

I am happy to rebase my -next on rc6 to avoid the conflict, but I believe the
rebase is considered poor practice.

You said no action required, but if there is something I can do to avoid this
kind of manual effort on your part (and a manual merge by Linus in the upcoming
merge window), I'm happy to update my process to accommodate.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
--
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] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

[Lan Tianyu]

On 2015年05月28日 14:33, Pan, XinhuiX wrote:
> acpi_os_wait_semaphore can be called in local/hard irq disabled path. like in 
> cpu up/down callback.
> So when dirver try to acquire the semaphore, current code may call down_wait 
> which might sleep.
> Then hit panic as we can't schedule here. So introduce acpi_os_down_wait to 
> cover such case.
> acpi_os_down_wait use down_trylock, and use cpu_relax to wait the semaphore 
> signalled if preempt is disabled.
> 
> below is the panic.

Hi Xinhui:

Does this issue happen in the latest upstream kernel?
In the latest code, acpi_cpu_soft_notify() doesn't detail with CPU_DYING
event and return directly. The issue should not take place.

> 
> [ 1148.230132, 1]smpboot: CPU 3 is now offline
> [ 1148.277288, 0]smpboot: CPU 2 is now offline
> [ 1148.322385, 1]BUG: scheduling while atomic: migration/1/13/0x0002
> [ 1148.329604, 1]Modules linked in: hid_sensor_hub sens_col_core hid_heci_ish 
> heci_ish heci vidt_driver atomisp_css2401a0_v21 lm3642 8723bs(O) cfg80211 
> gc2235 bt_lpm videobuf_vmalloc 6lowpan_iphc ip6table_raw iptable_raw 
> videobuf_core rfkill_gpio atmel_mxt_ts
> [ 1148.355276, 1]CPU: 1 PID: 13 Comm: migration/1 Tainted: GW  O 
> 3.14.37-x86_64-L1-R409-g73e8207 #25
> [ 1148.365983, 1]Hardware name: Intel Corporation CHERRYVIEW C0 
> PLATFORM/Cherry Trail CR, BIOS CH2TCR.X64.0004.R48.1504211851 04/21/2015
> [ 1148.379397, 1] 880077801140 880073233a58 819eec6c 
> 8800732303d0
> [ 1148.387914, 1] 880073233a70 819eb0e0 88007ac92240 
> 880073233ad0
> [ 1148.396430, 1] 819f790a 8800732303d0 880073233fd8 
> 00012240
> [ 1148.404948, 1]Call Trace:
> [ 1148.407912, 1] [] dump_stack+0x4e/0x7a
> [ 1148.413872, 1] [] __schedule_bug+0x58/0x67
> [ 1148.420219, 1] [] __schedule+0x67a/0x7b0
> [ 1148.426369, 1] [] schedule+0x29/0x70
> [ 1148.432123, 1] [] schedule_timeout+0x269/0x310
> [ 1148.438860, 1] [] ? update_group_power+0x16c/0x260
> [ 1148.445988, 1] [] __down_common+0x91/0xd6
> [ 1148.452236, 1] [] ? update_cfs_rq_blocked_load+0xc0/0x130
> [ 1148.460036, 1] [] __down_timeout+0x16/0x18
> [ 1148.466380, 1] [] down_timeout+0x4c/0x60
> [ 1148.472534, 1] [] acpi_os_wait_semaphore+0x43/0x57
> [ 1148.479658, 1] [] acpi_ut_acquire_mutex+0x48/0x88
> [ 1148.486683, 1] [] ? acpi_match_device+0x4d/0x4d
> [ 1148.493516, 1] [] acpi_get_data+0x35/0x77
> [ 1148.499761, 1] [] acpi_bus_get_device+0x21/0x3e
> [ 1148.506593, 1] [] acpi_cpu_soft_notify+0x3d/0xd3
> [ 1148.513522, 1] [] notifier_call_chain+0x53/0xa0
> [ 1148.520356, 1] [] ? cpu_stop_park+0x51/0x70
> [ 1148.526801, 1] [] __raw_notifier_call_chain+0xe/0x10
> [ 1148.534118, 1] [] cpu_notify+0x23/0x50
> [ 1148.540075, 1] [] take_cpu_down+0x27/0x40
> [ 1148.546322, 1] [] multi_cpu_stop+0xc1/0x110
> [ 1148.552763, 1] [] ? cpu_stop_should_run+0x50/0x50
> [ 1148.559776, 1] [] cpu_stopper_thread+0x78/0x150
> [ 1148.566608, 1] [] ? _raw_spin_unlock_irq+0x1e/0x40
> [ 1148.573730, 1] [] ? finish_task_switch+0x57/0xd0
> [ 1148.580646, 1] [] ? __schedule+0x37e/0x7b0
> [ 1148.586991, 1] [] smpboot_thread_fn+0x17d/0x2b0
> [ 1148.593819, 1] [] ? SyS_setgroups+0x160/0x160
> [ 1148.600455, 1] [] kthread+0xe4/0x100
> [ 1148.606208, 1] [] ? kthread_create_on_node+0x190/0x190
> [ 1148.613721, 1] [] ret_from_fork+0x58/0x90
> [ 1148.619967, 1] [] ? kthread_create_on_node+0x190/0x190
> 
> Signed-off-by: Pan Xinhui 
> ---
>   drivers/acpi/osl.c | 28 +++-
>   1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 7ccba39..57a1812 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -1195,6 +1195,32 @@ void acpi_os_wait_events_complete(void)
> flush_workqueue(kacpi_notify_wq);
>   }
> 
> +static int acpi_os_down_wait(struct semaphore *sem, long jiffies_timeout)
> +{
> +   unsigned long deadline_time;
> +   int ret = 0;
> +
> +   if (down_trylock(sem)) {
> +   if (unlikely(preempt_count())) {
> +   deadline_time = jiffies + jiffies_timeout;
> +   while (true) {
> +   cpu_relax();
> +
> +   if (!down_trylock(sem))
> +   break;
> +
> +   if (time_after(jiffies, deadline_time)) {
> +   ret = -ETIME;
> +   break;
> +   }
> +   }
> +   } else
> +   ret = down_timeout(sem, jiffies_timeout);
> +   }
> +
> +   return ret;
> +}
> +
>   struct acpi_hp_work {
> struct work_struct work;
> struct acpi_device *adev;
> @@ -1309,7 +1335,7 @@ acpi_status acpi_os_wait_semaphore(acpi_handle handle, 
> u32 units, u16 timeout)
> else
> jiffies = msecs_to_jiffies(timeout);
> 
> -   ret = 

Re: [PATCH v9 5/6] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

[Bintian]

Hello Mark, Rob and other ARM64 DT maintainers,

Could you help to ack this patch?

Thanks for your time.

Bintian

On 2015/5/30 9:51, Bintian Wang wrote:

Add initial dtsi file to support Hisilicon Hi6220 SoC with
support of Octal core CPUs in two clusters and each cluster
has quard Cortex-A53.

Also add dts file to support HiKey development board which
based on Hi6220 SoC.

Signed-off-by: Bintian Wang 
Acked-by: Haojian Zhuang 
Reviewed-by: Yiping Xu 
Tested-by: Will Deacon 
Tested-by: Tyler Baker 
Tested-by: Kevin Hilman 
---
  arch/arm64/boot/dts/Makefile   |1 +
  arch/arm64/boot/dts/hisilicon/Makefile |5 +
  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   31 +
  arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  172 
  4 files changed, 209 insertions(+)
  create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
  create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
  create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index ad26a75..38913be 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -4,6 +4,7 @@ dts-dirs += arm
  dts-dirs += cavium
  dts-dirs += exynos
  dts-dirs += freescale
+dts-dirs += hisilicon
  dts-dirs += mediatek
  dts-dirs += qcom
  dts-dirs += sprd
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
b/arch/arm64/boot/dts/hisilicon/Makefile
new file mode 100644
index 000..fa81a6e
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
new file mode 100644
index 000..e36a539
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -0,0 +1,31 @@
+/*
+ * dts file for Hisilicon HiKey Development Board
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ *
+ */
+
+/dts-v1/;
+
+/*Reserved 1MB memory for MCU*/
+/memreserve/ 0x05e0 0x0010;
+
+#include "hi6220.dtsi"
+
+/ {
+   model = "HiKey Development Board";
+   compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
new file mode 100644
index 000..229937f
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -0,0 +1,172 @@
+/*
+ * dts file for Hisilicon Hi6220 SoC
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "hisilicon,hi6220";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", 

Re: Regression: Disk corruption with dm-crypt and kernels >= 4.0

[Abelardo Ricart III]

On Tue, 2015-06-02 at 13:51 -0400, Mikulas Patocka wrote:
> 
> On Mon, 18 May 2015, Abelardo Ricart III wrote:
> 
> > On Fri, 2015-05-15 at 08:04 -0700, Brandon Smith wrote:
> > > On 2015-05-01 (Fri) at 19:42:15 -0400, Abelardo Ricart III wrote:
> > > > > > The patchset in question was tested quite heavily so this is a
> > > > > > surprising report.  I'm noticing you are opting in to dm-crypt 
> discard
> > > > > > support.  Have you tested without discards enabled?
> > > > > 
> > > > > I've disabled discards universally and rebuilt a vanilla kernel. 
> > > > > After 
> 
> > > > > running
> > > > > my heavy read-write-sync scripts, everything seems to be working fine 
> now. 
> > > > > I
> > > > > suppose this could be something that used to fail silently before, 
> > > > > but 
> now
> > > > > produces bad behavior? I seem to remember having something in my 
> message 
> > > > > log
> > > > > about "discards not supported on this device" when running with it 
> enabled
> > > > > before.
> > > > 
> > > > Forgive me, but I spoke too soon. The corruption and libata errors are 
> still
> > > > there, as was evidenced when I went to reboot and got treated to an eye 
> full 
> > > > of
> > > > "read-only filesystem" and ata errors.
> > > > 
> > > > So no, disabling discards unfortunately did nothing to help.
> > > 
> > > I've been experiencing the same problem.  Vanilla 4.0 series kernels,
> > > dm-crypt, with/or without discards, on a ThinkPad X1 Carbon with a
> > > LiteOn LGT-256M6G SSD.   
> > > 
> > > After some of googling around, I found some chatter relating to changes
> > > in NCQ on SSDs in 4.0.   Been running w/o NCQ for a full kernel build so
> > > far without issue.  Perhaps there's been some change in the interaction
> > > between dm-crypt and NCQ?
> > > 
> > > Abelardo, can you try w/o NCQ and see if that helps your situation?
> > > 
> > > Best,
> > > 
> > > --Brandon
> > 
> > I've been running with NCQ disabled and been stress testing for awhile and 
> the
> > issue is indeed gone. Thanks for the workaround!
> > 
> > So it seems the issue is somehow related to the combination of NCQ, dm
> -crypt,
> > and possibly (some?) SSDs.
> 
> Hi
> 
> I suspect that this is a bug in kernel NCQ processing or in SSD firmware 
> and recent dm-crypt changes made the bug show up.
> 
> I suggest this:
> 
> If you have some test that reliably reproduces the bug, please do this: 
> take kernel 3.19 or 3.18 and apply dm-crypt parallelization patches 
> (commits f3396c58fd8442850e759843457d78b6ec3a9589, 
> cf2f1abfbd0dba701f7f16ef619e4d2485de3366, 
> 7145c241a1bf2841952c3e297c4080b357b3e52d, 
> 94f5e0243c48aa01441c987743dc468e2d6eaca2, 
> dc2676210c425ee8e5cb1bec5bc84d004ddf4179, 
> 0f5d8e6ee758f7023e4353cca75d785b2d4f6abe, 
> b3c5fd3052492f1b8d060799d4f18be5a5438add) on it. If the bug doesn't show 
> up with the older kernel and dm-crypt parallelization patches, use git 
> bisect to find out which patch broken NCQ. When you test a kernel with 
> bisect, apply the above mentioned patches to it.
> 
> Mikulas
> --
> 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/

Alright, I'll try this next and report back soon.
--
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 12/15] KVM: MTRR: introduce mtrr_for_each_mem_type

[Xiao Guangrong]

On 06/01/2015 10:26 PM, Paolo Bonzini wrote:



On 01/06/2015 11:33, Paolo Bonzini wrote:

+   looker->mem_type = looker->mtrr_state->fixed_ranges[index];

+   looker->start = fixed_mtrr_range_end_addr(seg, index);
+   return true;

in mtrr_lookup_fixed_start is the same as this:



+   end = fixed_mtrr_range_end_addr(looker->seg, looker->index);
+
+   /* switch to next segment. */
+   if (end >= eseg->end) {
+   looker->seg++;
+   looker->index = 0;
+
+   /* have looked up for all fixed MTRRs. */
+   if (looker->seg >= ARRAY_SIZE(fixed_seg_table))
+   return mtrr_lookup_var_start(looker);
+
+   end = fixed_mtrr_range_end_addr(looker->seg, looker->index);
+   }
+
+   looker->mem_type = mtrr_state->fixed_ranges[looker->index];
+   looker->start = end;

in mtrr_lookup_fixed_next.  Can you try to make them more common?

Basically you should have

+#define mtrr_for_each_mem_type(_looker_, _mtrr_, _gpa_start_, _gpa_end_) \
+   for (mtrr_lookup_init(_looker_, _mtrr_, _gpa_start_, _gpa_end_); \
+!mtrr_lookup_end(_looker_); mtrr_lookup_next(_looker_))


... where the above code I quoted would be part of mtrr_lookup_end.


Okay, will do. :)
--
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 14/15] KVM: MTRR: do not map huage page for non-consistent range

[Xiao Guangrong]

On 06/01/2015 05:36 PM, Paolo Bonzini wrote:



On 30/05/2015 12:59, Xiao Guangrong wrote:

Currently guest MTRR is completely prohibited if cache snoop is supported on
IOMMU (!noncoherent_dma) and host does the emulation based on the knowledge
from host side, however, host side is not the good point to know
what the purpose of guest is. A good example is that pass-throughed VGA
frame buffer is not always UC as host expected


Can you explain how?  The original idea was that such a framebuffer
would be kvm_is_reserved_pfn and thus be unconditionally UC.


Yes, frame-buffer is always UC in current code, however, UC for frame-buffer
causes bad performance. It's quoted from Documentation/x86/mtrr.txt:

| This is most useful when you have a video (VGA) card on a PCI or AGP bus.
| Enabling write-combining allows bus write transfers to be combined into a
| larger transfer before bursting over the PCI/AGP bus. This can increase
| performance of image write operations 2.5 times or more.

So that guest will configure the range to MTRR, this patchset follows
guest MTRR and cooperates with guest PAT (ept.VMX_EPT_IPAT_BIT = 0) to emulate
guest cache type as guest expects.
--
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 2/2] arch/x86: remove pci uart early console from early_prink.c

[Bin Gao]

On Wed, Jun 03, 2015 at 12:16:36AM +, Anderson, Stuart R wrote:
> Bin, et al,
> 
> What we are losing here is the ability to specify a UART by its bus address
> instead of just supplying the memory or io address. There are some cases
> where this is useful, though I admit it is probably not going to be widely
> used. I have seen a platform where the location of the UART moves depending
> on the firmware version, but the bus address (B:D.F) did not change. There
> are also some platforms where you do not know the address until you boot the
> OS and can use the UART to login and find the address of the UART (oops.
> Chicken and egg problem).
> 
> Also, I was going to soon send a patch to allow "pciserial32" for the case 
> where the UART registers are 32-bit aligned instead of 8-bit aligned.
> 
> Stuart
> 

Theare are several reasons that we want to move it to serial_core.
First, pci is arch independent, so putting these codes in serial_core
(which is arch independent) makes more sense.
Second, B:D.F may change across SoCs, then to support new SoC we only
need change command line but don't need to change the code.
Lastly, there could be other non-x86 platforms using it in the future.

-Bin
--
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] libnvdimm: Add sysfs numa_node to NVDIMM devices

[Dan Williams]

On Tue, Jun 2, 2015 at 6:01 PM, Dan Williams  wrote:
> On Tue, Jun 2, 2015 at 5:26 PM, Toshi Kani  wrote:
>> Since NVDIMMs are installed on memory slots, they expose the NUMA
>> topology of a platform.
>>
>> This patch adds support of sysfs 'numa_node' to the NVDIMM devices
>> under /sys/bus/nd/devices, such as regionN, namespaceN.0, and bttN.
>> When bttN is not set up, its numa_node returns -1 (NUMA_NO_NODE).
>> nmemN/numa_node always returns -1 for now since this device is for
>> dimm-ioctl message interface and has little use of NUMA.  It can be
>> enhanced later to set a valid value if necessary.
>>
>> Here is an example of numa_node values on a 2-socket system with
>> a single NVDIMM range on each socket.
>>   /sys/bus/nd/devices
>>   |-- btt0/numa_node:-1
>>   |-- btt1/numa_node:0
>>   |-- namespace0.0/numa_node:0
>>   |-- namespace1.0/numa_node:1
>>   |-- nmem0/numa_node:-1
>>   |-- nmem1/numa_node:-1
>>   |-- region0/numa_node:0
>>   |-- region1/numa_node:1
>>
>> With this change, numactl(8) accepts 'block:' and 'file:' paths of
>> pmem and btt devices as shown in the examples below.
>>   numactl --preferred block:pmem0 --show
>>   numactl --preferred file:/dev/pmem0s --show
>>
>> Signed-off-by: Toshi Kani 
>> ---
>>  drivers/acpi/nfit.c  |2 ++
>>  drivers/nvdimm/btt.c |2 ++
>>  drivers/nvdimm/bus.c |   12 
>>  drivers/nvdimm/nd.h  |1 +
>>  drivers/nvdimm/region.c  |1 +
>>  drivers/nvdimm/region_devs.c |1 +
>>  include/linux/libnvdimm.h|1 +
>>  7 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
>> index 5731e4a..a255f3a 100644
>> --- a/drivers/acpi/nfit.c
>> +++ b/drivers/acpi/nfit.c
>> @@ -1255,6 +1255,8 @@ static int acpi_nfit_register_region(struct 
>> acpi_nfit_desc *acpi_desc,
>> ndr_desc->res = 
>> ndr_desc->provider_data = nfit_spa;
>> ndr_desc->attr_groups = acpi_nfit_region_attribute_groups;
>> +   ndr_desc->numa_node = acpi_map_pxm_to_node(spa->proximity_domain);
>> +
>> list_for_each_entry(nfit_memdev, _desc->memdevs, list) {
>> struct acpi_nfit_memory_map *memdev = nfit_memdev->memdev;
>> struct nd_mapping *nd_mapping;
>> diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
>> index 2d7ce9e..3b3e115 100644
>> --- a/drivers/nvdimm/btt.c
>> +++ b/drivers/nvdimm/btt.c
>> @@ -1369,6 +1369,8 @@ static int nd_btt_probe(struct device *dev)
>> rc = -ENOMEM;
>> goto err_btt;
>> }
>> +
>> +   set_dev_node(dev, nd_region->numa_node);
>> dev_set_drvdata(dev, btt);
>>
>> return 0;
>> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
>> index d8a1794..5c34e68 100644
>> --- a/drivers/nvdimm/bus.c
>> +++ b/drivers/nvdimm/bus.c
>> @@ -339,9 +339,21 @@ static ssize_t devtype_show(struct device *dev, struct 
>> device_attribute *attr,
>>  }
>>  static DEVICE_ATTR_RO(devtype);
>>
>> +#ifdef CONFIG_NUMA
>> +static ssize_t numa_node_show(struct device *dev, struct device_attribute 
>> *attr,
>> +   char *buf)
>> +{
>> +   return sprintf(buf, "%d\n", dev->numa_node);
>> +}
>> +DEVICE_ATTR_RO(numa_node);
>> +#endif
>> +
>>  static struct attribute *nd_device_attributes[] = {
>> _attr_modalias.attr,
>> _attr_devtype.attr,
>> +#ifdef CONFIG_NUMA
>> +   _attr_numa_node.attr,
>> +#endif
>> NULL,
>>  };
>
> I'd prefer you define is_visible() in the nd_device_attribute_group
> and gate showing this attribute on IS_ENABLED(CONFIG_NUMA) rather than
> including these ifdef guards.  The ifdef guards aren't necessary in
> the CONFIG_NUMA=n case.

I also think is_visible() should hide this attribute on is_nvdimm() devices.
--
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 2/2] arch/x86: remove pci uart early console from early_prink.c

[Bin Gao]

On Tue, Jun 02, 2015 at 01:37:52PM -0700, Yinghai Lu wrote:
> how about
> earlyprintk=serial,ttyS0
> earlyprintk=ttyS0
> 
> Thanks
> 
> Yinghai

Yes, both work.

-Bin
--
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 v6 23/30] perf tools: Make perf depend on libbpf

[Wang Nan]

By adding libbpf into perf's Makefile, this patch enables perf to
build libbpf during building if libelf is found and neither NO_LIBELF
nor NO_LIBBPF is set. The newly introduced code is similar to libapi
and libtraceevent building in Makefile.perf.

MANIFEST is also updated for 'make perf-*-src-pkg'.

Append make_no_libbpf to tools/perf/tests/make.

Error messages are also updated to notify users about the disable of
BPF support of 'perf record' if libelf is missed or BPF API check
failed.

Signed-off-by: Wang Nan 
---
 tools/perf/MANIFEST|  3 +++
 tools/perf/Makefile.perf   | 17 -
 tools/perf/config/Makefile | 19 ++-
 tools/perf/tests/make  |  4 +++-
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST
index a0bdd61..1ad2016 100644
--- a/tools/perf/MANIFEST
+++ b/tools/perf/MANIFEST
@@ -17,6 +17,7 @@ tools/build
 tools/arch/x86/include/asm/atomic.h
 tools/arch/x86/include/asm/rmwcc.h
 tools/lib/traceevent
+tools/lib/bpf
 tools/lib/api
 tools/lib/symbol/kallsyms.c
 tools/lib/symbol/kallsyms.h
@@ -71,6 +72,8 @@ include/linux/magic.h
 include/linux/hw_breakpoint.h
 include/linux/rbtree_augmented.h
 include/uapi/linux/perf_event.h
+include/uapi/linux/bpf.h
+include/uapi/linux/bpf_common.h
 include/uapi/linux/const.h
 include/uapi/linux/swab.h
 include/uapi/linux/hw_breakpoint.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 5816a3b..8fe92d6 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -125,6 +125,7 @@ STRIP   = strip
 
 LIB_DIR  = $(srctree)/tools/lib/api/
 TRACE_EVENT_DIR = $(srctree)/tools/lib/traceevent/
+BPF_DIR = $(srctree)/tools/lib/bpf/
 
 # include config/Makefile by default and rule out
 # non-config cases
@@ -160,6 +161,7 @@ strip-libs = $(filter-out -l%,$(1))
 
 ifneq ($(OUTPUT),)
   TE_PATH=$(OUTPUT)
+  BPF_PATH=$(OUTPUT)
 ifneq ($(subdir),)
   LIB_PATH=$(OUTPUT)/../lib/api/
 else
@@ -168,6 +170,7 @@ endif
 else
   TE_PATH=$(TRACE_EVENT_DIR)
   LIB_PATH=$(LIB_DIR)
+  BPF_PATH=$(BPF_DIR)
 endif
 
 LIBTRACEEVENT = $(TE_PATH)libtraceevent.a
@@ -176,6 +179,8 @@ export LIBTRACEEVENT
 LIBAPI = $(LIB_PATH)libapi.a
 export LIBAPI
 
+LIBBPF = $(BPF_PATH)libbpf.a
+
 # python extension build directories
 PYTHON_EXTBUILD := $(OUTPUT)python_ext_build/
 PYTHON_EXTBUILD_LIB := $(PYTHON_EXTBUILD)lib/
@@ -227,6 +232,9 @@ export PERL_PATH
 LIB_FILE=$(OUTPUT)libperf.a
 
 PERFLIBS = $(LIB_FILE) $(LIBAPI) $(LIBTRACEEVENT)
+ifndef NO_LIBELF
+  PERFLIBS += $(LIBBPF)
+endif
 
 # We choose to avoid "if .. else if .. else .. endif endif"
 # because maintaining the nesting to match is a pain.  If
@@ -389,6 +397,13 @@ $(LIBAPI)-clean:
$(call QUIET_CLEAN, libapi)
$(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
 
+$(LIBBPF): FORCE
+   $(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) $(OUTPUT)libbpf.a
+
+$(LIBBPF)-clean:
+   $(call QUIET_CLEAN, libbpf)
+   $(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) clean >/dev/null
+
 help:
@echo 'Perf make targets:'
@echo '  doc- make *all* documentation (see below)'
@@ -531,7 +546,7 @@ config-clean:
$(call QUIET_CLEAN, config)
$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
 
-clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean config-clean
+clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean config-clean
$(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_FILE) $(OUTPUT)perf-archive 
$(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
$(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name 
'\.*.d' -delete
$(Q)$(RM) .config-detected
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 317001c..1b387ec 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -106,6 +106,7 @@ ifdef LIBBABELTRACE
   FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) 
-lbabeltrace-ctf
 endif
 
+FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/arch/$(ARCH)/include/uapi -I$(srctree)/include/uapi
 # include ARCH specific config
 -include $(src-perf)/arch/$(ARCH)/Makefile
 
@@ -233,6 +234,7 @@ ifdef NO_LIBELF
   NO_DEMANGLE := 1
   NO_LIBUNWIND := 1
   NO_LIBDW_DWARF_UNWIND := 1
+  NO_LIBBPF := 1
 else
   ifeq ($(feature-libelf), 0)
 ifeq ($(feature-glibc), 1)
@@ -242,13 +244,14 @@ else
   LIBC_SUPPORT := 1
 endif
 ifeq ($(LIBC_SUPPORT),1)
-  msg := $(warning No libelf found, disables 'probe' tool, please install 
elfutils-libelf-devel/libelf-dev);
+  msg := $(warning No libelf found, disables 'probe' tool and BPF support 
in 'perf record', please install elfutils-libelf-devel/libelf-dev);
 
   NO_LIBELF := 1
   NO_DWARF := 1
   NO_DEMANGLE := 1
   NO_LIBUNWIND := 1
   NO_LIBDW_DWARF_UNWIND := 1
+  NO_LIBBPF := 1
 else
   ifneq ($(filter s% -static%,$(LDFLAGS),),)
 msg := $(error No static glibc found, please install 

Re: [PATCH 12/15] KVM: MTRR: introduce mtrr_for_each_mem_type

[Xiao Guangrong]

On 06/01/2015 05:33 PM, Paolo Bonzini wrote:



On 30/05/2015 12:59, Xiao Guangrong wrote:

+struct mtrr_looker {
+   /* input fields. */
+   struct kvm_mtrr *mtrr_state;
+   u64 start;
+   u64 end;


s/looker/iter/ or s/looker/lookup/


Good to me.




+static void mtrr_lookup_start(struct mtrr_looker *looker)
+{
+   looker->mem_type = -1;
+
+   if (!looker->mtrr_state->mtrr_enabled) {
+   looker->partial_map = true;
+   return;
+   }
+
+   if (!mtrr_lookup_fixed_start(looker))
+   mtrr_lookup_var_start(looker);
+}
+


Separating mtrr_lookup_start and mtrr_lookup_init is weird.


Agreed, will fold mtrr_lookup_start() into mtrr_lookup_init().



There are common parts of mtrr_lookup_*_start and mtrr_lookup_*_next.
For example this:


+   looker->mem_type = looker->mtrr_state->fixed_ranges[index];
+   looker->start = fixed_mtrr_range_end_addr(seg, index);
+   return true;


in mtrr_lookup_fixed_start is the same as this:



+   end = fixed_mtrr_range_end_addr(looker->seg, looker->index);
+
+   /* switch to next segment. */
+   if (end >= eseg->end) {
+   looker->seg++;
+   looker->index = 0;
+
+   /* have looked up for all fixed MTRRs. */
+   if (looker->seg >= ARRAY_SIZE(fixed_seg_table))
+   return mtrr_lookup_var_start(looker);
+
+   end = fixed_mtrr_range_end_addr(looker->seg, looker->index);
+   }
+
+   looker->mem_type = mtrr_state->fixed_ranges[looker->index];
+   looker->start = end;


in mtrr_lookup_fixed_next.  Can you try to make them more common?


Yes, i will check them carefully and introduce common functions to do
it.



Basically you should have

+#define mtrr_for_each_mem_type(_looker_, _mtrr_, _gpa_start_, _gpa_end_) \
+   for (mtrr_lookup_init(_looker_, _mtrr_, _gpa_start_, _gpa_end_); \
+!mtrr_lookup_end(_looker_); mtrr_lookup_next(_looker_))


Good idea, will do it in v2.

--
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 8/8] cgroup: implement the PIDs subsystem

[Aleksa Sarai]

>> That's complete and utter nonsense. What has the parent limit to do
>> with the overflow of the child limit?

I didn't read this sentence properly. It's because you're migrating
*from* the parent to the child. If you have the right to attach to the
child from the parent, then you also have the right to change the
limit of the child.

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

Re: [patch 2/2] w1: unlock correct lock on error in w1_seq_show()

[David Fries]

On Tue, Jun 02, 2015 at 09:54:10PM -0400, Matt Campbell wrote:
> Thanks for the response, I will try to answer your questions.
> 
> The other function besides temp conversion and EEPROM write that
> requires a delay is the initial CHAIN on command. The datasheet says
> to "Wait for chain to charge" but it does not offer ANY indication on
> how to do so.  I did discover that my sleep was a sleep(0) long after
> I submitted the patch, but as you observed it was not hurting
> anything.

Then it should be removed as it gives the wrong impression and that
variable shouldn't be used in the slave code anyway.

> The 64 was, in all honesty, a starting point that I picked for lack of
> finding a better option.  I only currently have 10 sensors available
> for me to test with, so I was not able to do any significant tests to
> see what would happen if I raised that limit and the loop did not exit
> properly at the end of the chain.  I was also not able to find an edge
> case that would cause the loop to not find a match.  The w1_seq file
> only shows for the one type sensor that supports it so in the absence
> of a bus error, a match is guaranteed.

That's easy enough to test, comment out your if...break; in the loop.

Is there a good reason that the loop doesn't terminate when the device
you're after sl->reg_num.id is found?  By making your loop terminate
on a different condition, W1_42_FINISHED_BYTE, if the slave you are
after isn't found you'll still return seq of 0.  I'm wondering if seq
should be initialized to -1.

Do this, make up the right id of the correct family code and manually
tell the kernel it is there.  That would be the same as if you removed
a chip before the kernel's search timed it out.  Then do your sequence
scan on your devices including this new one which isn't there.
cd /sys/devices/w1_bus_master1
echo 42-01234567 > w1_master_add

The devices return the rom numbers, I wonder about returning the rom
list (which is in the sequence), instead of the sequence number for a
device if that would be more or less useful to users.  You would be
able to do it in one pass.

> The output of the function in the event the pins are hooked up as GPIO
> and not a chain is undefined.  Since the chips are very tiny,
> prototyping this function would require me to design and order some
> boards that I never was able to use.  To my knowledge it is not
> possible to determine that things are wired this way in the software.

Something like "Output is undefined if all direct sequence sensors on
this one wire bus aren't part of one chain.  GPIO control of the two
pins is not support by this driver." for the comment above
w1_seq_show, in addition to the other comments I was asking about.  I
see now you have some documentation in
Documentation/w1/slaves/w1_therm already that I didn't realize
earlier.

> Apologies, this is my first foray in submitting any sort of kernel
> code so I am not sure of exactly how I would submit a fixup patch for
> gregkh's tree.  If someone wants to walk me through that off list I
> would be most appreciative!

git remote add gregkh_char-misc 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
git fetch gregkh_char-misc
git rebase remotes/gregkh_char-misc/char-misc-next
and add a new commit from there.

> Matt Campbell
> mattrcampb...@gmail.com
> 
> 
> On Tue, Jun 2, 2015 at 9:07 PM, David Fries  wrote:
> > The source code is as good as it gets, that's why I posted those two
> > lines from the w1.h file.  Maybe it could be expanded upon, mutex is
> > more for adding or removing slaves and the like modifications to
> > w1_master data structure, where bus_mutex is what make sure something
> > else doesn't try to talk on the bus while the current device is using
> > it.  What really matters is how other code is using the locks.  For
> > instance if you look at w1_therm.c bus_mutex is the only one used.
> > Then you look at what your routine is doing, and what the existing
> > routine is doing, they are both reading/writing from the one wire bus,
> > and then return their output to the user, so then use the same lock.
> > If it's the wrong lock then it's at least consistent and easier to
> > cleanup when someone figures out it's the wrong lock.  If you think
> > it's the wrong lock raise a flag and ask.
> >
> > My patch review comments.
> >
> > The temperature sensor uses a strong pullup or delay of 750 ms to do
> > the temperature conversion.  A quick read through of this sensor has
> > temperature conversion and EEPROM write as the only operations
> > requiring a significant time delay, everything else is in the us, so I
> > would expect this to not require any delay.
> >
> > Read the comments to w1_next_pullup in w1_io.c as pullup_duration will
> > always be 0 in msleep(sl->master->pullup_duration); which isn't likely
> > what you expect.  Apparently it is working for you so that further
> > reinforces my previous point.
> >
> > Where did the 64 come from?  I have 14 

Re: [PATCH 10/15] KVM: MTRR: sort variable MTRRs

[Xiao Guangrong]

On 06/01/2015 05:27 PM, Paolo Bonzini wrote:



On 30/05/2015 12:59, Xiao Guangrong wrote:

Sort all valid variable MTRRs based on its base address, it will help us to
check a range to see if it's fully contained in variable MTRRs

Signed-off-by: Xiao Guangrong 
---
  arch/x86/include/asm/kvm_host.h |  3 +++
  arch/x86/kvm/mtrr.c | 39 +++
  arch/x86/kvm/x86.c  |  2 +-
  arch/x86/kvm/x86.h  |  1 +
  4 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f3fc152..5be8f2e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -347,6 +347,7 @@ enum {
  struct kvm_mtrr_range {
u64 base;
u64 mask;
+   struct list_head node;
  };

  struct kvm_mtrr {
@@ -362,6 +363,8 @@ struct kvm_mtrr {
unsigned mtrr_enabled:1;
};
};
+
+   struct list_head head;
  };

  struct kvm_vcpu_arch {
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index aeb9767..8e3b81a 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -262,6 +262,38 @@ do_zap:
kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(start), gpa_to_gfn(end));
  }

+static bool var_mtrr_range_is_valid(struct kvm_mtrr_range *range)
+{
+   u64 start, end;
+
+   if (!(range->mask & (1 << 11)))
+   return false;
+
+   var_mtrr_range(range, , );
+   return end > start;
+}
+
+static void set_var_mtrr_start(struct kvm_mtrr *mtrr_state, int index)
+{
+   /* remove the entry if it's in the list. */
+   if (var_mtrr_range_is_valid(_state->var_ranges[index]))
+   list_del(_state->var_ranges[index].node);
+}
+
+static void set_var_mtrr_end(struct kvm_mtrr *mtrr_state, int index)
+{
+   struct kvm_mtrr_range *tmp, *cur = _state->var_ranges[index];
+
+   /* add it to the list if it's valid. */
+   if (var_mtrr_range_is_valid(_state->var_ranges[index])) {
+   list_for_each_entry(tmp, _state->head, node)
+   if (cur->base < tmp->base)
+   list_add_tail(>node, >node);
+
+   list_add_tail(>node, _state->head);
+   }
+}
+
  int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data)
  {
int index;
@@ -281,10 +313,12 @@ int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
data)

index = (msr - 0x200) / 2;
is_mtrr_mask = msr - 0x200 - 2 * index;
+   set_var_mtrr_start(>arch.mtrr_state, index);
if (!is_mtrr_mask)
vcpu->arch.mtrr_state.var_ranges[index].base = data;
else
vcpu->arch.mtrr_state.var_ranges[index].mask = data;
+   set_var_mtrr_end(>arch.mtrr_state, index);


Just move the whole code to a new kvm_set_var_mtrr function.


Okay.




}

update_mtrr(vcpu, msr);
@@ -331,6 +365,11 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
return 0;
  }

+void kvm_vcpu_mtrr_init(struct kvm_vcpu *vcpu)
+{
+   INIT_LIST_HEAD(>arch.mtrr_state.head);
+}
+
  u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
  {
struct kvm_mtrr *mtrr_state = >arch.mtrr_state;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 64c2891..8084ac3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6991,7 +6991,7 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
kvm_vcpu_reset(vcpu, false);
kvm_mmu_setup(vcpu);
vcpu_put(vcpu);
-
+   kvm_vcpu_mtrr_init(vcpu);


Please move this call much earlier.


Okay, will do these in v2.

--
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 v10 1/3] smpboot: allow excluding cpus from the smpboot threads

[Don Zickus]

On Mon, May 04, 2015 at 06:06:24PM -0400, Chris Metcalf wrote:
> On 5/1/2015 5:23 PM, Frederic Weisbecker wrote:
> >On Fri, May 01, 2015 at 03:57:51PM -0400, Chris Metcalf wrote:
> >
> >>For example, booting with only cpu 0 as a housekeeping core (and
> >>therefore all watchdogs 1-35 on my 36-core tilegx are parked), and
> >>immediately doing "echo 0 > /proc/sys/kernel/watchdog", I see
> >>(via SysRq ^O-l) the first parked watchdog, on cpu 1, hung with:
> >>
> >>   frame 0: 0xfff7000f2928 lock_hrtimer_base+0xb8/0xc0
> >>   frame 1: 0xfff7000f2a28 hrtimer_try_to_cancel+0x40/0x170
> >>   frame 2: 0xfff7000f2a28 hrtimer_try_to_cancel+0x40/0x170
> >>   frame 3: 0xfff7000f2b98 hrtimer_cancel+0x40/0x68
> >>   frame 4: 0xfff70014cce0 watchdog_disable+0x50/0x70
> >>   frame 5: 0xfff70008c2d0 smpboot_thread_fn+0x350/0x438
> >>   frame 6: 0xfff700084b28 kthread+0x160/0x178
> >Have you tried to do that before your patchset?
> 
> Yes, it works fine.  It requires the presence of the parked threads to 
> trigger the issue.
> 
> >>The config does not have NO_HZ_FULL_ALL or NO_HZ_FULL_SYSIDLE
> >>set, and does have RCU_FAST_NO_HZ and RCU_NOCB_CPU_ALL.
> >>
> >>I don't really know how to start debugging this, but I do know that
> >>unparking the threads first avoids the issue :-)
> >Do you have CONFIG_PROVE_LOCKING=y ?
> 
> There seems to be some skew between the community version, which is throwing a
> bunch of errors when I enable PROVE_LOCKING, and our internal version where 
> some
> things are not yet upstreamed but PROVE_LOCKING works :-)
> 
> I'll try to set aside some time to reconcile the two to figure it out.

Hi Chris,

I was digging this thread back up and wondered what happened.  It seems like
a v11 was going to materialize?

Cheers,
Don
--
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 08/15] KVM: MTRR: introduce fixed_mtrr_segment table

[Xiao Guangrong]

On 06/01/2015 05:25 PM, Paolo Bonzini wrote:



On 30/05/2015 12:59, Xiao Guangrong wrote:

This table summarizes the information of fixed MTRRs and introduce some APIs
to abstract its operation which helps us to clean up the code and will be
used in later patches

Signed-off-by: Xiao Guangrong 
---
  arch/x86/kvm/mtrr.c | 191 ++--
  1 file changed, 142 insertions(+), 49 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index d3c06d2..888441e 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -102,12 +102,126 @@ bool kvm_mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 
data)
  }
  EXPORT_SYMBOL_GPL(kvm_mtrr_valid);

+struct fixed_mtrr_segment {
+   u64 start;
+   u64 end;
+
+   /*
+* unit corresponds to the MSR entry in this segment, the size
+* of unit is covered in one MSR.
+*/
+   u64 unit_size;
+
+   /* a range is covered in one memory cache type. */
+   u64 range_size;
+
+   /* the start position in kvm_mtrr.fixed_ranges[]. */
+   int range_start;
+};
+
+static struct fixed_mtrr_segment fixed_seg_table[] = {
+   /* MSR_MTRRfix64K_0, 1 unit. 64K fixed mtrr. */
+   {
+   .start = 0x0,
+   .end = 0x8,
+   .unit_size = 0x8,


Unit size is always range size * 8.


Good catch, will drop this.




+   .range_size = 1ULL << 16,


Perhaps 64 * 1024 (and so on below) is clearer, because it matches the
name of the MSR?


Yes, it's better.




+   .range_start = 0,
+   },
+
+   /*
+* MSR_MTRRfix16K_8 ... MSR_MTRRfix16K_A, 2 units,
+* 16K fixed mtrr.
+*/
+   {
+   .start = 0x8,
+   .end = 0xc,
+   .unit_size = (0xc - 0x8) / 2,
+   .range_size = 1ULL << 14,
+   .range_start = 8,
+   },
+
+   /*
+* MSR_MTRRfix4K_C ... MSR_MTRRfix4K_F8000, 8 units,
+* 4K fixed mtrr.
+*/
+   {
+   .start = 0xc,
+   .end = 0x10,
+   .unit_size = (0x10 - 0xc) / 8,
+   .range_size = 1ULL << 12,
+   .range_start = 24,
+   }
+};
+
+static int fixed_msr_to_range_index(u32 msr)
+{
+   int seg, unit;
+
+   if (!fixed_msr_to_seg_unit(msr, , ))
+   return -1;
+
+   fixed_mtrr_seg_unit_range_index(seg, unit);


This looks wrong.


Oops, should be "return fixed_mtrr_seg_unit_range_index(seg, unit);" :(




+   return 0;
+}
+
  static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
  {
struct kvm_mtrr *mtrr_state = >arch.mtrr_state;
gfn_t start, end, mask;
int index;
-   bool is_fixed = true;

if (msr == MSR_IA32_CR_PAT || !tdp_enabled ||
  !kvm_arch_has_noncoherent_dma(vcpu->kvm))
@@ -116,32 +230,19 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
if (!mtrr_state->mtrr_enabled && msr != MSR_MTRRdefType)
return;

+   if (fixed_msr_to_range(msr, , )) {
+   if (!mtrr_state->fixed_mtrr_enabled)
+   return;
+   goto do_zap;
+   }
+
switch (msr) {


Please move defType handling in an "if" above "if
(fixed_msr_to_range(msr, , ))".  Then you don't need the goto.



Yes, indeed. Will do it in the next version.
--
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 5/9] net: dsa: mv88e6352: disable mirroring

[Guenter Roeck]

On Tue, Jun 02, 2015 at 09:12:30PM -0400, Vivien Didelot wrote:
> Hi Guenter, Andrew,
> 
> On Jun 2, 2015, at 10:53 AM, Andrew Lunn and...@lunn.ch wrote:
> On Tue, Jun 02, 2015 at 07:16:10AM -0700, Guenter Roeck wrote:
> >> On 06/01/2015 06:27 PM, Vivien Didelot wrote:
> >> >Disable the mirroring policy in the monitor control register, since this
> >> >feature is not needed.
> >> >
> >> >Signed-off-by: Vivien Didelot 
> >> 
> >> Should this be a separate patch, unrelated to the patch set ?
> 
> Indeed, this one is an unrelated patch, sorry.
> 
> >> If I understand correctly, this effectively disables IGMP/MLD snooping.
> >> I think this warrants an explanation why that it not needed, not just
> >> a statement that it is not needed.
> > 
> > +1
> > 
> > Especially since we might want to revisit this to implement IGMP/MLD
> > snooping in the bridge. The hardware should be capable of it.
> 
> This is something I want to disable because I can have several times
> gigabit traffic on my ports. This would end up in a bottleneck on the
> CPU port. Am I right?
> 
Not really. That should not be that much traffic. Besides, IGMP/MLD snooping
still needs to be enabled separately, as well as egress monitoring.

I don't think this has any impact on the traffic to the CPU port unless other
configuration bits are set as well.

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

Re: [PATCH v4 06/11] md/raid5: get rid of bio_fits_rdev()

[NeilBrown]

On Tue, 26 May 2015 15:32:38 -0700 Ming Lin  wrote:

> On Tue, May 26, 2015 at 7:33 AM, Ming Lin  wrote:
> > On Mon, May 25, 2015 at 7:17 AM, Christoph Hellwig  wrote:
> >> On Mon, May 25, 2015 at 05:54:14PM +1000, NeilBrown wrote:
> >>> Did I write that?  I guess I did :-(
> >>> I meant *after*.   Don't get rid of bio_fits_rdev until split_bio is in
> >>> chunk_aligned_read().
> >>
> >> I suspect the whole series could use some reordering.
> >
> > Nice reordering.
> > I'll do this.
> 
> Here is the reordering.
> https://git.kernel.org/cgit/linux/kernel/git/mlin/linux.git/log/?h=block-generic-req
> 
> I'll post it if you are OK.
> 
> [PATCH 01/15] block: add blk_queue_split()
> [PATCH 02/15] md: remove ->merge_bvec_fn
> [PATCH 03/15] dm: remov merge functions
> [PATCH 04/15] drbd: remove ->merge_bvec_fn
> [PATCH 05/15] pktcdvd: remove ->merge_bvec_fn
> [PATCH 06/15] rbd: remove ->merge_bvec_fn
> [PATCH 07/15] bcache: remove driver private bio splitting code
> [PATCH 08/15] btrfs: remove bio splitting and merge_bvec_fn() calls
> [PATCH 09/15] block: call blk_queue_split() in make_request functions
> [PATCH 10/15] block: kill ->merge_bvec_fn and simplify bio_add_page
> [PATCH 11/15] block: remove split code in blkdev_issue_discard
> [PATCH 12/15] md/raid5: get rid of bio_fits_rdev()
> [PATCH 13/15] block: remove bio_get_nr_vecs()
> [PATCH 14/15] fs: use helper bio_add_page() instead of open coding on
> [PATCH 15/15] Documentation: update notes in biovecs about

The changes to dm.c and dm.h should be in the "dm:" patch, not "md:".

But I don't think the sequence is right.

You cannot remove ->merge_bvec_fn for *any* stacked device until *all* devices
make use of blk_queue_split() (or otherwise handle arbitrarily large bios).

I think it would be easiest to:
 - add blk_queue_split() and call it from common code before ->make_request_fn
   is called.  The ensure all devices can accept arbitrarily large bios.
 - driver-by-driver remove merge_bvec_fn and make sure the the driver can cope
   with arbitrary bios themselve, calling blk_queue_split in the make_request
   function only if needed
 - finally remove the call to blk_queue_split from the common code.

Does that make sense to others?

Thanks,
NeilBrown

> 
> >
> > Thanks.
> >
> >>
> >> patch 1:
> >>
> >>  add ->bio_split and blk_queue_split
> >>
> >> patch 2..n:
> >>
> >>  one for each non-trivial driver that implements ->merge_bvec_fn to
> >>  remove it and instead split bios in ->make_request.  The md patch
> >>  to do the right thing in chunk_aligned_read goes into the general
> >>  md patch here.  The bcache patch also goes into this series.
> >>
> >> patch n+1:
> >>
> >>  - add blk_queue_split calls for remaining trivial drivers
> >>
> >> patch n+2:
> >>
> >>  - remove ->merge_bvec_fn and checking of max_sectors a for all
> >>drivers, simplify bio_add_page
> >>
> >> patch n+2:
> >>
> >>  - remove splitting in blkdev_issue_discard
> >>
> >> patch n+3
> >>
> >>  - remove bio_fits_rdev
> >>
> >> patch n+4
> >>
> >>  - remove bio_get_nr_vecs
> >>
> >> patch n+4
> >>
> >>  - use bio_add_page
> >>
> >> patch n+5
> >>
> >>  - update documentation



pgplT7k7DiGh_.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 06/11] md/raid5: get rid of bio_fits_rdev()

[NeilBrown]

On Tue, 26 May 2015 16:42:35 -0700 Ming Lin  wrote:

> On Tue, May 26, 2015 at 4:03 PM, NeilBrown  wrote:
> > On Tue, 26 May 2015 15:32:38 -0700 Ming Lin  wrote:
> >
> >> On Tue, May 26, 2015 at 7:33 AM, Ming Lin  wrote:
> >> > On Mon, May 25, 2015 at 7:17 AM, Christoph Hellwig  wrote:
> >> >> On Mon, May 25, 2015 at 05:54:14PM +1000, NeilBrown wrote:
> >> >>> Did I write that?  I guess I did :-(
> >> >>> I meant *after*.   Don't get rid of bio_fits_rdev until split_bio is in
> >> >>> chunk_aligned_read().
> >> >>
> >> >> I suspect the whole series could use some reordering.
> >> >
> >> > Nice reordering.
> >> > I'll do this.
> >>
> >> Here is the reordering.
> >> https://git.kernel.org/cgit/linux/kernel/git/mlin/linux.git/log/?h=block-generic-req
> >>
> >> I'll post it if you are OK.
> >>
> >> [PATCH 01/15] block: add blk_queue_split()
> >> [PATCH 02/15] md: remove ->merge_bvec_fn
> >> [PATCH 03/15] dm: remov merge functions
> >> [PATCH 04/15] drbd: remove ->merge_bvec_fn
> >> [PATCH 05/15] pktcdvd: remove ->merge_bvec_fn
> >> [PATCH 06/15] rbd: remove ->merge_bvec_fn
> >> [PATCH 07/15] bcache: remove driver private bio splitting code
> >> [PATCH 08/15] btrfs: remove bio splitting and merge_bvec_fn() calls
> >> [PATCH 09/15] block: call blk_queue_split() in make_request functions
> >> [PATCH 10/15] block: kill ->merge_bvec_fn and simplify bio_add_page
> >> [PATCH 11/15] block: remove split code in blkdev_issue_discard
> >> [PATCH 12/15] md/raid5: get rid of bio_fits_rdev()
> >> [PATCH 13/15] block: remove bio_get_nr_vecs()
> >> [PATCH 14/15] fs: use helper bio_add_page() instead of open coding on
> >> [PATCH 15/15] Documentation: update notes in biovecs about
> >
> > The changes to dm.c and dm.h should be in the "dm:" patch, not "md:".
> 
> Will move it.
> 
> >
> > But I don't think the sequence is right.
> >
> > You cannot remove ->merge_bvec_fn for *any* stacked device until *all* 
> > devices
> > make use of blk_queue_split() (or otherwise handle arbitrarily large bios).
> >
> > I think it would be easiest to:
> >  - add blk_queue_split() and call it from common code before 
> > ->make_request_fn
> >is called.  The ensure all devices can accept arbitrarily large bios.
> 
> For "common code", do you mean "generic_make_request()"
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index fbbb337..bb6455b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1942,6 +1942,7 @@ void generic_make_request(struct bio *bio)
> do {
> struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> 
> +   blk_queue_split(q, , q->bio_split);
> q->make_request_fn(q, bio);
> 
> bio = bio_list_pop(current->bio_list);

Yes, that is what I mean (assuming that is the only place that calls
->make_request_fn).

Thanks,
NeilBrown




pgpd4h2Fv2hcv.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios

[NeilBrown]

On Tue, 26 May 2015 16:34:14 +0100 Alasdair G Kergon  wrote:

> On Tue, May 26, 2015 at 08:02:08AM -0700, Ming Lin wrote:
> > Now bio_add_page() can build lager bios.
> > And blk_queue_split() can split the bios in ->make_request() if needed.
> 
> But why not try to make the bio the right size in the first place so you
> don't have to incur the performance impact of splitting?

Because we don't know what the "right" size is.  And the "right" size can
change when array reconfiguration happens.

Splitting has to happen somewhere, if only in bio_addpage where it decides to
create a new bio rather than add another page to the current one.  So moving
the split to a different level of the stack shouldn't necessarily change the
performance profile.

Obviously testing is important to confirm that.

NeilBrown

> 
> What performance testing have you yet done to demonstrate the *actual* impact
> of this patchset in situations where merge_bvec_fn is currently a net benefit?
> 
> Alasdair
> 
> --
> 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/



pgpo1HWsZRW3O.pgp
Description: OpenPGP digital signature

[GIT PULL REQUEST] more md bug fixes for 4.1-rc

[NeilBrown]

Hi Linus,
 please pull these fixes.
 I think raid5 is all working nicely again now.
 I think there is still a race somewhere in starting the recovery thread, but
 it is minor and I suspect I'll have it nailed soon.  Not quite this week
 though.

Thanks,
NeilBrown



The following changes since commit 8532e3439087de69bb1b71fd6be2baa6fc196a55:

  md/bitmap: remove rcu annotation from pointer arithmetic. (2015-05-21 
09:14:41 +1000)

are available in the git repository at:

  git://neil.brown.name/md/ tags/md/4.1-rc5-fixes

for you to fetch changes up to 56ccc1125bc141cf63927eda7febff4216dea2d3:

  md: fix race when unfreezing sync_action (2015-05-28 18:04:45 +1000)


Assorted fixes for new RAID5 stripe-batching functionality.

Unfortunately this functionality was merged a little prematurely.
The necessary testing and code review is now complete (or as
complete as it can be) and to code passes a variety of tests
and looks quite sensible.

Also a fix for some recent locking changes - a race was introduced
which causes a reshape request to sometimes fail.  No data safety issues.


NeilBrown (10):
  md/raid5: ensure whole batch is delayed for all required bitmap updates.
  md/raid5: close race between STRIPE_BIT_DELAY and batching.
  md/raid5: Ensure a batch member is not handled prematurely.
  md/raid5: remove condition test from check_break_stripe_batch_list.
  md/raid5: duplicate some more handle_stripe_clean_event code in 
break_stripe_batch_list
  md/raid5: add handle_flags arg to break_stripe_batch_list.
  md/raid5: be more selective about distributing flags across batch.
  md/raid5: call break_stripe_batch_list from handle_stripe_clean_event
  md/raid5: break stripe-batches when the array has failed.
  md: fix race when unfreezing sync_action

 drivers/md/md.c|  14 ++---
 drivers/md/raid5.c | 146 +++--
 drivers/md/raid5.h |   5 +-
 3 files changed, 98 insertions(+), 67 deletions(-)


pgpKrjcADkmIC.pgp
Description: OpenPGP digital signature

Re: [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses

[Guenter Roeck]

On Tue, Jun 02, 2015 at 09:06:15PM -0400, Vivien Didelot wrote:
> Hi Guenter,
> 
> On Jun 2, 2015, at 10:24 AM, Guenter Roeck li...@roeck-us.net wrote:
> On 06/01/2015 06:27 PM, Vivien Didelot wrote:
> >> This commit disables SA learning and refreshing for the CPU port.
> >>
> > 
> > Hi Vivien,
> > 
> > This patch also seems to be unrelated to the rest of the series.
> > 
> > Can you add an explanation why it is needed ?
> > 
> > With this in place, how does the CPU port SA find its way into the fdb ?
> > Do we assume that it will be configured statically ?
> > An explanation might be useful.
> 
> Without this patch, I noticed the CPU port was stealing the SA of a PC
> behind a switch port. this happened when the port was a bridge member,
> as the bridge was relaying broadcast coming from one switch port to the
> other switch ports in the same vlan.
> 
Makes me feel really uncomfortable. I think we may be going into the wrong
direction. The whole point of offloading bridging is to have the switch handle
forwarding, and that includes multicasts and broadcasts. Instead of doing that,
it looks like we put more and more workarounds in place.

Maybe the software bridge code needs to understand that it isn't support to
forward broadcasts to ports of an offloaded bridge, and we should let the
switch chip handle it ?

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

Re: LOCKDEP warning due to ext_devt_lock

[NeilBrown]

On Wed, 27 May 2015 21:32:21 -0600 Jens Axboe  wrote:

> On 05/27/2015 08:32 PM, NeilBrown wrote:
> >
> > Hi Keith,
> >   I'm getting lockdep warning around use of ext_devt_lock.
> >
> > [11428.266019] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> >
> >   As you say in
> >  2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
> > ext_devt_lock can be taken from call_rcu's soft-irq.
> > I think that means it should always use the _irq verion of spinlock.
> 
> Wouldn't spin_lock_bh() and friends suffice then?
> 

Quite possibly.  I've never actually used those so I don't tend to think
about them.  But only reflection I think they would be exactly right.
I'll modify my patch for future testing.

BTW, did you get my:

   [PATCH v2] block: discard bdi_unregister() in favour of bdi_destroy()

??  I haven't seen it appear in your 'block' tree.

Thanks,
NeilBrown


pgpzSkB0qfyat.pgp
Description: OpenPGP digital signature

LOCKDEP warning due to ext_devt_lock

[NeilBrown]

Hi Keith,
 I'm getting lockdep warning around use of ext_devt_lock.

[11428.266019] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.

 As you say in
2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
ext_devt_lock can be taken from call_rcu's soft-irq.
I think that means it should always use the _irq verion of spinlock.

I've been using the following patch and the LOCKDEP message are gone.

If you agree, could you forward it or something similar upstream?
Thanks,
NeilBrown


Signed-off-by: NeilBrown 
diff --git a/block/genhd.c b/block/genhd.c
index 666e11b83983..d1338934562e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -422,9 +422,9 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
/* allocate ext devt */
idr_preload(GFP_KERNEL);
 
-   spin_lock(_devt_lock);
+   spin_lock_irq(_devt_lock);
idx = idr_alloc(_devt_idr, part, 0, NR_EXT_DEVT, GFP_NOWAIT);
-   spin_unlock(_devt_lock);
+   spin_unlock_irq(_devt_lock);
 
idr_preload_end();
if (idx < 0)
@@ -449,9 +449,9 @@ void blk_free_devt(dev_t devt)
return;
 
if (MAJOR(devt) == BLOCK_EXT_MAJOR) {
-   spin_lock(_devt_lock);
+   spin_lock_irq(_devt_lock);
idr_remove(_devt_idr, blk_mangle_minor(MINOR(devt)));
-   spin_unlock(_devt_lock);
+   spin_unlock_irq(_devt_lock);
}
 }
 
@@ -690,13 +690,13 @@ struct gendisk *get_gendisk(dev_t devt, int *partno)
} else {
struct hd_struct *part;
 
-   spin_lock(_devt_lock);
+   spin_lock_irq(_devt_lock);
part = idr_find(_devt_idr, blk_mangle_minor(MINOR(devt)));
if (part && get_disk(part_to_disk(part))) {
*partno = part->partno;
disk = part_to_disk(part);
}
-   spin_unlock(_devt_lock);
+   spin_unlock_irq(_devt_lock);
}
 
return disk;


pgpMS4GUMWxq5.pgp
Description: OpenPGP digital signature

Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops

[Guenter Roeck]

On Tue, Jun 02, 2015 at 09:39:50PM -0400, Vivien Didelot wrote:
> Guenter,
> 
> On Jun 2, 2015, at 2:50 AM, Guenter Roeck li...@roeck-us.net wrote:
> > On 06/01/2015 06:27 PM, Vivien Didelot wrote:
> >> +/* Bringing an interface up adds it to the VLAN 0. Ignore this. */
> >> +if (!vid)
> >> +return 0;
> >> +
> > 
> > Me puzzled ;-). I brought this and the fid question up before.
> > No idea if my e-mail got lost or what happened.
> > 
> > Can you explain why we don't need a configuration for vlan 0 ?
> 
> Sorry for late reply. Initially, when issuing "ip link set up dev swp0",
> ndo_vlan_rx_add_vid was called to add the interface in the VLAN 0.
> 
Loading the 802.1q module has the same effect.

I think this may be on purpose; it is telling the switch to accept
packets with vid==0 (and untagged packets).

> 2 things happen here:
> 
>   * this is inconsistent with the "bridge vlan" output which doesn't seem to
> know about a VID 0;
>   * VID 0 seems special for this switch: if an ingressing frame has VID 0, the
> tagged port will override the VID bits with the port default VID at 
> egress.
> 
As far as I can see, the switch treats packets with vid==0 and untaged packets
as unknown if VLAN support is enabled.

Anyway, sounds odd. Sure this isn't a configuration problem somethere ?

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

Re: [PATCH 07/15] KVM: MTRR: improve kvm_mtrr_get_guest_memory_type

[Xiao Guangrong]

On 06/01/2015 05:16 PM, Paolo Bonzini wrote:



On 30/05/2015 12:59, Xiao Guangrong wrote:

  - kvm_mtrr_get_guest_memory_type() only checks one page in MTRRs so that
it's unnecessary to check to see if the range is partially covered in
MTRR

  - optimize the check of overlap memory type and add some comments to explain
the precedence

Signed-off-by: Xiao Guangrong 
---
  arch/x86/kvm/mtrr.c | 89 ++---
  1 file changed, 44 insertions(+), 45 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index bc9c6da..d3c06d2 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -231,24 +231,16 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
return 0;
  }

-/*
- * The function is based on mtrr_type_lookup() in
- * arch/x86/kernel/cpu/mtrr/generic.c
- */
-static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
-u64 start, u64 end)
+u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
  {
-   u64 base, mask;
-   u8 prev_match, curr_match;
-   int i, num_var_ranges = KVM_NR_VAR_MTRR;
+   struct kvm_mtrr *mtrr_state = >arch.mtrr_state;
+   u64 base, mask, start = gfn_to_gpa(gfn);
+   int i, num_var_ranges = KVM_NR_VAR_MTRR, type_mask, type = -1;


Do not mix initialized and uninitialized variables on the same line
(preexisting, I know, but let's fix it instead of making it worse :)).
Please put each initialized variable on a separate line.


Okay. Will follow this style in the future development.



Also please initialize type_mask here (more on this below).



/* MTRR is completely disabled, use UC for all of physical memory. */
if (!mtrr_state->mtrr_enabled)
return MTRR_TYPE_UNCACHABLE;

-   /* Make end inclusive end, instead of exclusive */
-   end--;
-
/* Look in fixed ranges. Just return the type as per start */
if (mtrr_state->fixed_mtrr_enabled && (start < 0x10)) {
int idx;
@@ -273,9 +265,9 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
 * Look of multiple ranges matching this address and pick type
 * as per MTRR precedence
 */
-   prev_match = 0xFF;
+   type_mask = (1 << MTRR_TYPE_WRBACK) | (1 << MTRR_TYPE_WRTHROUGH);
for (i = 0; i < num_var_ranges; ++i) {
-   unsigned short start_state, end_state;
+   int curr_type;

if (!(mtrr_state->var_ranges[i].mask & (1 << 11)))
continue;
@@ -283,50 +275,57 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
base = mtrr_state->var_ranges[i].base & PAGE_MASK;
mask = mtrr_state->var_ranges[i].mask & PAGE_MASK;

-   start_state = ((start & mask) == (base & mask));
-   end_state = ((end & mask) == (base & mask));
-   if (start_state != end_state)
-   return 0xFE;
-
if ((start & mask) != (base & mask))
continue;

-   curr_match = mtrr_state->var_ranges[i].base & 0xff;
-   if (prev_match == 0xFF) {
-   prev_match = curr_match;
+   /*
+* Please refer to Intel SDM Volume 3: 11.11.4.1 MTRR
+* Precedences.
+*/
+
+   curr_type = mtrr_state->var_ranges[i].base & 0xff;
+   if (type == -1) {
+   type = curr_type;
continue;
}

-   if (prev_match == MTRR_TYPE_UNCACHABLE ||
-   curr_match == MTRR_TYPE_UNCACHABLE)
+   /*
+* If two or more variable memory ranges match and the
+* memory types are identical, then that memory type is
+* used.
+*/
+   if (type == curr_type)
+   continue;
+
+   /*
+* If two or more variable memory ranges match and one of
+* the memory types is UC, the UC memory type used.
+*/
+   if (curr_type == MTRR_TYPE_UNCACHABLE)
return MTRR_TYPE_UNCACHABLE;

-   if ((prev_match == MTRR_TYPE_WRBACK &&
-curr_match == MTRR_TYPE_WRTHROUGH) ||
-   (prev_match == MTRR_TYPE_WRTHROUGH &&
-curr_match == MTRR_TYPE_WRBACK)) {
-   prev_match = MTRR_TYPE_WRTHROUGH;
-   curr_match = MTRR_TYPE_WRTHROUGH;
+   /*
+* If two or more variable memory ranges match and the
+* memory types are WT and WB, the WT memory type is used.
+*/
+   if (((1 << type) & type_mask) &&
+ ((1 << curr_type) & type_mask)) {


Please inline definition of type_mask in the "if", or rename it to
"wt_wb_mask" and make it 

[network feature request] Optimized sys_accept and sys_connect

[Alexey Syrnikov]

Hello, kernel developers.

Many network server (HTTP for example) currently work in such way:

  accept -> read (once) -> write (typically once) -> close

So, this sequence can be optimized by making accept and read in one
syscall. When socket ready to accept it can already have data (delivered
in 3-rd tcp packet in 3-way handshake with SYN+ACK). Making accept and
read at once we will

1) reduce syscalls (one in place of two)
2) reduce network latancy (at least for 1 mks, it is ~1000 CPU ticks for
syscall)
The cost: new syscall and bit of code

Because some protocols requires server at first send data to connected
client, this syscall can also do accept+write. This behavior can be
switched by some flag (accept+read or accept+write). I call it
sys_accept_plus :)

The same apply to connect+write. Network client at connecting stage
already knows which HTTP request they need to send. So making connect
and write in one syscall we will

1) make one syscall (not two)
2) reduce network latency
3) send GET request with the same (in most cases single) TCP packet as
last SYN+ACK without waiting sys_write (as in separate connect and write).
Costs are same: one extra syscall and bit of code.

This is sys_connect_plus.

I did not think about error reporting (userspace code need to know when
error happens at first or second stage and some errors have same codes).

What do You think about such feature?

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 05/15] KVM: MTRR: clean up mtrr default type

[Xiao Guangrong]

Thanks for your review, Paolo!


On 06/01/2015 05:11 PM, Paolo Bonzini wrote:


  struct kvm_vcpu_arch {
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 562341b..6de49dd 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -105,7 +105,6 @@ EXPORT_SYMBOL_GPL(kvm_mtrr_valid);
  static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
  {
struct kvm_mtrr *mtrr_state = >arch.mtrr_state;
-   unsigned char mtrr_enabled = mtrr_state->enabled;
gfn_t start, end, mask;
int index;
bool is_fixed = true;
@@ -114,7 +113,7 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
  !kvm_arch_has_noncoherent_dma(vcpu->kvm))
return;

-   if (!(mtrr_enabled & 0x2) && msr != MSR_MTRRdefType)
+   if (!mtrr_state->mtrr_enabled && msr != MSR_MTRRdefType)


I know Linus doesn't like bitfields too much.  Can you change these to
inline functions, and only leave an "u64 deftype" in the struct?



Sure. I will introduce mtrr_is_enabled() and fixed_mtrr_is_enabled() instead
of these bitfields.

--
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] MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers

[Leonid Yegoshin]

On 06/02/2015 04:56 PM, David Daney wrote:

On 06/02/2015 09:15 AM, Maciej W. Rozycki wrote:

On Tue, 2 Jun 2015, James Hogan wrote:



binutils appears to support the sync_mb, sync_rmb, sync_wmb aliases
since version 2.21. Can we safely use them?


  I suggest that we don't -- we still officially support binutils 
2.12 and
have other places where we even use `.word' to insert instructions 
current
versions of binutils properly handle.  It may be worth noting in a 
comment
though that these encodings correspond to these operations that you 
named.




Surely the other MIPSr6 instructions are not supported in binutils 
2.12 either.  So if it is for r6, why not require modern tools, and 
put something user readable in here?




No, it can be used for MIPS R2 also.

--
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/2] w1: unlock correct lock on error in w1_seq_show()

[Matt Campbell]

Thanks for the response, I will try to answer your questions.

The other function besides temp conversion and EEPROM write that
requires a delay is the initial CHAIN on command. The datasheet says
to "Wait for chain to charge" but it does not offer ANY indication on
how to do so.  I did discover that my sleep was a sleep(0) long after
I submitted the patch, but as you observed it was not hurting
anything.

The 64 was, in all honesty, a starting point that I picked for lack of
finding a better option.  I only currently have 10 sensors available
for me to test with, so I was not able to do any significant tests to
see what would happen if I raised that limit and the loop did not exit
properly at the end of the chain.  I was also not able to find an edge
case that would cause the loop to not find a match.  The w1_seq file
only shows for the one type sensor that supports it so in the absence
of a bus error, a match is guaranteed.

The output of the function in the event the pins are hooked up as GPIO
and not a chain is undefined.  Since the chips are very tiny,
prototyping this function would require me to design and order some
boards that I never was able to use.  To my knowledge it is not
possible to determine that things are wired this way in the software.

Apologies, this is my first foray in submitting any sort of kernel
code so I am not sure of exactly how I would submit a fixup patch for
gregkh's tree.  If someone wants to walk me through that off list I
would be most appreciative!
--m

Matt Campbell
mattrcampb...@gmail.com


On Tue, Jun 2, 2015 at 9:07 PM, David Fries  wrote:
> The source code is as good as it gets, that's why I posted those two
> lines from the w1.h file.  Maybe it could be expanded upon, mutex is
> more for adding or removing slaves and the like modifications to
> w1_master data structure, where bus_mutex is what make sure something
> else doesn't try to talk on the bus while the current device is using
> it.  What really matters is how other code is using the locks.  For
> instance if you look at w1_therm.c bus_mutex is the only one used.
> Then you look at what your routine is doing, and what the existing
> routine is doing, they are both reading/writing from the one wire bus,
> and then return their output to the user, so then use the same lock.
> If it's the wrong lock then it's at least consistent and easier to
> cleanup when someone figures out it's the wrong lock.  If you think
> it's the wrong lock raise a flag and ask.
>
> My patch review comments.
>
> The temperature sensor uses a strong pullup or delay of 750 ms to do
> the temperature conversion.  A quick read through of this sensor has
> temperature conversion and EEPROM write as the only operations
> requiring a significant time delay, everything else is in the us, so I
> would expect this to not require any delay.
>
> Read the comments to w1_next_pullup in w1_io.c as pullup_duration will
> always be 0 in msleep(sl->master->pullup_duration); which isn't likely
> what you expect.  Apparently it is working for you so that further
> reinforces my previous point.
>
> Where did the 64 come from?  I have 14 temperature sensors in my
> single family residence right now, and it would take another 7 to
> cover each area/room.  I could imagine an actual industrial setting to
> far exceed the 64 count, but I don't work in that area so I don't know
> the practical limits.  How long does it take to read if it loops
> through 64 times without finding a match?  What is reg_num value if a
> sensor doesn't reply?  If it is all 00's or all ff's would that be a
> better test for the end of the line?  How long would it take to loop
> 16384 times?  Maybe you stop if it reaches 16384 or if the end of line
> value is read 64 times.  I also assume this is pretty much a static
> answer, so you aren't going to be querying it except once per device,
> once per program setup and rarely or infrequently after that so the
> time shouldn't matter too much.  Maybe the program queries again if a
> sensor is detected or removed.
>
> I would like to see some documentation (comment) at the top of
> w1_seq_show as to what the sysfs number returns means.  I can see the
> variable is named seq, and it returns it as a signed number.  What
> does a negative value mean?  Are they expected?  Will the first device
> in the chain be 0 or 1, and what defines what end that is?  What kind
> of value is returned if the pins are connected as GPIO and not in the
> direct sequence configuration?  Maybe it needs a comment that all
> sensors of this type must be in the direct sequence configuration for
> this routine to give meaningful values.  "Place all devices in CHAIN
> state" that will address all devices including other types of devices,
> would you expect this to cause a problem with other devices?
>
> Line up the constants after #define to the same tab location before
> w1_seq_show.
>
> Do you plan to send in a mutex fixup patch?  In my experience gregkh's
> tree 

Re: [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

[Jiang Liu]

On 2015/6/3 3:19, Thomas Gleixner wrote:
> On Mon, 1 Jun 2015, Jiang Liu wrote:
> 
>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
>> index 9b62f690b0ff..dfa3a5f5b3d3 100644
>> --- a/arch/x86/kernel/apic/vector.c
>> +++ b/arch/x86/kernel/apic/vector.c
>> @@ -494,9 +494,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
>>  
>>  err = assign_irq_vector(irq, data, dest);
>>  if (err) {
>> -struct irq_data *top = irq_get_irq_data(irq);
>> -
>> -if (assign_irq_vector(irq, data, top->affinity))
>> +if (assign_irq_vector(irq, data,
>> +  irq_data_get_affinity_mask(irq_data)))
> 
> Does this patch work w/o moving the affinity mask to common data? I
> doubt so, as you remove the retrieval of 'top'.
Hi Thomas,
This piece of code should be moved into [31/36], otherwise
it will break bisecting. I will redo patch this and [31/36] to
support bisecting.
Thanks!
Gerry

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

Re: [RFC 6/9] net: dsa: mv88e6352: allow egress of unknown multicast

[Vivien Didelot]

Hi Guenter,

On Jun 2, 2015, at 10:20 AM, Guenter Roeck li...@roeck-us.net wrote:
> On 06/01/2015 06:27 PM, Vivien Didelot wrote:
>> This patch disables egress of unknown unicast destination addresses.
>>
> 
> Hi Vivien,
> 
> seems to me this patch is unrelated to the rest of the series.
> 
> Not sure if we really want this. If an address is in the arp cache
> but has timed out from the bridge database, any unicast to that address
> will no longer be sent. If the bridge database has been flushed for some
> reason, such as a spanning tree reconfiguration, we'll have a hard time
> to send anything.
> 
> What is the problem you are trying to solve with this patch ?

TBH, I don't remember which one of the test cases I described in 0/9
this patch was solving... Some ARP request didn't propagate correctly
without this, IIRC.

I'll try to revert the change and do my tests again in order to isolate
the problem.

Thanks,
-v
--
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] Fix typo in the comment

[명혁]

This patch fix a spelling typo in the comment in synclink.c and
synclinkmp.c.

Signed-off-by: Hyuk Myeong 
---
 drivers/tty/synclink.c   | 4 ++--
 drivers/tty/synclinkmp.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/synclink.c b/drivers/tty/synclink.c
index b799170..3bbb07c 100644
--- a/drivers/tty/synclink.c
+++ b/drivers/tty/synclink.c
@@ -7468,9 +7468,9 @@ static bool mgsl_memory_test( struct mgsl_struct
*info )
  * memory.
  * 
  * This function in effect, breaks the a large shared memory write
- * into multiple transations by interleaving a shared memory read
+ * into multiple transactions by interleaving a shared memory read
  * which will flush the write FIFO and 'complete' the write
- * transation. This allows any pending DMA request to gain control
+ * transaction. This allows any pending DMA request to gain control
  * of the local bus in a timely fasion.
  * 
  * Arguments:
diff --git a/drivers/tty/synclinkmp.c b/drivers/tty/synclinkmp.c
index c3f9091..2ffcfe4 100644
--- a/drivers/tty/synclinkmp.c
+++ b/drivers/tty/synclinkmp.c
@@ -5415,9 +5415,9 @@ static bool memory_test(SLMP_INFO *info)
  * and does not release the bus. This causes DMA latency problems
  * at high speeds when copying large data blocks to the shared memory.
  *
- * This function breaks a write into multiple transations by
+ * This function breaks a write into multiple transactions by
  * interleaving a read which flushes the write FIFO and 'completes'
- * the write transation. This allows any pending DMA request to gain
control
+ * the write transaction. This allows any pending DMA request to gain
control
  * of the local bus in a timely fasion.
  */
 static void load_pci_memory(SLMP_INFO *info, char* dest, const char* src,
unsigned short count)
-- 
1.9.3

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

Re: [RFC 2/4] mm/balloon: apply driver page migratable into balloon driver

[Konstantin Khlebnikov]

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim  wrote:
> Apply driver page migration into balloon driver.
>
> Signed-off-by: Gioh Kim 
> ---
>  drivers/virtio/virtio_balloon.c|  2 ++
>  fs/proc/page.c |  4 +--
>  include/linux/balloon_compaction.h | 42 ---
>  include/linux/mm.h | 19 ---
>  include/uapi/linux/kernel-page-flags.h |  2 +-
>  mm/balloon_compaction.c| 61 
> --
>  6 files changed, 94 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 6a356e3..cdd0038 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -496,6 +496,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
> balloon_devinfo_init(>vb_dev_info);
>  #ifdef CONFIG_BALLOON_COMPACTION
> vb->vb_dev_info.migratepage = virtballoon_migratepage;
> +   vb->vb_dev_info.mapping = balloon_mapping_alloc(>vb_dev_info,
> +   _aops);
>  #endif
>
> err = init_vqs(vb);
> diff --git a/fs/proc/page.c b/fs/proc/page.c
> index 7eee2d8..e741307 100644
> --- a/fs/proc/page.c
> +++ b/fs/proc/page.c
> @@ -143,8 +143,8 @@ u64 stable_page_flags(struct page *page)
> if (PageBuddy(page))
> u |= 1 << KPF_BUDDY;
>
> -   if (PageBalloon(page))
> -   u |= 1 << KPF_BALLOON;
> +   if (PageMigratable(page))
> +   u |= 1 << KPF_MIGRATABLE;
>
> u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
>
> diff --git a/include/linux/balloon_compaction.h 
> b/include/linux/balloon_compaction.h
> index 9b0a15d..0989e96 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -48,6 +48,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   * Balloon device information descriptor.
> @@ -62,6 +63,7 @@ struct balloon_dev_info {
> struct list_head pages; /* Pages enqueued & handled to Host */
> int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
> struct page *page, enum migrate_mode mode);
> +   struct address_space *mapping;
>  };
>
>  extern struct page *balloon_page_enqueue(struct balloon_dev_info 
> *b_dev_info);
> @@ -73,24 +75,37 @@ static inline void balloon_devinfo_init(struct 
> balloon_dev_info *balloon)
> spin_lock_init(>pages_lock);
> INIT_LIST_HEAD(>pages);
> balloon->migratepage = NULL;
> +   balloon->mapping = NULL;
>  }
>
>  #ifdef CONFIG_BALLOON_COMPACTION
> -extern bool balloon_page_isolate(struct page *page);
> +extern const struct address_space_operations balloon_aops;
> +extern bool balloon_page_isolate(struct page *page,
> +isolate_mode_t mode);
>  extern void balloon_page_putback(struct page *page);
> -extern int balloon_page_migrate(struct page *newpage,
> +extern int balloon_page_migrate(struct address_space *mapping,
> +   struct page *newpage,
> struct page *page, enum migrate_mode mode);
>
> +extern struct address_space
> +*balloon_mapping_alloc(struct balloon_dev_info *b_dev_info,
> +  const struct address_space_operations *a_ops);
> +
> +static inline void balloon_mapping_free(struct address_space 
> *balloon_mapping)
> +{
> +   kfree(balloon_mapping);
> +}
> +
>  /*
> - * __is_movable_balloon_page - helper to perform @page PageBalloon tests
> + * __is_movable_balloon_page - helper to perform @page PageMigratable tests
>   */
>  static inline bool __is_movable_balloon_page(struct page *page)
>  {
> -   return PageBalloon(page);
> +   return PageMigratable(page);
>  }
>
>  /*
> - * balloon_page_movable - test PageBalloon to identify balloon pages
> + * balloon_page_movable - test PageMigratable to identify balloon pages
>   *   and PagePrivate to check that the page is not
>   *   isolated and can be moved by compaction/migration.
>   *
> @@ -99,7 +114,7 @@ static inline bool __is_movable_balloon_page(struct page 
> *page)
>   */
>  static inline bool balloon_page_movable(struct page *page)
>  {
> -   return PageBalloon(page) && PagePrivate(page);
> +   return PageMigratable(page) && PagePrivate(page);
>  }
>
>  /*
> @@ -108,7 +123,7 @@ static inline bool balloon_page_movable(struct page *page)
>   */
>  static inline bool isolated_balloon_page(struct page *page)
>  {
> -   return PageBalloon(page);
> +   return PageMigratable(page);
>  }
>
>  /*
> @@ -123,7 +138,8 @@ static inline bool isolated_balloon_page(struct page 
> *page)
>  static inline void balloon_page_insert(struct balloon_dev_info *balloon,
>struct page *page)
>  {
> -   __SetPageBalloon(page);
> +   page->mapping = balloon->mapping;
> +  

Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops

[Vivien Didelot]

Guenter,

On Jun 2, 2015, at 2:50 AM, Guenter Roeck li...@roeck-us.net wrote:
> On 06/01/2015 06:27 PM, Vivien Didelot wrote:
>> +/* Bringing an interface up adds it to the VLAN 0. Ignore this. */
>> +if (!vid)
>> +return 0;
>> +
> 
> Me puzzled ;-). I brought this and the fid question up before.
> No idea if my e-mail got lost or what happened.
> 
> Can you explain why we don't need a configuration for vlan 0 ?

Sorry for late reply. Initially, when issuing "ip link set up dev swp0",
ndo_vlan_rx_add_vid was called to add the interface in the VLAN 0.

2 things happen here:

  * this is inconsistent with the "bridge vlan" output which doesn't seem to
know about a VID 0;
  * VID 0 seems special for this switch: if an ingressing frame has VID 0, the
tagged port will override the VID bits with the port default VID at egress.

Thanks,
-v
--
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/1] mtd: nand_bbt: separate struct nand_chip from nand_bbt.c

[peterpandong]

Ping
> 
> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> onenand has own bbt(onenand_bbt.c).
> 
> Parameterize a few relevant device detail information into a new
> nand_bbt struct, and set some hooks for chip specified part. Allocate
> and initialize struct nand_bbt in nand_base.c.
> 
> Most of the patch is borrowed from Brian Norris
> .
> http://git.infradead.org/users/norris/linux-
> mtd.git/shortlog/refs/heads/nand-bbt
> 
> Signed-off-by: Peter Pan 
> Signed-off-by: Brian Norris 
> ---
>  drivers/mtd/nand/docg4.c |   8 +-
>  drivers/mtd/nand/nand_base.c | 145 +++-
>  drivers/mtd/nand/nand_bbt.c  | 518 +--
> 
>  include/linux/mtd/bbm.h  |  96 +---
>  include/linux/mtd/nand.h |  11 +-
>  include/linux/mtd/nand_bbt.h | 160 +
>  6 files changed, 516 insertions(+), 422 deletions(-)
>  create mode 100644 include/linux/mtd/nand_bbt.h
> 

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

[GIT PULL] extcon next for 4.2

[Chanwoo Choi]

Dear Greg,

This is extcon-next full request for v4.2. I add detailed description of this
pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:

  Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.2

for you to fetch changes up to f8df88081183bd4d3c461c617c3519445eb85642:

  extcon: Remove optional print_name() function pointer of extcon_dev 
(2015-05-29 19:56:11 +0900)


Update extcon for v4.2

This patchset include the huge update of extcon core and add the new one extcon
driver and fix minor isseu of extcon drivers.

Detailed description for patchset:
1. Update the extcon core.
- Modify the extcon device name on sysfs from device name name to 'extcon[X]'
as following because if same extcon device are included in H/W development 
board,
the one of the two device driver might be failed on the probe().
: /sys/class/extcon/[device name] -> /sys/class/extcon/extcon[X]

- Use the unique id for external connectors instead of legacy string name.
Previously, extcon used the string name to identify the type of external
connectors. This way have the many potential issues. So, extcon core define the
unique id for each external connectors as following:

enum extcon {
EXTCON_NONE = 0x0,

/* USB external connector */
EXTCON_USB  = 0x1,
EXTCON_USB_HOST = 0x2,

/* Charger external connector */
EXTCON_TA   = 0x10,
EXTCON_FAST_CHARGER = 0x11,
EXTCON_SLOW_CHARGER = 0x12,
EXTCON_CHARGE_DOWNSTREAM = 0x13,

/* Audio and video external connector */
EXTCON_LINE_IN  = 0x20,
EXTCON_LINE_OUT = 0x21,
EXTCON_MICROPHONE   = 0x22,
EXTCON_HEADPHONE= 0x23,
...
};

- Update tye prototype of extcon_register_notifier() by using the unique id
(enum extcon) of external connectors.

- Add extcon_get_edev_name() API to get the name of extcon device on extcon
client driver because the name is included in 'struct extcon_dev' and 'struct
extcon_dev' should be handled in only drivers/extcon directory. So. if extcon
client need the name of extcon device, they could use this function.

- Unify the jig/dock and MHL-TA cable name on extcon driver.
: JIG-{USB-ON|USB-OFF|UART-ON|UART-OFF} -> JIG
: Dock-{Smart|Desk|Audio|Card} -> DOCK
: MHL-TA -> TA

- Use the capital letter for the name of all external connectors.
- Remove the optional print_name() function pointer from struct extcon_dev to
maintain the consistent name of extcon device.

2. Add the new extcon-axp288.c extcon driver.
- The extcon-axp288.c driver support for AXP288 PMIC which has the BC1.2
charger detection capability. So this extcon driver can detect the
EXTCON_SLOW_CHARGER, EXTCON_CHARGE_DOWNSTREAM and EXTCON_FAST_CHARGER.

3. Update the extcon-arizona.c driver.
- Add support for selective detection mode when headphone detection.
- Apply HP clamps for WM8280

4. Clean-up the extcon core and drivers.
- Add manufactor information of each extcon device.
- Fix checkpatch warning and minor coding style on extcon.c.c
- Fix build break if GPIOLIB is not enabled on extcon-usb-gpiio.c.
- Set the direction of gpio when calling devm_gpiod_get() on extcon-usb-gpio.c


Chanwoo Choi (14):
  extcon: Add manufactor name of each extcon device
  extcon: Modify the device name as extcon[X] for sysfs
  extcon: Add extcon_get_edev_name() API to get the extcon device name
  extcon: Fix the checkpatch warning and minor coding style issue
  extcon: arizona: Remove the setting of device name
  extcon: Unify the jig cable names on rt8973 and max14577/77693/77843
  extcon: Unify the dock device names on max8997/77693
  extcon: Alter MHL-TA cable name to TA cable name
  extcon: adc-jack: Remove the unneeded num_cables field
  extcon: Remove the optional name of extcon device
  extcon: Use the unique id for external connector instead of string
  extcon: Use capital letter for the name of external connectors
  extcon: Update the prototype of extcon_register_notifier() with enum 
extcon
  extcon: Remove optional print_name() function pointer of extcon_dev

Charles Keepax (1):
  extcon: arizona: Apply HP clamps correctly for WM8280

Geert Uytterhoeven (1):
  extcon: Allow compile test of GPIO consumers if !GPIOLIB

Inha Song (2):
  extcon: arizona: Add support for select accessory detect mode when 
headphone detection
  mfd: arizona: Update DT binding 

Re: [PATCH v2 1/4] drivers/rtc/pcf8563: Replace deprecated rtc_time_to_tm() and rtc_tm_to_time()

[pang . xunlei]

Hi Alexandre,

Alexandre Belloni  wrote 2015-06-03 
AM 12:41:25:
> Re: [PATCH v2 1/4] drivers/rtc/pcf8563: Replace deprecated 
> rtc_time_to_tm() and rtc_tm_to_time()
> 
> On 03/06/2015 at 00:23:40 +0900, pang.xun...@zte.com.cn wrote :
> > Apologies for the spamming, please ignore all those former 27 pending 
> > patches.
> > 
> > I'll re-organize them with a cover letter, will resend them as new 
ones 
> > tomorrow.
> > 
> 
> Or maybe, instead of resending, you can give me the status of those
> patches:

Ok, I'll use a cover letter in future ones like so.

> 415468 [RFC,2/4] rtc: Convert rtc_class_ops.set_mmss() to use time64_t
> 415470 [RFC,3/4] rtc/lib: Provide interfaces to map between 32bit 
> hardware and 64bit time
> 428475 [RFC,v2,2/9] time: Provide y2106 safe get_seconds() replacement
> 431162 [1/3] time: Don't bother to run rtc_resume() for nonstop 
clocksource
> 431649 [1/5] drivers/rtc/interface.c: Update code to use y2038-safe 
> time interfaces
> 431650 [2/5] drivers/rtc/rtc-dev.c: Update code to use y2038-safe 
> time interfaces
> 431798 [v2,3/3] time: clocksource: Add a comment to 
> CLOCK_SOURCE_SUSPEND_NONSTOP
> 434592 [v3,1/2] time: Don't bother to run rtc_resume() for the 
> nonstop clocksource
> 448780 [5/8] ARM: tegra: clock: Provide y2038-safe 
> tegra_read_persistent_clock() replacement
> 448782 [6/8] ARM: time: Provide read_boot_clock64() and 
> read_persistent_clock64()
> 448781 [7/8] s390: time: Provide read_boot_clock64() and 
> read_persistent_clock64()
> 448783 [8/8] time: Remove read_boot_clock()

The above had already been merged into upstream, at least I can see them
in tip/master now.

> 
> You just sent those so I guess I still have to review them:
> 477947 [RESEND,1/3] drivers/rtc/pcf8563: Replace deprecated 
> rtc_time_to_tm() and rtc_tm_to_time()
> 477949 [RESEND,2/3] drivers/rtc/isl1208: Replace deprecated 
rtc_tm_to_time()
> 477948 [RESEND,3/3] drivers/rtc/sunxi: Replace deprecated 
rtc_tm_to_time()


Patch series below is about replacing deprecated 
rtc_tm_to_time()/rtc_time_to_tm()
mostly in rtc drivers with their y2038-safe substitutes 
rtc_tm_to_time64()/
rtc_time64_to_tm() which were merged into upstream last year.

> 479350 [v2,1/4] drivers/rtc/pcf8563: Replace deprecated 
> rtc_time_to_tm() and rtc_tm_to_time()
> 479348 [v2,2/4] rtc/lib: Introduce rtc_tm_subtract() helper function
> 479351 [v2,3/4] drivers/rtc/isl1208: Replace deprecated rtc_tm_to_time()
> 479349 [v2,4/4] drivers/rtc/sunxi: Replace deprecated rtc_tm_to_time()

And in the following one, I want to replace all the xxx_persistent_clock()
architecture implementations with xxx_persistent_clock64() or simply 
remove
it if can(mainly for rtc-related persistent clock).

> 479360 [v2,1/4] NTP: rtc: Add CONFIG_RTC_SYSTOHC_DEVICE for NTP 
> synchronization
> 479359 [v2,2/4] sparc: time: Replace update_persistent_clock() with 
> CONFIG_RTC_SYSTOHC
> 479358 [v2,3/4] drivers/rtc/interface.c: Remove rtc_set_mmss()
> 479357 [v2,4/4] cris: time: Cleanup of persistent clock stuff
> 
> Many thanks for your work.

I think you can only review the two v2 series :-)

-Xunlei


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
--
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 v5 03/30] tools build: Add feature check for eBPF API

[Wangnan (F)]

On 2015/6/3 6:11, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 01, 2015 at 07:37:49AM +, Wang Nan escreveu:

In this patch, eBPF API is checked by compiling a c source file which
uses fields in bpf_attr which will be used by libbpf.

Something is missing, where is the message saying that I need to install
something to have bpf support? Look at the liblzma one at config/Makefile:556:

[acme@zoo linux]$ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; m
make: Entering directory '/home/git/linux/tools/perf'
   BUILD:   Doing 'make -j4' parallel build

Auto-detecting system features:
... dwarf: [ OFF ]
... glibc: [ on  ]
...  gtk2: [ on  ]
...  libaudit: [ OFF ]
...libbfd: [ on  ]
...libelf: [ OFF ]
...   libnuma: [ OFF ]
...   libperl: [ on  ]
... libpython: [ OFF ]
...  libslang: [ OFF ]
... libunwind: [ OFF ]
...libdw-dwarf-unwind: [ OFF ]
...  zlib: [ OFF ]
...  lzma: [ OFF ]
...   bpf: [ OFF ]

config/Makefile:245: No libelf found, disables 'probe' tool, please install 
elfutils-libelf-devel/libelf-dev
config/Makefile:325: Disabling post unwind, no support found.
config/Makefile:366: No libaudit.h found, disables 'trace' tool, please install 
audit-libs-devel or libaudit-dev
config/Makefile:381: slang not found, disables TUI support. Please install 
slang-devel or libslang-dev
config/Makefile:466: No 'Python.h' (for Python 2.x support) was found: disables 
Python support - please install python-devel/python-dev
config/Makefile:556: No liblzma found, disables xz kernel module decompression, 
please install xz-devel/liblzma-dev
config/Makefile:569: No numa.h found, disables 'perf bench numa mem' benchmark, 
please install numactl-devel/libnuma-devel/libnuma-dev
   MKDIR/tmp/build/perf/util/
   CC   /tmp/build/perf/util/abspath.o


Those messages are printed by perf's makefile. I'll add them in patch 
23/30 'perf tools: Make perf
depend on libbpf'. I think error message in this patch is not required, 
because other feature checks

are also silent when it found something is missing.



Applied the first two patches in this series, will push them soon.


Do you want me to repost a full v6 series with those error messages 
added or only repost a v6 of 23/30

by replying the v5 patch?

Thank you.



- Arnaldo



--
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 5/9] net: dsa: mv88e6352: disable mirroring

[Vivien Didelot]

Hi Guenter, Andrew,

On Jun 2, 2015, at 10:53 AM, Andrew Lunn and...@lunn.ch wrote:
On Tue, Jun 02, 2015 at 07:16:10AM -0700, Guenter Roeck wrote:
>> On 06/01/2015 06:27 PM, Vivien Didelot wrote:
>> >Disable the mirroring policy in the monitor control register, since this
>> >feature is not needed.
>> >
>> >Signed-off-by: Vivien Didelot 
>> 
>> Should this be a separate patch, unrelated to the patch set ?

Indeed, this one is an unrelated patch, sorry.

>> If I understand correctly, this effectively disables IGMP/MLD snooping.
>> I think this warrants an explanation why that it not needed, not just
>> a statement that it is not needed.
> 
> +1
> 
> Especially since we might want to revisit this to implement IGMP/MLD
> snooping in the bridge. The hardware should be capable of it.

This is something I want to disable because I can have several times
gigabit traffic on my ports. This would end up in a bottleneck on the
CPU port. Am I right?

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

Re: [PATCH v1 7/9]powerpc/powernv: Event attr creation and PMU registration

[Daniel Axtens]

On Tue, 2015-06-02 at 21:29 +0530, Madhavan Srinivasan wrote:
> Patch adds common event attribute function and Nest pmu registration call.
> 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Sukadev Bhattiprolu 
> Cc: Anshuman Khandual 
> Cc: Stephane Eranian 
> Signed-off-by: Madhavan Srinivasan 
> ---
>  arch/powerpc/perf/nest-pmu.c | 52 
> 
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
> index 514a0be..dd84fd7 100644
> --- a/arch/powerpc/perf/nest-pmu.c
> +++ b/arch/powerpc/perf/nest-pmu.c
> @@ -244,6 +244,49 @@ static int update_pmu_ops(struct nest_pmu *pmu)
>   return 0;
>  }
>  
> +/*
> + * Populate event name and string in attribute
> + */
> +struct attribute *dev_str_attr(char *name, char *str)
> +{
> + struct perf_pmu_events_attr *attr;
> +
> + attr = kzalloc(sizeof(*attr), GFP_KERNEL);
> +
> + attr->event_str = (const char *)str;
Erk. Two things:
 - Is str const or not? If you're treating it as const here, should you
pass that through the function signature?
 - Who is responsible for the memory behind it? It looks like a caller
can't construct str dynamically, pass it to this function and then free
it, because that will invalidate attr->event_str. Is this documented?

> + attr->attr.attr.name = name;
> + attr->attr.attr.mode = 0444;
> + attr->attr.show = perf_event_sysfs_show;
> +
> + return >attr.attr;
If you're returning the address of attr->attr.attr, then:
 - why don't you just deal directly with struct attribute * in the
function? Why an entire struct perf_pmu_events_attr *?
 - with the function as written, if you return just >attr.attr,
don't attr->event_str and attr->attr.show get lost?

> +}
> +
> +int update_events_in_group(
> + struct ppc64_nest_ima_events *p8_events, int idx,
> + struct nest_pmu *pmu)
> +{
> + struct attribute_group *attr_group;
> + struct attribute **attrs;
> + int i;
> +
> + attr_group = kzalloc(((sizeof(struct attribute *) * (idx + 1)) +
> + sizeof(*attr_group)), GFP_KERNEL);
> + if (!attr_group)
> + return -ENOMEM;
> +
> + attrs = (struct attribute **)(attr_group + 1);
> + attr_group->name = "events";
> + attr_group->attrs = attrs;
> +
> + for (i=0; i< idx; i++, p8_events++)
> + attrs[i] = dev_str_attr((char *)p8_events->ev_name,
> + (char *)p8_events->ev_value);
> +
> + pmu->attr_groups[0] = attr_group;
> + return 0;
> +}
I'm very confused by what this function is trying to do. Could you add
some comments? I'm particularly confused by the relationship between
attrs and attr_group.

> +
> +
>  static int nest_pmu_create(struct device_node *dev, int pmu_index)
>  {
>   struct ppc64_nest_ima_events **p8_events_arr;
> @@ -364,6 +407,15 @@ static int nest_pmu_create(struct device_node *dev, int 
> pmu_index)
>   }
>   }
>  
> + update_events_in_group(
> + (struct ppc64_nest_ima_events *)p8_events_arr,
> + idx, pmu_ptr);
> + update_pmu_ops(pmu_ptr);
> +
> + /* Register the pmu */
> + perf_pmu_register(_ptr->pmu, pmu_ptr->pmu.name, -1);
> + printk(KERN_INFO "Nest PMU %s Registered\n", pmu_ptr->pmu.name);
> +
>   return 0;
>  }
>  

Regards,
Daniel



signature.asc
Description: This is a digitally signed message part

Re: [patch 2/2] w1: unlock correct lock on error in w1_seq_show()

[David Fries]

The source code is as good as it gets, that's why I posted those two
lines from the w1.h file.  Maybe it could be expanded upon, mutex is
more for adding or removing slaves and the like modifications to
w1_master data structure, where bus_mutex is what make sure something
else doesn't try to talk on the bus while the current device is using
it.  What really matters is how other code is using the locks.  For
instance if you look at w1_therm.c bus_mutex is the only one used.
Then you look at what your routine is doing, and what the existing
routine is doing, they are both reading/writing from the one wire bus,
and then return their output to the user, so then use the same lock.
If it's the wrong lock then it's at least consistent and easier to
cleanup when someone figures out it's the wrong lock.  If you think
it's the wrong lock raise a flag and ask.

My patch review comments.

The temperature sensor uses a strong pullup or delay of 750 ms to do
the temperature conversion.  A quick read through of this sensor has
temperature conversion and EEPROM write as the only operations
requiring a significant time delay, everything else is in the us, so I
would expect this to not require any delay.

Read the comments to w1_next_pullup in w1_io.c as pullup_duration will
always be 0 in msleep(sl->master->pullup_duration); which isn't likely
what you expect.  Apparently it is working for you so that further
reinforces my previous point.

Where did the 64 come from?  I have 14 temperature sensors in my
single family residence right now, and it would take another 7 to
cover each area/room.  I could imagine an actual industrial setting to
far exceed the 64 count, but I don't work in that area so I don't know
the practical limits.  How long does it take to read if it loops
through 64 times without finding a match?  What is reg_num value if a
sensor doesn't reply?  If it is all 00's or all ff's would that be a
better test for the end of the line?  How long would it take to loop
16384 times?  Maybe you stop if it reaches 16384 or if the end of line
value is read 64 times.  I also assume this is pretty much a static
answer, so you aren't going to be querying it except once per device,
once per program setup and rarely or infrequently after that so the
time shouldn't matter too much.  Maybe the program queries again if a
sensor is detected or removed.

I would like to see some documentation (comment) at the top of
w1_seq_show as to what the sysfs number returns means.  I can see the
variable is named seq, and it returns it as a signed number.  What
does a negative value mean?  Are they expected?  Will the first device
in the chain be 0 or 1, and what defines what end that is?  What kind
of value is returned if the pins are connected as GPIO and not in the
direct sequence configuration?  Maybe it needs a comment that all
sensors of this type must be in the direct sequence configuration for
this routine to give meaningful values.  "Place all devices in CHAIN
state" that will address all devices including other types of devices,
would you expect this to cause a problem with other devices?

Line up the constants after #define to the same tab location before
w1_seq_show.

Do you plan to send in a mutex fixup patch?  In my experience gregkh's
tree only accepts patches to what is already there, he won't swap out a
patch he already has (he could as it isn't in Linus's tree, but he
doesn't).

On Tue, Jun 02, 2015 at 08:35:41AM -0400, Matt Campbell wrote:
> David, not arguing just curious how you decide which lock to use?  Is there
> a standard documented?
> 
> --m
> 
> Matt Campbell
> mattrcampb...@gmail.com
> 
> On Tue, Jun 2, 2015 at 8:12 AM, David Fries  wrote:
> 
> > Thanks for including me, I'm going to have to nack this though, it is
> > an error, but bus_mutex is correct, mutex is incorrect, so the other
> > two lock/unlock in that routine are the ones that need to be changed.
> >
> > w1.h
> >  * @mutex:  protect most of w1_master
> >  * @bus_mutex:  pretect concurrent bus access
> >
> > On Mon, Jun 01, 2015 at 12:56:32PM +0300, Dan Carpenter wrote:
> > > Smatch complains that we don't unlock "master->mutex" on this error
> > > path.  It looks like it is a typo and we unlock ->bus_mutext where
> > > ->mutex was intended.
> > >
> > > Fixes: d9411e57dc7f ('w1: Add support for DS28EA00 sequence to w1-therm')
> > > Signed-off-by: Dan Carpenter 
> > >
> > > diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> > > index 3351be6..79ecaf8 100644
> > > --- a/drivers/w1/slaves/w1_therm.c
> > > +++ b/drivers/w1/slaves/w1_therm.c
> > > @@ -412,7 +412,7 @@ static ssize_t w1_seq_show(struct device *device,
> > >   c -= snprintf(buf + PAGE_SIZE - c, c, "%d\n", seq);
> > >   return PAGE_SIZE - c;
> > >  error:
> > > - mutex_unlock(>master->bus_mutex);
> > > + mutex_unlock(>master->mutex);
> > >   return -EIO;
> > >  }
> > >
> >
> > --
> > David Fries 
> >

-- 
David Fries 
--
To 

Re: [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses

[Vivien Didelot]

Hi Guenter,

On Jun 2, 2015, at 10:24 AM, Guenter Roeck li...@roeck-us.net wrote:
On 06/01/2015 06:27 PM, Vivien Didelot wrote:
>> This commit disables SA learning and refreshing for the CPU port.
>>
> 
> Hi Vivien,
> 
> This patch also seems to be unrelated to the rest of the series.
> 
> Can you add an explanation why it is needed ?
> 
> With this in place, how does the CPU port SA find its way into the fdb ?
> Do we assume that it will be configured statically ?
> An explanation might be useful.

Without this patch, I noticed the CPU port was stealing the SA of a PC
behind a switch port. this happened when the port was a bridge member,
as the bridge was relaying broadcast coming from one switch port to the
other switch ports in the same vlan.

Thanks,
-v
--
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: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

[Wu, Feng]

> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Tuesday, June 02, 2015 9:59 PM
> To: Wu, Feng
> Cc: j...@8bytes.org; dw...@infradead.org; jiang@linux.intel.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for
> intel_ir_chip
> 
> On Wed, 27 May 2015, Feng Wu wrote:
> > +   /* stop posting interrupts, back to remapping mode */
> > +   if (!vcpu_info) {
> > +   modify_irte(_data->irq_2_iommu, _data->irte_entry);
> > +   } else {
> > +   vcpu_pi_info = (struct vcpu_data *)vcpu_info;
> > +
> > +   /*
> > +* "ir_data->irte_entry" saves the remapped format of IRTE,
> > +* which being a cached irte is still updated when setting
> > +* the affinity even when we are in posted mode. So this make
> 
> s/make/makes/
> 
> > +* it possible to switch back to remapped mode from posted mode,
> > +* we can just set "ir_data->irte_entry" to hardware for that
> > +* purpose. Here we store the posted format of IRTE in another
> > +* new member "ir_data->irte_pi_entry" to not corrupt
> 
> Remove the 'another new member' please. That member is not longer new
> once that patch is applied.
> 
> Now there is another question. Are we actually using that pi_entry
> cached value for anything else than this code here? If not, we can do
> this on the stack and avoid the extra storage in ir_data.
> 

That's a good comments. I also thought about this before. Right now the cached 
value
is only used here in this function, but I am not sure whether we need it in 
future. Anyway,
I think we can delete it now.

Thanks,
Feng


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

Re: [PATCH 2/2] ARM: multi_v7_defconfig: Enable display on Trats2board

[Kukjin Kim]

On 05/24/15 05:27, Arnd Bergmann wrote:
> On Saturday 23 May 2015 11:18:58 Kukjin Kim wrote:
>> On 05/22/15 18:11, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 05/22/2015 02:48 AM, Krzysztof Kozlowski wrote:
 Enable the Exynos DSI and S6E8AA0 panel for full X11 display on Trats2.

 Signed-off-by: Krzysztof Kozlowski 
 ---
  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 0848337a2a01..e9785020aab1 100644
 --- a/arch/arm/configs/multi_v7_defconfig
 +++ b/arch/arm/configs/multi_v7_defconfig
 @@ -413,10 +413,12 @@ CONFIG_DRM=y
  CONFIG_DRM_PTN3460=m
  CONFIG_DRM_PS8622=m
  CONFIG_DRM_EXYNOS=m
 +CONFIG_DRM_EXYNOS_DSI=y
  CONFIG_DRM_EXYNOS_FIMD=y
  CONFIG_DRM_EXYNOS_HDMI=y
  CONFIG_DRM_RCAR_DU=m
  CONFIG_DRM_TEGRA=y
 +CONFIG_DRM_PANEL_S6E8AA0=m
  CONFIG_DRM_PANEL_SIMPLE=y
  CONFIG_FB_ARMCLCD=y
  CONFIG_FB_WM8505=y

>>>
>>> Reviewed-by: Javier Martinez Canillas 
>>>
>> Looks good to me and this would be handled by arm-soc guys directly 
>>
>> Acked-by: Kukjin Kim 
>>
> 
> I'd actually prefer if you could put this into the same branch as your
> other defconfig changes. We'll handle any conflicts when merging that in.
> 
OK, done.

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 3/3] libnvdimm: Add sysfs numa_node to NVDIMM devices

[Dan Williams]

On Tue, Jun 2, 2015 at 5:26 PM, Toshi Kani  wrote:
> Since NVDIMMs are installed on memory slots, they expose the NUMA
> topology of a platform.
>
> This patch adds support of sysfs 'numa_node' to the NVDIMM devices
> under /sys/bus/nd/devices, such as regionN, namespaceN.0, and bttN.
> When bttN is not set up, its numa_node returns -1 (NUMA_NO_NODE).
> nmemN/numa_node always returns -1 for now since this device is for
> dimm-ioctl message interface and has little use of NUMA.  It can be
> enhanced later to set a valid value if necessary.
>
> Here is an example of numa_node values on a 2-socket system with
> a single NVDIMM range on each socket.
>   /sys/bus/nd/devices
>   |-- btt0/numa_node:-1
>   |-- btt1/numa_node:0
>   |-- namespace0.0/numa_node:0
>   |-- namespace1.0/numa_node:1
>   |-- nmem0/numa_node:-1
>   |-- nmem1/numa_node:-1
>   |-- region0/numa_node:0
>   |-- region1/numa_node:1
>
> With this change, numactl(8) accepts 'block:' and 'file:' paths of
> pmem and btt devices as shown in the examples below.
>   numactl --preferred block:pmem0 --show
>   numactl --preferred file:/dev/pmem0s --show
>
> Signed-off-by: Toshi Kani 
> ---
>  drivers/acpi/nfit.c  |2 ++
>  drivers/nvdimm/btt.c |2 ++
>  drivers/nvdimm/bus.c |   12 
>  drivers/nvdimm/nd.h  |1 +
>  drivers/nvdimm/region.c  |1 +
>  drivers/nvdimm/region_devs.c |1 +
>  include/linux/libnvdimm.h|1 +
>  7 files changed, 20 insertions(+)
>
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
> index 5731e4a..a255f3a 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
> @@ -1255,6 +1255,8 @@ static int acpi_nfit_register_region(struct 
> acpi_nfit_desc *acpi_desc,
> ndr_desc->res = 
> ndr_desc->provider_data = nfit_spa;
> ndr_desc->attr_groups = acpi_nfit_region_attribute_groups;
> +   ndr_desc->numa_node = acpi_map_pxm_to_node(spa->proximity_domain);
> +
> list_for_each_entry(nfit_memdev, _desc->memdevs, list) {
> struct acpi_nfit_memory_map *memdev = nfit_memdev->memdev;
> struct nd_mapping *nd_mapping;
> diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
> index 2d7ce9e..3b3e115 100644
> --- a/drivers/nvdimm/btt.c
> +++ b/drivers/nvdimm/btt.c
> @@ -1369,6 +1369,8 @@ static int nd_btt_probe(struct device *dev)
> rc = -ENOMEM;
> goto err_btt;
> }
> +
> +   set_dev_node(dev, nd_region->numa_node);
> dev_set_drvdata(dev, btt);
>
> return 0;
> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
> index d8a1794..5c34e68 100644
> --- a/drivers/nvdimm/bus.c
> +++ b/drivers/nvdimm/bus.c
> @@ -339,9 +339,21 @@ static ssize_t devtype_show(struct device *dev, struct 
> device_attribute *attr,
>  }
>  static DEVICE_ATTR_RO(devtype);
>
> +#ifdef CONFIG_NUMA
> +static ssize_t numa_node_show(struct device *dev, struct device_attribute 
> *attr,
> +   char *buf)
> +{
> +   return sprintf(buf, "%d\n", dev->numa_node);
> +}
> +DEVICE_ATTR_RO(numa_node);
> +#endif
> +
>  static struct attribute *nd_device_attributes[] = {
> _attr_modalias.attr,
> _attr_devtype.attr,
> +#ifdef CONFIG_NUMA
> +   _attr_numa_node.attr,
> +#endif
> NULL,
>  };

I'd prefer you define is_visible() in the nd_device_attribute_group
and gate showing this attribute on IS_ENABLED(CONFIG_NUMA) rather than
including these ifdef guards.  The ifdef guards aren't necessary in
the CONFIG_NUMA=n case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Andy Lutomirski]

On Tue, Jun 2, 2015 at 5:39 PM, Andi Kleen  wrote:
> On Tue, Jun 02, 2015 at 05:21:27PM -0700, Andy Lutomirski wrote:
>> On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen  wrote:
>> > On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
>> >>
>> >>
>> >> On Tue, 2 Jun 2015, Andi Kleen wrote:
>> >>
>> >> > > There's the code in tsc_msr.c.  It should be relatively
>> >> > > straightforward to extend it to cover everything that intel_pstate
>> >> > > supports.
>> >> >
>> >> > That's a good idea, but we still need an always working fallback when 
>> >> > the
>> >> > model number is not available. So Adrian's patch is needed in any
>> >> > case.
>> >>
>> >> Nonsense. The slow calibration is already a working fallback.
>> >
>> > Please read Adrian's description again. It's not working when the PIT read 
>> > is
>> > too slow. That is when the new algorithm is needed.
>> >
>>
>> tglx's suggestion was to use slow calibration as a fallback.
>
> You mean the last fallback we have today?
>
> That one doesn't work if the PIT read is too slow.
>
> And Adrian's patch is fixing that.

Then the changelog should say that I think.  The current text says
"Fast TSC calibration will always fail", which, to me, suggests that
either the slow calibration will work or that the changelog message
should be changed.

--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 v1 8/9] powerpc/powernv: Add OPAL support for Nest PMU

[Daniel Axtens]

> +int64_t opal_nest_ima_control(uint32_t value);

If I'm understanding things correctly, you call this function in patch
3. Quoting from that patch:
> +static void nest_init(void *dummy)
> +{
> +   opal_nest_ima_control(P8_NEST_ENGINE_START);
> +}
Does this patch need to be moved earlier in the series? 

Have you tested that the series compiles at every point? 
(I've found that this can be done quite easily with
 git rebase --interactive using x to run the compile)

> +
>  /* Internal functions */
>  extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
>  int depth, void *data);
> diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
> b/arch/powerpc/platforms/powernv/opal-wrappers.S
> index a7ade94..ce36a68 100644
> --- a/arch/powerpc/platforms/powernv/opal-wrappers.S
> +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
> @@ -295,3 +295,4 @@ OPAL_CALL(opal_i2c_request,   
> OPAL_I2C_REQUEST);
>  OPAL_CALL(opal_flash_read,   OPAL_FLASH_READ);
>  OPAL_CALL(opal_flash_write,  OPAL_FLASH_WRITE);
>  OPAL_CALL(opal_flash_erase,  OPAL_FLASH_ERASE);
> +OPAL_CALL(opal_nest_ima_control, OPAL_NEST_IMA_CONTROL);



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v1 6/9]powerpc/powernv: dt parser function for nest pmu and its events

[Daniel Axtens]

> +static int nest_pmu_create(struct device_node *dev, int pmu_index)
> +{
> + struct ppc64_nest_ima_events **p8_events_arr;
> + struct ppc64_nest_ima_events *p8_events;
> + struct property *pp;
> + char *buf;
> + const __be32 *lval;
> + u32 val;
> + int len, idx = 0;
> + struct nest_pmu *pmu_ptr;
> + const char *start, *end;
> +
> + if (!dev)
> + return -EINVAL;
> +
> + pmu_ptr = kzalloc(sizeof(struct nest_pmu), GFP_KERNEL);
> + if (!pmu_ptr)
> + return -ENOMEM;
> +
> + /* Needed for hotplug/migration */
> + per_nestpmu_arr[pmu_index] = pmu_ptr;
> +
> + p8_events_arr = kzalloc((sizeof(struct ppc64_nest_ima_events) * 64),
> + GFP_KERNEL);
> + if (!p8_events_arr)
> + return -ENOMEM;
> + p8_events = (struct ppc64_nest_ima_events *)p8_events_arr;
I think you're trying to get the first element of the array here: why
not just `p8_events = p8_events_arr[0];`?

> +
> + /*
> +  * Loop through each property
> +  */
> + for_each_property_of_node(dev, pp) {
> + start = pp->name;
> + end = start + strlen(start);
> + len = strlen(start);
> +
> + if (!strcmp(pp->name, "name")) {
> + if (!pp->value ||
> +(strnlen(pp->value, pp->length) >= pp->length))
> + return -EINVAL;
> +
> + buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + sprintf(buf, "Nest_%s", (char *)pp->value);
> + pmu_ptr->pmu.name = (char *)buf;
> + pmu_ptr->attr_groups[1] = _nest_format_group;
> + pmu_ptr->attr_groups[2] = _nest_pmu_attr_group;
> + }
> +
> + /* Skip these, we dont need it */
> + if (!strcmp(pp->name, "name") ||
> + !strcmp(pp->name, "phandle") ||
> + !strcmp(pp->name, "device_type") ||
> + !strcmp(pp->name, "linux,phandle"))
> + continue;
> +
> + buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + if (strncmp(pp->name, "unit.", 5) == 0) {
> + start += 5;
> + len = strlen(start);
> + strncpy(buf, start, strlen(start));
You've just saved strlen(start), you could just use len. This also
applies in the next case below.
> + p8_events->ev_name = buf;
> +
> + if (!pp->value ||
> +(strnlen(pp->value, pp->length) >= pp->length))
> + return -EINVAL;
The strnlen will never be greater than pp->length, so the only case this
will hit is if strnlen(pp->value, pp->length) == pp->length. This also
applies again below.

> +
> + buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + strncpy(buf, (const char *)pp->value, pp->length);
> + p8_events->ev_value = buf;
> + idx++;
> + p8_events++;
> +
> + } else if (strncmp(pp->name, "scale.", 6) == 0) {
> + start += 6;
> + len = strlen(start);
> + strncpy(buf, start, strlen(start));
> + p8_events->ev_name = buf;
> +
> + if (!pp->value ||
> +(strnlen(pp->value, pp->length) >= pp->length))
> + return -EINVAL;
> +
> + buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + strncpy(buf, (const char *)pp->value, pp->length);
> + p8_events->ev_value = buf;
> + idx++;
> + p8_events++;
> +
> + } else {
> + strncpy(buf, start, len);
This is the only case where you actually use the orignal version of len.
This makes me think you could drop the variable entirely and just use
strlen(start) in all cases. I also don't see where `end` is used
anywhere in this function: could that be dropped?
> + p8_events->ev_name = buf;
> + lval = of_get_property(dev, pp->name, NULL);
> + val = (uint32_t)be32_to_cpup(lval);
> +
> + /*
> + * Use DT property value as the event
> + */
I'm not sure if this is my mailer, but it looks like lines 2 and 3 of
that comment need to be indented to line up under the * in the first
line.
> + buf = 

[PATCH 2/3] acpi: Add export to acpi_map_pxm_to_node()

[Toshi Kani]

acpi_get_node() allows ACPI kernel modules to map a proximity ID
to a node ID from ACPI _PXM method.  Some ACPI static tables,
such as SRAT, DMAR, PMTT and NFIT, also contain proximity IDs.

This patch exports acpi_map_pxm_to_node() so that ACPI kernel
modules can call this function to map a proximity ID to a node ID
from an ACPI static table as well.

When CONFIG_ACPI_NUMA is not set, acpi_map_pxm_to_node() always
returns 0.

Signed-off-by: Toshi Kani 
---
 drivers/acpi/numa.c  |1 +
 include/linux/acpi.h |5 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4898082..8f50d5d 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -90,6 +90,7 @@ int acpi_map_pxm_to_node(int pxm)
 
return node;
 }
+EXPORT_SYMBOL(acpi_map_pxm_to_node);
 
 static void __init
 acpi_table_print_srat_entry(struct acpi_subtable_header *header)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index e4da5e3..7a76e51 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -289,8 +289,13 @@ extern void acpi_dmi_osi_linux(int enable, const struct 
dmi_system_id *d);
 extern void acpi_osi_setup(char *str);
 
 #ifdef CONFIG_ACPI_NUMA
+int acpi_map_pxm_to_node(int pxm);
 int acpi_get_node(acpi_handle handle);
 #else
+static inline int acpi_map_pxm_to_node(int pxm)
+{
+   return 0;
+}
 static inline int acpi_get_node(acpi_handle handle)
 {
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Add NUMA support for NVDIMM devices

[Toshi Kani]

Since NVDIMMs are installed on memory slots, they expose the NUMA
topology of a platform.  This patchset adds support of sysfs
'numa_node' to the NVDIMM devices under /sys/bus/nd/devices.
With this change, numactl(8) accepts 'block:' and 'file:' paths of
pmem and btt devices as shown in the examples below.
  numactl --preferred block:pmem0 --show
  numactl --preferred file:/dev/pmem0s --show

Here is a result of fio benchmark to ext4/dax on pmem0 using numactl
on an HP DL380 with 2 sockets; pmem0 on node 0, and pmem1 on node 1.

  Local [1] :  4098.3MB/s
  Remote [2]:  3718.4MB/s

[1] numactl --preferred block:pmem0 --cpunodebind block:pmem0 fio  
[2] numactl --preferred block:pmem1 --cpunodebind block:pmem1 fio 

Patch 1/3-2/3 apply on top of the acpica branch of the pm tree.
Patch 3/3 applies on top of Dan Williams's v5 patch series of 
"libnvdimm: non-volatile memory devices".

---
Toshi Kani (3):
  1/3 acpi: Fix acpi_map_pxm_to_node() to handle numa_off
  2/3 acpi: Add export to acpi_map_pxm_to_node()
  3/3 libnvdimm: Add sysfs numa_node to NVDIMM devices

---
 drivers/acpi/nfit.c  |  2 ++
 drivers/acpi/numa.c  | 13 ++---
 drivers/nvdimm/btt.c |  2 ++
 drivers/nvdimm/bus.c | 12 
 drivers/nvdimm/nd.h  |  1 +
 drivers/nvdimm/region.c  |  1 +
 drivers/nvdimm/region_devs.c |  1 +
 include/linux/acpi.h |  5 +
 include/linux/libnvdimm.h|  1 +
 9 files changed, 35 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] libnvdimm: Add sysfs numa_node to NVDIMM devices

[Toshi Kani]

Since NVDIMMs are installed on memory slots, they expose the NUMA
topology of a platform.

This patch adds support of sysfs 'numa_node' to the NVDIMM devices
under /sys/bus/nd/devices, such as regionN, namespaceN.0, and bttN.
When bttN is not set up, its numa_node returns -1 (NUMA_NO_NODE).
nmemN/numa_node always returns -1 for now since this device is for
dimm-ioctl message interface and has little use of NUMA.  It can be
enhanced later to set a valid value if necessary.

Here is an example of numa_node values on a 2-socket system with
a single NVDIMM range on each socket.
  /sys/bus/nd/devices
  |-- btt0/numa_node:-1
  |-- btt1/numa_node:0
  |-- namespace0.0/numa_node:0
  |-- namespace1.0/numa_node:1
  |-- nmem0/numa_node:-1
  |-- nmem1/numa_node:-1
  |-- region0/numa_node:0
  |-- region1/numa_node:1

With this change, numactl(8) accepts 'block:' and 'file:' paths of
pmem and btt devices as shown in the examples below.
  numactl --preferred block:pmem0 --show
  numactl --preferred file:/dev/pmem0s --show

Signed-off-by: Toshi Kani 
---
 drivers/acpi/nfit.c  |2 ++
 drivers/nvdimm/btt.c |2 ++
 drivers/nvdimm/bus.c |   12 
 drivers/nvdimm/nd.h  |1 +
 drivers/nvdimm/region.c  |1 +
 drivers/nvdimm/region_devs.c |1 +
 include/linux/libnvdimm.h|1 +
 7 files changed, 20 insertions(+)

diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index 5731e4a..a255f3a 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -1255,6 +1255,8 @@ static int acpi_nfit_register_region(struct 
acpi_nfit_desc *acpi_desc,
ndr_desc->res = 
ndr_desc->provider_data = nfit_spa;
ndr_desc->attr_groups = acpi_nfit_region_attribute_groups;
+   ndr_desc->numa_node = acpi_map_pxm_to_node(spa->proximity_domain);
+
list_for_each_entry(nfit_memdev, _desc->memdevs, list) {
struct acpi_nfit_memory_map *memdev = nfit_memdev->memdev;
struct nd_mapping *nd_mapping;
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 2d7ce9e..3b3e115 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1369,6 +1369,8 @@ static int nd_btt_probe(struct device *dev)
rc = -ENOMEM;
goto err_btt;
}
+
+   set_dev_node(dev, nd_region->numa_node);
dev_set_drvdata(dev, btt);
 
return 0;
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index d8a1794..5c34e68 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -339,9 +339,21 @@ static ssize_t devtype_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(devtype);
 
+#ifdef CONFIG_NUMA
+static ssize_t numa_node_show(struct device *dev, struct device_attribute 
*attr,
+   char *buf)
+{
+   return sprintf(buf, "%d\n", dev->numa_node);
+}
+DEVICE_ATTR_RO(numa_node);
+#endif
+
 static struct attribute *nd_device_attributes[] = {
_attr_modalias.attr,
_attr_devtype.attr,
+#ifdef CONFIG_NUMA
+   _attr_numa_node.attr,
+#endif
NULL,
 };
 
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index c807379..fefd8f6 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -108,6 +108,7 @@ struct nd_region {
u64 ndr_size;
u64 ndr_start;
int id, num_lanes;
+   int numa_node;
void *provider_data;
struct nd_interleave_set *nd_set;
struct nd_mapping mapping[0];
diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c
index 373eab4..783220e 100644
--- a/drivers/nvdimm/region.c
+++ b/drivers/nvdimm/region.c
@@ -123,6 +123,7 @@ static int nd_region_probe(struct device *dev)
 
num_ns->active = rc;
num_ns->count = rc + err;
+   set_dev_node(dev, nd_region->numa_node);
dev_set_drvdata(dev, num_ns);
 
if (err == 0)
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index 86adbd8..352bc80 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -627,6 +627,7 @@ static noinline struct nd_region *nd_region_create(struct 
nvdimm_bus *nvdimm_bus
nd_region->provider_data = ndr_desc->provider_data;
nd_region->nd_set = ndr_desc->nd_set;
nd_region->num_lanes = ndr_desc->num_lanes;
+   nd_region->numa_node = ndr_desc->numa_node;
ida_init(_region->ns_ida);
dev = _region->dev;
dev_set_name(dev, "region%d", nd_region->id);
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index 96b9507..5d0c75a 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -78,6 +78,7 @@ struct nd_region_desc {
struct nd_interleave_set *nd_set;
void *provider_data;
int num_lanes;
+   int numa_node;
 };
 
 struct nvdimm_bus;
--
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  

[PATCH 1/3] acpi: Fix acpi_map_pxm_to_node() to handle numa_off

[Toshi Kani]

When numa_off is set, NUMA is turned off and node 0 is the only
valid node on the system.  The kernel skips parsing ACPI SRAT
table in this case.

Change acpi_map_pxm_to_node() to always return 0 when numa_off
is set.  Also move the range check of a proximity ID from
acpi_get_node() to acpi_map_pxm_to_node() after the numa_off
check.  This keeps the interfaces to return 0 regardless of
proximity ID values.

Signed-off-by: Toshi Kani 
---
 drivers/acpi/numa.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 1333cbdc..4898082 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -70,7 +70,15 @@ static void __acpi_map_pxm_to_node(int pxm, int node)
 
 int acpi_map_pxm_to_node(int pxm)
 {
-   int node = pxm_to_node_map[pxm];
+   int node;
+
+   if (numa_off)
+   return 0;
+
+   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS)
+   return NUMA_NO_NODE;
+
+   node = pxm_to_node_map[pxm];
 
if (node == NUMA_NO_NODE) {
if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
@@ -328,8 +336,6 @@ int acpi_get_node(acpi_handle handle)
int pxm;
 
pxm = acpi_get_pxm(handle);
-   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS)
-   return NUMA_NO_NODE;
 
return acpi_map_pxm_to_node(pxm);
 }
--
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 2/9] net: dsa: add basic support for VLAN operations

[Vivien Didelot]

Hi Guenter,

On Jun 2, 2015, at 10:42 AM, Guenter Roeck li...@roeck-us.net wrote:
On 06/01/2015 06:27 PM, Vivien Didelot wrote:
>> This patch adds the glue between DSA and switchdev to add and delete
>> SWITCHDEV_OBJ_PORT_VLAN objects.
>>
>> This will allow the DSA switch drivers implementing the port_vlan_add
>> and port_vlan_del functions to access the switch VLAN database through
>> userspace commands such as "bridge vlan".
>>
>> Signed-off-by: Vivien Didelot 
>> ---
>>   include/net/dsa.h |  7 +++
>>   net/dsa/slave.c   | 61 
>> +--
>>   2 files changed, 66 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net/dsa.h b/include/net/dsa.h
>> index fbca63b..726357b 100644
>> --- a/include/net/dsa.h
>> +++ b/include/net/dsa.h
>> @@ -302,6 +302,13 @@ struct dsa_switch_driver {
>> const unsigned char *addr, u16 vid);
>>  int (*fdb_getnext)(struct dsa_switch *ds, int port,
>> unsigned char *addr, bool *is_static);
>> +
>> +/*
>> + * VLAN support
>> + */
>> +int (*port_vlan_add)(struct dsa_switch *ds, int port, u16 vid,
>> + u16 bridge_flags);
>> +int (*port_vlan_del)(struct dsa_switch *ds, int port, u16 vid);
>>   };
>>
>>   void register_switch_driver(struct dsa_switch_driver *type);
>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>> index cbda00a..52ba5a1 100644
>> --- a/net/dsa/slave.c
>> +++ b/net/dsa/slave.c
>> @@ -363,6 +363,25 @@ static int dsa_slave_port_attr_set(struct net_device 
>> *dev,
>>  return ret;
>>   }
>>
>> +static int dsa_slave_port_vlans_add(struct net_device *dev,
>> +struct switchdev_obj_vlan *vlan)
>> +{
>> +struct dsa_slave_priv *p = netdev_priv(dev);
>> +struct dsa_switch *ds = p->parent;
>> +int vid, err = 0;
>> +
>> +if (!ds->drv->port_vlan_add)
>> +return -ENOTSUPP;
>> +
>> +for (vid = vlan->vid_start; vid <= vlan->vid_end; ++vid) {
>> +err = ds->drv->port_vlan_add(ds, p->port, vid, vlan->flags);
>> +if (err)
>> +break;
>> +}
>> +
>> +return err;
>> +}
>> +
>>   static int dsa_slave_port_obj_add(struct net_device *dev,
>>struct switchdev_obj *obj)
>>   {
>> @@ -378,6 +397,9 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
>>  return 0;
>>
>>  switch (obj->id) {
>> +case SWITCHDEV_OBJ_PORT_VLAN:
>> +err = dsa_slave_port_vlans_add(dev, >u.vlan);
>> +break;
>>  default:
>>  err = -ENOTSUPP;
>>  break;
>> @@ -386,12 +408,34 @@ static int dsa_slave_port_obj_add(struct net_device 
>> *dev,
>>  return err;
>>   }
>>
>> +static int dsa_slave_port_vlans_del(struct net_device *dev,
>> +struct switchdev_obj_vlan *vlan)
>> +{
>> +struct dsa_slave_priv *p = netdev_priv(dev);
>> +struct dsa_switch *ds = p->parent;
>> +int vid, err = 0;
>> +
>> +if (!ds->drv->port_vlan_del)
>> +return -ENOTSUPP;
>> +
>> +for (vid = vlan->vid_start; vid <= vlan->vid_end; ++vid) {
>> +err = ds->drv->port_vlan_del(ds, p->port, vid);
>> +if (err)
>> +break;
>> +}
>> +
>> +return err;
>> +}
>> +
>>   static int dsa_slave_port_obj_del(struct net_device *dev,
>>struct switchdev_obj *obj)
>>   {
>>  int err;
>>
>>  switch (obj->id) {
>> +case SWITCHDEV_OBJ_PORT_VLAN:
>> +err = dsa_slave_port_vlans_del(dev, >u.vlan);
>> +break;
>>  default:
>>  err = -EOPNOTSUPP;
>>  break;
>> @@ -473,6 +517,15 @@ static netdev_tx_t dsa_slave_notag_xmit(struct sk_buff
>> *skb,
>>  return NETDEV_TX_OK;
>>   }
>>
>> +static int dsa_slave_vlan_noop(struct net_device *dev, __be16 proto, u16 
>> vid)
>> +{
>> +/* NETIF_F_HW_VLAN_CTAG_FILTER requires ndo_vlan_rx_add_vid and
>> + * ndo_vlan_rx_kill_vid, otherwise the VLAN acceleration is considered
>> + * buggy (see net/core/dev.c).
>> + */
>> +return 0;
>> +}
>> +
>>
>>   /* ethtool operations 
>> ***/
>>   static int
>> @@ -734,6 +787,10 @@ static const struct net_device_ops dsa_slave_netdev_ops 
>> = {
>>  .ndo_fdb_dump   = dsa_slave_fdb_dump,
>>  .ndo_do_ioctl   = dsa_slave_ioctl,
>>  .ndo_get_iflink = dsa_slave_get_iflink,
>> +.ndo_vlan_rx_add_vid= dsa_slave_vlan_noop,
>> +.ndo_vlan_rx_kill_vid   = dsa_slave_vlan_noop,
>> +.ndo_bridge_setlink = switchdev_port_bridge_setlink,
>> +.ndo_bridge_dellink = switchdev_port_bridge_dellink,
>>   };
>>
>>   static const struct switchdev_ops dsa_slave_switchdev_ops = {
>> @@ -924,7 +981,7 @@ int dsa_slave_create(struct dsa_switch *ds, struct device
>> *parent,
>>  if (slave_dev == NULL)
>>  return -ENOMEM;
>>
>> -slave_dev->features = master->vlan_features;
>> +slave_dev->features = master->vlan_features | NETIF_F_VLAN_FEATURES;
> 
> Hi Vivien,
> 
> 

Re: [PATCH][V3] usb: isp1760: check for null return from kzalloc

[Laurent Pinchart]

Hi Colin,

Thank you for the patch.

On Tuesday 02 June 2015 19:05:13 Colin King wrote:
> From: Colin Ian King 
> 
> isp1760_ep_alloc_request allocates a structure with kzalloc without checking
> for NULL and then returns a pointer to one of the structure fields. As the
> field happens to be the first in the structure the caller can properly
> check for NULL, but this is risky if the structure layout is changed later.
> Add an explicit NULL check for the kzalloc return value
> 
> Detected with smatch static analysis:
> 
> drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
>   error: potential null dereference 'req'.  (kzalloc returns null)
> 
> [ thanks to Laurent Pinchart for improved commit message ]
> 
> Signed-off-by: Colin Ian King 

Acked-by: Laurent Pinchart 

Felipe, I expect you to pick this up, please let me know if there's any issue.

> ---
>  drivers/usb/isp1760/isp1760-udc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/isp1760/isp1760-udc.c
> b/drivers/usb/isp1760/isp1760-udc.c index 3fc4fe7..18ebf5b 100644
> --- a/drivers/usb/isp1760/isp1760-udc.c
> +++ b/drivers/usb/isp1760/isp1760-udc.c
> @@ -812,6 +812,8 @@ static struct usb_request
> *isp1760_ep_alloc_request(struct usb_ep *ep, struct isp1760_request *req;
> 
>   req = kzalloc(sizeof(*req), gfp_flags);
> + if (!req)
> + return NULL;
> 
>   return >req;
>  }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Andi Kleen]

On Tue, Jun 02, 2015 at 05:21:27PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen  wrote:
> > On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
> >>
> >>
> >> On Tue, 2 Jun 2015, Andi Kleen wrote:
> >>
> >> > > There's the code in tsc_msr.c.  It should be relatively
> >> > > straightforward to extend it to cover everything that intel_pstate
> >> > > supports.
> >> >
> >> > That's a good idea, but we still need an always working fallback when the
> >> > model number is not available. So Adrian's patch is needed in any
> >> > case.
> >>
> >> Nonsense. The slow calibration is already a working fallback.
> >
> > Please read Adrian's description again. It's not working when the PIT read 
> > is
> > too slow. That is when the new algorithm is needed.
> >
> 
> tglx's suggestion was to use slow calibration as a fallback.

You mean the last fallback we have today?

That one doesn't work if the PIT read is too slow.

And Adrian's patch is fixing that.

-Andi

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

Re: [PATCH v1 5/9]powerpc/powernv: nest pmu feature detection support

[Daniel Axtens]

On Tue, 2015-06-02 at 21:29 +0530, Madhavan Srinivasan wrote:
> Patch adds a device tree function to detect the nest pmu
> support. Function will look for specific dt property "ibm,ima-chip"
> as a detection mechanism for the nest pmu.
> 
> For Nest pmu, device tree will have two set of information.
> 1) Per-chip Homer address region for nest pmu counter collection area.
> 2) Supported Nest PMUs and events
What's HOMER?

>  
> +static int nest_ima_detect_parse(void)
> +{
> + const __be32 *gcid;
> + const __be64 *chip_ima_reg;
> + const __be64 *chip_ima_size;
> + struct device_node *dev;
> + int rc = -EINVAL, idx;
> +
> + for_each_node_with_property(dev, "ibm,ima-chip") {
> + gcid = of_get_property(dev, "ibm,chip-id", NULL);
> + chip_ima_reg = of_get_property(dev, "reg", NULL);
> + chip_ima_size = of_get_property(dev, "size", NULL);
> + if ((!gcid) || (!chip_ima_reg) || (!chip_ima_size)) {
> + pr_err("%s: device %s missing property \n",
> + __func__, dev->full_name);
This is not a particularly informative error message. It'd be good if it
mentioned that it was for PMU.
> + return rc;
> + }
> +
> + idx = (uint32_t)be32_to_cpup(gcid);
> + p8_perchip_nest_info[idx].pbase = be64_to_cpup(chip_ima_reg);
> + p8_perchip_nest_info[idx].size = be64_to_cpup(chip_ima_size);
> + p8_perchip_nest_info[idx].vbase = (uint64_t)
> + phys_to_virt(p8_perchip_nest_info[idx].pbase);
> +
> + rc = 0;
> + }
> +
> + return rc;

I'm not sure your rc handling is correct. As I understand it:
 - Start with rc = -EINVAL.
 - If your first node is missing a property, return -EINVAL.
 - Once your first node succeeds, set rc = 0
 - If any subsequent node is missing a property, return 0.
 - Return 0 if any node is successfully processed, otherwise return
-EINVAL.

If that's what you intended (especially with regards to returning 0 when
a subsequent node is missing a property), a comment explaining it would
be great. 

Also, why bail out if a property is missing on any node? Why not try all
of them and see if any succeed?

> +}
> +
>  static int __init nest_pmu_init(void)
>  {
>   int ret = 0;
> @@ -256,6 +287,12 @@ static int __init nest_pmu_init(void)
>  
>   cpumask_chip();
>  
> + /*
> +  * Detect the Nest PMU feature
> +  */
> + if (nest_ima_detect_parse())
> + return 0;
> +
>   return 0;
>  }
Zero is returned regardless of the output of nest_ima_detect_parse. Is
that intentional? If so, do you need the 'if'?

>  device_initcall(nest_pmu_init);

Regards,
Daniel Axtens



signature.asc
Description: This is a digitally signed message part

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Andy Lutomirski]

On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen  wrote:
> On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
>>
>>
>> On Tue, 2 Jun 2015, Andi Kleen wrote:
>>
>> > > There's the code in tsc_msr.c.  It should be relatively
>> > > straightforward to extend it to cover everything that intel_pstate
>> > > supports.
>> >
>> > That's a good idea, but we still need an always working fallback when the
>> > model number is not available. So Adrian's patch is needed in any
>> > case.
>>
>> Nonsense. The slow calibration is already a working fallback.
>
> Please read Adrian's description again. It's not working when the PIT read is
> too slow. That is when the new algorithm is needed.
>

tglx's suggestion was to use slow calibration as a fallback.

--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 v5 2/2] arch/x86: remove pci uart early console from early_prink.c

[Anderson, Stuart R]

Bin, et al,

What we are losing here is the ability to specify a UART by its bus address 
instead of just supplying the memory or io address. There are some cases where 
this is useful, though I admit it is probably not going to be widely used. I 
have seen a platform where the location of the UART moves depending on the 
firmware version, but the bus address (B:D.F) did not change. There are also 
some platforms where you do not know the address until you boot the OS and can 
use the UART to login and find the address of the UART (oops. Chicken and egg 
problem).

Also, I was going to soon send a patch to allow "pciserial32" for the case 
where the UART registers are 32-bit aligned instead of 8-bit aligned.

Stuart

-Original Message-
From: Bin Gao [mailto:bin@linux.intel.com] 
Sent: Tuesday, June 02, 2015 3:43 PM
To: Thomas Gleixner
Cc: Ingo Molnar; Ingo Molnar; H. Peter Anvin; Greg Kroah-Hartman; One Thousand 
Gnomes; Peter Hurley; Jiri Slaby; Borislav Petkov; Anderson, Stuart R; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/2] arch/x86: remove pci uart early console from 
early_prink.c

On Tue, Jun 02, 2015 at 11:07:39PM +0200, Thomas Gleixner wrote:
> What about the memory mapped uarts which have been source of trouble 
> in the past?
> 
> Thanks,
> 
>   tglx

Not sure which specific early console you are referring to.
Currently we have serial, ttyS, vga, dbgp, xen, efi and pciserial in 
arch/x86/kernel/early_printk.c, and only pciserial is memory mapped (but it's 
being removed).

And this patch only touches pciserial/serial parts so ideally shouldn't have 
impact on other early consoles.

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