[PATCH -next] staging: fsl-mc: remove .owner field for driver

2016-09-14 Thread Wei Yongjun 
From: Wei Yongjun 

Remove .owner field if calls are used which set it automatically.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Wei Yongjun 
---
 drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
index 2004fa7..1a35cfb 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
@@ -652,7 +652,6 @@ static const struct fsl_mc_device_id match_id_table[] = {
 static struct fsl_mc_driver fsl_mc_allocator_driver = {
.driver = {
   .name = "fsl_mc_allocator",
-  .owner = THIS_MODULE,
   .pm = NULL,
   },
.match_id_table = match_id_table,



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: fsl-mc: use list_del_init instead of list_del/INIT_LIST_HEAD

2016-09-14 Thread Wei Yongjun 
From: Wei Yongjun 

Using list_del_init() instead of list_del() + INIT_LIST_HEAD().

Signed-off-by: Wei Yongjun 
---
 drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
index 2004fa7..1e06d28 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
@@ -142,8 +142,7 @@ static int __must_check 
fsl_mc_resource_pool_remove_device(struct fsl_mc_device
goto out_unlock;
}
 
-   list_del(>node);
-   INIT_LIST_HEAD(>node);
+   list_del_init(>node);
res_pool->free_count--;
res_pool->max_count--;
 
@@ -220,8 +219,7 @@ int __must_check fsl_mc_resource_allocate(struct fsl_mc_bus 
*mc_bus,
res_pool->free_count > res_pool->max_count))
goto out_unlock;
 
-   list_del(>node);
-   INIT_LIST_HEAD(>node);
+   list_del_init(>node);
 
res_pool->free_count--;
error = 0;



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: android: ion: Fix return value check in hi6220_ion_probe()

2016-09-14 Thread Wei Yongjun 
From: Wei Yongjun 

In case of error, the function ion_device_create() returns ERR_PTR() and
never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
index f392db2..659aa71 100644
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
@@ -49,8 +49,8 @@ static int hi6220_ion_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ipdev);
 
ipdev->idev = ion_device_create(NULL);
-   if (!ipdev->idev)
-   return -ENOMEM;
+   if (IS_ERR(ipdev->idev))
+   return PTR_ERR(ipdev->idev);
 
ipdev->data = ion_parse_dt(pdev, hisi_heaps);
if (IS_ERR(ipdev->data))



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2 v2] pci-hyperv: lock pci bus on device eject

2016-09-14 Thread Long Li 
From: Long Li 

A PCI_EJECT message can arrive at the same time we are calling 
pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message 
or in create_root_hv_pci_bus(), in this case we could potentailly modify the 
bus from multiple places. Properly lock the bus access.

Thanks Dexuan Cui  for pointing out the race condition in 
create_root_hv_pci_bus().

Signed-off-by: Long Li 
---
 drivers/pci/host/pci-hyperv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 4a37598..33c75c9 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1198,9 +1198,11 @@ static int create_root_hv_pci_bus(struct 
hv_pcibus_device *hbus)
hbus->pci_bus->msi = >msi_chip;
hbus->pci_bus->msi->dev = >hdev->device;
 
+   pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_bus_assign_resources(hbus->pci_bus);
pci_bus_add_devices(hbus->pci_bus);
+   pci_unlock_rescan_remove();
hbus->state = hv_pcibus_installed;
return 0;
 }
@@ -1590,8 +1592,10 @@ static void hv_eject_device_work(struct work_struct 
*work)
pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
   wslot);
if (pdev) {
+   pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
pci_dev_put(pdev);
+   pci_unlock_rescan_remove();
}
 
memset(, 0, sizeof(ctxt));
-- 
1.8.5.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2 v2] pci-hyperv: properly handle pci bus remove

2016-09-14 Thread Long Li 
From: Long Li 

hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device 
from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is 
already removed before the call, so we don't need to rescan the bus in the 
workqueue scheduled from hv_pci_devices_present. By introducing status 
hv_pcibus_removed, we can avoid this situation.

The patch fixes the following kernel panic.

[  383.853124] Workqueue: events pci_devices_present_work [pci_hyperv]
[  383.853124] task: 88007f5f8000 ti: 88007f60 task.ti:
88007f60
[  383.853124] RIP: 0010:[]  []
pci_is_pcie+0x6/0x20
[  383.853124] RSP: 0018:88007f603d38  EFLAGS: 00010206
[  383.853124] RAX: 88007f5f8000 RBX: 642f3d4854415056 RCX:
88007f603fd8
[  383.853124] RDX:  RSI:  RDI:
642f3d4854415056
[  383.853124] RBP: 88007f603d68 R08: 0246 R09:
a045eb9e
[  383.853124] R10: 88007b419a80 R11: ea0001c0ef40 R12:
880003ee1c00
[  383.853124] R13: 63702f30303a3137 R14:  R15:
0246
[  383.853124] FS:  () GS:88007b40()
knlGS:
[  383.853124] CS:  0010 DS:  ES:  CR0: 80050033
[  383.853124] CR2: 7f68b3f52350 CR3: 03546000 CR4:
000406f0
[  383.853124] DR0:  DR1:  DR2:

[  383.853124] DR3:  DR6: 0ff0 DR7:
0400
[  383.853124] Stack:
[  383.853124]  88007f603d68 8134db17 0008
880003ee1c00
[  383.853124]  63702f30303a3137 880003d8edb8 88007f603da0
8134ee2d
[  383.853124]  880003d8ed00 88007f603dd8 880075fec320
880003d8edb8
[  383.853124] Call Trace:
[  383.853124]  [] ? pci_scan_slot+0x27/0x140
[  383.853124]  [] pci_scan_child_bus+0x3d/0x150
[  383.853124]  []
pci_devices_present_work+0x3ea/0x400 [pci_hyperv]
[  383.853124]  [] process_one_work+0x17b/0x470
[  383.853124]  [] worker_thread+0x126/0x410
[  383.853124]  [] ? rescuer_thread+0x460/0x460
[  383.853124]  [] kthread+0xcf/0xe0
[  383.853124]  [] ?
kthread_create_on_node+0x140/0x140
[  383.853124]  [] ret_from_fork+0x58/0x90
[  383.853124]  [] ?
kthread_create_on_node+0x140/0x140
[  383.853124] Code: 89 e5 5d 25 f0 00 00 00 c1 f8 04 c3 66 0f 1f 84 00
00 00 00 00 66 66 66 66 90 55 0f b6 47 4a 48 89 e5 5d c3 90 66 66 66 66
90 55 <80> 7f 4a 00 48 89 e5 5d 0f 95 c0 c3 0f 1f 40 00 66 2e 0f 1f 84
[  383.853124] RIP  [] pci_is_pcie+0x6/0x20
[  383.853124]  RSP 

