Re: "isert: isert_setup_id: rdma_bind_addr() failed: -19" spam, followed by Recursive Fault on reboot

[Stevie Trujillo]

On Sun, 29 Jan 2017 09:39:39 +0200
Sagi Grimberg  wrote:

Hello, thank you very much for your help. I'm very sorry but I think
I've made too many changes to my system to recreate the problem.
I tried recreating my targtetcli config and downgrading
linux+userspace+firmware to the versions I used when it broke, but
never got this problem again :(

> > I'm trying (failing) to get iSER working. After rebooting with some
> > settings saved in targetcli, I got an endless stream of messages
> > like this:
> >
> > [  192.701299] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.702733] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.704021] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.705458] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.706979] isert: isert_setup_id: rdma_bind_addr() failed: -19  
> 
> You get -ENODEV errors because you don't have an RDMA device.
> This is probably due to the fact that the mlx5_ib (or mlx4_ib,
> depending on your device) is not loaded.
> 
> Can you try loading mlx[4|5]_ib module before you enable iser on
> a network portal?
> 
> I do see that mlx5 and mlx4 are requesting the mlx_ib module at probe
> time, I wander how that didn't happen on your system..
> 
> I didn't see a endless loop of this error? can you share your
> targetcli json?
> 
> > I tried deleting everything from targetcli, but the flood would not
> > stop. The ib_isert module did not unload. When rebooting I got a
> > "Recursive Fault" with a stacktrace inside configfs.
> >
> > I hope this is enough information to fix this bug. I assumed the
> > stacktrace would be saved to the log so I didn't write it down, and
> > I haven't been able to retrace all the wrong stuff I did trying to
> > make iSER work.
> >
> > Linux Version: Linux 4.8.15-2~bpo8+2 (Debian 8 Backports)  
> 
> Would it be possible to try with upstream kernel and report what you
> are seeing?

Re: "isert: isert_setup_id: rdma_bind_addr() failed: -19" spam, followed by Recursive Fault on reboot

[Stevie Trujillo]

On Sun, 29 Jan 2017 09:39:39 +0200
Sagi Grimberg  wrote:

Hello, thank you very much for your help. I'm very sorry but I think
I've made too many changes to my system to recreate the problem.
I tried recreating my targtetcli config and downgrading
linux+userspace+firmware to the versions I used when it broke, but
never got this problem again :(

> > I'm trying (failing) to get iSER working. After rebooting with some
> > settings saved in targetcli, I got an endless stream of messages
> > like this:
> >
> > [  192.701299] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.702733] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.704021] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.705458] isert: isert_setup_id: rdma_bind_addr() failed: -19
> > [  192.706979] isert: isert_setup_id: rdma_bind_addr() failed: -19  
> 
> You get -ENODEV errors because you don't have an RDMA device.
> This is probably due to the fact that the mlx5_ib (or mlx4_ib,
> depending on your device) is not loaded.
> 
> Can you try loading mlx[4|5]_ib module before you enable iser on
> a network portal?
> 
> I do see that mlx5 and mlx4 are requesting the mlx_ib module at probe
> time, I wander how that didn't happen on your system..
> 
> I didn't see a endless loop of this error? can you share your
> targetcli json?
> 
> > I tried deleting everything from targetcli, but the flood would not
> > stop. The ib_isert module did not unload. When rebooting I got a
> > "Recursive Fault" with a stacktrace inside configfs.
> >
> > I hope this is enough information to fix this bug. I assumed the
> > stacktrace would be saved to the log so I didn't write it down, and
> > I haven't been able to retrace all the wrong stuff I did trying to
> > make iSER work.
> >
> > Linux Version: Linux 4.8.15-2~bpo8+2 (Debian 8 Backports)  
> 
> Would it be possible to try with upstream kernel and report what you
> are seeing?

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ov5640>;
> + clocks = <_xclk>;
> + clock-names = "xclk";
> + reg = <0x40>;
> + xclk = <2200>;
> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> + pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;

How do you envision a four-lane sensor being described?

data-lanes = <0 1 3 4>;
clock-lanes = <2>;

?

The binding document for video-interfaces.txt says:

- clock-lanes: an array of physical clock lane indexes. Position of an entry
  determines the logical lane number, while the value of an entry indicates
  physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
  which places the clock lane on hardware lane 0. This property is valid for
  serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
  array contains only one entry.

So I think you need to have a good reason to make the clock lane non-zero.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ov5640>;
> + clocks = <_xclk>;
> + clock-names = "xclk";
> + reg = <0x40>;
> + xclk = <2200>;
> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> + pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;

How do you envision a four-lane sensor being described?

data-lanes = <0 1 3 4>;
clock-lanes = <2>;

?

The binding document for video-interfaces.txt says:

- clock-lanes: an array of physical clock lane indexes. Position of an entry
  determines the logical lane number, while the value of an entry indicates
  physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
  which places the clock lane on hardware lane 0. This property is valid for
  serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
  array contains only one entry.

So I think you need to have a good reason to make the clock lane non-zero.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] clk: add more managed APIs

[Guenter Roeck]

On Mon, Jan 30, 2017 at 09:42:28PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
> > Maybe the additional calls make sense; I can imagine they would.
> > However, I personally would be a bit wary of changing the initialization
> > order of multi-clock initializations, and I am not sure how a single call
> > could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
> > seems like a bit too much).
> > 
> > [ On a side note, why is there no clk_get_prepare_enable() and
> >   clk_get_prepare() ? Maybe it would be better to introduce those
> >   together with the matching devm_ functions in a separate patch
> >   if they are useful. ]
> 
> If you take the view that trying to keep clocks disabled is a good way
> to save power, then you'd have the clk_prepare() or maybe
> clk_prepare_enable() in your runtime PM resume handler, or maybe even
> deeper in the driver... the original design goal of the clk API was to
> allow power saving and clock control.
> 
> With that in mind, getting and enabling the clock together in the
> probe function didn't make sense.
> 
> I feel that aspect has been somewhat lost, and people now regard much
> of the clk API as a bit of a probe-time nusience.
> 

While I understand what you are saying, I think just focusing on power
savings paints a bit of a simplistic view of the clock API and its use.
Power saving is not its only use case. In a system where power saving isn't
the highest priority (say, in a high end switch), it is still extremely
valuable, providing a unified API to the clocks in the system (and there
are lots of clocks in a high end switch). Having seen what happens if there
is _no_ unified API (ie a complete mess of per-clock-driver calls all over
the place), I consider this as at least as or even more important than its
power savings potential. In this use case, one would normally both get and
enable the clock (or, much more likely, clocks) in the probe function.
One would also need remove functions, since interfaces in a high end switch
are typically OIR capable.

For my part, I stumbled over the lack of devm functions for clock APIs recently
when trying to convert watchdog drivers to use devm functions where possible.
Many watchdog drivers do use the clock API to only enable the clock when the
watchdog is actually running. However, there are several which prepare and
enable the clock at probe time, and disable/unprepare on remove. Would it be
possible to convert those to only prepare/enable the clocks if the watchdog
is actually enabled ? Possibly, but I am sure that there are cases where that
is not possible, or feasible. Either way, watchdog drivers are usually only
loaded when actually used, so trying to optimize clock usage would often be
more pain than it is worth.

When I did that conversion, I started out using devm_add_action_or_reset().
While that does work, it was pointed out that using devm functions for the
clock APIs would be a much better solution. As it turns out, devm_add_action()
and devm_add_action_or_reset() is already being used by various drivers to
work around the lack of devm functions for the clock API. With that in mind,
have a choice to make - we can continue forcing people to do that, or we can
introduce devm functions. My vote is for the latter.

Thanks,
Guenter

Re: [PATCH v2] clk: add more managed APIs

[Guenter Roeck]

On Mon, Jan 30, 2017 at 09:42:28PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
> > Maybe the additional calls make sense; I can imagine they would.
> > However, I personally would be a bit wary of changing the initialization
> > order of multi-clock initializations, and I am not sure how a single call
> > could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
> > seems like a bit too much).
> > 
> > [ On a side note, why is there no clk_get_prepare_enable() and
> >   clk_get_prepare() ? Maybe it would be better to introduce those
> >   together with the matching devm_ functions in a separate patch
> >   if they are useful. ]
> 
> If you take the view that trying to keep clocks disabled is a good way
> to save power, then you'd have the clk_prepare() or maybe
> clk_prepare_enable() in your runtime PM resume handler, or maybe even
> deeper in the driver... the original design goal of the clk API was to
> allow power saving and clock control.
> 
> With that in mind, getting and enabling the clock together in the
> probe function didn't make sense.
> 
> I feel that aspect has been somewhat lost, and people now regard much
> of the clk API as a bit of a probe-time nusience.
> 

While I understand what you are saying, I think just focusing on power
savings paints a bit of a simplistic view of the clock API and its use.
Power saving is not its only use case. In a system where power saving isn't
the highest priority (say, in a high end switch), it is still extremely
valuable, providing a unified API to the clocks in the system (and there
are lots of clocks in a high end switch). Having seen what happens if there
is _no_ unified API (ie a complete mess of per-clock-driver calls all over
the place), I consider this as at least as or even more important than its
power savings potential. In this use case, one would normally both get and
enable the clock (or, much more likely, clocks) in the probe function.
One would also need remove functions, since interfaces in a high end switch
are typically OIR capable.

For my part, I stumbled over the lack of devm functions for clock APIs recently
when trying to convert watchdog drivers to use devm functions where possible.
Many watchdog drivers do use the clock API to only enable the clock when the
watchdog is actually running. However, there are several which prepare and
enable the clock at probe time, and disable/unprepare on remove. Would it be
possible to convert those to only prepare/enable the clocks if the watchdog
is actually enabled ? Possibly, but I am sure that there are cases where that
is not possible, or feasible. Either way, watchdog drivers are usually only
loaded when actually used, so trying to optimize clock usage would often be
more pain than it is worth.

When I did that conversion, I started out using devm_add_action_or_reset().
While that does work, it was pointed out that using devm functions for the
clock APIs would be a much better solution. As it turns out, devm_add_action()
and devm_add_action_or_reset() is already being used by various drivers to
work around the lack of devm functions for the clock API. With that in mind,
have a choice to make - we can continue forcing people to do that, or we can
introduce devm functions. My vote is for the latter.

Thanks,
Guenter

Re: [PATCH 1/2] device property: export code duplicating array of property entries

[Rafael J. Wysocki]

On 1/23/2017 11:46 PM, Dmitry Torokhov wrote:

On Mon, Jan 23, 2017 at 05:00:38PM +0200, Andy Shevchenko wrote:

On Sun, 2017-01-22 at 23:38 -0800, Dmitry Torokhov wrote:

When augmenting ACPI-enumerated devices with additional property data
based
on DMI info, a module has often several potential property sets, with
only
one being active on a given box. In order to save memory it should be
possible to mark everything and __initdata or __initconst, execute DMI
match early, and duplicate relevant properties. Then kernel will
discard
the rest of them.


Looks good to me.

Reviewed-by: Andy Shevchenko 

Couple of style nitpicks.


+struct property_entry *property_entries_dup(
+   const struct property_entry
*properties)

Can we use

struct propert_entry *
property_entries_dup(...)

?

Sure, will adjust. I also realized we'll need property_entries_free()
for proper cleanups. I'll repost the series.


Can you please CC it to linux-acpi while at that?  It will help to 
handle it.


Thanks,
Rafael

Re: [PATCH 1/2] device property: export code duplicating array of property entries

[Rafael J. Wysocki]

On 1/23/2017 11:46 PM, Dmitry Torokhov wrote:

On Mon, Jan 23, 2017 at 05:00:38PM +0200, Andy Shevchenko wrote:

On Sun, 2017-01-22 at 23:38 -0800, Dmitry Torokhov wrote:

When augmenting ACPI-enumerated devices with additional property data
based
on DMI info, a module has often several potential property sets, with
only
one being active on a given box. In order to save memory it should be
possible to mark everything and __initdata or __initconst, execute DMI
match early, and duplicate relevant properties. Then kernel will
discard
the rest of them.


Looks good to me.

Reviewed-by: Andy Shevchenko 

Couple of style nitpicks.


+struct property_entry *property_entries_dup(
+   const struct property_entry
*properties)

Can we use

struct propert_entry *
property_entries_dup(...)

?

Sure, will adjust. I also realized we'll need property_entries_free()
for proper cleanups. I'll repost the series.


Can you please CC it to linux-acpi while at that?  It will help to 
handle it.


Thanks,
Rafael

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Rafael J. Wysocki]

On 1/24/2017 2:33 AM, Sedat Dilek wrote:

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  wrote:

On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  wrote:

Hi,

I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).

I tried v4.10-rc1 and latest Linus tree up to...

commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"

Here we go...

