Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator

2017-08-07 Thread Tony Lindgren 
* Hans de Goede  [170806 05:37]:
> Register the 5V boost converter as a regulator named
> "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because
> the bq24190 family is also used on ACPI devices where there are no
> device-tree phandles, so regulator_get will fallback to the name and thus
> it must be unique on the system.

Nice, this makes VBUS easy to use for USB PHY drivers :)

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

[PATCH] staging: pi433: style fixes for conditionals

2017-08-07 Thread Frank Jozsa 
Cleans up some incongruous braces

Signed-off-by: Frank Jozsa 
---
 drivers/staging/pi433/pi433_if.c | 203 +++
 1 file changed, 78 insertions(+), 125 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index ed737f4b1e77..542a9bb92d41 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -133,19 +133,14 @@ DIO0_irq_handler(unsigned int irq, void *dev_id, struct 
pt_regs *regs)
 {
struct pi433_device *device = dev_id;
 
-   if  (device->irq_state[DIO0] == DIO_PacketSent)
-   {
+   if  (device->irq_state[DIO0] == DIO_PacketSent) {
device->free_in_fifo = FIFO_SIZE;
printk("DIO0 irq: Packet sent\n"); // TODO: printk() should 
include KERN_ facility level
wake_up_interruptible(>fifo_wait_queue);
-   }
-   else if (device->irq_state[DIO0] == DIO_Rssi_DIO0)
-   {
+   } else if (device->irq_state[DIO0] == DIO_Rssi_DIO0) {
printk("DIO0 irq: RSSI level over threshold\n");
wake_up_interruptible(>rx_wait_queue);
-   }
-   else if (device->irq_state[DIO0] == DIO_PayloadReady)
-   {
+   } else if (device->irq_state[DIO0] == DIO_PayloadReady) {
printk("DIO0 irq: PayloadReady\n");
device->free_in_fifo = 0;
wake_up_interruptible(>fifo_wait_queue);
@@ -159,14 +154,13 @@ DIO1_irq_handler(unsigned int irq, void *dev_id, struct 
pt_regs *regs)
 {
struct pi433_device *device = dev_id;
 
-   if  (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1)
-   {
+   if  (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1) {
device->free_in_fifo = FIFO_SIZE;
-   }
-   else if (device->irq_state[DIO1] == DIO_FifoLevel)
-   {
-   if (device->rx_active)  device->free_in_fifo = FIFO_THRESHOLD - 
1;
-   elsedevice->free_in_fifo = FIFO_SIZE - 
FIFO_THRESHOLD - 1;
+   } else if (device->irq_state[DIO1] == DIO_FifoLevel) {
+   if (device->rx_active)
+   device->free_in_fifo = FIFO_THRESHOLD - 1;
+   else
+   device->free_in_fifo = FIFO_SIZE - FIFO_THRESHOLD - 1;
}
printk("DIO1 irq: %d bytes free in fifo\n", device->free_in_fifo); // 
TODO: printk() should include KERN_ facility level
wake_up_interruptible(>fifo_wait_queue);
@@ -202,12 +196,9 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
/* packet config */
/* enable */
SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
-   if (rx_cfg->enable_sync == optionOn)
-   {
+   if (rx_cfg->enable_sync == optionOn) {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, 
afterSyncInterrupt));
-   }
-   else
-   {
+   } else {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
SET_CHECKED(rf69_set_packet_format  (dev->spi, 
rx_cfg->enable_length_byte));
@@ -216,29 +207,24 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
 
/* lengths */
SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
-   if (rx_cfg->enable_length_byte == optionOn)
-   {
+   if (rx_cfg->enable_length_byte == optionOn) {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
-   }
-   else if (rx_cfg->fixed_message_length != 0)
-   {
+   } else if (rx_cfg->fixed_message_length != 0) {
payload_length = rx_cfg->fixed_message_length;
-   if (rx_cfg->enable_length_byte  == optionOn) payload_length++;
-   if (rx_cfg->enable_address_filtering != filteringOff) 
payload_length++;
+   if (rx_cfg->enable_length_byte  == optionOn)
+   payload_length++;
+   if (rx_cfg->enable_address_filtering != filteringOff)
+   payload_length++;
SET_CHECKED(rf69_set_payload_length(dev->spi, payload_length));
-   }
-   else
-   {
+   } else {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0));
}
 
/* values */
-   if (rx_cfg->enable_sync == optionOn)
-   {
+   if (rx_cfg->enable_sync == optionOn) {
SET_CHECKED(rf69_set_sync_values(dev->spi, 
rx_cfg->sync_pattern));
}
-   if (rx_cfg->enable_address_filtering != filteringOff)
-   {
+   if (rx_cfg->enable_address_filtering != filteringOff) {
SET_CHECKED(rf69_set_node_address (dev->spi, 
rx_cfg->node_address));
SET_CHECKED(rf69_set_broadcast_address(dev->spi, 
rx_cfg->broadcast_address));
}
@@ -258,12 +244,9 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
pi433_tx_cfg *tx_cfg)

[PATCH] staging: pi433: style fixes for conditionals

2017-08-07 Thread Frank Jozsa 
Cleans up some incongruous braces

Signed-off-by: Frank Jozsa 
---
 drivers/staging/pi433/pi433_if.c | 203 +++
 1 file changed, 78 insertions(+), 125 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index ed737f4b1e77..542a9bb92d41 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -133,19 +133,14 @@ DIO0_irq_handler(unsigned int irq, void *dev_id, struct 
pt_regs *regs)
 {
struct pi433_device *device = dev_id;
 
-   if  (device->irq_state[DIO0] == DIO_PacketSent)
-   {
+   if  (device->irq_state[DIO0] == DIO_PacketSent) {
device->free_in_fifo = FIFO_SIZE;
printk("DIO0 irq: Packet sent\n"); // TODO: printk() should 
include KERN_ facility level
wake_up_interruptible(>fifo_wait_queue);
-   }
-   else if (device->irq_state[DIO0] == DIO_Rssi_DIO0)
-   {
+   } else if (device->irq_state[DIO0] == DIO_Rssi_DIO0) {
printk("DIO0 irq: RSSI level over threshold\n");
wake_up_interruptible(>rx_wait_queue);
-   }
-   else if (device->irq_state[DIO0] == DIO_PayloadReady)
-   {
+   } else if (device->irq_state[DIO0] == DIO_PayloadReady) {
printk("DIO0 irq: PayloadReady\n");
device->free_in_fifo = 0;
wake_up_interruptible(>fifo_wait_queue);
@@ -159,14 +154,13 @@ DIO1_irq_handler(unsigned int irq, void *dev_id, struct 
pt_regs *regs)
 {
struct pi433_device *device = dev_id;
 
-   if  (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1)
-   {
+   if  (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1) {
device->free_in_fifo = FIFO_SIZE;
-   }
-   else if (device->irq_state[DIO1] == DIO_FifoLevel)
-   {
-   if (device->rx_active)  device->free_in_fifo = FIFO_THRESHOLD - 
1;
-   elsedevice->free_in_fifo = FIFO_SIZE - 
FIFO_THRESHOLD - 1;
+   } else if (device->irq_state[DIO1] == DIO_FifoLevel) {
+   if (device->rx_active)
+   device->free_in_fifo = FIFO_THRESHOLD - 1;
+   else
+   device->free_in_fifo = FIFO_SIZE - FIFO_THRESHOLD - 1;
}
printk("DIO1 irq: %d bytes free in fifo\n", device->free_in_fifo); // 
TODO: printk() should include KERN_ facility level
wake_up_interruptible(>fifo_wait_queue);
@@ -202,12 +196,9 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
/* packet config */
/* enable */
SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
-   if (rx_cfg->enable_sync == optionOn)
-   {
+   if (rx_cfg->enable_sync == optionOn) {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, 
afterSyncInterrupt));
-   }
-   else
-   {
+   } else {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
SET_CHECKED(rf69_set_packet_format  (dev->spi, 
rx_cfg->enable_length_byte));
@@ -216,29 +207,24 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
 
/* lengths */
SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
-   if (rx_cfg->enable_length_byte == optionOn)
-   {
+   if (rx_cfg->enable_length_byte == optionOn) {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
-   }
-   else if (rx_cfg->fixed_message_length != 0)
-   {
+   } else if (rx_cfg->fixed_message_length != 0) {
payload_length = rx_cfg->fixed_message_length;
-   if (rx_cfg->enable_length_byte  == optionOn) payload_length++;
-   if (rx_cfg->enable_address_filtering != filteringOff) 
payload_length++;
+   if (rx_cfg->enable_length_byte  == optionOn)
+   payload_length++;
+   if (rx_cfg->enable_address_filtering != filteringOff)
+   payload_length++;
SET_CHECKED(rf69_set_payload_length(dev->spi, payload_length));
-   }
-   else
-   {
+   } else {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0));
}
 
/* values */
-   if (rx_cfg->enable_sync == optionOn)
-   {
+   if (rx_cfg->enable_sync == optionOn) {
SET_CHECKED(rf69_set_sync_values(dev->spi, 
rx_cfg->sync_pattern));
}
-   if (rx_cfg->enable_address_filtering != filteringOff)
-   {
+   if (rx_cfg->enable_address_filtering != filteringOff) {
SET_CHECKED(rf69_set_node_address (dev->spi, 
rx_cfg->node_address));
SET_CHECKED(rf69_set_broadcast_address(dev->spi, 
rx_cfg->broadcast_address));
}
@@ -258,12 +244,9 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
pi433_tx_cfg *tx_cfg)

[PATCH v2 2/2] MAINTAINERS: update email address for mcgrof for few straggling drivers

2017-08-07 Thread Luis R. Rodriguez 
This will ensure I get emails on my work and personal email address.

Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3deaddc8c578..997b8062397a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2212,7 +2212,7 @@ F:drivers/gpio/gpio-ath79.c
 F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
 
 ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 S: Supported
 F: drivers/net/wireless/ath/*
@@ -2220,7 +2220,7 @@ F:drivers/net/wireless/ath/*
 ATHEROS ATH5K WIRELESS DRIVER
 M: Jiri Slaby 
 M: Nick Kossifidis 
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/ath5k
 S: Maintained
-- 
2.11.0

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

[PATCH v2 1/2] wireless: move prism54 out to staging

2017-08-07 Thread Luis R. Rodriguez 
prism54 is deprecated in favor of the p54pci device driver. Although
only *one soul* had reported issues with it long ago Linux most Linux
distributions these days just disable the device driver given the
conflicts with the PCI IDs of p54pci and the *very* unlikely situation
of folks really need this driver anymore.

Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.

Acked-by: Kalle Valo 
Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS  |  4 ++--
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 10 insertions(+), 23 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 672b5d5402f0..3deaddc8c578 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10674,11 +10674,11 @@ F:kernel/printk/
 F: include/linux/printk.h
 
 PRISM54 WIRELESS DRIVER
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S: Obsolete
-F: drivers/net/wireless/intersil/prism54/
+F: drivers/staging/prism54/
 
 PROC SYSCTL
 M: "Luis R. Rodriguez" 
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index 9da136049955..2b056b6daef8 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -15,24 +15,4 @@ source "drivers/net/wireless/intersil/hostap/Kconfig"
 source "drivers/net/wireless/intersil/orinoco/Kconfig"
 source "drivers/net/wireless/intersil/p54/Kconfig"
 
-config PRISM54
-   tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
-   depends on PCI
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select FW_LOADER
-   ---help---
- This enables support for FullMAC PCI/Cardbus prism54 devices. This
- driver is now deprecated in favor for the SoftMAC driver, p54pci.
- p54pci supports FullMAC PCI/Cardbus devices as well.
-
- For more information refer to the p54 wiki:
-
- http://wireless.kernel.org/en/users/Drivers/p54
-
- Note: You need a motherboard with DMA support to use any of these 
cards
-
- When built as module you get the module prism54
-
 endif # WLAN_VENDOR_INTERSIL
diff --git a/drivers/net/wireless/intersil/Makefile

[PATCH v2 0/2] prism54: move to staging

2017-08-07 Thread Luis R. Rodriguez 
Greg,

This v2 adds the TODO you requested to clarify prism54 will be removed in
two kernel releases from now, and so no further cleanup is needed other
than to ensure the driver compiles.

This is based on linux-next tag next-20170807.

  Luis

Luis R. Rodriguez (2):
  wireless: move prism54 out to staging
  MAINTAINERS: update email address for mcgrof for few straggling
drivers

  Luis

 MAINTAINERS  |  8 
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 12 insertions(+), 25 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

-- 
2.11.0

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

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

2017-08-07 Thread Han Xu 


On 08/04/2017 10:29 AM, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later create a nand.h header
> containing all common structure and function prototypes.
>
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Peter Pan 
> Cc: Jonathan Corbet 
> Cc: Sekhar Nori 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: Gregory Clement 
> Cc: Hartley Sweeten 
> Cc: Alexander Sverdlin 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Imre Kaloz 
> Cc: Krzysztof Halasa 
> Cc: Eric Miao 
> Cc: Haojian Zhuang 
> Cc: Aaro Koskinen 
> Cc: Tony Lindgren 
> Cc: Alexander Clouter 
> Cc: Daniel Mack 
> Cc: Robert Jarzmik 
> Cc: Marek Vasut 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Simtec Linux Team 
> Cc: Steven Miao 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: Ralf Baechle 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: Wenyou Yang 
> Cc: Josh Wu 
> Cc: Kamal Dasu 
> Cc: Masahiro Yamada 
> Cc: Han Xu 
> Cc: Harvey Hunt 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Matthias Brugger 
> Cc: Wan ZongShun 
> Cc: Neil Armstrong 
> Cc: Ezequiel Garcia 
> Cc: Maxim Levitsky 
> Cc: Marc Gonzalez 
> Cc: Stefan Agner 
> Cc: Greg Kroah-Hartman 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: adi-buildroot-de...@lists.sourceforge.net
> Cc: linux-cris-ker...@axis.com
> Cc: linux-m...@linux-mips.org
> Cc: linux...@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-media...@lists.infradead.org
> Cc: linux-ox...@lists.tuxfamily.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: de...@driverdev.osuosl.org
> ---
> Hi All,
>
> Sorry for the huge Cc list, but I'd like to collect as much acks as
> possible for this patch which is actually part of a bigger series [1].
>
> Note that there's nothing complicated here, it's just a mechanical
> s/nand\.h/rawnand\.h/ replacement, but it impacts several architectures,
> the doc and staging directories.
>
> Regards,
>
> Boris
>
> [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F723694%2F=01%7C01%7Chan.xu%40nxp.com%7C56dfaec7f33e4893722f08d4db4d9424%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=51dsjHWusyD4BgqrKKbC%2BrcUG6zZRwh%2Bk4ANU6Y9w%2F0%3D=0
> ---
>   Documentation/driver-api/mtdnand.rst| 8 
>   MAINTAINERS | 2 +-
>   arch/arm/mach-davinci/board-da850-evm.c | 2 +-
>   arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
>   arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
>   arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
>   arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
>   arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
>   arch/arm/mach-davinci/board-sffsdr.c| 2 +-
>   arch/arm/mach-dove/dove-db-setup.c  | 2 +-
>   arch/arm/mach-ep93xx/snappercl15.c  | 2 +-
>   arch/arm/mach-ep93xx/ts72xx.c   | 2 +-
>   arch/arm/mach-imx/mach-qong.c   | 2 +-
>   arch/arm/mach-ixp4xx/ixdp425-setup.c| 2 +-
>   arch/arm/mach-mmp/aspenite.c| 2 +-
>   arch/arm/mach-omap1/board-fsample.c | 2 +-
>   arch/arm/mach-omap1/board-h2.c  | 2 +-
>   arch/arm/mach-omap1/board-h3.c  | 2 +-
>   arch/arm/mach-omap1/board-nand.c| 2 +-
>   arch/arm/mach-omap1/board-perseus2.c| 2 +-
>   arch/arm/mach-orion5x/db88f5281-setup.c | 2 +-
>

RE: [PATCH] mtd: nand: Rename nand.h into rawnand.h

2017-08-07 Thread Hartley Sweeten 
On Friday, August 04, 2017 8:29 AM, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later create a nand.h header
> containing all common structure and function prototypes.

For ep93xx,

Acked-by: H Hartley Sweeten 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

2017-08-07 Thread Harvey Hunt 

Hi Boris,

On 08/04/2017 04:29 PM, Boris Brezillon wrote:
[...]

  drivers/mtd/nand/jz4780_nand.c  | 2 +-

[...]

For JZ4780,

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

Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property

2017-08-07 Thread Hans de Goede 

Hi,

On 07-08-17 17:41, Mark Brown wrote:

On Mon, Aug 07, 2017 at 04:41:18PM +0200, Hans de Goede wrote:

On 07-08-17 13:10, Mark Brown wrote:



Problem 1)



The regulator in question is part of the bq24292i charger-IC attached to
a private i2c bus between the PMIC and the charger. The driver for the i2c
controller inside the PMIC which drivers this bus currently also instantiates
the i2c-client for the charger:


...


Note that the bq24190 driver is a generic driver, so to pass the
board specific regulator_init_data to it I would need to somehow
pass it here, but I don't see how, except by storing a pointer to
it in an u64 device-property which seems like a bad idea


I2C has a perfectly good platform_data pointer in the board info for
this stuff.


True, so you are suggesting that I define a bq24190_platform_data
struct with a regulator_init_data pointer in there I guess?

At least I would not want to just claim that pointer for
just regulator_init_data and more-over assuming that what
is in there will be regulator_init_data feels wrong.

I don't think the power-supply maintainers will be enthusiastic
about this (hi Sebastian). But that does make sense and is
actually a good idea for tackling the problem of regulator_init_data.


Problem 2)



Even if I could add the mapping through regulator_init_data
then it may well be too late, if the regulator_get happens
before the bq24190 driver registers its regulator (and thus
the mapping) the regulator_get for it may have already
happened and returned a dummy-regulator, or another regulator
with the rather generic vbus name.


If you don't have control over the instantiation ordering


It is not just device-instantiation ordering, it is also driver
loading order, the event around which ordering needs to happen is
the registration of the regulator (as things are now).


but you have a firmware which claims to provide a complete description of 
regulators
then you'd need to add an interface that allows mappings to be
registered separately to regulator registration.


So the pwm subsys has this pwm_add_table thing which can add lookup
entries indepdentent of pwm_registration and which uses supply/device_name
matching to find the entry for the caller of pwm_get which is the same as
the current lookup code in the regulator-core, but since it is
independent of the registration the lookup-table does not contain
direct pointers to pwmchip-s instead it uses a string which gets
matches against the pwm (parent) dev's dev_name().

Would extending the struct regulator_map with a const char *provider_name:

struct regulator_map {
struct list_head list;
const char *dev_name;   /* The dev_name() for the consumer */
const char *supply;
struct regulator_dev *regulator;
const char *provider;   /* The dev_name() for the regulator parent-dev 
*/
};

And having a regulator_add_lookup function which adds an entry to the
regulator_map_list which sets provider_name instead of regulator
be acceptable ?

lookup of such entries would look for regulators where supply
matches the regulator-name and provider matches the
regulators parent-dev-name.

Alternatively the entry could additionally contain a provider_supply_name
so that we can make arbitrary consumer-dev-name + consumer-supply-name
provider-dev-name + provider-supply-name matches. That would probably
be more flexible then requiring the supply name to match.

So would something like this (including returning -EPROBE_DEFER if there
is a pwm_map_list entry and no matching regulator can be found) acceptable ?


Whatever you're doing the answer isn't to try to specify the name of the
supply through some firmware binding, that's just obviously not sensible
both in terms of a firmware abstraction and in terms of how the
abstractions in Linux work.


Ok.

Regards,

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

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

2017-08-07 Thread Krzysztof Kozlowski 
On Fri, Aug 04, 2017 at 05:29:10PM +0200, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later create a nand.h header
> containing all common structure and function prototypes.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Peter Pan 
> Cc: Jonathan Corbet 
> Cc: Sekhar Nori 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: Gregory Clement 
> Cc: Hartley Sweeten 
> Cc: Alexander Sverdlin 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Imre Kaloz 
> Cc: Krzysztof Halasa 
> Cc: Eric Miao 
> Cc: Haojian Zhuang 
> Cc: Aaro Koskinen 
> Cc: Tony Lindgren 
> Cc: Alexander Clouter 
> Cc: Daniel Mack 
> Cc: Robert Jarzmik 
> Cc: Marek Vasut 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Simtec Linux Team 
> Cc: Steven Miao 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: Ralf Baechle 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: Wenyou Yang 
> Cc: Josh Wu 
> Cc: Kamal Dasu 
> Cc: Masahiro Yamada 
> Cc: Han Xu 
> Cc: Harvey Hunt 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Matthias Brugger 
> Cc: Wan ZongShun 
> Cc: Neil Armstrong 
> Cc: Ezequiel Garcia 
> Cc: Maxim Levitsky 
> Cc: Marc Gonzalez 
> Cc: Stefan Agner 
> Cc: Greg Kroah-Hartman 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: adi-buildroot-de...@lists.sourceforge.net
> Cc: linux-cris-ker...@axis.com
> Cc: linux-m...@linux-mips.org
> Cc: linux...@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-media...@lists.infradead.org
> Cc: linux-ox...@lists.tuxfamily.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: de...@driverdev.osuosl.org
> ---
> Hi All,
> 
> Sorry for the huge Cc list, but I'd like to collect as much acks as
> possible for this patch which is actually part of a bigger series [1].
> 
> Note that there's nothing complicated here, it's just a mechanical
> s/nand\.h/rawnand\.h/ replacement, but it impacts several architectures,
> the doc and staging directories.
> 
> Regards,
> 
> Boris
> 
> [1]https://lwn.net/Articles/723694/
> ---
>  Documentation/driver-api/mtdnand.rst| 8 
>  MAINTAINERS | 2 +-
>  arch/arm/mach-davinci/board-da850-evm.c | 2 +-
>  arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
>  arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
>  arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
>  arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
>  arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
>  arch/arm/mach-davinci/board-sffsdr.c| 2 +-
>  arch/arm/mach-dove/dove-db-setup.c  | 2 +-
>  arch/arm/mach-ep93xx/snappercl15.c  | 2 +-
>  arch/arm/mach-ep93xx/ts72xx.c   | 2 +-
>  arch/arm/mach-imx/mach-qong.c   | 2 +-
>  arch/arm/mach-ixp4xx/ixdp425-setup.c| 2 +-
>  arch/arm/mach-mmp/aspenite.c| 2 +-
>  arch/arm/mach-omap1/board-fsample.c | 2 +-
>  arch/arm/mach-omap1/board-h2.c  | 2 +-
>  arch/arm/mach-omap1/board-h3.c  | 2 +-
>  arch/arm/mach-omap1/board-nand.c| 2 +-
>  arch/arm/mach-omap1/board-perseus2.c| 2 +-
>  arch/arm/mach-orion5x/db88f5281-setup.c | 2 +-
>  arch/arm/mach-orion5x/kurobox_pro-setup.c   | 2 +-
>  arch/arm/mach-orion5x/ts209-setup.c | 2 +-
>  arch/arm/mach-orion5x/ts78xx-setup.c| 2 +-
>  arch/arm/mach-pxa/balloon3.c| 2 +-
>

[PATCH net-next 0/1] netvsc: another VF datapath fix

2017-08-07 Thread Stephen Hemminger 
Previous fix was incomplete.

Stephen Hemminger (1):
  netvsc: make sure and unregister datapath

 drivers/net/hyperv/hyperv_net.h |  3 --
 drivers/net/hyperv/netvsc.c |  2 --
 drivers/net/hyperv/netvsc_drv.c | 71 -
 3 files changed, 28 insertions(+), 48 deletions(-)

-- 
2.11.0

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

[PATCH net-next 1/1] netvsc: make sure and unregister datapath

2017-08-07 Thread Stephen Hemminger 
Go back to switching datapath directly in the notifier callback.
Otherwise datapath might not get switched on unregister.

No need for calling the NOTIFY_PEERS notifier since that is only for
a gratitious ARP/ND packet; but that is not required with Hyper-V
because both VF and synthetic NIC have the same MAC address.

Reported-by: Vitaly Kuznetsov 
Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
Signed-off-by: Stephen Hemminger 
---
 drivers/net/hyperv/hyperv_net.h |  3 --
 drivers/net/hyperv/netvsc.c |  2 --
 drivers/net/hyperv/netvsc_drv.c | 71 -
 3 files changed, 28 insertions(+), 48 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index c701b059c5ac..d1ea99a12cf2 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -724,14 +724,11 @@ struct net_device_context {
struct net_device __rcu *vf_netdev;
struct netvsc_vf_pcpu_stats __percpu *vf_stats;
struct work_struct vf_takeover;
-   struct work_struct vf_notify;
 
/* 1: allocated, serial number is valid. 0: not allocated */
u32 vf_alloc;
/* Serial number of the VF to team with */
u32 vf_serial;
-
-   bool datapath;  /* 0 - synthetic, 1 - VF nic */
 };
 
 /* Per channel data */
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 9598220b3bcc..208f03aa83de 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -60,8 +60,6 @@ void netvsc_switch_datapath(struct net_device *ndev, bool vf)
   sizeof(struct nvsp_message),
   (unsigned long)init_pkt,
   VM_PKT_DATA_INBAND, 0);
-
-   net_device_ctx->datapath = vf;
 }
 
 static struct netvsc_device *alloc_net_device(void)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index e75c0f852a63..eb0023f55fe1 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1649,55 +1649,35 @@ static int netvsc_register_vf(struct net_device 
*vf_netdev)
return NOTIFY_OK;
 }
 
-/* Change datapath */
-static void netvsc_vf_update(struct work_struct *w)
+static int netvsc_vf_up(struct net_device *vf_netdev)
 {
-   struct net_device_context *ndev_ctx
-   = container_of(w, struct net_device_context, vf_notify);
-   struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
+   struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
-   struct net_device *vf_netdev;
-   bool vf_is_up;
-
-   if (!rtnl_trylock()) {
-   schedule_work(w);
-   return;
-   }
+   struct net_device *ndev;
 
-   vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
-   if (!vf_netdev)
-   goto unlock;
+   ndev = get_netvsc_byref(vf_netdev);
+   if (!ndev)
+   return NOTIFY_DONE;
 
-   netvsc_dev = rtnl_dereference(ndev_ctx->nvdev);
+   net_device_ctx = netdev_priv(ndev);
+   netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev)
-   goto unlock;
-
-   vf_is_up = netif_running(vf_netdev);
-   if (vf_is_up != ndev_ctx->datapath) {
-   if (vf_is_up) {
-   netdev_info(ndev, "VF up: %s\n", vf_netdev->name);
-   rndis_filter_open(netvsc_dev);
-   netvsc_switch_datapath(ndev, true);
-   netdev_info(ndev, "Data path switched to VF: %s\n",
-   vf_netdev->name);
-   } else {
-   netdev_info(ndev, "VF down: %s\n", vf_netdev->name);
-   netvsc_switch_datapath(ndev, false);
-   rndis_filter_close(netvsc_dev);
-   netdev_info(ndev, "Data path switched from VF: %s\n",
-   vf_netdev->name);
-   }
+   return NOTIFY_DONE;
 
-   /* Now notify peers through VF device. */
-   call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, ndev);
-   }
-unlock:
-   rtnl_unlock();
+   /* Bump refcount when datapath is acvive - Why? */
+   rndis_filter_open(netvsc_dev);
+
+   /* notify the host to switch the data path. */
+   netvsc_switch_datapath(ndev, true);
+   netdev_info(ndev, "Data path switched to VF: %s\n", vf_netdev->name);
+
+   return NOTIFY_OK;
 }
 
-static int netvsc_vf_notify(struct net_device *vf_netdev)
+static int netvsc_vf_down(struct net_device *vf_netdev)
 {
struct net_device_context *net_device_ctx;
+   struct netvsc_device *netvsc_dev;
struct net_device *ndev;
 
ndev = get_netvsc_byref(vf_netdev);
@@ -1705,7 +1685,13 @@ static int netvsc_vf_notify(struct net_device *vf_netdev)
return

Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property

2017-08-07 Thread Mark Brown 
On Mon, Aug 07, 2017 at 04:41:18PM +0200, Hans de Goede wrote:
> On 07-08-17 13:10, Mark Brown wrote:

> Problem 1)

> The regulator in question is part of the bq24292i charger-IC attached to
> a private i2c bus between the PMIC and the charger. The driver for the i2c
> controller inside the PMIC which drivers this bus currently also instantiates
> the i2c-client for the charger:

...

> Note that the bq24190 driver is a generic driver, so to pass the
> board specific regulator_init_data to it I would need to somehow
> pass it here, but I don't see how, except by storing a pointer to
> it in an u64 device-property which seems like a bad idea

I2C has a perfectly good platform_data pointer in the board info for
this stuff.

> Problem 2)

> Even if I could add the mapping through regulator_init_data
> then it may well be too late, if the regulator_get happens
> before the bq24190 driver registers its regulator (and thus
> the mapping) the regulator_get for it may have already
> happened and returned a dummy-regulator, or another regulator
> with the rather generic vbus name.

If you don't have control over the instantiation ordering but you have a
firmware which claims to provide a complete description of regulators
then you'd need to add an interface that allows mappings to be
registered separately to regulator registration.

Whatever you're doing the answer isn't to try to specify the name of the
supply through some firmware binding, that's just obviously not sensible
both in terms of a firmware abstraction and in terms of how the
abstractions in Linux work.


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

Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf

2017-08-07 Thread Stephen Hemminger 
On Mon, 07 Aug 2017 17:17:19 +0200
Vitaly Kuznetsov  wrote:

> Vitaly Kuznetsov  writes:
> 
> > Vitaly Kuznetsov  writes:
> >  
> >> Stephen Hemminger  writes:
> >>  
> >>> With new transparent VF support, it is possible to get a deadlock
> >>> when some of the deferred work is running and the unregister_vf
> >>> is trying to cancel the work element. The solution is to use
> >>> trylock and reschedule (similar to bonding and team device).
> >>>
> >>> Reported-by: Vitaly Kuznetsov 
> >>> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
> >>> Signed-off-by: Stephen Hemminger 
> >>> ---
> >>>  drivers/net/hyperv/netvsc_drv.c | 12 ++--
> >>>  1 file changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/net/hyperv/netvsc_drv.c 
> >>> b/drivers/net/hyperv/netvsc_drv.c
> >>> index c71728d82049..e75c0f852a63 100644
> >>> --- a/drivers/net/hyperv/netvsc_drv.c
> >>> +++ b/drivers/net/hyperv/netvsc_drv.c
> >>> @@ -1601,7 +1601,11 @@ static void netvsc_vf_setup(struct work_struct *w)
> >>>   struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
> >>>   struct net_device *vf_netdev;
> >>>
> >>> - rtnl_lock();
> >>> + if (!rtnl_trylock()) {
> >>> + schedule_work(w);
> >>> + return;
> >>> + }
> >>> +
> >>>   vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
> >>>   if (vf_netdev)
> >>>   __netvsc_vf_setup(ndev, vf_netdev);
> >>> @@ -1655,7 +1659,11 @@ static void netvsc_vf_update(struct work_struct *w)
> >>>   struct net_device *vf_netdev;
> >>>   bool vf_is_up;
> >>>
> >>> - rtnl_lock();
> >>> + if (!rtnl_trylock()) {
> >>> + schedule_work(w);
> >>> + return;
> >>> + }
> >>> +  
> >>
> >> So in the situation when we're currently in netvsc_unregister_vf() and
> >> trying to do
> >> cancel_work_sync(_device_ctx->vf_takeover);
> >>cancel_work_sync(_device_ctx->vf_notify);
> >>
> >> we'll end up not executing netvsc_vf_update() at all, right? Wouldn't it
> >> create an issue as nobody is switching the datapath back to netvsc?
> >>  
> >
> > Actually, looking more at this I think we have additional issues:
> >
> > netvsc_unregister_vf() may get executed _before_ netvsc_vf_update() gets
> > a chance and we just cancel it so the data path is never switched
> > back. I actually have a VM where I suppose it happens ...
> >
> > [7.235566] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF up: 
> > enP2p0s2
> > [7.235569] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: 
> > Datapath switched to VF: enP2p0s2
> >
> > On VF removal:
> >
> > [   17.675885] mlx4_en: enP2p0s2: Close port called
> > [   17.727005] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF 
> > unregistering: enP2p0s2
> > 
> >
> > We need to make sure netvsc_vf_update() is always processed on removal.  
> 
> So the question I have is: why do we need to call netvsc_vf_update()
> from a work? I tried calling it directly from netvsc_netdev_event() (and
> with rtnl_lock()/unlock() calls dropped from it as we already have it,
> of course) and everything seems to work for me.

Switching datapath needs to be waiting for ack and isn't

> 
> Shall I send a patch removing the work?

I will take care of that.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf

2017-08-07 Thread Stephen Hemminger 
On Mon, 07 Aug 2017 15:37:49 +0200
Vitaly Kuznetsov  wrote:

> Vitaly Kuznetsov  writes:
> 
> > Stephen Hemminger  writes:
> >  
> >> With new transparent VF support, it is possible to get a deadlock
> >> when some of the deferred work is running and the unregister_vf
> >> is trying to cancel the work element. The solution is to use
> >> trylock and reschedule (similar to bonding and team device).
> >>
> >> Reported-by: Vitaly Kuznetsov 
> >> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
> >> Signed-off-by: Stephen Hemminger 
> >> ---
> >>  drivers/net/hyperv/netvsc_drv.c | 12 ++--
> >>  1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/hyperv/netvsc_drv.c 
> >> b/drivers/net/hyperv/netvsc_drv.c
> >> index c71728d82049..e75c0f852a63 100644
> >> --- a/drivers/net/hyperv/netvsc_drv.c
> >> +++ b/drivers/net/hyperv/netvsc_drv.c
> >> @@ -1601,7 +1601,11 @@ static void netvsc_vf_setup(struct work_struct *w)
> >>struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
> >>struct net_device *vf_netdev;
> >>
> >> -  rtnl_lock();
> >> +  if (!rtnl_trylock()) {
> >> +  schedule_work(w);
> >> +  return;
> >> +  }
> >> +
> >>vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
> >>if (vf_netdev)
> >>__netvsc_vf_setup(ndev, vf_netdev);
> >> @@ -1655,7 +1659,11 @@ static void netvsc_vf_update(struct work_struct *w)
> >>struct net_device *vf_netdev;
> >>bool vf_is_up;
> >>
> >> -  rtnl_lock();
> >> +  if (!rtnl_trylock()) {
> >> +  schedule_work(w);
> >> +  return;
> >> +  }
> >> +  
> >
> > So in the situation when we're currently in netvsc_unregister_vf() and
> > trying to do
> > cancel_work_sync(_device_ctx->vf_takeover);
> > cancel_work_sync(_device_ctx->vf_notify);
> >
> > we'll end up not executing netvsc_vf_update() at all, right? Wouldn't it
> > create an issue as nobody is switching the datapath back to netvsc?

It worked testing, but most likely only because host is doing it for us.
Not a good thing to rely on.

> 
> Actually, looking more at this I think we have additional issues:
> 
> netvsc_unregister_vf() may get executed _before_ netvsc_vf_update() gets
> a chance and we just cancel it so the data path is never switched
> back. I actually have a VM where I suppose it happens ...
> 
> [7.235566] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF up: 
> enP2p0s2
> [7.235569] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: Datapath 
> switched to VF: enP2p0s2
> 
> On VF removal:
> 
> [   17.675885] mlx4_en: enP2p0s2: Close port called
> [   17.727005] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF 
> unregistering: enP2p0s2
> 
> 
> We need to make sure netvsc_vf_update() is always processed on removal.

The reason vf_update was converted to work queue was because there were some
case the old code could sleep. Probably best to go back to doing it directly
in notifier and handle the special cases.




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

Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf

2017-08-07 Thread Vitaly Kuznetsov 
Vitaly Kuznetsov  writes:

> Vitaly Kuznetsov  writes:
>
>> Stephen Hemminger  writes:
>>
>>> With new transparent VF support, it is possible to get a deadlock
>>> when some of the deferred work is running and the unregister_vf
>>> is trying to cancel the work element. The solution is to use
>>> trylock and reschedule (similar to bonding and team device).
>>>
>>> Reported-by: Vitaly Kuznetsov 
>>> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
>>> Signed-off-by: Stephen Hemminger 
>>> ---
>>>  drivers/net/hyperv/netvsc_drv.c | 12 ++--
>>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/hyperv/netvsc_drv.c 
>>> b/drivers/net/hyperv/netvsc_drv.c
>>> index c71728d82049..e75c0f852a63 100644
>>> --- a/drivers/net/hyperv/netvsc_drv.c
>>> +++ b/drivers/net/hyperv/netvsc_drv.c
>>> @@ -1601,7 +1601,11 @@ static void netvsc_vf_setup(struct work_struct *w)
>>> struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
>>> struct net_device *vf_netdev;
>>>
>>> -   rtnl_lock();
>>> +   if (!rtnl_trylock()) {
>>> +   schedule_work(w);
>>> +   return;
>>> +   }
>>> +
>>> vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
>>> if (vf_netdev)
>>> __netvsc_vf_setup(ndev, vf_netdev);
>>> @@ -1655,7 +1659,11 @@ static void netvsc_vf_update(struct work_struct *w)
>>> struct net_device *vf_netdev;
>>> bool vf_is_up;
>>>
>>> -   rtnl_lock();
>>> +   if (!rtnl_trylock()) {
>>> +   schedule_work(w);
>>> +   return;
>>> +   }
>>> +
>>
>> So in the situation when we're currently in netvsc_unregister_vf() and
>> trying to do
>> cancel_work_sync(_device_ctx->vf_takeover);
>>  cancel_work_sync(_device_ctx->vf_notify);
>>
>> we'll end up not executing netvsc_vf_update() at all, right? Wouldn't it
>> create an issue as nobody is switching the datapath back to netvsc?
>>
>
> Actually, looking more at this I think we have additional issues:
>
> netvsc_unregister_vf() may get executed _before_ netvsc_vf_update() gets
> a chance and we just cancel it so the data path is never switched
> back. I actually have a VM where I suppose it happens ...
>
> [7.235566] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF up: 
> enP2p0s2
> [7.235569] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: Datapath 
> switched to VF: enP2p0s2
>
> On VF removal:
>
> [   17.675885] mlx4_en: enP2p0s2: Close port called
> [   17.727005] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF 
> unregistering: enP2p0s2
> 
>
> We need to make sure netvsc_vf_update() is always processed on removal.

So the question I have is: why do we need to call netvsc_vf_update()
from a work? I tried calling it directly from netvsc_netdev_event() (and
with rtnl_lock()/unlock() calls dropped from it as we already have it,
of course) and everything seems to work for me.

Shall I send a patch removing the work?

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

Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property

2017-08-07 Thread Hans de Goede 

Hi Mark,

On 07-08-17 13:10, Mark Brown wrote:

On Sun, Aug 06, 2017 at 05:44:36PM +0200, Hans de Goede wrote:

On 06-08-17 16:30, Guenter Roeck wrote:

On 08/06/2017 05:35 AM, Hans de Goede wrote:



On ACPI platforms, there are no phandles and we need to get the vbus by a
system wide unique name. Add support for a new "fcs,vbus-regulator-name"
device-property which ACPI platform code can set to pass the name.



Another property to be documented and approved.



Again this is for kernel internal use on non-dt platforms only, so documenting
it in the devicetree bindings is not necessary.


However it *is* for use on ACPI platforms and is impacting power
management (which is something ACPI definitely models) so should be
being documented in an ASWG spec.  We don't want Linux systems to start
breaking the ACPI power management model with uncontrolled extensions,
it's fine to add new bindings for things where there's just no ACPI
specification at all but power management isn't one of those areas.


This regulator is used to enable/disable driving vbus on the Type-C connector
from a 5V boost converter or not depending on the power direction (sink
or source) negotiated by the Type-C port-controller. As such this is never
under firmware/ACPI control it always gets controlled by the Type-C
port-manager, so there is no need for ACPI to control it. The problem is
that the Type-C setup on these boards consist of a bunch of ICs chained
together / driving different pins of the Type-C connector. So we need to
somehow tell the bq24292i charger-IC to turn on/off its 5V boost converter
from the Type-C port-controller driver. This discussion (and this patch)
is about getting a handle to the regulator-device for the 5V boost converter
from the Type-C port-controller driver.

For added fun the bq24292i charger-IC is not described in ACPI at all,
but we know that the Whiskey Cove PMIC used is always paired with it.

The fusb302 Type-c port-controller itself is enumerated to the weird
INT33FE ACPI device node (which describes 3 different i2c ICs, including
the fusb302)


TL;DR: It seems that on x86, at least for existing devices where we cannot
control the ACPI tables that getting things by name is the thing to do.


The idiomatic thing to do on an ACPI system at present appears to be to
have a big DMI quirk table somewhere that instantiates the regulators
and mappings required for them based on the machine's DMI data.  Or if
it's a self contained PCI device or something with both regulator and
consumer do it as part of the subfunction instantiation there.


Thanks for your input. I've taken a look at the possibility to specify
a mapping via regualtor_init_data, rather then falling back to finding the
regulator by name. I've found 2 problems with this:

Problem 1)

The regulator in question is part of the bq24292i charger-IC attached to
a private i2c bus between the PMIC and the charger. The driver for the i2c
controller inside the PMIC which drivers this bus currently also instantiates
the i2c-client for the charger:

drivers/i2c/busses/i2c-cht-wc.c:

static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };

static const struct property_entry bq24190_props[] = {
PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),
PROPERTY_ENTRY_BOOL("input-current-limit-from-supplier"),
PROPERTY_ENTRY_BOOL("omit-battery-class"),
PROPERTY_ENTRY_BOOL("disable-reset"),
{ }
};