Signed-off-by: Long Li 
---
 drivers/pci/host/pci-hyperv.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a8deeca..4a37598 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -348,6 +348,7 @@ enum hv_pcibus_state {
hv_pcibus_init = 0,
hv_pcibus_probed,
hv_pcibus_installed,
+   hv_pcibus_removed,
hv_pcibus_maximum
 };
 
@@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct work_struct 
*work)
put_pcichild(hpdev, hv_pcidev_ref_initial);
}
 
-   /* Tell the core to rescan bus because there may have been changes. */
-   if (hbus->state == hv_pcibus_installed) {
+   switch (hbus->state) {
+   case hv_pcibus_installed:
+   /*
+* Tell the core to rescan bus
+* because there may have been changes.
+*/
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
-   } else {
+   break;
+
+   case hv_pcibus_init:
+   case hv_pcibus_probed:
survey_child_resources(hbus);
+   break;
+
+   default:
+   break;
}
 
up(>enum_sem);
@@ -2163,6 +2175,7 @@ static int hv_pci_probe(struct hv_device *hdev,
hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
if (!hbus)
return -ENOMEM;
+   hbus->state = hv_pcibus_init;
 
/*
 * The PCI bus "domain" is what is called "segment" in ACPI and
@@ -2305,6 +2318,7 @@ static int hv_pci_remove(struct hv_device *hdev)
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
+   hbus->state = hv_pcibus_removed;
}
 
ret = hv_send_resources_released(hdev);
-- 
1.8.5.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC 2/3] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

2016-09-14 Thread Larry Finger 

On 09/14/2016 04:55 PM, Zach Brown wrote:

Adding led support for phy causes namespace conflicts for some
phy drivers.

The rtl871 driver declared an enum for representing LED states. The enum
contains constant LED_OFF which conflicted with declartation found in
linux/leds.h. LED_OFF changed to LED_STATE_OFF

Signed-off-by: Zach Brown 


I have no objection to this change. My only substantive comment is that LED_ON 
should also be changed to LED_STATE_ON, otherwise there might be another 
namespace collision later. There is also a typo in the commit message. In 
addition, staging driver patches should be sent to Greg KH.


Larry


---
 drivers/staging/rtl8712/rtl8712_led.c | 192 +-
 1 file changed, 96 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_led.c 
b/drivers/staging/rtl8712/rtl8712_led.c
index 9055827..d53ad76 100644
--- a/drivers/staging/rtl8712/rtl8712_led.c
+++ b/drivers/staging/rtl8712/rtl8712_led.c
@@ -52,7 +52,7 @@
 enum _LED_STATE_871x {
LED_UNKNOWN = 0,
LED_ON = 1,
-   LED_OFF = 2,
+   LED_STATE_OFF = 2,
LED_BLINK_NORMAL = 3,
LED_BLINK_SLOWLY = 4,
LED_POWER_ON_BLINK = 5,
@@ -92,7 +92,7 @@ static void InitLed871x(struct _adapter *padapter, struct 
LED_871x *pLed,
nic = padapter->pnetdev;
pLed->padapter = padapter;
pLed->LedPin = LedPin;
-   pLed->CurrLedState = LED_OFF;
+   pLed->CurrLedState = LED_STATE_OFF;
pLed->bLedOn = false;
pLed->bLedBlinkInProgress = false;
pLed->BlinkTimes = 0;
@@ -249,7 +249,7 @@ static void SwLedBlink(struct LED_871x *pLed)
} else {
/* Assign LED state to toggle. */
if (pLed->BlinkingLedState == LED_ON)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;

@@ -312,7 +312,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
switch (pLed->CurrLedState) {
case LED_BLINK_SLOWLY:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -320,7 +320,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
break;
case LED_BLINK_NORMAL:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -335,7 +335,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_NORMAL;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -344,7 +344,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedNoLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_SLOWLY;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -353,7 +353,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedScanBlinkInProgress = false;
} else {
 if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -369,7 +369,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_NORMAL;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState =

Re: [RFC 3/3] phy,leds: add support for led triggers on phy link state change

2016-09-14 Thread Florian Fainelli 
On 09/14/2016 02:55 PM, Zach Brown wrote:
> From: Josh Cartwright 
> 
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> create a set of led triggers for each instantiated PHY device.  There is
> one LED trigger per link-speed, per-phy.
> 
> This allows for a user to configure their system to allow a set of LEDs
> to represent link state changes on the phy.

The part that seems to be missing from this changeset (not an issue) is
how you can "accelerate" the triggers, or rather make sure that the
trigger configuration potentially calls back into the PHY driver when
the requested trigger is actually supported by the on-PHY LEDs.

Other than that, just minor nits here and there.

> 
> Signed-off-by: Josh Cartwright 
> Signed-off-by: Nathan Sullivan 
> Signed-off-by: Zach Brown 
> ---

> +config LED_TRIGGER_PHY
> + bool "Support LED triggers for tracking link state"
> + depends on LEDS_TRIGGERS
> + ---help---
> +   Adds support for a set of LED trigger events per-PHY.  Link
> +   state change will trigger the events, for consumption by an
> +   LED class driver.  There are triggers for each link speed,
> +   and are of the form:
> +::
> +
> +   Where speed is one of: 10Mb, 100Mb, Gb, 2.5Gb, or 10GbE.

I would do s/10GbE/10Gb/ just to be consistent with the other speeds, or
maybe, to avoid too much duplicationg of how we represent speeds, use
the same set of strings that drivers/net/phy/phy.c::phy_speed_to_str uses.


> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index c6f6683..3345767 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -936,6 +936,7 @@ void phy_state_machine(struct work_struct *work)
>   phydev->state = PHY_NOLINK;
>   netif_carrier_off(phydev->attached_dev);
>   phydev->adjust_link(phydev->attached_dev);
> + phy_led_trigger_change_speed(phydev);

Since we have essentially two actions to take when performing link state
changes:

- call the adjust_link callback
- call into the LED trigger

we might consider encapsulating this into a function that could be named
phy_adjust_link() and does both of these. That would be a preliminary
patch to this this one.

>  
> @@ -345,6 +347,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus, 
> int addr, int phy_id,
>  
>   dev->state = PHY_DOWN;
>  
> + phy_led_triggers_register(dev);
> +
>   mutex_init(>lock);
>   INIT_DELAYED_WORK(>state_queue, phy_state_machine);
>   INIT_WORK(>phy_queue, phy_change);

Humm, should it be before the PHY state machine workqueue creation or
after? Just wondering if there is a remote chance we could get an user
to immediately program a trigger and this could create a problem, maybe
not so much.

> diff --git a/drivers/net/phy/phy_led_triggers.c 
> b/drivers/net/phy/phy_led_triggers.c
> new file mode 100644
> index 000..6c40414
> --- /dev/null
> +++ b/drivers/net/phy/phy_led_triggers.c
> @@ -0,0 +1,109 @@
> +/* Copyright (C) 2016 National Instruments Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +
> +void phy_led_trigger_change_speed(struct phy_device *phy)
> +{
> + struct phy_led_trigger *plt;
> +
> + if (!phy->link) {
> + if (phy->last_triggered) {
> + led_trigger_event(>last_triggered->trigger,
> +   LED_OFF);
> + phy->last_triggered = NULL;
> + }
> + return;
> + }
> +
> + switch (phy->speed) {
> + case SPEED_10:
> + plt = >phy_led_trigger[0];
> + break;
> + case SPEED_100:
> + plt = >phy_led_trigger[1];
> + break;
> + case SPEED_1000:
> + plt = >phy_led_trigger[2];
> + break;
> + case SPEED_2500:
> + plt = >phy_led_trigger[3];
> + break;
> + case SPEED_1:
> + plt = >phy_led_trigger[4];
> + break;

We could use a table here indexed by the speed, or have a function that
does phy_speed_to_led_trigger(unsigned int speed) for instance, which
would be more robust to adding other speeds in the future.

> + default:
> + plt = NULL;
> + break;
> + }
> +
> + if (plt != phy->last_triggered) {
> +

[RFC 2/3] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

2016-09-14 Thread Zach Brown 
Adding led support for phy causes namespace conflicts for some
phy drivers.

The rtl871 driver declared an enum for representing LED states. The enum
contains constant LED_OFF which conflicted with declartation found in
linux/leds.h. LED_OFF changed to LED_STATE_OFF

Signed-off-by: Zach Brown 
---
 drivers/staging/rtl8712/rtl8712_led.c | 192 +-
 1 file changed, 96 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_led.c 
b/drivers/staging/rtl8712/rtl8712_led.c
index 9055827..d53ad76 100644
--- a/drivers/staging/rtl8712/rtl8712_led.c
+++ b/drivers/staging/rtl8712/rtl8712_led.c
@@ -52,7 +52,7 @@
 enum _LED_STATE_871x {
LED_UNKNOWN = 0,
LED_ON = 1,
-   LED_OFF = 2,
+   LED_STATE_OFF = 2,
LED_BLINK_NORMAL = 3,
LED_BLINK_SLOWLY = 4,
LED_POWER_ON_BLINK = 5,
@@ -92,7 +92,7 @@ static void InitLed871x(struct _adapter *padapter, struct 
LED_871x *pLed,
nic = padapter->pnetdev;
pLed->padapter = padapter;
pLed->LedPin = LedPin;
-   pLed->CurrLedState = LED_OFF;
+   pLed->CurrLedState = LED_STATE_OFF;
pLed->bLedOn = false;
pLed->bLedBlinkInProgress = false;
pLed->BlinkTimes = 0;
@@ -249,7 +249,7 @@ static void SwLedBlink(struct LED_871x *pLed)
} else {
/* Assign LED state to toggle. */
if (pLed->BlinkingLedState == LED_ON)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
 
@@ -312,7 +312,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
switch (pLed->CurrLedState) {
case LED_BLINK_SLOWLY:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -320,7 +320,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
break;
case LED_BLINK_NORMAL:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -335,7 +335,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_NORMAL;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -344,7 +344,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedNoLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_SLOWLY;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -353,7 +353,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedScanBlinkInProgress = false;
} else {
 if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -369,7 +369,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_NORMAL;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
pLed->BlinkingLedState = LED_ON;
mod_timer(>BlinkTimer, jiffies +
@@ -378,7 +378,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedNoLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_SLOWLY;
if (pLed->bLedOn)
-

[RFC 3/3] phy, leds: add support for led triggers on phy link state change

2016-09-14 Thread Zach Brown 
From: Josh Cartwright 

Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
create a set of led triggers for each instantiated PHY device.  There is
one LED trigger per link-speed, per-phy.

This allows for a user to configure their system to allow a set of LEDs
to represent link state changes on the phy.

Signed-off-by: Josh Cartwright 
Signed-off-by: Nathan Sullivan 
Signed-off-by: Zach Brown 
---
 drivers/net/phy/Kconfig|  12 
 drivers/net/phy/Makefile   |   1 +
 drivers/net/phy/phy.c  |   8 +++
 drivers/net/phy/phy_device.c   |   4 ++
 drivers/net/phy/phy_led_triggers.c | 109 +
 include/linux/phy.h|   9 +++
 include/linux/phy_led_triggers.h   |  42 ++
 7 files changed, 185 insertions(+)
 create mode 100644 drivers/net/phy/phy_led_triggers.c
 create mode 100644 include/linux/phy_led_triggers.h

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 1c3e07c..4aeaba4 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -15,6 +15,18 @@ if PHYLIB
 config SWPHY
bool
 
+config LED_TRIGGER_PHY
+   bool "Support LED triggers for tracking link state"
+   depends on LEDS_TRIGGERS
+   ---help---
+ Adds support for a set of LED trigger events per-PHY.  Link
+ state change will trigger the events, for consumption by an
+ LED class driver.  There are triggers for each link speed,
+ and are of the form:
+  ::
+
+ Where speed is one of: 10Mb, 100Mb, Gb, 2.5Gb, or 10GbE.
+
 comment "MDIO bus device drivers"
 
 config MDIO_BCM_IPROC
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..86d12cd 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,6 +2,7 @@
 
 libphy-y   := phy.o phy_device.o mdio_bus.o mdio_device.o
 libphy-$(CONFIG_SWPHY) += swphy.o
+libphy-$(CONFIG_LED_TRIGGER_PHY)   += phy_led_triggers.o
 
 obj-$(CONFIG_PHYLIB)   += libphy.o
 
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c6f6683..3345767 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -936,6 +936,7 @@ void phy_state_machine(struct work_struct *work)
phydev->state = PHY_NOLINK;
netif_carrier_off(phydev->attached_dev);
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
break;
}
 
@@ -949,6 +950,7 @@ void phy_state_machine(struct work_struct *work)
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
 
} else if (0 == phydev->link_timeout--)
needs_aneg = true;
@@ -976,6 +978,7 @@ void phy_state_machine(struct work_struct *work)
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
}
break;
case PHY_FORCING:
@@ -992,6 +995,7 @@ void phy_state_machine(struct work_struct *work)
}
 
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
break;
case PHY_RUNNING:
/* Only register a CHANGE if we are polling and link changed
@@ -1021,6 +1025,7 @@ void phy_state_machine(struct work_struct *work)
}
 
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
 
if (phy_interrupt_is_valid(phydev))
err = phy_config_interrupt(phydev,
@@ -1031,6 +1036,7 @@ void phy_state_machine(struct work_struct *work)
phydev->link = 0;
netif_carrier_off(phydev->attached_dev);
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
do_suspend = true;
}
break;
@@ -1055,6 +1061,7 @@ void phy_state_machine(struct work_struct *work)
phydev->state = PHY_NOLINK;
}
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
} else {
phydev->state = PHY_AN;
phydev->link_timeout = PHY_AN_TIMEOUT;
@@ -1071,6

[RFC 1/3] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

2016-09-14 Thread Zach Brown 
Adding led support for phy causes namespace conflicts for some
phy drivers.

The marvel skge driver declared an enum for representing the states of
Link LED Register. The enum contained constant LED_OFF which conflicted
with declartation found in linux/leds.h.
LED_OFF changed to LED_REG_OFF

Signed-off-by: Zach Brown 
---
 drivers/net/ethernet/marvell/skge.c | 4 ++--
 drivers/net/ethernet/marvell/skge.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c 
b/drivers/net/ethernet/marvell/skge.c
index 7173836..ff5a087 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -1062,7 +1062,7 @@ static void skge_link_up(struct skge_port *skge)
 
 static void skge_link_down(struct skge_port *skge)
 {
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
netif_carrier_off(skge->netdev);
netif_stop_queue(skge->netdev);
 
@@ -2668,7 +2668,7 @@ static int skge_down(struct net_device *dev)
if (hw->ports == 1)
free_irq(hw->pdev->irq, hw);
 
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
if (is_genesis(hw))
genesis_stop(skge);
else
diff --git a/drivers/net/ethernet/marvell/skge.h 
b/drivers/net/ethernet/marvell/skge.h
index a2eb341..ec054d3 100644
--- a/drivers/net/ethernet/marvell/skge.h
+++ b/drivers/net/ethernet/marvell/skge.h
@@ -663,7 +663,7 @@ enum {
LED_SYNC_ON = 1<<3, /* Use Sync Wire to switch LED */
LED_SYNC_OFF= 1<<2, /* Disable Sync Wire Input */
LED_ON  = 1<<1, /* switch LED on */
-   LED_OFF = 1<<0, /* switch LED off */
+   LED_REG_OFF = 1<<0, /* switch LED off */
 };
 
 /* Receive GMAC FIFO (YUKON) */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 0/3] Add support for led triggers on phy link state change

2016-09-14 Thread Zach Brown 
Some drivers that include phy.h defined LED_OFF which conflicts with
definition in leds.h. phy led support uses leds.h so the two namespaces are no
longer isolated.
The first two patches fix the two net drivers that declared enum constants that
conflict with enum constants in linux/leds.h.

The final patch adds support for led triggers on phy link state changes by
adding a config option. When set the config option will create a set of led
triggers for each phy device. Users can use the led triggers to represent link
state changes on the phy.
The changes assumes that there are 5 speed options
10Mb,100Mb,1Gb,2.5Gb,10Gb
The assumption makes mapping a phy_device's current speed to a trigger easy,
but means there are triggers made that aren't used if the phy doesn't support
the corresponding speeds.
Thoughts on how to better manage the triggers created would be appreciated
if is important to do so.

Josh Cartwright (1):
  phy,leds: add support for led triggers on phy link state change

Zach Brown (2):
  skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid
conflicts with leds namespace
  staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid
conflicts with LED namespace

 drivers/net/ethernet/marvell/skge.c   |   4 +-
 drivers/net/ethernet/marvell/skge.h   |   2 +-
 drivers/net/phy/Kconfig   |  12 +++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/phy.c |   8 ++
 drivers/net/phy/phy_device.c  |   4 +
 drivers/net/phy/phy_led_triggers.c| 109 +++
 drivers/staging/rtl8712/rtl8712_led.c | 192 +-
 include/linux/phy.h   |   9 ++
 include/linux/phy_led_triggers.h  |  42 
 10 files changed, 284 insertions(+), 99 deletions(-)
 create mode 100644 drivers/net/phy/phy_led_triggers.c
 create mode 100644 include/linux/phy_led_triggers.h

--
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: drivers: staging: vme: Fixed some code style warnings

2016-09-14 Thread Markus Böhme 
On 09/14/2016 06:31 PM, Andrew Kanner wrote:
> ‎Thanks, I understood my fault, but haven't done this changes yet. I
> can't understand if I should reply to original message with v2 patch or
> send a new email with it?

Just send the patch with your revised commit message as a new mail, and
be sure to mark it as v2.

In future mails, please avoid top-posting. It is frowned upon because it
makes it unnecessarily hard to follow a discussion.

Thanks,
Markus

> 
> 
>   Исходное сообщение  
> От: Markus Böhme
> Отправлено: среда, 14 сентября 2016 г., 15:56
> Кому: Andrew Kanner; gre...@linuxfoundation.org
> Копия: de...@driverdev.osuosl.org; manohar.va...@gmail.com; 
> egor.ulieis...@gmail.com; linux-ker...@vger.kernel.org
> Тема: Re: drivers: staging: vme: Fixed some code style warnings
> 
> On 09/13/2016 12:31 AM, Andrew Kanner wrote:
>> Signed-off-by: Andrew Kanner 
>> ---
>> drivers/staging/vme/devices/vme_pio2_core.c | 12 ++--
>> drivers/staging/vme/devices/vme_user.c | 2 +-
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>> (snip)
> 
> Hello Andrew,
> 
> please be more specific in your subject line, e.g.
> "drivers: staging: vme: Convert to octal notation for permission bits".
> 
> Also don't forget to add a commit message to your patch with a short
> description what you are fixing and why. In your case it would be good
> to mention that you are fixing a checkpatch warning, and to include the
> warning message in your description. Then resend as V2.
> 
> Thanks,
> Markus
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android: ion: Make ION_OF depend on OF_ADDRESS

2016-09-14 Thread Guenter Roeck 
On Wed, Sep 14, 2016 at 08:33:58AM -0700, Laura Abbott wrote:
> The Ion platform code uses of_platform_device_create which has
> dependencies on OF_ADDRESS. Depending on OF is not sufficient
> 
> Building sparc64:allmodconfig ... failed
> --
> Error log:
> ...
> drivers/built-in.o: In function `ion_parse_dt':
> (.text+0x11aa2c): undefined reference to `of_platform_device_create'
> 
> Add a dependency on OF_ADDRESS
> 
> Reported-by: Guenter Roeck <li...@roeck-us.net>
> Signed-off-by: Laura Abbott <labb...@redhat.com>

Tested-by: Guenter Roeck <li...@roeck-us.net>

> ---
> Based on next-20160914
> ---
>  drivers/staging/android/ion/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index 8a54ddc..9410554 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -43,7 +43,7 @@ source "drivers/staging/android/ion/hisilicon/Kconfig"
>  
>  config ION_OF
>   bool "Devicetree support for Ion"
> - depends on ION && OF
> + depends on ION && OF_ADDRESS
>   help
> Provides base support for defining Ion heaps in devicetree
> and setting them up. Also includes functions for platforms
> -- 
> 2.7.4
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: lustre: include/lustre_net.h: Remove unnecessary space before function pointer arguments.

2016-09-14 Thread Greg KH 
On Wed, Sep 14, 2016 at 06:09:09PM +0200, Richard wrote:
> Greetings Linux Kernel Developers,
> 
> This is Task 10 of the Eudyptula Challenge.

These lines are not needed.

> I fix few minor warnings spotted by checkpatch.pl in lustre

You need to be very specific.

> Signed-off-by: Richard 

We need a "full" name, I doubt you sign legal documents as only
"Richard" :)

Please fix up and resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Wed, Sep 14, 2016 at 06:13:40PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 14, 2016 at 06:11:03PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 13, 2016 at 12:53:27PM -0700, Arve Hjønnevåg wrote:
> > > On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra  
> > > wrote:
> > > > cgroups should be irrelevant, PI is unaware of them.
> > > 
> > > I don't think cgroups are irrelevant. PI being unaware of them
> > > explains the problem I described. If the task that holds the lock is
> > > in a cgroup that has a low cpu.shares value, then boosting the task's
> > > priority within that group does necessarily make it any more likely to
> > > run.
> > 
> > Thing is, for FIFO/DL the important parameters (prio and deadline resp.)
> > are not cgroup dependent.
> > 
> > For CFS you're right, and as per usual, cgroups will be a royal pain.
> > While we can compute the total weight in the block chain, getting that
> > back to a task which is stuck in a cgroup is just not going to work
> > well.
> 
> Not to mention the fact that the weight depends on the current running
> state. Having those tasks block insta changes the actual weight.
> 
> > /me curses @ cgroups.. bloody stupid things.
> 
> More of that.


Something a little like so... completely untested, and has a fair number
of corner cases still left open I think..


