Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote:
> You can't. If the iommu is on, everything is remapped. Or do you mean
> to have dma_map_* not do a remapping ?

Well, yes, you'd have to change the code so that iomem pages do not get
remapped and the raw BAR address is passed to the DMA engine. I said
specifically we haven't done this at this time but it really doesn't
seem like an unsolvable problem. It is something we will need to address
before a proper patch set is posted though.

> That's the problem again, same as before, for that to work, the
> dma_map_* ops would have to do something special that depends on *both*
> the source and target device.

No, I don't think you have to do things different based on the source.
Have the p2pmem device layer restrict allocating p2pmem based on the
devices in use (similar to how the RFC code works now) and when the dma
mapping code sees iomem pages it just needs to leave the address alone
so it's used directly by the dma in question.

It's much better to make the decision on which memory to use when you
allocate it. If you wait until you map it, it would be a pain to fall
back to system memory if it doesn't look like it will work. So, if when
you allocate it, you know everything will work you just need the dma
mapping layer to stay out of the way.

> The dma_ops today are architecture specific and have no way to
> differenciate between normal and those special P2P DMA pages.

Correct, unless Dan's idea works (which will need some investigation),
we'd need a flag in struct page or some other similar method to
determine that these are special iomem pages.

>> Though if it does, I'd expect
>> everything would still work you just wouldn't get the performance or
>> traffic flow you are looking for. We've been testing with the software
>> iommu which doesn't have this problem.
> 
> So first, no, it's more than "you wouldn't get the performance". On
> some systems it may also just not work. Also what do you mean by "the
> SW iommu doesn't have this problem" ? It catches the fact that
> addresses don't point to RAM and maps differently ?

I haven't tested it but I can't imagine why an iommu would not correctly
map the memory in the bar. But that's _way_ beside the point. We
_really_ want to avoid that situation anyway. If the iommu maps the
memory it defeats what we are trying to accomplish.

I believe the sotfware iommu only uses bounce buffers if the DMA engine
in use cannot address the memory. So in most cases, with modern
hardware, it just passes the BAR's address to the DMA engine and
everything works. The code posted in the RFC does in fact work without
needing to do any of this fussing.

>>> The problem is that the latter while seemingly easier, is also slower
>>> and not supported by all platforms and architectures (for example,
>>> POWER currently won't allow it, or rather only allows a store-only
>>> subset of it under special circumstances).
>>
>> Yes, I think situations where we have to cross host bridges will remain
>> unsupported by this work for a long time. There are two many cases where
>> it just doesn't work or it performs too poorly to be useful.
> 
> And the situation where you don't cross bridges is the one where you
> need to also take into account the offsets.

I think for the first incarnation we will just not support systems that
have offsets. This makes things much easier and still supports all the
use cases we are interested in.

> So you are designing something that is built from scratch to only work
> on a specific limited category of systems and is also incompatible with
> virtualization.

Yes, we are starting with support for specific use cases. Almost all
technology starts that way. Dax has been in the kernel for years and
only recently has someone submitted patches for it to support pmem on
powerpc. This is not unusual. If you had forced the pmem developers to
support all architectures in existence before allowing them upstream
they couldn't possibly be as far as they are today.

Virtualization specifically would be a _lot_ more difficult than simply
supporting offsets. The actual topology of the bus will probably be lost
on the guest OS and it would therefor have a difficult time figuring out
when it's acceptable to use p2pmem. I also have a difficult time seeing
a use case for it and thus I have a hard time with the argument that we
can't support use cases that do want it because use cases that don't
want it (perhaps yet) won't work.

> This is an interesting experiement to look at I suppose, but if you
> ever want this upstream I would like at least for you to develop a
> strategy to support the wider case, if not an actual implementation.

I think there are plenty of avenues forward to support offsets, etc.
It's just work. Nothing we'd be proposing would be incompatible with it.
We just don't want to have to do it all upfront especially when no one
really knows how well various architecture's hardware supports this or
if 

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote:
> You can't. If the iommu is on, everything is remapped. Or do you mean
> to have dma_map_* not do a remapping ?

Well, yes, you'd have to change the code so that iomem pages do not get
remapped and the raw BAR address is passed to the DMA engine. I said
specifically we haven't done this at this time but it really doesn't
seem like an unsolvable problem. It is something we will need to address
before a proper patch set is posted though.

> That's the problem again, same as before, for that to work, the
> dma_map_* ops would have to do something special that depends on *both*
> the source and target device.

No, I don't think you have to do things different based on the source.
Have the p2pmem device layer restrict allocating p2pmem based on the
devices in use (similar to how the RFC code works now) and when the dma
mapping code sees iomem pages it just needs to leave the address alone
so it's used directly by the dma in question.

It's much better to make the decision on which memory to use when you
allocate it. If you wait until you map it, it would be a pain to fall
back to system memory if it doesn't look like it will work. So, if when
you allocate it, you know everything will work you just need the dma
mapping layer to stay out of the way.

> The dma_ops today are architecture specific and have no way to
> differenciate between normal and those special P2P DMA pages.

Correct, unless Dan's idea works (which will need some investigation),
we'd need a flag in struct page or some other similar method to
determine that these are special iomem pages.

>> Though if it does, I'd expect
>> everything would still work you just wouldn't get the performance or
>> traffic flow you are looking for. We've been testing with the software
>> iommu which doesn't have this problem.
> 
> So first, no, it's more than "you wouldn't get the performance". On
> some systems it may also just not work. Also what do you mean by "the
> SW iommu doesn't have this problem" ? It catches the fact that
> addresses don't point to RAM and maps differently ?

I haven't tested it but I can't imagine why an iommu would not correctly
map the memory in the bar. But that's _way_ beside the point. We
_really_ want to avoid that situation anyway. If the iommu maps the
memory it defeats what we are trying to accomplish.

I believe the sotfware iommu only uses bounce buffers if the DMA engine
in use cannot address the memory. So in most cases, with modern
hardware, it just passes the BAR's address to the DMA engine and
everything works. The code posted in the RFC does in fact work without
needing to do any of this fussing.

>>> The problem is that the latter while seemingly easier, is also slower
>>> and not supported by all platforms and architectures (for example,
>>> POWER currently won't allow it, or rather only allows a store-only
>>> subset of it under special circumstances).
>>
>> Yes, I think situations where we have to cross host bridges will remain
>> unsupported by this work for a long time. There are two many cases where
>> it just doesn't work or it performs too poorly to be useful.
> 
> And the situation where you don't cross bridges is the one where you
> need to also take into account the offsets.

I think for the first incarnation we will just not support systems that
have offsets. This makes things much easier and still supports all the
use cases we are interested in.

> So you are designing something that is built from scratch to only work
> on a specific limited category of systems and is also incompatible with
> virtualization.

Yes, we are starting with support for specific use cases. Almost all
technology starts that way. Dax has been in the kernel for years and
only recently has someone submitted patches for it to support pmem on
powerpc. This is not unusual. If you had forced the pmem developers to
support all architectures in existence before allowing them upstream
they couldn't possibly be as far as they are today.

Virtualization specifically would be a _lot_ more difficult than simply
supporting offsets. The actual topology of the bus will probably be lost
on the guest OS and it would therefor have a difficult time figuring out
when it's acceptable to use p2pmem. I also have a difficult time seeing
a use case for it and thus I have a hard time with the argument that we
can't support use cases that do want it because use cases that don't
want it (perhaps yet) won't work.

> This is an interesting experiement to look at I suppose, but if you
> ever want this upstream I would like at least for you to develop a
> strategy to support the wider case, if not an actual implementation.

I think there are plenty of avenues forward to support offsets, etc.
It's just work. Nothing we'd be proposing would be incompatible with it.
We just don't want to have to do it all upfront especially when no one
really knows how well various architecture's hardware supports this or
if 

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Stefan Agner]

On 2017-04-15 18:12, Axel Lin wrote:
> 2017-04-16 0:53 GMT+08:00 Stefan Agner :
>> On 2017-04-15 07:52, Axel Lin wrote:
>>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>>> So for rn5t618, there is out of bounds array access when checking
>>> regulators[i].name in the for loop.
>>
>> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
>> that the non initialized elements are zero. The highest element LDORTC2
>> is defined, hence the length of the array should be RN5T618_REG_NUM.
> 
> ok, I missed that. Then current code is fine.
> Though the meaing of RN5T618_REG_NUM seems misleading to me as different
> variant has differnt number of regulators.

Yeah I admit the code is somewhat unobvious as it is now. But it allowed
me to add RN5T567 support without changing the existing array and the
preprocessor macro.

--
Stefan

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Stefan Agner]

On 2017-04-15 18:12, Axel Lin wrote:
> 2017-04-16 0:53 GMT+08:00 Stefan Agner :
>> On 2017-04-15 07:52, Axel Lin wrote:
>>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>>> So for rn5t618, there is out of bounds array access when checking
>>> regulators[i].name in the for loop.
>>
>> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
>> that the non initialized elements are zero. The highest element LDORTC2
>> is defined, hence the length of the array should be RN5T618_REG_NUM.
> 
> ok, I missed that. Then current code is fine.
> Though the meaing of RN5T618_REG_NUM seems misleading to me as different
> variant has differnt number of regulators.

Yeah I admit the code is somewhat unobvious as it is now. But it allowed
me to add RN5T567 support without changing the existing array and the
preprocessor macro.

--
Stefan

[PATCH 2/8] Input: rotary-encoder - remove references to platform data from docs

[Dmitry Torokhov]

The driver has been converted to use generic device properties, so
stop referring to platform data.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/rotary-encoder.rst | 85 ++
 1 file changed, 44 insertions(+), 41 deletions(-)

diff --git a/Documentation/input/rotary-encoder.rst 
b/Documentation/input/rotary-encoder.rst
index 4695bea67f9b..b07b20a295ac 100644
--- a/Documentation/input/rotary-encoder.rst
+++ b/Documentation/input/rotary-encoder.rst
@@ -81,48 +81,51 @@ Board integration
 
 To use this driver in your system, register a platform_device with the
 name 'rotary-encoder' and associate the IRQs and some specific platform
-data with it.
+data with it. Because the driver uses generic device properties, this can
+be done either via device tree, ACPI, or using static board files, like in
+example below:
 
-struct rotary_encoder_platform_data is declared in
-include/linux/rotary-encoder.h and needs to be filled with the number of
-steps the encoder has and can carry information about externally inverted
-signals (because of an inverting buffer or other reasons). The encoder
-can be set up to deliver input information as either an absolute or relative
-axes. For relative axes the input event returns +/-1 for each step. For
-absolute axes the position of the encoder can either roll over between zero
-and the number of steps or will clamp at the maximum and zero depending on
-the configuration.
+::
 
-Because GPIO to IRQ mapping is platform specific, this information must
-be given in separately to the driver. See the example below.
+   /* board support file example */
 
-::
+   #include 
+   #include 
+   #include 
+
+   #define GPIO_ROTARY_A 1
+   #define GPIO_ROTARY_B 2
+
+   static struct gpiod_lookup_table rotary_encoder_gpios = {
+   .dev_id = "rotary-encoder.0",
+   .table = {
+   GPIO_LOOKUP_IDX("gpio-0",
+   GPIO_ROTARY_A, NULL, 0, 
GPIO_ACTIVE_LOW),
+   GPIO_LOOKUP_IDX("gpio-0",
+   GPIO_ROTARY_B, NULL, 1, 
GPIO_ACTIVE_HIGH),
+   { },
+   },
+   };
+
+   static const struct property_entry rotary_encoder_properties[] 
__initconst = {
+   PROPERTY_ENTRY_INTEGER("rotary-encoder,steps-per-period", u32, 
24),
+   PROPERTY_ENTRY_INTEGER("linux,axis",  u32, 
ABS_X),
+   PROPERTY_ENTRY_INTEGER("rotary-encoder,relative_axis",u32, 
0),
+   { },
+   };
+
+   static struct platform_device rotary_encoder_device = {
+   .name   = "rotary-encoder",
+   .id = 0,
+   };
+
+   ...
+
+   gpiod_add_lookup_table(_encoder_gpios);
+   device_add_properties(_encoder_device, 
rotary_encoder_properties);
+   platform_device_register(_encoder_device);
+
+   ...
 
-/* board support file example */
-
-#include 
-#include 
-
-#define GPIO_ROTARY_A 1
-#define GPIO_ROTARY_B 2
-
-static struct rotary_encoder_platform_data my_rotary_encoder_info = {
-   .steps  = 24,
-   .axis   = ABS_X,
-   .relative_axis  = false,
-   .rollover   = false,
-   .gpio_a = GPIO_ROTARY_A,
-   .gpio_b = GPIO_ROTARY_B,
-   .inverted_a = 0,
-   .inverted_b = 0,
-   .half_period= false,
-   .wakeup_source  = false,
-};
-
-static struct platform_device rotary_encoder_device = {
-   .name   = "rotary-encoder",
-   .id = 0,
-   .dev= {
-   .platform_data = _rotary_encoder_info,
-   }
-};
+Please consult device tree binding documentation to see all properties
+supported by the driver.
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 3/8] Input: fix "Game console" heading level in joystick documentation

[Dmitry Torokhov]

The heading level should be the same as for other devices.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/joystick.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/input/joystick.rst b/Documentation/input/joystick.rst
index 202f5a090675..c9c175ffc2ff 100644
--- a/Documentation/input/joystick.rst
+++ b/Documentation/input/joystick.rst
@@ -465,7 +465,7 @@ No more joystick types are supported now, but that should 
change in the
 future if I get an Amiga in the reach of my fingers.
 
 Game console and 8-bit pads and joysticks
-~
+-
 
 See :ref:`joystick-parport` for more info.
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 2/8] Input: rotary-encoder - remove references to platform data from docs

[Dmitry Torokhov]

The driver has been converted to use generic device properties, so
stop referring to platform data.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/rotary-encoder.rst | 85 ++
 1 file changed, 44 insertions(+), 41 deletions(-)

diff --git a/Documentation/input/rotary-encoder.rst 
b/Documentation/input/rotary-encoder.rst
index 4695bea67f9b..b07b20a295ac 100644
--- a/Documentation/input/rotary-encoder.rst
+++ b/Documentation/input/rotary-encoder.rst
@@ -81,48 +81,51 @@ Board integration
 
 To use this driver in your system, register a platform_device with the
 name 'rotary-encoder' and associate the IRQs and some specific platform
-data with it.
+data with it. Because the driver uses generic device properties, this can
+be done either via device tree, ACPI, or using static board files, like in
+example below:
 
-struct rotary_encoder_platform_data is declared in
-include/linux/rotary-encoder.h and needs to be filled with the number of
-steps the encoder has and can carry information about externally inverted
-signals (because of an inverting buffer or other reasons). The encoder
-can be set up to deliver input information as either an absolute or relative
-axes. For relative axes the input event returns +/-1 for each step. For
-absolute axes the position of the encoder can either roll over between zero
-and the number of steps or will clamp at the maximum and zero depending on
-the configuration.
+::
 
-Because GPIO to IRQ mapping is platform specific, this information must
-be given in separately to the driver. See the example below.
+   /* board support file example */
 
-::
+   #include 
+   #include 
+   #include 
+
+   #define GPIO_ROTARY_A 1
+   #define GPIO_ROTARY_B 2
+
+   static struct gpiod_lookup_table rotary_encoder_gpios = {
+   .dev_id = "rotary-encoder.0",
+   .table = {
+   GPIO_LOOKUP_IDX("gpio-0",
+   GPIO_ROTARY_A, NULL, 0, 
GPIO_ACTIVE_LOW),
+   GPIO_LOOKUP_IDX("gpio-0",
+   GPIO_ROTARY_B, NULL, 1, 
GPIO_ACTIVE_HIGH),
+   { },
+   },
+   };
+
+   static const struct property_entry rotary_encoder_properties[] 
__initconst = {
+   PROPERTY_ENTRY_INTEGER("rotary-encoder,steps-per-period", u32, 
24),
+   PROPERTY_ENTRY_INTEGER("linux,axis",  u32, 
ABS_X),
+   PROPERTY_ENTRY_INTEGER("rotary-encoder,relative_axis",u32, 
0),
+   { },
+   };
+
+   static struct platform_device rotary_encoder_device = {
+   .name   = "rotary-encoder",
+   .id = 0,
+   };
+
+   ...
+
+   gpiod_add_lookup_table(_encoder_gpios);
+   device_add_properties(_encoder_device, 
rotary_encoder_properties);
+   platform_device_register(_encoder_device);
+
+   ...
 
-/* board support file example */
-
-#include 
-#include 
-
-#define GPIO_ROTARY_A 1
-#define GPIO_ROTARY_B 2
-
-static struct rotary_encoder_platform_data my_rotary_encoder_info = {
-   .steps  = 24,
-   .axis   = ABS_X,
-   .relative_axis  = false,
-   .rollover   = false,
-   .gpio_a = GPIO_ROTARY_A,
-   .gpio_b = GPIO_ROTARY_B,
-   .inverted_a = 0,
-   .inverted_b = 0,
-   .half_period= false,
-   .wakeup_source  = false,
-};
-
-static struct platform_device rotary_encoder_device = {
-   .name   = "rotary-encoder",
-   .id = 0,
-   .dev= {
-   .platform_data = _rotary_encoder_info,
-   }
-};
+Please consult device tree binding documentation to see all properties
+supported by the driver.
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 3/8] Input: fix "Game console" heading level in joystick documentation

[Dmitry Torokhov]

The heading level should be the same as for other devices.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/joystick.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/input/joystick.rst b/Documentation/input/joystick.rst
index 202f5a090675..c9c175ffc2ff 100644
--- a/Documentation/input/joystick.rst
+++ b/Documentation/input/joystick.rst
@@ -465,7 +465,7 @@ No more joystick types are supported now, but that should 
change in the
 future if I get an Amiga in the reach of my fingers.
 
 Game console and 8-bit pads and joysticks
-~
+-
 
 See :ref:`joystick-parport` for more info.
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 6/8] Input: docs - note that MT-A protocol is obsolete

[Dmitry Torokhov]

Everyone should be using multitouch protocol B (slotted) now.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/multi-touch-protocol.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/input/multi-touch-protocol.rst 
b/Documentation/input/multi-touch-protocol.rst
index 81775d7c1997..8035868c56bc 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -22,6 +22,9 @@ describes how to send the raw data for all contacts to the 
receiver. For
 devices capable of tracking identifiable contacts (type B), the protocol
 describes how to send updates for individual contacts via event slots.
 
+.. note::
+   MT potocol type A is obsolete, all kernel drivers have been
+   converted to use type B.
 
 Protocol Usage
 --
@@ -400,9 +403,6 @@ in a finger packet must not be recognized as single-touch 
events.
 For type A devices, all finger data bypasses input filtering, since
 subsequent events of the same type refer to different fingers.
 
-For example usage of the type A protocol, see the bcm5974 driver. For
-example usage of the type B protocol, see the hid-egalax driver.
-
 .. [#f1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt.
 .. [#f2] The list can of course be extended.
 .. [#f3] The mtdev project: http://bitmath.org/code/mtdev/.
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 6/8] Input: docs - note that MT-A protocol is obsolete

[Dmitry Torokhov]

Everyone should be using multitouch protocol B (slotted) now.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/multi-touch-protocol.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/input/multi-touch-protocol.rst 
b/Documentation/input/multi-touch-protocol.rst
index 81775d7c1997..8035868c56bc 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -22,6 +22,9 @@ describes how to send the raw data for all contacts to the 
receiver. For
 devices capable of tracking identifiable contacts (type B), the protocol
 describes how to send updates for individual contacts via event slots.
 
+.. note::
+   MT potocol type A is obsolete, all kernel drivers have been
+   converted to use type B.
 
 Protocol Usage
 --
@@ -400,9 +403,6 @@ in a finger packet must not be recognized as single-touch 
events.
 For type A devices, all finger data bypasses input filtering, since
 subsequent events of the same type refer to different fingers.
 
-For example usage of the type A protocol, see the bcm5974 driver. For
-example usage of the type B protocol, see the hid-egalax driver.
-
 .. [#f1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt.
 .. [#f2] The list can of course be extended.
 .. [#f3] The mtdev project: http://bitmath.org/code/mtdev/.
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 7/8] Input: docs - split input docs into kernel- and user-facing

[Dmitry Torokhov]

Split input documentation into several groups: kernel- and user-facing, and
notes about individual device drivers. Move device drivers docs into a
separate subdirectory.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/{ => devices}/alps.rst |  2 +-
 Documentation/input/{ => devices}/amijoy.rst   |  0
 Documentation/input/{ => devices}/appletouch.rst   |  0
 Documentation/input/{ => devices}/atarikbd.rst |  0
 Documentation/input/{ => devices}/bcm5974.rst  |  0
 Documentation/input/{ => devices}/cma3000_d0x.rst  |  4 +-
 Documentation/input/{ => devices}/cs461x.rst   |  8 +---
 Documentation/input/{ => devices}/edt-ft5x06.rst   |  0
 Documentation/input/{ => devices}/elantech.rst |  0
 Documentation/input/{ => devices}/gpio-tilt.rst|  8 ++--
 .../input/{ => devices}/iforce-protocol.rst|  0
 Documentation/input/devices/index.rst  | 19 +
 .../input/{ => devices}/joystick-parport.rst   |  2 +-
 Documentation/input/{ => devices}/ntrig.rst|  0
 .../input/{ => devices}/rotary-encoder.rst |  0
 Documentation/input/{ => devices}/sentelic.rst | 10 ++---
 Documentation/input/{ => devices}/walkera0701.rst  |  0
 Documentation/input/{ => devices}/xpad.rst | 22 +-
 Documentation/input/{ => devices}/yealink.rst  | 47 --
 Documentation/input/gamepad.rst| 10 ++---
 Documentation/input/index.rst  | 39 ++
 Documentation/input/input-programming.rst  |  5 +--
 Documentation/input/input_kapi.rst | 17 
 Documentation/input/input_uapi.rst | 21 ++
 24 files changed, 107 insertions(+), 107 deletions(-)
 rename Documentation/input/{ => devices}/alps.rst (99%)
 rename Documentation/input/{ => devices}/amijoy.rst (100%)
 rename Documentation/input/{ => devices}/appletouch.rst (100%)
 rename Documentation/input/{ => devices}/atarikbd.rst (100%)
 rename Documentation/input/{ => devices}/bcm5974.rst (100%)
 rename Documentation/input/{ => devices}/cma3000_d0x.rst (97%)
 rename Documentation/input/{ => devices}/cs461x.rst (88%)
 rename Documentation/input/{ => devices}/edt-ft5x06.rst (100%)
 rename Documentation/input/{ => devices}/elantech.rst (100%)
 rename Documentation/input/{ => devices}/gpio-tilt.rst (98%)
 rename Documentation/input/{ => devices}/iforce-protocol.rst (100%)
 create mode 100644 Documentation/input/devices/index.rst
 rename Documentation/input/{ => devices}/joystick-parport.rst (99%)
 rename Documentation/input/{ => devices}/ntrig.rst (100%)
 rename Documentation/input/{ => devices}/rotary-encoder.rst (100%)
 rename Documentation/input/{ => devices}/sentelic.rst (99%)
 rename Documentation/input/{ => devices}/walkera0701.rst (100%)
 rename Documentation/input/{ => devices}/xpad.rst (95%)
 rename Documentation/input/{ => devices}/yealink.rst (94%)
 create mode 100644 Documentation/input/input_kapi.rst
 create mode 100644 Documentation/input/input_uapi.rst

diff --git a/Documentation/input/alps.rst b/Documentation/input/devices/alps.rst
similarity index 99%
rename from Documentation/input/alps.rst
rename to Documentation/input/devices/alps.rst
index 76a71a146e50..6779148e428c 100644
--- a/Documentation/input/alps.rst
+++ b/Documentation/input/devices/alps.rst
@@ -5,7 +5,7 @@ ALPS Touchpad Protocol
 Introduction
 
 Currently the ALPS touchpad driver supports seven protocol versions in use by
-ALPS touchpads, called versions 1, 2, 3, 4, 5, 6 and 7.
+ALPS touchpads, called versions 1, 2, 3, 4, 5, 6, 7 and 8.
 
 Since roughly mid-2010 several new ALPS touchpads have been released and
 integrated into a variety of laptops and netbooks.  These new touchpads
diff --git a/Documentation/input/amijoy.rst 
b/Documentation/input/devices/amijoy.rst
similarity index 100%
rename from Documentation/input/amijoy.rst
rename to Documentation/input/devices/amijoy.rst
diff --git a/Documentation/input/appletouch.rst 
b/Documentation/input/devices/appletouch.rst
similarity index 100%
rename from Documentation/input/appletouch.rst
rename to Documentation/input/devices/appletouch.rst
diff --git a/Documentation/input/atarikbd.rst 
b/Documentation/input/devices/atarikbd.rst
similarity index 100%
rename from Documentation/input/atarikbd.rst
rename to Documentation/input/devices/atarikbd.rst
diff --git a/Documentation/input/bcm5974.rst 
b/Documentation/input/devices/bcm5974.rst
similarity index 100%
rename from Documentation/input/bcm5974.rst
rename to Documentation/input/devices/bcm5974.rst
diff --git a/Documentation/input/cma3000_d0x.rst 
b/Documentation/input/devices/cma3000_d0x.rst
similarity index 97%
rename from Documentation/input/cma3000_d0x.rst
rename to Documentation/input/devices/cma3000_d0x.rst
index 6f40c17c1aca..8bc8e61487b0 100644
--- a/Documentation/input/cma3000_d0x.rst
+++ b/Documentation/input/devices/cma3000_d0x.rst
@@ -1,5 +1,5 @@
-Kernel driver 

[PATCH 8/8] Input: docs - freshen up introduction

[Dmitry Torokhov]

Stop saying that API is experimental and that only USB is supported,
acknowledge that evdev is the preferred interface, and remove paragraph
encouraging people sending snail mail to Vojtech :) along with his email.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/event-codes.rst |   2 +
 Documentation/input/input.rst   | 253 +---
 Documentation/input/joydev/joystick-api.rst |   2 +
 Documentation/input/joydev/joystick.rst |   2 +
 4 files changed, 127 insertions(+), 132 deletions(-)

diff --git a/Documentation/input/event-codes.rst 
b/Documentation/input/event-codes.rst
index 92db50954169..00b88f113bda 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -1,3 +1,5 @@
+.. _input-event-codes:
+
 =
 Input event codes
 =
diff --git a/Documentation/input/input.rst b/Documentation/input/input.rst
index ac7669ad3e76..3b3a22975106 100644
--- a/Documentation/input/input.rst
+++ b/Documentation/input/input.rst
@@ -1,25 +1,20 @@
 .. include:: 
 
-===
-Linux Input drivers
-===
+
+Introduction
+
 
 :Copyright: |copy| 1999-2001 Vojtech Pavlik  - Sponsored by 
SuSE
 
-Should you need to contact me, the author, you can do so either by e-mail
-- mail your message to , or by paper mail: Vojtech Pavlik,
-Simunkova 1594, Prague 8, 182 00 Czech Republic
-
-Introduction
+Architecture
 
 
-This is a collection of drivers that is designed to support all input
-devices under Linux. While it is currently used only on for USB input
-devices, future use (say 2.5/2.6) is expected to expand to replace
-most of the existing input system, which is why it lives in
-drivers/input/ instead of drivers/usb/.
+Input subsystem  a collection of drivers that is designed to support
+all input devices under Linux. Most of the drivers reside in
+drivers/input, although quite a few live in drivers/hid and
+drivers/platform.
 
-The centre of the input drivers is the input module, which must be
+The core of the input subsystem is the input module, which must be
 loaded before any other of the input modules - it serves as a way of
 communication between two groups of modules:
 
@@ -32,9 +27,9 @@ events (keystrokes, mouse movements) to the input module.
 Event handlers
 --
 
-These modules get events from input and pass them where needed via
-various interfaces - keystrokes to the kernel, mouse movements via a
-simulated PS/2 interface to GPM and X and so on.
+These modules get events from input core and pass them where needed
+via various interfaces - keystrokes to the kernel, mouse movements via
+a simulated PS/2 interface to GPM and X, and so on.
 
 Simple Usage
 
@@ -45,19 +40,18 @@ kernel)::
 
input
mousedev
-   keybdev
usbcore
uhci_hcd or ohci_hcd or ehci_hcd
usbhid
+   hid_generic
 
 After this, the USB keyboard will work straight away, and the USB mouse
 will be available as a character device on major 13, minor 63::
 
crw-r--r--   1 root root  13,  63 Mar 28 22:45 mice
 
-This device has to be created.
-
-The commands to create it by hand are::
+This device usually created automatically by the system. The commands
+to create it by hand are::
 
cd /dev
mkdir input
@@ -81,100 +75,50 @@ When you do all of the above, you can use your USB mouse 
and keyboard.
 Detailed Description
 
 
-Device drivers
+Event handlers
 --
 
-Device drivers are the modules that generate events. The events are
-however not useful without being handled, so you also will need to use some
-of the modules from section 3.2.
-
-usbhid
-~~
-
-usbhid is the largest and most complex driver of the whole suite. It
-handles all HID devices, and because there is a very wide variety of them,
-and because the USB HID specification isn't simple, it needs to be this big.
-
-Currently, it handles USB mice, joysticks, gamepads, steering wheels
-keyboards, trackballs and digitizers.
-
-However, USB uses HID also for monitor controls, speaker controls, UPSs,
-LCDs and many other purposes.
-
-The monitor and speaker controls should be easy to add to the hid/input
-interface, but for the UPSs and LCDs it doesn't make much sense. For this,
-the hiddev interface was designed. See Documentation/hid/hiddev.txt
-for more information about it.
-
-The usage of the usbhid module is very simple, it takes no parameters,
-detects everything automatically and when a HID device is inserted, it
-detects it appropriately.
-
-However, because the devices vary wildly, you might happen to have a
-device that doesn't work well. In that case #define DEBUG at the beginning
-of hid-core.c and send me the syslog traces.
+Event handlers distribute the events from the devices to userspace and
+in-kernel consumers, as needed.
 

[PATCH 7/8] Input: docs - split input docs into kernel- and user-facing

[Dmitry Torokhov]

Split input documentation into several groups: kernel- and user-facing, and
notes about individual device drivers. Move device drivers docs into a
separate subdirectory.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/{ => devices}/alps.rst |  2 +-
 Documentation/input/{ => devices}/amijoy.rst   |  0
 Documentation/input/{ => devices}/appletouch.rst   |  0
 Documentation/input/{ => devices}/atarikbd.rst |  0
 Documentation/input/{ => devices}/bcm5974.rst  |  0
 Documentation/input/{ => devices}/cma3000_d0x.rst  |  4 +-
 Documentation/input/{ => devices}/cs461x.rst   |  8 +---
 Documentation/input/{ => devices}/edt-ft5x06.rst   |  0
 Documentation/input/{ => devices}/elantech.rst |  0
 Documentation/input/{ => devices}/gpio-tilt.rst|  8 ++--
 .../input/{ => devices}/iforce-protocol.rst|  0
 Documentation/input/devices/index.rst  | 19 +
 .../input/{ => devices}/joystick-parport.rst   |  2 +-
 Documentation/input/{ => devices}/ntrig.rst|  0
 .../input/{ => devices}/rotary-encoder.rst |  0
 Documentation/input/{ => devices}/sentelic.rst | 10 ++---
 Documentation/input/{ => devices}/walkera0701.rst  |  0
 Documentation/input/{ => devices}/xpad.rst | 22 +-
 Documentation/input/{ => devices}/yealink.rst  | 47 --
 Documentation/input/gamepad.rst| 10 ++---
 Documentation/input/index.rst  | 39 ++
 Documentation/input/input-programming.rst  |  5 +--
 Documentation/input/input_kapi.rst | 17 
 Documentation/input/input_uapi.rst | 21 ++
 24 files changed, 107 insertions(+), 107 deletions(-)
 rename Documentation/input/{ => devices}/alps.rst (99%)
 rename Documentation/input/{ => devices}/amijoy.rst (100%)
 rename Documentation/input/{ => devices}/appletouch.rst (100%)
 rename Documentation/input/{ => devices}/atarikbd.rst (100%)
 rename Documentation/input/{ => devices}/bcm5974.rst (100%)
 rename Documentation/input/{ => devices}/cma3000_d0x.rst (97%)
 rename Documentation/input/{ => devices}/cs461x.rst (88%)
 rename Documentation/input/{ => devices}/edt-ft5x06.rst (100%)
 rename Documentation/input/{ => devices}/elantech.rst (100%)
 rename Documentation/input/{ => devices}/gpio-tilt.rst (98%)
 rename Documentation/input/{ => devices}/iforce-protocol.rst (100%)
 create mode 100644 Documentation/input/devices/index.rst
 rename Documentation/input/{ => devices}/joystick-parport.rst (99%)
 rename Documentation/input/{ => devices}/ntrig.rst (100%)
 rename Documentation/input/{ => devices}/rotary-encoder.rst (100%)
 rename Documentation/input/{ => devices}/sentelic.rst (99%)
 rename Documentation/input/{ => devices}/walkera0701.rst (100%)
 rename Documentation/input/{ => devices}/xpad.rst (95%)
 rename Documentation/input/{ => devices}/yealink.rst (94%)
 create mode 100644 Documentation/input/input_kapi.rst
 create mode 100644 Documentation/input/input_uapi.rst

diff --git a/Documentation/input/alps.rst b/Documentation/input/devices/alps.rst
similarity index 99%
rename from Documentation/input/alps.rst
rename to Documentation/input/devices/alps.rst
index 76a71a146e50..6779148e428c 100644
--- a/Documentation/input/alps.rst
+++ b/Documentation/input/devices/alps.rst
@@ -5,7 +5,7 @@ ALPS Touchpad Protocol
 Introduction
 
 Currently the ALPS touchpad driver supports seven protocol versions in use by
-ALPS touchpads, called versions 1, 2, 3, 4, 5, 6 and 7.
+ALPS touchpads, called versions 1, 2, 3, 4, 5, 6, 7 and 8.
 
 Since roughly mid-2010 several new ALPS touchpads have been released and
 integrated into a variety of laptops and netbooks.  These new touchpads
diff --git a/Documentation/input/amijoy.rst 
b/Documentation/input/devices/amijoy.rst
similarity index 100%
rename from Documentation/input/amijoy.rst
rename to Documentation/input/devices/amijoy.rst
diff --git a/Documentation/input/appletouch.rst 
b/Documentation/input/devices/appletouch.rst
similarity index 100%
rename from Documentation/input/appletouch.rst
rename to Documentation/input/devices/appletouch.rst
diff --git a/Documentation/input/atarikbd.rst 
b/Documentation/input/devices/atarikbd.rst
similarity index 100%
rename from Documentation/input/atarikbd.rst
rename to Documentation/input/devices/atarikbd.rst
diff --git a/Documentation/input/bcm5974.rst 
b/Documentation/input/devices/bcm5974.rst
similarity index 100%
rename from Documentation/input/bcm5974.rst
rename to Documentation/input/devices/bcm5974.rst
diff --git a/Documentation/input/cma3000_d0x.rst 
b/Documentation/input/devices/cma3000_d0x.rst
similarity index 97%
rename from Documentation/input/cma3000_d0x.rst
rename to Documentation/input/devices/cma3000_d0x.rst
index 6f40c17c1aca..8bc8e61487b0 100644
--- a/Documentation/input/cma3000_d0x.rst
+++ b/Documentation/input/devices/cma3000_d0x.rst
@@ -1,5 +1,5 @@
-Kernel driver for CMA3000-D0x

[PATCH 8/8] Input: docs - freshen up introduction

[Dmitry Torokhov]

Stop saying that API is experimental and that only USB is supported,
acknowledge that evdev is the preferred interface, and remove paragraph
encouraging people sending snail mail to Vojtech :) along with his email.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/event-codes.rst |   2 +
 Documentation/input/input.rst   | 253 +---
 Documentation/input/joydev/joystick-api.rst |   2 +
 Documentation/input/joydev/joystick.rst |   2 +
 4 files changed, 127 insertions(+), 132 deletions(-)

diff --git a/Documentation/input/event-codes.rst 
b/Documentation/input/event-codes.rst
index 92db50954169..00b88f113bda 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -1,3 +1,5 @@
+.. _input-event-codes:
+
 =
 Input event codes
 =
diff --git a/Documentation/input/input.rst b/Documentation/input/input.rst
index ac7669ad3e76..3b3a22975106 100644
--- a/Documentation/input/input.rst
+++ b/Documentation/input/input.rst
@@ -1,25 +1,20 @@
 .. include:: 
 
-===
-Linux Input drivers
-===
+
+Introduction
+
 
 :Copyright: |copy| 1999-2001 Vojtech Pavlik  - Sponsored by 
SuSE
 
-Should you need to contact me, the author, you can do so either by e-mail
-- mail your message to , or by paper mail: Vojtech Pavlik,
-Simunkova 1594, Prague 8, 182 00 Czech Republic
-
-Introduction
+Architecture
 
 
-This is a collection of drivers that is designed to support all input
-devices under Linux. While it is currently used only on for USB input
-devices, future use (say 2.5/2.6) is expected to expand to replace
-most of the existing input system, which is why it lives in
-drivers/input/ instead of drivers/usb/.
+Input subsystem  a collection of drivers that is designed to support
+all input devices under Linux. Most of the drivers reside in
+drivers/input, although quite a few live in drivers/hid and
+drivers/platform.
 
-The centre of the input drivers is the input module, which must be
+The core of the input subsystem is the input module, which must be
 loaded before any other of the input modules - it serves as a way of
 communication between two groups of modules:
 
@@ -32,9 +27,9 @@ events (keystrokes, mouse movements) to the input module.
 Event handlers
 --
 
-These modules get events from input and pass them where needed via
-various interfaces - keystrokes to the kernel, mouse movements via a
-simulated PS/2 interface to GPM and X and so on.
+These modules get events from input core and pass them where needed
+via various interfaces - keystrokes to the kernel, mouse movements via
+a simulated PS/2 interface to GPM and X, and so on.
 
 Simple Usage
 
@@ -45,19 +40,18 @@ kernel)::
 
input
mousedev
-   keybdev
usbcore
uhci_hcd or ohci_hcd or ehci_hcd
usbhid
+   hid_generic
 
 After this, the USB keyboard will work straight away, and the USB mouse
 will be available as a character device on major 13, minor 63::
 
crw-r--r--   1 root root  13,  63 Mar 28 22:45 mice
 
-This device has to be created.
-
-The commands to create it by hand are::
+This device usually created automatically by the system. The commands
+to create it by hand are::
 
cd /dev
mkdir input
@@ -81,100 +75,50 @@ When you do all of the above, you can use your USB mouse 
and keyboard.
 Detailed Description
 
 
-Device drivers
+Event handlers
 --
 
-Device drivers are the modules that generate events. The events are
-however not useful without being handled, so you also will need to use some
-of the modules from section 3.2.
-
-usbhid
-~~
-
-usbhid is the largest and most complex driver of the whole suite. It
-handles all HID devices, and because there is a very wide variety of them,
-and because the USB HID specification isn't simple, it needs to be this big.
-
-Currently, it handles USB mice, joysticks, gamepads, steering wheels
-keyboards, trackballs and digitizers.
-
-However, USB uses HID also for monitor controls, speaker controls, UPSs,
-LCDs and many other purposes.
-
-The monitor and speaker controls should be easy to add to the hid/input
-interface, but for the UPSs and LCDs it doesn't make much sense. For this,
-the hiddev interface was designed. See Documentation/hid/hiddev.txt
-for more information about it.
-
-The usage of the usbhid module is very simple, it takes no parameters,
-detects everything automatically and when a HID device is inserted, it
-detects it appropriately.
-
-However, because the devices vary wildly, you might happen to have a
-device that doesn't work well. In that case #define DEBUG at the beginning
-of hid-core.c and send me the syslog traces.
+Event handlers distribute the events from the devices to userspace and
+in-kernel consumers, as needed.
 
-usbmouse
-
-
-For embedded systems, for mice with 

[PATCH 1/8] Input: move documentation for Amiga CD32

[Dmitry Torokhov]

Move the documentation for Amiga CD32 together with other parallel port
joysticks.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/cd32.rst | 24 -
 Documentation/input/index.rst|  1 -
 Documentation/input/joystick-parport.rst | 37 
 3 files changed, 37 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/input/cd32.rst

diff --git a/Documentation/input/cd32.rst b/Documentation/input/cd32.rst
deleted file mode 100644
index 935028b957d9..
--- a/Documentation/input/cd32.rst
+++ /dev/null
@@ -1,24 +0,0 @@
-==
-Amiga CD32
-==
-
-I have written a small patch that let's me use my Amiga CD32
-joypad connected to the parallel port. Thought I'd share it with you so
-you can add it to the list of supported joysticks (hopefully someone will
-find it useful).
-
-It needs the following wiring:
-
-====
-CD32 pad   Parallel port
-====
-1 (Up)  2 (D0)
-2 (Down)3 (D1)
-3 (Left)4 (D2)
-4 (Right)   5 (D3)
-5 (Fire3)  14 (AUTOFD)
-6 (Fire1)  17 (SELIN)
-7 (+5V) 1 (STROBE)
-8 (Gnd)18 (Gnd)
-9 (Fire2)   7 (D5)
-====
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 153f0d476c3e..32c0515fd24b 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -54,7 +54,6 @@ Input drivers
appletouch
atarikbd
bcm5974
-   cd32
cma3000_d0x
cs461x
edt-ft5x06
diff --git a/Documentation/input/joystick-parport.rst 
b/Documentation/input/joystick-parport.rst
index 0aa0fb17bf48..fa8cab584793 100644
--- a/Documentation/input/joystick-parport.rst
+++ b/Documentation/input/joystick-parport.rst
@@ -443,6 +443,43 @@ parallel port::
 The other pins (Up, Down, Right, Left, Power, Ground) are the same as for
 Multi joysticks using db9.c
 
+Amiga CD32
+--
+
+Amiga CD32 joypad uses the following pinout::
+
++---> Button 3
+| +-> Right
+| | +---> Left
+| | | +-> Down
+| | | | +---> Up
+| | | | |
+  _
+5 \ o o o o o / 1
+   \ o o o o /
+  9 `~~~' 6
+| | | |
+| | | +> Button 1
+| | +--> Power
+| +> Ground
++--> Button 2
+
+It can be connected to the parallel port and driven by db9.c driver. It needs 
the following wiring:
+
+   =
+   CD32 padParallel port
+   =
+   1 (Up)   2 (D0)
+   2 (Down) 3 (D1)
+   3 (Left) 4 (D2)
+   4 (Right)5 (D3)
+   5 (Button 3)14 (AUTOFD)
+   6 (Button 1)17 (SELIN)
+   7 (+5V)  1 (STROBE)
+   8 (Gnd) 18 (Gnd)
+   9 (Button 2) 7 (D5)
+   =
+
 The drivers
 ===
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 4/8] Input: docs - remove disclaimer/GPL notice

[Dmitry Torokhov]

This is just a part of kernel documentation, it does not require explicit
license notice.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/index.rst | 21 -
 1 file changed, 21 deletions(-)

diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 32c0515fd24b..5887c79173b8 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -2,27 +2,6 @@
 The Linux Input Documentation
 =
 
-Disclaimer
-==
-
-This program is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 2 of the License, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-more details.
-
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc., 59
-Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
-For your convenience, the GNU General Public License version 2 is included
-in the package: See the file COPYING.
-
-
 Core API
 
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 5/8] Input: docs - update joystick documentation a bit

[Dmitry Torokhov]

Consolidate use instructions and userspace API notes into the same chapter;
remove completely obsolete references, move into a separate subdirectory.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/index.rst |  6 +-
 Documentation/input/joydev/index.rst  | 18 +
 Documentation/input/{ => joydev}/joystick-api.rst | 30 ++--
 Documentation/input/{ => joydev}/joystick.rst | 88 ++-
 Documentation/input/joystick-parport.rst  | 12 ++--
 5 files changed, 71 insertions(+), 83 deletions(-)
 create mode 100644 Documentation/input/joydev/index.rst
 rename Documentation/input/{ => joydev}/joystick-api.rst (89%)
 rename Documentation/input/{ => joydev}/joystick.rst (86%)

diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 5887c79173b8..b25a67198a65 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -2,8 +2,7 @@
 The Linux Input Documentation
 =
 
-Core API
-
+Contents:
 
 .. toctree::
:maxdepth: 2
@@ -12,8 +11,7 @@ Core API
input
input-programming
event-codes
-   joystick
-   joystick-api
+   joydev/index
multi-touch-protocol
gamepad
gameport-programming
diff --git a/Documentation/input/joydev/index.rst 
b/Documentation/input/joydev/index.rst
new file mode 100644
index ..8d9666c7561c
--- /dev/null
+++ b/Documentation/input/joydev/index.rst
@@ -0,0 +1,18 @@
+.. include:: 
+
+==
+Linux Joystick support
+==
+
+:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
+
+.. class:: toc-title
+
+   Table of Contents
+
+.. toctree::
+   :maxdepth: 3
+   :numbered:
+
+   joystick
+   joystick-api
diff --git a/Documentation/input/joystick-api.rst 
b/Documentation/input/joydev/joystick-api.rst
similarity index 89%
rename from Documentation/input/joystick-api.rst
rename to Documentation/input/joydev/joystick-api.rst
index 9b9d26833086..42edcfc6e8af 100644
--- a/Documentation/input/joystick-api.rst
+++ b/Documentation/input/joydev/joystick-api.rst
@@ -1,16 +1,36 @@
-==
-Joystick API Documentation
-==
+=
+Programming Interface
+=
 
 :Author: Ragnar Hojland Espinosa  - 7 Aug 1998
 
+Introduction
+
+
+.. important::
+   This document describes legacy ``js`` interface. Newer clients are
+   encouraged to switch to the generic event (``evdev``) interface.
+
+The 1.0 driver uses a new, event based approach to the joystick driver.
+Instead of the user program polling for the joystick values, the joystick
+driver now reports only any changes of its state. See joystick-api.txt,
+joystick.h and jstest.c included in the joystick package for more
+information. The joystick device can be used in either blocking or
+nonblocking mode, and supports select() calls.
+
+For backward compatibility the old (v0.x) interface is still included.
+Any call to the joystick driver using the old interface will return values
+that are compatible to the old interface. This interface is still limited
+to 2 axes, and applications using it usually decode only 2 buttons, although
+the driver provides up to 32.
+
 Initialization
 ==
 
 Open the joystick device following the usual semantics (that is, with open).
 Since the driver now reports events instead of polling for changes,
 immediately after the open it will issue a series of synthetic events
-(JS_EVENT_INIT) that you can read to check the initial state of the
+(JS_EVENT_INIT) that you can read to obtain the initial state of the
 joystick.
 
 By default, the device is opened in blocking mode::
@@ -182,7 +202,7 @@ the actual state of the joystick.
 
 .. note::
 
- As for version 1.2.8, the queue is circular and able to hold 64
+ As of version 1.2.8, the queue is circular and able to hold 64
  events. You can increment this size bumping up JS_BUFF_SIZE in
  joystick.h and recompiling the driver.
 
diff --git a/Documentation/input/joystick.rst 
b/Documentation/input/joydev/joystick.rst
similarity index 86%
rename from Documentation/input/joystick.rst
rename to Documentation/input/joydev/joystick.rst
index c9c175ffc2ff..b90705eb69b1 100644
--- a/Documentation/input/joystick.rst
+++ b/Documentation/input/joydev/joystick.rst
@@ -1,56 +1,17 @@
 .. include:: 
 
-
-Linux Joystick driver v2.0.0
-
-
-:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
-
-
-Disclaimer
-==
-
-This program is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 2 of the License, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be 

[PATCH 1/8] Input: move documentation for Amiga CD32

[Dmitry Torokhov]

Move the documentation for Amiga CD32 together with other parallel port
joysticks.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/cd32.rst | 24 -
 Documentation/input/index.rst|  1 -
 Documentation/input/joystick-parport.rst | 37 
 3 files changed, 37 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/input/cd32.rst

diff --git a/Documentation/input/cd32.rst b/Documentation/input/cd32.rst
deleted file mode 100644
index 935028b957d9..
--- a/Documentation/input/cd32.rst
+++ /dev/null
@@ -1,24 +0,0 @@
-==
-Amiga CD32
-==
-
-I have written a small patch that let's me use my Amiga CD32
-joypad connected to the parallel port. Thought I'd share it with you so
-you can add it to the list of supported joysticks (hopefully someone will
-find it useful).
-
-It needs the following wiring:
-
-====
-CD32 pad   Parallel port
-====
-1 (Up)  2 (D0)
-2 (Down)3 (D1)
-3 (Left)4 (D2)
-4 (Right)   5 (D3)
-5 (Fire3)  14 (AUTOFD)
-6 (Fire1)  17 (SELIN)
-7 (+5V) 1 (STROBE)
-8 (Gnd)18 (Gnd)
-9 (Fire2)   7 (D5)
-====
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 153f0d476c3e..32c0515fd24b 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -54,7 +54,6 @@ Input drivers
appletouch
atarikbd
bcm5974
-   cd32
cma3000_d0x
cs461x
edt-ft5x06
diff --git a/Documentation/input/joystick-parport.rst 
b/Documentation/input/joystick-parport.rst
index 0aa0fb17bf48..fa8cab584793 100644
--- a/Documentation/input/joystick-parport.rst
+++ b/Documentation/input/joystick-parport.rst
@@ -443,6 +443,43 @@ parallel port::
 The other pins (Up, Down, Right, Left, Power, Ground) are the same as for
 Multi joysticks using db9.c
 
+Amiga CD32
+--
+
+Amiga CD32 joypad uses the following pinout::
+
++---> Button 3
+| +-> Right
+| | +---> Left
+| | | +-> Down
+| | | | +---> Up
+| | | | |
+  _
+5 \ o o o o o / 1
+   \ o o o o /
+  9 `~~~' 6
+| | | |
+| | | +> Button 1
+| | +--> Power
+| +> Ground
++--> Button 2
+
+It can be connected to the parallel port and driven by db9.c driver. It needs 
the following wiring:
+
+   =
+   CD32 padParallel port
+   =
+   1 (Up)   2 (D0)
+   2 (Down) 3 (D1)
+   3 (Left) 4 (D2)
+   4 (Right)5 (D3)
+   5 (Button 3)14 (AUTOFD)
+   6 (Button 1)17 (SELIN)
+   7 (+5V)  1 (STROBE)
+   8 (Gnd) 18 (Gnd)
+   9 (Button 2) 7 (D5)
+   =
+
 The drivers
 ===
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 4/8] Input: docs - remove disclaimer/GPL notice

[Dmitry Torokhov]

This is just a part of kernel documentation, it does not require explicit
license notice.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/index.rst | 21 -
 1 file changed, 21 deletions(-)

diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 32c0515fd24b..5887c79173b8 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -2,27 +2,6 @@
 The Linux Input Documentation
 =
 
-Disclaimer
-==
-
-This program is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 2 of the License, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-more details.
-
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc., 59
-Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
-For your convenience, the GNU General Public License version 2 is included
-in the package: See the file COPYING.
-
-
 Core API
 
 
-- 
2.12.2.762.g0e3151a226-goog

[PATCH 5/8] Input: docs - update joystick documentation a bit

[Dmitry Torokhov]

Consolidate use instructions and userspace API notes into the same chapter;
remove completely obsolete references, move into a separate subdirectory.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/index.rst |  6 +-
 Documentation/input/joydev/index.rst  | 18 +
 Documentation/input/{ => joydev}/joystick-api.rst | 30 ++--
 Documentation/input/{ => joydev}/joystick.rst | 88 ++-
 Documentation/input/joystick-parport.rst  | 12 ++--
 5 files changed, 71 insertions(+), 83 deletions(-)
 create mode 100644 Documentation/input/joydev/index.rst
 rename Documentation/input/{ => joydev}/joystick-api.rst (89%)
 rename Documentation/input/{ => joydev}/joystick.rst (86%)

diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 5887c79173b8..b25a67198a65 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -2,8 +2,7 @@
 The Linux Input Documentation
 =
 
-Core API
-
+Contents:
 
 .. toctree::
:maxdepth: 2
@@ -12,8 +11,7 @@ Core API
input
input-programming
event-codes
-   joystick
-   joystick-api
+   joydev/index
multi-touch-protocol
gamepad
gameport-programming
diff --git a/Documentation/input/joydev/index.rst 
b/Documentation/input/joydev/index.rst
new file mode 100644
index ..8d9666c7561c
--- /dev/null
+++ b/Documentation/input/joydev/index.rst
@@ -0,0 +1,18 @@
+.. include:: 
+
+==
+Linux Joystick support
+==
+
+:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
+
+.. class:: toc-title
+
+   Table of Contents
+
+.. toctree::
+   :maxdepth: 3
+   :numbered:
+
+   joystick
+   joystick-api
diff --git a/Documentation/input/joystick-api.rst 
b/Documentation/input/joydev/joystick-api.rst
similarity index 89%
rename from Documentation/input/joystick-api.rst
rename to Documentation/input/joydev/joystick-api.rst
index 9b9d26833086..42edcfc6e8af 100644
--- a/Documentation/input/joystick-api.rst
+++ b/Documentation/input/joydev/joystick-api.rst
@@ -1,16 +1,36 @@
-==
-Joystick API Documentation
-==
+=
+Programming Interface
+=
 
 :Author: Ragnar Hojland Espinosa  - 7 Aug 1998
 
+Introduction
+
+
+.. important::
+   This document describes legacy ``js`` interface. Newer clients are
+   encouraged to switch to the generic event (``evdev``) interface.
+
+The 1.0 driver uses a new, event based approach to the joystick driver.
+Instead of the user program polling for the joystick values, the joystick
+driver now reports only any changes of its state. See joystick-api.txt,
+joystick.h and jstest.c included in the joystick package for more
+information. The joystick device can be used in either blocking or
+nonblocking mode, and supports select() calls.
+
+For backward compatibility the old (v0.x) interface is still included.
+Any call to the joystick driver using the old interface will return values
+that are compatible to the old interface. This interface is still limited
+to 2 axes, and applications using it usually decode only 2 buttons, although
+the driver provides up to 32.
+
 Initialization
 ==
 
 Open the joystick device following the usual semantics (that is, with open).
 Since the driver now reports events instead of polling for changes,
 immediately after the open it will issue a series of synthetic events
-(JS_EVENT_INIT) that you can read to check the initial state of the
+(JS_EVENT_INIT) that you can read to obtain the initial state of the
 joystick.
 
 By default, the device is opened in blocking mode::
@@ -182,7 +202,7 @@ the actual state of the joystick.
 
 .. note::
 
- As for version 1.2.8, the queue is circular and able to hold 64
+ As of version 1.2.8, the queue is circular and able to hold 64
  events. You can increment this size bumping up JS_BUFF_SIZE in
  joystick.h and recompiling the driver.
 
diff --git a/Documentation/input/joystick.rst 
b/Documentation/input/joydev/joystick.rst
similarity index 86%
rename from Documentation/input/joystick.rst
rename to Documentation/input/joydev/joystick.rst
index c9c175ffc2ff..b90705eb69b1 100644
--- a/Documentation/input/joystick.rst
+++ b/Documentation/input/joydev/joystick.rst
@@ -1,56 +1,17 @@
 .. include:: 
 
-
-Linux Joystick driver v2.0.0
-
-
-:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
-
-
-Disclaimer
-==
-
-This program is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 2 of the License, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of 

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 15/04/17 09:01 PM, Benjamin Herrenschmidt wrote:
> Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a
> flag ?)

Well you can't use ZONE_DEVICE as an indicator. They may be regular RAM,
(eg. pmem). It would need a separate flag indicating it is backed by iomem.

Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 15/04/17 09:01 PM, Benjamin Herrenschmidt wrote:
> Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a
> flag ?)

Well you can't use ZONE_DEVICE as an indicator. They may be regular RAM,
(eg. pmem). It would need a separate flag indicating it is backed by iomem.

Logan

Re: [PATCH v4 00/10] Add Basic SoC support for MT6797

[Mars Cheng]

Hi Stephen, Matthias

gentle ping. :-)

Thanks.

On Sat, 2017-04-08 at 09:20 +0800, Mars Cheng wrote:
> This patch set adds basic SoC support for mediatek's first 10-core
> chip, X20, also known as MT6797.
> 
> - based on 4.11-rc1
> - support common clk framework
> - apply patches about intpol just accepted to get full feature support:
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008371.html
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008375.html
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008373.html
> 
> Changes since v3:
> - since intpol patches accepted in v3, remove them
> - clk ID header separated from original clk driver submit
> - clean up clk driver, including unnecessary header and fields in structure
> 
> Changes since v2:
> - prevent uncessary #intpol-bases for mtk-sysirq
> - add fast path for mtk-sysirq set_type when introducing multiple bases
> - add acked-by and tested-by
> - remove wrong usage for timer node
> 
> Changes since v1:
> - add multiple base addresses support, v1 only allow 2 bases
> - clean up clk driver
> 
> Kevin-CW Chen (2):
>   dt-bindings: arm: mediatek: document clk bindings for MT6797
>   clk: mediatek: add clk support for MT6797
> 
> Mars Cheng (8):
>   dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
>   arm64: dts: mediatek: add mt6797 support
>   clk: mediatek: add mt6797 clock IDs
>   soc: mediatek: avoid using fixed spm power status defines
>   soc: mediatek: add vdec item for scpsys
>   dt-bindings: mediatek: add MT6797 power dt-bindings
>   soc: mediatek: add MT6797 scpsys support
>   arm64: dts: mediatek: add clk and scp nodes for MT6797
> 
>  Documentation/devicetree/bindings/arm/mediatek.txt |4 +
>  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
>  .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
>  .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
>  .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
>  .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
>  .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
>  .../bindings/arm/mediatek/mediatek,vencsys.txt |3 +-
>  .../interrupt-controller/mediatek,sysirq.txt   |1 +
>  .../devicetree/bindings/serial/mtk-uart.txt|1 +
>  .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
>  arch/arm64/boot/dts/mediatek/Makefile  |1 +
>  arch/arm64/boot/dts/mediatek/mt6797-evb.dts|   36 +
>  arch/arm64/boot/dts/mediatek/mt6797.dtsi   |  245 +++
>  drivers/clk/mediatek/Kconfig   |   32 +
>  drivers/clk/mediatek/Makefile  |5 +
>  drivers/clk/mediatek/clk-mt6797-img.c  |   76 +++
>  drivers/clk/mediatek/clk-mt6797-mm.c   |  136 
>  drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +++
>  drivers/clk/mediatek/clk-mt6797-venc.c |   78 +++
>  drivers/clk/mediatek/clk-mt6797.c  |  714 
> 
>  drivers/soc/mediatek/mtk-scpsys.c  |  149 +++-
>  include/dt-bindings/clock/mt6797-clk.h |  281 
>  include/dt-bindings/power/mt6797-power.h   |   30 +
>  24 files changed, 1889 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797.c
>  create mode 100644 include/dt-bindings/clock/mt6797-clk.h
>  create mode 100644 include/dt-bindings/power/mt6797-power.h
> 
> --
> 1.7.9.5

Re: [PATCH v4 00/10] Add Basic SoC support for MT6797

[Mars Cheng]

Hi Stephen, Matthias

gentle ping. :-)

Thanks.

On Sat, 2017-04-08 at 09:20 +0800, Mars Cheng wrote:
> This patch set adds basic SoC support for mediatek's first 10-core
> chip, X20, also known as MT6797.
> 
> - based on 4.11-rc1
> - support common clk framework
> - apply patches about intpol just accepted to get full feature support:
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008371.html
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008375.html
> http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008373.html
> 
> Changes since v3:
> - since intpol patches accepted in v3, remove them
> - clk ID header separated from original clk driver submit
> - clean up clk driver, including unnecessary header and fields in structure
> 
> Changes since v2:
> - prevent uncessary #intpol-bases for mtk-sysirq
> - add fast path for mtk-sysirq set_type when introducing multiple bases
> - add acked-by and tested-by
> - remove wrong usage for timer node
> 
> Changes since v1:
> - add multiple base addresses support, v1 only allow 2 bases
> - clean up clk driver
> 
> Kevin-CW Chen (2):
>   dt-bindings: arm: mediatek: document clk bindings for MT6797
>   clk: mediatek: add clk support for MT6797
> 
> Mars Cheng (8):
>   dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
>   arm64: dts: mediatek: add mt6797 support
>   clk: mediatek: add mt6797 clock IDs
>   soc: mediatek: avoid using fixed spm power status defines
>   soc: mediatek: add vdec item for scpsys
>   dt-bindings: mediatek: add MT6797 power dt-bindings
>   soc: mediatek: add MT6797 scpsys support
>   arm64: dts: mediatek: add clk and scp nodes for MT6797
> 
>  Documentation/devicetree/bindings/arm/mediatek.txt |4 +
>  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
>  .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
>  .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
>  .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
>  .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
>  .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
>  .../bindings/arm/mediatek/mediatek,vencsys.txt |3 +-
>  .../interrupt-controller/mediatek,sysirq.txt   |1 +
>  .../devicetree/bindings/serial/mtk-uart.txt|1 +
>  .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
>  arch/arm64/boot/dts/mediatek/Makefile  |1 +
>  arch/arm64/boot/dts/mediatek/mt6797-evb.dts|   36 +
>  arch/arm64/boot/dts/mediatek/mt6797.dtsi   |  245 +++
>  drivers/clk/mediatek/Kconfig   |   32 +
>  drivers/clk/mediatek/Makefile  |5 +
>  drivers/clk/mediatek/clk-mt6797-img.c  |   76 +++
>  drivers/clk/mediatek/clk-mt6797-mm.c   |  136 
>  drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +++
>  drivers/clk/mediatek/clk-mt6797-venc.c |   78 +++
>  drivers/clk/mediatek/clk-mt6797.c  |  714 
> 
>  drivers/soc/mediatek/mtk-scpsys.c  |  149 +++-
>  include/dt-bindings/clock/mt6797-clk.h |  281 
>  include/dt-bindings/power/mt6797-power.h   |   30 +
>  24 files changed, 1889 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt6797.c
>  create mode 100644 include/dt-bindings/clock/mt6797-clk.h
>  create mode 100644 include/dt-bindings/power/mt6797-power.h
> 
> --
> 1.7.9.5

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Axel Lin]

2017-04-16 9:12 GMT+08:00 Axel Lin :
> 2017-04-16 0:53 GMT+08:00 Stefan Agner :
>> On 2017-04-15 07:52, Axel Lin wrote:
>>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>>> So for rn5t618, there is out of bounds array access when checking
>>> regulators[i].name in the for loop.
>>
>> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
>> that the non initialized elements are zero. The highest element LDORTC2
>> is defined, hence the length of the array should be RN5T618_REG_NUM.
>
> ok, I missed that. Then current code is fine.
I just realize my patch is wrong due to the use of designated initializers.

Regards,
Axel

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Axel Lin]

2017-04-16 9:12 GMT+08:00 Axel Lin :
> 2017-04-16 0:53 GMT+08:00 Stefan Agner :
>> On 2017-04-15 07:52, Axel Lin wrote:
>>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>>> So for rn5t618, there is out of bounds array access when checking
>>> regulators[i].name in the for loop.
>>
>> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
>> that the non initialized elements are zero. The highest element LDORTC2
>> is defined, hence the length of the array should be RN5T618_REG_NUM.
>
> ok, I missed that. Then current code is fine.
I just realize my patch is wrong due to the use of designated initializers.

Regards,
Axel

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Benjamin Herrenschmidt]

On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote:
> I'm wondering, since this is limited to support behind a single
> switch, if you could have a software-iommu hanging off that switch
> device object that knows how to catch and translate the non-zero
> offset bus address case. We have something like this with VMD driver,
> and I toyed with a soft pci bridge when trying to support AHCI+NVME
> bar remapping. When the dma api looks up the iommu for its device it
> hits this soft-iommu and that driver checks if the page is host memory
> or device memory to do the dma translation. You wouldn't need a bit in
> struct page, just a lookup to the hosting struct dev_pagemap in the
> is_zone_device_page() case and that can point you to p2p details.

I was thinking about a hook in the arch DMA ops but that kind of
wrapper might work instead indeed. However I'm not sure what's the best
way to "instantiate" it.

The main issue is that the DMA ops are a function of the initiator,
not the target (since the target is supposed to be memory) so things
are a bit awkward.

One (user ?) would have to know that a given device "intends" to DMA
directly to another device.

This is awkward because in the ideal scenario, this isn't something the
device knows. For example, one could want to have an existing NIC DMA
directly to/from NVME pages or GPU pages.

The NIC itself doesn't know the characteristic of these pages, but
*something* needs to insert itself in the DMA ops of that bridge to
make it possible.

That's why I wonder if it's the struct page of the target that should
be "marked" in such a way that the arch dma'ops can immediately catch
that they belong to a device and might require "wrapped" operations.

Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a
flag ?)

That would allow us to keep a fast path for normal memory targets, but
also have some kind of way to handle the special cases of such peer 2
peer (or also handle other type of peer to peer that don't necessarily
involve PCI address wrangling but could require additional iommu bits).

Just thinking out loud ... I don't have a firm idea or a design. But
peer to peer is definitely a problem we need to tackle generically, the
demand for it keeps coming up.

Cheers,
Ben.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Benjamin Herrenschmidt]

On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote:
> I'm wondering, since this is limited to support behind a single
> switch, if you could have a software-iommu hanging off that switch
> device object that knows how to catch and translate the non-zero
> offset bus address case. We have something like this with VMD driver,
> and I toyed with a soft pci bridge when trying to support AHCI+NVME
> bar remapping. When the dma api looks up the iommu for its device it
> hits this soft-iommu and that driver checks if the page is host memory
> or device memory to do the dma translation. You wouldn't need a bit in
> struct page, just a lookup to the hosting struct dev_pagemap in the
> is_zone_device_page() case and that can point you to p2p details.

I was thinking about a hook in the arch DMA ops but that kind of
wrapper might work instead indeed. However I'm not sure what's the best
way to "instantiate" it.

The main issue is that the DMA ops are a function of the initiator,
not the target (since the target is supposed to be memory) so things
are a bit awkward.

One (user ?) would have to know that a given device "intends" to DMA
directly to another device.

This is awkward because in the ideal scenario, this isn't something the
device knows. For example, one could want to have an existing NIC DMA
directly to/from NVME pages or GPU pages.

The NIC itself doesn't know the characteristic of these pages, but
*something* needs to insert itself in the DMA ops of that bridge to
make it possible.

That's why I wonder if it's the struct page of the target that should
be "marked" in such a way that the arch dma'ops can immediately catch
that they belong to a device and might require "wrapped" operations.

Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a
flag ?)

That would allow us to keep a fast path for normal memory targets, but
also have some kind of way to handle the special cases of such peer 2
peer (or also handle other type of peer to peer that don't necessarily
involve PCI address wrangling but could require additional iommu bits).

Just thinking out loud ... I don't have a firm idea or a design. But
peer to peer is definitely a problem we need to tackle generically, the
demand for it keeps coming up.

Cheers,
Ben.

Re: [PATCH] microblaze/timer: set ->min_delta_ticks and ->max_delta_ticks

[Nicolai Stange]

Hello Daniel,

On Fri, Apr 07 2017, Daniel Lezcano wrote:

> On Thu, Mar 30, 2017 at 09:45:28PM +0200, Nicolai Stange wrote:
>> diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
>> index 999066192715..545ccd46edb3 100644
>> --- a/arch/microblaze/kernel/timer.c
>> +++ b/arch/microblaze/kernel/timer.c
>> @@ -178,8 +178,10 @@ static __init int xilinx_clockevent_init(void)
>>  clockevent_xilinx_timer.shift);
>>  clockevent_xilinx_timer.max_delta_ns =
>>  clockevent_delta2ns((u32)~0, _xilinx_timer);
>> +clockevent_xilinx_timer.max_delta_ticks = (u32)~0;
>
> Can you take the opportunity to fix the type (unsigned long) ?

Hmm, I personally think that it'd be better to leave the u32 there as it
corresponds to the hardware's counter width?

clockevent_delta2ns()' latch argument has been of type unsigned long
from the beginning and this might indicate that at least this
driver's original author followed this line of reasoning...

OTOH, I think that u32 is equivalent to unsigned long on microblaze, so
it doesn't matter much.

Does the above convince you or do you still want the

  - clockevent_xilinx_timer.max_delta_ticks = (u32)~0;
  + clockevent_xilinx_timer.max_delta_ticks = ~0UL;

change?


Thanks,

Nicolai

Re: [PATCH] microblaze/timer: set ->min_delta_ticks and ->max_delta_ticks

[Nicolai Stange]

Hello Daniel,

On Fri, Apr 07 2017, Daniel Lezcano wrote:

> On Thu, Mar 30, 2017 at 09:45:28PM +0200, Nicolai Stange wrote:
>> diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
>> index 999066192715..545ccd46edb3 100644
>> --- a/arch/microblaze/kernel/timer.c
>> +++ b/arch/microblaze/kernel/timer.c
>> @@ -178,8 +178,10 @@ static __init int xilinx_clockevent_init(void)
>>  clockevent_xilinx_timer.shift);
>>  clockevent_xilinx_timer.max_delta_ns =
>>  clockevent_delta2ns((u32)~0, _xilinx_timer);
>> +clockevent_xilinx_timer.max_delta_ticks = (u32)~0;
>
> Can you take the opportunity to fix the type (unsigned long) ?

Hmm, I personally think that it'd be better to leave the u32 there as it
corresponds to the hardware's counter width?

clockevent_delta2ns()' latch argument has been of type unsigned long
from the beginning and this might indicate that at least this
driver's original author followed this line of reasoning...

OTOH, I think that u32 is equivalent to unsigned long on microblaze, so
it doesn't matter much.

Does the above convince you or do you still want the

  - clockevent_xilinx_timer.max_delta_ticks = (u32)~0;
  + clockevent_xilinx_timer.max_delta_ticks = ~0UL;

change?


Thanks,

Nicolai

Re: [PATCH] ARM: dts: omap4-droid4: add bluetooth

[Rob Herring]

On Sat, Apr 15, 2017 at 5:18 PM, Sebastian Reichel  wrote:
> Droid 4 has wl1835 connected to the OMAP's UART4 port, which is
> used for Bluetooth and most likely can also be used for controlling
> the FM radio and GPS receivers.
>
> Signed-off-by: Sebastian Reichel 
> ---
> Hi,
>
> Thanks to the work of Rob adding Bluetooth support for Droid 4 was
> straight forward :) I did a short test scanning for available devices
> using bluetoothctl. For that I had to rebind the bluetooth device,
> since it has been initialized before rootfs/firmware was available
> (builtin driver):
>
> echo serial0-0 > /sys/bus/serial/drivers/hci-ti/unbind
> echo serial0-0 > /sys/bus/serial/drivers/hci-ti/bind
>
> According to my research the FM module should be functional on
> Droid 4 and the wl1835's GPS is also used. Rob, do you have a
> plans for supporting the extra resources?

I don't think the h/w I have can do FM or GPS. At least there's no
headphone jack to serve as the FM antenna. For GPS, it seems support
for that is not publicly available. Maybe an antenna is not needed to
get the control interface working. It would be nice to integrate
though and then we can kill off the shared transport driver. Marcel
had mentioned that the Intel BT driver provides a regmap interface to
its FM driver. Not sure if that would work for TI.

Rob

Re: [PATCH] ARM: dts: omap4-droid4: add bluetooth

[Rob Herring]

On Sat, Apr 15, 2017 at 5:18 PM, Sebastian Reichel  wrote:
> Droid 4 has wl1835 connected to the OMAP's UART4 port, which is
> used for Bluetooth and most likely can also be used for controlling
> the FM radio and GPS receivers.
>
> Signed-off-by: Sebastian Reichel 
> ---
> Hi,
>
> Thanks to the work of Rob adding Bluetooth support for Droid 4 was
> straight forward :) I did a short test scanning for available devices
> using bluetoothctl. For that I had to rebind the bluetooth device,
> since it has been initialized before rootfs/firmware was available
> (builtin driver):
>
> echo serial0-0 > /sys/bus/serial/drivers/hci-ti/unbind
> echo serial0-0 > /sys/bus/serial/drivers/hci-ti/bind
>
> According to my research the FM module should be functional on
> Droid 4 and the wl1835's GPS is also used. Rob, do you have a
> plans for supporting the extra resources?

I don't think the h/w I have can do FM or GPS. At least there's no
headphone jack to serve as the FM antenna. For GPS, it seems support
for that is not publicly available. Maybe an antenna is not needed to
get the control interface working. It would be nice to integrate
though and then we can kill off the shared transport driver. Marcel
had mentioned that the Intel BT driver provides a regmap interface to
its FM driver. Not sure if that would work for TI.

Rob

arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACER &

[kbuild test robot]

Hi Josh,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d5ff0814fda50f0306e102f39640cf5bb76af08e
commit: 3f135e57a4f76d24ae8d8a490314331f0ced40c5 x86/build: Mostly disable 
'-maccumulate-outgoing-args'
date:   2 weeks ago
config: x86_64-randconfig-s1-04160822 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 3f135e57a4f76d24ae8d8a490314331f0ced40c5
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is 
>> not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and 
>> !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACER && 
>> CONFIG_CC_OPTIMIZE_FOR_SIZE

vim +35 arch/x86//kernel/ftrace.c

29  #include 
30  #include 
31  
32  #if defined(CONFIG_FUNCTION_GRAPH_TRACER) && \
33  !defined(CC_USING_FENTRY) && \
34  !defined(CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE)
  > 35  # error The following combination is not supported: ((compiler missing 
-mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && 
CONFIG_FUNCTION_GRAPH_TRACER && CONFIG_CC_OPTIMIZE_FOR_SIZE
36  #endif
37  
38  #ifdef CONFIG_DYNAMIC_FTRACE

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


.config.gz
Description: application/gzip

arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACER &

[kbuild test robot]

Hi Josh,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d5ff0814fda50f0306e102f39640cf5bb76af08e
commit: 3f135e57a4f76d24ae8d8a490314331f0ced40c5 x86/build: Mostly disable 
'-maccumulate-outgoing-args'
date:   2 weeks ago
config: x86_64-randconfig-s1-04160822 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 3f135e57a4f76d24ae8d8a490314331f0ced40c5
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is 
>> not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and 
>> !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACER && 
>> CONFIG_CC_OPTIMIZE_FOR_SIZE

vim +35 arch/x86//kernel/ftrace.c

29  #include 
30  #include 
31  
32  #if defined(CONFIG_FUNCTION_GRAPH_TRACER) && \
33  !defined(CC_USING_FENTRY) && \
34  !defined(CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE)
  > 35  # error The following combination is not supported: ((compiler missing 
-mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && 
CONFIG_FUNCTION_GRAPH_TRACER && CONFIG_CC_OPTIMIZE_FOR_SIZE
36  #endif
37  
38  #ifdef CONFIG_DYNAMIC_FTRACE

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


.config.gz
Description: application/gzip

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Axel Lin]

2017-04-16 0:53 GMT+08:00 Stefan Agner :
> On 2017-04-15 07:52, Axel Lin wrote:
>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>> So for rn5t618, there is out of bounds array access when checking
>> regulators[i].name in the for loop.
>
> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
> that the non initialized elements are zero. The highest element LDORTC2
> is defined, hence the length of the array should be RN5T618_REG_NUM.

ok, I missed that. Then current code is fine.
Though the meaing of RN5T618_REG_NUM seems misleading to me as different
variant has differnt number of regulators.

Thanks for the review,
Axel

Re: [PATCH RESEND] regulator: rn5t618: Fix out of bounds array access

[Axel Lin]

2017-04-16 0:53 GMT+08:00 Stefan Agner :
> On 2017-04-15 07:52, Axel Lin wrote:
>> The commit "regulator: rn5t618: Add RN5T567 PMIC support" added
>> RN5T618_DCDC4 to the enum, then RN5T618_REG_NUM is also changed.
>> So for rn5t618, there is out of bounds array access when checking
>> regulators[i].name in the for loop.
>
> I use designated initializers ([RN5T618_##rid] = {..), which guarantee
> that the non initialized elements are zero. The highest element LDORTC2
> is defined, hence the length of the array should be RN5T618_REG_NUM.

ok, I missed that. Then current code is fine.
Though the meaing of RN5T618_REG_NUM seems misleading to me as different
variant has differnt number of regulators.

Thanks for the review,
Axel

[PATCH] Remove ARM errata Workarounds 458693 and 460075

[Nisal Menuka]

According to ARM, these errata exist only in a version of Cortex-A8
(r2p0) which was never built. Therefore, I believe there are no platforms
where this workaround should be enabled.
link :http://infocenter.arm.com/help/index.jsp?topic=
/com.arm.doc.faqs/ka15634.html

Signed-off-by: Nisal Menuka 
---
 arch/arm/Kconfig  | 27 ---
 arch/arm/mm/proc-v7.S | 14 --
 2 files changed, 41 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d4e71b..d527963 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1005,33 +1005,6 @@ config ARM_ERRATA_430973
  Note that setting specific bits in the ACTLR register may not be
  available in non-secure mode.
 
-config ARM_ERRATA_458693
-   bool "ARM errata: Processor deadlock when a false hazard is created"
-   depends on CPU_V7
-   depends on !ARCH_MULTIPLATFORM
-   help
- This option enables the workaround for the 458693 Cortex-A8 (r2p0)
- erratum. For very specific sequences of memory operations, it is
- possible for a hazard condition intended for a cache line to instead
- be incorrectly associated with a different cache line. This false
- hazard might then cause a processor deadlock. The workaround enables
- the L1 caching of the NEON accesses and disables the PLD instruction
- in the ACTLR register. Note that setting specific bits in the ACTLR
- register may not be available in non-secure mode.
-
-config ARM_ERRATA_460075
-   bool "ARM errata: Data written to the L2 cache can be overwritten with 
stale data"
-   depends on CPU_V7
-   depends on !ARCH_MULTIPLATFORM
-   help
- This option enables the workaround for the 460075 Cortex-A8 (r2p0)
- erratum. Any asynchronous access to the L2 cache may encounter a
- situation in which recent store transactions to the L2 cache are lost
- and overwritten with stale memory contents from external memory. The
- workaround disables the write-allocate mode for the L2 cache via the
- ACTLR register. Note that setting specific bits in the ACTLR register
- may not be available in non-secure mode.
-
 config ARM_ERRATA_742230
bool "ARM errata: DMB operation may be faulty"
depends on CPU_V7 && SMP
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d00d52c..43a4a12 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -306,20 +306,6 @@ __ca8_errata:
orreq   r0, r0, #(1 << 6)   @ set IBE to 1
mcreq   p15, 0, r0, c1, c0, 1   @ write aux control register
 #endif
-#ifdef CONFIG_ARM_ERRATA_458693
-   teq r6, #0x20   @ only present in r2p0
-   mrceq   p15, 0, r0, c1, c0, 1   @ read aux control register
-   orreq   r0, r0, #(1 << 5)   @ set L1NEON to 1
-   orreq   r0, r0, #(1 << 9)   @ set PLDNOP to 1
-   mcreq   p15, 0, r0, c1, c0, 1   @ write aux control register
-#endif
-#ifdef CONFIG_ARM_ERRATA_460075
-   teq r6, #0x20   @ only present in r2p0
-   mrceq   p15, 1, r0, c9, c0, 2   @ read L2 cache aux ctrl 
register
-   tsteq   r0, #1 << 22
-   orreq   r0, r0, #(1 << 22)  @ set the Write Allocate 
disable bit
-   mcreq   p15, 1, r0, c9, c0, 2   @ write the L2 cache aux ctrl 
register
-#endif
b   __errata_finish
 
 __ca9_errata:
-- 
2.7.4

[PATCH] Remove ARM errata Workarounds 458693 and 460075

[Nisal Menuka]

According to ARM, these errata exist only in a version of Cortex-A8
(r2p0) which was never built. Therefore, I believe there are no platforms
where this workaround should be enabled.
link :http://infocenter.arm.com/help/index.jsp?topic=
/com.arm.doc.faqs/ka15634.html

Signed-off-by: Nisal Menuka 
---
 arch/arm/Kconfig  | 27 ---
 arch/arm/mm/proc-v7.S | 14 --
 2 files changed, 41 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d4e71b..d527963 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1005,33 +1005,6 @@ config ARM_ERRATA_430973
  Note that setting specific bits in the ACTLR register may not be
  available in non-secure mode.
 
-config ARM_ERRATA_458693
-   bool "ARM errata: Processor deadlock when a false hazard is created"
-   depends on CPU_V7
-   depends on !ARCH_MULTIPLATFORM
-   help
- This option enables the workaround for the 458693 Cortex-A8 (r2p0)
- erratum. For very specific sequences of memory operations, it is
- possible for a hazard condition intended for a cache line to instead
- be incorrectly associated with a different cache line. This false
- hazard might then cause a processor deadlock. The workaround enables
- the L1 caching of the NEON accesses and disables the PLD instruction
- in the ACTLR register. Note that setting specific bits in the ACTLR
- register may not be available in non-secure mode.
-
-config ARM_ERRATA_460075
-   bool "ARM errata: Data written to the L2 cache can be overwritten with 
stale data"
-   depends on CPU_V7
-   depends on !ARCH_MULTIPLATFORM
-   help
- This option enables the workaround for the 460075 Cortex-A8 (r2p0)
- erratum. Any asynchronous access to the L2 cache may encounter a
- situation in which recent store transactions to the L2 cache are lost
- and overwritten with stale memory contents from external memory. The
- workaround disables the write-allocate mode for the L2 cache via the
- ACTLR register. Note that setting specific bits in the ACTLR register
- may not be available in non-secure mode.
-
 config ARM_ERRATA_742230
bool "ARM errata: DMB operation may be faulty"
depends on CPU_V7 && SMP
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d00d52c..43a4a12 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -306,20 +306,6 @@ __ca8_errata:
orreq   r0, r0, #(1 << 6)   @ set IBE to 1
mcreq   p15, 0, r0, c1, c0, 1   @ write aux control register
 #endif
-#ifdef CONFIG_ARM_ERRATA_458693
-   teq r6, #0x20   @ only present in r2p0
-   mrceq   p15, 0, r0, c1, c0, 1   @ read aux control register
-   orreq   r0, r0, #(1 << 5)   @ set L1NEON to 1
-   orreq   r0, r0, #(1 << 9)   @ set PLDNOP to 1
-   mcreq   p15, 0, r0, c1, c0, 1   @ write aux control register
-#endif
-#ifdef CONFIG_ARM_ERRATA_460075
-   teq r6, #0x20   @ only present in r2p0
-   mrceq   p15, 1, r0, c9, c0, 2   @ read L2 cache aux ctrl 
register
-   tsteq   r0, #1 << 22
-   orreq   r0, r0, #(1 << 22)  @ set the Write Allocate 
disable bit
-   mcreq   p15, 1, r0, c9, c0, 2   @ write the L2 cache aux ctrl 
register
-#endif
b   __errata_finish
 
 __ca9_errata:
-- 
2.7.4

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

[Mike Kravetz]

On 04/13/2017 08:32 PM, Naoya Horiguchi wrote:
> On Tue, Apr 11, 2017 at 03:51:58PM -0700, Mike Kravetz wrote:
> ...
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 7163fe0..dde8613 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -136,17 +136,26 @@ static int hugetlbfs_file_mmap(struct file *file, 
>> struct vm_area_struct *vma)
>>  vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND;
>>  vma->vm_ops = _vm_ops;
>>  
>> +/*
>> + * Offset passed to mmap (before page shift) could have been
>> + * negative when represented as a (l)off_t.
>> + */
>> +if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
>> +return -EINVAL;
>> +
>>  if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
>>  return -EINVAL;
>>  
>>  vma_len = (loff_t)(vma->vm_end - vma->vm_start);
>> +len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
>> +/* check for overflow */
>> +if (len < vma_len)
>> +return -EINVAL;
> 
> Andrew sent this patch to Linus today, so I know it's a little too late, but
> I think that getting len directly from vma like below might be a simpler fix.
> 
>   len = (loff_t)(vma->vm_end - vma->vm_start + (vma->vm_pgoff << 
> PAGE_SHIFT)); 
> 
> This shouldn't overflow because vma->vm_{end|start|pgoff} are unsigned long,
> but if worried you can add VM_BUG_ON_VMA(len < 0, vma).

Thanks Naoya,

I am pretty sure the checks are necessary.  You are correct in that
vma->vm_{end|start|pgoff} are unsigned long.  However,  pgoff can be
a REALLY big value that becomes negative when shifted.

Note that pgoff is simply the off_t offset value passed from the user cast
to unsigned long and shifted right by PAGE_SHIFT.  There is nothing to
prevent a user from passing a 'signed' negative value.  In the reproducer
provided, the value passed from user space is 0x8000ULL.

-- 
Mike Kravetz

Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

[Mike Kravetz]

On 04/13/2017 08:32 PM, Naoya Horiguchi wrote:
> On Tue, Apr 11, 2017 at 03:51:58PM -0700, Mike Kravetz wrote:
> ...
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 7163fe0..dde8613 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -136,17 +136,26 @@ static int hugetlbfs_file_mmap(struct file *file, 
>> struct vm_area_struct *vma)
>>  vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND;
>>  vma->vm_ops = _vm_ops;
>>  
>> +/*
>> + * Offset passed to mmap (before page shift) could have been
>> + * negative when represented as a (l)off_t.
>> + */
>> +if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
>> +return -EINVAL;
>> +
>>  if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
>>  return -EINVAL;
>>  
>>  vma_len = (loff_t)(vma->vm_end - vma->vm_start);
>> +len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
>> +/* check for overflow */
>> +if (len < vma_len)
>> +return -EINVAL;
> 
> Andrew sent this patch to Linus today, so I know it's a little too late, but
> I think that getting len directly from vma like below might be a simpler fix.
> 
>   len = (loff_t)(vma->vm_end - vma->vm_start + (vma->vm_pgoff << 
> PAGE_SHIFT)); 
> 
> This shouldn't overflow because vma->vm_{end|start|pgoff} are unsigned long,
> but if worried you can add VM_BUG_ON_VMA(len < 0, vma).

Thanks Naoya,

I am pretty sure the checks are necessary.  You are correct in that
vma->vm_{end|start|pgoff} are unsigned long.  However,  pgoff can be
a REALLY big value that becomes negative when shifted.

Note that pgoff is simply the off_t offset value passed from the user cast
to unsigned long and shifted right by PAGE_SHIFT.  There is nothing to
prevent a user from passing a 'signed' negative value.  In the reproducer
provided, the value passed from user space is 0x8000ULL.

-- 
Mike Kravetz

Re: [patch 06/20] cpufreq: Use cpuhp_setup_state_nocalls_locked()

[Rafael J. Wysocki]

On Sat, Apr 15, 2017 at 7:01 PM, Thomas Gleixner  wrote:
> From: Sebastian Andrzej Siewior 
>
> cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls()
> to make subsys_interface_register() and the registration of hotplug calls
> atomic versus cpu hotplug.
>
> cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is
> correct, but prevents the conversion of the hotplug locking to a percpu
> rwsem.
>
> Use cpuhp_setup_state_nocalls_locked() to avoid the nested call.
>
> Signed-off-by: Sebastian Andrzej Siewior 
> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org

Acked-by: Rafael J. Wysocki 

>
> ---
>  drivers/cpufreq/cpufreq.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2473,9 +2473,10 @@ int cpufreq_register_driver(struct cpufr
> goto err_if_unreg;
> }
>
> -   ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "cpufreq:online",
> -   cpuhp_cpufreq_online,
> -   cpuhp_cpufreq_offline);
> +   ret = cpuhp_setup_state_nocalls_locked(CPUHP_AP_ONLINE_DYN,
> +  "cpufreq:online",
> +  cpuhp_cpufreq_online,
> +  cpuhp_cpufreq_offline);
> if (ret < 0)
> goto err_if_unreg;
> hp_online = ret;
> @@ -2519,7 +2520,7 @@ int cpufreq_unregister_driver(struct cpu
> get_online_cpus();
> subsys_interface_unregister(_interface);
> remove_boost_sysfs_file();
> -   cpuhp_remove_state_nocalls(hp_online);
> +   cpuhp_remove_state_nocalls_locked(hp_online);
>
> write_lock_irqsave(_driver_lock, flags);
>
>
>

Re: [patch 06/20] cpufreq: Use cpuhp_setup_state_nocalls_locked()

[Rafael J. Wysocki]

On Sat, Apr 15, 2017 at 7:01 PM, Thomas Gleixner  wrote:
> From: Sebastian Andrzej Siewior 
>
> cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls()
> to make subsys_interface_register() and the registration of hotplug calls
> atomic versus cpu hotplug.
>
> cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is
> correct, but prevents the conversion of the hotplug locking to a percpu
> rwsem.
>
> Use cpuhp_setup_state_nocalls_locked() to avoid the nested call.
>
> Signed-off-by: Sebastian Andrzej Siewior 
> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org

Acked-by: Rafael J. Wysocki 

>
> ---
>  drivers/cpufreq/cpufreq.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2473,9 +2473,10 @@ int cpufreq_register_driver(struct cpufr
> goto err_if_unreg;
> }
>
> -   ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "cpufreq:online",
> -   cpuhp_cpufreq_online,
> -   cpuhp_cpufreq_offline);
> +   ret = cpuhp_setup_state_nocalls_locked(CPUHP_AP_ONLINE_DYN,
> +  "cpufreq:online",
> +  cpuhp_cpufreq_online,
> +  cpuhp_cpufreq_offline);
> if (ret < 0)
> goto err_if_unreg;
> hp_online = ret;
> @@ -2519,7 +2520,7 @@ int cpufreq_unregister_driver(struct cpu
> get_online_cpus();
> subsys_interface_unregister(_interface);
> remove_boost_sysfs_file();
> -   cpuhp_remove_state_nocalls(hp_online);
> +   cpuhp_remove_state_nocalls_locked(hp_online);
>
> write_lock_irqsave(_driver_lock, flags);
>
>
>

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Benjamin Herrenschmidt]

On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote:
> Thanks, Benjamin, for the summary of some of the issues.
> 
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
> > So I assume the p2p code provides a way to address that too via special
> > dma_ops ? Or wrappers ?
> 
> Not at this time. We will probably need a way to ensure the iommus do
> not attempt to remap these addresses.

You can't. If the iommu is on, everything is remapped. Or do you mean
to have dma_map_* not do a remapping ?

That's the problem again, same as before, for that to work, the
dma_map_* ops would have to do something special that depends on *both*
the source and target device.

The current DMA infrastructure doesn't have anything like that. It's a
rather fundamental issue to your design that you need to address.

The dma_ops today are architecture specific and have no way to
differenciate between normal and those special P2P DMA pages.

> Though if it does, I'd expect
> everything would still work you just wouldn't get the performance or
> traffic flow you are looking for. We've been testing with the software
> iommu which doesn't have this problem.

So first, no, it's more than "you wouldn't get the performance". On
some systems it may also just not work. Also what do you mean by "the
SW iommu doesn't have this problem" ? It catches the fact that
addresses don't point to RAM and maps differently ?

> > The problem is that the latter while seemingly easier, is also slower
> > and not supported by all platforms and architectures (for example,
> > POWER currently won't allow it, or rather only allows a store-only
> > subset of it under special circumstances).
> 
> Yes, I think situations where we have to cross host bridges will remain
> unsupported by this work for a long time. There are two many cases where
> it just doesn't work or it performs too poorly to be useful.

And the situation where you don't cross bridges is the one where you
need to also take into account the offsets.

*both* cases mean that you need somewhat to intervene at the dma_ops
level to handle this. Which means having a way to identify your special
struct pages or PFNs to allow the arch to add a special case to the
dma_ops.

> > I don't fully understand how p2pmem "solves" that by creating struct
> > pages. The offset problem is one issue. But there's the iommu issue as
> > well, the driver cannot just use the normal dma_map ops.
> 
> We are not using a proper iommu and we are dealing with systems that
> have zero offset. This case is also easily supported. I expect fixing
> the iommus to not map these addresses would also be reasonably achievable.

So you are designing something that is built from scratch to only work
on a specific limited category of systems and is also incompatible with
virtualization.

This is an interesting experiement to look at I suppose, but if you
ever want this upstream I would like at least for you to develop a
strategy to support the wider case, if not an actual implementation.

Cheers,
Ben.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Benjamin Herrenschmidt]

On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote:
> Thanks, Benjamin, for the summary of some of the issues.
> 
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
> > So I assume the p2p code provides a way to address that too via special
> > dma_ops ? Or wrappers ?
> 
> Not at this time. We will probably need a way to ensure the iommus do
> not attempt to remap these addresses.

You can't. If the iommu is on, everything is remapped. Or do you mean
to have dma_map_* not do a remapping ?

That's the problem again, same as before, for that to work, the
dma_map_* ops would have to do something special that depends on *both*
the source and target device.

The current DMA infrastructure doesn't have anything like that. It's a
rather fundamental issue to your design that you need to address.

The dma_ops today are architecture specific and have no way to
differenciate between normal and those special P2P DMA pages.

> Though if it does, I'd expect
> everything would still work you just wouldn't get the performance or
> traffic flow you are looking for. We've been testing with the software
> iommu which doesn't have this problem.

So first, no, it's more than "you wouldn't get the performance". On
some systems it may also just not work. Also what do you mean by "the
SW iommu doesn't have this problem" ? It catches the fact that
addresses don't point to RAM and maps differently ?

> > The problem is that the latter while seemingly easier, is also slower
> > and not supported by all platforms and architectures (for example,
> > POWER currently won't allow it, or rather only allows a store-only
> > subset of it under special circumstances).
> 
> Yes, I think situations where we have to cross host bridges will remain
> unsupported by this work for a long time. There are two many cases where
> it just doesn't work or it performs too poorly to be useful.

And the situation where you don't cross bridges is the one where you
need to also take into account the offsets.

*both* cases mean that you need somewhat to intervene at the dma_ops
level to handle this. Which means having a way to identify your special
struct pages or PFNs to allow the arch to add a special case to the
dma_ops.

> > I don't fully understand how p2pmem "solves" that by creating struct
> > pages. The offset problem is one issue. But there's the iommu issue as
> > well, the driver cannot just use the normal dma_map ops.
> 
> We are not using a proper iommu and we are dealing with systems that
> have zero offset. This case is also easily supported. I expect fixing
> the iommus to not map these addresses would also be reasonably achievable.

So you are designing something that is built from scratch to only work
on a specific limited category of systems and is also incompatible with
virtualization.

This is an interesting experiement to look at I suppose, but if you
ever want this upstream I would like at least for you to develop a
strategy to support the wider case, if not an actual implementation.

Cheers,
Ben.

[PATCH] ARM: dts: omap4-droid4: add bluetooth

[Sebastian Reichel]

Droid 4 has wl1835 connected to the OMAP's UART4 port, which is
used for Bluetooth and most likely can also be used for controlling
the FM radio and GPS receivers.

Signed-off-by: Sebastian Reichel 
---
Hi,

Thanks to the work of Rob adding Bluetooth support for Droid 4 was
straight forward :) I did a short test scanning for available devices
using bluetoothctl. For that I had to rebind the bluetooth device,
since it has been initialized before rootfs/firmware was available
(builtin driver):

echo serial0-0 > /sys/bus/serial/drivers/hci-ti/unbind
echo serial0-0 > /sys/bus/serial/drivers/hci-ti/bind

According to my research the FM module should be functional on
Droid 4 and the wl1835's GPS is also used. Rob, do you have a
plans for supporting the extra resources?

-- Sebastian
---
 arch/arm/boot/dts/omap4-droid4-xt894.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index e0fdfe6cc78c..2495faf79a43 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -395,6 +395,15 @@
>;
};
 
+   uart4_pins: pinmux_uart4_pins {
+   pinctrl-single,pins = <
+   OMAP4_IOPAD(0x15c, PIN_INPUT | MUX_MODE0)   /* 
uart4_rx */
+   OMAP4_IOPAD(0x15e, PIN_OUTPUT | MUX_MODE0)  /* 
uart4_tx */
+   OMAP4_IOPAD(0x110, PIN_INPUT_PULLUP | MUX_MODE5)/* 
uart4_cts */
+   OMAP4_IOPAD(0x112, PIN_OUTPUT_PULLUP | MUX_MODE5)   /* 
uart4_rts */
+   >;
+   };
+
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins = <
OMAP4_IOPAD(0x0f6, PIN_INPUT | MUX_MODE0)   /* 
abe_mcbsp2_clkx */
@@ -429,6 +438,17 @@
   _pmx_core 0x17c>;
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   bluetooth {
+   compatible = "ti,wl1835-st";
+   enable-gpios = < 14 GPIO_ACTIVE_HIGH>; /* gpio 174 */
+   max-speed = <3686400>;
+   };
+};
+
  {
phys = <_phy>;
 };
-- 
2.11.0

[PATCH] ARM: dts: omap4-droid4: add bluetooth

[Sebastian Reichel]

Droid 4 has wl1835 connected to the OMAP's UART4 port, which is
used for Bluetooth and most likely can also be used for controlling
the FM radio and GPS receivers.

Signed-off-by: Sebastian Reichel 
---
Hi,

Thanks to the work of Rob adding Bluetooth support for Droid 4 was
straight forward :) I did a short test scanning for available devices
using bluetoothctl. For that I had to rebind the bluetooth device,
since it has been initialized before rootfs/firmware was available
(builtin driver):

echo serial0-0 > /sys/bus/serial/drivers/hci-ti/unbind
echo serial0-0 > /sys/bus/serial/drivers/hci-ti/bind

According to my research the FM module should be functional on
Droid 4 and the wl1835's GPS is also used. Rob, do you have a
plans for supporting the extra resources?

-- Sebastian
---
 arch/arm/boot/dts/omap4-droid4-xt894.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index e0fdfe6cc78c..2495faf79a43 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -395,6 +395,15 @@
>;
};
 
+   uart4_pins: pinmux_uart4_pins {
+   pinctrl-single,pins = <
+   OMAP4_IOPAD(0x15c, PIN_INPUT | MUX_MODE0)   /* 
uart4_rx */
+   OMAP4_IOPAD(0x15e, PIN_OUTPUT | MUX_MODE0)  /* 
uart4_tx */
+   OMAP4_IOPAD(0x110, PIN_INPUT_PULLUP | MUX_MODE5)/* 
uart4_cts */
+   OMAP4_IOPAD(0x112, PIN_OUTPUT_PULLUP | MUX_MODE5)   /* 
uart4_rts */
+   >;
+   };
+
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins = <
OMAP4_IOPAD(0x0f6, PIN_INPUT | MUX_MODE0)   /* 
abe_mcbsp2_clkx */
@@ -429,6 +438,17 @@
   _pmx_core 0x17c>;
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   bluetooth {
+   compatible = "ti,wl1835-st";
+   enable-gpios = < 14 GPIO_ACTIVE_HIGH>; /* gpio 174 */
+   max-speed = <3686400>;
+   };
+};
+
  {
phys = <_phy>;
 };
-- 
2.11.0

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Dan Williams]

On Sat, Apr 15, 2017 at 10:41 AM, Logan Gunthorpe  wrote:
> Thanks, Benjamin, for the summary of some of the issues.
>
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
>> So I assume the p2p code provides a way to address that too via special
>> dma_ops ? Or wrappers ?
>
> Not at this time. We will probably need a way to ensure the iommus do
> not attempt to remap these addresses. Though if it does, I'd expect
> everything would still work you just wouldn't get the performance or
> traffic flow you are looking for. We've been testing with the software
> iommu which doesn't have this problem.
>
>> The problem is that the latter while seemingly easier, is also slower
>> and not supported by all platforms and architectures (for example,
>> POWER currently won't allow it, or rather only allows a store-only
>> subset of it under special circumstances).
>
> Yes, I think situations where we have to cross host bridges will remain
> unsupported by this work for a long time. There are two many cases where
> it just doesn't work or it performs too poorly to be useful.
>
>> I don't fully understand how p2pmem "solves" that by creating struct
>> pages. The offset problem is one issue. But there's the iommu issue as
>> well, the driver cannot just use the normal dma_map ops.
>
> We are not using a proper iommu and we are dealing with systems that
> have zero offset. This case is also easily supported. I expect fixing
> the iommus to not map these addresses would also be reasonably achievable.

I'm wondering, since this is limited to support behind a single
switch, if you could have a software-iommu hanging off that switch
device object that knows how to catch and translate the non-zero
offset bus address case. We have something like this with VMD driver,
and I toyed with a soft pci bridge when trying to support AHCI+NVME
bar remapping. When the dma api looks up the iommu for its device it
hits this soft-iommu and that driver checks if the page is host memory
or device memory to do the dma translation. You wouldn't need a bit in
struct page, just a lookup to the hosting struct dev_pagemap in the
is_zone_device_page() case and that can point you to p2p details.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Dan Williams]

On Sat, Apr 15, 2017 at 10:41 AM, Logan Gunthorpe  wrote:
> Thanks, Benjamin, for the summary of some of the issues.
>
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
>> So I assume the p2p code provides a way to address that too via special
>> dma_ops ? Or wrappers ?
>
> Not at this time. We will probably need a way to ensure the iommus do
> not attempt to remap these addresses. Though if it does, I'd expect
> everything would still work you just wouldn't get the performance or
> traffic flow you are looking for. We've been testing with the software
> iommu which doesn't have this problem.
>
>> The problem is that the latter while seemingly easier, is also slower
>> and not supported by all platforms and architectures (for example,
>> POWER currently won't allow it, or rather only allows a store-only
>> subset of it under special circumstances).
>
> Yes, I think situations where we have to cross host bridges will remain
> unsupported by this work for a long time. There are two many cases where
> it just doesn't work or it performs too poorly to be useful.
>
>> I don't fully understand how p2pmem "solves" that by creating struct
>> pages. The offset problem is one issue. But there's the iommu issue as
>> well, the driver cannot just use the normal dma_map ops.
>
> We are not using a proper iommu and we are dealing with systems that
> have zero offset. This case is also easily supported. I expect fixing
> the iommus to not map these addresses would also be reasonably achievable.

I'm wondering, since this is limited to support behind a single
switch, if you could have a software-iommu hanging off that switch
device object that knows how to catch and translate the non-zero
offset bus address case. We have something like this with VMD driver,
and I toyed with a soft pci bridge when trying to support AHCI+NVME
bar remapping. When the dma api looks up the iommu for its device it
hits this soft-iommu and that driver checks if the page is host memory
or device memory to do the dma translation. You wouldn't need a bit in
struct page, just a lookup to the hosting struct dev_pagemap in the
is_zone_device_page() case and that can point you to p2p details.

Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

[Andreas Hartmann]

Hello!

Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
CONFIG_VMAP_STACK is disabled.

I would be glad if it would be fixed.


Thanks,
kind regards,
Andreas


Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3 
using ehci-pci
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device found, 
idVendor=0cf2, idProduct=6250
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=4
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Product: UB6250   
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash  
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801
Apr 15 17:58:54 notebook2 mtp-probe[2134]: checking bus 1, device 3: 
"/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Apr 15 17:58:54 notebook2 mtp-probe[2134]: bus: 1, device: 3 was not an MTP 
device
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver 
usb-storage
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver uas
Apr 15 17:58:55 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage 
device detected
Apr 15 17:58:55 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0
Apr 15 17:58:55 notebook2 kernel: [ cut here ]
Apr 15 17:58:55 notebook2 kernel: WARNING: CPU: 2 PID: 2133 at 
../drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel: transfer buffer not dma capable
Apr 15 17:58:55 notebook2 kernel: Modules linked in: ums_eneub6250(+) uas 
usb_storage fuse binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss msi_wmi iTCO_wdt iTCO_vendor_support snd_pcm wmi snd_seq battery ac 
msi_laptop sparse_keymap rfkill joydev snd_seq_device snd_timer r8169 mii 
snd_mixer_oss intel_powerclamp coretemp kvm_intel snd mei_me mei kvm i2c_i801 
lpc_ich soundcore intel_ips shpchp mfd_core i2c_smbus fjes acpi_cpufreq tpm_tis 
pcspkr thermal tpm_tis_core tpm irqbypass fan dm_crypt crc32c_intel serio_raw 
sr_mod cdrom ehci_pci i915 ehci_hcd i2c_algo_bit usbcore drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm video button dm_mirror 
dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc 
scsi_dh_alua
Apr 15 17:58:55 notebook2 kernel: CPU: 2 PID: 2133 Comm: systemd-udevd Not 
tainted 4.9.21-1-default #1
Apr 15 17:58:55 notebook2 kernel: Hardware name: Micro-Star International 
CR620/CR620, BIOS E1681IMS VER.10C 04/12/2011
Apr 15 17:58:55 notebook2 kernel:  baf681b477f0 af3c854a 
baf681b47840 
Apr 15 17:58:55 notebook2 kernel:  baf681b47830 af085c71 
0633af0bd0de 8d35b2844e40
Apr 15 17:58:55 notebook2 kernel:   0200 
0002 8d360fafd800
Apr 15 17:58:55 notebook2 kernel: Call Trace:
Apr 15 17:58:55 notebook2 kernel:  [] dump_stack+0x63/0x89
Apr 15 17:58:55 notebook2 kernel:  [] __warn+0xd1/0xf0
Apr 15 17:58:55 notebook2 kernel:  [] 
warn_slowpath_fmt+0x4f/0x60
Apr 15 17:58:55 notebook2 kernel:  [] ? 
put_prev_entity+0x48/0x720
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 
finish_task_switch+0x78/0x1e0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_submit_urb+0x1c9/0xb30 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? schedule+0x3d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] ? 
schedule_timeout+0x220/0x3c0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb.part.6+0x295/0x550 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb+0x34/0x70 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_msg_common+0x9d/0x120 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_buf+0x56/0xa0 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_sg+0x4e/0x60 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_send_scsi_cmd+0x97/0x160 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_get_card_type.constprop.19+0x5b/0x60 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_probe+0x8f/0x110 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_probe_interface+0x157/0x2f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_probe_device+0x227/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
__driver_attach+0xdd/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] ? 
driver_probe_device+0x440/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_for_each_dev+0x5d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] driver_attach+0x1e/0x20
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_add_driver+0x45/0x270
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_register+0x60/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_register_driver+0x82/0x150 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 0xc03b9000
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_driver_init+0x38/0x1000 

Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

[Andreas Hartmann]

Hello!

Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
CONFIG_VMAP_STACK is disabled.

I would be glad if it would be fixed.


Thanks,
kind regards,
Andreas


Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3 
using ehci-pci
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device found, 
idVendor=0cf2, idProduct=6250
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=4
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Product: UB6250   
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash  
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801
Apr 15 17:58:54 notebook2 mtp-probe[2134]: checking bus 1, device 3: 
"/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Apr 15 17:58:54 notebook2 mtp-probe[2134]: bus: 1, device: 3 was not an MTP 
device
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver 
usb-storage
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver uas
Apr 15 17:58:55 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage 
device detected
Apr 15 17:58:55 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0
Apr 15 17:58:55 notebook2 kernel: [ cut here ]
Apr 15 17:58:55 notebook2 kernel: WARNING: CPU: 2 PID: 2133 at 
../drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel: transfer buffer not dma capable
Apr 15 17:58:55 notebook2 kernel: Modules linked in: ums_eneub6250(+) uas 
usb_storage fuse binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss msi_wmi iTCO_wdt iTCO_vendor_support snd_pcm wmi snd_seq battery ac 
msi_laptop sparse_keymap rfkill joydev snd_seq_device snd_timer r8169 mii 
snd_mixer_oss intel_powerclamp coretemp kvm_intel snd mei_me mei kvm i2c_i801 
lpc_ich soundcore intel_ips shpchp mfd_core i2c_smbus fjes acpi_cpufreq tpm_tis 
pcspkr thermal tpm_tis_core tpm irqbypass fan dm_crypt crc32c_intel serio_raw 
sr_mod cdrom ehci_pci i915 ehci_hcd i2c_algo_bit usbcore drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm video button dm_mirror 
dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc 
scsi_dh_alua
Apr 15 17:58:55 notebook2 kernel: CPU: 2 PID: 2133 Comm: systemd-udevd Not 
tainted 4.9.21-1-default #1
Apr 15 17:58:55 notebook2 kernel: Hardware name: Micro-Star International 
CR620/CR620, BIOS E1681IMS VER.10C 04/12/2011
Apr 15 17:58:55 notebook2 kernel:  baf681b477f0 af3c854a 
baf681b47840 
Apr 15 17:58:55 notebook2 kernel:  baf681b47830 af085c71 
0633af0bd0de 8d35b2844e40
Apr 15 17:58:55 notebook2 kernel:   0200 
0002 8d360fafd800
Apr 15 17:58:55 notebook2 kernel: Call Trace:
Apr 15 17:58:55 notebook2 kernel:  [] dump_stack+0x63/0x89
Apr 15 17:58:55 notebook2 kernel:  [] __warn+0xd1/0xf0
Apr 15 17:58:55 notebook2 kernel:  [] 
warn_slowpath_fmt+0x4f/0x60
Apr 15 17:58:55 notebook2 kernel:  [] ? 
put_prev_entity+0x48/0x720
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 
finish_task_switch+0x78/0x1e0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_submit_urb+0x1c9/0xb30 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? schedule+0x3d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] ? 
schedule_timeout+0x220/0x3c0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb.part.6+0x295/0x550 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb+0x34/0x70 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_msg_common+0x9d/0x120 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_buf+0x56/0xa0 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_sg+0x4e/0x60 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_send_scsi_cmd+0x97/0x160 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_get_card_type.constprop.19+0x5b/0x60 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_probe+0x8f/0x110 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_probe_interface+0x157/0x2f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_probe_device+0x227/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
__driver_attach+0xdd/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] ? 
driver_probe_device+0x440/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_for_each_dev+0x5d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] driver_attach+0x1e/0x20
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_add_driver+0x45/0x270
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_register+0x60/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_register_driver+0x82/0x150 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 0xc03b9000
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_driver_init+0x38/0x1000 

[PATCH] Bluetooth: hci_ll: Fix NULL pointer deref on FW upload failure

[Sebastian Reichel]

Avoid NULL pointer dereference occurring due to freeing
skb containing an error pointer. It can easily be triggered
by using the driver with broken uart (i.e. due to misconfigured
pinmuxing).

Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver 
support")
Signed-off-by: Sebastian Reichel 
---
 drivers/bluetooth/hci_ll.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 485e8eb04542..adc444f309a3 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -537,8 +537,7 @@ static int read_local_version(struct hci_dev *hdev)
if (IS_ERR(skb)) {
bt_dev_err(hdev, "Reading TI version information failed (%ld)",
   PTR_ERR(skb));
-   err = PTR_ERR(skb);
-   goto out;
+   return PTR_ERR(skb);
}
if (skb->len != sizeof(*ver)) {
err = -EILSEQ;
-- 
2.11.0

[PATCH] Bluetooth: hci_ll: Fix NULL pointer deref on FW upload failure

[Sebastian Reichel]

Avoid NULL pointer dereference occurring due to freeing
skb containing an error pointer. It can easily be triggered
by using the driver with broken uart (i.e. due to misconfigured
pinmuxing).

Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver 
support")
Signed-off-by: Sebastian Reichel 
---
 drivers/bluetooth/hci_ll.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 485e8eb04542..adc444f309a3 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -537,8 +537,7 @@ static int read_local_version(struct hci_dev *hdev)
if (IS_ERR(skb)) {
bt_dev_err(hdev, "Reading TI version information failed (%ld)",
   PTR_ERR(skb));
-   err = PTR_ERR(skb);
-   goto out;
+   return PTR_ERR(skb);
}
if (skb->len != sizeof(*ver)) {
err = -EILSEQ;
-- 
2.11.0

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Wed 2017-04-12 17:08:35, Frederic Weisbecker wrote:
> On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote:
> > > > > > > ...1d.7: PCI fixup... pass 2
> > > > > > > ...1d.7: PCI fixup... pass 3
> > > > > > > ...1d.7: PCI fixup... pass 3 done
> > > > > > > 
> > > > > > > ...followed by hang. So yes, it looks USB related.
> > > > > > > 
> > > > > > > (Sometimes it hangs with some kind backtrace involving secondary 
> > > > > > > CPU
> > > > > > > startup, unfortunately useful info is off screen at that point).
> > > > > > 
> > > > > > Forgot to say, 1d.7 is EHCI controller.
> > > > > > 
> > > > > > 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> > > > > > Controller (rev 01)
> > > > > 
> > > > > Ok, I should have access soon to a EeePc 1015CX (which seem to have 
> > > > > this controller).
> > > > > I hope I'll be able to reproduce the issue there. If not, I'm sorry 
> > > > > but I'll have to
> > > > > burden you again :-)
> > > > 
> > > > Go through more mails. It is only reproducible after cold boot. .. so
> > > > I doubt it will be easy to reproduce on another machine.
> > > > 
> > > > Now... I do have serial port, and I even might have serial cable
> > > > somewhere, but Giving how sensitive it is, it is probably going to
> > > > go away with console on ttyS...
> > > 
> > > I also tried on an eeepc (which has ICH7/NM10 as well), with your config.
> > > I even plugged a usb keyboard but even then I have been unable to
> > > reproduce either :-(
> > 
> > Ok, give me some time. I'm no longer using the affected machine, so no
> > promises.
> 
> Actually someone reported me a very similar issue than yours lately. It's 
> probably
> the same. And I have a potential fix.

Got the machine back to work -- I guess it will be useful for distcc.

And yes, you seem to have right fix :-). 

Tested-by: Pavel Machek 

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Wed 2017-04-12 17:08:35, Frederic Weisbecker wrote:
> On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote:
> > > > > > > ...1d.7: PCI fixup... pass 2
> > > > > > > ...1d.7: PCI fixup... pass 3
> > > > > > > ...1d.7: PCI fixup... pass 3 done
> > > > > > > 
> > > > > > > ...followed by hang. So yes, it looks USB related.
> > > > > > > 
> > > > > > > (Sometimes it hangs with some kind backtrace involving secondary 
> > > > > > > CPU
> > > > > > > startup, unfortunately useful info is off screen at that point).
> > > > > > 
> > > > > > Forgot to say, 1d.7 is EHCI controller.
> > > > > > 
> > > > > > 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> > > > > > Controller (rev 01)
> > > > > 
> > > > > Ok, I should have access soon to a EeePc 1015CX (which seem to have 
> > > > > this controller).
> > > > > I hope I'll be able to reproduce the issue there. If not, I'm sorry 
> > > > > but I'll have to
> > > > > burden you again :-)
> > > > 
> > > > Go through more mails. It is only reproducible after cold boot. .. so
> > > > I doubt it will be easy to reproduce on another machine.
> > > > 
> > > > Now... I do have serial port, and I even might have serial cable
> > > > somewhere, but Giving how sensitive it is, it is probably going to
> > > > go away with console on ttyS...
> > > 
> > > I also tried on an eeepc (which has ICH7/NM10 as well), with your config.
> > > I even plugged a usb keyboard but even then I have been unable to
> > > reproduce either :-(
> > 
> > Ok, give me some time. I'm no longer using the affected machine, so no
> > promises.
> 
> Actually someone reported me a very similar issue than yours lately. It's 
> probably
> the same. And I have a potential fix.

Got the machine back to work -- I guess it will be useful for distcc.

And yes, you seem to have right fix :-). 

Tested-by: Pavel Machek 

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[GIT PULL] ftrace: Fix removing of second function probe

[Steven Rostedt]

Linus,

While rewriting the function probe code, I stumbled over a long standing
bug. This bug has been there since function tracing was added way back
when. But my new development depends on this bug being fixed, and it
should be fixed regardless as it causes ftrace to disable itself when
triggered, and a reboot is required to enable it again.

The bug is that the function probe does not disable itself properly
if there's another probe of its type still enabled. For example:

 # cd /sys/kernel/debug/tracing
 # echo schedule:traceoff > set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter
 # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter

The above registers two traceoff probes (one for schedule and one for
do_IRQ, and then removes do_IRQ. But since there still exists one for
schedule, it is not done properly. When adding do_IRQ back, the breakage
in the accounting is noticed by the ftrace self tests, and it causes
a warning and disables ftrace.


Please pull the latest trace-v4.11-rc5-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.11-rc5-2

Tag SHA1: fe8a1251ab0940f3807c2cc1228906681b3880da
Head SHA1: 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae


Steven Rostedt (VMware) (1):
  ftrace: Fix removing of second function probe


 kernel/trace/ftrace.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)
---
commit 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae
Author: Steven Rostedt (VMware) 
Date:   Fri Apr 14 17:45:45 2017 -0400

ftrace: Fix removing of second function probe

When two function probes are added to set_ftrace_filter, and then one of
them is removed, the update to the function locations is not performed, and
the record keeping of the function states are corrupted, and causes an
ftrace_bug() to occur.

This is easily reproducable by adding two probes, removing one, and then
adding it back again.

 # cd /sys/kernel/debug/tracing
 # echo schedule:traceoff > set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter
 # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter

Causes:
 [ cut here ]
 WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 
ftrace_get_addr_curr+0x143/0x220
 Modules linked in: [...]
 CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 
v02.05 05/07/2012
 Call Trace:
  dump_stack+0x68/0x9f
  __warn+0x111/0x130
  ? trace_irq_work_interrupt+0xa0/0xa0
  warn_slowpath_null+0x1d/0x20
  ftrace_get_addr_curr+0x143/0x220
  ? __fentry__+0x10/0x10
  ftrace_replace_code+0xe3/0x4f0
  ? ftrace_int3_handler+0x90/0x90
  ? printk+0x99/0xb5
  ? 0x8100
  ftrace_modify_all_code+0x97/0x110
  arch_ftrace_update_code+0x10/0x20
  ftrace_run_update_code+0x1c/0x60
  ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
  register_ftrace_function_probe+0x4b6/0x590
  ? ftrace_startup+0x310/0x310
  ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
  ? update_stack_state+0x88/0x110
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? preempt_count_sub+0x18/0xd0
  ? mutex_lock_nested+0x104/0x800
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? __unwind_start+0x1c0/0x1c0
  ? _mutex_lock_nest_lock+0x800/0x800
  ftrace_trace_probe_callback.isra.3+0xc0/0x130
  ? func_set_flag+0xe0/0xe0
  ? __lock_acquire+0x642/0x1790
  ? __might_fault+0x1e/0x20
  ? trace_get_user+0x398/0x470
  ? strcmp+0x35/0x60
  ftrace_trace_onoff_callback+0x48/0x70
  ftrace_regex_write.isra.43.part.44+0x251/0x320
  ? match_records+0x420/0x420
  ftrace_filter_write+0x2b/0x30
  __vfs_write+0xd7/0x330
  ? do_loop_readv_writev+0x120/0x120
  ? locks_remove_posix+0x90/0x2f0
  ? do_lock_file_wait+0x160/0x160
  ? __lock_is_held+0x93/0x100
  ? rcu_read_lock_sched_held+0x5c/0xb0
  ? preempt_count_sub+0x18/0xd0
  ? __sb_start_write+0x10a/0x230
  ? vfs_write+0x222/0x240
  vfs_write+0xef/0x240
  SyS_write+0xab/0x130
  ? SyS_read+0x130/0x130
  ? trace_hardirqs_on_caller+0x182/0x280
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL_64_fastpath+0x18/0xad
 RIP: 0033:0x7fe61c157c30
 RSP: 002b:7ffe87890258 EFLAGS: 0246 ORIG_RAX: 0001
 RAX: ffda RBX: 8114a410 RCX: 7fe61c157c30
 RDX: 0010 RSI: 55814798f5e0 RDI: 0001
 RBP: 8800c9027f98 R08: 7fe61c422740 R09: 7fe61ca53700
 R10: 0073 R11: 0246 R12: 558147a36400
 R13: 7ffe8788f160 R14: 0024 

[GIT PULL] ftrace: Fix removing of second function probe

[Steven Rostedt]

Linus,

While rewriting the function probe code, I stumbled over a long standing
bug. This bug has been there since function tracing was added way back
when. But my new development depends on this bug being fixed, and it
should be fixed regardless as it causes ftrace to disable itself when
triggered, and a reboot is required to enable it again.

The bug is that the function probe does not disable itself properly
if there's another probe of its type still enabled. For example:

 # cd /sys/kernel/debug/tracing
 # echo schedule:traceoff > set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter
 # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter

The above registers two traceoff probes (one for schedule and one for
do_IRQ, and then removes do_IRQ. But since there still exists one for
schedule, it is not done properly. When adding do_IRQ back, the breakage
in the accounting is noticed by the ftrace self tests, and it causes
a warning and disables ftrace.


Please pull the latest trace-v4.11-rc5-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.11-rc5-2

Tag SHA1: fe8a1251ab0940f3807c2cc1228906681b3880da
Head SHA1: 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae


Steven Rostedt (VMware) (1):
  ftrace: Fix removing of second function probe


 kernel/trace/ftrace.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)
---
commit 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae
Author: Steven Rostedt (VMware) 
Date:   Fri Apr 14 17:45:45 2017 -0400

ftrace: Fix removing of second function probe

When two function probes are added to set_ftrace_filter, and then one of
them is removed, the update to the function locations is not performed, and
the record keeping of the function states are corrupted, and causes an
ftrace_bug() to occur.

This is easily reproducable by adding two probes, removing one, and then
adding it back again.

 # cd /sys/kernel/debug/tracing
 # echo schedule:traceoff > set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter
 # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
 # echo do_IRQ:traceoff > set_ftrace_filter

Causes:
 [ cut here ]
 WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 
ftrace_get_addr_curr+0x143/0x220
 Modules linked in: [...]
 CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 
v02.05 05/07/2012
 Call Trace:
  dump_stack+0x68/0x9f
  __warn+0x111/0x130
  ? trace_irq_work_interrupt+0xa0/0xa0
  warn_slowpath_null+0x1d/0x20
  ftrace_get_addr_curr+0x143/0x220
  ? __fentry__+0x10/0x10
  ftrace_replace_code+0xe3/0x4f0
  ? ftrace_int3_handler+0x90/0x90
  ? printk+0x99/0xb5
  ? 0x8100
  ftrace_modify_all_code+0x97/0x110
  arch_ftrace_update_code+0x10/0x20
  ftrace_run_update_code+0x1c/0x60
  ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
  register_ftrace_function_probe+0x4b6/0x590
  ? ftrace_startup+0x310/0x310
  ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
  ? update_stack_state+0x88/0x110
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? preempt_count_sub+0x18/0xd0
  ? mutex_lock_nested+0x104/0x800
  ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
  ? __unwind_start+0x1c0/0x1c0
  ? _mutex_lock_nest_lock+0x800/0x800
  ftrace_trace_probe_callback.isra.3+0xc0/0x130
  ? func_set_flag+0xe0/0xe0
  ? __lock_acquire+0x642/0x1790
  ? __might_fault+0x1e/0x20
  ? trace_get_user+0x398/0x470
  ? strcmp+0x35/0x60
  ftrace_trace_onoff_callback+0x48/0x70
  ftrace_regex_write.isra.43.part.44+0x251/0x320
  ? match_records+0x420/0x420
  ftrace_filter_write+0x2b/0x30
  __vfs_write+0xd7/0x330
  ? do_loop_readv_writev+0x120/0x120
  ? locks_remove_posix+0x90/0x2f0
  ? do_lock_file_wait+0x160/0x160
  ? __lock_is_held+0x93/0x100
  ? rcu_read_lock_sched_held+0x5c/0xb0
  ? preempt_count_sub+0x18/0xd0
  ? __sb_start_write+0x10a/0x230
  ? vfs_write+0x222/0x240
  vfs_write+0xef/0x240
  SyS_write+0xab/0x130
  ? SyS_read+0x130/0x130
  ? trace_hardirqs_on_caller+0x182/0x280
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL_64_fastpath+0x18/0xad
 RIP: 0033:0x7fe61c157c30
 RSP: 002b:7ffe87890258 EFLAGS: 0246 ORIG_RAX: 0001
 RAX: ffda RBX: 8114a410 RCX: 7fe61c157c30
 RDX: 0010 RSI: 55814798f5e0 RDI: 0001
 RBP: 8800c9027f98 R08: 7fe61c422740 R09: 7fe61ca53700
 R10: 0073 R11: 0246 R12: 558147a36400
 R13: 7ffe8788f160 R14: 0024 R15: 7ffe8788f15c
   

Re: 4.10.9 nok with realtek wlan, atom

[Larry Finger]

On 04/14/2017 03:26 PM, rupert THURNER wrote:

On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger  wrote:

On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:


[+cc rtl8192ce folks in case they've seen this]

On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:


hi,

not technical expert enough, i just wanted to give a short user
feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
hotspot is possible then drops, or connecting to wlan fails
alltogether.



Thanks very much for your report, and sorry for the inconvenience.

v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.

But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
need to figure out why and make sure we fix the v4.9 stable series.

I can't tell yet whether this is PCI-related or not.  If it is,
4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
appeared in v4.9.6, and there is a known issue with that.  The issue
should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
the first thing to do would be to test v4.9.9.

If it's not fixed in v4.9.9, can you share the complete dmesg log
(output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
known working version) and v4.9.6 (first known broken version)?  On
v4.9.6, collect the dmesg output after the failure occurs.


24: PCI 300.0: 0282 WLAN controller
  [Created at pci.366]
  Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
  Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
  Revision: 0x01
  Driver: "rtl8192ce"
  Driver Modules: "rtl8192ce"
  Device File: wlp3s0
  Features: WLAN



It would be helpful if someone were to bisect this issue. The only issue
that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
backported to 4.9.

The above issue is one that could not be reproduced on my hardware, thus it
took Jurij Smakov to find the fix. Without his bisection of the problem, who
knows how long it would have taken to find my edit mistake.


larry, using the newest kernel 4.10.8 the network connection dropps
again irregular.

# dmesg
[0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
2017
[   11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
[   11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[   11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   11.978945] rtlwifi: rtlwifi: wireless switch is on

# lspci -vv
Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter
Kernel driver in use: rtl8192ce


Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?

Larry

Re: 4.10.9 nok with realtek wlan, atom

[Larry Finger]

On 04/14/2017 03:26 PM, rupert THURNER wrote:

On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger  wrote:

On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:


[+cc rtl8192ce folks in case they've seen this]

On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:


hi,

not technical expert enough, i just wanted to give a short user
feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
hotspot is possible then drops, or connecting to wlan fails
alltogether.



Thanks very much for your report, and sorry for the inconvenience.

v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.

But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
need to figure out why and make sure we fix the v4.9 stable series.

I can't tell yet whether this is PCI-related or not.  If it is,
4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
appeared in v4.9.6, and there is a known issue with that.  The issue
should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
the first thing to do would be to test v4.9.9.

If it's not fixed in v4.9.9, can you share the complete dmesg log
(output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
known working version) and v4.9.6 (first known broken version)?  On
v4.9.6, collect the dmesg output after the failure occurs.


24: PCI 300.0: 0282 WLAN controller
  [Created at pci.366]
  Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
  Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
  Revision: 0x01
  Driver: "rtl8192ce"
  Driver Modules: "rtl8192ce"
  Device File: wlp3s0
  Features: WLAN



It would be helpful if someone were to bisect this issue. The only issue
that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
backported to 4.9.

The above issue is one that could not be reproduced on my hardware, thus it
took Jurij Smakov to find the fix. Without his bisection of the problem, who
knows how long it would have taken to find my edit mistake.


larry, using the newest kernel 4.10.8 the network connection dropps
again irregular.

# dmesg
[0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
2017
[   11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
[   11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[   11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   11.978945] rtlwifi: rtlwifi: wireless switch is on

# lspci -vv
Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter
Kernel driver in use: rtl8192ce


Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?

Larry

[PATCH 1/3] mtd: sharpsl: add sharpslpart MTD partition parser

[Andrea Adami]

The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.

The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.

The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )

In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.

Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.

The Parameter Area in the first (boot) partition extends from 0x0004 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x0006: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model   16k
...

The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.

There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.

The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.

Signed-off-by: Andrea Adami 
---
 drivers/mtd/Kconfig   |   8 ++
 drivers/mtd/Makefile  |   2 +
 drivers/mtd/sharpsl_ftl.c | 309 ++
 drivers/mtd/sharpsl_ftl.h |  34 +
 drivers/mtd/sharpslpart.c | 142 +
 5 files changed, 495 insertions(+)
 create mode 100644 drivers/mtd/sharpsl_ftl.c
 create mode 100644 drivers/mtd/sharpsl_ftl.h
 create mode 100644 drivers/mtd/sharpslpart.c

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index e83a279..5c96127 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -155,6 +155,14 @@ config MTD_BCM47XX_PARTS
  This provides partitions parser for devices based on BCM47xx
  boards.
 
+config MTD_SHARPSL_PARTS
+   tristate "Sharp SL Series NAND flash partition parser"
+   depends on MTD_NAND_SHARPSL || MTD_NAND_TMIO
+   help
+ This provides the read-only FTL logic necessary to read the partition
+ table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
+ partition parser using this code.
+
 comment "User Modules And Translation Layers"
 
 #
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1..89f707b 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_MTD_AFS_PARTS)   += afs.o
 obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-$(CONFIG_MTD_SHARPSL_PARTS)+= sharpsl-part.o
+sharpsl-part-objs := sharpsl_ftl.o sharpslpart.o
 
 # 'Users' - code which presents functionality to userspace.
 obj-$(CONFIG_MTD_BLKDEVS)  += mtd_blkdevs.o
diff --git a/drivers/mtd/sharpsl_ftl.c b/drivers/mtd/sharpsl_ftl.c
new file mode 100644
index 000..d8ebefe
--- /dev/null
+++ b/drivers/mtd/sharpsl_ftl.c
@@ -0,0 +1,309 @@
+/*
+ * MTD method for NAND accessing via logical address (SHARP FTL)
+ *
+ * Copyright (C) 2017 Andrea Adami 
+ *
+ * Based on 2.4 sources: drivers/mtd/nand/sharp_sl_logical.c
+ * Copyright (C) 2002  SHARP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sharpsl_ftl.h"
+
+/* oob structure */
+#define NAND_NOOB_LOGADDR_00   8
+#define NAND_NOOB_LOGADDR_01   9
+#define NAND_NOOB_LOGADDR_10   10
+#define NAND_NOOB_LOGADDR_11   11
+#define NAND_NOOB_LOGADDR_20   12
+#define NAND_NOOB_LOGADDR_21   13
+
+/* Logical Table */
+struct mtd_logical {
+   u32 size;   

[PATCH 1/3] mtd: sharpsl: add sharpslpart MTD partition parser

[Andrea Adami]

The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.

The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.

The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )

In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.

Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.

The Parameter Area in the first (boot) partition extends from 0x0004 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x0006: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model   16k
...

The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.

There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.

The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.

Signed-off-by: Andrea Adami 
---
 drivers/mtd/Kconfig   |   8 ++
 drivers/mtd/Makefile  |   2 +
 drivers/mtd/sharpsl_ftl.c | 309 ++
 drivers/mtd/sharpsl_ftl.h |  34 +
 drivers/mtd/sharpslpart.c | 142 +
 5 files changed, 495 insertions(+)
 create mode 100644 drivers/mtd/sharpsl_ftl.c
 create mode 100644 drivers/mtd/sharpsl_ftl.h
 create mode 100644 drivers/mtd/sharpslpart.c

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index e83a279..5c96127 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -155,6 +155,14 @@ config MTD_BCM47XX_PARTS
  This provides partitions parser for devices based on BCM47xx
  boards.
 
+config MTD_SHARPSL_PARTS
+   tristate "Sharp SL Series NAND flash partition parser"
+   depends on MTD_NAND_SHARPSL || MTD_NAND_TMIO
+   help
+ This provides the read-only FTL logic necessary to read the partition
+ table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
+ partition parser using this code.
+
 comment "User Modules And Translation Layers"
 
 #
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1..89f707b 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_MTD_AFS_PARTS)   += afs.o
 obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-$(CONFIG_MTD_SHARPSL_PARTS)+= sharpsl-part.o
+sharpsl-part-objs := sharpsl_ftl.o sharpslpart.o
 
 # 'Users' - code which presents functionality to userspace.
 obj-$(CONFIG_MTD_BLKDEVS)  += mtd_blkdevs.o
diff --git a/drivers/mtd/sharpsl_ftl.c b/drivers/mtd/sharpsl_ftl.c
new file mode 100644
index 000..d8ebefe
--- /dev/null
+++ b/drivers/mtd/sharpsl_ftl.c
@@ -0,0 +1,309 @@
+/*
+ * MTD method for NAND accessing via logical address (SHARP FTL)
+ *
+ * Copyright (C) 2017 Andrea Adami 
+ *
+ * Based on 2.4 sources: drivers/mtd/nand/sharp_sl_logical.c
+ * Copyright (C) 2002  SHARP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sharpsl_ftl.h"
+
+/* oob structure */
+#define NAND_NOOB_LOGADDR_00   8
+#define NAND_NOOB_LOGADDR_01   9
+#define NAND_NOOB_LOGADDR_10   10
+#define NAND_NOOB_LOGADDR_11   11
+#define NAND_NOOB_LOGADDR_20   12
+#define NAND_NOOB_LOGADDR_21   13
+
+/* Logical Table */
+struct mtd_logical {
+   u32 size;   /* size of the handled partition */
+   

[PATCH 0/3] mtd: sharpslpart partition parser

[Andrea Adami]

This patchset introduces a simple partition parser for the Sharp SL
Series PXA handhelds. More details in the commit text.

I have set in cc the ARM PXA maintainers because this is the MTD part of
a planned wider patchset cleaning the Zaurus board files.

Andrea Adami (3):
  mtd: sharpsl: add sharpslpart MTD partition parser
  mtd: nand: sharpsl.c: prefer sharpslpart MTD partition parser
  mtd: nand: tmio_nand.c: prefer sharpslpart MTD partition parser

 drivers/mtd/Kconfig  |   8 ++
 drivers/mtd/Makefile |   2 +
 drivers/mtd/nand/sharpsl.c   |   4 +-
 drivers/mtd/nand/tmio_nand.c |   4 +-
 drivers/mtd/sharpsl_ftl.c| 309 +++
 drivers/mtd/sharpsl_ftl.h|  34 +
 drivers/mtd/sharpslpart.c| 142 
 7 files changed, 501 insertions(+), 2 deletions(-)
 create mode 100644 drivers/mtd/sharpsl_ftl.c
 create mode 100644 drivers/mtd/sharpsl_ftl.h
 create mode 100644 drivers/mtd/sharpslpart.c

-- 
2.7.4

[PATCH 2/3] mtd: nand: sharpsl.c: prefer sharpslpart MTD partition parser

[Andrea Adami]

This is the specific parser for Sharp SL Series (Zaurus).

Signed-off-by: Andrea Adami 
---
 drivers/mtd/nand/sharpsl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/sharpsl.c b/drivers/mtd/nand/sharpsl.c
index 064ca17..2d1ba0e 100644
--- a/drivers/mtd/nand/sharpsl.c
+++ b/drivers/mtd/nand/sharpsl.c
@@ -108,6 +108,8 @@ static int sharpsl_nand_calculate_ecc(struct mtd_info *mtd, 
const u_char * dat,
 /*
  * Main initialization routine
  */
+static const char * const probes[] = { "sharpslpart", NULL };
+
 static int sharpsl_nand_probe(struct platform_device *pdev)
 {
struct nand_chip *this;
@@ -183,7 +185,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
/* Register the partitions */
mtd->name = "sharpsl-nand";
 
-   err = mtd_device_parse_register(mtd, NULL, NULL,
+   err = mtd_device_parse_register(mtd, probes, NULL,
data->partitions, data->nr_partitions);
if (err)
goto err_add;
-- 
2.7.4

[PATCH 3/3] mtd: nand: tmio_nand.c: prefer sharpslpart MTD partition parser

[Andrea Adami]

This is the specific parser for Sharp SL Series (Zaurus)

Signed-off-by: Andrea Adami 
---
 drivers/mtd/nand/tmio_nand.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/tmio_nand.c b/drivers/mtd/nand/tmio_nand.c
index fc5e773..f3612ac 100644
--- a/drivers/mtd/nand/tmio_nand.c
+++ b/drivers/mtd/nand/tmio_nand.c
@@ -357,6 +357,8 @@ static void tmio_hw_stop(struct platform_device *dev, 
struct tmio_nand *tmio)
cell->disable(dev);
 }
 
+static const char * const probes[] = { "sharpslpart", NULL };
+
 static int tmio_probe(struct platform_device *dev)
 {
struct tmio_nand_data *data = dev_get_platdata(>dev);
@@ -440,7 +442,7 @@ static int tmio_probe(struct platform_device *dev)
goto err_irq;
 
/* Register the partitions */
-   retval = mtd_device_parse_register(mtd, NULL, NULL,
+   retval = mtd_device_parse_register(mtd, probes, NULL,
   data ? data->partition : NULL,
   data ? data->num_partitions : 0);
if (!retval)
-- 
2.7.4

[PATCH 2/3] mtd: nand: sharpsl.c: prefer sharpslpart MTD partition parser

[Andrea Adami]

This is the specific parser for Sharp SL Series (Zaurus).

Signed-off-by: Andrea Adami 
---
 drivers/mtd/nand/sharpsl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/sharpsl.c b/drivers/mtd/nand/sharpsl.c
index 064ca17..2d1ba0e 100644
--- a/drivers/mtd/nand/sharpsl.c
+++ b/drivers/mtd/nand/sharpsl.c
@@ -108,6 +108,8 @@ static int sharpsl_nand_calculate_ecc(struct mtd_info *mtd, 
const u_char * dat,
 /*
  * Main initialization routine
  */
+static const char * const probes[] = { "sharpslpart", NULL };
+
 static int sharpsl_nand_probe(struct platform_device *pdev)
 {
struct nand_chip *this;
@@ -183,7 +185,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
/* Register the partitions */
mtd->name = "sharpsl-nand";
 
-   err = mtd_device_parse_register(mtd, NULL, NULL,
+   err = mtd_device_parse_register(mtd, probes, NULL,
data->partitions, data->nr_partitions);
if (err)
goto err_add;
-- 
2.7.4

[PATCH 3/3] mtd: nand: tmio_nand.c: prefer sharpslpart MTD partition parser

[Andrea Adami]

This is the specific parser for Sharp SL Series (Zaurus)

Signed-off-by: Andrea Adami 
---
 drivers/mtd/nand/tmio_nand.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/tmio_nand.c b/drivers/mtd/nand/tmio_nand.c
index fc5e773..f3612ac 100644
--- a/drivers/mtd/nand/tmio_nand.c
+++ b/drivers/mtd/nand/tmio_nand.c
@@ -357,6 +357,8 @@ static void tmio_hw_stop(struct platform_device *dev, 
struct tmio_nand *tmio)
cell->disable(dev);
 }
 
+static const char * const probes[] = { "sharpslpart", NULL };
+
 static int tmio_probe(struct platform_device *dev)
 {
struct tmio_nand_data *data = dev_get_platdata(>dev);
@@ -440,7 +442,7 @@ static int tmio_probe(struct platform_device *dev)
goto err_irq;
 
/* Register the partitions */
-   retval = mtd_device_parse_register(mtd, NULL, NULL,
+   retval = mtd_device_parse_register(mtd, probes, NULL,
   data ? data->partition : NULL,
   data ? data->num_partitions : 0);
if (!retval)
-- 
2.7.4

[PATCH 0/3] mtd: sharpslpart partition parser

[Andrea Adami]

This patchset introduces a simple partition parser for the Sharp SL
Series PXA handhelds. More details in the commit text.

I have set in cc the ARM PXA maintainers because this is the MTD part of
a planned wider patchset cleaning the Zaurus board files.

Andrea Adami (3):
  mtd: sharpsl: add sharpslpart MTD partition parser
  mtd: nand: sharpsl.c: prefer sharpslpart MTD partition parser
  mtd: nand: tmio_nand.c: prefer sharpslpart MTD partition parser

 drivers/mtd/Kconfig  |   8 ++
 drivers/mtd/Makefile |   2 +
 drivers/mtd/nand/sharpsl.c   |   4 +-
 drivers/mtd/nand/tmio_nand.c |   4 +-
 drivers/mtd/sharpsl_ftl.c| 309 +++
 drivers/mtd/sharpsl_ftl.h|  34 +
 drivers/mtd/sharpslpart.c| 142 
 7 files changed, 501 insertions(+), 2 deletions(-)
 create mode 100644 drivers/mtd/sharpsl_ftl.c
 create mode 100644 drivers/mtd/sharpsl_ftl.h
 create mode 100644 drivers/mtd/sharpslpart.c

-- 
2.7.4

Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"

[Mel Gorman]

On Sat, Apr 15, 2017 at 09:28:33PM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 15 Apr 2017 15:53:50 +0100
> Mel Gorman  wrote:
> 
> > This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the
> > patch worked great for userspace allocations, the fact that softirq loses
> > the per-cpu allocator caused problems. It needs to be redone taking into
> > account that a separate list is needed for hard/soft IRQs or alternatively
> > find a cheap way of detecting reentry due to an interrupt. Both are possible
> > but sufficiently tricky that it shouldn't be rushed. Jesper had one method
> > for allowing softirqs but reported that the cost was high enough that it
> > performed similarly to a plain revert. His figures for netperf TCP_STREAM
> > were as follows
> > 
> > Baseline v4.10.0  : 60316 Mbit/s
> > Current 4.11.0-rc6: 47491 Mbit/s
> > This patch: 60662 Mbit/s
> (should instead state "Jesper's patch" or "His patch")
> 

Yes, you are correct of course.

> Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied:
> 
>  This patch 60106 Mbit/s (average of 7 iteration 60 sec runs)
> 
> With these speeds I'm starting to hit the memory bandwidth of my machines.
> Thus, the 60 GBit/s measurement cannot be used to validate the
> performance impact of reverting this compared to my softirq patch, it
> only shows we fixed the regression.  (I'm suspicious as I see a higher
> contention on the page allocator lock (4% vs 1.3%) with this patch and
> still same performance... but lets worry about that outside the rc-series).
> 

Well, in itself that limitation highlights that evaluating this is
challenging and needs careful treatment. Otherwise two different
approaches can seem equivalent only because a hardware-related
bottleneck was at play.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"

[Mel Gorman]

On Sat, Apr 15, 2017 at 09:28:33PM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 15 Apr 2017 15:53:50 +0100
> Mel Gorman  wrote:
> 
> > This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the
> > patch worked great for userspace allocations, the fact that softirq loses
> > the per-cpu allocator caused problems. It needs to be redone taking into
> > account that a separate list is needed for hard/soft IRQs or alternatively
> > find a cheap way of detecting reentry due to an interrupt. Both are possible
> > but sufficiently tricky that it shouldn't be rushed. Jesper had one method
> > for allowing softirqs but reported that the cost was high enough that it
> > performed similarly to a plain revert. His figures for netperf TCP_STREAM
> > were as follows
> > 
> > Baseline v4.10.0  : 60316 Mbit/s
> > Current 4.11.0-rc6: 47491 Mbit/s
> > This patch: 60662 Mbit/s
> (should instead state "Jesper's patch" or "His patch")
> 

Yes, you are correct of course.

> Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied:
> 
>  This patch 60106 Mbit/s (average of 7 iteration 60 sec runs)
> 
> With these speeds I'm starting to hit the memory bandwidth of my machines.
> Thus, the 60 GBit/s measurement cannot be used to validate the
> performance impact of reverting this compared to my softirq patch, it
> only shows we fixed the regression.  (I'm suspicious as I see a higher
> contention on the page allocator lock (4% vs 1.3%) with this patch and
> still same performance... but lets worry about that outside the rc-series).
> 

Well, in itself that limitation highlights that evaluating this is
challenging and needs careful treatment. Otherwise two different
approaches can seem equivalent only because a hardware-related
bottleneck was at play.

-- 
Mel Gorman
SUSE Labs

pinctrl: imx: Checking reuse of grouping functionality

[SF Markus Elfring]

Hello,

A preprocessor symbol like “CONFIG_GENERIC_PINCTRL_GROUPS” was introduced
by the commit c033a718f615b6b3ddc83ce3e0a217c30bd09cb5 (“pinctrl: stricten up
generic group code”) on 2017-01-03. Some functions are only available then
when this macro is defined.

I have got the impression that the corresponding programming interface is used
by the source file “drivers/pinctrl/freescale/pinctrl-imx.c” unconditionally.
How do you think about to extend specifications for conditional compilation 
there?

Regards,
Markus

pinctrl: imx: Checking reuse of grouping functionality

[SF Markus Elfring]

Hello,

A preprocessor symbol like “CONFIG_GENERIC_PINCTRL_GROUPS” was introduced
by the commit c033a718f615b6b3ddc83ce3e0a217c30bd09cb5 (“pinctrl: stricten up
generic group code”) on 2017-01-03. Some functions are only available then
when this macro is defined.

I have got the impression that the corresponding programming interface is used
by the source file “drivers/pinctrl/freescale/pinctrl-imx.c” unconditionally.
How do you think about to extend specifications for conditional compilation 
there?

Regards,
Markus

Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"

[Jesper Dangaard Brouer]

On Sat, 15 Apr 2017 15:53:50 +0100
Mel Gorman  wrote:

> This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the
> patch worked great for userspace allocations, the fact that softirq loses
> the per-cpu allocator caused problems. It needs to be redone taking into
> account that a separate list is needed for hard/soft IRQs or alternatively
> find a cheap way of detecting reentry due to an interrupt. Both are possible
> but sufficiently tricky that it shouldn't be rushed. Jesper had one method
> for allowing softirqs but reported that the cost was high enough that it
> performed similarly to a plain revert. His figures for netperf TCP_STREAM
> were as follows
> 
> Baseline v4.10.0  : 60316 Mbit/s
> Current 4.11.0-rc6: 47491 Mbit/s
> This patch: 60662 Mbit/s
(should instead state "Jesper's patch" or "His patch")

Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied:

 This patch 60106 Mbit/s (average of 7 iteration 60 sec runs)

With these speeds I'm starting to hit the memory bandwidth of my machines.
Thus, the 60 GBit/s measurement cannot be used to validate the
performance impact of reverting this compared to my softirq patch, it
only shows we fixed the regression.  (I'm suspicious as I see a higher
contention on the page allocator lock (4% vs 1.3%) with this patch and
still same performance... but lets worry about that outside the rc-series).

I would be interested in Tariq to re-run these benchmarks on some
hardware with enough memory bandwidth for 100Gbit/s throughput.


> As this is a regression, I wish to revert to noirq allocator for now and
> go back to the drawing board.
> 
> Signed-off-by: Mel Gorman 
> Reported-by: Tariq Toukan 

Acked-by: Jesper Dangaard Brouer 

> ---
>  mm/page_alloc.c | 43 ---
>  1 file changed, 20 insertions(+), 23 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6cbde310abed..3bba4f46214c 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1090,10 +1090,10 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>  {
>   int migratetype = 0;
>   int batch_free = 0;
> - unsigned long nr_scanned, flags;
> + unsigned long nr_scanned;
>   bool isolated_pageblocks;
>  
> - spin_lock_irqsave(>lock, flags);
> + spin_lock(>lock);
>   isolated_pageblocks = has_isolate_pageblock(zone);
>   nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
>   if (nr_scanned)
> @@ -1142,7 +1142,7 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>   trace_mm_page_pcpu_drain(page, 0, mt);
>   } while (--count && --batch_free && !list_empty(list));
>   }
> - spin_unlock_irqrestore(>lock, flags);
> + spin_unlock(>lock);
>  }
>  
>  static void free_one_page(struct zone *zone,
> @@ -1150,9 +1150,8 @@ static void free_one_page(struct zone *zone,
>   unsigned int order,
>   int migratetype)
>  {
> - unsigned long nr_scanned, flags;
> - spin_lock_irqsave(>lock, flags);
> - __count_vm_events(PGFREE, 1 << order);
> + unsigned long nr_scanned;
> + spin_lock(>lock);
>   nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
>   if (nr_scanned)
>   __mod_node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED, 
> -nr_scanned);
> @@ -1162,7 +1161,7 @@ static void free_one_page(struct zone *zone,
>   migratetype = get_pfnblock_migratetype(page, pfn);
>   }
>   __free_one_page(page, pfn, zone, order, migratetype);
> - spin_unlock_irqrestore(>lock, flags);
> + spin_unlock(>lock);
>  }
>  
>  static void __meminit __init_single_page(struct page *page, unsigned long 
> pfn,
> @@ -1240,6 +1239,7 @@ void __meminit reserve_bootmem_region(phys_addr_t 
> start, phys_addr_t end)
>  
>  static void __free_pages_ok(struct page *page, unsigned int order)
>  {
> + unsigned long flags;
>   int migratetype;
>   unsigned long pfn = page_to_pfn(page);
>  
> @@ -1247,7 +1247,10 @@ static void __free_pages_ok(struct page *page, 
> unsigned int order)
>   return;
>  
>   migratetype = get_pfnblock_migratetype(page, pfn);
> + local_irq_save(flags);
> + __count_vm_events(PGFREE, 1 << order);
>   free_one_page(page_zone(page), page, pfn, order, migratetype);
> + local_irq_restore(flags);
>  }
>  
>  static void __init __free_pages_boot_core(struct page *page, unsigned int 
> order)
> @@ -2219,9 +,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
> order,
>   int migratetype, bool cold)
>  {
>   int i, alloced = 0;
> - unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + spin_lock(>lock);
>   for (i = 0; i < count; ++i) {
>   struct page *page = 

Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"

[Jesper Dangaard Brouer]

On Sat, 15 Apr 2017 15:53:50 +0100
Mel Gorman  wrote:

> This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the
> patch worked great for userspace allocations, the fact that softirq loses
> the per-cpu allocator caused problems. It needs to be redone taking into
> account that a separate list is needed for hard/soft IRQs or alternatively
> find a cheap way of detecting reentry due to an interrupt. Both are possible
> but sufficiently tricky that it shouldn't be rushed. Jesper had one method
> for allowing softirqs but reported that the cost was high enough that it
> performed similarly to a plain revert. His figures for netperf TCP_STREAM
> were as follows
> 
> Baseline v4.10.0  : 60316 Mbit/s
> Current 4.11.0-rc6: 47491 Mbit/s
> This patch: 60662 Mbit/s
(should instead state "Jesper's patch" or "His patch")

Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied:

 This patch 60106 Mbit/s (average of 7 iteration 60 sec runs)

With these speeds I'm starting to hit the memory bandwidth of my machines.
Thus, the 60 GBit/s measurement cannot be used to validate the
performance impact of reverting this compared to my softirq patch, it
only shows we fixed the regression.  (I'm suspicious as I see a higher
contention on the page allocator lock (4% vs 1.3%) with this patch and
still same performance... but lets worry about that outside the rc-series).

I would be interested in Tariq to re-run these benchmarks on some
hardware with enough memory bandwidth for 100Gbit/s throughput.


> As this is a regression, I wish to revert to noirq allocator for now and
> go back to the drawing board.
> 
> Signed-off-by: Mel Gorman 
> Reported-by: Tariq Toukan 

Acked-by: Jesper Dangaard Brouer 

> ---
>  mm/page_alloc.c | 43 ---
>  1 file changed, 20 insertions(+), 23 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6cbde310abed..3bba4f46214c 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1090,10 +1090,10 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>  {
>   int migratetype = 0;
>   int batch_free = 0;
> - unsigned long nr_scanned, flags;
> + unsigned long nr_scanned;
>   bool isolated_pageblocks;
>  
> - spin_lock_irqsave(>lock, flags);
> + spin_lock(>lock);
>   isolated_pageblocks = has_isolate_pageblock(zone);
>   nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
>   if (nr_scanned)
> @@ -1142,7 +1142,7 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>   trace_mm_page_pcpu_drain(page, 0, mt);
>   } while (--count && --batch_free && !list_empty(list));
>   }
> - spin_unlock_irqrestore(>lock, flags);
> + spin_unlock(>lock);
>  }
>  
>  static void free_one_page(struct zone *zone,
> @@ -1150,9 +1150,8 @@ static void free_one_page(struct zone *zone,
>   unsigned int order,
>   int migratetype)
>  {
> - unsigned long nr_scanned, flags;
> - spin_lock_irqsave(>lock, flags);
> - __count_vm_events(PGFREE, 1 << order);
> + unsigned long nr_scanned;
> + spin_lock(>lock);
>   nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
>   if (nr_scanned)
>   __mod_node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED, 
> -nr_scanned);
> @@ -1162,7 +1161,7 @@ static void free_one_page(struct zone *zone,
>   migratetype = get_pfnblock_migratetype(page, pfn);
>   }
>   __free_one_page(page, pfn, zone, order, migratetype);
> - spin_unlock_irqrestore(>lock, flags);
> + spin_unlock(>lock);
>  }
>  
>  static void __meminit __init_single_page(struct page *page, unsigned long 
> pfn,
> @@ -1240,6 +1239,7 @@ void __meminit reserve_bootmem_region(phys_addr_t 
> start, phys_addr_t end)
>  
>  static void __free_pages_ok(struct page *page, unsigned int order)
>  {
> + unsigned long flags;
>   int migratetype;
>   unsigned long pfn = page_to_pfn(page);
>  
> @@ -1247,7 +1247,10 @@ static void __free_pages_ok(struct page *page, 
> unsigned int order)
>   return;
>  
>   migratetype = get_pfnblock_migratetype(page, pfn);
> + local_irq_save(flags);
> + __count_vm_events(PGFREE, 1 << order);
>   free_one_page(page_zone(page), page, pfn, order, migratetype);
> + local_irq_restore(flags);
>  }
>  
>  static void __init __free_pages_boot_core(struct page *page, unsigned int 
> order)
> @@ -2219,9 +,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
> order,
>   int migratetype, bool cold)
>  {
>   int i, alloced = 0;
> - unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + spin_lock(>lock);
>   for (i = 0; i < count; ++i) {
>   struct page *page = __rmqueue(zone, order, migratetype);
>   if (unlikely(page == NULL))
> @@ -2257,7 +2259,7 @@ 

[GIT PULL 07/19] lightnvm: don't check for failure from mempool_alloc()

[Matias Bjørling]

From: NeilBrown 

mempool_alloc() cannot fail if the gfp flags allow it to
sleep, and both GFP_KERNEL and GFP_NOIO allows for sleeping.

So rrpc_move_valid_pages() and rrpc_make_rq() don't need to
test the return value.

Signed-off-by: NeilBrown 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/rrpc.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 4e4c299..a8acf9e 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -318,10 +318,6 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, struct 
rrpc_block *rblk)
}
 
page = mempool_alloc(rrpc->page_pool, GFP_NOIO);
-   if (!page) {
-   bio_put(bio);
-   return -ENOMEM;
-   }
 
while ((slot = find_first_zero_bit(rblk->invalid_pages,
nr_sec_per_blk)) < nr_sec_per_blk) {
@@ -1006,11 +1002,6 @@ static blk_qc_t rrpc_make_rq(struct request_queue *q, 
struct bio *bio)
}
 
rqd = mempool_alloc(rrpc->rq_pool, GFP_KERNEL);
-   if (!rqd) {
-   pr_err_ratelimited("rrpc: not able to queue bio.");
-   bio_io_error(bio);
-   return BLK_QC_T_NONE;
-   }
memset(rqd, 0, sizeof(struct nvm_rq));
 
err = rrpc_submit_io(rrpc, bio, rqd, NVM_IOTYPE_NONE);
-- 
2.9.3

[GIT PULL 07/19] lightnvm: don't check for failure from mempool_alloc()

[Matias Bjørling]

From: NeilBrown 

mempool_alloc() cannot fail if the gfp flags allow it to
sleep, and both GFP_KERNEL and GFP_NOIO allows for sleeping.

So rrpc_move_valid_pages() and rrpc_make_rq() don't need to
test the return value.

Signed-off-by: NeilBrown 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/rrpc.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 4e4c299..a8acf9e 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -318,10 +318,6 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, struct 
rrpc_block *rblk)
}
 
page = mempool_alloc(rrpc->page_pool, GFP_NOIO);
-   if (!page) {
-   bio_put(bio);
-   return -ENOMEM;
-   }
 
while ((slot = find_first_zero_bit(rblk->invalid_pages,
nr_sec_per_blk)) < nr_sec_per_blk) {
@@ -1006,11 +1002,6 @@ static blk_qc_t rrpc_make_rq(struct request_queue *q, 
struct bio *bio)
}
 
rqd = mempool_alloc(rrpc->rq_pool, GFP_KERNEL);
-   if (!rqd) {
-   pr_err_ratelimited("rrpc: not able to queue bio.");
-   bio_io_error(bio);
-   return BLK_QC_T_NONE;
-   }
memset(rqd, 0, sizeof(struct nvm_rq));
 
err = rrpc_submit_io(rrpc, bio, rqd, NVM_IOTYPE_NONE);
-- 
2.9.3

[GIT PULL 06/19] lightnvm: enable nvme size compile asserts

[Matias Bjørling]

The asserts in _nvme_nvm_check_size are not compiled due to the function
not begin called. Make sure that it is called, and also fix the wrong
sizes of asserts for nvme_nvm_addr_format, and nvme_nvm_bb_tbl, which
checked for number of bits instead of bytes.

Reported-by: Scott Bauer 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 4ea9c93..12c5a40 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -241,9 +241,9 @@ static inline void _nvme_nvm_check_size(void)
BUILD_BUG_ON(sizeof(struct nvme_nvm_l2ptbl) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_erase_blk) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id_group) != 960);
-   BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 128);
+   BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 16);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id) != 4096);
-   BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 512);
+   BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 64);
 }
 
 static int init_grps(struct nvm_id *nvm_id, struct nvme_nvm_id *nvme_nvm_id)
@@ -797,6 +797,8 @@ int nvme_nvm_register(struct nvme_ns *ns, char *disk_name, 
int node)
struct request_queue *q = ns->queue;
struct nvm_dev *dev;
 
+   _nvme_nvm_check_size();
+
dev = nvm_alloc_dev(node);
if (!dev)
return -ENOMEM;
-- 
2.9.3

[GIT PULL 10/19] lightnvm: bad type conversion for nvme control bits

[Matias Bjørling]

From: Javier González 

The NVMe I/O command control bits are 16 bytes, but is interpreted as
32 bytes in the lightnvm user I/O data path.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 12c5a40..4b78090 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -754,7 +754,7 @@ static int nvme_nvm_user_vcmd(struct nvme_ns *ns, int admin,
c.common.cdw2[1] = cpu_to_le32(vcmd.cdw3);
/* cdw11-12 */
c.ph_rw.length = cpu_to_le16(vcmd.nppas);
-   c.ph_rw.control  = cpu_to_le32(vcmd.control);
+   c.ph_rw.control  = cpu_to_le16(vcmd.control);
c.common.cdw10[3] = cpu_to_le32(vcmd.cdw13);
c.common.cdw10[4] = cpu_to_le32(vcmd.cdw14);
c.common.cdw10[5] = cpu_to_le32(vcmd.cdw15);
-- 
2.9.3

[GIT PULL 06/19] lightnvm: enable nvme size compile asserts

[Matias Bjørling]

The asserts in _nvme_nvm_check_size are not compiled due to the function
not begin called. Make sure that it is called, and also fix the wrong
sizes of asserts for nvme_nvm_addr_format, and nvme_nvm_bb_tbl, which
checked for number of bits instead of bytes.

Reported-by: Scott Bauer 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 4ea9c93..12c5a40 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -241,9 +241,9 @@ static inline void _nvme_nvm_check_size(void)
BUILD_BUG_ON(sizeof(struct nvme_nvm_l2ptbl) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_erase_blk) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id_group) != 960);
-   BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 128);
+   BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 16);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id) != 4096);
-   BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 512);
+   BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 64);
 }
 
 static int init_grps(struct nvm_id *nvm_id, struct nvme_nvm_id *nvme_nvm_id)
@@ -797,6 +797,8 @@ int nvme_nvm_register(struct nvme_ns *ns, char *disk_name, 
int node)
struct request_queue *q = ns->queue;
struct nvm_dev *dev;
 
+   _nvme_nvm_check_size();
+
dev = nvm_alloc_dev(node);
if (!dev)
return -ENOMEM;
-- 
2.9.3

[GIT PULL 10/19] lightnvm: bad type conversion for nvme control bits

[Matias Bjørling]

From: Javier González 

The NVMe I/O command control bits are 16 bytes, but is interpreted as
32 bytes in the lightnvm user I/O data path.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 12c5a40..4b78090 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -754,7 +754,7 @@ static int nvme_nvm_user_vcmd(struct nvme_ns *ns, int admin,
c.common.cdw2[1] = cpu_to_le32(vcmd.cdw3);
/* cdw11-12 */
c.ph_rw.length = cpu_to_le16(vcmd.nppas);
-   c.ph_rw.control  = cpu_to_le32(vcmd.control);
+   c.ph_rw.control  = cpu_to_le16(vcmd.control);
c.common.cdw10[3] = cpu_to_le32(vcmd.cdw13);
c.common.cdw10[4] = cpu_to_le32(vcmd.cdw14);
c.common.cdw10[5] = cpu_to_le32(vcmd.cdw15);
-- 
2.9.3

[GIT PULL 02/19] nvme/lightnvm: Prevent small buffer overflow in nvme_nvm_identify

[Matias Bjørling]

From: Scott Bauer 

There are two closely named structs in lightnvm:
struct nvme_nvm_addr_format and
struct nvme_addr_format.

The first struct has 4 reserved bytes at the end, the second does not.
(gdb) p sizeof(struct nvme_nvm_addr_format)
$1 = 16
(gdb) p sizeof(struct nvm_addr_format)
$2 = 12

In the nvme_nvm_identify function we memcpy from the larger struct to the
smaller struct. We incorrectly pass the length of the larger struct
and overflow by 4 bytes, lets not do that.

Signed-off-by: Scott Bauer 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 21cac85..fd98954 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -324,7 +324,7 @@ static int nvme_nvm_identity(struct nvm_dev *nvmdev, struct 
nvm_id *nvm_id)
nvm_id->cap = le32_to_cpu(nvme_nvm_id->cap);
nvm_id->dom = le32_to_cpu(nvme_nvm_id->dom);
memcpy(_id->ppaf, _nvm_id->ppaf,
-   sizeof(struct nvme_nvm_addr_format));
+   sizeof(struct nvm_addr_format));
 
ret = init_grps(nvm_id, nvme_nvm_id);
 out:
-- 
2.9.3

[GIT PULL 09/19] lightnvm: fix cleanup order of disk on init error

[Matias Bjørling]

From: Javier González 

Reorder disk allocation such that the disk structure can be put
safely.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5eea3d5..5f84d2a 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -264,15 +264,15 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
goto err_t;
}
 
+   tdisk = alloc_disk(0);
+   if (!tdisk)
+   goto err_dev;
+
tqueue = blk_alloc_queue_node(GFP_KERNEL, dev->q->node);
if (!tqueue)
-   goto err_dev;
+   goto err_disk;
blk_queue_make_request(tqueue, tt->make_rq);
 
-   tdisk = alloc_disk(0);
-   if (!tdisk)
-   goto err_queue;
-
sprintf(tdisk->disk_name, "%s", create->tgtname);
tdisk->flags = GENHD_FL_EXT_DEVT;
tdisk->major = 0;
@@ -308,9 +308,9 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
if (tt->exit)
tt->exit(targetdata);
 err_init:
-   put_disk(tdisk);
-err_queue:
blk_cleanup_queue(tqueue);
+err_disk:
+   put_disk(tdisk);
 err_dev:
nvm_remove_tgt_dev(tgt_dev, 0);
 err_t:
-- 
2.9.3

[GIT PULL 02/19] nvme/lightnvm: Prevent small buffer overflow in nvme_nvm_identify

[Matias Bjørling]

From: Scott Bauer 

There are two closely named structs in lightnvm:
struct nvme_nvm_addr_format and
struct nvme_addr_format.

The first struct has 4 reserved bytes at the end, the second does not.
(gdb) p sizeof(struct nvme_nvm_addr_format)
$1 = 16
(gdb) p sizeof(struct nvm_addr_format)
$2 = 12

In the nvme_nvm_identify function we memcpy from the larger struct to the
smaller struct. We incorrectly pass the length of the larger struct
and overflow by 4 bytes, lets not do that.

Signed-off-by: Scott Bauer 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/lightnvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 21cac85..fd98954 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -324,7 +324,7 @@ static int nvme_nvm_identity(struct nvm_dev *nvmdev, struct 
nvm_id *nvm_id)
nvm_id->cap = le32_to_cpu(nvme_nvm_id->cap);
nvm_id->dom = le32_to_cpu(nvme_nvm_id->dom);
memcpy(_id->ppaf, _nvm_id->ppaf,
-   sizeof(struct nvme_nvm_addr_format));
+   sizeof(struct nvm_addr_format));
 
ret = init_grps(nvm_id, nvme_nvm_id);
 out:
-- 
2.9.3

[GIT PULL 09/19] lightnvm: fix cleanup order of disk on init error

[Matias Bjørling]

From: Javier González 

Reorder disk allocation such that the disk structure can be put
safely.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5eea3d5..5f84d2a 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -264,15 +264,15 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
goto err_t;
}
 
+   tdisk = alloc_disk(0);
+   if (!tdisk)
+   goto err_dev;
+
tqueue = blk_alloc_queue_node(GFP_KERNEL, dev->q->node);
if (!tqueue)
-   goto err_dev;
+   goto err_disk;
blk_queue_make_request(tqueue, tt->make_rq);
 
-   tdisk = alloc_disk(0);
-   if (!tdisk)
-   goto err_queue;
-
sprintf(tdisk->disk_name, "%s", create->tgtname);
tdisk->flags = GENHD_FL_EXT_DEVT;
tdisk->major = 0;
@@ -308,9 +308,9 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
if (tt->exit)
tt->exit(targetdata);
 err_init:
-   put_disk(tdisk);
-err_queue:
blk_cleanup_queue(tqueue);
+err_disk:
+   put_disk(tdisk);
 err_dev:
nvm_remove_tgt_dev(tgt_dev, 0);
 err_t:
-- 
2.9.3

[GIT PULL 03/19] lightnvm: submit erases using the I/O path

[Matias Bjørling]

From: Javier González 

Until now erases have been submitted as synchronous commands through a
dedicated erase function. In order to enable targets implementing
asynchronous erases, refactor the erase path so that it uses the normal
async I/O submission functions. If a target requires sync I/O, it can
implement it internally. Also, adapt rrpc to use the new erase path.

Signed-off-by: Javier González 
Fixed spelling error.
Signed-off-by: Matias Bjørling 

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c  | 54 +++-
 drivers/lightnvm/rrpc.c  |  3 +--
 drivers/nvme/host/lightnvm.c | 32 --
 include/linux/lightnvm.h |  8 +++
 4 files changed, 47 insertions(+), 50 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5262ba6..95105c4 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -590,11 +590,11 @@ int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, 
struct ppa_addr *ppas,
 
memset(, 0, sizeof(struct nvm_rq));
 
-   nvm_set_rqd_ppalist(dev, , ppas, nr_ppas, 1);
+   nvm_set_rqd_ppalist(tgt_dev, , ppas, nr_ppas, 1);
nvm_rq_tgt_to_dev(tgt_dev, );
 
ret = dev->ops->set_bb_tbl(dev, _addr, rqd.nr_ppas, type);
-   nvm_free_rqd_ppalist(dev, );
+   nvm_free_rqd_ppalist(tgt_dev, );
if (ret) {
pr_err("nvm: failed bb mark\n");
return -EINVAL;
@@ -626,34 +626,45 @@ int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct 
nvm_rq *rqd)
 }
 EXPORT_SYMBOL(nvm_submit_io);
 
-int nvm_erase_blk(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas, int 
flags)
+static void nvm_end_io_sync(struct nvm_rq *rqd)
 {
-   struct nvm_dev *dev = tgt_dev->parent;
+   struct completion *waiting = rqd->private;
+
+   complete(waiting);
+}
+
+int nvm_erase_sync(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
+   int nr_ppas)
+{
+   struct nvm_geo *geo = _dev->geo;
struct nvm_rq rqd;
int ret;
-
-   if (!dev->ops->erase_block)
-   return 0;
-
-   nvm_map_to_dev(tgt_dev, ppas);
+   DECLARE_COMPLETION_ONSTACK(wait);
 
memset(, 0, sizeof(struct nvm_rq));
 
-   ret = nvm_set_rqd_ppalist(dev, , ppas, 1, 1);
+   rqd.opcode = NVM_OP_ERASE;
+   rqd.end_io = nvm_end_io_sync;
+   rqd.private = 
+   rqd.flags = geo->plane_mode >> 1;
+
+   ret = nvm_set_rqd_ppalist(tgt_dev, , ppas, nr_ppas, 1);
if (ret)
return ret;
 
-   nvm_rq_tgt_to_dev(tgt_dev, );
+   ret = nvm_submit_io(tgt_dev, );
+   if (ret) {
+   pr_err("rrpr: erase I/O submission failed: %d\n", ret);
+   goto free_ppa_list;
+   }
+   wait_for_completion_io();
 
-   rqd.flags = flags;
-
-   ret = dev->ops->erase_block(dev, );
-
-   nvm_free_rqd_ppalist(dev, );
+free_ppa_list:
+   nvm_free_rqd_ppalist(tgt_dev, );
 
return ret;
 }
-EXPORT_SYMBOL(nvm_erase_blk);
+EXPORT_SYMBOL(nvm_erase_sync);
 
 int nvm_get_l2p_tbl(struct nvm_tgt_dev *tgt_dev, u64 slba, u32 nlb,
nvm_l2p_update_fn *update_l2p, void *priv)
@@ -732,10 +743,11 @@ void nvm_put_area(struct nvm_tgt_dev *tgt_dev, sector_t 
begin)
 }
 EXPORT_SYMBOL(nvm_put_area);
 
-int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
+int nvm_set_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd,
const struct ppa_addr *ppas, int nr_ppas, int vblk)
 {
-   struct nvm_geo *geo = >geo;
+   struct nvm_dev *dev = tgt_dev->parent;
+   struct nvm_geo *geo = _dev->geo;
int i, plane_cnt, pl_idx;
struct ppa_addr ppa;
 
@@ -773,12 +785,12 @@ int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct 
nvm_rq *rqd,
 }
 EXPORT_SYMBOL(nvm_set_rqd_ppalist);
 
-void nvm_free_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd)
+void nvm_free_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
 {
if (!rqd->ppa_list)
return;
 
-   nvm_dev_dma_free(dev, rqd->ppa_list, rqd->dma_ppa_list);
+   nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
 }
 EXPORT_SYMBOL(nvm_free_rqd_ppalist);
 
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index e68efbc..4e4c299 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -414,7 +414,6 @@ static void rrpc_block_gc(struct work_struct *work)
struct rrpc *rrpc = gcb->rrpc;
struct rrpc_block *rblk = gcb->rblk;
struct rrpc_lun *rlun = rblk->rlun;
-   struct nvm_tgt_dev *dev = rrpc->dev;
struct ppa_addr ppa;
 
mempool_free(gcb, rrpc->gcb_pool);
@@ -430,7 +429,7 @@ static void rrpc_block_gc(struct work_struct *work)
ppa.g.lun = rlun->bppa.g.lun;
ppa.g.blk = rblk->id;
 
-   if 

[GIT PULL 03/19] lightnvm: submit erases using the I/O path

[Matias Bjørling]

From: Javier González 

Until now erases have been submitted as synchronous commands through a
dedicated erase function. In order to enable targets implementing
asynchronous erases, refactor the erase path so that it uses the normal
async I/O submission functions. If a target requires sync I/O, it can
implement it internally. Also, adapt rrpc to use the new erase path.

Signed-off-by: Javier González 
Fixed spelling error.
Signed-off-by: Matias Bjørling 

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c  | 54 +++-
 drivers/lightnvm/rrpc.c  |  3 +--
 drivers/nvme/host/lightnvm.c | 32 --
 include/linux/lightnvm.h |  8 +++
 4 files changed, 47 insertions(+), 50 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5262ba6..95105c4 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -590,11 +590,11 @@ int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, 
struct ppa_addr *ppas,
 
memset(, 0, sizeof(struct nvm_rq));
 
-   nvm_set_rqd_ppalist(dev, , ppas, nr_ppas, 1);
+   nvm_set_rqd_ppalist(tgt_dev, , ppas, nr_ppas, 1);
nvm_rq_tgt_to_dev(tgt_dev, );
 
ret = dev->ops->set_bb_tbl(dev, _addr, rqd.nr_ppas, type);
-   nvm_free_rqd_ppalist(dev, );
+   nvm_free_rqd_ppalist(tgt_dev, );
if (ret) {
pr_err("nvm: failed bb mark\n");
return -EINVAL;
@@ -626,34 +626,45 @@ int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct 
nvm_rq *rqd)
 }
 EXPORT_SYMBOL(nvm_submit_io);
 
-int nvm_erase_blk(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas, int 
flags)
+static void nvm_end_io_sync(struct nvm_rq *rqd)
 {
-   struct nvm_dev *dev = tgt_dev->parent;
+   struct completion *waiting = rqd->private;
+
+   complete(waiting);
+}
+
+int nvm_erase_sync(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
+   int nr_ppas)
+{
+   struct nvm_geo *geo = _dev->geo;
struct nvm_rq rqd;
int ret;
-
-   if (!dev->ops->erase_block)
-   return 0;
-
-   nvm_map_to_dev(tgt_dev, ppas);
+   DECLARE_COMPLETION_ONSTACK(wait);
 
memset(, 0, sizeof(struct nvm_rq));
 
-   ret = nvm_set_rqd_ppalist(dev, , ppas, 1, 1);
+   rqd.opcode = NVM_OP_ERASE;
+   rqd.end_io = nvm_end_io_sync;
+   rqd.private = 
+   rqd.flags = geo->plane_mode >> 1;
+
+   ret = nvm_set_rqd_ppalist(tgt_dev, , ppas, nr_ppas, 1);
if (ret)
return ret;
 
-   nvm_rq_tgt_to_dev(tgt_dev, );
+   ret = nvm_submit_io(tgt_dev, );
+   if (ret) {
+   pr_err("rrpr: erase I/O submission failed: %d\n", ret);
+   goto free_ppa_list;
+   }
+   wait_for_completion_io();
 
-   rqd.flags = flags;
-
-   ret = dev->ops->erase_block(dev, );
-
-   nvm_free_rqd_ppalist(dev, );
+free_ppa_list:
+   nvm_free_rqd_ppalist(tgt_dev, );
 
return ret;
 }
-EXPORT_SYMBOL(nvm_erase_blk);
+EXPORT_SYMBOL(nvm_erase_sync);
 
 int nvm_get_l2p_tbl(struct nvm_tgt_dev *tgt_dev, u64 slba, u32 nlb,
nvm_l2p_update_fn *update_l2p, void *priv)
@@ -732,10 +743,11 @@ void nvm_put_area(struct nvm_tgt_dev *tgt_dev, sector_t 
begin)
 }
 EXPORT_SYMBOL(nvm_put_area);
 
-int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
+int nvm_set_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd,
const struct ppa_addr *ppas, int nr_ppas, int vblk)
 {
-   struct nvm_geo *geo = >geo;
+   struct nvm_dev *dev = tgt_dev->parent;
+   struct nvm_geo *geo = _dev->geo;
int i, plane_cnt, pl_idx;
struct ppa_addr ppa;
 
@@ -773,12 +785,12 @@ int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct 
nvm_rq *rqd,
 }
 EXPORT_SYMBOL(nvm_set_rqd_ppalist);
 
-void nvm_free_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd)
+void nvm_free_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
 {
if (!rqd->ppa_list)
return;
 
-   nvm_dev_dma_free(dev, rqd->ppa_list, rqd->dma_ppa_list);
+   nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
 }
 EXPORT_SYMBOL(nvm_free_rqd_ppalist);
 
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index e68efbc..4e4c299 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -414,7 +414,6 @@ static void rrpc_block_gc(struct work_struct *work)
struct rrpc *rrpc = gcb->rrpc;
struct rrpc_block *rblk = gcb->rblk;
struct rrpc_lun *rlun = rblk->rlun;
-   struct nvm_tgt_dev *dev = rrpc->dev;
struct ppa_addr ppa;
 
mempool_free(gcb, rrpc->gcb_pool);
@@ -430,7 +429,7 @@ static void rrpc_block_gc(struct work_struct *work)
ppa.g.lun = rlun->bppa.g.lun;
ppa.g.blk = rblk->id;
 
-   if (nvm_erase_blk(dev, , 0))
+   if (nvm_erase_sync(rrpc->dev, , 1))

[GIT PULL 15/19] lightnvm: convert sprintf into strlcpy

[Matias Bjørling]

From: Javier González 

Convert sprintf calls to strlcpy in order to make possible buffer
overflow more obvious.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 258007a..2c26af3 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -273,7 +273,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
goto err_disk;
blk_queue_make_request(tqueue, tt->make_rq);
 
-   sprintf(tdisk->disk_name, "%s", create->tgtname);
+   strlcpy(tdisk->disk_name, create->tgtname, sizeof(tdisk->disk_name));
tdisk->flags = GENHD_FL_EXT_DEVT;
tdisk->major = 0;
tdisk->first_minor = 0;
@@ -1198,13 +1198,13 @@ static long nvm_ioctl_get_devices(struct file *file, 
void __user *arg)
list_for_each_entry(dev, _devices, devices) {
struct nvm_ioctl_device_info *info = >info[i];
 
-   sprintf(info->devname, "%s", dev->name);
+   strlcpy(info->devname, dev->name, sizeof(info->devname));
 
/* kept for compatibility */
info->bmversion[0] = 1;
info->bmversion[1] = 0;
info->bmversion[2] = 0;
-   sprintf(info->bmname, "%s", "gennvm");
+   strlcpy(info->bmname, "gennvm", sizeof(info->bmname));
i++;
 
if (i > 31) {
-- 
2.9.3

[GIT PULL 15/19] lightnvm: convert sprintf into strlcpy

[Matias Bjørling]

From: Javier González 

Convert sprintf calls to strlcpy in order to make possible buffer
overflow more obvious.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 258007a..2c26af3 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -273,7 +273,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
goto err_disk;
blk_queue_make_request(tqueue, tt->make_rq);
 
-   sprintf(tdisk->disk_name, "%s", create->tgtname);
+   strlcpy(tdisk->disk_name, create->tgtname, sizeof(tdisk->disk_name));
tdisk->flags = GENHD_FL_EXT_DEVT;
tdisk->major = 0;
tdisk->first_minor = 0;
@@ -1198,13 +1198,13 @@ static long nvm_ioctl_get_devices(struct file *file, 
void __user *arg)
list_for_each_entry(dev, _devices, devices) {
struct nvm_ioctl_device_info *info = >info[i];
 
-   sprintf(info->devname, "%s", dev->name);
+   strlcpy(info->devname, dev->name, sizeof(info->devname));
 
/* kept for compatibility */
info->bmversion[0] = 1;
info->bmversion[1] = 0;
info->bmversion[2] = 0;
-   sprintf(info->bmname, "%s", "gennvm");
+   strlcpy(info->bmname, "gennvm", sizeof(info->bmname));
i++;
 
if (i > 31) {
-- 
2.9.3

[GIT PULL 14/19] lightnvm: fix type checks on rrpc

[Matias Bjørling]

From: Javier González 

sector_t is always unsigned, therefore avoid < 0 checks on it.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/rrpc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 5dba544..cf0e28a 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -817,7 +817,7 @@ static int rrpc_read_ppalist_rq(struct rrpc *rrpc, struct 
bio *bio,
 
for (i = 0; i < npages; i++) {
/* We assume that mapping occurs at 4KB granularity */
-   BUG_ON(!(laddr + i >= 0 && laddr + i < rrpc->nr_sects));
+   BUG_ON(!(laddr + i < rrpc->nr_sects));
gp = >trans_map[laddr + i];
 
if (gp->rblk) {
@@ -846,7 +846,7 @@ static int rrpc_read_rq(struct rrpc *rrpc, struct bio *bio, 
struct nvm_rq *rqd,
if (!is_gc && rrpc_lock_rq(rrpc, bio, rqd))
return NVM_IO_REQUEUE;
 
-   BUG_ON(!(laddr >= 0 && laddr < rrpc->nr_sects));
+   BUG_ON(!(laddr < rrpc->nr_sects));
gp = >trans_map[laddr];
 
if (gp->rblk) {
-- 
2.9.3

[GIT PULL 14/19] lightnvm: fix type checks on rrpc

[Matias Bjørling]

From: Javier González 

sector_t is always unsigned, therefore avoid < 0 checks on it.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/rrpc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 5dba544..cf0e28a 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -817,7 +817,7 @@ static int rrpc_read_ppalist_rq(struct rrpc *rrpc, struct 
bio *bio,
 
for (i = 0; i < npages; i++) {
/* We assume that mapping occurs at 4KB granularity */
-   BUG_ON(!(laddr + i >= 0 && laddr + i < rrpc->nr_sects));
+   BUG_ON(!(laddr + i < rrpc->nr_sects));
gp = >trans_map[laddr + i];
 
if (gp->rblk) {
@@ -846,7 +846,7 @@ static int rrpc_read_rq(struct rrpc *rrpc, struct bio *bio, 
struct nvm_rq *rqd,
if (!is_gc && rrpc_lock_rq(rrpc, bio, rqd))
return NVM_IO_REQUEUE;
 
-   BUG_ON(!(laddr >= 0 && laddr < rrpc->nr_sects));
+   BUG_ON(!(laddr < rrpc->nr_sects));
gp = >trans_map[laddr];
 
if (gp->rblk) {
-- 
2.9.3

[GIT PULL 08/19] lightnvm: double-clear of dev->lun_map on target init error

[Matias Bjørling]

From: Javier González 

The dev->lun_map bits are cleared twice if an target init error occurs.
First in the target clean routine, and then next in the nvm_tgt_create
error function. Make sure that it is only cleared once by extending
nvm_remove_tgt_devi() with a clear bit, such that clearing of bits can
ignored when cleaning up a successful initialized target.

Signed-off-by: Javier González 
Fix style.
Signed-off-by: Matias Bjørling 

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index a14c52c..5eea3d5 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -89,7 +89,7 @@ static void nvm_release_luns_err(struct nvm_dev *dev, int 
lun_begin,
WARN_ON(!test_and_clear_bit(i, dev->lun_map));
 }
 
-static void nvm_remove_tgt_dev(struct nvm_tgt_dev *tgt_dev)
+static void nvm_remove_tgt_dev(struct nvm_tgt_dev *tgt_dev, int clear)
 {
struct nvm_dev *dev = tgt_dev->parent;
struct nvm_dev_map *dev_map = tgt_dev->map;
@@ -100,11 +100,14 @@ static void nvm_remove_tgt_dev(struct nvm_tgt_dev 
*tgt_dev)
int *lun_offs = ch_map->lun_offs;
int ch = i + ch_map->ch_off;
 
-   for (j = 0; j < ch_map->nr_luns; j++) {
-   int lun = j + lun_offs[j];
-   int lunid = (ch * dev->geo.luns_per_chnl) + lun;
+   if (clear) {
+   for (j = 0; j < ch_map->nr_luns; j++) {
+   int lun = j + lun_offs[j];
+   int lunid = (ch * dev->geo.luns_per_chnl) + lun;
 
-   WARN_ON(!test_and_clear_bit(lunid, dev->lun_map));
+   WARN_ON(!test_and_clear_bit(lunid,
+   dev->lun_map));
+   }
}
 
kfree(ch_map->lun_offs);
@@ -309,7 +312,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
 err_queue:
blk_cleanup_queue(tqueue);
 err_dev:
-   nvm_remove_tgt_dev(tgt_dev);
+   nvm_remove_tgt_dev(tgt_dev, 0);
 err_t:
kfree(t);
 err_reserve:
@@ -332,7 +335,7 @@ static void __nvm_remove_target(struct nvm_target *t)
if (tt->exit)
tt->exit(tdisk->private_data);
 
-   nvm_remove_tgt_dev(t->dev);
+   nvm_remove_tgt_dev(t->dev, 1);
put_disk(tdisk);
 
list_del(>list);
-- 
2.9.3

[GIT PULL 08/19] lightnvm: double-clear of dev->lun_map on target init error

[Matias Bjørling]

From: Javier González 

The dev->lun_map bits are cleared twice if an target init error occurs.
First in the target clean routine, and then next in the nvm_tgt_create
error function. Make sure that it is only cleared once by extending
nvm_remove_tgt_devi() with a clear bit, such that clearing of bits can
ignored when cleaning up a successful initialized target.

Signed-off-by: Javier González 
Fix style.
Signed-off-by: Matias Bjørling 

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index a14c52c..5eea3d5 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -89,7 +89,7 @@ static void nvm_release_luns_err(struct nvm_dev *dev, int 
lun_begin,
WARN_ON(!test_and_clear_bit(i, dev->lun_map));
 }
 
-static void nvm_remove_tgt_dev(struct nvm_tgt_dev *tgt_dev)
+static void nvm_remove_tgt_dev(struct nvm_tgt_dev *tgt_dev, int clear)
 {
struct nvm_dev *dev = tgt_dev->parent;
struct nvm_dev_map *dev_map = tgt_dev->map;
@@ -100,11 +100,14 @@ static void nvm_remove_tgt_dev(struct nvm_tgt_dev 
*tgt_dev)
int *lun_offs = ch_map->lun_offs;
int ch = i + ch_map->ch_off;
 
-   for (j = 0; j < ch_map->nr_luns; j++) {
-   int lun = j + lun_offs[j];
-   int lunid = (ch * dev->geo.luns_per_chnl) + lun;
+   if (clear) {
+   for (j = 0; j < ch_map->nr_luns; j++) {
+   int lun = j + lun_offs[j];
+   int lunid = (ch * dev->geo.luns_per_chnl) + lun;
 
-   WARN_ON(!test_and_clear_bit(lunid, dev->lun_map));
+   WARN_ON(!test_and_clear_bit(lunid,
+   dev->lun_map));
+   }
}
 
kfree(ch_map->lun_offs);
@@ -309,7 +312,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
 err_queue:
blk_cleanup_queue(tqueue);
 err_dev:
-   nvm_remove_tgt_dev(tgt_dev);
+   nvm_remove_tgt_dev(tgt_dev, 0);
 err_t:
kfree(t);
 err_reserve:
@@ -332,7 +335,7 @@ static void __nvm_remove_target(struct nvm_target *t)
if (tt->exit)
tt->exit(tdisk->private_data);
 
-   nvm_remove_tgt_dev(t->dev);
+   nvm_remove_tgt_dev(t->dev, 1);
put_disk(tdisk);
 
list_del(>list);
-- 
2.9.3

[GIT PULL 19/19] lightnvm: fix some error code in pblk-init.c

[Matias Bjørling]

From: Dan Carpenter 

There were a bunch of places in pblk_lines_init() where we didn't set an
error code.  And in pblk_writer_init() we accidentally return 1 instead
of a correct error code, which would result in a Oops later.

Fixes: 11a5d6fdf919 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-init.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index 94653b1..3996e4b 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -543,7 +543,7 @@ static int pblk_lines_init(struct pblk *pblk)
long nr_bad_blks, nr_meta_blks, nr_free_blks;
int bb_distance;
int i;
-   int ret = 0;
+   int ret;
 
lm->sec_per_line = geo->sec_per_blk * geo->nr_luns;
lm->blk_per_line = geo->nr_luns;
@@ -638,12 +638,16 @@ static int pblk_lines_init(struct pblk *pblk)
}
 
l_mg->bb_template = kzalloc(lm->sec_bitmap_len, GFP_KERNEL);
-   if (!l_mg->bb_template)
+   if (!l_mg->bb_template) {
+   ret = -ENOMEM;
goto fail_free_meta;
+   }
 
l_mg->bb_aux = kzalloc(lm->sec_bitmap_len, GFP_KERNEL);
-   if (!l_mg->bb_aux)
+   if (!l_mg->bb_aux) {
+   ret = -ENOMEM;
goto fail_free_bb_template;
+   }
 
bb_distance = (geo->nr_luns) * geo->sec_per_pl;
for (i = 0; i < lm->sec_per_line; i += bb_distance)
@@ -667,8 +671,10 @@ static int pblk_lines_init(struct pblk *pblk)
 
pblk->lines = kcalloc(l_mg->nr_lines, sizeof(struct pblk_line),
GFP_KERNEL);
-   if (!pblk->lines)
+   if (!pblk->lines) {
+   ret = -ENOMEM;
goto fail_free_bb_aux;
+   }
 
nr_free_blks = 0;
for (i = 0; i < l_mg->nr_lines; i++) {
@@ -682,8 +688,10 @@ static int pblk_lines_init(struct pblk *pblk)
spin_lock_init(>lock);
 
nr_bad_blks = pblk_bb_line(pblk, line);
-   if (nr_bad_blks < 0 || nr_bad_blks > lm->blk_per_line)
+   if (nr_bad_blks < 0 || nr_bad_blks > lm->blk_per_line) {
+   ret = -EINVAL;
goto fail_free_lines;
+   }
 
line->blk_in_line = lm->blk_per_line - nr_bad_blks;
if (line->blk_in_line < lm->min_blk_line) {
@@ -733,7 +741,7 @@ static int pblk_writer_init(struct pblk *pblk)
pblk->writer_ts = kthread_create(pblk_write_ts, pblk, "pblk-writer-t");
if (IS_ERR(pblk->writer_ts)) {
pr_err("pblk: could not allocate writer kthread\n");
-   return 1;
+   return PTR_ERR(pblk->writer_ts);
}
 
return 0;
-- 
2.9.3

[GIT PULL 19/19] lightnvm: fix some error code in pblk-init.c

[Matias Bjørling]

From: Dan Carpenter 

There were a bunch of places in pblk_lines_init() where we didn't set an
error code.  And in pblk_writer_init() we accidentally return 1 instead
of a correct error code, which would result in a Oops later.

Fixes: 11a5d6fdf919 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-init.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index 94653b1..3996e4b 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -543,7 +543,7 @@ static int pblk_lines_init(struct pblk *pblk)
long nr_bad_blks, nr_meta_blks, nr_free_blks;
int bb_distance;
int i;
-   int ret = 0;
+   int ret;
 
lm->sec_per_line = geo->sec_per_blk * geo->nr_luns;
lm->blk_per_line = geo->nr_luns;
@@ -638,12 +638,16 @@ static int pblk_lines_init(struct pblk *pblk)
}
 
l_mg->bb_template = kzalloc(lm->sec_bitmap_len, GFP_KERNEL);
-   if (!l_mg->bb_template)
+   if (!l_mg->bb_template) {
+   ret = -ENOMEM;
goto fail_free_meta;
+   }
 
l_mg->bb_aux = kzalloc(lm->sec_bitmap_len, GFP_KERNEL);
-   if (!l_mg->bb_aux)
+   if (!l_mg->bb_aux) {
+   ret = -ENOMEM;
goto fail_free_bb_template;
+   }
 
bb_distance = (geo->nr_luns) * geo->sec_per_pl;
for (i = 0; i < lm->sec_per_line; i += bb_distance)
@@ -667,8 +671,10 @@ static int pblk_lines_init(struct pblk *pblk)
 
pblk->lines = kcalloc(l_mg->nr_lines, sizeof(struct pblk_line),
GFP_KERNEL);
-   if (!pblk->lines)
+   if (!pblk->lines) {
+   ret = -ENOMEM;
goto fail_free_bb_aux;
+   }
 
nr_free_blks = 0;
for (i = 0; i < l_mg->nr_lines; i++) {
@@ -682,8 +688,10 @@ static int pblk_lines_init(struct pblk *pblk)
spin_lock_init(>lock);
 
nr_bad_blks = pblk_bb_line(pblk, line);
-   if (nr_bad_blks < 0 || nr_bad_blks > lm->blk_per_line)
+   if (nr_bad_blks < 0 || nr_bad_blks > lm->blk_per_line) {
+   ret = -EINVAL;
goto fail_free_lines;
+   }
 
line->blk_in_line = lm->blk_per_line - nr_bad_blks;
if (line->blk_in_line < lm->min_blk_line) {
@@ -733,7 +741,7 @@ static int pblk_writer_init(struct pblk *pblk)
pblk->writer_ts = kthread_create(pblk_write_ts, pblk, "pblk-writer-t");
if (IS_ERR(pblk->writer_ts)) {
pr_err("pblk: could not allocate writer kthread\n");
-   return 1;
+   return PTR_ERR(pblk->writer_ts);
}
 
return 0;
-- 
2.9.3

[GIT PULL 17/19] lightnvm: pblk-gc: fix an error pointer dereference in init

[Matias Bjørling]

From: Dan Carpenter 

These labels are reversed so we could end up dereferencing an error
pointer or leaking.

Fixes: 7f347ba6bb3a ("lightnvm: physical block device (pblk) target")
Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/lightnvm/pblk-gc.c b/drivers/lightnvm/pblk-gc.c
index 9b147cf..f173fd4 100644
--- a/drivers/lightnvm/pblk-gc.c
+++ b/drivers/lightnvm/pblk-gc.c
@@ -527,10 +527,10 @@ int pblk_gc_init(struct pblk *pblk)
 
return 0;
 
-fail_free_main_kthread:
-   kthread_stop(gc->gc_ts);
 fail_free_writer_kthread:
kthread_stop(gc->gc_writer_ts);
+fail_free_main_kthread:
+   kthread_stop(gc->gc_ts);
 
return ret;
 }
-- 
2.9.3

[GIT PULL 17/19] lightnvm: pblk-gc: fix an error pointer dereference in init

[Matias Bjørling]

From: Dan Carpenter 

These labels are reversed so we could end up dereferencing an error
pointer or leaking.

Fixes: 7f347ba6bb3a ("lightnvm: physical block device (pblk) target")
Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/lightnvm/pblk-gc.c b/drivers/lightnvm/pblk-gc.c
index 9b147cf..f173fd4 100644
--- a/drivers/lightnvm/pblk-gc.c
+++ b/drivers/lightnvm/pblk-gc.c
@@ -527,10 +527,10 @@ int pblk_gc_init(struct pblk *pblk)
 
return 0;
 
-fail_free_main_kthread:
-   kthread_stop(gc->gc_ts);
 fail_free_writer_kthread:
kthread_stop(gc->gc_writer_ts);
+fail_free_main_kthread:
+   kthread_stop(gc->gc_ts);
 
return ret;
 }
-- 
2.9.3

[GIT PULL 18/19] lightnvm: fix some WARN() messages

[Matias Bjørling]

From: Dan Carpenter 

WARN_ON() takes a condition, not an error message.  I slightly tweaked
some conditions so hopefully it's more clear.

Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-read.c | 12 ++--
 drivers/lightnvm/pblk-recovery.c |  2 +-
 drivers/lightnvm/pblk-write.c|  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index eff0982..bce7ed5 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -49,8 +49,8 @@ static void pblk_read_ppalist_rq(struct pblk *pblk, struct 
nvm_rq *rqd,
int i, j = 0;
 
/* logic error: lba out-of-bounds. Ignore read request */
-   if (!(blba + nr_secs < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lbas out of bounds\n");
+   if (blba + nr_secs >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lbas out of bounds\n");
return;
}
 
@@ -254,8 +254,8 @@ static void pblk_read_rq(struct pblk *pblk, struct nvm_rq 
*rqd,
sector_t lba = pblk_get_lba(bio);
 
/* logic error: lba out-of-bounds. Ignore read request */
-   if (!(lba < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lba out of bounds\n");
+   if (lba >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lba out of bounds\n");
return;
}
 
@@ -411,8 +411,8 @@ static int read_rq_gc(struct pblk *pblk, struct nvm_rq *rqd,
int valid_secs = 0;
 
/* logic error: lba out-of-bounds */
-   if (!(lba < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lba out of bounds\n");
+   if (lba >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lba out of bounds\n");
goto out;
}
 
diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
index 0d50f41..f8f8508 100644
--- a/drivers/lightnvm/pblk-recovery.c
+++ b/drivers/lightnvm/pblk-recovery.c
@@ -167,7 +167,7 @@ static int pblk_recov_l2p_from_emeta(struct pblk *pblk, 
struct pblk_line *line)
if (le64_to_cpu(lba_list[i]) == ADDR_EMPTY) {
spin_lock(>lock);
if (test_and_set_bit(i, line->invalid_bitmap))
-   WARN_ON_ONCE("pblk: rec. double invalidate:\n");
+   WARN_ONCE(1, "pblk: rec. double invalidate:\n");
else
line->vsc--;
spin_unlock(>lock);
diff --git a/drivers/lightnvm/pblk-write.c b/drivers/lightnvm/pblk-write.c
index ee57db9..74f7413 100644
--- a/drivers/lightnvm/pblk-write.c
+++ b/drivers/lightnvm/pblk-write.c
@@ -141,7 +141,7 @@ static void pblk_end_w_fail(struct pblk *pblk, struct 
nvm_rq *rqd)
 
/* Logic error */
if (bit > c_ctx->nr_valid) {
-   WARN_ON_ONCE("pblk: corrupted write request\n");
+   WARN_ONCE(1, "pblk: corrupted write request\n");
goto out;
}
 
-- 
2.9.3

[GIT PULL 18/19] lightnvm: fix some WARN() messages

[Matias Bjørling]

From: Dan Carpenter 

WARN_ON() takes a condition, not an error message.  I slightly tweaked
some conditions so hopefully it's more clear.

Signed-off-by: Dan Carpenter 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/pblk-read.c | 12 ++--
 drivers/lightnvm/pblk-recovery.c |  2 +-
 drivers/lightnvm/pblk-write.c|  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index eff0982..bce7ed5 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -49,8 +49,8 @@ static void pblk_read_ppalist_rq(struct pblk *pblk, struct 
nvm_rq *rqd,
int i, j = 0;
 
/* logic error: lba out-of-bounds. Ignore read request */
-   if (!(blba + nr_secs < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lbas out of bounds\n");
+   if (blba + nr_secs >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lbas out of bounds\n");
return;
}
 
@@ -254,8 +254,8 @@ static void pblk_read_rq(struct pblk *pblk, struct nvm_rq 
*rqd,
sector_t lba = pblk_get_lba(bio);
 
/* logic error: lba out-of-bounds. Ignore read request */
-   if (!(lba < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lba out of bounds\n");
+   if (lba >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lba out of bounds\n");
return;
}
 
@@ -411,8 +411,8 @@ static int read_rq_gc(struct pblk *pblk, struct nvm_rq *rqd,
int valid_secs = 0;
 
/* logic error: lba out-of-bounds */
-   if (!(lba < pblk->rl.nr_secs)) {
-   WARN_ON("pblk: read lba out of bounds\n");
+   if (lba >= pblk->rl.nr_secs) {
+   WARN(1, "pblk: read lba out of bounds\n");
goto out;
}
 
diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
index 0d50f41..f8f8508 100644
--- a/drivers/lightnvm/pblk-recovery.c
+++ b/drivers/lightnvm/pblk-recovery.c
@@ -167,7 +167,7 @@ static int pblk_recov_l2p_from_emeta(struct pblk *pblk, 
struct pblk_line *line)
if (le64_to_cpu(lba_list[i]) == ADDR_EMPTY) {
spin_lock(>lock);
if (test_and_set_bit(i, line->invalid_bitmap))
-   WARN_ON_ONCE("pblk: rec. double invalidate:\n");
+   WARN_ONCE(1, "pblk: rec. double invalidate:\n");
else
line->vsc--;
spin_unlock(>lock);
diff --git a/drivers/lightnvm/pblk-write.c b/drivers/lightnvm/pblk-write.c
index ee57db9..74f7413 100644
--- a/drivers/lightnvm/pblk-write.c
+++ b/drivers/lightnvm/pblk-write.c
@@ -141,7 +141,7 @@ static void pblk_end_w_fail(struct pblk *pblk, struct 
nvm_rq *rqd)
 
/* Logic error */
if (bit > c_ctx->nr_valid) {
-   WARN_ON_ONCE("pblk: corrupted write request\n");
+   WARN_ONCE(1, "pblk: corrupted write request\n");
goto out;
}
 
-- 
2.9.3

[GIT PULL 12/19] lightnvm: make nvm_free static

[Matias Bjørling]

From: Javier González 

Prefix the nvm_free static function with a missing static keyword.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index a63b563..eb9ab1a 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -999,7 +999,7 @@ static int nvm_core_init(struct nvm_dev *dev)
return ret;
 }
 
-void nvm_free(struct nvm_dev *dev)
+static void nvm_free(struct nvm_dev *dev)
 {
if (!dev)
return;
-- 
2.9.3

[GIT PULL 12/19] lightnvm: make nvm_free static

[Matias Bjørling]

From: Javier González 

Prefix the nvm_free static function with a missing static keyword.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index a63b563..eb9ab1a 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -999,7 +999,7 @@ static int nvm_core_init(struct nvm_dev *dev)
return ret;
 }
 
-void nvm_free(struct nvm_dev *dev)
+static void nvm_free(struct nvm_dev *dev)
 {
if (!dev)
return;
-- 
2.9.3

[GIT PULL 13/19] lightnvm: clean unused variable

[Matias Bjørling]

From: Javier González 

Clean unused variable on lightnvm core.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index eb9ab1a..258007a 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -501,7 +501,6 @@ void nvm_part_to_tgt(struct nvm_dev *dev, sector_t *entries,
int *lun_roffs;
struct ppa_addr gaddr;
u64 pba = le64_to_cpu(entries[i]);
-   int off;
u64 diff;
 
if (!pba)
@@ -511,8 +510,6 @@ void nvm_part_to_tgt(struct nvm_dev *dev, sector_t *entries,
ch_rmap = _rmap->chnls[gaddr.g.ch];
lun_roffs = ch_rmap->lun_offs;
 
-   off = gaddr.g.ch * geo->luns_per_chnl + gaddr.g.lun;
-
diff = ((ch_rmap->ch_off * geo->luns_per_chnl) +
(lun_roffs[gaddr.g.lun])) * geo->sec_per_lun;
 
-- 
2.9.3

[GIT PULL 11/19] lightnvm: allow to init targets on factory mode

[Matias Bjørling]

From: Javier González 

Target initialization has two responsibilities: creating the target
partition and instantiating the target. This patch enables to create a
factory partition (e.g., do not trigger recovery on the given target).
This is useful for target development and for being able to restore the
device state at any moment in time without requiring a full-device
erase.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/core.c   | 14 +++---
 drivers/lightnvm/rrpc.c   |  3 ++-
 include/linux/lightnvm.h  |  3 ++-
 include/uapi/linux/lightnvm.h |  4 
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5f84d2a..a63b563 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -280,7 +280,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
tdisk->fops = _fops;
tdisk->queue = tqueue;
 
-   targetdata = tt->init(tgt_dev, tdisk);
+   targetdata = tt->init(tgt_dev, tdisk, create->flags);
if (IS_ERR(targetdata))
goto err_init;
 
@@ -1244,8 +1244,16 @@ static long nvm_ioctl_dev_create(struct file *file, void 
__user *arg)
create.tgtname[DISK_NAME_LEN - 1] = '\0';
 
if (create.flags != 0) {
-   pr_err("nvm: no flags supported\n");
-   return -EINVAL;
+   __u32 flags = create.flags;
+
+   /* Check for valid flags */
+   if (flags & NVM_TARGET_FACTORY)
+   flags &= ~NVM_TARGET_FACTORY;
+
+   if (flags) {
+   pr_err("nvm: flag not supported\n");
+   return -EINVAL;
+   }
}
 
return __nvm_configure_create();
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index a8acf9e..5dba544 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -1506,7 +1506,8 @@ static int rrpc_luns_configure(struct rrpc *rrpc)
 
 static struct nvm_tgt_type tt_rrpc;
 
-static void *rrpc_init(struct nvm_tgt_dev *dev, struct gendisk *tdisk)
+static void *rrpc_init(struct nvm_tgt_dev *dev, struct gendisk *tdisk,
+  int flags)
 {
struct request_queue *bqueue = dev->q;
struct request_queue *tqueue = tdisk->queue;
diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
index eff7d1f..7dfa56e 100644
--- a/include/linux/lightnvm.h
+++ b/include/linux/lightnvm.h
@@ -436,7 +436,8 @@ static inline int ppa_cmp_blk(struct ppa_addr ppa1, struct 
ppa_addr ppa2)
 
 typedef blk_qc_t (nvm_tgt_make_rq_fn)(struct request_queue *, struct bio *);
 typedef sector_t (nvm_tgt_capacity_fn)(void *);
-typedef void *(nvm_tgt_init_fn)(struct nvm_tgt_dev *, struct gendisk *);
+typedef void *(nvm_tgt_init_fn)(struct nvm_tgt_dev *, struct gendisk *,
+   int flags);
 typedef void (nvm_tgt_exit_fn)(void *);
 typedef int (nvm_tgt_sysfs_init_fn)(struct gendisk *);
 typedef void (nvm_tgt_sysfs_exit_fn)(struct gendisk *);
diff --git a/include/uapi/linux/lightnvm.h b/include/uapi/linux/lightnvm.h
index fd19f36..c8aec4b 100644
--- a/include/uapi/linux/lightnvm.h
+++ b/include/uapi/linux/lightnvm.h
@@ -85,6 +85,10 @@ struct nvm_ioctl_create_conf {
};
 };
 
+enum {
+   NVM_TARGET_FACTORY = 1 << 0,/* Init target in factory mode */
+};
+
 struct nvm_ioctl_create {
char dev[DISK_NAME_LEN];/* open-channel SSD device */
char tgttype[NVM_TTYPE_NAME_MAX];   /* target type name */
-- 
2.9.3