[   29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[   29.636058] 1 lock held by Xorg/1500:
[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[   29.636111] Call Trace:
[   29.636120]  dump_stack+0x85/0xc2
[   29.636124]  ___might_sleep+0x196/0x260
[   29.636127]  __might_sleep+0x53/0xb0
[   29.636131]  __pm_runtime_resume+0x7a/0x90
[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[   29.636275]  ? trace_hardirqs_on+0xd/0x10
[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[   29.636347]  ? __might_fault+0x4e/0xb0
[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
[   29.636376]  ? __might_fault+0x4e/0xb0
[   29.636395]  drm_ioctl+0x206/0x450 [drm]
[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
[   29.636425]  ? __fget+0x5/0x200
[   29.636429]  do_vfs_ioctl+0x91/0x6f0
[   29.636431]  ? __fget+0x111/0x200
[   29.636433]  ? __fget+0x5/0x200
[   29.636436]  SyS_ioctl+0x79/0x90
[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6

On suspend/resume I see the same call trace.
[2] points to the "BUG" line.

Well, this appears to be an i915 issue, but not a serious one.

Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts.  If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).

Let me see if I the might_sleep_if() assertion in
__pm_runtime_resume(() can be moved to a better place.


Hi Rafael,

did you had a chance to look at this?
The problem still remains in Linux v4.10-rc5.


No, I didn't.

As I said, this is not a serious issue.

Thanks,
Rafael

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Rafael J. Wysocki]

On 1/24/2017 2:33 AM, Sedat Dilek wrote:

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  wrote:

On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  wrote:

Hi,

I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).

I tried v4.10-rc1 and latest Linus tree up to...

commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"

Here we go...

[   29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[   29.636058] 1 lock held by Xorg/1500:
[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[   29.636111] Call Trace:
[   29.636120]  dump_stack+0x85/0xc2
[   29.636124]  ___might_sleep+0x196/0x260
[   29.636127]  __might_sleep+0x53/0xb0
[   29.636131]  __pm_runtime_resume+0x7a/0x90
[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[   29.636275]  ? trace_hardirqs_on+0xd/0x10
[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[   29.636347]  ? __might_fault+0x4e/0xb0
[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
[   29.636376]  ? __might_fault+0x4e/0xb0
[   29.636395]  drm_ioctl+0x206/0x450 [drm]
[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
[   29.636425]  ? __fget+0x5/0x200
[   29.636429]  do_vfs_ioctl+0x91/0x6f0
[   29.636431]  ? __fget+0x111/0x200
[   29.636433]  ? __fget+0x5/0x200
[   29.636436]  SyS_ioctl+0x79/0x90
[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6

On suspend/resume I see the same call trace.
[2] points to the "BUG" line.

Well, this appears to be an i915 issue, but not a serious one.

Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts.  If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).

Let me see if I the might_sleep_if() assertion in
__pm_runtime_resume(() can be moved to a better place.


Hi Rafael,

did you had a chance to look at this?
The problem still remains in Linux v4.10-rc5.


No, I didn't.

As I said, this is not a serious issue.

Thanks,
Rafael

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

[Florian Fainelli]

On 01/25/2017 01:25 PM, Greg KH wrote:
> On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
>> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
>>>
>>> Back to the actual code that triggered this discussion, the whole
>>> purpose is just a safeguard. Given a device reference, we can assume
>>> that it is indeed the backing device for a net_device, and we could do a
>>> to_net_device() right away (and crash if someone did not write correct
>>> platform_data structures), or, by walking the device tree (the device
>>> driver model one) we can make sure it does belong in the proper class
>>> and this is indeed what we think it is.
>>
>> Greg, did Russell's explanation clarify things, or do you still think
>> this is completely bogus and we need to re design the whole thing?
>>
>> Just asking so I can try to resubmit just the preparatory parts or just
>> the whole thing.
> 
> Sorry, I haven't gotten back to this, it's lower on my list.  Should try
> to get to it tomorrow...

Greg, please give some feedback here, I can only produce new patches as
fast as I am given feedback, and I would really hate to miss the 4.11
merge window because we have been sleeping on this. If there is a need
to clarify things, I will be more than happy to try to provide information.

Thank you!
-- 
Florian

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

[Florian Fainelli]

On 01/25/2017 01:25 PM, Greg KH wrote:
> On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
>> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
>>>
>>> Back to the actual code that triggered this discussion, the whole
>>> purpose is just a safeguard. Given a device reference, we can assume
>>> that it is indeed the backing device for a net_device, and we could do a
>>> to_net_device() right away (and crash if someone did not write correct
>>> platform_data structures), or, by walking the device tree (the device
>>> driver model one) we can make sure it does belong in the proper class
>>> and this is indeed what we think it is.
>>
>> Greg, did Russell's explanation clarify things, or do you still think
>> this is completely bogus and we need to re design the whole thing?
>>
>> Just asking so I can try to resubmit just the preparatory parts or just
>> the whole thing.
> 
> Sorry, I haven't gotten back to this, it's lower on my list.  Should try
> to get to it tomorrow...

Greg, please give some feedback here, I can only produce new patches as
fast as I am given feedback, and I would really hate to miss the 4.11
merge window because we have been sleeping on this. If there is a need
to clarify things, I will be more than happy to try to provide information.

Thank you!
-- 
Florian

Re: [PATCH] printk: fix printk.devkmsg sysctl

[Borislav Petkov]

On Mon, Jan 30, 2017 at 06:03:18PM +0100, Borislav Petkov wrote:
> IOW, I'd like the user to know what she does and mean it. No sloppy
> inputs.

Ok, here's what I wanna do. I decided to do my own parsing on the write
path since proc_dostring() does not really allow me to look at the input
string. Here's what I have so far, I'll do some more testing tomorrow.

I know, the diff is practically unreadable so let me paste the whole
function here.

So this way I can really control which input is accepted and which not
without jumping through hoops and doing silly games with the length.

And of course I'm not saving/restoring strings like a crazy person.

:-)

Anyway, more fun tomorrow.

int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
  void __user *buffer, size_t *lenp, loff_t *ppos)
{
char tmp_str[DEVKMSG_STR_MAX_SIZE];
unsigned int setting;
int len, err;

if (!write) {
err = proc_dostring(table, write, buffer, lenp, ppos);
if (err)
return err;

return 0;
}

if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
return -EINVAL;

len = min_t(int, (int)*lenp, DEVKMSG_STR_MAX_SIZE);

memset(tmp_str, 0, DEVKMSG_STR_MAX_SIZE);

err = copy_from_user(tmp_str, buffer, len);
if (err)
return -EFAULT;

err = __control_devkmsg(tmp_str, );
if (err < 0)
return -EINVAL;

/* known string */
if (err == len)
goto assign;

/* known string with a trailing \n */
if ((err + 1 == len) && (tmp_str[len - 1] == '\n'))
goto assign;

return -EINVAL;

assign:
if (devkmsg_log != setting) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, tmp_str, err);
devkmsg_log = setting;
   }

return 0;
}

---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8b2696420abb..9bd84ca700d5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -102,19 +102,19 @@ enum devkmsg_log_masks {
 
 static unsigned int __read_mostly devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
 
-static int __control_devkmsg(char *str)
+static int __control_devkmsg(char *str, unsigned int *ret)
 {
if (!str)
return -EINVAL;
 
if (!strncmp(str, "on", 2)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_ON;
+   *ret = DEVKMSG_LOG_MASK_ON;
return 2;
} else if (!strncmp(str, "off", 3)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_OFF;
+   *ret = DEVKMSG_LOG_MASK_OFF;
return 3;
} else if (!strncmp(str, "ratelimit", 9)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
+   *ret = DEVKMSG_LOG_MASK_DEFAULT;
return 9;
}
return -EINVAL;
@@ -122,21 +122,25 @@ static int __control_devkmsg(char *str)
 
 static int __init control_devkmsg(char *str)
 {
-   if (__control_devkmsg(str) < 0)
+   unsigned int setting;
+
+   if (__control_devkmsg(str, ) < 0)
return 1;
 
/*
 * Set sysctl string accordingly:
 */
-   if (devkmsg_log == DEVKMSG_LOG_MASK_ON) {
+   if (setting == DEVKMSG_LOG_MASK_ON) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, "on", 2);
-   } else if (devkmsg_log == DEVKMSG_LOG_MASK_OFF) {
+   } else if (setting == DEVKMSG_LOG_MASK_OFF) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, "off", 3);
}
/* else "ratelimit" which is set by default. */
 
+   devkmsg_log = setting;
+
/*
 * Sysctl cannot change it anymore. The kernel command line setting of
 * this parameter is to force the setting to be permanent throughout the
@@ -154,37 +158,48 @@ char devkmsg_log_str[DEVKMSG_STR_MAX_SIZE] = "ratelimit";
 int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
  void __user *buffer, size_t *lenp, loff_t *ppos)
 {
-   char old_str[DEVKMSG_STR_MAX_SIZE];
-   unsigned int old;
-   int err;
+   char tmp_str[DEVKMSG_STR_MAX_SIZE];
+   unsigned int setting;
+   int len, err;
 
-   if (write) {
-   if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
-   return -EINVAL;
+   if (!write) {
+   err = proc_dostring(table, write, buffer, lenp, ppos);
+   if (err)
+   return err;
 
-   old = devkmsg_log;
-   strncpy(old_str, devkmsg_log_str, DEVKMSG_STR_MAX_SIZE);
+   return 0;
}
 
-   err = proc_dostring(table, write, buffer, lenp, ppos);
+   if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
+   return 

Re: [PATCH] printk: fix printk.devkmsg sysctl

[Borislav Petkov]

On Mon, Jan 30, 2017 at 06:03:18PM +0100, Borislav Petkov wrote:
> IOW, I'd like the user to know what she does and mean it. No sloppy
> inputs.

Ok, here's what I wanna do. I decided to do my own parsing on the write
path since proc_dostring() does not really allow me to look at the input
string. Here's what I have so far, I'll do some more testing tomorrow.

I know, the diff is practically unreadable so let me paste the whole
function here.

So this way I can really control which input is accepted and which not
without jumping through hoops and doing silly games with the length.

And of course I'm not saving/restoring strings like a crazy person.

:-)

Anyway, more fun tomorrow.

int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
  void __user *buffer, size_t *lenp, loff_t *ppos)
{
char tmp_str[DEVKMSG_STR_MAX_SIZE];
unsigned int setting;
int len, err;

if (!write) {
err = proc_dostring(table, write, buffer, lenp, ppos);
if (err)
return err;

return 0;
}

if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
return -EINVAL;

len = min_t(int, (int)*lenp, DEVKMSG_STR_MAX_SIZE);

memset(tmp_str, 0, DEVKMSG_STR_MAX_SIZE);

err = copy_from_user(tmp_str, buffer, len);
if (err)
return -EFAULT;

err = __control_devkmsg(tmp_str, );
if (err < 0)
return -EINVAL;

/* known string */
if (err == len)
goto assign;

/* known string with a trailing \n */
if ((err + 1 == len) && (tmp_str[len - 1] == '\n'))
goto assign;

return -EINVAL;

assign:
if (devkmsg_log != setting) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, tmp_str, err);
devkmsg_log = setting;
   }

return 0;
}

---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8b2696420abb..9bd84ca700d5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -102,19 +102,19 @@ enum devkmsg_log_masks {
 
 static unsigned int __read_mostly devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
 
-static int __control_devkmsg(char *str)
+static int __control_devkmsg(char *str, unsigned int *ret)
 {
if (!str)
return -EINVAL;
 
if (!strncmp(str, "on", 2)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_ON;
+   *ret = DEVKMSG_LOG_MASK_ON;
return 2;
} else if (!strncmp(str, "off", 3)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_OFF;
+   *ret = DEVKMSG_LOG_MASK_OFF;
return 3;
} else if (!strncmp(str, "ratelimit", 9)) {
-   devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
+   *ret = DEVKMSG_LOG_MASK_DEFAULT;
return 9;
}
return -EINVAL;
@@ -122,21 +122,25 @@ static int __control_devkmsg(char *str)
 
 static int __init control_devkmsg(char *str)
 {
-   if (__control_devkmsg(str) < 0)
+   unsigned int setting;
+
+   if (__control_devkmsg(str, ) < 0)
return 1;
 
/*
 * Set sysctl string accordingly:
 */
-   if (devkmsg_log == DEVKMSG_LOG_MASK_ON) {
+   if (setting == DEVKMSG_LOG_MASK_ON) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, "on", 2);
-   } else if (devkmsg_log == DEVKMSG_LOG_MASK_OFF) {
+   } else if (setting == DEVKMSG_LOG_MASK_OFF) {
memset(devkmsg_log_str, 0, DEVKMSG_STR_MAX_SIZE);
strncpy(devkmsg_log_str, "off", 3);
}
/* else "ratelimit" which is set by default. */
 
+   devkmsg_log = setting;
+
/*
 * Sysctl cannot change it anymore. The kernel command line setting of
 * this parameter is to force the setting to be permanent throughout the
@@ -154,37 +158,48 @@ char devkmsg_log_str[DEVKMSG_STR_MAX_SIZE] = "ratelimit";
 int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
  void __user *buffer, size_t *lenp, loff_t *ppos)
 {
-   char old_str[DEVKMSG_STR_MAX_SIZE];
-   unsigned int old;
-   int err;
+   char tmp_str[DEVKMSG_STR_MAX_SIZE];
+   unsigned int setting;
+   int len, err;
 
-   if (write) {
-   if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
-   return -EINVAL;
+   if (!write) {
+   err = proc_dostring(table, write, buffer, lenp, ppos);
+   if (err)
+   return err;
 
-   old = devkmsg_log;
-   strncpy(old_str, devkmsg_log_str, DEVKMSG_STR_MAX_SIZE);
+   return 0;
}
 
-   err = proc_dostring(table, write, buffer, lenp, ppos);
+   if (devkmsg_log & DEVKMSG_LOG_MASK_LOCK)
+   return 

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:522: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:522: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[GIT] Sparc

[David Miller]

Several small bug fixes and tidies, along with a fix for non-resumable
memory errors triggered by userspace.

Please pull, thanks a lot!

The following changes since commit ba6d973f78eb62ffebb32f6ef3334fc9a3b33d22:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-12-20 
15:48:34 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

for you to fetch changes up to 54791b276b4000b307339f269d3bf7db877d536f:

  Merge branch 'sparc64-non-resumable-user-error-recovery' (2017-01-30 14:28:22 
-0800)


David S. Miller (1):
  Merge branch 'sparc64-non-resumable-user-error-recovery'

Liam R. Howlett (2):
  sparc64: Zero pages on allocation for mondo and error queues.
  sparc64: Handle PIO & MEM non-resumable errors.

Mike Kravetz (1):
  sparc: use symbolic names for tsb indexing

Tom Hromatka (1):
  sparc: Fixed typo in sstate.c. Replaced panicing with panicking

 arch/sparc/include/asm/mmu_context_64.h |  8 
 arch/sparc/kernel/irq_64.c  |  2 +-
 arch/sparc/kernel/sstate.c  |  6 +++---
 arch/sparc/kernel/traps_64.c| 73 
+
 4 files changed, 81 insertions(+), 8 deletions(-)

[GIT] Sparc

[David Miller]

Several small bug fixes and tidies, along with a fix for non-resumable
memory errors triggered by userspace.

Please pull, thanks a lot!

The following changes since commit ba6d973f78eb62ffebb32f6ef3334fc9a3b33d22:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-12-20 
15:48:34 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

for you to fetch changes up to 54791b276b4000b307339f269d3bf7db877d536f:

  Merge branch 'sparc64-non-resumable-user-error-recovery' (2017-01-30 14:28:22 
-0800)


David S. Miller (1):
  Merge branch 'sparc64-non-resumable-user-error-recovery'

Liam R. Howlett (2):
  sparc64: Zero pages on allocation for mondo and error queues.
  sparc64: Handle PIO & MEM non-resumable errors.

Mike Kravetz (1):
  sparc: use symbolic names for tsb indexing

Tom Hromatka (1):
  sparc: Fixed typo in sstate.c. Replaced panicing with panicking

 arch/sparc/include/asm/mmu_context_64.h |  8 
 arch/sparc/kernel/irq_64.c  |  2 +-
 arch/sparc/kernel/sstate.c  |  6 +++---
 arch/sparc/kernel/traps_64.c| 73 
+
 4 files changed, 81 insertions(+), 8 deletions(-)

[PATCH v13 1/2] serial: exar: split out the exar code from 8250_pci

[Sudip Mukherjee]

From: Sudip Mukherjee 

Add the serial driver for the Exar chips. And also register the
platform device for the GPIO provided by the Exar chips.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sudip Mukherjee 
---

Andy,
I have added the if (!board) check, but I am not sure how board can be
NULL here. If probe executes that will mean there was a match of the
device id and so in that case board can not be NULL.

 drivers/tty/serial/8250/8250_exar.c | 396 
 drivers/tty/serial/8250/Kconfig |   4 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 401 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
new file mode 100644
index 000..ba1f359
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -0,0 +1,396 @@
+/*
+ *  Probe module for 8250/16550-type Exar chips PCI serial ports.
+ *
+ *  Based on drivers/tty/serial/8250/8250_pci.c,
+ *
+ *  Copyright (C) 2017 Sudip Mukherjee, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "8250.h"
+
+#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
+#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
+#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
+#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
+
+#define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
+#define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
+#define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
+#define UART_EXAR_MPIOINV_7_0  0x92/* MPIOINV[7:0] */
+#define UART_EXAR_MPIOSEL_7_0  0x93/* MPIOSEL[7:0] */
+#define UART_EXAR_MPIOOD_7_0   0x94/* MPIOOD[7:0] */
+#define UART_EXAR_MPIOINT_15_8 0x95/* MPIOINT[15:8] */
+#define UART_EXAR_MPIOLVL_15_8 0x96/* MPIOLVL[15:8] */
+#define UART_EXAR_MPIO3T_15_8  0x97/* MPIO3T[15:8] */
+#define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
+#define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
+#define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
+
+struct exar8250;
+
+/**
+ * struct exar8250_board - board information
+ * @num_ports: number of serial ports
+ * @reg_shift: describes UART register mapping in PCI memory
+ */
+struct exar8250_board {
+   unsigned int num_ports;
+   unsigned int reg_shift;
+   bool has_slave;
+   int (*setup)(struct exar8250 *, struct pci_dev *,
+struct uart_8250_port *, int);
+   void(*exit)(struct pci_dev *pcidev);
+};
+
+struct exar8250 {
+   unsigned intnr;
+   struct exar8250_board   *board;
+   int line[0];
+};
+
+static int default_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+int idx, unsigned int offset,
+struct uart_8250_port *port)
+{
+   const struct exar8250_board *board = priv->board;
+   unsigned int bar = 0;
+
+   port->port.iotype = UPIO_MEM;
+   port->port.mapbase = pci_resource_start(pcidev, bar) + offset;
+   port->port.membase = pcim_iomap_table(pcidev)[bar] + offset;
+   port->port.regshift = board->reg_shift;
+
+   return 0;
+}
+
+static int
+pci_connect_tech_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+  struct uart_8250_port *port, int idx)
+{
+   unsigned int offset = idx * 0x200;
+   unsigned int baud = 1843200;
+
+   port->port.uartclk = baud * 16;
+   return default_setup(priv, pcidev, idx, offset, port);
+}
+
+static int
+pci_xr17c154_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+  struct uart_8250_port *port, int idx)
+{
+   unsigned int offset = idx * 0x200;
+   unsigned int baud = 921600;
+
+   port->port.uartclk = baud * 16;
+   return default_setup(priv, pcidev, idx, offset, port);
+}
+
+static void setup_gpio(u8 __iomem *p)
+{
+   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
+   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
+   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
+}
+
+static void *
+xr17v35x_register_gpio(struct pci_dev 

[PATCH v13 1/2] serial: exar: split out the exar code from 8250_pci

[Sudip Mukherjee]

From: Sudip Mukherjee 

Add the serial driver for the Exar chips. And also register the
platform device for the GPIO provided by the Exar chips.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sudip Mukherjee 
---

Andy,
I have added the if (!board) check, but I am not sure how board can be
NULL here. If probe executes that will mean there was a match of the
device id and so in that case board can not be NULL.

 drivers/tty/serial/8250/8250_exar.c | 396 
 drivers/tty/serial/8250/Kconfig |   4 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 401 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
new file mode 100644
index 000..ba1f359
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -0,0 +1,396 @@
+/*
+ *  Probe module for 8250/16550-type Exar chips PCI serial ports.
+ *
+ *  Based on drivers/tty/serial/8250/8250_pci.c,
+ *
+ *  Copyright (C) 2017 Sudip Mukherjee, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "8250.h"
+
+#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
+#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
+#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
+#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
+
+#define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
+#define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
+#define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
+#define UART_EXAR_MPIOINV_7_0  0x92/* MPIOINV[7:0] */
+#define UART_EXAR_MPIOSEL_7_0  0x93/* MPIOSEL[7:0] */
+#define UART_EXAR_MPIOOD_7_0   0x94/* MPIOOD[7:0] */
+#define UART_EXAR_MPIOINT_15_8 0x95/* MPIOINT[15:8] */
+#define UART_EXAR_MPIOLVL_15_8 0x96/* MPIOLVL[15:8] */
+#define UART_EXAR_MPIO3T_15_8  0x97/* MPIO3T[15:8] */
+#define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
+#define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
+#define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
+
+struct exar8250;
+
+/**
+ * struct exar8250_board - board information
+ * @num_ports: number of serial ports
+ * @reg_shift: describes UART register mapping in PCI memory
+ */
+struct exar8250_board {
+   unsigned int num_ports;
+   unsigned int reg_shift;
+   bool has_slave;
+   int (*setup)(struct exar8250 *, struct pci_dev *,
+struct uart_8250_port *, int);
+   void(*exit)(struct pci_dev *pcidev);
+};
+
+struct exar8250 {
+   unsigned intnr;
+   struct exar8250_board   *board;
+   int line[0];
+};
+
+static int default_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+int idx, unsigned int offset,
+struct uart_8250_port *port)
+{
+   const struct exar8250_board *board = priv->board;
+   unsigned int bar = 0;
+
+   port->port.iotype = UPIO_MEM;
+   port->port.mapbase = pci_resource_start(pcidev, bar) + offset;
+   port->port.membase = pcim_iomap_table(pcidev)[bar] + offset;
+   port->port.regshift = board->reg_shift;
+
+   return 0;
+}
+
+static int
+pci_connect_tech_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+  struct uart_8250_port *port, int idx)
+{
+   unsigned int offset = idx * 0x200;
+   unsigned int baud = 1843200;
+
+   port->port.uartclk = baud * 16;
+   return default_setup(priv, pcidev, idx, offset, port);
+}
+
+static int
+pci_xr17c154_setup(struct exar8250 *priv, struct pci_dev *pcidev,
+  struct uart_8250_port *port, int idx)
+{
+   unsigned int offset = idx * 0x200;
+   unsigned int baud = 921600;
+
+   port->port.uartclk = baud * 16;
+   return default_setup(priv, pcidev, idx, offset, port);
+}
+
+static void setup_gpio(u8 __iomem *p)
+{
+   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
+   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
+   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
+   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
+   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
+}
+
+static void *
+xr17v35x_register_gpio(struct pci_dev *pcidev)
+{
+   struct platform_device *pdev;
+
+   pdev = 

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

[Peter Griffin]

Hi Lee,

On Mon, 30 Jan 2017, Lee Jones wrote:

> On Mon, 30 Jan 2017, Peter Griffin wrote:
> > On Mon, 30 Jan 2017, Lee Jones wrote:
> > > On Mon, 30 Jan 2017, Peter Griffin wrote:
> > > > On Fri, 27 Jan 2017, Lee Jones wrote:
> > > > > On Wed, 25 Jan 2017, Peter Griffin wrote:
> > > > > > On Tue, 24 Jan 2017, Lee Jones wrote:
> > > > > > 
> > > > > > > There are now 2 possible separate/different Pinctrl states which 
> > > > > > > can
> > > > > > > be provided from platform data.  One which encompasses the lines
> > > > > > > required for HW flow-control (CTS/RTS) and another which does not
> > > > > > > specify these lines, such that they can be used via GPIO 
> > > > > > > mechanisms
> > > > > > > for manually toggling (i.e. from a request by `stty`).
> > > > > > > 
> > > > > > > Signed-off-by: Lee Jones 
> > > > > > > ---
> > > > > > >  drivers/tty/serial/st-asc.c | 28 
> > > > > > >  1 file changed, 28 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/tty/serial/st-asc.c 
> > > > > > > b/drivers/tty/serial/st-asc.c
> > > > > > > index 397df50..03801ed 100644
> > > > > > > --- a/drivers/tty/serial/st-asc.c
> > > > > > > +++ b/drivers/tty/serial/st-asc.c
> 
> [...]
> 
> > > > > > > + pinctrl_lookup_state(ascport->pinctrl, "manual-rts");
> > > > > > > + if (IS_ERR(ascport->states[MANUAL_RTS]))
> > > > > > > + ascport->states[MANUAL_RTS] = NULL;
> > > > > > > +
> > > > > > 
> > > > > > The different pinctrl states looks like a neat solution to the 
> > > > > > problem.
> > > > > > 
> > > > > > My only concern here is that 'default' state is implying a 
> > > > > > hw-flow-control
> > > > > > pinmux config, and manual-rts is implying what is the current 
> > > > > > upstream
> > > > > > 'default' pinmux config.
> > > > > > 
> > > > > > Which maybe ok if you update all uarts, but currently only serial0
> > > > > > is updated. So the other uarts current 'default' is actually the 
> > > > > > same as serial0
> > > > > > 'manual-rts' grouping, which conceptually is odd.
> > > > > > 
> > > > > > Would it not be better to make 'manual-rts' the default state? As 
> > > > > > that aligns
> > > > > > to what is currently already the default for the other UARTS? And 
> > > > > > then make
> > > > > > hw-flow-control the optional state for serial0?
> > > > > > 
> > > > > > That also has the advantage that 'default' has the same meaning 
> > > > > > with older DT's.
> > > > > 
> > > > > The reason it was done is this was because none of the other UARTs
> > > > > require 2 separate Pinctrl configurations, only this one.  Moreover,
> > > > > if they support RTS/CTS then I believe that the lines should be
> > > > > defined in Pinctrl.
> > > > 
> > > > Yes I agree with that.
> > > > 
> > > > > Thus, it was my plan to update all UART's default
> > > > > Pinctrl configs to include the RTS/CTS lines.
> > > > > 
> > > > 
> > > > I still don't see the point in changing the meaning of 'default' group 
> > > > and breaking
> > > > ABI if you don't need to?
> > > > 
> > > > As far as I can tell if you swap the meaning of 'default' and 
> > > > 'maunal-rts'
> > > > groups you get all the benefits of this series whilst also maintaining 
> > > > backwards
> > > > compatbility with older DT's.
> > > 
> > > What makes you think this will break ABI?
> > 
> > I've not tried it, but an older DT defines one group, 'default' which 
> > contains
> > the same pin config as your new optional 'manual-rts' group.
> > 
> > The driver now reads like the manual-rts pin config is optional and should 
> > be stored in
> > ascport->states[MANUAL_RTS]. An older DT will pass that same pin config as 
> > the default
> > group and it will be stored in ascport->states[DEFAULT].
> > 
> > That seems wrong to me, and if it executes OK it wouldn't be what you
> > expect by reading the code.
> 
> This makes no sense at a functional level.
> 
> Old kernel, old DTB:
> 
> ASC driver doesn't understand Pinctrl, but since only the "default"
> state is defined, that's what will be used as a matter of course.
> RTS/CTS aren't configured, but that doesn't matter because the DTS
> does not advertise that HW flow-control is available.  In this
> use-case neither HW flow-control, nor manual toggling of the RTS line
> is possible.
> 
> New kernel, old DTB:
> 
> ASC driver demands "default" and requests "manual-rts" Pinctrl states,
> but "manual-rts" isn't available so "default" will be the only
> utilised state.  Unlike the first example above, "default" now
> contains the RTS and CTS lines,

No it doesn't, default just contains 'tx' & 'rx' pins, as it has always
done until now.

Which is IMO where the condusion arises, as it is the same pin configuration
as what you are now calling 'manual-rts' which the driver just tried and failed
to obtain (although in reality it has actually obtained those pins but stored
them in DEFAULT instead.

I presume this is why it didn't make sense to you above.

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

[Peter Griffin]

Hi Lee,

On Mon, 30 Jan 2017, Lee Jones wrote:

> On Mon, 30 Jan 2017, Peter Griffin wrote:
> > On Mon, 30 Jan 2017, Lee Jones wrote:
> > > On Mon, 30 Jan 2017, Peter Griffin wrote:
> > > > On Fri, 27 Jan 2017, Lee Jones wrote:
> > > > > On Wed, 25 Jan 2017, Peter Griffin wrote:
> > > > > > On Tue, 24 Jan 2017, Lee Jones wrote:
> > > > > > 
> > > > > > > There are now 2 possible separate/different Pinctrl states which 
> > > > > > > can
> > > > > > > be provided from platform data.  One which encompasses the lines
> > > > > > > required for HW flow-control (CTS/RTS) and another which does not
> > > > > > > specify these lines, such that they can be used via GPIO 
> > > > > > > mechanisms
> > > > > > > for manually toggling (i.e. from a request by `stty`).
> > > > > > > 
> > > > > > > Signed-off-by: Lee Jones 
> > > > > > > ---
> > > > > > >  drivers/tty/serial/st-asc.c | 28 
> > > > > > >  1 file changed, 28 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/tty/serial/st-asc.c 
> > > > > > > b/drivers/tty/serial/st-asc.c
> > > > > > > index 397df50..03801ed 100644
> > > > > > > --- a/drivers/tty/serial/st-asc.c
> > > > > > > +++ b/drivers/tty/serial/st-asc.c
> 
> [...]
> 
> > > > > > > + pinctrl_lookup_state(ascport->pinctrl, "manual-rts");
> > > > > > > + if (IS_ERR(ascport->states[MANUAL_RTS]))
> > > > > > > + ascport->states[MANUAL_RTS] = NULL;
> > > > > > > +
> > > > > > 
> > > > > > The different pinctrl states looks like a neat solution to the 
> > > > > > problem.
> > > > > > 
> > > > > > My only concern here is that 'default' state is implying a 
> > > > > > hw-flow-control
> > > > > > pinmux config, and manual-rts is implying what is the current 
> > > > > > upstream
> > > > > > 'default' pinmux config.
> > > > > > 
> > > > > > Which maybe ok if you update all uarts, but currently only serial0
> > > > > > is updated. So the other uarts current 'default' is actually the 
> > > > > > same as serial0
> > > > > > 'manual-rts' grouping, which conceptually is odd.
> > > > > > 
> > > > > > Would it not be better to make 'manual-rts' the default state? As 
> > > > > > that aligns
> > > > > > to what is currently already the default for the other UARTS? And 
> > > > > > then make
> > > > > > hw-flow-control the optional state for serial0?
> > > > > > 
> > > > > > That also has the advantage that 'default' has the same meaning 
> > > > > > with older DT's.
> > > > > 
> > > > > The reason it was done is this was because none of the other UARTs
> > > > > require 2 separate Pinctrl configurations, only this one.  Moreover,
> > > > > if they support RTS/CTS then I believe that the lines should be
> > > > > defined in Pinctrl.
> > > > 
> > > > Yes I agree with that.
> > > > 
> > > > > Thus, it was my plan to update all UART's default
> > > > > Pinctrl configs to include the RTS/CTS lines.
> > > > > 
> > > > 
> > > > I still don't see the point in changing the meaning of 'default' group 
> > > > and breaking
> > > > ABI if you don't need to?
> > > > 
> > > > As far as I can tell if you swap the meaning of 'default' and 
> > > > 'maunal-rts'
> > > > groups you get all the benefits of this series whilst also maintaining 
> > > > backwards
> > > > compatbility with older DT's.
> > > 
> > > What makes you think this will break ABI?
> > 
> > I've not tried it, but an older DT defines one group, 'default' which 
> > contains
> > the same pin config as your new optional 'manual-rts' group.
> > 
> > The driver now reads like the manual-rts pin config is optional and should 
> > be stored in
> > ascport->states[MANUAL_RTS]. An older DT will pass that same pin config as 
> > the default
> > group and it will be stored in ascport->states[DEFAULT].
> > 
> > That seems wrong to me, and if it executes OK it wouldn't be what you
> > expect by reading the code.
> 
> This makes no sense at a functional level.
> 
> Old kernel, old DTB:
> 
> ASC driver doesn't understand Pinctrl, but since only the "default"
> state is defined, that's what will be used as a matter of course.
> RTS/CTS aren't configured, but that doesn't matter because the DTS
> does not advertise that HW flow-control is available.  In this
> use-case neither HW flow-control, nor manual toggling of the RTS line
> is possible.
> 
> New kernel, old DTB:
> 
> ASC driver demands "default" and requests "manual-rts" Pinctrl states,
> but "manual-rts" isn't available so "default" will be the only
> utilised state.  Unlike the first example above, "default" now
> contains the RTS and CTS lines,

No it doesn't, default just contains 'tx' & 'rx' pins, as it has always
done until now.

Which is IMO where the condusion arises, as it is the same pin configuration
as what you are now calling 'manual-rts' which the driver just tried and failed
to obtain (although in reality it has actually obtained those pins but stored
them in DEFAULT instead.

I presume this is why it didn't make sense to you above.

>but since the DTS 

Re: [PATCH v3 19/24] media: imx: Add IC subdev drivers

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:37PM -0800, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
> 
> - Pre-processing Encode task: video frames are routed directly from
>   the CSI and can be scaled, color-space converted, and rotated.
>   Scaled output is limited to 1024x1024 resolution. Output frames
>   are routed to the camera interface entities (camif).
> 
> - Pre-processing Viewfinder task: this task can perform the same
>   conversions as the pre-process encode task, but in addition can
>   be used for hardware motion compensated deinterlacing. Frames can
>   come either directly from the CSI or from the SMFC entities (memory
>   buffers via IDMAC channels). Scaled output is limited to 1024x1024
>   resolution. Output frames can be routed to various sinks including
>   the post-processing task entities.
> 
> - Post-processing task: same conversions as pre-process encode. However
>   this entity sends frames to the i.MX IPU image converter which supports
>   image tiling, which allows scaled output up to 4096x4096 resolution.
>   Output frames can be routed to the camera interfaces.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add IC subdev drivers
.git/rebase-apply/patch:3054: new blank line at EOF.
+
warning: 1 line adds whitespace errors.


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 19/24] media: imx: Add IC subdev drivers

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:37PM -0800, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
> 
> - Pre-processing Encode task: video frames are routed directly from
>   the CSI and can be scaled, color-space converted, and rotated.
>   Scaled output is limited to 1024x1024 resolution. Output frames
>   are routed to the camera interface entities (camif).
> 
> - Pre-processing Viewfinder task: this task can perform the same
>   conversions as the pre-process encode task, but in addition can
>   be used for hardware motion compensated deinterlacing. Frames can
>   come either directly from the CSI or from the SMFC entities (memory
>   buffers via IDMAC channels). Scaled output is limited to 1024x1024
>   resolution. Output frames can be routed to various sinks including
>   the post-processing task entities.
> 
> - Post-processing task: same conversions as pre-process encode. However
>   this entity sends frames to the i.MX IPU image converter which supports
>   image tiling, which allows scaled output up to 4096x4096 resolution.
>   Output frames can be routed to the camera interfaces.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: imx: Add IC subdev drivers
.git/rebase-apply/patch:3054: new blank line at EOF.
+
warning: 1 line adds whitespace errors.


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v13 2/2] serial: 8250_pci: remove exar code

[Sudip Mukherjee]

From: Sudip Mukherjee 

Remove the Exar specific codes from 8250_pci and blacklist those chips
so that the new Exar serial driver binds to the devices.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sudip Mukherjee 
---
 drivers/tty/serial/8250/8250_pci.c | 336 +
 drivers/tty/serial/8250/Kconfig|   1 +
 2 files changed, 4 insertions(+), 333 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index f7ee4e0..3eb638c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1610,9 +1610,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #endif
 }
 
-#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
-#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
-
 #define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
 #define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
 #define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
@@ -1625,71 +1622,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
 #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
-
-static int
-pci_xr17c154_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   port->port.flags |= UPF_EXAR_EFR;
-   return pci_default_setup(priv, board, port, idx);
-}
-
-static inline int
-xr17v35x_has_slave(struct serial_private *priv)
-{
-   const int dev_id = priv->dev->device;
-
-   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
-   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
-}
-
-static int
-pci_xr17v35x_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   u8 __iomem *p;
-
-   p = pci_ioremap_bar(priv->dev, 0);
-   if (p == NULL)
-   return -ENOMEM;
-
-   port->port.flags |= UPF_EXAR_EFR;
-
-   /*
-* Setup the uart clock for the devices on expansion slot to
-* half the clock speed of the main chip (which is 125MHz)
-*/
-   if (xr17v35x_has_slave(priv) && idx >= 8)
-   port->port.uartclk = (7812500 * 16 / 2);
-
-   /*
-* Setup Multipurpose Input/Output pins.
-*/
-   if (idx == 0) {
-   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
-   }
-   writeb(0x00, p + UART_EXAR_8XMODE);
-   writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
-   writeb(128, p + UART_EXAR_TXTRG);
-   writeb(128, p + UART_EXAR_RXTRG);
-   iounmap(p);
-
-   return pci_default_setup(priv, board, port, idx);
-}
-
 #define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
 #define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
 #define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -1814,9 +1746,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define PCI_VENDOR_ID_AGESTAR  0x5372
 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
 #define PCI_VENDOR_ID_ASIX 0x9710
-#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
-#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
-#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
 #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a
 #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e
 
@@ -2278,65 +2207,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
.setup  = pci_timedia_setup,
},
/*
-* Exar cards
-*/
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C152,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C154,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C158,
-   .subvendor  = PCI_ANY_ID,
-

[PATCH v13 2/2] serial: 8250_pci: remove exar code

[Sudip Mukherjee]

From: Sudip Mukherjee 

Remove the Exar specific codes from 8250_pci and blacklist those chips
so that the new Exar serial driver binds to the devices.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sudip Mukherjee 
---
 drivers/tty/serial/8250/8250_pci.c | 336 +
 drivers/tty/serial/8250/Kconfig|   1 +
 2 files changed, 4 insertions(+), 333 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index f7ee4e0..3eb638c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1610,9 +1610,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #endif
 }
 
-#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
-#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
-
 #define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
 #define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
 #define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
@@ -1625,71 +1622,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
 #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
-
-static int
-pci_xr17c154_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   port->port.flags |= UPF_EXAR_EFR;
-   return pci_default_setup(priv, board, port, idx);
-}
-
-static inline int
-xr17v35x_has_slave(struct serial_private *priv)
-{
-   const int dev_id = priv->dev->device;
-
-   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
-   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
-}
-
-static int
-pci_xr17v35x_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   u8 __iomem *p;
-
-   p = pci_ioremap_bar(priv->dev, 0);
-   if (p == NULL)
-   return -ENOMEM;
-
-   port->port.flags |= UPF_EXAR_EFR;
-
-   /*
-* Setup the uart clock for the devices on expansion slot to
-* half the clock speed of the main chip (which is 125MHz)
-*/
-   if (xr17v35x_has_slave(priv) && idx >= 8)
-   port->port.uartclk = (7812500 * 16 / 2);
-
-   /*
-* Setup Multipurpose Input/Output pins.
-*/
-   if (idx == 0) {
-   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
-   }
-   writeb(0x00, p + UART_EXAR_8XMODE);
-   writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
-   writeb(128, p + UART_EXAR_TXTRG);
-   writeb(128, p + UART_EXAR_RXTRG);
-   iounmap(p);
-
-   return pci_default_setup(priv, board, port, idx);
-}
-
 #define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
 #define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
 #define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -1814,9 +1746,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define PCI_VENDOR_ID_AGESTAR  0x5372
 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
 #define PCI_VENDOR_ID_ASIX 0x9710
-#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
-#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
-#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
 #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a
 #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e
 
@@ -2278,65 +2207,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
.setup  = pci_timedia_setup,
},
/*
-* Exar cards
-*/
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C152,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C154,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C158,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
- 

Re: [PATCH] sparc32: mm: srmmu: add __ro_after_init to sparc32_cachetlb_ops structures

[David Miller]

From: Bhumika Goyal 
Date: Sat, 14 Jan 2017 18:01:54 +0530

> The objects viking_ops, viking_sun4d_smp_ops and smp_cachetlb_ops of
> type sparc32_cachetlb_ops are not modified anywhere after getting modified 
> in the init functions. Inside init their reference is also stored in a
> pointer of type const struct sparc32_cachetlb_ops *. So these structures 
> are never modified after init, therefore add __ro_after to the declaration 
> of these structures.
> 
> Signed-off-by: Bhumika Goyal 

Applied, thanks.

Re: [PATCH] sparc32: mm: srmmu: add __ro_after_init to sparc32_cachetlb_ops structures

[David Miller]

From: Bhumika Goyal 
Date: Sat, 14 Jan 2017 18:01:54 +0530

> The objects viking_ops, viking_sun4d_smp_ops and smp_cachetlb_ops of
> type sparc32_cachetlb_ops are not modified anywhere after getting modified 
> in the init functions. Inside init their reference is also stored in a
> pointer of type const struct sparc32_cachetlb_ops *. So these structures 
> are never modified after init, therefore add __ro_after to the declaration 
> of these structures.
> 
> Signed-off-by: Bhumika Goyal 

Applied, thanks.

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
> 
> Signed-off-by: Steve Longerbeam 

warning: 3 lines add whitespace errors.
Applying: media: imx: Add CSI subdev driver
.git/rebase-apply/patch:38: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
> 
> Signed-off-by: Steve Longerbeam 

warning: 3 lines add whitespace errors.
Applying: media: imx: Add CSI subdev driver
.git/rebase-apply/patch:38: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:516: new blank line at EOF.
+
.git/rebase-apply/patch:528: new blank line at EOF.
+
.git/rebase-apply/patch:556: new blank line at EOF.
+
warning: 3 lines add whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:516: new blank line at EOF.
+
.git/rebase-apply/patch:528: new blank line at EOF.
+
.git/rebase-apply/patch:556: new blank line at EOF.
+
warning: 3 lines add whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
> b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +52,9 @@
>   {
>   status = "okay";
>  };
> +
> +_csi1_from_mipi_vc1 {
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> +};
> +
> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> index 795b5a5..bca9fed 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
...
> +/* Incoming port from sensor */
> +_csi_from_mipi_sensor {
> +remote-endpoint = <_to_mipi_csi>;
> +data-lanes = <0 1>;
> +clock-lanes = <2>;
> +};
> +

Applying: ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
.git/rebase-apply/patch:33: new blank line at EOF.
+
.git/rebase-apply/patch:201: new blank line at EOF.
+
warning: 2 lines add whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
> b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +52,9 @@
>   {
>   status = "okay";
>  };
> +
> +_csi1_from_mipi_vc1 {
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> +};
> +
> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> index 795b5a5..bca9fed 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
...
> +/* Incoming port from sensor */
> +_csi_from_mipi_sensor {
> +remote-endpoint = <_to_mipi_csi>;
> +data-lanes = <0 1>;
> +clock-lanes = <2>;
> +};
> +

Applying: ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
.git/rebase-apply/patch:33: new blank line at EOF.
+
.git/rebase-apply/patch:201: new blank line at EOF.
+
warning: 2 lines add whitespace errors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] clk: add more managed APIs

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 01:58:05PM -0800, Dmitry Torokhov wrote:
> FWIW I do not think that kitchen sink calls, like
> "devm_clk_get_prepare_set_rate_enable" are helpful. Resource
> acquisition and use of said resource are logically separate.

That alone is an argument against devm_clk_get_prepare_enable() in
so far that drivers should really get all their resources before
they start to enable anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] clk: add more managed APIs

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 01:58:05PM -0800, Dmitry Torokhov wrote:
> FWIW I do not think that kitchen sink calls, like
> "devm_clk_get_prepare_set_rate_enable" are helpful. Resource
> acquisition and use of said resource are logically separate.

That alone is an argument against devm_clk_get_prepare_enable() in
so far that drivers should really get all their resources before
they start to enable anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

[Pavel Machek]

Hi!

I'm a bit late to the party...

> Example:
> Imagine a receiver with a limit of 1024 handles. A sender transmits a
> message to that receiver. It gets access to half the limit not used by
> anyone else, hence 512 handles. It does not matter how many senders
> there are, nor how many messages are sent, it will reach its quota at
> 512. As long as they all belong to the same user, they will share the
> quota and can queue at most 512 handles. If a second sending user
> comes into play, it gets half the remaining not used by anyone else,
> which ends up being 256. And so on... If the peer dequeues messages in
> between, the numbers get higher again. But if you do the math, the
> most you can get is 50% of the targets resources, if you're the only
> sender. In all other cases you get less (like intertwined transfers,
> etc).
> 
> We did look into sender-based inflight accounting, but the same set of
> issues arises. Sure, a Request+Reply model would make this easier to
> handle, but we want to explicitly support a Subscribe+Event{n} model.
> In this case there is more than one Reply to a message.
> 
> Long story short: We have uid<->uid quotas so far, which prevent DoS
> attacks, unless you get access to a ridiculous amount of local UIDs.
> Details on which resources are accounted can be found in the wiki
> [1].

So if there's limit of 1024 handles, all I need is 10 UIDs, right?

That might be a problem on multiuser unix machine, but on Android
phones, each application gets its own UID. So all you need is 10
applications to bring the system down...
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: [RFC v1 00/14] Bus1 Kernel Message Bus

[Pavel Machek]

Hi!

I'm a bit late to the party...

> Example:
> Imagine a receiver with a limit of 1024 handles. A sender transmits a
> message to that receiver. It gets access to half the limit not used by
> anyone else, hence 512 handles. It does not matter how many senders
> there are, nor how many messages are sent, it will reach its quota at
> 512. As long as they all belong to the same user, they will share the
> quota and can queue at most 512 handles. If a second sending user
> comes into play, it gets half the remaining not used by anyone else,
> which ends up being 256. And so on... If the peer dequeues messages in
> between, the numbers get higher again. But if you do the math, the
> most you can get is 50% of the targets resources, if you're the only
> sender. In all other cases you get less (like intertwined transfers,
> etc).
> 
> We did look into sender-based inflight accounting, but the same set of
> issues arises. Sure, a Request+Reply model would make this easier to
> handle, but we want to explicitly support a Subscribe+Event{n} model.
> In this case there is more than one Reply to a message.
> 
> Long story short: We have uid<->uid quotas so far, which prevent DoS
> attacks, unless you get access to a ridiculous amount of local UIDs.
> Details on which resources are accounted can be found in the wiki
> [1].

So if there's limit of 1024 handles, all I need is 10 UIDs, right?

That might be a problem on multiuser unix machine, but on Android
phones, each application gets its own UID. So all you need is 10
applications to bring the system down...
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: [PATCH] phy: qcom-ufs: Fix misplaced jump label

[Kishon Vijay Abraham I]

On Friday 27 January 2017 01:40 PM, Vivek Gautam wrote:
> We want to skip only tx/rx_iface clocks and not ref_clk_src
> as well. Fix the jump label accordingly.
> 
> Fixes: 300f96771d78 ("phy: qcom-ufs: Skip obtaining rx/tx_iface_clk for 
> msm8996 based phy")

merged, thanks.

-Kishon
> 
> Cc: Subhash Jadavani 
> Cc: Martin K. Petersen 
> Cc: Kishon Vijay Abraham I 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vivek Gautam 
> ---
> 
> Based on linux-phy next.
> 
>  drivers/phy/phy-qcom-ufs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index c69568b8543d..1aee8723a682 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -189,12 +189,12 @@ int ufs_qcom_phy_init_clks(struct ufs_qcom_phy 
> *phy_common)
>   if (err)
>   goto out;
>  
> +skip_txrx_clk:
>   err = ufs_qcom_phy_clk_get(phy_common->dev, "ref_clk_src",
>  _common->ref_clk_src);
>   if (err)
>   goto out;
>  
> -skip_txrx_clk:
>   /*
>* "ref_clk_parent" is optional hence don't abort init if it's not
>* found.
> 

Re: [PATCH] phy: qcom-ufs: Fix misplaced jump label

[Kishon Vijay Abraham I]

On Friday 27 January 2017 01:40 PM, Vivek Gautam wrote:
> We want to skip only tx/rx_iface clocks and not ref_clk_src
> as well. Fix the jump label accordingly.
> 
> Fixes: 300f96771d78 ("phy: qcom-ufs: Skip obtaining rx/tx_iface_clk for 
> msm8996 based phy")

merged, thanks.

-Kishon
> 
> Cc: Subhash Jadavani 
> Cc: Martin K. Petersen 
> Cc: Kishon Vijay Abraham I 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vivek Gautam 
> ---
> 
> Based on linux-phy next.
> 
>  drivers/phy/phy-qcom-ufs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index c69568b8543d..1aee8723a682 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -189,12 +189,12 @@ int ufs_qcom_phy_init_clks(struct ufs_qcom_phy 
> *phy_common)
>   if (err)
>   goto out;
>  
> +skip_txrx_clk:
>   err = ufs_qcom_phy_clk_get(phy_common->dev, "ref_clk_src",
>  _common->ref_clk_src);
>   if (err)
>   goto out;
>  
> -skip_txrx_clk:
>   /*
>* "ref_clk_parent" is optional hence don't abort init if it's not
>* found.
> 

Re: [PATCH v2 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

[Magnus Damm]

Hi Joerg,

On Fri, Jan 27, 2017 at 8:47 PM, Joerg Roedel  wrote:
> On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Bump up the maximum numbers of micro-TLBS to 48.
>>
>> Each IPMMU device instance get micro-TLB assignment via
>> the "iommus" property in DT. Older SoCs tend to use a
>> maximum number of 32 micro-TLBs per IPMMU instance however
>> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
>>
>> At this point no SoC specific handling is done to validate
>> the maximum number of micro-TLBs, and because of that the
>> DT information is assumed to be within correct range for
>> each particular SoC.
>>
>> If needed in the future SoC specific feature flags can be
>> added to handle the maximum number of micro-TLBs without
>> requiring DT changes, however at this point this does not
>> seem necessary.
>>
>> Signed-off-by: Magnus Damm 
>
> I get a conflict when applying this to v4.10-rc5. What is this based on,
> any patches I missed?

Thanks for giving it a go. The second patch in this series should apply as-is:
[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding

However for driver code there are two series in between:
 [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6
 [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2

For more detailed dependency information please see the cover letter!

Regarding the driver code please wait for "IPMMU multi-arch update V7"
that takes comments from Laurent into consideration. Hopefully I
should be able to send it out some time this week.

As for "[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding",
would it be possible to fast track mainline merge of that particular
DT binding patch? Can you take it in your tree?

To give some background, we already have the IPMMU DT binding for
older devices and the sister device r8a7795 in mainline, so the
r8a7796 DT binding is just a small incremental step. To make sure we
don't go too wild with DT changes we tend to require that the DT
binding change should be queued up before starting to merge changes to
DTS files. So currently some DT changes are blocking on that r8a7796
DT binding and it would be nice to unblock those if possible..

Thanks!

/ magnus

Re: [PATCH v2 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

[Magnus Damm]

Hi Joerg,

On Fri, Jan 27, 2017 at 8:47 PM, Joerg Roedel  wrote:
> On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Bump up the maximum numbers of micro-TLBS to 48.
>>
>> Each IPMMU device instance get micro-TLB assignment via
>> the "iommus" property in DT. Older SoCs tend to use a
>> maximum number of 32 micro-TLBs per IPMMU instance however
>> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
>>
>> At this point no SoC specific handling is done to validate
>> the maximum number of micro-TLBs, and because of that the
>> DT information is assumed to be within correct range for
>> each particular SoC.
>>
>> If needed in the future SoC specific feature flags can be
>> added to handle the maximum number of micro-TLBs without
>> requiring DT changes, however at this point this does not
>> seem necessary.
>>
>> Signed-off-by: Magnus Damm 
>
> I get a conflict when applying this to v4.10-rc5. What is this based on,
> any patches I missed?

Thanks for giving it a go. The second patch in this series should apply as-is:
[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding

However for driver code there are two series in between:
 [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6
 [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2

For more detailed dependency information please see the cover letter!

Regarding the driver code please wait for "IPMMU multi-arch update V7"
that takes comments from Laurent into consideration. Hopefully I
should be able to send it out some time this week.

As for "[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding",
would it be possible to fast track mainline merge of that particular
DT binding patch? Can you take it in your tree?

To give some background, we already have the IPMMU DT binding for
older devices and the sister device r8a7795 in mainline, so the
r8a7796 DT binding is just a small incremental step. To make sure we
don't go too wild with DT changes we tend to require that the DT
binding change should be queued up before starting to merge changes to
DTS files. So currently some DT changes are blocking on that r8a7796
DT binding and it would be nice to unblock those if possible..

Thanks!

/ magnus

Re: [PATCH v2] drm: remove unnecessary fault wrappers

[Ross Zwisler]

On Mon, Jan 30, 2017 at 03:09:39PM -0700, Ross Zwisler wrote:

> This patch applies cleanly to mmots/master, which is currently at
> v4.10-rc5-mmots-2017-01-26-15-49.

Which may not be what you want...  The reason I was looking at this code was
because it was recently changed by Dave Jiang to remove the 'vma' argument
from all the fault handlers.

So, would you rather:

1) Take it through the -mm tree to avoid merge conflicts, in which case I'll
add akpm to the thread.

2) Take it through your tree & deal with merge conflicts later, in which case
I can rebase on your tree or on v4.10-rc6.

3) Just drop it and keep the extra 20 lines or whatever that the complier will
just optimize out.

I'm fine with any of the above.

Re: [PATCH v2] drm: remove unnecessary fault wrappers

[Ross Zwisler]

On Mon, Jan 30, 2017 at 03:09:39PM -0700, Ross Zwisler wrote:

> This patch applies cleanly to mmots/master, which is currently at
> v4.10-rc5-mmots-2017-01-26-15-49.

Which may not be what you want...  The reason I was looking at this code was
because it was recently changed by Dave Jiang to remove the 'vma' argument
from all the fault handlers.

So, would you rather:

1) Take it through the -mm tree to avoid merge conflicts, in which case I'll
add akpm to the thread.

2) Take it through your tree & deal with merge conflicts later, in which case
I can rebase on your tree or on v4.10-rc6.

3) Just drop it and keep the extra 20 lines or whatever that the complier will
just optimize out.

I'm fine with any of the above.

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[James Bottomley]

On Mon, 2017-01-30 at 23:45 +0200, Jarkko Sakkinen wrote:
> On Sun, Jan 29, 2017 at 02:36:58PM -0800, James Bottomley wrote:
[...]
> > > 2. Can it really return both TPM_RC_HANDLE and
> > > TPM_RC_REFERENCE_H0? 
> > 
> > Yes, it seems that a session that doesn't exist (because it's been
> > flushed) then it returns TPM_RC_REFERNCE_H0, but if the context has 
> > a sequence mismatch (because it's been flushed and reloaded) then 
> > we get TPM_RC_HANDLE.
> > 
> > James
> 
> If it is flushed, wouldn't you just get TPM_RC_REFERENCE_H0 when you 
> try to TPM2_ContextLoad? The "and reloaded" does not make sense to 
> me. Once a session is flushed it cannot be reloaded.
> 
> Maybe you meant to say "beause it's been saved and reloaded"? That 
> would make more sense and fits better what I see in the Commands 
> specification.

I mean if you load a prior context instead of the current one for an
existing handle, effectively a replay, you get TPM_RC_HANDLE.

James

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[James Bottomley]

On Mon, 2017-01-30 at 23:45 +0200, Jarkko Sakkinen wrote:
> On Sun, Jan 29, 2017 at 02:36:58PM -0800, James Bottomley wrote:
[...]
> > > 2. Can it really return both TPM_RC_HANDLE and
> > > TPM_RC_REFERENCE_H0? 
> > 
> > Yes, it seems that a session that doesn't exist (because it's been
> > flushed) then it returns TPM_RC_REFERNCE_H0, but if the context has 
> > a sequence mismatch (because it's been flushed and reloaded) then 
> > we get TPM_RC_HANDLE.
> > 
> > James
> 
> If it is flushed, wouldn't you just get TPM_RC_REFERENCE_H0 when you 
> try to TPM2_ContextLoad? The "and reloaded" does not make sense to 
> me. Once a session is flushed it cannot be reloaded.
> 
> Maybe you meant to say "beause it's been saved and reloaded"? That 
> would make more sense and fits better what I see in the Commands 
> specification.

I mean if you load a prior context instead of the current one for an
existing handle, effectively a replay, you get TPM_RC_HANDLE.

James

Re: [PATCH v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 25 Jan 2017 12:57:16 -0700

> +static inline void enable_adi(void)
> +{
 ...
> + __asm__ __volatile__(
> + "rdpr %%pstate, %%g1\n\t"
> + "or %%g1, %0, %%g1\n\t"
> + "wrpr %%g1, %%g0, %%pstate\n\t"
> + ".word 0x83438000\n\t"  /* rd %mcdper, %g1 */
> + ".word 0xaf91\n\t"  /* wrpr  %g0, %g1, %pmcdper */
> + :
> + : "i" (PSTATE_MCDE)
> + : "g1");
> +}

This is _crazy_ expensive.

This is 4 privileged register operations, every single one incurs a full
pipline flush and virtual cpu thread yield.

And we do this around _every_ single userspace access from the kernel
when the thread has ADI enabled.

I think if the kernel manages the ADI metadata properly, you can get rid
of all of this.

On etrap, you change ESTATE_PSTATE{1,2} to have the MCDE bit enabled.
Then the kernel always runs with ADI enabled.

Furthermore, since the %mcdper register should be set to whatever the
current task has asked for, you should be able to avoid touching it
as well assuming that traps do not change %mcdper's value.

Then you don't need to do anything special during userspace accesses
which seems to be the way this was designed to be used.

Re: [PATCH v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 25 Jan 2017 12:57:16 -0700

> +static inline void enable_adi(void)
> +{
 ...
> + __asm__ __volatile__(
> + "rdpr %%pstate, %%g1\n\t"
> + "or %%g1, %0, %%g1\n\t"
> + "wrpr %%g1, %%g0, %%pstate\n\t"
> + ".word 0x83438000\n\t"  /* rd %mcdper, %g1 */
> + ".word 0xaf91\n\t"  /* wrpr  %g0, %g1, %pmcdper */
> + :
> + : "i" (PSTATE_MCDE)
> + : "g1");
> +}

This is _crazy_ expensive.

This is 4 privileged register operations, every single one incurs a full
pipline flush and virtual cpu thread yield.

And we do this around _every_ single userspace access from the kernel
when the thread has ADI enabled.

I think if the kernel manages the ADI metadata properly, you can get rid
of all of this.

On etrap, you change ESTATE_PSTATE{1,2} to have the MCDE bit enabled.
Then the kernel always runs with ADI enabled.

Furthermore, since the %mcdper register should be set to whatever the
current task has asked for, you should be able to avoid touching it
as well assuming that traps do not change %mcdper's value.

Then you don't need to do anything special during userspace accesses
which seems to be the way this was designed to be used.

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[James Bottomley]

On Mon, 2017-01-30 at 23:58 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> > On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > > On 1/27/2017 5:04 PM, James Bottomley wrote:
> > > 
> > > > > Beware the nasty corner case:
> > > > > 
> > > > > - Application asks for a session and gets 0200
> > > > > 
> > > > > - Time elapses and 0200 gets forcibly flushed
> > > > > 
> > > > > - Later, app comes back, asks for a second session and again
> > > > > gets
> > > > > 0200.
> > > > > 
> > > > > - App gets very confused.
> > > > > 
> > > > > May it be better to close the connection completely, which
> > > > > the
> > > > > application can detect, than flush a session and give this
> > > > > corner
> > > > > case?
> > > > 
> > > > if I look at the code I've written, I don't know what the
> > > > session
> > > > number is, I just save sessionHandle in a variable for later
> > > > use 
> > > > (lets say to v1).  If I got the same session number returned at
> > > > a 
> > > > later time and placed it in v2, all I'd notice is that an 
> > > > authorization using v1 would fail.  I'm not averse to killing
> > > > the 
> > > > entire connection but, assuming you have fallback, it might be 
> > > > kinder simply to ensure that the operations with the reclaimed 
> > > > session fail (which is what the code currently does).
> > > 
> > > My worry is that this session failure cannot be detected by the 
> > > application.  An HMAC failure could cause the app to tell a user
> > > that
> > > they entered the wrong password.  Misleading.  On the TPM, it
> > > could 
> > > trigger the dictionary attack lockout.  For a PIN index, it could
> > > consume a failure count.  Killing a policy session that has e.g.,
> > > a 
> > > policy signed term could cause the application to go back to some
> > > external entity for another authorization signature.
> > > 
> > > Let's go up to the stack.  What's the attack?
> > > 
> > > If we're worried about many simultaneous applications (wouldn't
> > > that 
> > > be wonderful), why not just let startauthsession fail?  The 
> > > application can just retry periodically.
> > 
> > How in that scenario do we ensure that a session becomes available?
> >  Once that's established, there's no real difference between
> > retrying
> > the startauthsession in the kernel when we know the session is
> > available and forcing userspace to do the retry except that the
> > former
> > has a far greater chance of success (and it's only about 6 lines of
> > code).
> > 
> > >   Just allocate them in triples so there's no deadlock.
> > 
> > Is this the application or the kernel?  If it's the kernel, that
> > adds a
> > lot of complexity.
> > 
> > > If we're worried about a DoS attack, killing a session just helps
> > > the
> > > attacker.  The attacker can create a few connections and spin on 
> > > startauthsession, locking everyone out anyway.
> > 
> > There are two considerations here: firstly we'd need to introduce a
> > mechanism to "kill" the connection.  Probably we'd simply error
> > every
> > command on the space until it was closed.  The second is which
> > scenario
> > is more reasonable: Say the application simply forgot to flush the
> > session and will never use it again.  Simply reclaiming the session
> > would produce no effect at all on the application in this scenario.
> >  However, I have no data to say what's likely.
> > 
> > > ~~
> > > 
> > > Also, let's remember that this is a rare application.  Sessions
> > > are 
> > > only needed for remote access (requiring encryption, HMAC or
> > > salt), 
> > > or policy sessions.
> > 
> > This depends what your threat model is.  For ssh keys, you worry
> > that
> > someone might be watching, so you use HMAC authority even for a
> > local
> > TPM.  In the cloud, you don't quite know where the TPM is, so again
> > you'd use HMAC sessions ... however, in both use cases the sessions
> > should be very short lived.
> > 
> > > ~~
> > > 
> > > Should the code also reserve a session for the kernel?  Mark it
> > > not 
> > > kill'able?
> > 
> > At the moment, the kernel doesn't use sessions, so let's worry
> > about
> > that problem at the point it arises (if it ever arises).
> > 
> > James
> 
> It does. My trusted keys implementation actually uses sessions.

But as I read the code, I can't find where the kernel creates a
session.  It looks like the session and hmac are passed in as option
arguments, aren't they?

> I'm kind dilating to an opinion that we would leave this commit out 
> from the first kernel release that will contain the resource manager 
> with similar rationale as Jason gave me for whitelisting: get the 
> basic stuff in and once it is used with some workloads whitelisting 
> and exhaustion will take eventually the right form.
> 
> How would you feel about this?

As long as we get patch 1/2 then applications using sessions will
actually work with spaces, so taking more time with 

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[James Bottomley]

On Mon, 2017-01-30 at 23:58 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> > On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > > On 1/27/2017 5:04 PM, James Bottomley wrote:
> > > 
> > > > > Beware the nasty corner case:
> > > > > 
> > > > > - Application asks for a session and gets 0200
> > > > > 
> > > > > - Time elapses and 0200 gets forcibly flushed
> > > > > 
> > > > > - Later, app comes back, asks for a second session and again
> > > > > gets
> > > > > 0200.
> > > > > 
> > > > > - App gets very confused.
> > > > > 
> > > > > May it be better to close the connection completely, which
> > > > > the
> > > > > application can detect, than flush a session and give this
> > > > > corner
> > > > > case?
> > > > 
> > > > if I look at the code I've written, I don't know what the
> > > > session
> > > > number is, I just save sessionHandle in a variable for later
> > > > use 
> > > > (lets say to v1).  If I got the same session number returned at
> > > > a 
> > > > later time and placed it in v2, all I'd notice is that an 
> > > > authorization using v1 would fail.  I'm not averse to killing
> > > > the 
> > > > entire connection but, assuming you have fallback, it might be 
> > > > kinder simply to ensure that the operations with the reclaimed 
> > > > session fail (which is what the code currently does).
> > > 
> > > My worry is that this session failure cannot be detected by the 
> > > application.  An HMAC failure could cause the app to tell a user
> > > that
> > > they entered the wrong password.  Misleading.  On the TPM, it
> > > could 
> > > trigger the dictionary attack lockout.  For a PIN index, it could
> > > consume a failure count.  Killing a policy session that has e.g.,
> > > a 
> > > policy signed term could cause the application to go back to some
> > > external entity for another authorization signature.
> > > 
> > > Let's go up to the stack.  What's the attack?
> > > 
> > > If we're worried about many simultaneous applications (wouldn't
> > > that 
> > > be wonderful), why not just let startauthsession fail?  The 
> > > application can just retry periodically.
> > 
> > How in that scenario do we ensure that a session becomes available?
> >  Once that's established, there's no real difference between
> > retrying
> > the startauthsession in the kernel when we know the session is
> > available and forcing userspace to do the retry except that the
> > former
> > has a far greater chance of success (and it's only about 6 lines of
> > code).
> > 
> > >   Just allocate them in triples so there's no deadlock.
> > 
> > Is this the application or the kernel?  If it's the kernel, that
> > adds a
> > lot of complexity.
> > 
> > > If we're worried about a DoS attack, killing a session just helps
> > > the
> > > attacker.  The attacker can create a few connections and spin on 
> > > startauthsession, locking everyone out anyway.
> > 
> > There are two considerations here: firstly we'd need to introduce a
> > mechanism to "kill" the connection.  Probably we'd simply error
> > every
> > command on the space until it was closed.  The second is which
> > scenario
> > is more reasonable: Say the application simply forgot to flush the
> > session and will never use it again.  Simply reclaiming the session
> > would produce no effect at all on the application in this scenario.
> >  However, I have no data to say what's likely.
> > 
> > > ~~
> > > 
> > > Also, let's remember that this is a rare application.  Sessions
> > > are 
> > > only needed for remote access (requiring encryption, HMAC or
> > > salt), 
> > > or policy sessions.
> > 
> > This depends what your threat model is.  For ssh keys, you worry
> > that
> > someone might be watching, so you use HMAC authority even for a
> > local
> > TPM.  In the cloud, you don't quite know where the TPM is, so again
> > you'd use HMAC sessions ... however, in both use cases the sessions
> > should be very short lived.
> > 
> > > ~~
> > > 
> > > Should the code also reserve a session for the kernel?  Mark it
> > > not 
> > > kill'able?
> > 
> > At the moment, the kernel doesn't use sessions, so let's worry
> > about
> > that problem at the point it arises (if it ever arises).
> > 
> > James
> 
> It does. My trusted keys implementation actually uses sessions.

But as I read the code, I can't find where the kernel creates a
session.  It looks like the session and hmac are passed in as option
arguments, aren't they?

> I'm kind dilating to an opinion that we would leave this commit out 
> from the first kernel release that will contain the resource manager 
> with similar rationale as Jason gave me for whitelisting: get the 
> basic stuff in and once it is used with some workloads whitelisting 
> and exhaustion will take eventually the right form.
> 
> How would you feel about this?

As long as we get patch 1/2 then applications using sessions will
actually work with spaces, so taking more time with 

[PATCH v2] drm: remove unnecessary fault wrappers

[Ross Zwisler]

The fault wrappers drm_vm_fault(), drm_vm_shm_fault(), drm_vm_dma_fault()
and drm_vm_sg_fault() used to provide extra logic beyond what was in the
"drm_do_*" versions of these functions, but as of this commit:

commit ca0b07d9a969 ("drm: convert drm from nopage to fault.")

They are just unnecessary wrappers that do nothing.  Remove them, and
rename the the drm_do_* fault handlers to remove the "do_" since they no
longer have corresponding wrappers.

Signed-off-by: Ross Zwisler 
---

This patch applies cleanly to mmots/master, which is currently at
v4.10-rc5-mmots-2017-01-26-15-49.

---
 drivers/gpu/drm/drm_vm.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 0cd993a..039a1e0 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -95,7 +95,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct 
vm_area_struct *vma)
  * map, get the page, increment the use count and return it.
  */
 #if IS_ENABLED(CONFIG_AGP)
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -168,7 +168,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS; /* Disallow mremap */
 }
 #else
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
return VM_FAULT_SIGBUS;
 }
@@ -183,7 +183,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
  * Get the mapping, find the real physical page to map, get the page, and
  * return it.
  */
-static int drm_do_vm_shm_fault(struct vm_fault *vmf)
+static int drm_vm_shm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -285,7 +285,7 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
  *
  * Determine the page number from the page offset and get it from 
drm_device_dma::pagelist.
  */
-static int drm_do_vm_dma_fault(struct vm_fault *vmf)
+static int drm_vm_dma_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -320,7 +320,7 @@ static int drm_do_vm_dma_fault(struct vm_fault *vmf)
  *
  * Determine the map offset from the page offset and get it from 
drm_sg_mem::pagelist.
  */
-static int drm_do_vm_sg_fault(struct vm_fault *vmf)
+static int drm_vm_sg_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -347,26 +347,6 @@ static int drm_do_vm_sg_fault(struct vm_fault *vmf)
return 0;
 }
 
-static int drm_vm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_fault(vmf);
-}
-
-static int drm_vm_shm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_shm_fault(vmf);
-}
-
-static int drm_vm_dma_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_dma_fault(vmf);
-}
-
-static int drm_vm_sg_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_sg_fault(vmf);
-}
-
 /** AGP virtual memory operations */
 static const struct vm_operations_struct drm_vm_ops = {
.fault = drm_vm_fault,
-- 
2.7.4

[PATCH v2] drm: remove unnecessary fault wrappers

[Ross Zwisler]

The fault wrappers drm_vm_fault(), drm_vm_shm_fault(), drm_vm_dma_fault()
and drm_vm_sg_fault() used to provide extra logic beyond what was in the
"drm_do_*" versions of these functions, but as of this commit:

commit ca0b07d9a969 ("drm: convert drm from nopage to fault.")

They are just unnecessary wrappers that do nothing.  Remove them, and
rename the the drm_do_* fault handlers to remove the "do_" since they no
longer have corresponding wrappers.

Signed-off-by: Ross Zwisler 
---

This patch applies cleanly to mmots/master, which is currently at
v4.10-rc5-mmots-2017-01-26-15-49.

---
 drivers/gpu/drm/drm_vm.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 0cd993a..039a1e0 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -95,7 +95,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct 
vm_area_struct *vma)
  * map, get the page, increment the use count and return it.
  */
 #if IS_ENABLED(CONFIG_AGP)
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -168,7 +168,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS; /* Disallow mremap */
 }
 #else
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
return VM_FAULT_SIGBUS;
 }
@@ -183,7 +183,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
  * Get the mapping, find the real physical page to map, get the page, and
  * return it.
  */
-static int drm_do_vm_shm_fault(struct vm_fault *vmf)
+static int drm_vm_shm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -285,7 +285,7 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
  *
  * Determine the page number from the page offset and get it from 
drm_device_dma::pagelist.
  */
-static int drm_do_vm_dma_fault(struct vm_fault *vmf)
+static int drm_vm_dma_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -320,7 +320,7 @@ static int drm_do_vm_dma_fault(struct vm_fault *vmf)
  *
  * Determine the map offset from the page offset and get it from 
drm_sg_mem::pagelist.
  */
-static int drm_do_vm_sg_fault(struct vm_fault *vmf)
+static int drm_vm_sg_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -347,26 +347,6 @@ static int drm_do_vm_sg_fault(struct vm_fault *vmf)
return 0;
 }
 
-static int drm_vm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_fault(vmf);
-}
-
-static int drm_vm_shm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_shm_fault(vmf);
-}
-
-static int drm_vm_dma_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_dma_fault(vmf);
-}
-
-static int drm_vm_sg_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_sg_fault(vmf);
-}
-
 /** AGP virtual memory operations */
 static const struct vm_operations_struct drm_vm_ops = {
.fault = drm_vm_fault,
-- 
2.7.4

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Christopher Covington]

Hi Mark,

On 01/30/2017 05:56 AM, Mark Rutland wrote:
> Hi,
> 
> On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
>> On 01/27/2017 09:38 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> 
 Replacing the above sequence with the one below will ensure that no TLB
 entries with an incorrect ASID are used by software.

   write reserved value to TTBRx_EL1[ASID]
   ISB
   write new value to TTBRx_EL1[BADDR]
   ISB
   write new value to TTBRx_EL1[ASID]
   ISB

 When the above sequence is used, page table entries using the new BADDR
 value may still be incorrectly allocated into the TLB using the reserved
 ASID. Yet this will not reduce functionality, since TLB entries incorrectly
 tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> I agree that there should be no explicit accesses to the VAs for these
>>> entries. So tasks should not see erroneous VAs, and we shouldn't see
>>> synchronous TLB conflict aborts.
>>>
>>> Regardless, can this allow conflicting TLB entries to be allocated to
>>> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
>>> another has a 2M mapping which covers that VA, can both be allocated
>>> into the TLBs under the reserved ASID?
>>>
>>> Can that have any effect on asynchronous TLB lookups or page table
>>> walks, e.g. for speculated accesses?
>>
>> A speculative access that inserts an entry into the TLB could
>> possibly find the conflict but will not signal it. Does that answer
>> your question?
> 
> Yes!
> 
> The other case I was worried about was intermediate caching. I take it
> the values in TLBs are not used as part of subsequent page table walks?
> 
> If so, the above sounds fine to me.
> 
> Otherwise, we'll need additional TLB maintenance.

Errant TLB entries will not be used for any legitimate subsequent page
table walks.

I have some minor changes which I'll send as v5 based on
kernel/git/arm64/linux.git for-next/core.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Christopher Covington]

Hi Mark,

On 01/30/2017 05:56 AM, Mark Rutland wrote:
> Hi,
> 
> On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
>> On 01/27/2017 09:38 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> 
 Replacing the above sequence with the one below will ensure that no TLB
 entries with an incorrect ASID are used by software.

   write reserved value to TTBRx_EL1[ASID]
   ISB
   write new value to TTBRx_EL1[BADDR]
   ISB
   write new value to TTBRx_EL1[ASID]
   ISB

 When the above sequence is used, page table entries using the new BADDR
 value may still be incorrectly allocated into the TLB using the reserved
 ASID. Yet this will not reduce functionality, since TLB entries incorrectly
 tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> I agree that there should be no explicit accesses to the VAs for these
>>> entries. So tasks should not see erroneous VAs, and we shouldn't see
>>> synchronous TLB conflict aborts.
>>>
>>> Regardless, can this allow conflicting TLB entries to be allocated to
>>> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
>>> another has a 2M mapping which covers that VA, can both be allocated
>>> into the TLBs under the reserved ASID?
>>>
>>> Can that have any effect on asynchronous TLB lookups or page table
>>> walks, e.g. for speculated accesses?
>>
>> A speculative access that inserts an entry into the TLB could
>> possibly find the conflict but will not signal it. Does that answer
>> your question?
> 
> Yes!
> 
> The other case I was worried about was intermediate caching. I take it
> the values in TLBs are not used as part of subsequent page table walks?
> 
> If so, the above sounds fine to me.
> 
> Otherwise, we'll need additional TLB maintenance.

Errant TLB entries will not be used for any legitimate subsequent page
table walks.

I have some minor changes which I'll send as v5 based on
kernel/git/arm64/linux.git for-next/core.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH cgroup/for-4.11] cgroup: misc cleanups

[Tejun Heo]

On Fri, Jan 20, 2017 at 12:06:08PM -0500, Tejun Heo wrote:
> * cgrp_dfl_implicit_ss_mask is ulong instead of u16 unlike other
>   ss_masks.  Make it a u16.
> 
> * Move have_canfork_callback together with other callback ss_masks.
> 
> Signed-off-by: Tejun Heo 

Applied to cgroup/for-4.11.

Thanks.

-- 
tejun

Re: [PATCH cgroup/for-4.11] cgroup: misc cleanups

[Tejun Heo]

On Fri, Jan 20, 2017 at 12:06:08PM -0500, Tejun Heo wrote:
> * cgrp_dfl_implicit_ss_mask is ulong instead of u16 unlike other
>   ss_masks.  Make it a u16.
> 
> * Move have_canfork_callback together with other callback ss_masks.
> 
> Signed-off-by: Tejun Heo 

Applied to cgroup/for-4.11.

Thanks.

-- 
tejun

Re: Issue with i2c-designware-platdrv's suspend/runtime-suspend handling

[John Stultz]

On Tue, Jan 24, 2017 at 2:03 PM, John Stultz  wrote:
> I noticed that with my hikey board, on resume from suspend I'm getting
> the following WARNING:
>
> [   54.334054] [ cut here ]
> [   54.334077] WARNING: CPU: 0 PID: 2217 at drivers/clk/clk.c:594
> clk_core_disable+0x20/0x78
> [   54.334080]
> [   54.334090] CPU: 0 PID: 2217 Comm: system_server Not tainted
> 4.9.0-00046-gee9ec2c #2067
> [   54.334094] Hardware name: HiKey Development Board (DT)
> [   54.334099] task: ffc074863200 task.stack: ffc061d1c000
> [   54.334105] PC is at clk_core_disable+0x20/0x78
> [   54.334111] LR is at clk_core_disable_lock+0x20/0x38
> [   54.334116] pc : [] lr : []
> pstate: 81c5
> [   54.334119] sp : ffc061d1faf0
> [   54.334128] x29: ffc061d1faf0 x28: 
> [   54.334136] x27: 0002 x26: ff8008d47000
> [   54.334143] x25: ff8008596000 x24: ff8008d15498
> [   54.334151] x23: ff8008db9000 x22: ffc075074870
> [   54.334158] x21: 0002 x20: ffc005f09500
> [   54.334165] x19: 0140 x18: 0001
> [   54.334172] x17:  x16: 
> [   54.334180] x15: ffc005f43dc0 x14: 0001
> [   54.334187] x13: ff8008d906f8 x12: ff8008d15790
> [   54.334196] x11: ff8008d15000 x10: ff8008d8d000
> [   54.334204] x9 :  x8 : ffc077f26218
> [   54.334212] x7 :  x6 : 
> [   54.334220] x5 : ffc077f2b090 x4 : ffc061d1fa80
> [   54.334228] x3 : ff80084ab62c x2 : ff80084ab62c
> [   54.334236] x1 :  x0 : ffc005f09500
> [   54.334239]
> [   54.334243] ---[ end trace 6474a624fb2fd658 ]---
> [   54.334248] Call trace:
> [   54.334254] Exception stack(0xffc061d1f920 to 0xffc061d1fa50)
> [   54.334262] f920: 0140 0080
> ffc061d1faf0 ff80084ab728
> [   54.334269] f940: ff8008ccc090 ffc074863200
>  6f6674616c703d4d
> [   54.334276] f960: ffc061d1f970 ff8008087990
> ffc061d1f9b0 ff8008450c6c
> [   54.334283] f980: ff8008cc8000 ffc061d1fa90
> ff8008ccc090 ffc074863200
> [   54.334290] f9a0: ff8008db6170 ffc061d1fa08
> ffc061d1f9c0 ff8008087990
> [   54.334297] f9c0: ffc005f09500 
> ff80084ab62c ff80084ab62c
> [   54.334303] f9e0: ffc061d1fa80 ffc077f2b090
>  
> [   54.334310] fa00: ffc077f26218 
> ff8008d8d000 ff8008d15000
> [   54.334317] fa20: ff8008d15790 ff8008d906f8
> 0001 ffc005f43dc0
> [   54.334322] fa40:  
> [   54.334328] [] clk_core_disable+0x20/0x78
> [   54.334336] [] clk_disable+0x1c/0x30
> [   54.334349] [] i2c_dw_plat_prepare_clk.isra.0+0x44/0x80
> [   54.334356] [] dw_i2c_plat_suspend+0x24/0x38
> [   54.334367] [] platform_pm_suspend+0x24/0x58
> [   54.334377] [] dpm_run_callback.isra.7+0x20/0x68
> [   54.334385] [] __device_suspend+0x10c/0x298
> [   54.334393] [] dpm_suspend+0x10c/0x228
> [   54.334401] [] dpm_suspend_start+0x68/0x78
> [   54.334412] [] suspend_devices_and_enter+0xb8/0x458
> [   54.334419] [] pm_suspend+0x1ec/0x248
> [   54.334426] [] state_store+0x94/0xa8
> [   54.334434] [] kobj_attr_store+0x14/0x28
> [   54.33] [] sysfs_kf_write+0x48/0x58
> [   54.334451] [] kernfs_fop_write+0xb0/0x1d8
> [   54.334461] [] __vfs_write+0x1c/0x100
> [   54.334469] [] vfs_write+0xa0/0x1b8
> [   54.334477] [] SyS_write+0x44/0xa0
> [   54.334485] [] el0_svc_naked+0x24/0x28
>
>
> Doing some further debugging, it seems the problem is that the device
> is being runtime suspended, and then at suspend time, we're calling
> the same logic, calling i2c_dw_plat_prepare_clk, which causes the clk
> count warning.
>
> Removing the runtime pm ops:
> -   SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
> +// SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
>
> seems to avoid the warning, but clearly isn't ideal. :)
>
> Should there be some logic keep track of the suspend state for the
> dw_i2c_dev device so we don't try to suspend (or resume) it twice?  Or
> is there something else I'm missing to keep this from happening?

Ping? Any thoughts on how best to fix this?  I'm leaning towards
adding a suspended state to the struct dw_i2c_dev. Any objections?

thanks
-john

Re: Cherryview wake up events

[Andy Shevchenko]

On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach  wrote:
> On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote:
>> On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote:
>> > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach  
>> > wrote:
>> > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote:
>> >
>> > >> Had you tried to add ID to axp20x-i2c.c ?
>> > >
>> > > Nope, since I have no idea if the axp and TI hardware is similar.
>> >
>> > I think you would give a try.
>>
>> I'll check it.
>
> I checked the reference source code, my impression is the
> TI Dollar Cove and and AXP288 are completely different hardware.

Thanks for checking.

Yes, due to not obvious communication to PMIC. I suppose that the IP
core is quite similar in all of them, the difference is just how OS
and other MCUs in SoC communicate with it.

So, basically what it means that I2C direct communication is prohibited here.

>
>> > > [5.331709] i2c_designware 808622C1:06: controller timed out
>> > >
>> > This is known: http://www.spinics.net/lists/intel-gfx/msg117738.html
>
> Interestingly via this link I found Intel also published
> the TI DCove source in a patch series against an unspecified kernel:
> https://github.com/01org/ProductionKernelQuilts
> specifically
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
> and some more (the series is quite messy).
>
> For the Asus E200HA I'm not sure if the charger and coulomb
> counter drivers are needed since charging just works and
> the battery status is reported via ACPI.  It seems these
> drivers are only for tablets without ACPI support, right?

Have no idea.

What that code reminds me is MID family of devices. So, power button
is (reasonable) easy to get support of in that case.
Look into drivers/platform/x86/intel_mid_powerbtn.c. I recently
updated it to support Basin Cove on Intel Edison.

-- 
With Best Regards,
Andy Shevchenko

Re: Issue with i2c-designware-platdrv's suspend/runtime-suspend handling

[John Stultz]

On Tue, Jan 24, 2017 at 2:03 PM, John Stultz  wrote:
> I noticed that with my hikey board, on resume from suspend I'm getting
> the following WARNING:
>
> [   54.334054] [ cut here ]
> [   54.334077] WARNING: CPU: 0 PID: 2217 at drivers/clk/clk.c:594
> clk_core_disable+0x20/0x78
> [   54.334080]
> [   54.334090] CPU: 0 PID: 2217 Comm: system_server Not tainted
> 4.9.0-00046-gee9ec2c #2067
> [   54.334094] Hardware name: HiKey Development Board (DT)
> [   54.334099] task: ffc074863200 task.stack: ffc061d1c000
> [   54.334105] PC is at clk_core_disable+0x20/0x78
> [   54.334111] LR is at clk_core_disable_lock+0x20/0x38
> [   54.334116] pc : [] lr : []
> pstate: 81c5
> [   54.334119] sp : ffc061d1faf0
> [   54.334128] x29: ffc061d1faf0 x28: 
> [   54.334136] x27: 0002 x26: ff8008d47000
> [   54.334143] x25: ff8008596000 x24: ff8008d15498
> [   54.334151] x23: ff8008db9000 x22: ffc075074870
> [   54.334158] x21: 0002 x20: ffc005f09500
> [   54.334165] x19: 0140 x18: 0001
> [   54.334172] x17:  x16: 
> [   54.334180] x15: ffc005f43dc0 x14: 0001
> [   54.334187] x13: ff8008d906f8 x12: ff8008d15790
> [   54.334196] x11: ff8008d15000 x10: ff8008d8d000
> [   54.334204] x9 :  x8 : ffc077f26218
> [   54.334212] x7 :  x6 : 
> [   54.334220] x5 : ffc077f2b090 x4 : ffc061d1fa80
> [   54.334228] x3 : ff80084ab62c x2 : ff80084ab62c
> [   54.334236] x1 :  x0 : ffc005f09500
> [   54.334239]
> [   54.334243] ---[ end trace 6474a624fb2fd658 ]---
> [   54.334248] Call trace:
> [   54.334254] Exception stack(0xffc061d1f920 to 0xffc061d1fa50)
> [   54.334262] f920: 0140 0080
> ffc061d1faf0 ff80084ab728
> [   54.334269] f940: ff8008ccc090 ffc074863200
>  6f6674616c703d4d
> [   54.334276] f960: ffc061d1f970 ff8008087990
> ffc061d1f9b0 ff8008450c6c
> [   54.334283] f980: ff8008cc8000 ffc061d1fa90
> ff8008ccc090 ffc074863200
> [   54.334290] f9a0: ff8008db6170 ffc061d1fa08
> ffc061d1f9c0 ff8008087990
> [   54.334297] f9c0: ffc005f09500 
> ff80084ab62c ff80084ab62c
> [   54.334303] f9e0: ffc061d1fa80 ffc077f2b090
>  
> [   54.334310] fa00: ffc077f26218 
> ff8008d8d000 ff8008d15000
> [   54.334317] fa20: ff8008d15790 ff8008d906f8
> 0001 ffc005f43dc0
> [   54.334322] fa40:  
> [   54.334328] [] clk_core_disable+0x20/0x78
> [   54.334336] [] clk_disable+0x1c/0x30
> [   54.334349] [] i2c_dw_plat_prepare_clk.isra.0+0x44/0x80
> [   54.334356] [] dw_i2c_plat_suspend+0x24/0x38
> [   54.334367] [] platform_pm_suspend+0x24/0x58
> [   54.334377] [] dpm_run_callback.isra.7+0x20/0x68
> [   54.334385] [] __device_suspend+0x10c/0x298
> [   54.334393] [] dpm_suspend+0x10c/0x228
> [   54.334401] [] dpm_suspend_start+0x68/0x78
> [   54.334412] [] suspend_devices_and_enter+0xb8/0x458
> [   54.334419] [] pm_suspend+0x1ec/0x248
> [   54.334426] [] state_store+0x94/0xa8
> [   54.334434] [] kobj_attr_store+0x14/0x28
> [   54.33] [] sysfs_kf_write+0x48/0x58
> [   54.334451] [] kernfs_fop_write+0xb0/0x1d8
> [   54.334461] [] __vfs_write+0x1c/0x100
> [   54.334469] [] vfs_write+0xa0/0x1b8
> [   54.334477] [] SyS_write+0x44/0xa0
> [   54.334485] [] el0_svc_naked+0x24/0x28
>
>
> Doing some further debugging, it seems the problem is that the device
> is being runtime suspended, and then at suspend time, we're calling
> the same logic, calling i2c_dw_plat_prepare_clk, which causes the clk
> count warning.
>
> Removing the runtime pm ops:
> -   SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
> +// SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
>
> seems to avoid the warning, but clearly isn't ideal. :)
>
> Should there be some logic keep track of the suspend state for the
> dw_i2c_dev device so we don't try to suspend (or resume) it twice?  Or
> is there something else I'm missing to keep this from happening?

Ping? Any thoughts on how best to fix this?  I'm leaning towards
adding a suspended state to the struct dw_i2c_dev. Any objections?

thanks
-john

Re: Cherryview wake up events

[Andy Shevchenko]

On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach  wrote:
> On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote:
>> On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote:
>> > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach  
>> > wrote:
>> > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote:
>> >
>> > >> Had you tried to add ID to axp20x-i2c.c ?
>> > >
>> > > Nope, since I have no idea if the axp and TI hardware is similar.
>> >
>> > I think you would give a try.
>>
>> I'll check it.
>
> I checked the reference source code, my impression is the
> TI Dollar Cove and and AXP288 are completely different hardware.

Thanks for checking.

Yes, due to not obvious communication to PMIC. I suppose that the IP
core is quite similar in all of them, the difference is just how OS
and other MCUs in SoC communicate with it.

So, basically what it means that I2C direct communication is prohibited here.

>
>> > > [5.331709] i2c_designware 808622C1:06: controller timed out
>> > >
>> > This is known: http://www.spinics.net/lists/intel-gfx/msg117738.html
>
> Interestingly via this link I found Intel also published
> the TI DCove source in a patch series against an unspecified kernel:
> https://github.com/01org/ProductionKernelQuilts
> specifically
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
> and some more (the series is quite messy).
>
> For the Asus E200HA I'm not sure if the charger and coulomb
> counter drivers are needed since charging just works and
> the battery status is reported via ACPI.  It seems these
> drivers are only for tablets without ACPI support, right?

Have no idea.

What that code reminds me is MID family of devices. So, power button
is (reasonable) easy to get support of in that case.
Look into drivers/platform/x86/intel_mid_powerbtn.c. I recently
updated it to support Basin Cove on Intel Edison.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2] net: aquantia: atlantic: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
Changelog:
v2:
- add support and advertise for TP

 .../net/ethernet/aquantia/atlantic/aq_ethtool.c|   23 +
 drivers/net/ethernet/aquantia/atlantic/aq_nic.c|   51 +---
 drivers/net/ethernet/aquantia/atlantic/aq_nic.h|6 ++-
 3 files changed, 49 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
index c5b025e..a761e91 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
@@ -35,24 +35,25 @@ static u32 aq_ethtool_get_link(struct net_device *ndev)
return ethtool_op_get_link(ndev);
 }
 
-static int aq_ethtool_get_settings(struct net_device *ndev,
-  struct ethtool_cmd *cmd)
+static int aq_ethtool_get_link_ksettings(struct net_device *ndev,
+struct ethtool_link_ksettings *cmd)
 {
struct aq_nic_s *aq_nic = netdev_priv(ndev);
 
-   aq_nic_get_link_settings(aq_nic, cmd);
-   ethtool_cmd_speed_set(cmd, netif_carrier_ok(ndev) ?
-   aq_nic_get_link_speed(aq_nic) : 0U);
+   aq_nic_get_link_ksettings(aq_nic, cmd);
+   cmd->base.speed = netif_carrier_ok(ndev) ?
+   aq_nic_get_link_speed(aq_nic) : 0U;
 
return 0;
 }
 
-static int aq_ethtool_set_settings(struct net_device *ndev,
-  struct ethtool_cmd *cmd)
+static int
+aq_ethtool_set_link_ksettings(struct net_device *ndev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct aq_nic_s *aq_nic = netdev_priv(ndev);
 
-   return aq_nic_set_link_settings(aq_nic, cmd);
+   return aq_nic_set_link_ksettings(aq_nic, cmd);
 }
 
 /* there "5U" is number of queue[#] stats lines (InPackets+...+InErrors) */
@@ -248,8 +249,6 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_link= aq_ethtool_get_link,
.get_regs_len= aq_ethtool_get_regs_len,
.get_regs= aq_ethtool_get_regs,
-   .get_settings= aq_ethtool_get_settings,
-   .set_settings= aq_ethtool_set_settings,
.get_drvinfo = aq_ethtool_get_drvinfo,
.get_strings = aq_ethtool_get_strings,
.get_rxfh_indir_size = aq_ethtool_get_rss_indir_size,
@@ -257,5 +256,7 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_rxfh= aq_ethtool_get_rss,
.get_rxnfc   = aq_ethtool_get_rxnfc,
.get_sset_count  = aq_ethtool_get_sset_count,
-   .get_ethtool_stats   = aq_ethtool_stats
+   .get_ethtool_stats   = aq_ethtool_stats,
+   .get_link_ksettings  = aq_ethtool_get_link_ksettings,
+   .set_link_ksettings  = aq_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 84bb441..bed25ab 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -734,50 +734,65 @@ void aq_nic_get_stats(struct aq_nic_s *self, u64 *data)
(void)err;
 }
 
-void aq_nic_get_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd)
+void aq_nic_get_link_ksettings(struct aq_nic_s *self,
+  struct ethtool_link_ksettings *cmd)
 {
-   cmd->port = PORT_TP;
-   cmd->transceiver = XCVR_EXTERNAL;
+   u32 supported, advertising;
+
+   cmd->base.port = PORT_TP;
/* This driver supports only 10G capable adapters, so DUPLEX_FULL */
-   cmd->duplex = DUPLEX_FULL;
-   cmd->autoneg = self->aq_nic_cfg.is_autoneg;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.autoneg = self->aq_nic_cfg.is_autoneg;
+
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.supported);
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.advertising);
 
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
ADVERTISED_1baseT_Full : 0U;
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
ADVERTISED_1000baseT_Full : 0U;
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?

[PATCH v2] net: aquantia: atlantic: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
Changelog:
v2:
- add support and advertise for TP

 .../net/ethernet/aquantia/atlantic/aq_ethtool.c|   23 +
 drivers/net/ethernet/aquantia/atlantic/aq_nic.c|   51 +---
 drivers/net/ethernet/aquantia/atlantic/aq_nic.h|6 ++-
 3 files changed, 49 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
index c5b025e..a761e91 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
@@ -35,24 +35,25 @@ static u32 aq_ethtool_get_link(struct net_device *ndev)
return ethtool_op_get_link(ndev);
 }
 
-static int aq_ethtool_get_settings(struct net_device *ndev,
-  struct ethtool_cmd *cmd)
+static int aq_ethtool_get_link_ksettings(struct net_device *ndev,
+struct ethtool_link_ksettings *cmd)
 {
struct aq_nic_s *aq_nic = netdev_priv(ndev);
 
-   aq_nic_get_link_settings(aq_nic, cmd);
-   ethtool_cmd_speed_set(cmd, netif_carrier_ok(ndev) ?
-   aq_nic_get_link_speed(aq_nic) : 0U);
+   aq_nic_get_link_ksettings(aq_nic, cmd);
+   cmd->base.speed = netif_carrier_ok(ndev) ?
+   aq_nic_get_link_speed(aq_nic) : 0U;
 
return 0;
 }
 
-static int aq_ethtool_set_settings(struct net_device *ndev,
-  struct ethtool_cmd *cmd)
+static int
+aq_ethtool_set_link_ksettings(struct net_device *ndev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct aq_nic_s *aq_nic = netdev_priv(ndev);
 
-   return aq_nic_set_link_settings(aq_nic, cmd);
+   return aq_nic_set_link_ksettings(aq_nic, cmd);
 }
 
 /* there "5U" is number of queue[#] stats lines (InPackets+...+InErrors) */
@@ -248,8 +249,6 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_link= aq_ethtool_get_link,
.get_regs_len= aq_ethtool_get_regs_len,
.get_regs= aq_ethtool_get_regs,
-   .get_settings= aq_ethtool_get_settings,
-   .set_settings= aq_ethtool_set_settings,
.get_drvinfo = aq_ethtool_get_drvinfo,
.get_strings = aq_ethtool_get_strings,
.get_rxfh_indir_size = aq_ethtool_get_rss_indir_size,
@@ -257,5 +256,7 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_rxfh= aq_ethtool_get_rss,
.get_rxnfc   = aq_ethtool_get_rxnfc,
.get_sset_count  = aq_ethtool_get_sset_count,
-   .get_ethtool_stats   = aq_ethtool_stats
+   .get_ethtool_stats   = aq_ethtool_stats,
+   .get_link_ksettings  = aq_ethtool_get_link_ksettings,
+   .set_link_ksettings  = aq_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 84bb441..bed25ab 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -734,50 +734,65 @@ void aq_nic_get_stats(struct aq_nic_s *self, u64 *data)
(void)err;
 }
 
-void aq_nic_get_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd)
+void aq_nic_get_link_ksettings(struct aq_nic_s *self,
+  struct ethtool_link_ksettings *cmd)
 {
-   cmd->port = PORT_TP;
-   cmd->transceiver = XCVR_EXTERNAL;
+   u32 supported, advertising;
+
+   cmd->base.port = PORT_TP;
/* This driver supports only 10G capable adapters, so DUPLEX_FULL */
-   cmd->duplex = DUPLEX_FULL;
-   cmd->autoneg = self->aq_nic_cfg.is_autoneg;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.autoneg = self->aq_nic_cfg.is_autoneg;
+
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.supported);
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.advertising);
 
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
ADVERTISED_1baseT_Full : 0U;
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
ADVERTISED_1000baseT_Full : 0U;
-   cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?
+   supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?
ADVERTISED_100baseT_Full : 0U;
- 

Re: [PATCH v4] mm: add arch-independent testcases for RODATA

[Kees Cook]

On Sun, Jan 29, 2017 at 2:54 AM, Jinbum Park  wrote:
> This patch makes arch-independent testcases for RODATA.
> Both x86 and x86_64 already have testcases for RODATA,
> But they are arch-specific because using inline assembly directly.
>
> and cacheflush.h is not suitable location for rodata-test related things.
> Since they were in cacheflush.h,
> If someone change the state of CONFIG_DEBUG_RODATA_TEST,
> It cause overhead of kernel build.
>
> To solve above issue,
> write arch-independent testcases and move it to shared location.
>
> Signed-off-by: Jinbum Park 

This version looks good to me. Thanks!

Acked-by: Kees Cook 

-Kees

> ---
> v4: Move the rodata_test() call out into mark_readonly()
> Delete some comment
>
> v3: Use probe_kernel_write() instead of put_user()
> Move declaration of rodata_test_data to separate header 
> (rodata_test.h)
> Fix a kbuild-test-robot-error related to DEBUG_NX_TEST
>
> v2: Restore original credit of mm/rodata_test.c
>
>  arch/x86/Kconfig.debug| 10 +-
>  arch/x86/include/asm/cacheflush.h | 10 --
>  arch/x86/kernel/Makefile  |  1 -
>  arch/x86/kernel/test_rodata.c | 75 
> ---
>  arch/x86/mm/init_32.c |  4 ---
>  arch/x86/mm/init_64.c |  5 ---
>  include/linux/rodata_test.h   | 24 +
>  init/main.c   |  6 ++--
>  mm/Kconfig.debug  |  7 
>  mm/Makefile   |  1 +
>  mm/rodata_test.c  | 56 +
>  11 files changed, 93 insertions(+), 106 deletions(-)
>  delete mode 100644 arch/x86/kernel/test_rodata.c
>  create mode 100644 include/linux/rodata_test.h
>  create mode 100644 mm/rodata_test.c
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index 67eec55..3fa469c 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -74,14 +74,6 @@ config EFI_PGT_DUMP
>   issues with the mapping of the EFI runtime regions into that
>   table.
>
> -config DEBUG_RODATA_TEST
> -   bool "Testcase for the marking rodata read-only"
> -   default y
> -   ---help---
> - This option enables a testcase for the setting rodata read-only
> - as well as for the change_page_attr() infrastructure.
> - If in doubt, say "N"
> -
>  config DEBUG_WX
> bool "Warn on W+X mappings at boot"
> select X86_PTDUMP_CORE
> @@ -122,7 +114,7 @@ config DEBUG_SET_MODULE_RONX
>
>  config DEBUG_NX_TEST
> tristate "Testcase for the NX non-executable stack feature"
> -   depends on DEBUG_KERNEL && m
> +   depends on DEBUG_KERNEL && DEBUG_RODATA_TEST && m
> ---help---
>   This option enables a testcase for the CPU NX capability
>   and the software setup of this feature.
> diff --git a/arch/x86/include/asm/cacheflush.h 
> b/arch/x86/include/asm/cacheflush.h
> index 872877d..e7e1942e 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -90,18 +90,8 @@
>
>  #define mmio_flush_range(addr, size) clflush_cache_range(addr, size)
>
> -extern const int rodata_test_data;
>  extern int kernel_set_to_readonly;
>  void set_kernel_text_rw(void);
>  void set_kernel_text_ro(void);
>
> -#ifdef CONFIG_DEBUG_RODATA_TEST
> -int rodata_test(void);
> -#else
> -static inline int rodata_test(void)
> -{
> -   return 0;
> -}
> -#endif
> -
>  #endif /* _ASM_X86_CACHEFLUSH_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 581386c..f6caf82 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -100,7 +100,6 @@ obj-$(CONFIG_HPET_TIMER)+= hpet.o
>  obj-$(CONFIG_APB_TIMER)+= apb_timer.o
>
>  obj-$(CONFIG_AMD_NB)   += amd_nb.o
> -obj-$(CONFIG_DEBUG_RODATA_TEST)+= test_rodata.o
>  obj-$(CONFIG_DEBUG_NX_TEST)+= test_nx.o
>  obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
>
> diff --git a/arch/x86/kernel/test_rodata.c b/arch/x86/kernel/test_rodata.c
> deleted file mode 100644
> index 222e84e..000
> --- a/arch/x86/kernel/test_rodata.c
> +++ /dev/null
> @@ -1,75 +0,0 @@
> -/*
> - * test_rodata.c: functional test for mark_rodata_ro function
> - *
> - * (C) Copyright 2008 Intel Corporation
> - * Author: Arjan van de Ven 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; version 2
> - * of the License.
> - */
> -#include 
> -#include 
> -#include 
> -
> -int rodata_test(void)
> -{
> -   unsigned long result;
> -   unsigned long start, end;
> -
> -   /* test 1: read the value */
> -   /* If this test fails, some previous testrun has clobbered the state 
> */
> -   if (!rodata_test_data) {
> -   

Re: [PATCH v4] mm: add arch-independent testcases for RODATA

[Kees Cook]

On Sun, Jan 29, 2017 at 2:54 AM, Jinbum Park  wrote:
> This patch makes arch-independent testcases for RODATA.
> Both x86 and x86_64 already have testcases for RODATA,
> But they are arch-specific because using inline assembly directly.
>
> and cacheflush.h is not suitable location for rodata-test related things.
> Since they were in cacheflush.h,
> If someone change the state of CONFIG_DEBUG_RODATA_TEST,
> It cause overhead of kernel build.
>
> To solve above issue,
> write arch-independent testcases and move it to shared location.
>
> Signed-off-by: Jinbum Park 

This version looks good to me. Thanks!

Acked-by: Kees Cook 

-Kees

> ---
> v4: Move the rodata_test() call out into mark_readonly()
> Delete some comment
>
> v3: Use probe_kernel_write() instead of put_user()
> Move declaration of rodata_test_data to separate header 
> (rodata_test.h)
> Fix a kbuild-test-robot-error related to DEBUG_NX_TEST
>
> v2: Restore original credit of mm/rodata_test.c
>
>  arch/x86/Kconfig.debug| 10 +-
>  arch/x86/include/asm/cacheflush.h | 10 --
>  arch/x86/kernel/Makefile  |  1 -
>  arch/x86/kernel/test_rodata.c | 75 
> ---
>  arch/x86/mm/init_32.c |  4 ---
>  arch/x86/mm/init_64.c |  5 ---
>  include/linux/rodata_test.h   | 24 +
>  init/main.c   |  6 ++--
>  mm/Kconfig.debug  |  7 
>  mm/Makefile   |  1 +
>  mm/rodata_test.c  | 56 +
>  11 files changed, 93 insertions(+), 106 deletions(-)
>  delete mode 100644 arch/x86/kernel/test_rodata.c
>  create mode 100644 include/linux/rodata_test.h
>  create mode 100644 mm/rodata_test.c
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index 67eec55..3fa469c 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -74,14 +74,6 @@ config EFI_PGT_DUMP
>   issues with the mapping of the EFI runtime regions into that
>   table.
>
> -config DEBUG_RODATA_TEST
> -   bool "Testcase for the marking rodata read-only"
> -   default y
> -   ---help---
> - This option enables a testcase for the setting rodata read-only
> - as well as for the change_page_attr() infrastructure.
> - If in doubt, say "N"
> -
>  config DEBUG_WX
> bool "Warn on W+X mappings at boot"
> select X86_PTDUMP_CORE
> @@ -122,7 +114,7 @@ config DEBUG_SET_MODULE_RONX
>
>  config DEBUG_NX_TEST
> tristate "Testcase for the NX non-executable stack feature"
> -   depends on DEBUG_KERNEL && m
> +   depends on DEBUG_KERNEL && DEBUG_RODATA_TEST && m
> ---help---
>   This option enables a testcase for the CPU NX capability
>   and the software setup of this feature.
> diff --git a/arch/x86/include/asm/cacheflush.h 
> b/arch/x86/include/asm/cacheflush.h
> index 872877d..e7e1942e 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -90,18 +90,8 @@
>
>  #define mmio_flush_range(addr, size) clflush_cache_range(addr, size)
>
> -extern const int rodata_test_data;
>  extern int kernel_set_to_readonly;
>  void set_kernel_text_rw(void);
>  void set_kernel_text_ro(void);
>
> -#ifdef CONFIG_DEBUG_RODATA_TEST
> -int rodata_test(void);
> -#else
> -static inline int rodata_test(void)
> -{
> -   return 0;
> -}
> -#endif
> -
>  #endif /* _ASM_X86_CACHEFLUSH_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 581386c..f6caf82 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -100,7 +100,6 @@ obj-$(CONFIG_HPET_TIMER)+= hpet.o
>  obj-$(CONFIG_APB_TIMER)+= apb_timer.o
>
>  obj-$(CONFIG_AMD_NB)   += amd_nb.o
> -obj-$(CONFIG_DEBUG_RODATA_TEST)+= test_rodata.o
>  obj-$(CONFIG_DEBUG_NX_TEST)+= test_nx.o
>  obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
>
> diff --git a/arch/x86/kernel/test_rodata.c b/arch/x86/kernel/test_rodata.c
> deleted file mode 100644
> index 222e84e..000
> --- a/arch/x86/kernel/test_rodata.c
> +++ /dev/null
> @@ -1,75 +0,0 @@
> -/*
> - * test_rodata.c: functional test for mark_rodata_ro function
> - *
> - * (C) Copyright 2008 Intel Corporation
> - * Author: Arjan van de Ven 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; version 2
> - * of the License.
> - */
> -#include 
> -#include 
> -#include 
> -
> -int rodata_test(void)
> -{
> -   unsigned long result;
> -   unsigned long start, end;
> -
> -   /* test 1: read the value */
> -   /* If this test fails, some previous testrun has clobbered the state 
> */
> -   if (!rodata_test_data) {
> -   printk(KERN_ERR "rodata_test: test 1 fails (start data)\n");
> -   return -ENODEV;
> 

Re: [PATCH v6 5/5] arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards

[Chris Packham]

Hi Gregory,

On 31/01/17 03:29, Gregory CLEMENT wrote:
> Hi Chris,
>
>  On lun., janv. 30 2017, Chris Packham  
> wrote:
>
>> These boards are Marvell's evaluation boards for the 98DX4251 and
>> 98DX3336 SoCs.
>>
>> Signed-off-by: Chris Packham 
>
> Applied on mvebu/dt
>

I just noticed that I hadn't updated arch/arm/boot/dts/Makefile. The way 
I've been building things (explicitly running 'make 
armada-xp-db-xc3-24g4xg.dtb') it hasn't mattered to me but I'm wondering 
if I should have?

>> ---
>>
>> Notes:
>> Changes in v5:
>> - update license text
>> - use node labels
>> Changes in v6:
>> - Rename dts files to include 'armada-xp-' prefix
>>
>>  arch/arm/boot/dts/armada-xp-db-dxbc2.dts  | 151 
>> ++
>>  arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 142 
>>  2 files changed, 293 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/armada-xp-db-dxbc2.dts
>>  create mode 100644 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>>

Re: [PATCH v6 5/5] arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards

[Chris Packham]

Hi Gregory,

On 31/01/17 03:29, Gregory CLEMENT wrote:
> Hi Chris,
>
>  On lun., janv. 30 2017, Chris Packham  
> wrote:
>
>> These boards are Marvell's evaluation boards for the 98DX4251 and
>> 98DX3336 SoCs.
>>
>> Signed-off-by: Chris Packham 
>
> Applied on mvebu/dt
>

I just noticed that I hadn't updated arch/arm/boot/dts/Makefile. The way 
I've been building things (explicitly running 'make 
armada-xp-db-xc3-24g4xg.dtb') it hasn't mattered to me but I'm wondering 
if I should have?

>> ---
>>
>> Notes:
>> Changes in v5:
>> - update license text
>> - use node labels
>> Changes in v6:
>> - Rename dts files to include 'armada-xp-' prefix
>>
>>  arch/arm/boot/dts/armada-xp-db-dxbc2.dts  | 151 
>> ++
>>  arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 142 
>>  2 files changed, 293 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/armada-xp-db-dxbc2.dts
>>  create mode 100644 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>>

Re: Q: lockdep_assert_held_read() after downgrade_write()

[Jens Axboe]

On 01/30/2017 02:25 PM, J. R. Okajima wrote:
> Peter Zijlstra,
> 
> May I ask you a question?
> v4.10-rc1 got a commit
>   f831948 2016-11-30 locking/lockdep: Provide a type check for 
> lock_is_held
> I've tested a little and lockdep splat a stack trace.
> 
> {
>   DECLARE_RWSEM(rw);
>   static struct lock_class_key key;
>   lockdep_set_class(, );
> 
>   down_read();
>   lockdep_assert_held_read();
>   up_read();
> 
>   down_write();
>   lockdep_assert_held_exclusive();
>   up_write();
> 
>   downgrade_write();
>   lockdep_assert_held_read();  <-- here
>   up_read();
> }
> 
> I was expecting that lockdep_assert_held_read() splat nothing after
> downgrade_write(). Is this warning an intentional behaviour?
> 
> Also the final up_read() gives me a warning too. It is produced at
>   lockdep.c:3514:lock_release(): DEBUG_LOCKS_WARN_ON(depth <= 0)

I don't think you understand how it works. downgrade_write() turns a write
lock into read held. To make that last sequence valid, you'd need:

down_write();
downgrade_write();
lockdep_assert_held_read()
up_read();

or just not drop up_write() from the last section.

-- 
Jens Axboe

Re: Q: lockdep_assert_held_read() after downgrade_write()

[Jens Axboe]

On 01/30/2017 02:25 PM, J. R. Okajima wrote:
> Peter Zijlstra,
> 
> May I ask you a question?
> v4.10-rc1 got a commit
>   f831948 2016-11-30 locking/lockdep: Provide a type check for 
> lock_is_held
> I've tested a little and lockdep splat a stack trace.
> 
> {
>   DECLARE_RWSEM(rw);
>   static struct lock_class_key key;
>   lockdep_set_class(, );
> 
>   down_read();
>   lockdep_assert_held_read();
>   up_read();
> 
>   down_write();
>   lockdep_assert_held_exclusive();
>   up_write();
> 
>   downgrade_write();
>   lockdep_assert_held_read();  <-- here
>   up_read();
> }
> 
> I was expecting that lockdep_assert_held_read() splat nothing after
> downgrade_write(). Is this warning an intentional behaviour?
> 
> Also the final up_read() gives me a warning too. It is produced at
>   lockdep.c:3514:lock_release(): DEBUG_LOCKS_WARN_ON(depth <= 0)

I don't think you understand how it works. downgrade_write() turns a write
lock into read held. To make that last sequence valid, you'd need:

down_write();
downgrade_write();
lockdep_assert_held_read()
up_read();

or just not drop up_write() from the last section.

-- 
Jens Axboe

Re: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

[Dan Williams]

On Mon, Jan 30, 2017 at 4:24 AM, Christoph Hellwig  wrote:
> Hi Dan,
>
> this looks mostly fine to me.  A few code comments below, but except
> for this there is another issue with it:  We still have drivers
> that share a single request_queue for multiple gendisks, so I wonder

scsi drivers or others? If those drivers can switch to dynamically
allocated devt (GENHD_FL_EXT_DEVT), then they don't need this fix.

Re: [PATCH net-next v7 0/3] Add support for the ethernet switch on the ESPRESSObin

[David Miller]

From: Gregory CLEMENT 
Date: Mon, 30 Jan 2017 20:29:32 +0100

> This set of patches adds support for the Marvell Ethernet Topaz switch
> family (88E6141/88E6341) which is found on the ESPRESSObin. With this
> series the network is usable on this board.
> 
> As usual, I rebased the series on the very last net-next/master. In
> this series there is no temperature support which need some patches
> form Andrew Lunn.
> 
> As soon as Andrew Lunn will post the needed patch I will send a patch
> to enable the temperature support.

Series applied, thank you.

Re: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

[Dan Williams]

On Mon, Jan 30, 2017 at 4:24 AM, Christoph Hellwig  wrote:
> Hi Dan,
>
> this looks mostly fine to me.  A few code comments below, but except
> for this there is another issue with it:  We still have drivers
> that share a single request_queue for multiple gendisks, so I wonder

scsi drivers or others? If those drivers can switch to dynamically
allocated devt (GENHD_FL_EXT_DEVT), then they don't need this fix.

Re: [PATCH net-next v7 0/3] Add support for the ethernet switch on the ESPRESSObin

[David Miller]

From: Gregory CLEMENT 
Date: Mon, 30 Jan 2017 20:29:32 +0100

> This set of patches adds support for the Marvell Ethernet Topaz switch
> family (88E6141/88E6341) which is found on the ESPRESSObin. With this
> series the network is usable on this board.
> 
> As usual, I rebased the series on the very last net-next/master. In
> this series there is no temperature support which need some patches
> form Andrew Lunn.
> 
> As soon as Andrew Lunn will post the needed patch I will send a patch
> to enable the temperature support.

Series applied, thank you.

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > On 1/27/2017 5:04 PM, James Bottomley wrote:
> > 
> > > > Beware the nasty corner case:
> > > > 
> > > > - Application asks for a session and gets 0200
> > > > 
> > > > - Time elapses and 0200 gets forcibly flushed
> > > > 
> > > > - Later, app comes back, asks for a second session and again gets
> > > > 0200.
> > > > 
> > > > - App gets very confused.
> > > > 
> > > > May it be better to close the connection completely, which the
> > > > application can detect, than flush a session and give this corner
> > > > case?
> > > 
> > > if I look at the code I've written, I don't know what the session
> > > number is, I just save sessionHandle in a variable for later use 
> > > (lets say to v1).  If I got the same session number returned at a 
> > > later time and placed it in v2, all I'd notice is that an 
> > > authorization using v1 would fail.  I'm not averse to killing the 
> > > entire connection but, assuming you have fallback, it might be 
> > > kinder simply to ensure that the operations with the reclaimed 
> > > session fail (which is what the code currently does).
> > 
> > My worry is that this session failure cannot be detected by the 
> > application.  An HMAC failure could cause the app to tell a user that
> > they entered the wrong password.  Misleading.  On the TPM, it could 
> > trigger the dictionary attack lockout.  For a PIN index, it could 
> > consume a failure count.  Killing a policy session that has e.g., a 
> > policy signed term could cause the application to go back to some 
> > external entity for another authorization signature.
> > 
> > Let's go up to the stack.  What's the attack?
> > 
> > If we're worried about many simultaneous applications (wouldn't that 
> > be wonderful), why not just let startauthsession fail?  The 
> > application can just retry periodically.
> 
> How in that scenario do we ensure that a session becomes available? 
>  Once that's established, there's no real difference between retrying
> the startauthsession in the kernel when we know the session is
> available and forcing userspace to do the retry except that the former
> has a far greater chance of success (and it's only about 6 lines of
> code).
> 
> >   Just allocate them in triples so there's no deadlock.
> 
> Is this the application or the kernel?  If it's the kernel, that adds a
> lot of complexity.
> 
> > If we're worried about a DoS attack, killing a session just helps the
> > attacker.  The attacker can create a few connections and spin on 
> > startauthsession, locking everyone out anyway.
> 
> There are two considerations here: firstly we'd need to introduce a
> mechanism to "kill" the connection.  Probably we'd simply error every
> command on the space until it was closed.  The second is which scenario
> is more reasonable: Say the application simply forgot to flush the
> session and will never use it again.  Simply reclaiming the session
> would produce no effect at all on the application in this scenario. 
>  However, I have no data to say what's likely.
> 
> > ~~
> > 
> > Also, let's remember that this is a rare application.  Sessions are 
> > only needed for remote access (requiring encryption, HMAC or salt), 
> > or policy sessions.
> 
> This depends what your threat model is.  For ssh keys, you worry that
> someone might be watching, so you use HMAC authority even for a local
> TPM.  In the cloud, you don't quite know where the TPM is, so again
> you'd use HMAC sessions ... however, in both use cases the sessions
> should be very short lived.
> 
> > ~~
> > 
> > Should the code also reserve a session for the kernel?  Mark it not 
> > kill'able?
> 
> At the moment, the kernel doesn't use sessions, so let's worry about
> that problem at the point it arises (if it ever arises).
> 
> James

It does. My trusted keys implementation actually uses sessions.

I'm kind dilating to an opinion that we would leave this commit out from
the first kernel release that will contain the resource manager with
similar rationale as Jason gave me for whitelisting: get the basic stuff
in and once it is used with some workloads whitelisting and exhaustion
will take eventually the right form.

How would you feel about this?

/Jarkko

Re: [PATCH v2] clk: add more managed APIs

[Dmitry Torokhov]

On Mon, Jan 30, 2017 at 1:42 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
>> Maybe the additional calls make sense; I can imagine they would.
>> However, I personally would be a bit wary of changing the initialization
>> order of multi-clock initializations, and I am not sure how a single call
>> could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
>> seems like a bit too much).
>>
>> [ On a side note, why is there no clk_get_prepare_enable() and
>>   clk_get_prepare() ? Maybe it would be better to introduce those
>>   together with the matching devm_ functions in a separate patch
>>   if they are useful. ]
>
> If you take the view that trying to keep clocks disabled is a good way
> to save power, then you'd have the clk_prepare() or maybe
> clk_prepare_enable() in your runtime PM resume handler, or maybe even
> deeper in the driver... the original design goal of the clk API was to
> allow power saving and clock control.
>
> With that in mind, getting and enabling the clock together in the
> probe function didn't make sense.
>
> I feel that aspect has been somewhat lost, and people now regard much
> of the clk API as a bit of a probe-time nusience.

It really depends on the driver. Devices that are expected to be used
"all the time", like keyboards, that get "opened" very early in the
boot process, maybe even by the kernel itself, usually enable hardware
in probe as doing it later just makes code more complex. Devices that
are "less used" and could provide more power savings (like GPU) may
have more elaborate power management with clocks being turned on and
off as needed. I would not paint clk API as "probe-time nuisance", but
for some class of devices devm CLK API is really helpful.

FWIW I do not think that kitchen sink calls, like
"devm_clk_get_prepare_set_rate_enable" are helpful. Resource
acquisition and use of said resource are logically separate.

Thanks.

-- 
Dmitry

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > On 1/27/2017 5:04 PM, James Bottomley wrote:
> > 
> > > > Beware the nasty corner case:
> > > > 
> > > > - Application asks for a session and gets 0200
> > > > 
> > > > - Time elapses and 0200 gets forcibly flushed
> > > > 
> > > > - Later, app comes back, asks for a second session and again gets
> > > > 0200.
> > > > 
> > > > - App gets very confused.
> > > > 
> > > > May it be better to close the connection completely, which the
> > > > application can detect, than flush a session and give this corner
> > > > case?
> > > 
> > > if I look at the code I've written, I don't know what the session
> > > number is, I just save sessionHandle in a variable for later use 
> > > (lets say to v1).  If I got the same session number returned at a 
> > > later time and placed it in v2, all I'd notice is that an 
> > > authorization using v1 would fail.  I'm not averse to killing the 
> > > entire connection but, assuming you have fallback, it might be 
> > > kinder simply to ensure that the operations with the reclaimed 
> > > session fail (which is what the code currently does).
> > 
> > My worry is that this session failure cannot be detected by the 
> > application.  An HMAC failure could cause the app to tell a user that
> > they entered the wrong password.  Misleading.  On the TPM, it could 
> > trigger the dictionary attack lockout.  For a PIN index, it could 
> > consume a failure count.  Killing a policy session that has e.g., a 
> > policy signed term could cause the application to go back to some 
> > external entity for another authorization signature.
> > 
> > Let's go up to the stack.  What's the attack?
> > 
> > If we're worried about many simultaneous applications (wouldn't that 
> > be wonderful), why not just let startauthsession fail?  The 
> > application can just retry periodically.
> 
> How in that scenario do we ensure that a session becomes available? 
>  Once that's established, there's no real difference between retrying
> the startauthsession in the kernel when we know the session is
> available and forcing userspace to do the retry except that the former
> has a far greater chance of success (and it's only about 6 lines of
> code).
> 
> >   Just allocate them in triples so there's no deadlock.
> 
> Is this the application or the kernel?  If it's the kernel, that adds a
> lot of complexity.
> 
> > If we're worried about a DoS attack, killing a session just helps the
> > attacker.  The attacker can create a few connections and spin on 
> > startauthsession, locking everyone out anyway.
> 
> There are two considerations here: firstly we'd need to introduce a
> mechanism to "kill" the connection.  Probably we'd simply error every
> command on the space until it was closed.  The second is which scenario
> is more reasonable: Say the application simply forgot to flush the
> session and will never use it again.  Simply reclaiming the session
> would produce no effect at all on the application in this scenario. 
>  However, I have no data to say what's likely.
> 
> > ~~
> > 
> > Also, let's remember that this is a rare application.  Sessions are 
> > only needed for remote access (requiring encryption, HMAC or salt), 
> > or policy sessions.
> 
> This depends what your threat model is.  For ssh keys, you worry that
> someone might be watching, so you use HMAC authority even for a local
> TPM.  In the cloud, you don't quite know where the TPM is, so again
> you'd use HMAC sessions ... however, in both use cases the sessions
> should be very short lived.
> 
> > ~~
> > 
> > Should the code also reserve a session for the kernel?  Mark it not 
> > kill'able?
> 
> At the moment, the kernel doesn't use sessions, so let's worry about
> that problem at the point it arises (if it ever arises).
> 
> James

It does. My trusted keys implementation actually uses sessions.

I'm kind dilating to an opinion that we would leave this commit out from
the first kernel release that will contain the resource manager with
similar rationale as Jason gave me for whitelisting: get the basic stuff
in and once it is used with some workloads whitelisting and exhaustion
will take eventually the right form.

How would you feel about this?

/Jarkko

Re: [PATCH v2] clk: add more managed APIs

[Dmitry Torokhov]

On Mon, Jan 30, 2017 at 1:42 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
>> Maybe the additional calls make sense; I can imagine they would.
>> However, I personally would be a bit wary of changing the initialization
>> order of multi-clock initializations, and I am not sure how a single call
>> could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
>> seems like a bit too much).
>>
>> [ On a side note, why is there no clk_get_prepare_enable() and
>>   clk_get_prepare() ? Maybe it would be better to introduce those
>>   together with the matching devm_ functions in a separate patch
>>   if they are useful. ]
>
> If you take the view that trying to keep clocks disabled is a good way
> to save power, then you'd have the clk_prepare() or maybe
> clk_prepare_enable() in your runtime PM resume handler, or maybe even
> deeper in the driver... the original design goal of the clk API was to
> allow power saving and clock control.
>
> With that in mind, getting and enabling the clock together in the
> probe function didn't make sense.
>
> I feel that aspect has been somewhat lost, and people now regard much
> of the clk API as a bit of a probe-time nusience.

It really depends on the driver. Devices that are expected to be used
"all the time", like keyboards, that get "opened" very early in the
boot process, maybe even by the kernel itself, usually enable hardware
in probe as doing it later just makes code more complex. Devices that
are "less used" and could provide more power savings (like GPU) may
have more elaborate power management with clocks being turned on and
off as needed. I would not paint clk API as "probe-time nuisance", but
for some class of devices devm CLK API is really helpful.

FWIW I do not think that kitchen sink calls, like
"devm_clk_get_prepare_set_rate_enable" are helpful. Resource
acquisition and use of said resource are logically separate.

Thanks.

-- 
Dmitry

Re: [PATCH v3 16/24] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

[Sean Paul]

On Sun, Jan 29, 2017 at 01:24:36PM +, John Keeping wrote:
> These values are specified as constant time periods but the PHY
> configuration is in terms of the current lane byte clock so using
> constant values guarantees that the timings will be outside the
> specification with some display configurations.
> 
> Derive the necessary configuration from the byte clock in order to
> ensure that the PHY configuration is correct.
> 
> Signed-off-by: John Keeping 
> ---
> v3:
> - Wrap some long lines
> Unchanged in v2
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 
> ++
>  1 file changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index cfe7e4ba305c..85edf6dd2bac 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -383,6 +383,26 @@ static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi 
> *dsi, u8 test_code,
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLK | PHY_UNTESTCLR);
>  }
>  
> +/**
> + * ns2bc - Nanoseconds to byte clock cycles
> + */
> +static inline unsigned int ns2bc(struct dw_mipi_dsi *dsi, int ns)
> +{
> + unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC / 8;

Why multiply by 1000 (MSEC_PER_SEC) only to immediately divide by 1000?

> +
> + return (ns * (byte_clk_khz / 1000) + 999) / 1000;

Can you replace this whole function with:

return DIV_ROUND_UP(ns * dsi->lane_mbps / 8, 1000);

> +}
> +
> +/**
> + * ns2ui - Nanoseconds to UI time periods
> + */
> +static inline unsigned int ns2ui(struct dw_mipi_dsi *dsi, int ns)
> +{
> + unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC;
> +
> + return (ns * (byte_clk_khz / 1000) + 999) / 1000;

Same remarks here.

Sean


> +}
> +
>  static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  {
>   int ret, testdin, vco, val;
> @@ -434,10 +454,21 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>SETRD_MAX | POWER_MANAGE |
>TER_RESISTORS_ON);
>  
> -
> - dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf);
> - dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55);
> - dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa);
> + dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> + dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
> + dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
> + dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
> + dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
> + dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
> +
> + dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> + dw_mipi_dsi_phy_write(dsi, 0x71,
> +   THS_PRE_PROGRAM_EN | (ns2ui(dsi, 50) + 5));
> + dw_mipi_dsi_phy_write(dsi, 0x72,
> +   THS_ZERO_PROGRAM_EN | (ns2bc(dsi, 140) + 2));
> + dw_mipi_dsi_phy_write(dsi, 0x73,
> +   THS_PRE_PROGRAM_EN | (ns2ui(dsi, 60) + 8));
> + dw_mipi_dsi_phy_write(dsi, 0x74, BIT(5) | ns2bc(dsi, 100));
>  
>   dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
>PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
> -- 
> 2.11.0.197.gb556de5.dirty
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH v3 16/24] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

[Sean Paul]

On Sun, Jan 29, 2017 at 01:24:36PM +, John Keeping wrote:
> These values are specified as constant time periods but the PHY
> configuration is in terms of the current lane byte clock so using
> constant values guarantees that the timings will be outside the
> specification with some display configurations.
> 
> Derive the necessary configuration from the byte clock in order to
> ensure that the PHY configuration is correct.
> 
> Signed-off-by: John Keeping 
> ---
> v3:
> - Wrap some long lines
> Unchanged in v2
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 
> ++
>  1 file changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index cfe7e4ba305c..85edf6dd2bac 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -383,6 +383,26 @@ static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi 
> *dsi, u8 test_code,
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLK | PHY_UNTESTCLR);
>  }
>  
> +/**
> + * ns2bc - Nanoseconds to byte clock cycles
> + */
> +static inline unsigned int ns2bc(struct dw_mipi_dsi *dsi, int ns)
> +{
> + unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC / 8;

Why multiply by 1000 (MSEC_PER_SEC) only to immediately divide by 1000?

> +
> + return (ns * (byte_clk_khz / 1000) + 999) / 1000;

Can you replace this whole function with:

return DIV_ROUND_UP(ns * dsi->lane_mbps / 8, 1000);

> +}
> +
> +/**
> + * ns2ui - Nanoseconds to UI time periods
> + */
> +static inline unsigned int ns2ui(struct dw_mipi_dsi *dsi, int ns)
> +{
> + unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC;
> +
> + return (ns * (byte_clk_khz / 1000) + 999) / 1000;

Same remarks here.

Sean


> +}
> +
>  static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  {
>   int ret, testdin, vco, val;
> @@ -434,10 +454,21 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>SETRD_MAX | POWER_MANAGE |
>TER_RESISTORS_ON);
>  
> -
> - dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf);
> - dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55);
> - dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa);
> + dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> + dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
> + dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
> + dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
> + dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
> + dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
> +
> + dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> + dw_mipi_dsi_phy_write(dsi, 0x71,
> +   THS_PRE_PROGRAM_EN | (ns2ui(dsi, 50) + 5));
> + dw_mipi_dsi_phy_write(dsi, 0x72,
> +   THS_ZERO_PROGRAM_EN | (ns2bc(dsi, 140) + 2));
> + dw_mipi_dsi_phy_write(dsi, 0x73,
> +   THS_PRE_PROGRAM_EN | (ns2ui(dsi, 60) + 8));
> + dw_mipi_dsi_phy_write(dsi, 0x74, BIT(5) | ns2bc(dsi, 100));
>  
>   dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
>PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
> -- 
> 2.11.0.197.gb556de5.dirty
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [RFC 1/3] system-power: Add system power and restart framework

[Pavel Machek]

Hi!


> +struct system_power_chip;
> +
> +struct system_power_ops {
> + int (*restart)(struct system_power_chip *chip, enum reboot_mode mode,
> +char *cmd);
> + int (*power_off_prepare)(struct system_power_chip *chip);
> + int (*power_off)(struct system_power_chip *chip);
> +};
> +
> +struct system_power_chip {
> + const struct system_power_ops *ops;
> + struct list_head list;
> + struct device *dev;
> +};

Is it useful to have two structures? AFAICT one would do.

Do we always have struct device * to work with? IMO we have nothing
suitable for example in the ACPI case. Would void * be more suitable?

Could you convert someting (acpi?) to the new framework as
demonstration?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC 1/3] system-power: Add system power and restart framework

[Pavel Machek]

Hi!


> +struct system_power_chip;
> +
> +struct system_power_ops {
> + int (*restart)(struct system_power_chip *chip, enum reboot_mode mode,
> +char *cmd);
> + int (*power_off_prepare)(struct system_power_chip *chip);
> + int (*power_off)(struct system_power_chip *chip);
> +};
> +
> +struct system_power_chip {
> + const struct system_power_ops *ops;
> + struct list_head list;
> + struct device *dev;
> +};

Is it useful to have two structures? AFAICT one would do.

Do we always have struct device * to work with? IMO we have nothing
suitable for example in the ACPI case. Would void * be more suitable?

Could you convert someting (acpi?) to the new framework as
demonstration?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

[Ondrej Zary]

On Sunday 29 January 2017 02:05:02 Finn Thain wrote:
> On Sat, 28 Jan 2017, Ondrej Zary wrote:
> > On Monday 16 January 2017 00:50:57 Finn Thain wrote:
> > > This series removes some unused code and related comments, addresses
> > > the warnings generated by 'make W=1' and 'make C=1' and fixes a
> > > theoretical bug in the bus reset method in atari_scsi.
> > >
> > > There's also a patch to add a missing error check during target
> > > selection. The only target I tested was a QUANTUM DAYTONA514S disk as
> > > that's all I have access to right now. Some testing with other targets
> > > would be prudent.
> > >
> > > Michael, Ondrej, can I get you to review/test please?
> >
> > Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip),
> > DTC-3181L (DTCT-436P chip) and MS-PNR (53C400A chip) ISA cards -
> > everything works fine!
> >
> > Targets tested:
> > QUANTUM  LP240S GM240S01X
> > IBM  DORS-32160
> > IBM  0663L12
> >
> > Thanks.
> >
> > Tested-by: Ondrej Zary 
>
> Very helpful. Thank you, Ondrej.

Also tested two CD-ROM drives and they didn't work (machine hangs). They
didn't work before and looks like they never worked with PDMA.

The fundamental problem of PDMA is that it either transfers all required data
or it breaks horribly. Even when I added timeouts to the possibly infinite
loops (to avoid hangs), the chip remained in some bad state. Sometimes the
53C80 gated IRQ check triggers. This can be hopefully fixed but there is a HW
limitation: if less than 128 bytes were read from SCSI device, they get lost
in chip buffer (the 128B buffers don't swap until full).

Fortunately, most of the requests for too much data are bogus. The problem is
that generic_NCR5380_dma_xfer_len() uses cmd->transfersize which seems to be
wrong. All other NCR5380 drivers use cmd->SCp.this_residual.

This is also why rescan-scsi-bus hangs (cmd->transfersize is 8192 but
cmd->SCp.this_residual is only 96).

This quick fix allows CD-ROM and also rescan-scsi-bus to work.
But it's not complete. Seems that we need:
 - fix pread and pwrite to terminate gracefully
 - something like atari_scsi_dma_xfer_len to allow DMA only for block commands

@@ -588,22 +619,19 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
 struct scsi_cmnd *cmd)
 {
-   int transfersize = cmd->transfersize;
+   int transfersize = cmd->SCp.this_residual;

if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
return 0;

-   /* Limit transfers to 32K, for xx400 & xx406
-* pseudoDMA that transfers in 128 bytes blocks.
-*/
-   if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-   !(cmd->SCp.this_residual % transfersize))
-   transfersize = 32 * 1024;
-
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
transfersize = 0;

+   /* Limit transfers to 32K */
+   if (transfersize > 32 * 1024)
+   transfersize = 32 * 1024;
+
return transfersize;
 }




-- 
Ondrej Zary

Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

[Ondrej Zary]

On Sunday 29 January 2017 02:05:02 Finn Thain wrote:
> On Sat, 28 Jan 2017, Ondrej Zary wrote:
> > On Monday 16 January 2017 00:50:57 Finn Thain wrote:
> > > This series removes some unused code and related comments, addresses
> > > the warnings generated by 'make W=1' and 'make C=1' and fixes a
> > > theoretical bug in the bus reset method in atari_scsi.
> > >
> > > There's also a patch to add a missing error check during target
> > > selection. The only target I tested was a QUANTUM DAYTONA514S disk as
> > > that's all I have access to right now. Some testing with other targets
> > > would be prudent.
> > >
> > > Michael, Ondrej, can I get you to review/test please?
> >
> > Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip),
> > DTC-3181L (DTCT-436P chip) and MS-PNR (53C400A chip) ISA cards -
> > everything works fine!
> >
> > Targets tested:
> > QUANTUM  LP240S GM240S01X
> > IBM  DORS-32160
> > IBM  0663L12
> >
> > Thanks.
> >
> > Tested-by: Ondrej Zary 
>
> Very helpful. Thank you, Ondrej.

Also tested two CD-ROM drives and they didn't work (machine hangs). They
didn't work before and looks like they never worked with PDMA.

The fundamental problem of PDMA is that it either transfers all required data
or it breaks horribly. Even when I added timeouts to the possibly infinite
loops (to avoid hangs), the chip remained in some bad state. Sometimes the
53C80 gated IRQ check triggers. This can be hopefully fixed but there is a HW
limitation: if less than 128 bytes were read from SCSI device, they get lost
in chip buffer (the 128B buffers don't swap until full).

Fortunately, most of the requests for too much data are bogus. The problem is
that generic_NCR5380_dma_xfer_len() uses cmd->transfersize which seems to be
wrong. All other NCR5380 drivers use cmd->SCp.this_residual.

This is also why rescan-scsi-bus hangs (cmd->transfersize is 8192 but
cmd->SCp.this_residual is only 96).

This quick fix allows CD-ROM and also rescan-scsi-bus to work.
But it's not complete. Seems that we need:
 - fix pread and pwrite to terminate gracefully
 - something like atari_scsi_dma_xfer_len to allow DMA only for block commands

@@ -588,22 +619,19 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
 struct scsi_cmnd *cmd)
 {
-   int transfersize = cmd->transfersize;
+   int transfersize = cmd->SCp.this_residual;

if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
return 0;

-   /* Limit transfers to 32K, for xx400 & xx406
-* pseudoDMA that transfers in 128 bytes blocks.
-*/
-   if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-   !(cmd->SCp.this_residual % transfersize))
-   transfersize = 32 * 1024;
-
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
transfersize = 0;

+   /* Limit transfers to 32K */
+   if (transfersize > 32 * 1024)
+   transfersize = 32 * 1024;
+
return transfersize;
 }




-- 
Ondrej Zary

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 03:08:42PM +0530, Nayna wrote:
> 
> > From: "Ken Goldman"  > >
> > Date: 26-Jan-2017 2:53 AM
> > Subject: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs
> > support,for TPM 2.0 firmware event log
> > To:  > >,
> >  > >,
> >  > >
> > Cc:
> > 
> > You do not need to send a new patch set version as long as this
> > one gets peer tested. And it needs to be tested without hacks
> > like plumbing TCPA with TPM 2.0 in QEMU. OF code paths needs to
> > be peer tested to be more specific.
> > 
> > For me the code itself looks good but I simply cannot take it in
> > in the current situation.
> > 
> > /Jarkko
> > 
> > 
> > Tested-by: Kenneth Goldman  > >
> > 
> > I validated a firmware event log taken from a Power 8 against PCR 0-7
> > values for the SHA-1 and SHA-256 banks from a Nuvoton TPM 2.0 chip on
> > that same platform.
> > 
> 
> Thank You Ken.
> 
> Jarkko, I hope now these patches can be accepted for 4.11.
> 
> Thanks & Regards,
>- Nayna

Thanks Ken. I somehow managed to miss that response.

/Jarkko

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 03:08:42PM +0530, Nayna wrote:
> 
> > From: "Ken Goldman"  > >
> > Date: 26-Jan-2017 2:53 AM
> > Subject: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs
> > support,for TPM 2.0 firmware event log
> > To:  > >,
> >  > >,
> >  > >
> > Cc:
> > 
> > You do not need to send a new patch set version as long as this
> > one gets peer tested. And it needs to be tested without hacks
> > like plumbing TCPA with TPM 2.0 in QEMU. OF code paths needs to
> > be peer tested to be more specific.
> > 
> > For me the code itself looks good but I simply cannot take it in
> > in the current situation.
> > 
> > /Jarkko
> > 
> > 
> > Tested-by: Kenneth Goldman  > >
> > 
> > I validated a firmware event log taken from a Power 8 against PCR 0-7
> > values for the SHA-1 and SHA-256 banks from a Nuvoton TPM 2.0 chip on
> > that same platform.
> > 
> 
> Thank You Ken.
> 
> Jarkko, I hope now these patches can be accepted for 4.11.
> 
> Thanks & Regards,
>- Nayna

Thanks Ken. I somehow managed to miss that response.

/Jarkko

Re: [PATCH] tpm: add buffer access validation in tpm2_get_pcr_allocation()

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 08:28:30AM +0530, Nayna wrote:
> 
> 
> On 01/30/2017 02:50 AM, Jarkko Sakkinen wrote:
> > On Sun, Jan 29, 2017 at 10:48:39PM +0530, Nayna wrote:
> > > 
> > > 
> > > On 01/29/2017 08:10 PM, Jarkko Sakkinen wrote:
> > > > On Fri, Jan 27, 2017 at 10:25:49AM -0500, Nayna Jain wrote:
> > > > > This patch add validation in tpm2_get_pcr_allocation to avoid
> > > > > access beyond response buffer length.
> > > > > 
> > > > > Suggested-by: Stefan Berger 
> > > > > Signed-off-by: Nayna Jain 
> > > > 
> > > > This validation looks broken to me.
> > > > 
> > > > > ---
> > > > >drivers/char/tpm/tpm2-cmd.c | 28 +++-
> > > > >1 file changed, 23 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > > > > index 4aad84c..02c1ea7 100644
> > > > > --- a/drivers/char/tpm/tpm2-cmd.c
> > > > > +++ b/drivers/char/tpm/tpm2-cmd.c
> > > > > @@ -1008,9 +1008,13 @@ static ssize_t tpm2_get_pcr_allocation(struct 
> > > > > tpm_chip *chip)
> > > > >   struct tpm2_pcr_selection pcr_selection;
> > > > >   struct tpm_buf buf;
> > > > >   void *marker;
> > > > > - unsigned int count = 0;
> > > > > + void *end;
> > > > > + void *pcr_select_offset;
> > > > > + unsigned int count;
> > > > > + u32 sizeof_pcr_selection;
> > > > > + u32 resp_len;
> > > > 
> > > > Very cosmetic but we almos almost universally use the acronym 'rsp' in
> > > > the TPM driver.
> > > 
> > > Sure will update.
> > > 
> > > > 
> > > > >   int rc;
> > > > > - int i;
> > > > > + int i = 0;
> > > > 
> > > > Why do you need to initialize it?
> > > 
> > > Because in out: count is replaced with i.
> > > And it is replaced because  now for loop can break even before reaching
> > > count, because of new buffer checks.
> > > > 
> > > > > 
> > > > >   rc = tpm_buf_init(, TPM2_ST_NO_SESSIONS, 
> > > > > TPM2_CC_GET_CAPABILITY);
> > > > >   if (rc)
> > > > > @@ -1034,15 +1038,29 @@ static ssize_t tpm2_get_pcr_allocation(struct 
> > > > > tpm_chip *chip)
> > > > >   }
> > > > > 
> > > > >   marker = [TPM_HEADER_SIZE + 9];
> > > > > +
> > > > > + resp_len = be32_to_cpup((__be32 *)[2]);
> > > > > + end = [resp_len];
> > > > 
> > > > What if the response contains larger length than the buffer size?
> > > 
> > > Isn't this check need to be done in tpm_transmit_cmd for all responses ?
> > > Though, it seems it is not done there as well.
> > > 
> > > And to understand what do we expect max buffer length. PAGE_SIZE or
> > > TPM_BUFSIZE ?
> > 
> > Oops. You are correct it is done there:
> > 
> > if (len != be32_to_cpu(header->length))
> > return -EFAULT;
> > 
> > So need to do this.
> 
> To be sure, means nothing need to be done in this. Right ?

This is correct.

> And guess this was the only thing you meant by broken for this patch.
> 
> I will do other two smaller changes as I send the whole new patchset.
> 
> Thanks & Regards,
>   - Nayna

/Jarkko

Re: [PATCH] tpm: add buffer access validation in tpm2_get_pcr_allocation()

[Jarkko Sakkinen]

On Mon, Jan 30, 2017 at 08:28:30AM +0530, Nayna wrote:
> 
> 
> On 01/30/2017 02:50 AM, Jarkko Sakkinen wrote:
> > On Sun, Jan 29, 2017 at 10:48:39PM +0530, Nayna wrote:
> > > 
> > > 
> > > On 01/29/2017 08:10 PM, Jarkko Sakkinen wrote:
> > > > On Fri, Jan 27, 2017 at 10:25:49AM -0500, Nayna Jain wrote:
> > > > > This patch add validation in tpm2_get_pcr_allocation to avoid
> > > > > access beyond response buffer length.
> > > > > 
> > > > > Suggested-by: Stefan Berger 
> > > > > Signed-off-by: Nayna Jain 
> > > > 
> > > > This validation looks broken to me.
> > > > 
> > > > > ---
> > > > >drivers/char/tpm/tpm2-cmd.c | 28 +++-
> > > > >1 file changed, 23 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > > > > index 4aad84c..02c1ea7 100644
> > > > > --- a/drivers/char/tpm/tpm2-cmd.c
> > > > > +++ b/drivers/char/tpm/tpm2-cmd.c
> > > > > @@ -1008,9 +1008,13 @@ static ssize_t tpm2_get_pcr_allocation(struct 
> > > > > tpm_chip *chip)
> > > > >   struct tpm2_pcr_selection pcr_selection;
> > > > >   struct tpm_buf buf;
> > > > >   void *marker;
> > > > > - unsigned int count = 0;
> > > > > + void *end;
> > > > > + void *pcr_select_offset;
> > > > > + unsigned int count;
> > > > > + u32 sizeof_pcr_selection;
> > > > > + u32 resp_len;
> > > > 
> > > > Very cosmetic but we almos almost universally use the acronym 'rsp' in
> > > > the TPM driver.
> > > 
> > > Sure will update.
> > > 
> > > > 
> > > > >   int rc;
> > > > > - int i;
> > > > > + int i = 0;
> > > > 
> > > > Why do you need to initialize it?
> > > 
> > > Because in out: count is replaced with i.
> > > And it is replaced because  now for loop can break even before reaching
> > > count, because of new buffer checks.
> > > > 
> > > > > 
> > > > >   rc = tpm_buf_init(, TPM2_ST_NO_SESSIONS, 
> > > > > TPM2_CC_GET_CAPABILITY);
> > > > >   if (rc)
> > > > > @@ -1034,15 +1038,29 @@ static ssize_t tpm2_get_pcr_allocation(struct 
> > > > > tpm_chip *chip)
> > > > >   }
> > > > > 
> > > > >   marker = [TPM_HEADER_SIZE + 9];
> > > > > +
> > > > > + resp_len = be32_to_cpup((__be32 *)[2]);
> > > > > + end = [resp_len];
> > > > 
> > > > What if the response contains larger length than the buffer size?
> > > 
> > > Isn't this check need to be done in tpm_transmit_cmd for all responses ?
> > > Though, it seems it is not done there as well.
> > > 
> > > And to understand what do we expect max buffer length. PAGE_SIZE or
> > > TPM_BUFSIZE ?
> > 
> > Oops. You are correct it is done there:
> > 
> > if (len != be32_to_cpu(header->length))
> > return -EFAULT;
> > 
> > So need to do this.
> 
> To be sure, means nothing need to be done in this. Right ?

This is correct.

> And guess this was the only thing you meant by broken for this patch.
> 
> I will do other two smaller changes as I send the whole new patchset.
> 
> Thanks & Regards,
>   - Nayna

/Jarkko

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

[Afzal Mohammed]

Hi,

On Mon, Jan 30, 2017 at 02:03:26PM +, Russell King - ARM Linux wrote:
> On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote:

> > The exception base address is now dynamically estimated for no-MMU,
> > display it. As it is the case, now limit VECTORS_BASE usage to MMU
> > scenario.

> > +#define VECTORS_BASE   UL(0x)
> > +
> >  #else /* CONFIG_MMU */
> >  
> >  /*
> > @@ -111,8 +113,6 @@
> >  
> >  #endif /* !CONFIG_MMU */
> >  
> > -#define VECTORS_BASE   UL(0x)
> 
> I think adding a definition for VECTORS_BASE in asm/memory.h for nommu:
> 
> extern unsigned long vectors_base;
> #define VECTORS_BASE  vectors_base

Above was required to be enclosed by below,

 #ifndef __ASSEMBLY__
 #endif

Putting it inside the existing #ifndef __ASSEMBLY__ (which encloses
other externs) in asm/memory.h would put it alongside not so related
definitions as compared to the existing location.

And the existing #ifndef __ASSEMBLY__ in asm/memory.h is a bit down
that makes the above stand separately,

> > +#ifdef CONFIG_MMU
> > MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
> > +#else
> > +   MLK(vectors_base, vectors_base + PAGE_SIZE),
> > +#endif
> 
> will mean that this conditional becomes unnecessary.

> > -#endif
> > +#else /* CONFIG_MMU */
> > +extern unsigned long vectors_base;
> > +#endif /* CONFIG_MMU */
> 
> and you don't need this here either.

but the above improvements make the patch simpler.

Regards
afzal

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

[Afzal Mohammed]

Hi,

On Mon, Jan 30, 2017 at 02:03:26PM +, Russell King - ARM Linux wrote:
> On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote:

> > The exception base address is now dynamically estimated for no-MMU,
> > display it. As it is the case, now limit VECTORS_BASE usage to MMU
> > scenario.

> > +#define VECTORS_BASE   UL(0x)
> > +
> >  #else /* CONFIG_MMU */
> >  
> >  /*
> > @@ -111,8 +113,6 @@
> >  
> >  #endif /* !CONFIG_MMU */
> >  
> > -#define VECTORS_BASE   UL(0x)
> 
> I think adding a definition for VECTORS_BASE in asm/memory.h for nommu:
> 
> extern unsigned long vectors_base;
> #define VECTORS_BASE  vectors_base

Above was required to be enclosed by below,

 #ifndef __ASSEMBLY__
 #endif

Putting it inside the existing #ifndef __ASSEMBLY__ (which encloses
other externs) in asm/memory.h would put it alongside not so related
definitions as compared to the existing location.

And the existing #ifndef __ASSEMBLY__ in asm/memory.h is a bit down
that makes the above stand separately,

> > +#ifdef CONFIG_MMU
> > MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
> > +#else
> > +   MLK(vectors_base, vectors_base + PAGE_SIZE),
> > +#endif
> 
> will mean that this conditional becomes unnecessary.

> > -#endif
> > +#else /* CONFIG_MMU */
> > +extern unsigned long vectors_base;
> > +#endif /* CONFIG_MMU */
> 
> and you don't need this here either.

but the above improvements make the patch simpler.

Regards
afzal

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[Jarkko Sakkinen]

On Sun, Jan 29, 2017 at 07:35:32PM -0500, Ken Goldman wrote:
> On 1/27/2017 7:32 PM, James Bottomley wrote:
> >
> > Sessions are also isolated during each instance of a tpm space.  This
> > means that spaces shouldn't be able to see each other's sessions and
> > is enforced by ensuring that a space user may only refer to sessions
> > handles that are present in their own chip->session_tbl.  Finally when
> > a space is closed, all the sessions belonging to it should be flushed
> > so the handles may be re-used by other spaces.
> 
> This should be true for transient objects as well.

Transient objects do not need anything special. All transient objects
are flushed after command-response so you implicitly get the isolation.

/Jarkko

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[Jarkko Sakkinen]

On Sun, Jan 29, 2017 at 07:35:32PM -0500, Ken Goldman wrote:
> On 1/27/2017 7:32 PM, James Bottomley wrote:
> >
> > Sessions are also isolated during each instance of a tpm space.  This
> > means that spaces shouldn't be able to see each other's sessions and
> > is enforced by ensuring that a space user may only refer to sessions
> > handles that are present in their own chip->session_tbl.  Finally when
> > a space is closed, all the sessions belonging to it should be flushed
> > so the handles may be re-used by other spaces.
> 
> This should be true for transient objects as well.

Transient objects do not need anything special. All transient objects
are flushed after command-response so you implicitly get the isolation.

/Jarkko

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[Jarkko Sakkinen]

On Sun, Jan 29, 2017 at 02:36:58PM -0800, James Bottomley wrote:
> On Sun, 2017-01-29 at 23:39 +0200, Jarkko Sakkinen wrote:
> > On Fri, Jan 27, 2017 at 04:32:38PM -0800, James Bottomley wrote:
> > > sessions are different from transient objects in that their handles
> > > may not be virtualized (because they're used for some hmac
> > > calculations).  Additionally when a session is context saved, a
> > > vestigial memory remains in the TPM and if it is also flushed, that
> > > will be lost and the session context will refuse to load next time,
> > > so
> > > the code is updated to flush only transient objects after a context
> > > save.  Add a separate array (chip->session_tbl) to save and restore
> > > sessions by handle.  Use the failure of a context save or load to
> > > signal that the session has been flushed from the TPM and we can
> > > remove its memory from chip->session_tbl.
> > > 
> > > Sessions are also isolated during each instance of a tpm space. 
> > >  This
> > > means that spaces shouldn't be able to see each other's sessions
> > > and
> > > is enforced by ensuring that a space user may only refer to
> > > sessions
> > > handles that are present in their own chip->session_tbl.  Finally
> > > when
> > > a space is closed, all the sessions belonging to it should be
> > > flushed
> > > so the handles may be re-used by other spaces.
> > > 
> > > Note that if we get a session save or load error, all sessions are
> > > effectively flushed.  Even though we restore the session buffer,
> > > all
> > > the old sessions will refuse to load after the flush and they'll be
> > > purged from our session memory.  This means that while transient
> > > context handling is still soft in the face of errors, session
> > > handling
> > > is hard (any failure of the model means all sessions are lost).
> > > 
> > > Signed-off-by: James Bottomley <
> > > james.bottom...@hansenpartnership.com>
> > > 
> > > ---
> > > 
> > > v2: - add kill space to remove sessions on close
> > > - update changelog
> > > - reduce session table to 3 entries
> > > ---
> > >  drivers/char/tpm/tpm-chip.c   |   6 +++
> > >  drivers/char/tpm/tpm.h|   4 +-
> > >  drivers/char/tpm/tpm2-space.c | 112
> > > --
> > >  drivers/char/tpm/tpms-dev.c   |   2 +-
> > >  4 files changed, 118 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm
> > > -chip.c
> > > index ed4f887..6282ad0 100644
> > > --- a/drivers/char/tpm/tpm-chip.c
> > > +++ b/drivers/char/tpm/tpm-chip.c
> > > @@ -130,6 +130,7 @@ static void tpm_dev_release(struct device *dev)
> > >  
> > >   kfree(chip->log.bios_event_log);
> > >   kfree(chip->work_space.context_buf);
> > > + kfree(chip->work_space.session_buf);
> > >   kfree(chip);
> > >  }
> > >  
> > > @@ -223,6 +224,11 @@ struct tpm_chip *tpm_chip_alloc(struct device
> > > *pdev,
> > >   rc = -ENOMEM;
> > >   goto out;
> > >   }
> > > + chip->work_space.session_buf = kzalloc(PAGE_SIZE,
> > > GFP_KERNEL);
> > > + if (!chip->work_space.session_buf) {
> > > + rc = -ENOMEM;
> > > + goto out;
> > > + }
> > >  
> > >   return chip;
> > >  
> > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > index c4b8ec9..10c57b9 100644
> > > --- a/drivers/char/tpm/tpm.h
> > > +++ b/drivers/char/tpm/tpm.h
> > > @@ -161,6 +161,8 @@ enum tpm2_cc_attrs {
> > >  struct tpm_space {
> > >   u32 context_tbl[3];
> > >   u8 *context_buf;
> > > + u32 session_tbl[3];
> > > + u8 *session_buf;
> > >  };
> > >  
> > >  enum tpm_chip_flags {
> > > @@ -583,7 +585,7 @@ unsigned long tpm2_calc_ordinal_duration(struct
> > > tpm_chip *chip, u32 ordinal);
> > >  int tpm2_probe(struct tpm_chip *chip);
> > >  int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
> > >  int tpm2_init_space(struct tpm_space *space);
> > > -void tpm2_del_space(struct tpm_space *space);
> > > +void tpm2_del_space(struct tpm_chip *chip, struct tpm_space
> > > *space);
> > >  int tpm2_prepare_space(struct tpm_chip *chip, struct tpm_space
> > > *space, u32 cc,
> > >  u8 *cmd);
> > >  int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space
> > > *space,
> > > diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2
> > > -space.c
> > > index d241c2a..2b3d1ad 100644
> > > --- a/drivers/char/tpm/tpm2-space.c
> > > +++ b/drivers/char/tpm/tpm2-space.c
> > > @@ -32,18 +32,28 @@ struct tpm2_context {
> > >   __be16 blob_size;
> > >  } __packed;
> > >  
> > > +static void tpm2_kill_sessions(struct tpm_chip *chip, struct
> > > tpm_space *space);
> > > +
> > >  int tpm2_init_space(struct tpm_space *space)
> > >  {
> > >   space->context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > >   if (!space->context_buf)
> > >   return -ENOMEM;
> > >  
> > > + space->session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > > + if (space->session_buf == NULL) {
> > > + kfree(space->context_buf);
> > > + return -ENOMEM;
> 

Re: [tpmdd-devel] [PATCH v2 1/2] tpm2: add session handle context saving and restoring to the space code

[Jarkko Sakkinen]

On Sun, Jan 29, 2017 at 02:36:58PM -0800, James Bottomley wrote:
> On Sun, 2017-01-29 at 23:39 +0200, Jarkko Sakkinen wrote:
> > On Fri, Jan 27, 2017 at 04:32:38PM -0800, James Bottomley wrote:
> > > sessions are different from transient objects in that their handles
> > > may not be virtualized (because they're used for some hmac
> > > calculations).  Additionally when a session is context saved, a
> > > vestigial memory remains in the TPM and if it is also flushed, that
> > > will be lost and the session context will refuse to load next time,
> > > so
> > > the code is updated to flush only transient objects after a context
> > > save.  Add a separate array (chip->session_tbl) to save and restore
> > > sessions by handle.  Use the failure of a context save or load to
> > > signal that the session has been flushed from the TPM and we can
> > > remove its memory from chip->session_tbl.
> > > 
> > > Sessions are also isolated during each instance of a tpm space. 
> > >  This
> > > means that spaces shouldn't be able to see each other's sessions
> > > and
> > > is enforced by ensuring that a space user may only refer to
> > > sessions
> > > handles that are present in their own chip->session_tbl.  Finally
> > > when
> > > a space is closed, all the sessions belonging to it should be
> > > flushed
> > > so the handles may be re-used by other spaces.
> > > 
> > > Note that if we get a session save or load error, all sessions are
> > > effectively flushed.  Even though we restore the session buffer,
> > > all
> > > the old sessions will refuse to load after the flush and they'll be
> > > purged from our session memory.  This means that while transient
> > > context handling is still soft in the face of errors, session
> > > handling
> > > is hard (any failure of the model means all sessions are lost).
> > > 
> > > Signed-off-by: James Bottomley <
> > > james.bottom...@hansenpartnership.com>
> > > 
> > > ---
> > > 
> > > v2: - add kill space to remove sessions on close
> > > - update changelog
> > > - reduce session table to 3 entries
> > > ---
> > >  drivers/char/tpm/tpm-chip.c   |   6 +++
> > >  drivers/char/tpm/tpm.h|   4 +-
> > >  drivers/char/tpm/tpm2-space.c | 112
> > > --
> > >  drivers/char/tpm/tpms-dev.c   |   2 +-
> > >  4 files changed, 118 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm
> > > -chip.c
> > > index ed4f887..6282ad0 100644
> > > --- a/drivers/char/tpm/tpm-chip.c
> > > +++ b/drivers/char/tpm/tpm-chip.c
> > > @@ -130,6 +130,7 @@ static void tpm_dev_release(struct device *dev)
> > >  
> > >   kfree(chip->log.bios_event_log);
> > >   kfree(chip->work_space.context_buf);
> > > + kfree(chip->work_space.session_buf);
> > >   kfree(chip);
> > >  }
> > >  
> > > @@ -223,6 +224,11 @@ struct tpm_chip *tpm_chip_alloc(struct device
> > > *pdev,
> > >   rc = -ENOMEM;
> > >   goto out;
> > >   }
> > > + chip->work_space.session_buf = kzalloc(PAGE_SIZE,
> > > GFP_KERNEL);
> > > + if (!chip->work_space.session_buf) {
> > > + rc = -ENOMEM;
> > > + goto out;
> > > + }
> > >  
> > >   return chip;
> > >  
> > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > index c4b8ec9..10c57b9 100644
> > > --- a/drivers/char/tpm/tpm.h
> > > +++ b/drivers/char/tpm/tpm.h
> > > @@ -161,6 +161,8 @@ enum tpm2_cc_attrs {
> > >  struct tpm_space {
> > >   u32 context_tbl[3];
> > >   u8 *context_buf;
> > > + u32 session_tbl[3];
> > > + u8 *session_buf;
> > >  };
> > >  
> > >  enum tpm_chip_flags {
> > > @@ -583,7 +585,7 @@ unsigned long tpm2_calc_ordinal_duration(struct
> > > tpm_chip *chip, u32 ordinal);
> > >  int tpm2_probe(struct tpm_chip *chip);
> > >  int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
> > >  int tpm2_init_space(struct tpm_space *space);
> > > -void tpm2_del_space(struct tpm_space *space);
> > > +void tpm2_del_space(struct tpm_chip *chip, struct tpm_space
> > > *space);
> > >  int tpm2_prepare_space(struct tpm_chip *chip, struct tpm_space
> > > *space, u32 cc,
> > >  u8 *cmd);
> > >  int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space
> > > *space,
> > > diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2
> > > -space.c
> > > index d241c2a..2b3d1ad 100644
> > > --- a/drivers/char/tpm/tpm2-space.c
> > > +++ b/drivers/char/tpm/tpm2-space.c
> > > @@ -32,18 +32,28 @@ struct tpm2_context {
> > >   __be16 blob_size;
> > >  } __packed;
> > >  
> > > +static void tpm2_kill_sessions(struct tpm_chip *chip, struct
> > > tpm_space *space);
> > > +
> > >  int tpm2_init_space(struct tpm_space *space)
> > >  {
> > >   space->context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > >   if (!space->context_buf)
> > >   return -ENOMEM;
> > >  
> > > + space->session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > > + if (space->session_buf == NULL) {
> > > + kfree(space->context_buf);
> > > + return -ENOMEM;
> 

Re: [PATCH v2] clk: add more managed APIs

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
> Maybe the additional calls make sense; I can imagine they would.
> However, I personally would be a bit wary of changing the initialization
> order of multi-clock initializations, and I am not sure how a single call
> could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
> seems like a bit too much).
> 
> [ On a side note, why is there no clk_get_prepare_enable() and
>   clk_get_prepare() ? Maybe it would be better to introduce those
>   together with the matching devm_ functions in a separate patch
>   if they are useful. ]

If you take the view that trying to keep clocks disabled is a good way
to save power, then you'd have the clk_prepare() or maybe
clk_prepare_enable() in your runtime PM resume handler, or maybe even
deeper in the driver... the original design goal of the clk API was to
allow power saving and clock control.

With that in mind, getting and enabling the clock together in the
probe function didn't make sense.

I feel that aspect has been somewhat lost, and people now regard much
of the clk API as a bit of a probe-time nusience.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] clk: add more managed APIs

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
> Maybe the additional calls make sense; I can imagine they would.
> However, I personally would be a bit wary of changing the initialization
> order of multi-clock initializations, and I am not sure how a single call
> could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
> seems like a bit too much).
> 
> [ On a side note, why is there no clk_get_prepare_enable() and
>   clk_get_prepare() ? Maybe it would be better to introduce those
>   together with the matching devm_ functions in a separate patch
>   if they are useful. ]

If you take the view that trying to keep clocks disabled is a good way
to save power, then you'd have the clk_prepare() or maybe
clk_prepare_enable() in your runtime PM resume handler, or maybe even
deeper in the driver... the original design goal of the clk API was to
allow power saving and clock control.

With that in mind, getting and enabling the clock together in the
probe function didn't make sense.

I feel that aspect has been somewhat lost, and people now regard much
of the clk API as a bit of a probe-time nusience.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

[Matt Fleming]

On Tue, 31 Jan, at 08:24:53AM, Michael Ellerman wrote:
> 
> I'm hitting this on multiple powerpc systems:
> 
> [   38.339126] rq->clock_update_flags < RQCF_ACT_SKIP
> [   38.339134] [ cut here ]
> [   38.339142] WARNING: CPU: 2 PID: 1 at kernel/sched/sched.h:804 
> detach_task_cfs_rq+0xa0c/0xd10

[...]
 
> I assume I should be worried?

Thanks for the report. No need to worry, the bug has existed for a
while, this patch just turns on the warning ;-)

The following commit queued up in tip/sched/core should fix your
issues (assuming you see the same callstack on all your powerpc
machines):

  
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=sched/core=1b1d62254df0fe42a711eb71948f915918987790

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

[Matt Fleming]

On Tue, 31 Jan, at 08:24:53AM, Michael Ellerman wrote:
> 
> I'm hitting this on multiple powerpc systems:
> 
> [   38.339126] rq->clock_update_flags < RQCF_ACT_SKIP
> [   38.339134] [ cut here ]
> [   38.339142] WARNING: CPU: 2 PID: 1 at kernel/sched/sched.h:804 
> detach_task_cfs_rq+0xa0c/0xd10

[...]
 
> I assume I should be worried?

Thanks for the report. No need to worry, the bug has existed for a
while, this patch just turns on the warning ;-)

The following commit queued up in tip/sched/core should fix your
issues (assuming you see the same callstack on all your powerpc
machines):

  
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=sched/core=1b1d62254df0fe42a711eb71948f915918987790

Re: [PATCH 1/4] dt-bindings: Add binding for brcm,bcm2835-sdhost.

[Stefan Wahren]

> Gerd Hoffmann  hat am 27. Januar 2017 um 12:36 geschrieben:
> 
> 
> From: Eric Anholt 
> 
> This is the other SD controller on the platform, which can be swapped
> to the role of SD card host using pin muxing.

AFAIK the SDHOST controller isn't able to handle SDIO. Maybe we should mention 
this in the binding document.

Re: [PATCH 1/4] dt-bindings: Add binding for brcm,bcm2835-sdhost.

[Stefan Wahren]

> Gerd Hoffmann  hat am 27. Januar 2017 um 12:36 geschrieben:
> 
> 
> From: Eric Anholt 
> 
> This is the other SD controller on the platform, which can be swapped
> to the role of SD card host using pin muxing.

AFAIK the SDHOST controller isn't able to handle SDIO. Maybe we should mention 
this in the binding document.

Re: [PATCH 4/4] ARM: dts: bcm283x: switch from to

[Stefan Wahren]

> Gerd Hoffmann  hat am 27. Januar 2017 um 12:36 geschrieben:
> 
> 
> This flips the switch from (iproc-driven) sdhci controller to the custom
> sdhost controller.

As long as the SDHOST driver isn't enabled in bcm2835_defconfig we shouldn't do 
that.

Btw please write down the reason why this should be changed.

Re: [PATCH 4/4] ARM: dts: bcm283x: switch from to

[Stefan Wahren]

> Gerd Hoffmann  hat am 27. Januar 2017 um 12:36 geschrieben:
> 
> 
> This flips the switch from (iproc-driven) sdhci controller to the custom
> sdhost controller.

As long as the SDHOST driver isn't enabled in bcm2835_defconfig we shouldn't do 
that.

Btw please write down the reason why this should be changed.