--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1691,8 +1691,8 @@ struct task_struct {
struct seccomp seccomp;
 
 /* Thread group tracking */
-   u32 parent_exec_id;
-   u32 self_exec_id;
+   u32 parent_exec_id;
+   u32 self_exec_id;
 /* Protection of (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed,
  * mempolicy */
spinlock_t alloc_lock;
@@ -1710,6 +1710,11 @@ struct task_struct {
struct task_struct *pi_top_task;
/* Deadlock detection and priority inheritance handling */
struct rt_mutex_waiter *pi_blocked_on;
+   unsigned long pi_weight;
+#ifdef CONFIG_CGROUP_SCHED
+   struct task_group *orig_task_group;
+   unsigned long normal_weight;
+#endif
 #endif
 
 #ifdef CONFIG_DEBUG_MUTEXES
@@ -1977,6 +1982,8 @@ static inline int tsk_nr_cpus_allowed(st
return p->nr_cpus_allowed;
 }
 
+extern unsigned long task_pi_weight(struct task_struct *p);
+
 #define TNF_MIGRATED   0x01
 #define TNF_NO_GROUP   0x02
 #define TNF_SHARED 0x04
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -20,6 +20,19 @@
 #include "rtmutex_common.h"
 
 /*
+ * !(rt_prio || dl_prio)
+ */
+static inline bool other_prio(int prio)
+{
+   return prio >= MAX_RT_PRIO;
+}
+
+static inline bool other_task(struct task_struct *task)
+{
+   return other_prio(task->prio);
+}
+
+/*
  * lock->owner state tracking:
  *
  * lock->owner holds the task_struct pointer of the owner. Bit 0
@@ -226,6 +239,11 @@ rt_mutex_enqueue(struct rt_mutex *lock,
 
rb_link_node(>tree_entry, parent, link);
rb_insert_color(>tree_entry, >waiters);
+   /*
+* We want the lock->waiter_weight to reflect the sum of all queued
+* waiters.
+*/
+   lock->waiters_weight += waiter->weight;
 }
 
 static void
@@ -239,6 +257,7 @@ rt_mutex_dequeue(struct rt_mutex *lock,
 
rb_erase(>tree_entry, >waiters);
RB_CLEAR_NODE(>tree_entry);
+   lock->waiters_weight += waiter->weight;
 }
 
 static void
@@ -265,6 +284,18 @@ rt_mutex_enqueue_pi(struct task_struct *
 
rb_link_node(>pi_tree_entry, parent, link);
rb_insert_color(>pi_tree_entry, >pi_waiters);
+
+   /*
+* Since a task can own multiple locks, and we have one pi_waiter
+* for every lock, propagate the lock->waiter_weight, which is the sum
+* of all weights queued on that lock, into the top waiter, and add
+* that to the owning task's pi_weight.
+*
+* This results in pi_weight being the sum of all blocked waiters
+* on this task.
+*/
+   waiter->top_weight = waiter->lock->waiters_weight;
+   task->pi_weight += waiter->top_weight;
 }
 
 static void
@@ -278,6 +309,7 @@ rt_mutex_dequeue_pi(struct task_struct *
 
rb_erase(>pi_tree_entry, >pi_waiters);
RB_CLEAR_NODE(>pi_tree_entry);
+   task->pi_weight -= waiter->top_weight;
 }
 
 static void rt_mutex_adjust_prio(struct task_struct *p)
@@ -497,7 +529,7 @@ static int rt_mutex_adjust_prio_chain(st
 * detection is enabled we continue, but stop the
 * requeueing in the chain walk.
 */
-   if (top_waiter != task_top_pi_waiter(task)) {
+   if (top_waiter != task_top_pi_waiter(task) && 
!other_task(task)) {
if (!detect_deadlock)
goto out_unlock_pi;
else
@@ -512,7 +544,7 @@ static int rt_mutex_adjust_prio_chain(st
 * enabled we continue, but stop the requeueing in the chain
 * walk.
 */
-   if

Re: drivers: staging: vme: Fixed some code style warnings

2016-09-14 Thread Andrew Kanner 
‎Thanks, I understood my fault, but haven't done this changes yet. I can't 
understand if I should reply to original message with v2 patch or send a new 
email with it?


  Исходное сообщение  
От: Markus Böhme
Отправлено: среда, 14 сентября 2016 г., 15:56
Кому: Andrew Kanner; gre...@linuxfoundation.org
Копия: de...@driverdev.osuosl.org; manohar.va...@gmail.com; 
egor.ulieis...@gmail.com; linux-ker...@vger.kernel.org
Тема: Re: drivers: staging: vme: Fixed some code style warnings

On 09/13/2016 12:31 AM, Andrew Kanner wrote:
> Signed-off-by: Andrew Kanner 
> ---
> drivers/staging/vme/devices/vme_pio2_core.c | 12 ++--
> drivers/staging/vme/devices/vme_user.c | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
> (snip)

Hello Andrew,

please be more specific in your subject line, e.g.
"drivers: staging: vme: Convert to octal notation for permission bits".

Also don't forget to add a commit message to your patch with a short
description what you are fixing and why. In your case it would be good
to mention that you are fixing a checkpatch warning, and to include the
warning message in your description. Then resend as V2.

Thanks,
Markus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 2/2] pci-hyperv: properly handle device eject

2016-09-14 Thread Long Li 
> -Original Message-
> From: Dexuan Cui
> Sent: Tuesday, September 13, 2016 10:45 PM
> To: Long Li ; KY Srinivasan ;
> Haiyang Zhang ; Bjorn Helgaas
> 
> Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject: RE: [PATCH 2/2] pci-hyperv: properly handle device eject
> 
> > From: Long Li
> > Sent: Wednesday, September 14, 2016 1:41
> >
> > I think this code is safe here. If we reach the code
> > pci_stop_and_remove_bus_device_locked, create_root_hv_pci_bus() is
> > already called.
> 
> When hv_pci_probe() -> create_root_hv_pci_bus() -> pci_scan_child_bus()
> is running on one cpu, I think nothing in the current code can prevent
> hv_eject_device_work() -> pci_stop_and_remove_bus_device_locked()
> from running on another cpu?
> 
> The race window is pretty small however.

This is a valid race condition. I'll work on a V2 patch. Thanks!

> 
> Thanks,
> -- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android: ion: Make ION_OF depend on OF_ADDRESS

2016-09-14 Thread Sumit Semwal 
Hi Laura,

On 14 September 2016 at 21:03, Laura Abbott <labb...@redhat.com> wrote:
> The Ion platform code uses of_platform_device_create which has
> dependencies on OF_ADDRESS. Depending on OF is not sufficient
>
Thanks for the patch; looks good to me.
Please feel free to apply my
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>

Best,
Sumit.

> Building sparc64:allmodconfig ... failed
> --
> Error log:
> ...
> drivers/built-in.o: In function `ion_parse_dt':
> (.text+0x11aa2c): undefined reference to `of_platform_device_create'
>
> Add a dependency on OF_ADDRESS
>
> Reported-by: Guenter Roeck <li...@roeck-us.net>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
> ---
> Based on next-20160914
> ---
>  drivers/staging/android/ion/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index 8a54ddc..9410554 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -43,7 +43,7 @@ source "drivers/staging/android/ion/hisilicon/Kconfig"
>
>  config ION_OF
> bool "Devicetree support for Ion"
> -   depends on ION && OF
> +   depends on ION && OF_ADDRESS
> help
>   Provides base support for defining Ion heaps in devicetree
>   and setting them up. Also includes functions for platforms
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lustre: include/lustre_net.h: Remove unnecessary space before function pointer arguments.

2016-09-14 Thread Richard 
Greetings Linux Kernel Developers,

This is Task 10 of the Eudyptula Challenge.

I fix few minor warnings spotted by checkpatch.pl in lustre


Signed-off-by: Richard 
---
 drivers/staging/lustre/lustre/include/lustre_net.h | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h 
b/drivers/staging/lustre/lustre/include/lustre_net.h
index d5debd6..24ddccab 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -570,13 +570,13 @@ struct ptlrpc_nrs_pol_ops {
 *
 * \param[in,out] policy The policy being initialized
 */
-   int (*op_policy_init) (struct ptlrpc_nrs_policy *policy);
+   int (*op_policy_init)(struct ptlrpc_nrs_policy *policy);
/**
 * Called during policy unregistration; this operation is optional.
 *
 * \param[in,out] policy The policy being unregistered/finalized
 */
-   void(*op_policy_fini) (struct ptlrpc_nrs_policy *policy);
+   void(*op_policy_fini)(struct ptlrpc_nrs_policy *policy);
/**
 * Called when activating a policy via lprocfs; policies allocate and
 * initialize their resources here; this operation is optional.
@@ -585,7 +585,7 @@ struct ptlrpc_nrs_pol_ops {
 *
 * \see nrs_policy_start_locked()
 */
-   int (*op_policy_start) (struct ptlrpc_nrs_policy *policy);
+   int (*op_policy_start)(struct ptlrpc_nrs_policy *policy);
/**
 * Called when deactivating a policy via lprocfs; policies deallocate
 * their resources here; this operation is optional
@@ -594,7 +594,7 @@ struct ptlrpc_nrs_pol_ops {
 *
 * \see nrs_policy_stop0()
 */
-   void(*op_policy_stop) (struct ptlrpc_nrs_policy *policy);
+   void(*op_policy_stop)(struct ptlrpc_nrs_policy *policy);
/**
 * Used for policy-specific operations; i.e. not generic ones like
 * \e PTLRPC_NRS_CTL_START and \e PTLRPC_NRS_CTL_GET_INFO; analogous
@@ -610,8 +610,8 @@ struct ptlrpc_nrs_pol_ops {
 *
 * \see ptlrpc_nrs_policy_control()
 */
-   int (*op_policy_ctl) (struct ptlrpc_nrs_policy *policy,
- enum ptlrpc_nrs_ctl opc, void *arg);
+   int (*op_policy_ctl)(struct ptlrpc_nrs_policy *policy,
+enum ptlrpc_nrs_ctl opc, void *arg);
 
/**
 * Called when obtaining references to the resources of the resource
@@ -648,11 +648,11 @@ struct ptlrpc_nrs_pol_ops {
 * \see ptlrpc_nrs_req_initialize()
 * \see ptlrpc_nrs_hpreq_add_nolock()
 */
-   int (*op_res_get) (struct ptlrpc_nrs_policy *policy,
-  struct ptlrpc_nrs_request *nrq,
-  const struct ptlrpc_nrs_resource *parent,
-  struct ptlrpc_nrs_resource **resp,
-  bool moving_req);
+   int (*op_res_get)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq,
+ const struct ptlrpc_nrs_resource *parent,
+ struct ptlrpc_nrs_resource **resp,
+ bool moving_req);
/**
 * Called when releasing references taken for resources in the resource
 * hierarchy for the request; this operation is optional.
@@ -663,8 +663,8 @@ struct ptlrpc_nrs_pol_ops {
 * \see ptlrpc_nrs_req_finalize()
 * \see ptlrpc_nrs_hpreq_add_nolock()
 */
-   void(*op_res_put) (struct ptlrpc_nrs_policy *policy,
-  const struct ptlrpc_nrs_resource *res);
+   void(*op_res_put)(struct ptlrpc_nrs_policy *policy,
+ const struct ptlrpc_nrs_resource *res);
 
/**
 * Obtains a request for handling from the policy, and optionally
@@ -683,8 +683,8 @@ struct ptlrpc_nrs_pol_ops {
 * \see ptlrpc_nrs_req_get_nolock()
 */
struct ptlrpc_nrs_request *
-   (*op_req_get) (struct ptlrpc_nrs_policy *policy, bool peek,
-  bool force);
+   (*op_req_get)(struct ptlrpc_nrs_policy *policy, bool peek,
+ bool force);
/**
 * Called when attempting to add a request to a policy for later
 * handling; this operation is mandatory.
@@ -697,8 +697,8 @@ struct ptlrpc_nrs_pol_ops {
 *
 * \see ptlrpc_nrs_req_add_nolock()
 */
-   int (*op_req_enqueue) (struct ptlrpc_nrs_policy *policy,
-  struct ptlrpc_nrs_request *nrq);
+   int (*op_req_enqueue)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq);

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Wed, Sep 14, 2016 at 06:11:03PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 13, 2016 at 12:53:27PM -0700, Arve Hjønnevåg wrote:
> > On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra  
> > wrote:
> > > cgroups should be irrelevant, PI is unaware of them.
> > 
> > I don't think cgroups are irrelevant. PI being unaware of them
> > explains the problem I described. If the task that holds the lock is
> > in a cgroup that has a low cpu.shares value, then boosting the task's
> > priority within that group does necessarily make it any more likely to
> > run.
> 
> Thing is, for FIFO/DL the important parameters (prio and deadline resp.)
> are not cgroup dependent.
> 
> For CFS you're right, and as per usual, cgroups will be a royal pain.
> While we can compute the total weight in the block chain, getting that
> back to a task which is stuck in a cgroup is just not going to work
> well.

Not to mention the fact that the weight depends on the current running
state. Having those tasks block insta changes the actual weight.

> /me curses @ cgroups.. bloody stupid things.

More of that.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Tue, Sep 13, 2016 at 12:53:27PM -0700, Arve Hjønnevåg wrote:
> On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra  wrote:
> > cgroups should be irrelevant, PI is unaware of them.
> 
> I don't think cgroups are irrelevant. PI being unaware of them
> explains the problem I described. If the task that holds the lock is
> in a cgroup that has a low cpu.shares value, then boosting the task's
> priority within that group does necessarily make it any more likely to
> run.

Thing is, for FIFO/DL the important parameters (prio and deadline resp.)
are not cgroup dependent.

For CFS you're right, and as per usual, cgroups will be a royal pain.
While we can compute the total weight in the block chain, getting that
back to a task which is stuck in a cgroup is just not going to work
well.

The only 'solution' I can come up with in a hurry is, when the task is
boosted, move it to the root cgroup. That of course has a whole heap of
problems all on its own.

/me curses @ cgroups.. bloody stupid things.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: android: ion: Make ION_OF depend on OF_ADDRESS

2016-09-14 Thread Laura Abbott 
The Ion platform code uses of_platform_device_create which has
dependencies on OF_ADDRESS. Depending on OF is not sufficient

Building sparc64:allmodconfig ... failed
--
Error log:
...
drivers/built-in.o: In function `ion_parse_dt':
(.text+0x11aa2c): undefined reference to `of_platform_device_create'

Add a dependency on OF_ADDRESS

Reported-by: Guenter Roeck <li...@roeck-us.net>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
Based on next-20160914
---
 drivers/staging/android/ion/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 8a54ddc..9410554 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -43,7 +43,7 @@ source "drivers/staging/android/ion/hisilicon/Kconfig"
 
 config ION_OF
bool "Devicetree support for Ion"
-   depends on ION && OF
+   depends on ION && OF_ADDRESS
help
  Provides base support for defining Ion heaps in devicetree
  and setting them up. Also includes functions for platforms
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

2016-09-14 Thread Olaf Hering 
On Fri, Sep 09, k...@exchange.microsoft.com wrote:

> +  * This check is safe since we are executing in the
> +  * interrupt context and time synch messages arre always

Typo.

Olaf


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Wed, Sep 14, 2016 at 09:10:01AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 13, 2016 at 12:53:27PM -0700, Arve Hjønnevåg wrote:

> > Most of the tasks here are not RR/FIFO/DL tasks. I don't see anything
> > in the rtmutex code or documentation that indicates that they don't
> > work for normal tasks. From what I can tell the priority gets boosted
> > in every case. This may not work as well for CFS tasks as for realtime
> > tasks, but it should at least help when there is a large priority
> > difference.
> 
> It does something (it used to explicitly ignore OTHER) but its not
> something well defined or usable.

I looked again, and while it updates the ->prio field for OTHER tasks,
that does not seem to cause a change to the actual weight field (which
is derived from ->static_prio).

So it really should not do anything.. as I remebered it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] Drivers: hv: utils: Support TimeSync version 4.0 protocol samples.

2016-09-14 Thread Olaf Hering 
On Tue, Sep 13, Alex Ng (LIS) wrote:

> > On Thu, Sep 08, k...@exchange.microsoft.com wrote:
> > Perhaps a better approach would be to list the known existing hosts and use
> > the new protocol for upcoming, unknown hosts via 'default:'.
> This is a good idea. I will create another patch that addresses this.

I think this variant would cover upcoming hosts for an old kernel:

switch (vmbus_proto_version) {
case VERSION_WS2008:
util_fw_version = UTIL_WS2K8_FW_VERSION;
sd_srv_version = SD_VERSION_1;
ts_srv_version = TS_VERSION_1;
hb_srv_version = HB_VERSION_1;
break;
case VERSION_WIN7:
case VERSION_WIN8:
case VERSION_WIN8_1:
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
ts_srv_version = TS_VERSION_3;
hb_srv_version = HB_VERSION;
break;
case VERSION_WIN10:
default:
util_fw_version = UTIL_FW_VERSION;
sd_srv_version = SD_VERSION;
ts_srv_version = TS_VERSION;
hb_srv_version = HB_VERSION;
break;
}

Olaf


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: drivers: staging: vme: Fixed some code style warnings

2016-09-14 Thread Markus Böhme 
On 09/13/2016 12:31 AM, Andrew Kanner wrote:
> Signed-off-by: Andrew Kanner 
> ---
>  drivers/staging/vme/devices/vme_pio2_core.c | 12 ++--
>  drivers/staging/vme/devices/vme_user.c  |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)
> (snip)

Hello Andrew,

please be more specific in your subject line, e.g.
"drivers: staging: vme: Convert to octal notation for permission bits".

Also don't forget to add a commit message to your patch with a short
description what you are fixing and why. In your case it would be good
to mention that you are fixing a checkpatch warning, and to include the
warning message in your description. Then resend as V2.

Thanks,
Markus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Wed, Sep 14, 2016 at 09:10:01AM +0200, Peter Zijlstra wrote:
> We could define a meaningful something for CFS and implement that, but
> it isn't currently done.

So the generalization of the Priority Inheritance Protocol is Proxy
Execution Protocol, which basically lets the boosted task run _as_ the
task on the block chain as picked by the schedule function (treating all
of them as runnable). Where 'as' means it really consumes scheduling
resources of the (blocked) donor task.

Since the scheduling function for FIFO is: pick the highest prio one and
go for it, this trivially reduces to PI for FIFO.

Now, Proxy Execution Protocol is 'trivial' to implement on UP, but has a
few wobbles on SMP.

But we can use it to define a sensible definition for a WFQ class
scheduler (like CFS). For these the scheduling function basically runs
the boosted task as every donor task on the block chain gets their slice.
Alternatively, since it treats all 'blocked' tasks as runnable, the
total weight of the boosted task is its own weight plus the sum of
weight on the block chain.

Which is something that shouldn't be too hard to implement, but very
much isn't what happens today.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

2016-09-14 Thread Peter Zijlstra 
On Tue, Sep 13, 2016 at 12:53:27PM -0700, Arve Hjønnevåg wrote:
> On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra  wrote:
> > On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote:
> >
> >> A previous attempt to fix this problem, changed the lock to use
> >> rt_mutex instead of mutex, but this apparently did not work as well as
> >> this patch. I believe the added overhead was noticeable, and it did
> >> not work when the preempted thread was in a different cgroup (I don't
> >> know if this is still the case).
> >
> > Do you actually have RR/FIFO/DL tasks? Currently PI isn't
> > defined/implemented for OTHER.
> >
> 
> Most of the tasks here are not RR/FIFO/DL tasks. I don't see anything
> in the rtmutex code or documentation that indicates that they don't
> work for normal tasks. From what I can tell the priority gets boosted
> in every case. This may not work as well for CFS tasks as for realtime
> tasks, but it should at least help when there is a large priority
> difference.

It does something (it used to explicitly ignore OTHER) but its not
something well defined or usable.

> > cgroups should be irrelevant, PI is unaware of them.
> 
> I don't think cgroups are irrelevant. PI being unaware of them
> explains the problem I described. If the task that holds the lock is
> in a cgroup that has a low cpu.shares value, then boosting the task's
> priority within that group does necessarily make it any more likely to
> run.

See, the problem is that 'priority' is a meaningless concept for
OTHER/CFS.

In any case, typically only RT tasks care about PI, and the traditional
Priority Inheritance algorithm only really works correctly for FIFO. As
is RR has issues and DL is a crude hack, CFS is really just an accident
by not explicitly exempting it.

We could define a meaningful something for CFS and implement that, but
it isn't currently done.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel