Re: [PATCH v6 20/24] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

[Daniel Baluta]

On Sun, Apr 3, 2016 at 1:54 PM, Jonathan Cameron  wrote:
> On 03/04/16 09:52, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> The root i2c adapter lock is then no longer held by the i2c mux during
>> accesses behind the i2c gate, and such accesses need to take that lock
>> just like any other ordinary i2c accesses do.
>>
>> So, declare the i2c gate mux-locked, and zap the code that makes the
>> unlocked i2c accesses and just use ordinary regmap_write accesses.
>>
>> This also happens to fix the deadlock described in
>> http://patchwork.ozlabs.org/patch/584776/ authored by
>> Adriana Reus  and submitted by
>> Daniel Baluta 
>>
>> --8<--
>> iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock
>>
>> This deadlock occurs if the accel/gyro and the sensor on the auxiliary
>> I2C (in my setup it's an ak8975) are working at the same time.
>>
>> Scenario:
>>
>>   T1  T2
>>  
>> inv_mpu6050_read_fifo  aux sensor op (eg. ak8975_read_raw)
>> | |
>> mutex_lock(&indio_dev->mlock)   i2c_transfer
>> | |
>> i2c transaction i2c adapter lock
>> | |
>> i2c adapter locki2c_mux_master_xfer
>>   |
>> inv_mpu6050_select_bypass
>>   |
>> mutex_lock(&indio_dev->mlock)
>>
>> When we operate on an mpu sensor the order of locking is mpu lock
>> followed by the i2c adapter lock. However, when we operate the auxiliary
>> sensor the order of locking is the other way around.
>>
>> ...
>> --8<--
>>
>> The reason this patch fixes the deadlock is that T2 does not grab the
>> i2c adapter lock until the very end (and grabs the newfangled i2c mux
>> lock where it previously grabbed the i2c adapter lock).
>>
>> Signed-off-by: Peter Rosin 
> This one obviously wants a ack from Adriana or Daniel in addition to mine.
> I'm more than happy for these to go through the i2c tree btw.
>
> Acked-by: Jonathan Cameron 

Acked-by: Daniel Baluta 


>> ---
>>  Documentation/i2c/i2c-topology|  2 +-
>>  drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 56 
>> +++
>>  2 files changed, 13 insertions(+), 45 deletions(-)
>>
>> diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
>> index 7a10edd0874f..346623a80bd1 100644
>> --- a/Documentation/i2c/i2c-topology
>> +++ b/Documentation/i2c/i2c-topology
>> @@ -50,7 +50,7 @@ i2c-mux-pinctrl   Normally parent-locked, 
>> mux-locked iff
>>  i2c-mux-reg   Parent-locked
>>
>>  In drivers/iio/
>> -imu/inv_mpu6050/  Parent-locked
>> +imu/inv_mpu6050/  Mux-locked
>>
>>  In drivers/media/
>>  dvb-frontends/m88ds3103   Parent-locked
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> index 0d429d788106..71ad31a275c9 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> @@ -24,45 +24,16 @@ static const struct regmap_config inv_mpu_regmap_config 
>> = {
>>   .val_bits = 8,
>>  };
>>
>> -/*
>> - * The i2c read/write needs to happen in unlocked mode. As the parent
>> - * adapter is common. If we use locked versions, it will fail as
>> - * the mux adapter will lock the parent i2c adapter, while calling
>> - * select/deselect functions.
>> - */
>> -static int inv_mpu6050_write_reg_unlocked(struct i2c_client *client,
>> -   u8 reg, u8 d)
>> -{
>> - int ret;
>> - u8 buf[2] = {reg, d};
>> - struct i2c_msg msg[1] = {
>> - {
>> - .addr = client->addr,
>> - .flags = 0,
>> - .len = sizeof(buf),
>> - .buf = buf,
>> - }
>> - };
>> -
>> - ret = __i2c_transfer(client->adapter, msg, 1);
>> - if (ret != 1)
>> - return ret;
>> -
>> - return 0;
>> -}
>> -
>>  static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
>>  {
>> - struct i2c_client *client = i2c_mux_priv(muxc);
>> - struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
>> + struct iio_dev *indio_dev = i2c_mux_priv(muxc);
>>   struct inv_mpu6050_state *st = iio_priv(indio_dev);
>>   int ret = 0;
>>
>>   /* Use the same mutex which was used everywhere to protect power-op */
>>   mutex_lock(&indio_dev->mlock);
>>   if (!st->powerup_count) {
>> - ret = inv_mpu6050_write_reg_unlocked(client,
>> -  st->reg->pwr_mgmt_1, 0);
>> + ret = regmap_write(st->map, st->reg->pwr_mgmt_1, 0);

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Mauro, hi kernel-doc authors, 

Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab :

> Em Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  escreveu:
> 
>> Hi kernel-doc authors,
>> 
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s 
>> DocBook XML documentation to reST markup. 
>> 
>> It converts 99% of the docs well ... to gain an impression how 
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>> 
>> http://return42.github.io/sphkerneldoc/
>> 
>> The sources available at:
>> 
>> https://github.com/return42/sphkerneldoc
>> 
>> The work is underway, suggestions are welcome!
>> 
>> .. have a nice weekend ..
> 
> Hi Markus,
> 
> Thanks for your work. I'm basically worried about the media docbook,
> with has some complexities that I was not able to figure out a way to
> convert it to reST.
> 
> So, let me pinpoint some issues that I noticed there, on a quick
> look.
> 
> The first thing I noticed is that the index doesn't match what's
> there, when generated from DocBook:
>   https://linuxtv.org/downloads/v4l-dvb-apis/v4l2spec.html
> 
> So, for instance, "Interfaces" is at the same level as "Input/Output".
> 
> This sounds like an something went wrong when dealing with the title
> indentation levels during the conversion.
> 

Yes, the hierarchical structure was broken by two causes. First was, that the
*chunking* was wrong and the other was, that my DocBook-XML-filter (dbxml) 
placed
all sections and sub(-sub)-sections at the same level (direct under chapter). 
This was
not only broken in the linux_tv book, in the other books also.

Thanks for pointing and sorry that I have overlooked this (I was so much 
focused on
on converting single elements to reST, that I not see the wood for the trees).

It is now fixed, may you give it a new try.


> I would also like to see the titles numbered in chapters (and, if
> possible, in sections and items) and to be properly indented at the 
> index.

BTW a few words about differences between DockBook and reST (Sphinx).

With DocBook you write *books*, the protocol (the DocBook application) has
no facility to *chunk* and interconnect several documents. The external ENTITY 
is a workaround on the SGML layer, not on XML nor on the DB-application layer.
Thats the reason, why so many XML-tools don't handle this entities and
many DocBook to (e.g.) reST tools are fail.

With **standard** reST it is nearly the same, except there is a "include"
directive on the application layer. But this directive is very simple,
comparable to the C preprocessor "#include" directive.

With the **superset** reST-markup of Sphinx-doc you get a the "toctree" 
directive,
which lets you control how a document-tree should be build.

 http://www.sphinx-doc.org/en/stable/markup/toctree.html

@Mauro: you mentioned a docutils (rst2*) experience in your mail 
  http://marc.info/?l=linux-doc&m=145735316012094&w=2

  Because the "toctree" directive -- and other directives
  we use -- are a part of a superset of the **standard** 
  reST, the standard docutils (like rst2*) will not work.

OK, back to your requirements: within the toctree directive you can
set options like "maxdepth" and "numbered". It is a decision, how
deep TOCs should go and if they should be numbered. IMO, in a
HTML rendered page, with a proper navigation bar on the side, deep 
TOCs in the running text have no pros, they only blow up the running
text and bring more scrolling with. In my sense numbering chapters
make only sense in books, not in HTML pages, where you have hyperlinks.

Just for demonstration, I added numbering in the linux-tv book:

https://github.com/return42/sphkerneldoc/commit/468ded71f62d497ac71aead1a6d50de7ef77c3c3

May be, I will drop it later, because all reST sources are generated
by a make target and I always commit the whole reST tree. As I said, 
it is a decision which might be made later, when the migration takes 
places.

> Also, it seems that there's still a lot of work to do, as there are several
> tables that are missing conversion, like the table for "struct 
> v4l2_pix_format":
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt.html
> 
> and the big tables at:
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-rgb.html
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-yuv.html
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html
> 

Yes, I marked them as TODO: 

 https://github.com/return42/sphkerneldoc/blob/master/scripts/media.py#L262

aspect *authoring tables* (see below)

> Also, some tables that are not so big like:
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-y41p.html
> 
> don't look nice, at least on my browser, as the "white" area is too small,
> and some cells seem to be broken in two, because of the color changes in the 
> middle

Re: [PATCH 4/4] serial: doc: .break_ctl() may sleep

[Geert Uytterhoeven]

Hi Jon,

On Sat, Apr 16, 2016 at 6:47 PM, Jonathan Corbet  wrote:
> On Fri, 15 Apr 2016 16:07:39 -0700
> Peter Hurley  wrote:
>
>> > I'm missing something here.
>>
>> Yes.
>>
>> The analysis above is required to show that the API contract asserted by
>> the proposed change to the documentation is currently true in the code,
>> which is what I care about.
>
> Yes, but the analysis says nothing about what uart_break_ctl() itself
> might do, so by itself, it provides no guarantee for break_ctl().  That
> was my sticking point since somebody clearly put that line in there for a
> reason.
>
> Looking at the code, it's pretty obvious that uart_break_ctl() isn't
> acquiring any spinlocks.  The documentation line in question has been
> there, unchanged, since the beginning of the Git era.  The patch is
> obviously fine, and I've applied it, but I did tweak the changelog some.

Sorry, this indeed needed more clarification.
Thanks for fixing it up!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ARM64: ACPI: Update documentation for latest specification version

[Lorenzo Pieralisi]

On Fri, Apr 15, 2016 at 11:54:08AM -0600, Al Stone wrote:

[...]

> > Understood, the point I wanted to make is that adding a list of methods
> > in acpi_object_usage.txt ("Use as needed") is not necessarily additional
> > information, you can add a pointer at ACPI specs (for that specific
> > purpose - as I said there are parts of the patch that add additional
> > information Linux related) for that purpose instead of having to list
> > all of them in acpi_object_usage.txt again.
> 
> I see.  That makes sense.  How about I collapse those down with something
> on the order of "unless otherwise noted, use as needed" and just remove the
> ones that have no specific info?

Agreed, that would also help you avoid keeping track of new specs
updates that do not necessarily require updates to these docs.

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

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Jonahtan,

Am 12.04.2016 um 17:46 schrieb Jonathan Corbet :

> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  wrote:
> 
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s 
>> DocBook XML documentation to reST markup. 
>> 
>> It converts 99% of the docs well ... to gain an impression how 
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>> 
>>  http://return42.github.io/sphkerneldoc/
> 
> So I've obviously been pretty quiet on this recently.  Apologies...I've
> been dealing with an extended death-in-the-family experience, and there is
> still a fair amount of cleanup to be done.
> 
> Looking quickly at this work, it seems similar to the results I got.  But
> there's a lot of code there that came from somewhere?

>From me? ... except the kernel-doc script which is a fork from your 

  git://git.lwn.net/linux.git doc/sphinx


>  I'd put together a
> fairly simple conversion using pandoc and a couple of short sed scripts;
> is there a reason for a more complex solution?

It depends. If you have a simple DocBook with less various markup, maybe not.
May you want to read my remarks about migration tools and especially pandoc:

* 
https://return42.github.io/sphkerneldoc/articles/dbtools.html#remarks-on-pandoc

A few more words about, what I have done:

I wrote a lib of XML filters which might be also usefully in other
migration projects (dbxml). 

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbxml.py

It uses a xml-parser, pandoc, pandoc-filters and regular expressions. Because
I did not implemented a whole converter, I hacked around pandoc. Thats why
conversion is done in several steps:

1. copy xml file(s) to a cache space

2. substitude unsolved internal and external entities

3. filter all xml files

   * run custom hooks on every node 

   * apply filters on every node and inject reST into the XML-tree where pandoc 
fails.
 https://github.com/return42/sphkerneldoc/blob/master/scripts/dbxml.py#L515

4. convert intermediary XML result with pandoc to json (needed by pandoc 
filters)

5. apply pandoc-filter and clean up the injected reST markup from step3

6. convert filtered json to reST

7. fix the produce reST with regular expression

... the last step is similar to your sed scripts.


And I wrote a commandline Interface to use this lib (see func db2rst):

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbtools.py#L146
 
With this db2rst all kernel DB-XML books could be migrated, except the linux-tv
book, which has much more complexity. For this, there is a separated commandline
called media2rst

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbtools.py#L107

The media2rst needs several special handlings, which is implemented in 
hooks (the dbxml interface method)

* https://github.com/return42/sphkerneldoc/blob/master/scripts/media.py

Summarize, why should one prefer this tools over pandoc + sed?

* Pandoc coverage is less on reading and writing, this is where 
  dbxml comes into play

  - reading DocBook: 

https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
  
  - writing reST has many bugs and leaks 
(you fixed some of them with sed)

* Pandoc does not support external entities (linux-tv), covered by dbxml

* dbxml brings the ability to chunk one large XML book into small 
  reST chunks e.g. kernel-hacking book:


https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking

* dbxml lets you manipulate the XML source before you convert it to reST

  this might helpfull e.g. if you have to convert single-column informal-tables 
  to lists or other things ... in short; dbxml and it's hooks are the key to 
hack
  everything you need in a full automated DocBook-->reST migration workflow.


--Markus--

> Thanks for looking into this, anyway; I hope to be able to focus more on
> it shortly.
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH RFC 2/3] vfio: report group noiommu status

[Michael S. Tsirkin]

When using vfio, callers might want to know whether device is added to a
regular group or an non-iommu group.

Report this status from vfio_add_group_dev.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/vfio/pci/vfio_pci.c  | 2 +-
 drivers/vfio/platform/vfio_platform_common.c | 2 +-
 drivers/vfio/vfio.c  | 5 -
 Documentation/vfio.txt   | 4 +++-
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 712a849..d622a41 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1119,7 +1119,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
spin_lock_init(&vdev->irqlock);
 
ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
-   if (ret) {
+   if (ret < 0) {
vfio_iommu_group_put(group, &pdev->dev);
kfree(vdev);
return ret;
diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index e65b142..bf74e21 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -568,7 +568,7 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
}
 
ret = vfio_add_group_dev(dev, &vfio_platform_ops, vdev);
-   if (ret) {
+   if (ret < 0) {
iommu_group_put(group);
return ret;
}
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 6fd6fa5..67db231 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -756,6 +756,7 @@ int vfio_add_group_dev(struct device *dev,
struct iommu_group *iommu_group;
struct vfio_group *group;
struct vfio_device *device;
+   int noiommu;
 
iommu_group = iommu_group_get(dev);
if (!iommu_group)
@@ -791,6 +792,8 @@ int vfio_add_group_dev(struct device *dev,
return PTR_ERR(device);
}
 
+   noiommu = group->noiommu;
+
/*
 * Drop all but the vfio_device reference.  The vfio_device holds
 * a reference to the vfio_group, which holds a reference to the
@@ -798,7 +801,7 @@ int vfio_add_group_dev(struct device *dev,
 */
vfio_group_put(group);
 
-   return 0;
+   return noiommu;
 }
 EXPORT_SYMBOL_GPL(vfio_add_group_dev);
 
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 1dd3fdd..d76be0f 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -259,7 +259,9 @@ extern void *vfio_del_group_dev(struct device *dev);
 
 vfio_add_group_dev() indicates to the core to begin tracking the
 specified iommu_group and register the specified dev as owned by
-a VFIO bus driver.  The driver provides an ops structure for callbacks
+a VFIO bus driver.  A negative return value indicates failure.
+A positive return value indicates that an unsafe noiommu mode
+is in use.  The driver provides an ops structure for callbacks
 similar to a file operations structure:
 
 struct vfio_device_ops {
-- 
MST

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

[RFC v6 04/10] PCI: Add support for enforcing all MMIO BARs to be page aligned

[Yongji Xie]

When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.

This is because vfio will not allow to passthrough one BAR's
mmio page which may be shared with other BARs. Otherwise,
there will be a backdoor that guest can use to access BARs
of other guest.

To solve this issue, this patch modifies resource_alignment
to support syntax where multiple devices get the same
alignment. So we can use something like
"pci=resource_alignment=*:*:*.*:noresize" to enforce the
alignment of all MMIO BARs to be at least PAGE_SIZE so that
one BAR's mmio page would not be shared with other BARs.

And we also define a macro PCIBIOS_MIN_ALIGNMENT to enable this
automatically on PPC64 platform which can easily hit this issue
because its PAGE_SIZE is 64KB.

Signed-off-by: Yongji Xie 
---
 Documentation/kernel-parameters.txt |2 ++
 arch/powerpc/include/asm/pci.h  |2 ++
 drivers/pci/pci.c   |   64 +--
 3 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index d8b29ab..542be4a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
aligned memory resources.
If  is not specified,
PAGE_SIZE is used as alignment.
+   , ,  and  can be set to
+   "*" which means match all values.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
noresize: Don't change the resources' sizes when
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6f8065a..78f230f 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -30,6 +30,8 @@
 #define PCIBIOS_MIN_IO 0x1000
 #define PCIBIOS_MIN_MEM0x1000
 
+#define PCIBIOS_MIN_ALIGNMENT  PAGE_SIZE
+
 struct pci_dev;
 
 /* Values for the `which' argument to sys_pciconfig_iobase syscall.  */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7564ccc..0381c28 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4605,7 +4605,12 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
char *p;
+   bool invalid = false;
 
+#ifdef PCIBIOS_MIN_ALIGNMENT
+   align = PCIBIOS_MIN_ALIGNMENT;
+   *resize = false;
+#endif
spin_lock(&resource_alignment_lock);
p = resource_alignment_param;
while (*p) {
@@ -4622,16 +4627,49 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
} else {
align_order = -1;
}
-   if (sscanf(p, "%x:%x:%x.%x%n",
-   &seg, &bus, &slot, &func, &count) != 4) {
+   if (p[0] == '*' && p[1] == ':') {
+   seg = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", &seg, &count) != 1 ||
+   p[count] != ':') {
+   invalid = true;
+   break;
+   }
+   p += count + 1;
+   if (*p == '*') {
+   bus = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", &bus, &count) != 1) {
+   invalid = true;
+   break;
+   }
+   p += count;
+   if (*p == '.') {
+   slot = bus;
+   bus = seg;
seg = 0;
-   if (sscanf(p, "%x:%x.%x%n",
-   &bus, &slot, &func, &count) != 3) {
-   /* Invalid format */
-   printk(KERN_ERR "PCI: Can't parse 
resource_alignment parameter: %s\n",
-   p);
+   p++;
+   } else if (*p == ':') {
+   p++;
+   if (p[0] == '*' && p[1] == '.') {
+   slot = -1;
+   count = 1;
+   } else if (sscanf(p, "%x%n", &slot, &count) != 1 ||
+   p[count] != '.') {
+   invalid = true;
break;
}
+   p += count + 1;
+   } else {
+   invalid = true;
+   break;
+   }
+ 

[RFC v6 01/10] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

[Yongji Xie]

The resource_alignment will releases memory resources allocated
by firmware so that kernel can reassign new resources later on.
But this will cause the problem that no resources can be
allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries
platform because PCI_PROBE_ONLY force kernel to use firmware
setup and not to reassign any resources.

To solve this problem, this patch ignores resource_alignment
if PCI_PROBE_ONLY was set.

Signed-off-by: Yongji Xie 
---
 drivers/pci/pci.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..77b7494 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4607,6 +4607,12 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev)
spin_lock(&resource_alignment_lock);
p = resource_alignment_param;
while (*p) {
+   if (pci_has_flag(PCI_PROBE_ONLY)) {
+   printk(KERN_ERR "PCI: Ignore resource_alignment 
parameter: %s with PCI_PROBE_ONLY set\n",
+   p);
+   *p = 0;
+   break;
+   }
count = 0;
if (sscanf(p, "%d%n", &align_order, &count) == 1 &&
p[count] == '@') {
-- 
1.7.9.5

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

[RFC v6 00/10] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table

[Yongji Xie]

Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because
sub-page BARs' mmio page may be shared with other BARs and MSI-X table
should not be accessed directly from the guest for security reasons.

But it will easily cause some performance issues for mmio accesses
in guest when vfio passthrough sub-page BARs or BARs containing MSI-X
table on PPC64 platform. This is because PAGE_SIZE is 64KB by default
on PPC64 platform and the big page may easily hit the sub-page MMIO
BARs' unmmapping and cause the unmmaping of the mmio page which
MSI-X table locate in, which lead to mmio emulation in host.

For sub-page MMIO BARs' unmmapping, this patchset modifies
resource_alignment kernel parameter to enforce the alignment of all 
MMIO BARs to be at least PAGE_SZIE so that sub-page BAR's mmio page
will not be shared with other BARs. And we also add shadow resources
to the vfio device and put them into the holes of mmio pages in case
that hot-add device's BARs are assigned into the holes. Then we can 
mmap sub-page MMIO BARs safely.

For MSI-X table's unmmapping, we think MSI-X table is safe to access
directly from userspace if hardware supports the capability of  
interrupt remapping which can ensure that a given pci device can 
only shoot the MSIs assigned for it. But the implenmentation of  
this capability is arch-independent. To have a universal way 
to test this capability on PCI side for different archs, we introduce
a new bus_flags PCI_BUS_FLAGS_MSI_REMAP.

With this patchset applied, we can get almost 100% improvement on
performance for small block 4k random read when we passthrough a FC
HBA containing sub-page BARs and MSI-X BARs to guest on PPC64 in
our test.

The patch 8 are based on the proposed patchset[2].

Changelog v6: 
- Rebase on vfio/next with patchset[2] applied
- Fix some bugs of v5
- Add three patches to make PCI_BUS_FLAGS_MSI_REMAP as
  a universal flag to test IRQ remapping

Changelog v5:
- Rebase on vfio/next
- Change the order of patch 1,2,3
- Move the warning "resource_alignment will not work with
  PCI_PROBE_ONLY set" from documentation to kernel log
- Remove IORESOURCE_WINDOW
- Add description for parameter "resize"
- Add PCIBIOS_MIN_ALIGNMENT to force all MMIO BARs to
  get minimum alignment
- Add shadow resources to make sure sub-page BAR's mmio
  page will not be shared with hot-add BARs.
- Add a new bit to pci_bus_flags to indicate the capbility
  of interrupt remapping on PPC64
- Remove IOMMU_CAP_INTR_REMAP on PPC64
- Add a property msi_remap to vfio_pci_device to cache the
  capbility of interrupt remapping

Changelog v4:
- Rebase on v4.5-rc6 with patchset[1] applied.
- Remove resource_page_aligned kernel parameter
- Fix some problems with resource_alignment kernel parameter
- Modify resource_alignment kernel parameter to support multiple
  devices.
- Remove host bridge attribute: msi_filtered
- Use IOMMU_CAP_INTR_REMAP to check if MSI-X table can be mmapped
- Add IOMMU_CAP_INTR_REMAP for IODA host bridge on PPC64 platform

Changelog v3:
- Rebase on new linux kernel mainline with the patchset[1] applied.
- Add a function to check whether PCI BARs'mmio page is shared with
  other BARs.
- Add a host bridge attribute to indicate PCI host bridge support
  filtering of MSIs.
- Use the new host bridge attribute to check if MSI-X table can
  be mmapped instead of CONFIG_EEH.
- Remove Kconfig option VFIO_PCI_MMAP_MSIX

Changelog v2:
- Rebase on v4.4-rc6 with the patchset[1] applied.
- Use kernel parameter to enforce all MMIO BARs to be page aligned
  on PCI core code instead of doing it on PPC64 arch code.
- Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED

[1] http://www.spinics.net/lists/kvm/msg127812.html
[2] http://www.spinics.net/lists/kvm/msg130256.html

Yongji Xie (10):
  PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
  PCI: Do not Use IORESOURCE_STARTALIGN to identify bridge resources
  PCI: Add a new option for resource_alignment to reassign alignment
  PCI: Add support for enforcing all MMIO BARs to be page aligned
  vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping
  PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller supports IRQ remapping
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

 Documentation/kernel-parameters.txt   |7 +-
 arch/powerpc/include/asm/pci.h|2 +
 arch/powerpc/platforms/powernv/pci-ioda.c |8 +++
 drivers/iommu/iommu.c |   15 +
 drivers/pci/msi.c |   12 
 drivers/pci/pci.c |  105 +++--
 drivers/pci/probe.c   |3 +
 drivers/pci/setup-bus.c   |9 ++-
 drivers/vfio/pci/vfio_pci.c   |  

[RFC v6 02/10] PCI: Do not Use IORESOURCE_STARTALIGN to identify bridge resources

[Yongji Xie]

Now we use the IORESOURCE_STARTALIGN to identify bridge resources
in __assign_resources_sorted(). That's quite fragile. We can't
make sure that the PCI devices' resources will not use
IORESOURCE_STARTALIGN any more.

In this patch, we try to use a more robust way to identify
bridge resources.

Signed-off-by: Yongji Xie 
---
 drivers/pci/setup-bus.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..45fc484 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -391,6 +391,7 @@ static void __assign_resources_sorted(struct list_head 
*head,
struct pci_dev_resource *dev_res, *tmp_res, *dev_res2;
unsigned long fail_type;
resource_size_t add_align, align;
+   int index;
 
/* Check if optional add_size is there */
if (!realloc_head || list_empty(realloc_head))
@@ -411,11 +412,13 @@ static void __assign_resources_sorted(struct list_head 
*head,
 
/*
 * There are two kinds of additional resources in the list:
-* 1. bridge resource  -- IORESOURCE_STARTALIGN
-* 2. SR-IOV resource   -- IORESOURCE_SIZEALIGN
+* 1. bridge resource
+* 2. SR-IOV resource
 * Here just fix the additional alignment for bridge
 */
-   if (!(dev_res->res->flags & IORESOURCE_STARTALIGN))
+   index = dev_res->res - dev_res->dev->resource;
+   if (index < PCI_BRIDGE_RESOURCES ||
+   index > PCI_BRIDGE_RESOURCE_END)
continue;
 
add_align = get_res_add_align(realloc_head, dev_res->res);
-- 
1.7.9.5

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

[RFC v6 03/10] PCI: Add a new option for resource_alignment to reassign alignment

[Yongji Xie]

When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers. For example, the driver
uses the size to locate some register whose length is related
to the size.

This patch adds a new option "noresize" for the parameter to
solve this problem.

Signed-off-by: Yongji Xie 
---
 Documentation/kernel-parameters.txt |5 -
 drivers/pci/pci.c   |   35 +--
 2 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 9a53c92..d8b29ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2912,13 +2912,16 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
window. The default value is 64 megabytes.
resource_alignment=
Format:
-   [@][:]:.[; ...]
+   [@][:]:.
+   [:noresize][; ...]
Specifies alignment and device to reassign
aligned memory resources.
If  is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+   noresize: Don't change the resources' sizes when
+   reassigning alignment.
ecrc=   Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 77b7494..7564ccc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4594,11 +4594,13 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
 /**
  * pci_specified_resource_alignment - get resource alignment specified by user.
  * @dev: the PCI device to get
+ * @resize: whether or not to change resources' size when reassigning alignment
  *
  * RETURNS: Resource alignment if it is specified.
  *  Zero if it is not specified.
  */
-static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
+static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
+   bool *resize)
 {
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
@@ -4632,6 +4634,11 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev)
}
}
p += count;
+   if (!strncmp(p, ":noresize", 9)) {
+   *resize = false;
+   p += 9;
+   } else
+   *resize = true;
if (seg == pci_domain_nr(dev->bus) &&
bus == dev->bus->number &&
slot == PCI_SLOT(dev->devfn) &&
@@ -4664,11 +4671,12 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
*dev)
 {
int i;
struct resource *r;
+   bool resize = true;
resource_size_t align, size;
u16 command;
 
/* check if specified PCI is target device to reassign */
-   align = pci_specified_resource_alignment(dev);
+   align = pci_specified_resource_alignment(dev, &resize);
if (!align)
return;
 
@@ -4690,15 +4698,22 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
*dev)
if (!(r->flags & IORESOURCE_MEM))
continue;
size = resource_size(r);
-   if (size < align) {
-   size = align;
-   dev_info(&dev->dev,
-   "Rounding up size of resource #%d to %#llx.\n",
-   i, (unsigned long long)size);
+   if (resize) {
+   if (size < align) {
+   size = align;
+   dev_info(&dev->dev,
+   "Rounding up size of resource #%d to 
%#llx.\n",
+   i, (unsigned long long)size);
+   }
+   r->flags |= IORESOURCE_UNSET;
+   r->end = size - 1;
+   r->start = 0;
+   } else {
+   r->flags &= ~IORESOURCE_SIZEALIGN;
+   r->flags |= IORESOURCE_STARTALIGN | IORESOURCE_UNSET;
+   r->start = max(align, size);
+   r->end = r->start + size - 1;
}
-   r->flags |= IORESOURCE_UNSET;
-   r->end = size - 1;
-   r->start = 0

[RFC v6 05/10] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

[Yongji Xie]

Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs.

But we should allow to mmap these sub-page MMIO BARs if we can
make sure these BARs' mmio page will not be shared with other BARs.

To acheive that, we firstly need to enforce all PCI MMIO BARs
to be page aligned like the commit "PCI: Add support for
enforcing all MMIO BARs to be page aligned" does. Most of PCI
BARs will be assigned into an exclusive page with a hole. Then,
we must make sure that hot-add device's BAR will never be assigned
into the hole. So we add shadow resources and put them into the
hole in this patch. With these two guarantees, I think it should
be safe to mmap sub-page BAR.

Signed-off-by: Yongji Xie 
---
 drivers/vfio/pci/vfio_pci.c |   58 ++-
 drivers/vfio/pci/vfio_pci_private.h |8 +
 2 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 98059df..dc1779c 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -110,13 +110,47 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
 }
 
+static bool vfio_pci_bar_mmap_supported(struct vfio_pci_device *vdev, int 
index)
+{
+   struct resource *res = vdev->pdev->resource + index;
+   struct vfio_pci_shadow_resource *shadow_res;
+
+   if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) && res->flags & IORESOURCE_MEM &&
+   resource_size(res) > 0) {
+   if (resource_size(res) >= PAGE_SIZE)
+   return true;
+
+   if (!(res->start & ~PAGE_MASK)) {
+   /*
+* Add shadow resource for sub-page bar whose mmio
+* page is exclusive in case that hot-add device's
+* bar is assigned into the mem hole.
+*/
+   shadow_res = kzalloc(sizeof(*shadow_res), GFP_KERNEL);
+   shadow_res->resource.start = res->end + 1;
+   shadow_res->resource.end = res->start + PAGE_SIZE - 1;
+   shadow_res->resource.flags = res->flags;
+   if (request_resource(res->parent,
+   &shadow_res->resource)) {
+   kfree(shadow_res);
+   return false;
+   }
+   shadow_res->index = index;
+   list_add(&shadow_res->res_next,
+   &vdev->shadow_resources_list);
+   return true;
+   }
+   }
+   return false;
+}
+
 static void vfio_pci_try_bus_reset(struct vfio_pci_device *vdev);
 static void vfio_pci_disable(struct vfio_pci_device *vdev);
 
 static int vfio_pci_enable(struct vfio_pci_device *vdev)
 {
struct pci_dev *pdev = vdev->pdev;
-   int ret;
+   int ret, bar;
u16 cmd;
u8 msix_pos;
 
@@ -183,12 +217,17 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
}
}
 
+   for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
+   vdev->bar_mmap_supported[bar] =
+   vfio_pci_bar_mmap_supported(vdev, bar);
+   }
return 0;
 }
 
 static void vfio_pci_disable(struct vfio_pci_device *vdev)
 {
struct pci_dev *pdev = vdev->pdev;
+   struct vfio_pci_shadow_resource *shadow_res, *tmp;
int i, bar;
 
/* Stop the device from further DMA */
@@ -217,6 +256,13 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
vdev->barmap[bar] = NULL;
}
 
+   list_for_each_entry_safe(shadow_res, tmp,
+&vdev->shadow_resources_list, res_next) {
+   list_del(&shadow_res->res_next);
+   release_resource(&shadow_res->resource);
+   kfree(shadow_res);
+   }
+
vdev->needs_reset = true;
 
/*
@@ -587,9 +633,7 @@ static long vfio_pci_ioctl(void *device_data,
 
info.flags = VFIO_REGION_INFO_FLAG_READ |
 VFIO_REGION_INFO_FLAG_WRITE;
-   if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
-   pci_resource_flags(pdev, info.index) &
-   IORESOURCE_MEM && info.size >= PAGE_SIZE) {
+   if (vdev->bar_mmap_supported[info.index]) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
if (info.index == vdev->msix_bar) {
ret = msix_sparse_mmap_cap(vdev, &caps);
@@ -1011,16 +1055,16 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
return -EINVAL;
if (in

[RFC v6 07/10] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

[Yongji Xie]

The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.

To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when IOMMU_CAP_INTR_REMAP is set.

Signed-off-by: Yongji Xie 
---
 drivers/iommu/iommu.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0e3b009..5d2b6f6 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -813,6 +813,16 @@ struct iommu_group *pci_device_group(struct device *dev)
return group;
 }
 
+static void pci_check_msi_remapping(struct pci_dev *pdev,
+   const struct iommu_ops *ops)
+{
+   struct pci_bus *bus = pdev->bus;
+
+   if (ops->capable(IOMMU_CAP_INTR_REMAP) &&
+   !(bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP))
+   bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
@@ -871,6 +881,9 @@ static int add_iommu_group(struct device *dev, void *data)
const struct iommu_ops *ops = cb->ops;
int ret;
 
+   if (dev_is_pci(dev) && ops->capable)
+   pci_check_msi_remapping(to_pci_dev(dev), ops);
+
if (!ops->add_device)
return 0;
 
@@ -913,6 +926,8 @@ static int iommu_bus_notifier(struct notifier_block *nb,
 * result in ADD/DEL notifiers to group->notifier
 */
if (action == BUS_NOTIFY_ADD_DEVICE) {
+   if (dev_is_pci(dev) && ops->capable)
+   pci_check_msi_remapping(to_pci_dev(dev), ops);
if (ops->add_device)
return ops->add_device(dev);
} else if (action == BUS_NOTIFY_REMOVED_DEVICE) {
-- 
1.7.9.5

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

[RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[Yongji Xie]

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates all devices on the bus are protected by the
hardware which supports IRQ remapping(intel naming).

This flag will be used to know whether it's safe to expose
MSI-X tables of PCI BARs to userspace. Because the capability
of IRQ remapping can guarantee the PCI device cannot trigger
MSIs that correspond to interrupt IDs of other devices.

There is a existing flag for this in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract this
capability on MSI controller side for ARM. But it would
make sense to have a more common flag like
PCI_BUS_FLAGS_MSI_REMAP so that we can use a universal
flag to test this capability for different archs on
PCI side.

[1] http://www.spinics.net/lists/kvm/msg130256.html

Signed-off-by: Yongji Xie 
---
 include/linux/pci.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..d619228 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short __bitwise pci_bus_flags_t;
 enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI   = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 4,
 };
 
 /* These values come from the PCI Express Spec */
-- 
1.7.9.5

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

[RFC v6 10/10] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

[Yongji Xie]

This patch enables mmapping MSI-X tables if hardware supports
interrupt remapping which can ensure that a given pci device
can only shoot the MSIs assigned for it.

With MSI-X table mmapped, we also need to expose the
read/write interface which will be used to access MSI-X table.

Signed-off-by: Yongji Xie 
---
 drivers/vfio/pci/vfio_pci.c  |7 +--
 drivers/vfio/pci/vfio_pci_rdwr.c |3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index dc1779c..b08abe0 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -635,7 +635,9 @@ static long vfio_pci_ioctl(void *device_data,
 VFIO_REGION_INFO_FLAG_WRITE;
if (vdev->bar_mmap_supported[info.index]) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
-   if (info.index == vdev->msix_bar) {
+   if (info.index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags &
+   PCI_BUS_FLAGS_MSI_REMAP)) {
ret = msix_sparse_mmap_cap(vdev, &caps);
if (ret)
return ret;
@@ -1067,7 +1069,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9..dbf9cd0 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
1.7.9.5

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

[RFC v6 08/10] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller supports IRQ remapping

[Yongji Xie]

On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].

To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when MSI_FLAG_IRQ_REMAPPING is set.

[1] http://www.spinics.net/lists/kvm/msg130256.html

Signed-off-by: Yongji Xie 
---
 drivers/pci/msi.c   |   12 
 drivers/pci/probe.c |3 +++
 include/linux/msi.h |6 +-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f44..1661cdf 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1134,6 +1134,18 @@ void *msi_desc_to_pci_sysdata(struct msi_desc *desc)
 }
 EXPORT_SYMBOL_GPL(msi_desc_to_pci_sysdata);
 
+void pci_bus_check_msi_remapping(struct pci_bus *bus,
+struct irq_domain *domain)
+{
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+   struct msi_domain_info *info;
+
+   info = msi_get_domain_info(domain);
+   if (info->flags & MSI_FLAG_IRQ_REMAPPING)
+   bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+#endif
+}
+
 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
 /**
  * pci_msi_domain_write_msg - Helper to write MSI message to PCI config space
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..25cf1b1 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -696,6 +696,9 @@ static void pci_set_bus_msi_domain(struct pci_bus *bus)
if (!d)
d = pci_host_bridge_msi_domain(b);
 
+   if (d && b == bus)
+   pci_bus_check_msi_remapping(bus, d);
+
dev_set_msi_domain(&bus->dev, d);
 }
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 03eda72..b4c649e 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -15,6 +15,8 @@ extern int pci_msi_ignore_mask;
 struct irq_data;
 struct msi_desc;
 struct pci_dev;
+struct pci_bus;
+struct irq_domain;
 struct platform_msi_priv_data;
 void __get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg);
@@ -155,6 +157,9 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
 void default_teardown_msi_irqs(struct pci_dev *dev);
 void default_restore_msi_irqs(struct pci_dev *dev);
 
+void pci_bus_check_msi_remapping(struct pci_bus *bus,
+struct irq_domain *domain);
+
 struct msi_controller {
struct module *owner;
struct device *dev;
@@ -173,7 +178,6 @@ struct msi_controller {
 #include 
 #include 
 
-struct irq_domain;
 struct irq_domain_ops;
 struct irq_chip;
 struct device_node;
-- 
1.7.9.5

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

[RFC v6 09/10] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

[Yongji Xie]

Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
---
 arch/powerpc/platforms/powernv/pci-ioda.c |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f90dc04..9557638 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3080,6 +3080,12 @@ static void pnv_pci_ioda_fixup(void)
pnv_npu_ioda_fixup();
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3364,6 +3370,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU)
hose->controller_ops = pnv_npu_ioda_controller_ops;
else
-- 
1.7.9.5

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

[PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Provide *our* view of what the rules are for the different DAI formats,
so that we do not have to trust external interpretations for this
crucial bit of interoperability.

Signed-off-by: Peter Rosin 
---
 Documentation/sound/alsa/soc/clocking.txt | 110 +-
 1 file changed, 108 insertions(+), 2 deletions(-)

Now, the reason for me writing this is that I once again had to go hunting
the internet to find the rules for these things. And like last time, I
found no definitive source and sometimes strange things as well. So, I don't
know if the above is 100% good, but it is my understanding of the subject.

Please enlighten me on any errors.

Cheers,
Peter

diff --git a/Documentation/sound/alsa/soc/clocking.txt 
b/Documentation/sound/alsa/soc/clocking.txt
index b1300162e01c..8b498d610e10 100644
--- a/Documentation/sound/alsa/soc/clocking.txt
+++ b/Documentation/sound/alsa/soc/clocking.txt
@@ -47,5 +47,111 @@ rate, number of channels and word size) to save on power.
 It is also desirable to use the codec (if possible) to drive (or master) the
 audio clocks as it usually gives more accurate sample rates than the CPU.
 
-
-
+The below diagrams all have BCLK as the first signal, LRC as the second signal
+and DATA as the third. Below that is an indication about which DATA bits belong
+in what channel.
+
+A "..." marking as DATA indicates that there may be more bits that are not
+shown. Also, all DATA bits marked X may or may not be present. DAI
+transmitters must add them should LRC not match the word size exactly and DAI
+receivers must be prepared to ignore them. DAI transmitters must insert
+zeros for I2S, Left and Right Justified modes, and preferably not drive DATA
+for the DSP modes for these extra X bits.
+
+
+I2S
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+---.   .---.
+   '---'   '-
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   |   |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB| X |...| X |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+Left Justified (aka MSB)
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+   .---.   .-
+---'   '---'
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB| X |...| X |   |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+Right Justified (aka LSB)
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+   .---.   .-
+---'   '---'
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   | X |...| X |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB|   |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+DSP mode A
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+  -.  -.
+   '-  '-
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   |   |MSB|   |...|   |LSB|MSB|   |...|   |LSB| X |   |...|   | X |   |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |   |
+
+LRC examples for DSP mode A
+   .---.   .---.
+---'   '---'   '-
+ .-. .-.
+-' '-' '-
+---. .-. .---
+   '-' '-'
+
+
+DSP mode B
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+   .-  .-
+  -'  -'
+---.---.---.---.---.---.---.---.---.-

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Mon, 18 Apr 2016 10:10:17 +0200
Markus Heiser  escreveu:

> Hi Mauro, hi kernel-doc authors, 
> 
> Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Fri, 8 Apr 2016 17:12:27 +0200
> > Markus Heiser  escreveu:
> >   
> >> Hi kernel-doc authors,
> >> 
> >> motivated by this MT, I implemented a toolchain to migrate the kernel’s 
> >> DocBook XML documentation to reST markup. 
> >> 
> >> It converts 99% of the docs well ... to gain an impression how 
> >> kernel-docs could benefit from, visit my sphkerneldoc project page
> >> on github:
> >> 
> >> http://return42.github.io/sphkerneldoc/
> >> 
> >> The sources available at:
> >> 
> >> https://github.com/return42/sphkerneldoc
> >> 
> >> The work is underway, suggestions are welcome!
> >> 
> >> .. have a nice weekend ..  
> > 
> > Hi Markus,
> > 
> > Thanks for your work. I'm basically worried about the media docbook,
> > with has some complexities that I was not able to figure out a way to
> > convert it to reST.
> > 
> > So, let me pinpoint some issues that I noticed there, on a quick
> > look.
> > 
> > The first thing I noticed is that the index doesn't match what's
> > there, when generated from DocBook:
> > https://linuxtv.org/downloads/v4l-dvb-apis/v4l2spec.html
> > 
> > So, for instance, "Interfaces" is at the same level as "Input/Output".
> > 
> > This sounds like an something went wrong when dealing with the title
> > indentation levels during the conversion.
> >   
> 
> Yes, the hierarchical structure was broken by two causes. First was, that the
> *chunking* was wrong and the other was, that my DocBook-XML-filter (dbxml) 
> placed
> all sections and sub(-sub)-sections at the same level (direct under chapter). 
> This was
> not only broken in the linux_tv book, in the other books also.
> 
> Thanks for pointing and sorry that I have overlooked this (I was so much 
> focused on
> on converting single elements to reST, that I not see the wood for the trees).
> 
> It is now fixed, may you give it a new try.

Thanks! It looks good now.

> > I would also like to see the titles numbered in chapters (and, if
> > possible, in sections and items) and to be properly indented at the 
> > index.  
> 
> BTW a few words about differences between DockBook and reST (Sphinx).
> 
> With DocBook you write *books*, the protocol (the DocBook application) has
> no facility to *chunk* and interconnect several documents. The external 
> ENTITY 
> is a workaround on the SGML layer, not on XML nor on the DB-application layer.
> Thats the reason, why so many XML-tools don't handle this entities and
> many DocBook to (e.g.) reST tools are fail.
> 
> With **standard** reST it is nearly the same, except there is a "include"
> directive on the application layer. But this directive is very simple,
> comparable to the C preprocessor "#include" directive.
> 
> With the **superset** reST-markup of Sphinx-doc you get a the "toctree" 
> directive,
> which lets you control how a document-tree should be build.
> 
>  http://www.sphinx-doc.org/en/stable/markup/toctree.html
> 
> @Mauro: you mentioned a docutils (rst2*) experience in your mail 
>   http://marc.info/?l=linux-doc&m=145735316012094&w=2
> 
>   Because the "toctree" directive -- and other directives
>   we use -- are a part of a superset of the **standard** 
>   reST, the standard docutils (like rst2*) will not work.
> 
> OK, back to your requirements: within the toctree directive you can
> set options like "maxdepth" and "numbered". It is a decision, how
> deep TOCs should go and if they should be numbered. IMO, in a
> HTML rendered page, with a proper navigation bar on the side, deep 
> TOCs in the running text have no pros, they only blow up the running
> text and bring more scrolling with. In my sense numbering chapters
> make only sense in books, not in HTML pages, where you have hyperlinks.
> 
> Just for demonstration, I added numbering in the linux-tv book:
> 
> https://github.com/return42/sphkerneldoc/commit/468ded71f62d497ac71aead1a6d50de7ef77c3c3
> 
> May be, I will drop it later, because all reST sources are generated
> by a make target and I always commit the whole reST tree. As I said, 
> it is a decision which might be made later, when the migration takes 
> places.

This is the uAPI spec DocBook, that we modify frequently, as we add
more features to the Kernel, and as we make sure that all drivers will
behave the same. So, from time to time, we need to clarify some topics
at the documentation. By having a numeration, it is easier for us to
discuss things like:
"1.2.10.14. V4L2_PIX_FMT_VYUY (‘VYUY’)" is not properly
described and requires some sort of clarification.

Ok, one could also refer to it via a hyperlink, but several Kernel
media maintainers prefer to generate a single big html file, as it
makes easier to locate everything it is needed on it.

So, with the item number, they can just seek for "1.2.10.14. " string
to find the item that is under discussion.

> > Also

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Mark Brown]

On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote:

> +I2S
> + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
> +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-

There is an actual spec for I2S which is going to be clearer than ASCII
art:

   https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf

is the first hit on google (there's a bunch of electrical stuff in there
that gets roundly ignord these days but the clocking stuff is in there).

In general I'd rather have some words rather than just pictures, ASCII
art as the only thing is pretty hard to read.


signature.asc
Description: PGP signature

RE: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[David Laight]

From: Yongji Xie
> Sent: 18 April 2016 11:59
> We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
> which indicates all devices on the bus are protected by the
> hardware which supports IRQ remapping(intel naming).
> 
> This flag will be used to know whether it's safe to expose
> MSI-X tables of PCI BARs to userspace. Because the capability
> of IRQ remapping can guarantee the PCI device cannot trigger
> MSIs that correspond to interrupt IDs of other devices.

I'm worried that this entire series is going to break drivers
for existing hardware.

I understand some of the reasoning for 'vm pass through' configurations,
but there will be PCIe devices out there that have the MSI-X tables
in the same BAR as other device registers.
If you are lucky nothing else is in the same 4k area, but I wouldn't
assume it.

In any case, if the hardware can't police the card's master transfers
there is nothing to stop a different bus master block on the card
from raising MSI-X interrupts - they are just a PCIe write.
So all you are doing is raising the bar slightly and giving a very false
sense of security.

David

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Mark Brown wrote:
> On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote:
> 
> > +I2S
> > + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
> > +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
> 
> There is an actual spec for I2S which is going to be clearer than ASCII
> art:
> 
>https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
> 
> is the first hit on google (there's a bunch of electrical stuff in there
> that gets roundly ignord these days but the clocking stuff is in there).

Yes, but where are the equivalent docs for the other formats?

> In general I'd rather have some words rather than just pictures, ASCII
> art as the only thing is pretty hard to read.

I'll post a v2 with some words about each format. Or will you reject
anything with ASCII art?

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

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Mark Brown]

On Mon, Apr 18, 2016 at 12:55:23PM +, Peter Rosin wrote:
> Mark Brown wrote:

> > There is an actual spec for I2S which is going to be clearer than ASCII
> > art:

> >https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf

> > is the first hit on google (there's a bunch of electrical stuff in there
> > that gets roundly ignord these days but the clocking stuff is in there).

> Yes, but where are the equivalent docs for the other formats?

There aren't any (beyond the usual references to the Wolfson datasheets
which I'd suggest should be in here) but that doesn't mean we should
ignore this spec when we have it.

> > In general I'd rather have some words rather than just pictures, ASCII
> > art as the only thing is pretty hard to read.

> I'll post a v2 with some words about each format. Or will you reject
> anything with ASCII art?

So long as it's comprehensible.


signature.asc
Description: PGP signature

SV: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Mark Brown wrote:
> On Mon, Apr 18, 2016 at 12:55:23PM +, Peter Rosin wrote:
> > Mark Brown wrote:
> 
> > > There is an actual spec for I2S which is going to be clearer than ASCII
> > > art:
> 
> > >https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
> 
> > > is the first hit on google (there's a bunch of electrical stuff in there
> > > that gets roundly ignord these days but the clocking stuff is in there).
> 
> > Yes, but where are the equivalent docs for the other formats?
> 
> There aren't any (beyond the usual references to the Wolfson datasheets
> which I'd suggest should be in here) but that doesn't mean we should
> ignore this spec when we have it.

This is exactly the problem. For an outsider, it's impossible to know that
wolfson has the correct definition of the modes. Why should wolfson datasheets
trumph nxp or ti datasheets (or whatever), if there is an inconsistency?

We need to specify somewhere exactly what Linux means with the different
modes. Because there are bugs in this area, where DAIs claim to support
the same format but are not actually compatible. Which one is buggy then?
And this is not about flank timings or such details, it's about what bits go
where in relation to flanks etc.

> > > In general I'd rather have some words rather than just pictures, ASCII
> > > art as the only thing is pretty hard to read.
> 
> > I'll post a v2 with some words about each format. Or will you reject
> > anything with ASCII art?
> 
> So long as it's comprehensible.

Ok

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

[PATCH v2] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Provide *our* view of what the rules are for the different DAI formats,
so that we do not have to trust external interpretations for this
crucial bit of interoperability.

Signed-off-by: Peter Rosin 
---
 Documentation/sound/alsa/soc/clocking.txt | 145 +-
 1 file changed, 143 insertions(+), 2 deletions(-)

Now with some words on each format as well.

Cheers,
Peter

diff --git a/Documentation/sound/alsa/soc/clocking.txt 
b/Documentation/sound/alsa/soc/clocking.txt
index b1300162e01c..e74e91bbee94 100644
--- a/Documentation/sound/alsa/soc/clocking.txt
+++ b/Documentation/sound/alsa/soc/clocking.txt
@@ -47,5 +47,146 @@ rate, number of channels and word size) to save on power.
 It is also desirable to use the codec (if possible) to drive (or master) the
 audio clocks as it usually gives more accurate sample rates than the CPU.
 
-
-
+The below diagrams all have BCLK as the first signal, LRC as the second signal
+and DATA as the third. Below that is an indication about which DATA bits belong
+in what channel.
+
+A "..." marking as DATA indicates that there may be more bits that are not
+shown. Also, all DATA bits marked X may or may not be present. DAI
+transmitters must add them should LRC not match the word size exactly and DAI
+receivers must be prepared to ignore them. DAI transmitters must insert zeros
+for I2S and Left Justified modes, and preferably not drive DATA for the DSP
+modes for these extra X bits.
+
+
+I2S
+
+LRC should have its flanks synchronized with a negative flank of BCLK.
+The left channel word starts one BCLK cycle after a negative flank of LRC, and
+the right channel word starts one BCLK cycle after a positive flank of LRC. The
+words start with the MSB. Receivers must truncate words if more bits per word
+are transmitted than they can use, and transmitters must pad words with zeros
+if LRC is not matching the word size.
+
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+---.   .---.
+   '---'   '-
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   |   |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB| X |...| X |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+Left Justified (aka MSB)
+
+LRC should have its flanks synchronized with a negative flank of BCLK.
+The left channel word starts directly after a positive flank of LRC, and the
+right channel word starts directly after a negative flank of LRC. The words
+start with the MSB. Receivers must truncate words if more bits per word are
+transmitted than they can use, and transmitters must pad words with zeros if
+LRC is not matching the word size.
+
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+   .---.   .-
+---'   '---'
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB| X |...| X |   |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+Right Justified (aka LSB)
+
+LRC should have its flanks synchronized with a negative flank of BCLK.
+The left channel word end right before a negative flank of LRC, and the right
+channel word ends right before a positive flank of LRC. The words end with LSB.
+Receivers must truncate words if more bits per word are transmitted than they
+can use, and transmitters must pad words if LRC is not matching the word size.
+
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+   .---.   .-
+---'   '---'
+---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.-
+   | X |...| X |MSB|   |...|   |LSB| X |...| X |MSB|   |...|   |LSB|   |
+---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'-
+   | Left channel  | Right channel |
+
+
+DSP mode A
+
+LRC should have negative flanks synchronized with a negative flank of BCLK.
+The left channel word starts directly after a negative flank of LRC, and the
+right channel word starts directly after the left channel word. The words
+start with MSB.
+
+ .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
+-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
+  -. 

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

[Thor Thayer]

Hi Boris,

On 04/15/2016 04:46 PM, Borislav Petkov wrote:

On Fri, Apr 15, 2016 at 10:27:54AM -0500, Thor Thayer wrote:

I'll update this patch to only count errors.


... and also think about what that counting is going to bring. If it is
only going to be there to show how many network errors happened and we
can't do anything about it except stare at that number, then adding all
that code is probably waste of time an electrons...

I'm just sayin'.



Yes, valid point about the uncorrectable errors.

We're still getting the single bit correction which makes the entire 
system more stable and the ability to see both single bit errors 
corrected and the number of uncorrectable errors is useful from a system 
point of view.

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

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

[Joerg Roedel]

On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote:
> +#if defined(CONFIG_KASAN)
> +static const unsigned long memory_rand_end = KASAN_SHADOW_START;
> +#elfif defined(CONFIG_X86_ESPFIX64)
> +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR;
> +#elfif defined(CONFIG_EFI)
> +static const unsigned long memory_rand_end = EFI_VA_START;
> +#else
> +static const unsigned long memory_rand_end = __START_KERNEL_map;
> +#endif

That #elfif is a typo, right?


Joerg

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

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

[Thomas Garnier]

Yes, it is. Certainly happened while editing patches (sorry about
that), will be fixed on next iteration once I get a bit more feedback.

On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel  wrote:
> On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote:
>> +#if defined(CONFIG_KASAN)
>> +static const unsigned long memory_rand_end = KASAN_SHADOW_START;
>> +#elfif defined(CONFIG_X86_ESPFIX64)
>> +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR;
>> +#elfif defined(CONFIG_EFI)
>> +static const unsigned long memory_rand_end = EFI_VA_START;
>> +#else
>> +static const unsigned long memory_rand_end = __START_KERNEL_map;
>> +#endif
>
> That #elfif is a typo, right?
>
>
> Joerg
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SV: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Mark Brown]

On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote:
> Mark Brown wrote:

> > 
> > There aren't any (beyond the usual references to the Wolfson datasheets
> > which I'd suggest should be in here) but that doesn't mean we should
> > ignore this spec when we have it.

> This is exactly the problem. For an outsider, it's impossible to know that
> wolfson has the correct definition of the modes. Why should wolfson datasheets
> trumph nxp or ti datasheets (or whatever), if there is an inconsistency?

I'm not quite sure what your concern is here?  I'm saying that where
there are specs we should link to them.  I'm not saying we can't add
to that.


signature.asc
Description: PGP signature

[PATCH v11 3/4] tpm: Proxy driver for supporting multiple emulated TPMs

[Stefan Berger]

This patch implements a proxy driver for supporting multiple emulated TPMs
in a system.

The driver implements a device /dev/vtpmx that is used to created
a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that
is accessed using a file descriptor returned by an ioctl.
The device /dev/tpmX is the usual TPM device created by the core TPM
driver. Applications or kernel subsystems can send TPM commands to it
and the corresponding server-side file descriptor receives these
commands and delivers them to an emulated TPM.

The driver retrievs the TPM 1.2 durations and timeouts. Since this requires
the startup of the TPM, we send a startup for TPM 1.2 as well as TPM 2.

Signed-off-by: Stefan Berger 
Reviewed-by: Jason Gunthorpe 

CC: linux-ker...@vger.kernel.org
CC: linux-doc@vger.kernel.org
CC: linux-...@vger.kernel.org
---
 drivers/char/tpm/Kconfig  |  10 +
 drivers/char/tpm/Makefile |   1 +
 drivers/char/tpm/tpm_vtpm_proxy.c | 644 ++
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/vtpm_proxy.h   |  36 +++
 5 files changed, 692 insertions(+)
 create mode 100644 drivers/char/tpm/tpm_vtpm_proxy.c
 create mode 100644 include/uapi/linux/vtpm_proxy.h

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 3b84a8b..0eac596 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -122,5 +122,15 @@ config TCG_CRB
  from within Linux.  To compile this driver as a module, choose
  M here; the module will be called tpm_crb.
 
+config TCG_VTPM_PROXY
+   tristate "VTPM Proxy Interface"
+   depends on TCG_TPM
+   ---help---
+ This driver proxies for an emulated TPM (vTPM) running in userspace.
+ A device /dev/vtpmx is provided that creates a device pair
+ /dev/vtpmX and a server-side file descriptor on which the vTPM
+ can receive commands.
+
+
 source "drivers/char/tpm/st33zp24/Kconfig"
 endif # TCG_TPM
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index 56e8f1f..98de5e6 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
 obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
 obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
 obj-$(CONFIG_TCG_CRB) += tpm_crb.o
+obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c 
b/drivers/char/tpm/tpm_vtpm_proxy.c
new file mode 100644
index 000..4384042
--- /dev/null
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c
@@ -0,0 +1,644 @@
+/*
+ * Copyright (C) 2015, 2016 IBM Corporation
+ *
+ * Author: Stefan Berger 
+ *
+ * Maintained by: 
+ *
+ * Device driver for vTPM (vTPM proxy driver)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tpm.h"
+
+#define VTPM_PROXY_REQ_COMPLETE_FLAG  BIT(0)
+
+struct proxy_dev {
+   struct tpm_chip *chip;
+
+   u32 flags;   /* public API flags */
+
+   wait_queue_head_t wq;
+
+   struct mutex buf_lock;   /* protect buffer and flags */
+
+   long state;  /* internal state */
+#define STATE_OPENED_FLAGBIT(0)
+#define STATE_WAIT_RESPONSE_FLAG BIT(1)  /* waiting for emulator response */
+
+   size_t req_len;  /* length of queued TPM request */
+   size_t resp_len; /* length of queued TPM response */
+   u8 buffer[TPM_BUFSIZE];  /* request/response buffer */
+
+   struct work_struct work; /* task that retrieves TPM timeouts */
+};
+
+/* all supported flags */
+#define VTPM_PROXY_FLAGS_ALL  (VTPM_PROXY_FLAG_TPM2)
+
+static struct workqueue_struct *workqueue;
+
+static void vtpm_proxy_delete_device(struct proxy_dev *proxy_dev);
+
+/*
+ * Functions related to 'server side'
+ */
+
+/**
+ * vtpm_proxy_fops_read - Read TPM commands on 'server side'
+ *
+ * Return value:
+ * Number of bytes read or negative error code
+ */
+static ssize_t vtpm_proxy_fops_read(struct file *filp, char __user *buf,
+   size_t count, loff_t *off)
+{
+   struct proxy_dev *proxy_dev = filp->private_data;
+   size_t len;
+   int sig, rc;
+
+   sig = wait_event_interruptible(proxy_dev->wq,
+   proxy_dev->req_len != 0 ||
+   !(proxy_dev->state & STATE_OPENED_FLAG));
+   if (sig)
+   return -EINTR;
+
+   mutex_lock(&proxy_dev->buf_lock);
+
+   if (!(proxy_dev->state & STATE_OPENED_FLAG)) {
+   mutex_unlock(&proxy_dev->buf_lock);
+   return -EPIPE;
+   }
+
+   len = proxy_dev->req_len;
+
+   if (count < len) {
+   mutex_unlock(&proxy_dev->buf_lock);
+

[PATCH v11 4/4] tpm: Add documentation for the tpm_vtpm_proxy device driver

[Stefan Berger]

Add documentation for the tpm_vtpm device driver that implements
support for providing TPM functionality to Linux containers.

Parts of this documentation were recycled from the Xen vTPM
device driver documentation.

Update the documentation for the ioctl numbers.

Signed-off-by: Stefan Berger 
Reviewed-by: Jarkko Sakkinen 

CC: linux-ker...@vger.kernel.org
CC: linux-doc@vger.kernel.org
CC: linux-...@vger.kernel.org
---
 Documentation/ioctl/ioctl-number.txt |  1 +
 Documentation/tpm/tpm_vtpm_proxy.txt | 71 
 2 files changed, 72 insertions(+)
 create mode 100644 Documentation/tpm/tpm_vtpm_proxy.txt

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 91261a3..7dbec90 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -303,6 +303,7 @@ Code  Seq#(hex) Include FileComments

 0xA0   all linux/sdp/sdp.h Industrial Device Project

+0xA1   0   linux/vtpm_proxy.h  TPM Emulator Proxy Driver
 0xA2   00-0F   arch/tile/include/asm/hardwall.h
 0xA3   80-8F   Port ACLin development:

diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt 
b/Documentation/tpm/tpm_vtpm_proxy.txt
new file mode 100644
index 000..30d1902
--- /dev/null
+++ b/Documentation/tpm/tpm_vtpm_proxy.txt
@@ -0,0 +1,71 @@
+Virtual TPM Proxy Driver for Linux Containers
+
+Authors: Stefan Berger (IBM)
+
+This document describes the virtual Trusted Platform Module (vTPM)
+proxy device driver for Linux containers.
+
+INTRODUCTION
+
+
+The goal of this work is to provide TPM functionality to each Linux
+container. This allows programs to interact with a TPM in a container
+the same way they interact with a TPM on the physical system. Each
+container gets its own unique, emulated, software TPM.
+
+
+DESIGN
+--
+
+To make an emulated software TPM available to each container, the container
+management stack needs to create a device pair consisting of a client TPM
+character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
+descriptor. The former is moved into the container by creating a character
+device with the appropriate major and minor numbers while the file descriptor
+is passed to the TPM emulator. Software inside the container can then send
+TPM commands using the character device and the emulator will receive the
+commands via the file descriptor and use it for sending back responses.
+
+To support this, the virtual TPM proxy driver provides a device /dev/vtpmx
+that is used to create device pairs using an ioctl. The ioctl takes as
+an input flags for configuring the device. The flags  for example indicate
+whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
+The result of the ioctl are the file descriptor for the 'server side'
+as well as the major and minor numbers of the character device that was 
created.
+Besides that the number of the TPM character device is return. If for
+example /dev/tpm10 was created, the number (dev_num) 10 is returned.
+
+The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
+
+struct vtpm_proxy_new_dev {
+   __u32 flags; /* input */
+   __u32 tpm_num;   /* output */
+   __u32 fd;/* output */
+   __u32 major; /* output */
+   __u32 minor; /* output */
+};
+
+Note that if unsupported flags are passed to the device driver, the ioctl will
+fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl is
+called on the device driver, the ioctl will fail and errno will be set to
+ENOTTY.
+
+See /usr/include/linux/vtpm_proxy.h for definitions related to the public 
interface
+of this vTPM device driver.
+
+Once the device has been created, the driver will immediately try to talk
+to the TPM. All commands from the driver can be read from the file descriptor
+returned by the ioctl. The commands should be responded to immediately.
+
+Depending on the version of TPM the following commands will be sent by the
+driver:
+
+- TPM 1.2:
+  - the driver will send a TPM_Startup command to the TPM emulator
+  - the driver will send commands to read the command durations and
+interface timeouts from the TPM emulator
+- TPM 2:
+  - the driver will send a TPM2_Startup command to the TPM emulator
+
+The TPM device /dev/tpmX will only appear if all of the relevant commands
+were responded to properly.
-- 
2.4.3

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

Re: [PATCH] documentation: trivial typo: adding-syscalls.txt: s/statat/fstatat/

[Jonathan Corbet]

On Mon, 18 Apr 2016 20:30:56 +0300
Askar Safin  wrote:

> -page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
> +page; for an example of AT_EMPTY_PATH, see the fstatat(2) man page.)

Applied to the docs tree, thanks.

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

Greetings!!!

[andreas11]

Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] documentation: trivial typo: adding-syscalls.txt: s/statat/fstatat/

[Askar Safin]

Signed-off-by: Askar Safin 
---
diff --git a/Documentation/adding-syscalls.txt 
b/Documentation/adding-syscalls.txt
index cc2d4ac..bbb31e0 100644
--- a/Documentation/adding-syscalls.txt
+++ b/Documentation/adding-syscalls.txt
@@ -136,7 +136,7 @@ an fxyzzy(3) operation for free:
  - xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
 
 (For more details on the rationale of the *at() calls, see the openat(2) man
-page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
+page; for an example of AT_EMPTY_PATH, see the fstatat(2) man page.)
 
 If your new xyzzy(2) system call involves a parameter describing an offset
 within a file, make its type loff_t so that 64-bit offsets can be supported

Re: [PATCH RFC 2/3] vfio: report group noiommu status

[Alex Williamson]

On Mon, 18 Apr 2016 12:58:20 +0300
"Michael S. Tsirkin"  wrote:

> When using vfio, callers might want to know whether device is added to a
> regular group or an non-iommu group.
> 
> Report this status from vfio_add_group_dev.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---

What about making an interface to query this rather than playing games
with magic return values?

bool vfio_iommu_group_is_noiommu(struct iommu_group *group)
{
return iommu_group_get_iommudata(group) == &noiommu;
}

>  drivers/vfio/pci/vfio_pci.c  | 2 +-
>  drivers/vfio/platform/vfio_platform_common.c | 2 +-
>  drivers/vfio/vfio.c  | 5 -
>  Documentation/vfio.txt   | 4 +++-
>  4 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 712a849..d622a41 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -1119,7 +1119,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>   spin_lock_init(&vdev->irqlock);
>  
>   ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
> - if (ret) {
> + if (ret < 0) {
>   vfio_iommu_group_put(group, &pdev->dev);
>   kfree(vdev);
>   return ret;
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index e65b142..bf74e21 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -568,7 +568,7 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>   }
>  
>   ret = vfio_add_group_dev(dev, &vfio_platform_ops, vdev);
> - if (ret) {
> + if (ret < 0) {
>   iommu_group_put(group);
>   return ret;
>   }
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 6fd6fa5..67db231 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -756,6 +756,7 @@ int vfio_add_group_dev(struct device *dev,
>   struct iommu_group *iommu_group;
>   struct vfio_group *group;
>   struct vfio_device *device;
> + int noiommu;
>  
>   iommu_group = iommu_group_get(dev);
>   if (!iommu_group)
> @@ -791,6 +792,8 @@ int vfio_add_group_dev(struct device *dev,
>   return PTR_ERR(device);
>   }
>  
> + noiommu = group->noiommu;
> +
>   /*
>* Drop all but the vfio_device reference.  The vfio_device holds
>* a reference to the vfio_group, which holds a reference to the
> @@ -798,7 +801,7 @@ int vfio_add_group_dev(struct device *dev,
>*/
>   vfio_group_put(group);
>  
> - return 0;
> + return noiommu;
>  }
>  EXPORT_SYMBOL_GPL(vfio_add_group_dev);
>  
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index 1dd3fdd..d76be0f 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -259,7 +259,9 @@ extern void *vfio_del_group_dev(struct device *dev);
>  
>  vfio_add_group_dev() indicates to the core to begin tracking the
>  specified iommu_group and register the specified dev as owned by
> -a VFIO bus driver.  The driver provides an ops structure for callbacks
> +a VFIO bus driver.  A negative return value indicates failure.
> +A positive return value indicates that an unsafe noiommu mode
> +is in use.  The driver provides an ops structure for callbacks
>  similar to a file operations structure:
>  
>  struct vfio_device_ops {

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

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

[H. Peter Anvin]

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel  wrote:
>On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote:
>> +#if defined(CONFIG_KASAN)
>> +static const unsigned long memory_rand_end = KASAN_SHADOW_START;
>> +#elfif defined(CONFIG_X86_ESPFIX64)
>> +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR;
>> +#elfif defined(CONFIG_EFI)
>> +static const unsigned long memory_rand_end = EFI_VA_START;
>> +#else
>> +static const unsigned long memory_rand_end = __START_KERNEL_map;
>> +#endif
>
>That #elfif is a typo, right?
>
>
>   Joerg

It should be #efif right ;)
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] ARM64: ACPI: Update documentation for latest specification version

[Al Stone]

The ACPI 6.1 specification was recently released at the end of January
2016, but the arm64 kernel documentation for the use of ACPI was written
for the 5.1 version of the spec.  There were significant additions to the
spec that had not yet been mentioned -- for example, the 6.0 mechanisms
added to make it easier to define processors and low power idle states,
as well as the 6.1 addition allowing regular interrupts (not just from
GPIO) be used to signal ACPI general purpose events.

This patch reflects going back through and examining the specs in detail
and updating content appropriately.  Whilst there, a few odds and ends of
typos were caught as well.  This brings the documentation up to date with
ACPI 6.1 for arm64.

Changes for v4:
   -- Clarify that IORT can sometimes be optional (Jon Masters).
   -- Remove "Use as needed" descriptions of ACPI objects; they provide
  no substantive information and doing so simplifies maintenance of
  this document over time.  These have been replaced with a simpler
  notice that states that unless otherwise noted, do what the APCI
  specification says is needed.
   -- Corrected the _OSI object usage recommendation; it described kernel
  behavior that does not exist (Al Stone).

Changes for v3:
   -- Clarify use of _LPI/_RDI (Vikas Sajjan)
   -- Whitespace cleanup as pointed out by checkpatch

Changes for v2:
   -- Clean up white space (Harb Abdulhahmid)
   -- Clarification on _CCA usage (Harb Abdulhamid)
   -- IORT moved to required from recommended (Hanjun Guo)
   -- Clarify IORT description (Hanjun Guo)

Signed-off-by: Al Stone 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Jonathan Corbet 
---
 Documentation/arm64/acpi_object_usage.txt | 347 --
 Documentation/arm64/arm-acpi.txt  |  28 ++-
 2 files changed, 212 insertions(+), 163 deletions(-)

diff --git a/Documentation/arm64/acpi_object_usage.txt 
b/Documentation/arm64/acpi_object_usage.txt
index a6e1a18..3891750 100644
--- a/Documentation/arm64/acpi_object_usage.txt
+++ b/Documentation/arm64/acpi_object_usage.txt
@@ -13,14 +13,18 @@ For ACPI on arm64, tables also fall into the following 
categories:
 
-- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
 
-   -- Recommended: BERT, EINJ, ERST, HEST, SSDT
+   -- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
 
-   -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
-  MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
+   -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI,
+  MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA,
+  TPM2, UEFI, XENV
 
-   -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
-  LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+   -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
+  MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
 
+   -- NB: the IORT is required on certain SBSA platforms (e.g., when
+  using GICv3-ITS and an SMMU); it is optional on SBSA Level 0
+ platforms.
 
 Table  Usage for ARMv8 Linux
 -  
@@ -50,7 +54,8 @@ CSRT   Signature Reserved (signature == "CSRT")
 
 DBG2   Signature Reserved (signature == "DBG2")
== DeBuG port table 2 ==
-   Microsoft only table, will not be supported.
+   License has changed and should be usable.  Optional if used instead
+   of earlycon= on the command line.
 
 DBGP   Signature Reserved (signature == "DBGP")
== DeBuG Port table ==
@@ -133,10 +138,11 @@ GTDT   Section 5.2.24 (signature == "GTDT")
 
 HEST   Section 18.3.2 (signature == "HEST")
== Hardware Error Source Table ==
-   Until further error source types are defined, use only types 6 (AER
-   Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
-   Error Source).  Firmware first error handling is possible if and only
-   if Trusted Firmware is being used on arm64.
+   ARM-specific error sources have been defined; please use those or the
+   PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
+   Bridge), or use type 9 (Generic Hardware Error Source).  Firmware first
+   error handling is possible if and only if Trusted Firmware is being
+   used on arm64.
 
Must be supplied if RAS support is provided by the platform.  It
is recommended this table be supplied.
@@ -149,20 +155,30 @@ IBFT   Signature Reserved (signature == "IBFT")
== iSCSI Boot Firmware Table ==
Microsoft defined table, support TBD.
 
+IORT   Signature Reserved (signature == "IORT")
+   == Input Output Remapping Table ==
+   arm64 only table, required in order to describe IO topology, SMMUs,
+   and GIC ITSs, and how those various components are connected together,
+   such as identifying which components are behind which SMM

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

[Borislav Petkov]

On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote:
> We're still getting the single bit correction

By that you mean, you get that by enabling ECC on the FIFO block?

> which makes the entire system more stable and the ability to see both
> single bit errors corrected and the number of uncorrectable errors is
> useful from a system point of view.

If so, that makes sense, yes.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply. Srsly.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

[Borislav Petkov]

On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote:
> >  the number of uncorrectable errors is useful from a system point of
> > view.

I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want
to do that even for UEs coming from the network...?

Seems a bit overboard to me...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply. Srsly.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

[Thor Thayer]

On 04/18/2016 03:02 PM, Borislav Petkov wrote:

On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote:

We're still getting the single bit correction


By that you mean, you get that by enabling ECC on the FIFO block?

Yes, you are correct. I'd still get the single bit correction by 
enabling ECC on the FIFO which is a win.



which makes the entire system more stable and the ability to see both
single bit errors corrected and the number of uncorrectable errors is
useful from a system point of view.


If so, that makes sense, yes.

Thanks.


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

Greetings!!!

[andreas122]

Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

[Thor Thayer]

On 04/18/2016 03:06 PM, Borislav Petkov wrote:

On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote:

  the number of uncorrectable errors is useful from a system point of
view.


I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want
to do that even for UEs coming from the network...?

Seems a bit overboard to me...



Yes, as currently submitted, it is overboard and I'll fix this in the 
next patch submission. In the uncorrectable error case, I plan to just 
count the error. I'll add a constant flag in the Ethernet module's 
edac_device_prv_data to determine if the panic should be bypassed.

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

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

On 2016-04-18 17:11, Mark Brown wrote:
> On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote:
>> Mark Brown wrote:
> 
>>>
>>> There aren't any (beyond the usual references to the Wolfson datasheets
>>> which I'd suggest should be in here) but that doesn't mean we should
>>> ignore this spec when we have it.
> 
>> This is exactly the problem. For an outsider, it's impossible to know that
>> wolfson has the correct definition of the modes. Why should wolfson 
>> datasheets
>> trumph nxp or ti datasheets (or whatever), if there is an inconsistency?
> 
> I'm not quite sure what your concern is here?  I'm saying that where
> there are specs we should link to them.  I'm not saying we can't add
> to that.

I'm just saying that I don't know which specs to trust.

E.g. a random wolfson datasheet (wm8778) says that DSP mode B will have BCLK and
LRC like this when it is clk master

 .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
   .---.   .---.
---'   '---'   '-

and that it will accept the negative LRC flank later when it is clk slave,
with a figure showing this as the extreme:

 .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
---.   .---.   .-
   '---'   '---'

Then we have the tfa9879 datasheet from nxp which has this for its long sync
format:

-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-
 '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-'
-. .-. .-
 '-' '-'

This is all very difficult to match up for someone who doesn't work with this
on a day-to-day basis and know it by heart. Why should I go to some random
wolfson datasheet for info?

I don't know if the nxp long sync format is compatible with DSP mode B with
inverted BCLK, but it certainly looks like it might be. The LRC is low for
only half a cycle and that is not acceptable according to the wolfson
datasheet, but is that a limitation in wm8778 or is the tfa9879 problematic?
How would you suppose I figure out if the tfa9879 driver should declare
compatibility with DSP mode B with inverted BCLK if there is no documentation
of what *ASoC* thinks that DSP mode B really is?

This info is desperately missing, that is all that I'm saying.

With this background, I'm a bit reluctant to add links to some datasheet,
because they tend to describe how the chip in question behaves, and not the
protocol as such. But sure, the I2S spec is something else as it's independent
from any particular chip.

BTW, I found out that I had misunderstood DSP mode A in v1/v2 of the patch, so
a v3 is coming up where I'll also add a link to the I2S spec. If there is any
particular link that you think I should add for any other format spec, please
holler.

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

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

[David Rientjes]

On Thu, 7 Apr 2016, Vitaly Kuznetsov wrote:

> >> > This patchset continues the work I started with:
> >> > 
> >> > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
> >> > Author: Vitaly Kuznetsov 
> >> > Date:   Tue Mar 15 14:56:48 2016 -0700
> >> > 
> >> > memory-hotplug: add automatic onlining policy for the newly added 
> >> > memory
> >> > 
> >> > Initially I was going to stop there and bring the policy setting logic to
> >> > userspace. I met two issues on this way:
> >> > 
> >> > 1) It is possible to have memory hotplugged at boot (e.g. with QEMU). 
> >> > These
> >> >blocks stay offlined if we turn the onlining policy on by userspace.
> >> > 
> >> > 2) My attempt to bring this policy setting to systemd failed, systemd
> >> >maintainers suggest to change the default in kernel or ... to use 
> >> > tmpfiles.d
> >> >to alter the policy (which looks like a hack to me): 
> >> >https://github.com/systemd/systemd/pull/2938
> >> 
> >> That discussion really didn't come to a conclusion and I don't
> >> understand why you consider Lennert's "recommended way" to be a hack?
> >> 
> >> > Here I suggest to add a config option to set the default value for the 
> >> > policy
> >> > and a kernel command line parameter to make the override.
> >> 
> >> But the patchset looks pretty reasonable regardless of the above.
> >> 
> >
> > I don't understand why initscripts simply cannot crawl sysfs memory blocks 
> > and online them for the same behavior.
> 
> Yes, they can. With this patchset I don't bring any new features, it's
> rather a convenience so linux distros can make memory hotplug work
> 'out of the box' without such distro-specific initscripts. Memory
> hotplug is a standard feature of all major virt technologies so I think
> it's pretty reasonable to have an option to make it work 'by default'
> available.
> 

I'd personally disagree that we need more and more config options to take 
care of something that an initscript can easily do and most distros 
already have their own initscripts that this can be added to.  I don't see 
anything that the config option adds.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re[2]: [PATCH] documentation: trivial typo: adding-syscalls.txt: s/statat/fstatat/

[Askar Safin]

>Applied to the docs tree, thanks.
Thanks. Also, MAINTAINERS gives git://git.lwn.net/linux.git as repo for 
documentation. But when I try to clone it, I see "remote: fatal: Out of memory, 
realloc failed" error. Even if I have 64 G of memory. So, it seems there is 
some error on the remote side.

root@linuxp2:~# eatmydata git clone git://git.lwn.net/linux.git
Cloning into 'linux'...
remote: fatal: Out of memory, realloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
root@linuxp2:~# free -h
 total   used   free sharedbuffers cached
Mem:   63G   959M62G   8.3M34M   683M
-/+ buffers/cache:   241M62G
Swap:   0B 0B 0B