static int cht_wc_i2c_adap_i2c_probe(struct platform_device *pdev)
{
struct i2c_board_info board_info = {
.type = "bq24190",
.addr = 0x6b,
.properties = bq24190_props,
};
...
adap->client_irq = irq_create_mapping(adap->irq_domain, 0);
ret = i2c_add_adapter(>adapter);

board_info.irq = adap->client_irq;
adap->client = i2c_new_device(>adapter, _info);
...
}

Note that the bq24190 driver is a generic driver, so to pass the
board specific regulator_init_data to it I would need to somehow
pass it here, but I don't see how, except by storing a pointer to
it in an u64 device-property which seems like a bad idea


Problem 2)

Even if I could add the mapping through regulator_init_data
then it may well be too late, if the regulator_get happens
before the bq24190 driver registers its regulator (and thus
the mapping) the regulator_get for it may have already
happened and returned a dummy-regulator, or another regulator
with the rather generic vbus name.


TL;DR: It is a mess and I cannot come up with anything better then
just using a globally-unique name, suggestions for a better
solution are welcome.

Regards,

Hans


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

[PATCH] staging: media: atomisp: use kvmalloc/kvzalloc

2017-08-07 Thread Geliang Tang 
Use kvmalloc()/kvzalloc() instead of atomisp_kernel_malloc()
/atomisp_kernel_zalloc().

Signed-off-by: Geliang Tang 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 31 +-
 .../media/atomisp/pci/atomisp2/atomisp_cmd.h   |  2 --
 .../atomisp/pci/atomisp2/atomisp_compat_css20.c|  4 +--
 .../media/atomisp/pci/atomisp2/atomisp_internal.h  |  2 --
 4 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 7bf5dcd..f48bf45 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -83,35 +83,6 @@ union host {
 };
 
 /*
- * atomisp_kernel_malloc: chooses whether kmalloc() or vmalloc() is preferable.
- *
- * It is also a wrap functions to pass into css framework.
- */
-void *atomisp_kernel_malloc(size_t bytes)
-{
-   /* vmalloc() is preferable if allocating more than 1 page */
-   if (bytes > PAGE_SIZE)
-   return vmalloc(bytes);
-
-   return kmalloc(bytes, GFP_KERNEL);
-}
-
-/*
- * atomisp_kernel_zalloc: chooses whether set 0 to the allocated memory.
- *
- * It is also a wrap functions to pass into css framework.
- */
-void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
-{
-   void *ptr = atomisp_kernel_malloc(bytes);
-
-   if (ptr && zero_mem)
-   memset(ptr, 0, bytes);
-
-   return ptr;
-}
-
-/*
  * get sensor:dis71430/ov2720 related info from v4l2_subdev->priv data field.
  * subdev->priv is set in mrst.c
  */
@@ -4316,7 +4287,7 @@ int atomisp_set_parameters(struct video_device *vdev,
 * are ready, the parameters will be set to CSS.
 * per-frame setting only works for the main output frame.
 */
-   param = atomisp_kernel_zalloc(sizeof(*param), true);
+   param = kvzalloc(sizeof(*param), GFP_KERNEL);
if (!param) {
dev_err(asd->isp->dev, "%s: failed to alloc params 
buffer\n",
__func__);
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.h
index 1ccd911..31ba4e6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.h
@@ -78,8 +78,6 @@ static inline void __iomem *atomisp_get_io_virt_addr(unsigned 
int address)
return ret;
 }
 */
-void *atomisp_kernel_malloc(size_t bytes);
-void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem);
 
 /*
  * Interrupt functions
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index 36f934d..05897b7 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -1671,9 +1671,9 @@ int atomisp_alloc_metadata_output_buf(struct 
atomisp_sub_device *asd)
/* We allocate the cpu-side buffer used for communication with user
 * space */
for (i = 0; i < ATOMISP_METADATA_TYPE_NUM; i++) {
-   asd->params.metadata_user[i] = atomisp_kernel_malloc(
+   asd->params.metadata_user[i] = kvmalloc(
asd->stream_env[ATOMISP_INPUT_STREAM_GENERAL].
-   stream_info.metadata_info.size);
+   stream_info.metadata_info.size, GFP_KERNEL);
if (!asd->params.metadata_user[i]) {
while (--i >= 0) {
kvfree(asd->params.metadata_user[i]);
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
index 4b03f28..7542a72f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
@@ -301,8 +301,6 @@ struct atomisp_device {
 
 extern struct device *atomisp_dev;
 
-extern void *atomisp_kernel_malloc(size_t bytes);
-
 #define atomisp_is_wdt_running(a) timer_pending(&(a)->wdt)
 #ifdef ISP2401
 extern void atomisp_wdt_refresh_pipe(struct atomisp_video_pipe *pipe,
-- 
2.9.3

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

Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf

2017-08-07 Thread Vitaly Kuznetsov 
Vitaly Kuznetsov  writes:

> Stephen Hemminger  writes:
>
>> With new transparent VF support, it is possible to get a deadlock
>> when some of the deferred work is running and the unregister_vf
>> is trying to cancel the work element. The solution is to use
>> trylock and reschedule (similar to bonding and team device).
>>
>> Reported-by: Vitaly Kuznetsov 
>> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
>> Signed-off-by: Stephen Hemminger 
>> ---
>>  drivers/net/hyperv/netvsc_drv.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hyperv/netvsc_drv.c 
>> b/drivers/net/hyperv/netvsc_drv.c
>> index c71728d82049..e75c0f852a63 100644
>> --- a/drivers/net/hyperv/netvsc_drv.c
>> +++ b/drivers/net/hyperv/netvsc_drv.c
>> @@ -1601,7 +1601,11 @@ static void netvsc_vf_setup(struct work_struct *w)
>>  struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
>>  struct net_device *vf_netdev;
>>
>> -rtnl_lock();
>> +if (!rtnl_trylock()) {
>> +schedule_work(w);
>> +return;
>> +}
>> +
>>  vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
>>  if (vf_netdev)
>>  __netvsc_vf_setup(ndev, vf_netdev);
>> @@ -1655,7 +1659,11 @@ static void netvsc_vf_update(struct work_struct *w)
>>  struct net_device *vf_netdev;
>>  bool vf_is_up;
>>
>> -rtnl_lock();
>> +if (!rtnl_trylock()) {
>> +schedule_work(w);
>> +return;
>> +}
>> +
>
> So in the situation when we're currently in netvsc_unregister_vf() and
> trying to do
> cancel_work_sync(_device_ctx->vf_takeover);
>   cancel_work_sync(_device_ctx->vf_notify);
>
> we'll end up not executing netvsc_vf_update() at all, right? Wouldn't it
> create an issue as nobody is switching the datapath back to netvsc?
>

Actually, looking more at this I think we have additional issues:

netvsc_unregister_vf() may get executed _before_ netvsc_vf_update() gets
a chance and we just cancel it so the data path is never switched
back. I actually have a VM where I suppose it happens ...

[7.235566] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF up: 
enP2p0s2
[7.235569] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: Datapath 
switched to VF: enP2p0s2

On VF removal:

[   17.675885] mlx4_en: enP2p0s2: Close port called
[   17.727005] hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF 
unregistering: enP2p0s2


We need to make sure netvsc_vf_update() is always processed on removal.

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

Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf

2017-08-07 Thread Vitaly Kuznetsov 
Stephen Hemminger  writes:

> With new transparent VF support, it is possible to get a deadlock
> when some of the deferred work is running and the unregister_vf
> is trying to cancel the work element. The solution is to use
> trylock and reschedule (similar to bonding and team device).
>
> Reported-by: Vitaly Kuznetsov 
> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/net/hyperv/netvsc_drv.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index c71728d82049..e75c0f852a63 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -1601,7 +1601,11 @@ static void netvsc_vf_setup(struct work_struct *w)
>   struct net_device *ndev = hv_get_drvdata(ndev_ctx->device_ctx);
>   struct net_device *vf_netdev;
>
> - rtnl_lock();
> + if (!rtnl_trylock()) {
> + schedule_work(w);
> + return;
> + }
> +
>   vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
>   if (vf_netdev)
>   __netvsc_vf_setup(ndev, vf_netdev);
> @@ -1655,7 +1659,11 @@ static void netvsc_vf_update(struct work_struct *w)
>   struct net_device *vf_netdev;
>   bool vf_is_up;
>
> - rtnl_lock();
> + if (!rtnl_trylock()) {
> + schedule_work(w);
> + return;
> + }
> +

So in the situation when we're currently in netvsc_unregister_vf() and
trying to do
cancel_work_sync(_device_ctx->vf_takeover);
cancel_work_sync(_device_ctx->vf_notify);

we'll end up not executing netvsc_vf_update() at all, right? Wouldn't it
create an issue as nobody is switching the datapath back to netvsc?

>   vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
>   if (!vf_netdev)
>   goto unlock;

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

Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property

2017-08-07 Thread Mark Brown 
On Sun, Aug 06, 2017 at 05:44:36PM +0200, Hans de Goede wrote:
> On 06-08-17 16:30, Guenter Roeck wrote:
> > On 08/06/2017 05:35 AM, Hans de Goede wrote:

> > > On ACPI platforms, there are no phandles and we need to get the vbus by a
> > > system wide unique name. Add support for a new "fcs,vbus-regulator-name"
> > > device-property which ACPI platform code can set to pass the name.

> > Another property to be documented and approved.

> Again this is for kernel internal use on non-dt platforms only, so documenting
> it in the devicetree bindings is not necessary.

However it *is* for use on ACPI platforms and is impacting power
management (which is something ACPI definitely models) so should be
being documented in an ASWG spec.  We don't want Linux systems to start
breaking the ACPI power management model with uncontrolled extensions,
it's fine to add new bindings for things where there's just no ACPI
specification at all but power management isn't one of those areas.

> TL;DR: It seems that on x86, at least for existing devices where we cannot
> control the ACPI tables that getting things by name is the thing to do.

The idiomatic thing to do on an ACPI system at present appears to be to
have a big DMI quirk table somewhere that instantiates the regulators
and mappings required for them based on the machine's DMI data.  Or if
it's a self contained PCI device or something with both regulator and
consumer do it as part of the subfunction instantiation there.


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

[PATCH] [media] staging: atomisp: imx: remove dead code

2017-08-07 Thread Arnd Bergmann 
Making some functions 'static' has uncovered a few functions that
have no caller, through the gcc warnings:

atomisp/i2c/imx/imx.c::12: error: 'imx_t_focus_vcm' defined but not used 
[-Werror=unused-function]
atomisp/i2c/imx/imx.c:1103:12: error: 'imx_vcm_init' defined but not used 
[-Werror=unused-function]
atomisp/i2c/imx/imx.c:1095:12: error: 'imx_vcm_power_down' defined but not used 
[-Werror=unused-function]
atomisp/i2c/imx/imx.c:1087:12: error: 'imx_vcm_power_up' defined but not used 
[-Werror=unused-function]

All four of these can be removed. Since they call indirect functions,
I also looked at how those are used in turn:

- The power_up/power_down callbacks are called from other functions
  and are still needed.

- The t_focus_vcm callbacks pointers are completely unused and can
  be removed in both imx and ov8858. Some of the handlers are called
  directly and can now be marked static, the others are dummy
  implemntations that we can remove.

- vcm_init is unused in imx, but dw9718_vcm_init is used in ov8858,
  but is not used in imx, so that one needs to stay around. The callback
  pointers in imx can be removed.

Fixes: 9a5a6911aa3f ("staging: imx: fix non-static declarations")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/atomisp/i2c/imx/ad5816g.c   | 11 +---
 drivers/staging/media/atomisp/i2c/imx/drv201.c| 11 +---
 drivers/staging/media/atomisp/i2c/imx/dw9714.c| 14 +-
 drivers/staging/media/atomisp/i2c/imx/dw9718.c|  5 
 drivers/staging/media/atomisp/i2c/imx/dw9719.c| 11 
 drivers/staging/media/atomisp/i2c/imx/imx.c   | 32 ---
 drivers/staging/media/atomisp/i2c/imx/imx.h   | 29 
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.c |  2 +-
 drivers/staging/media/atomisp/i2c/ov8858.h|  3 ---
 drivers/staging/media/atomisp/i2c/ov8858_btns.h   |  3 ---
 10 files changed, 4 insertions(+), 117 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/imx/ad5816g.c 
b/drivers/staging/media/atomisp/i2c/imx/ad5816g.c
index d68ebb49f002..558dcdf135d9 100644
--- a/drivers/staging/media/atomisp/i2c/imx/ad5816g.c
+++ b/drivers/staging/media/atomisp/i2c/imx/ad5816g.c
@@ -136,7 +136,7 @@ int ad5816g_vcm_power_down(struct v4l2_subdev *sd)
 }
 
 
-int ad5816g_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
+static int ad5816g_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
u16 data = val & VCM_CODE_MASK;
@@ -214,12 +214,3 @@ int ad5816g_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
 {
return 0;
 }
-
-int ad5816g_vcm_init(struct v4l2_subdev *sd)
-{
-   ad5816g_dev.platform_data = camera_get_af_platform_data();
-   return (NULL == ad5816g_dev.platform_data) ? -ENODEV : 0;
-
-}
-
-
diff --git a/drivers/staging/media/atomisp/i2c/imx/drv201.c 
b/drivers/staging/media/atomisp/i2c/imx/drv201.c
index 915e4019cfeb..6d9d4c968722 100644
--- a/drivers/staging/media/atomisp/i2c/imx/drv201.c
+++ b/drivers/staging/media/atomisp/i2c/imx/drv201.c
@@ -128,7 +128,7 @@ int drv201_vcm_power_down(struct v4l2_subdev *sd)
 }
 
 
-int drv201_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
+static int drv201_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
u16 data = val & VCM_CODE_MASK;
@@ -207,12 +207,3 @@ int drv201_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
 {
return 0;
 }
-
-int drv201_vcm_init(struct v4l2_subdev *sd)
-{
-   drv201_dev.platform_data = camera_get_af_platform_data();
-   return (NULL == drv201_dev.platform_data) ? -ENODEV : 0;
-}
-
-
-
diff --git a/drivers/staging/media/atomisp/i2c/imx/dw9714.c 
b/drivers/staging/media/atomisp/i2c/imx/dw9714.c
index b7dee1b6bb37..6397a7ee0af6 100644
--- a/drivers/staging/media/atomisp/i2c/imx/dw9714.c
+++ b/drivers/staging/media/atomisp/i2c/imx/dw9714.c
@@ -56,7 +56,7 @@ int dw9714_vcm_power_down(struct v4l2_subdev *sd)
 }
 
 
-int dw9714_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
+static int dw9714_t_focus_vcm(struct v4l2_subdev *sd, u16 val)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret = -EINVAL;
@@ -221,15 +221,3 @@ int dw9714_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
 
return 0;
 }
-
-int dw9714_vcm_init(struct v4l2_subdev *sd)
-{
-
-   /* set VCM to home position and vcm mode to direct*/
-   dw9714_dev.vcm_mode = DW9714_DIRECT;
-   dw9714_dev.vcm_settings.update = false;
-   dw9714_dev.platform_data = camera_get_af_platform_data();
-   return (NULL == dw9714_dev.platform_data) ? -ENODEV : 0;
-
-}
-
diff --git a/drivers/staging/media/atomisp/i2c/imx/dw9718.c 
b/drivers/staging/media/atomisp/i2c/imx/dw9718.c
index 65a1fcf187d5..c02b9f0a2440 100644
--- a/drivers/staging/media/atomisp/i2c/imx/dw9718.c
+++ b/drivers/staging/media/atomisp/i2c/imx/dw9718.c
@@ -204,11 +204,6 @@ int dw9718_q_focus_status(struct

[PATCH] [media] staging/imx: always select VIDEOBUF2_DMA_CONTIG

2017-08-07 Thread Arnd Bergmann 
I ran into a rare build error during randconfig testing:

drivers/staging/media/imx/imx-media-capture.o: In function 
`capture_stop_streaming':
imx-media-capture.c:(.text+0x224): undefined reference to `vb2_buffer_done'
drivers/staging/media/imx/imx-media-capture.o: In function 
`imx_media_capture_device_register':
imx-media-capture.c:(.text+0xe60): undefined reference to `vb2_queue_init'
imx-media-capture.c:(.text+0xfa0): undefined reference to 
`vb2_dma_contig_memops'

While VIDEOBUF2_DMA_CONTIG was already selected by the camera driver,
it wasn't necessarily there with just the base driver enabled.
This moves the 'select' statement to the top-level option to make
sure it's always available.

Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 719508fcb0e9..2be921cd0d55 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -2,6 +2,7 @@ config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
depends on MEDIA_CONTROLLER && VIDEO_V4L2 && ARCH_MXC && IMX_IPUV3_CORE
depends on VIDEO_V4L2_SUBDEV_API
+   select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
---help---
  Say yes here to enable support for video4linux media controller
@@ -13,7 +14,6 @@ menu "i.MX5/6 Media Sub devices"
 config VIDEO_IMX_CSI
tristate "i.MX5/6 Camera Sensor Interface driver"
depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
-   select VIDEOBUF2_DMA_CONTIG
default y
---help---
  A video4linux camera sensor interface driver for i.MX5/6.
-- 
2.9.0

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

[PATCH] staging: lustre: mgc: fix potential use after free in error path

2017-08-07 Thread Cihangir Akturk 
The config_log_add() function first calls config_log_put() with the
variable 'cld' and then jumps to label 'out_cld', which will call
the same function with the same 'cld' variable. However, at this
point, 'cld' might have been already freed by the first invocation
of config_log_put(). Even if we remove the invocation at that point,
we will still get into trouble. This is because, in the error path,
just below the label 'out_cld', we try to put 'params_cls' and
'sptlrpc_cld', which might also have been freed by config_log_put().

The point is that, config_llog_data::cld_sptlrpc and
config_llog_data::cld_params members are assigned at the beginning
of this function.

To avoid this, do not call config_log_put() inside the else block,
immediately jump to 'out_cld' instead. Moreover, remove assignments
to config_llog_data::cld_sptlrpc and config_llog_data::cld_params at
the beginning, since we already assign them below in the function
with 'cld_lock' held.

As an additional benefit, code size gets smaller.

before:
textdata bss dec hex filename
26188   22564208   326527f8c 
drivers/staging/lustre/lustre/mgc/mgc_request.o

after:
textdata bss dec hex filename
26092   22564208   325567f2c 
drivers/staging/lustre/lustre/mgc/mgc_request.o

Signed-off-by: Cihangir Akturk 
---
 drivers/staging/lustre/lustre/mgc/mgc_request.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index eee0b66..36c3049 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -288,7 +288,7 @@ config_log_add(struct obd_device *obd, char *logname,
struct config_llog_data *cld;
struct config_llog_data *sptlrpc_cld;
struct config_llog_data *params_cld;
-   bool locked = false;
+   struct config_llog_data *recover_cld = NULL;
charseclogname[32];
char*ptr;
int rc;
@@ -333,20 +333,14 @@ config_log_add(struct obd_device *obd, char *logname,
goto out_params;
}
 
-   cld->cld_sptlrpc = sptlrpc_cld;
-   cld->cld_params = params_cld;
-
LASSERT(lsi->lsi_lmd);
if (!(lsi->lsi_lmd->lmd_flags & LMD_FLG_NOIR)) {
-   struct config_llog_data *recover_cld;
-
ptr = strrchr(seclogname, '-');
if (ptr) {
*ptr = 0;
} else {
CERROR("%s: sptlrpc log name not correct, %s: rc = 
%d\n",
   obd->obd_name, seclogname, -EINVAL);
-   config_log_put(cld);
rc = -EINVAL;
goto out_cld;
}
@@ -355,14 +349,10 @@ config_log_add(struct obd_device *obd, char *logname,
rc = PTR_ERR(recover_cld);
goto out_cld;
}
-
-   mutex_lock(>cld_lock);
-   locked = true;
-   cld->cld_recover = recover_cld;
}
 
-   if (!locked)
-   mutex_lock(>cld_lock);
+   mutex_lock(>cld_lock);
+   cld->cld_recover = recover_cld;
cld->cld_params = params_cld;
cld->cld_sptlrpc = sptlrpc_cld;
mutex_unlock(>cld_lock);
-- 
2.7.4

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

Re: [RESEND PATCH] staging: vboxvideo: remove dead gamma lut code

2017-08-07 Thread Daniel Vetter 
On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code that was not doing anything
> sensible anyway.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/staging/vboxvideo/vbox_fb.c   | 15 ---
>  drivers/staging/vboxvideo/vbox_mode.c |  5 -
>  2 files changed, 20 deletions(-)
> 
> [This time with an improved Cc list, sorry for the noise. For new
>  people, please refer to https://lkml.org/lkml/2017/7/13/593 for
>  context]
> 
> Hi Daniel,
> 
> Here it goes, but do you really need me to resend v5 14/14?

Well it's not yet on dri-devel, but our pre-merge CI bots can't read such
instructions. They expect a clean new series that applies cleanly, as a
top-post, when resending stuff.

Anyway, applied.

Thanks, Daniel

> 
> Cheers,
> peda
> 
> diff --git a/drivers/staging/vboxvideo/vbox_fb.c 
> b/drivers/staging/vboxvideo/vbox_fb.c
> index 35f6d9f8c203..bf6635826159 100644
> --- a/drivers/staging/vboxvideo/vbox_fb.c
> +++ b/drivers/staging/vboxvideo/vbox_fb.c
> @@ -317,22 +317,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
>   return 0;
>  }
>  
> -static void vbox_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
> -   u16 blue, int regno)
> -{
> -}
> -
> -static void vbox_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
> -   u16 *blue, int regno)
> -{
> - *red = regno;
> - *green = regno;
> - *blue = regno;
> -}
> -
>  static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
> - .gamma_set = vbox_fb_gamma_set,
> - .gamma_get = vbox_fb_gamma_get,
>   .fb_probe = vboxfb_create,
>  };
>  
> diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
> b/drivers/staging/vboxvideo/vbox_mode.c
> index f2b85f3256fa..996da1c79158 100644
> --- a/drivers/staging/vboxvideo/vbox_mode.c
> +++ b/drivers/staging/vboxvideo/vbox_mode.c
> @@ -134,10 +134,6 @@ static int vbox_set_view(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> -static void vbox_crtc_load_lut(struct drm_crtc *crtc)
> -{
> -}
> -
>  static void vbox_crtc_dpms(struct drm_crtc *crtc, int mode)
>  {
>   struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> @@ -330,7 +326,6 @@ static const struct drm_crtc_helper_funcs 
> vbox_crtc_helper_funcs = {
>   .mode_set = vbox_crtc_mode_set,
>   /* .mode_set_base = vbox_crtc_mode_set_base, */
>   .disable = vbox_crtc_disable,
> - .load_lut = vbox_crtc_load_lut,
>   .prepare = vbox_crtc_prepare,
>   .commit = vbox_crtc_commit,
>  };
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel