date:20181123

Re: [PATCH v6 00/33] staging: mt7621-pci: Parse ports info from DT and other minor cleanups

2018-11-23 Thread Sergio Paracuellos

On Sat, Nov 24, 2018 at 1:21 AM NeilBrown  wrote:
>
> On Mon, Nov 12 2018, Sergio Paracuellos wrote:
>
> > On Mon, Nov 12, 2018 at 08:40:10AM +1100, NeilBrown wrote:
> >> On Sun, Nov 11 2018, Greg KH wrote:
> >>
> >> > On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
> >> >> This patch series parse remaining port info from device tree storing
> >> >> it in mt7621_pcie_port struct created for this. It also performs a lot
> >> >> of cleanups to get the driver in a good shape to give it a try to get
> >> >> mainlined. All of this changes are only compile-tested.
> >> >
> >> > Given the lack of responses here, I guess I'll just merge this and see
> >> > what happens :)
> >>
> >> Sounds like a good plan.
> >> I had meant to look at it this past weekend, but ran out of time.
> >> It is a bit awkward for me to test on mainline at the moment as
> >>
> >> # first bad commit: [f8c55dc6e828324fc58c0bb32d72a5a4041d1c3b] MIPS: use 
> >> generic dma noncoherent ops for simple noncoherent platforms
> >>
> >> breaks mmc on my hardware, and my root filesystem is on mmc.
> >>
> >> But I should still be able to get it tested sometime in the next couple
> >> of weeks, and will provide feedback once I have it.
> >
> > Thanks, Neil. Please, let me know if I can help in any way.
>
> I've got all the way to the end of the series and with the fixes that
> I've already posted, my device still works.
> There are lots of nice clean-ups in there - thanks!  I didn't review
> them very closely as I was mostly focused on testing but what I saw
> generally looked nice.

Thanks for your effort in reviewing and testing this series. There
were a bit long
and with lots of changes and cleanups.

>
> For the clock issue, I would just make a missing driver non-fatal.
> clk_enable() is a no-op on ralink-mips, and I'm not sure that
> clk_prepare does much either.

Do you mean just remove clocks from bindings and its clk_* references in
code?

>
> Handling the reset issue is a bit harder.
> It seems that most bits in the reset register are
>  1=assert  0=deassert
> but that on some chips, the three PCI reset lines are inverted.
> It would be easiest to put a quirk in  arch/mips/ralink/reset.c
> to check the CHIP_REV for the three lines and invert.

I'll see how to achieve this issue. Is it ok to submit the patch to staging
if I add a quirk in the mainlined reset.c file? Include linux-mips
mail list in the
CC is enough?

>
> It might be cleaner to add some information to devicetree, but I cannot
> easily find any precedent for that.
>
> BTW, rather than calling
> reset_control_deassert(port->pcie_rst);
> reset_control_assert(port->pcie_rst);
>
> maybe we should
> reset_control_reset(port->pcie_rst);
> and not worry about a delay.

I'll also check this.

>
> Are you OK to submit patches to address the various issues that I found?

I'll do my best to try to fix this up.

>
> Thanks a lot,
> NeilBrown

Best regards,
Sergio Paracuellos
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 14/33] staging: mt7621-dts: add sysctl registers base address to pcie

2018-11-23 Thread Sergio Paracuellos

On Sat, Nov 24, 2018 at 12:07 AM NeilBrown  wrote:
>
> On Sun, Nov 04 2018, Sergio Paracuellos wrote:
>
> > Add missing system control registers address in pcie node of
> > the device tree.
> >
> > Signed-off-by: Sergio Paracuellos 
> > ---
> >  drivers/staging/mt7621-dts/mt7621.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
> > b/drivers/staging/mt7621-dts/mt7621.dtsi
> > index 2e837e6..6b4bc43 100644
> > --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> > +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> > @@ -397,8 +397,8 @@
> >   reg = <0x1e14 0x100 /* host-pci bridge registers */
> >   0x1e142000 0x100/* pcie port 0 RC control 
> > registers */
> >   0x1e143000 0x100/* pcie port 1 RC control 
> > registers */
> > - 0x1e144000 0x100>;  /* pcie port 2 RC control 
> > registers */
> > -
> > + 0x1e144000 0x100/* pcie port 2 RC control 
> > registers */
> > + 0x1e00 0x100>;  /* sysctl */
>
> This is no good.  The sysctl register are already claimed by palmbus, so
> pci fails to claim it.
> The best way to access the sysc registers is to use
>  rt_sysc_[rwm]32().
>
> Below is my current fix-up patch to deal with this.
>
> Thanks,
> NeilBrown

Yes, It has more sense now. I was wondering the real need to do this
mapping from pcie bindings
and the best way to access the sys control registers and I ended up
with that. I'll fix this up.

Thanks for testing, Neil.

Best regards,
Sergio Paracuellos
>
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index 6b4bc43d8eb6..e1000690bef2 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -398,7 +398,7 @@
> 0x1e142000 0x100/* pcie port 0 RC control 
> registers */
> 0x1e143000 0x100/* pcie port 1 RC control 
> registers */
> 0x1e144000 0x100/* pcie port 2 RC control 
> registers */
> -   0x1e00 0x100>;  /* sysctl */
> +   >;
> #address-cells = <3>;
> #size-cells = <2>;
>
> diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
> b/drivers/staging/mt7621-pci/pci-mt7621.c
> index aa9baa776923..be4680f9b43a 100644
> --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> @@ -172,7 +172,6 @@ struct mt7621_pcie_port {
>  /**
>   * struct mt7621_pcie - PCIe host information
>   * @base: IO Mapped Register Base
> - * @sysctl: system control mapped register base
>   * @io: IO resource
>   * @mem: non-prefetchable memory resource
>   * @busn: bus range
> @@ -182,7 +181,6 @@ struct mt7621_pcie_port {
>   */
>  struct mt7621_pcie {
> void __iomem *base;
> -   void __iomem *sysctl;
> struct device *dev;
> struct resource io;
> struct resource mem;
> @@ -397,8 +395,7 @@ set_phy_for_ssc(struct mt7621_pcie_port *port)
>
>  static void mt7621_enable_phy(struct mt7621_pcie_port *port)
>  {
> -   struct mt7621_pcie *pcie = port->pcie;
> -   u32 chip_rev_id = ioread32(pcie->sysctl + MT7621_CHIP_REV_ID);
> +   u32 chip_rev_id = rt_sysc_r32(MT7621_CHIP_REV_ID);
>
> if ((chip_rev_id & 0x) == CHIP_REV_MT7621_E2)
> bypass_pipe_rst(port);
> @@ -534,16 +531,6 @@ static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
> if (IS_ERR(pcie->base))
> return PTR_ERR(pcie->base);
>
> -   err = of_address_to_resource(node, 4, );
> -   if (err) {
> -   dev_err(dev, "missing \"reg\" property\n");
> -   return err;
> -   }
> -
> -   pcie->sysctl = devm_ioremap_resource(dev, );
> -   if (IS_ERR(pcie->sysctl))
> -   return PTR_ERR(pcie->sysctl);
> -
> for_each_available_child_of_node(node, child) {
> int slot;
>
> @@ -637,11 +624,9 @@ static int mt7621_pcie_register_host(struct 
> pci_host_bridge *host,
>
>  static void mt7621_set_gpio_mode(struct mt7621_pcie *pcie)
>  {
> -   u32 reg = ioread32(pcie->sysctl + MT7621_GPIO_MODE);
> -
> -   reg &= ~(0x3 << 10 | 0x3 << 3);
> -   reg |= (BIT(10) | BIT(3));
> -   iowrite32(reg, pcie->sysctl + MT7621_GPIO_MODE);
> +   rt_sysc_m32(0x3 << 10 | 0x3 << 3,
> +   BIT(10) | BIT(3),
> +   MT7621_GPIO_MODE);
> mdelay(100);
>  }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 00/12] switchdev: Convert switchdev_port_obj_{add,del}() to notifiers

2018-11-23 Thread David Miller

From: Petr Machata 
Date: Thu, 22 Nov 2018 23:27:52 +

> An offloading driver may need to have access to switchdev events on
> ports that aren't directly under its control. An example is a VXLAN port
> attached to a bridge offloaded by a driver. The driver needs to know
> about VLANs configured on the VXLAN device. However the VXLAN device
> isn't stashed between the bridge and a front-panel-port device (such as
> is the case e.g. for LAG devices), so the usual switchdev ops don't
> reach the driver.
> 
> VXLAN is likely not the only device type like this: in theory any L2
> tunnel device that needs offloading will prompt requirement of this
> sort.
> 
> A way to fix this is to give up the notion of port object addition /
> deletion as a switchdev operation, which assumes somewhat tight coupling
> between the message producer and consumer. And instead send the message
> over a notifier chain.
 ...

Series applied, thank you.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: iio: ad5933: finalized device-tree support

2018-11-23 Thread Rodrigo Siqueira

Hi Marcelo,

I believe that a proper commit message for this patch could be something
like "Add device tree support".

On 11/23, Marcelo Schmitt wrote:
> Added a of_device_id struct variable and subsequent call to
> MODULE_DEVICE_TABLE macro to complete device-tree support for this
> driver.
> 
> Signed-off-by: Marcelo Schmitt 
> ---
>  drivers/staging/iio/impedance-analyzer/ad5933.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index edb8b540bbf1..19e8b6d2865c 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -771,9 +771,18 @@ static const struct i2c_device_id ad5933_id[] = {
>  
>  MODULE_DEVICE_TABLE(i2c, ad5933_id);
>  
> +static const struct of_device_id ad5933_of_match[] = {
> + { .compatible = "analog-devices,ad5933" },
> + { .compatible = "analog-devices,ad5934" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad5933_of_match);
> +
>  static struct i2c_driver ad5933_driver = {
>   .driver = {
>   .name = "ad5933",
> + .of_match_table = ad5933_of_match,
>   },
>   .probe = ad5933_probe,
>   .remove = ad5933_remove,
> -- 
> 2.17.1
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-usp+unsubscr...@googlegroups.com.
> To post to this group, send email to kernel-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kernel-usp/20181123235159.hh43xnvvwsil4on2%40smtp.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
Rodrigo Siqueira
https://siqueira.tech
https://twitter.com/siqueirajordao
Graduate Student
Department of Computer Science
University of São Paulo


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

[PATCH v3 7/7] staging:iio:ad2s90: Move out of staging

2018-11-23 Thread Matheus Tavares

Move ad2s90 resolver driver out of staging to the main tree.

Signed-off-by: Matheus Tavares 
Signed-off-by: Victor Colombo 
---
Changes in v3:
 - none

Changes in v2:
 - Disabled git move detection, to see the whole code, as Jonathan
 suggested

 drivers/iio/resolver/Kconfig  |  10 ++
 drivers/iio/resolver/Makefile |   1 +
 drivers/iio/resolver/ad2s90.c | 131 ++
 drivers/staging/iio/resolver/Kconfig  |  10 --
 drivers/staging/iio/resolver/Makefile |   1 -
 drivers/staging/iio/resolver/ad2s90.c | 131 --
 6 files changed, 142 insertions(+), 142 deletions(-)
 create mode 100644 drivers/iio/resolver/ad2s90.c
 delete mode 100644 drivers/staging/iio/resolver/ad2s90.c

diff --git a/drivers/iio/resolver/Kconfig b/drivers/iio/resolver/Kconfig
index 2ced9f22aa70..786801be54f6 100644
--- a/drivers/iio/resolver/Kconfig
+++ b/drivers/iio/resolver/Kconfig
@@ -3,6 +3,16 @@
 #
 menu "Resolver to digital converters"
 
+config AD2S90
+   tristate "Analog Devices ad2s90 driver"
+   depends on SPI
+   help
+ Say yes here to build support for Analog Devices spi resolver
+ to digital converters, ad2s90, provides direct access via sysfs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad2s90.
+
 config AD2S1200
tristate "Analog Devices ad2s1200/ad2s1205 driver"
depends on SPI
diff --git a/drivers/iio/resolver/Makefile b/drivers/iio/resolver/Makefile
index 4e1dccae07e7..398d82d50028 100644
--- a/drivers/iio/resolver/Makefile
+++ b/drivers/iio/resolver/Makefile
@@ -2,4 +2,5 @@
 # Makefile for Resolver/Synchro drivers
 #
 
+obj-$(CONFIG_AD2S90) += ad2s90.o
 obj-$(CONFIG_AD2S1200) += ad2s1200.o
diff --git a/drivers/iio/resolver/ad2s90.c b/drivers/iio/resolver/ad2s90.c
new file mode 100644
index ..a41f5cb10da5
--- /dev/null
+++ b/drivers/iio/resolver/ad2s90.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ad2s90.c simple support for the ADI Resolver to Digital Converters: AD2S90
+ *
+ * Copyright (c) 2010-2010 Analog Devices Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * Although chip's max frequency is 2Mhz, it needs 600ns between CS and the
+ * first falling edge of SCLK, so frequency should be at most 1 / (2 * 6e-7)
+ */
+#define AD2S90_MAX_SPI_FREQ_HZ  83
+
+struct ad2s90_state {
+   struct mutex lock; /* lock to protect rx buffer */
+   struct spi_device *sdev;
+   u8 rx[2] cacheline_aligned;
+};
+
+static int ad2s90_read_raw(struct iio_dev *indio_dev,
+  struct iio_chan_spec const *chan,
+  int *val,
+  int *val2,
+  long m)
+{
+   int ret;
+   struct ad2s90_state *st = iio_priv(indio_dev);
+
+   if (chan->type != IIO_ANGL)
+   return -EINVAL;
+
+   switch (m) {
+   case IIO_CHAN_INFO_SCALE:
+   /* 2 * Pi / 2^12 */
+   *val = 6283; /* mV */
+   *val2 = 12;
+   return IIO_VAL_FRACTIONAL_LOG2;
+   case IIO_CHAN_INFO_RAW:
+   mutex_lock(>lock);
+   ret = spi_read(st->sdev, st->rx, 2);
+   if (ret < 0) {
+   mutex_unlock(>lock);
+   return ret;
+   }
+   *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
+
+   mutex_unlock(>lock);
+
+   return IIO_VAL_INT;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static const struct iio_info ad2s90_info = {
+   .read_raw = ad2s90_read_raw,
+};
+
+static const struct iio_chan_spec ad2s90_chan = {
+   .type = IIO_ANGL,
+   .indexed = 1,
+   .channel = 0,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+};
+
+static int ad2s90_probe(struct spi_device *spi)
+{
+   struct iio_dev *indio_dev;
+   struct ad2s90_state *st;
+
+   if (spi->max_speed_hz > AD2S90_MAX_SPI_FREQ_HZ) {
+   dev_err(>dev, "SPI CLK, %d Hz exceeds %d Hz\n",
+   spi->max_speed_hz, AD2S90_MAX_SPI_FREQ_HZ);
+   return -EINVAL;
+   }
+
+   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
+   if (!indio_dev)
+   return -ENOMEM;
+   st = iio_priv(indio_dev);
+   spi_set_drvdata(spi, indio_dev);
+
+   mutex_init(>lock);
+   st->sdev = spi;
+   indio_dev->dev.parent = >dev;
+   indio_dev->info = _info;
+   indio_dev->modes = INDIO_DIRECT_MODE;
+   indio_dev->channels = _chan;
+   indio_dev->num_channels = 1;
+   indio_dev->name = spi_get_device_id(spi)->name;
+
+   return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
+}
+
+static const struct of_device_id ad2s90_of_match[] = {
+   { .compatible = "adi,ad2s90", },
+

[PATCH v3 2/7] staging:iio:ad2s90: Remove spi setup that should be done via dt

2018-11-23 Thread Matheus Tavares

The ad2s90 driver currently sets some spi settings (max_speed_hz and
mode) at ad2s90_probe. Since the maximum frequency is a required element
in DT binding for spi slave devices and because the spi mode for the
device can be either (0,0) or (1,1), these settings should be handled
via device tree, not in the driver's code. This patch removes them from
the probe function.

Note: The way in which the mentioned spi settings need to be specified
on the ad2s90's node of a device tree will be documented in the future
patch "dt-bindings:iio:resolver: Add docs for ad2s90".

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Rewritten patch message to better explain why the code snippet in
 question should be removed.

 drivers/staging/iio/resolver/ad2s90.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index fdae067ed866..abb9b9147ee6 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -77,7 +77,6 @@ static int ad2s90_probe(struct spi_device *spi)
 {
struct iio_dev *indio_dev;
struct ad2s90_state *st;
-   int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
if (!indio_dev)
@@ -94,16 +93,6 @@ static int ad2s90_probe(struct spi_device *spi)
indio_dev->num_channels = 1;
indio_dev->name = spi_get_device_id(spi)->name;
 
-   /* need 600ns between CS and the first falling edge of SCLK */
-   spi->max_speed_hz = 83;
-   spi->mode = SPI_MODE_3;
-   ret = spi_setup(spi);
-
-   if (ret < 0) {
-   dev_err(>dev, "spi_setup failed!\n");
-   return ret;
-   }
-
return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
 }
 
-- 
2.18.0

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

[PATCH v3 6/7] staging:iio:ad2s90: Add comment to device state mutex

2018-11-23 Thread Matheus Tavares

From: Victor Colombo 

Fix the checkpatch.pl issue:
"CHECK: struct mutex definition without comment".

Signed-off-by: Victor Colombo 
Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Patch added in v2

 drivers/staging/iio/resolver/ad2s90.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 678351dabe6b..a41f5cb10da5 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -22,7 +22,7 @@
 #define AD2S90_MAX_SPI_FREQ_HZ  83
 
 struct ad2s90_state {
-   struct mutex lock;
+   struct mutex lock; /* lock to protect rx buffer */
struct spi_device *sdev;
u8 rx[2] cacheline_aligned;
 };
-- 
2.18.0

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

[PATCH v3 4/7] dt-bindings:iio:resolver: Add docs for ad2s90

2018-11-23 Thread Matheus Tavares

This patch adds the device tree binding documentation for the ad2s90
resolver-to-digital converter.

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - Added reference to spi-bus documentation after spi properties, as
 suggested by Alexandru Ardelean.

Changes in v2:
 - Rewritten 'spi-cpol and spi-cpha' item to say that the device can
 work in either mode (0,0) or (1,1) and explain how they should be
 specified in DT.

 .../bindings/iio/resolver/ad2s90.txt  | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/resolver/ad2s90.txt

diff --git a/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt 
b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
new file mode 100644
index ..477d41fa6467
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
@@ -0,0 +1,31 @@
+Analog Devices AD2S90 Resolver-to-Digital Converter
+
+https://www.analog.com/en/products/ad2s90.html
+
+Required properties:
+  - compatible: should be "adi,ad2s90"
+  - reg: SPI chip select number for the device
+  - spi-max-frequency: set maximum clock frequency, must be 83
+  - spi-cpol and spi-cpha:
+Either SPI mode (0,0) or (1,1) must be used, so specify none or both of
+spi-cpha, spi-cpol.
+
+See for more details:
+Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Note about max frequency:
+Chip's max frequency, as specified in its datasheet, is 2Mhz. But a 600ns
+delay is expected between the application of a logic LO to CS and the
+application of SCLK, as also specified. And since the delay is not
+implemented in the spi code, to satisfy it, SCLK's period should be at most
+2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which gives
+roughly 83Hz.
+
+Example:
+resolver@0 {
+   compatible = "adi,ad2s90";
+   reg = <0>;
+   spi-max-frequency = <83>;
+   spi-cpol;
+   spi-cpha;
+};
-- 
2.18.0

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

[PATCH v3 5/7] staging:iio:ad2s90: Replace license text w/ SPDX identifier

2018-11-23 Thread Matheus Tavares

This patch removes the license boilerplate text at the top of ad2s90.c
and, instead, adds the SPDX GPL-2.0 license identifier, which solves the
checkpatch.pl warning:
"WARNING: Missing or malformed SPDX-License-Identifier tag in line 1".

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Changed GPL-2.0-only identifier to GPL-2.0
 - Removed license boilerplate text
 - Rewritten patch message to reflect these modifications

 drivers/staging/iio/resolver/ad2s90.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 4721e9bbb8b0..678351dabe6b 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ad2s90.c simple support for the ADI Resolver to Digital Converters: AD2S90
  *
  * Copyright (c) 2010-2010 Analog Devices Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
  */
 #include 
 #include 
-- 
2.18.0

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

[PATCH v3 3/7] staging:iio:ad2s90: Add max frequency check at probe

2018-11-23 Thread Matheus Tavares

From: Alexandru Ardelean 

This patch adds a max frequency check at the beginning of ad2s90_probe
function so that when it is set to a value above 0.83Mhz, dev_err is
called with an appropriate message and -EINVAL is returned.

The defined limit is 0.83Mhz instead of 2Mhz, which is the chip's max
frequency as specified in the datasheet, because, as also specified in
the datasheet, a 600ns delay is expected between the application of a
logic LO to CS and the application of SCLK. Since the delay is not
implemented in the spi code, to satisfy it, SCLK's period should be at
most 2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which
gives roughly 83Hz.

Signed-off-by: Alexandru Ardelean 
Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - none

Changes in v2:
 - Correctly credit Alexandru as the patch's author

 drivers/staging/iio/resolver/ad2s90.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index abb9b9147ee6..4721e9bbb8b0 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -19,6 +19,12 @@
 #include 
 #include 
 
+/*
+ * Although chip's max frequency is 2Mhz, it needs 600ns between CS and the
+ * first falling edge of SCLK, so frequency should be at most 1 / (2 * 6e-7)
+ */
+#define AD2S90_MAX_SPI_FREQ_HZ  83
+
 struct ad2s90_state {
struct mutex lock;
struct spi_device *sdev;
@@ -78,6 +84,12 @@ static int ad2s90_probe(struct spi_device *spi)
struct iio_dev *indio_dev;
struct ad2s90_state *st;
 
+   if (spi->max_speed_hz > AD2S90_MAX_SPI_FREQ_HZ) {
+   dev_err(>dev, "SPI CLK, %d Hz exceeds %d Hz\n",
+   spi->max_speed_hz, AD2S90_MAX_SPI_FREQ_HZ);
+   return -EINVAL;
+   }
+
indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
-- 
2.18.0

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

[PATCH v3 1/7] staging:iio:ad2s90: Add device tree support

2018-11-23 Thread Matheus Tavares

This patch adds device tree support to ad2s90 with standard
device tree id table.

Signed-off-by: Matheus Tavares 
---
Changes in v3:
 - Removed of_patch_ptr from of_match_table assignment

Changes in v2:
 - none

 drivers/staging/iio/resolver/ad2s90.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 3e257ac46f7a..fdae067ed866 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -107,6 +107,12 @@ static int ad2s90_probe(struct spi_device *spi)
return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
 }
 
+static const struct of_device_id ad2s90_of_match[] = {
+   { .compatible = "adi,ad2s90", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, ad2s90_of_match);
+
 static const struct spi_device_id ad2s90_id[] = {
{ "ad2s90" },
{}
@@ -116,6 +122,7 @@ MODULE_DEVICE_TABLE(spi, ad2s90_id);
 static struct spi_driver ad2s90_driver = {
.driver = {
.name = "ad2s90",
+   .of_match_table = ad2s90_of_match,
},
.probe = ad2s90_probe,
.id_table = ad2s90_id,
-- 
2.18.0

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

[PATCH v3 0/7] staging:iio:ad2s90: Add dt support and move out of staging

2018-11-23 Thread Matheus Tavares

This series adds device tree support to ad2s90, adds the respective dt-binding
documentation, solves all remaining codestyle problems for ad2s90 and move it
out of staging.

This patch set completes all the remaining itens listed to be done before moving
the driver out of staging, enumerated in this mail thread:
https://marc.info/?l=linux-iio=154028966111330=2.

Alexandru Ardelean (1):
  staging:iio:ad2s90: Add max frequency check at probe

Matheus Tavares (5):
  staging:iio:ad2s90: Add device tree support
  staging:iio:ad2s90: Remove spi setup that should be done via dt
  dt-bindings:iio:resolver: Add docs for ad2s90
  staging:iio:ad2s90: Replace license text w/ SPDX identifier
  staging:iio:ad2s90: Move out of staging

Victor Colombo (1):
  staging:iio:ad2s90: Add comment to device state mutex

 .../bindings/iio/resolver/ad2s90.txt  |  31 +
 drivers/iio/resolver/Kconfig  |  10 ++
 drivers/iio/resolver/Makefile |   1 +
 drivers/iio/resolver/ad2s90.c | 131 ++
 drivers/staging/iio/resolver/Kconfig  |  10 --
 drivers/staging/iio/resolver/Makefile |   1 -
 drivers/staging/iio/resolver/ad2s90.c | 127 -
 7 files changed, 173 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
 create mode 100644 drivers/iio/resolver/ad2s90.c
 delete mode 100644 drivers/staging/iio/resolver/ad2s90.c

-- 
2.18.0

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

Re: [PATCH v6 00/33] staging: mt7621-pci: Parse ports info from DT and other minor cleanups

2018-11-23 Thread NeilBrown

On Mon, Nov 12 2018, Sergio Paracuellos wrote:

> On Mon, Nov 12, 2018 at 08:40:10AM +1100, NeilBrown wrote:
>> On Sun, Nov 11 2018, Greg KH wrote:
>> 
>> > On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
>> >> This patch series parse remaining port info from device tree storing
>> >> it in mt7621_pcie_port struct created for this. It also performs a lot
>> >> of cleanups to get the driver in a good shape to give it a try to get
>> >> mainlined. All of this changes are only compile-tested.
>> >
>> > Given the lack of responses here, I guess I'll just merge this and see
>> > what happens :)
>> 
>> Sounds like a good plan.
>> I had meant to look at it this past weekend, but ran out of time.
>> It is a bit awkward for me to test on mainline at the moment as
>> 
>> # first bad commit: [f8c55dc6e828324fc58c0bb32d72a5a4041d1c3b] MIPS: use 
>> generic dma noncoherent ops for simple noncoherent platforms
>> 
>> breaks mmc on my hardware, and my root filesystem is on mmc.
>> 
>> But I should still be able to get it tested sometime in the next couple
>> of weeks, and will provide feedback once I have it.
>
> Thanks, Neil. Please, let me know if I can help in any way.

I've got all the way to the end of the series and with the fixes that
I've already posted, my device still works.
There are lots of nice clean-ups in there - thanks!  I didn't review
them very closely as I was mostly focused on testing but what I saw
generally looked nice.

For the clock issue, I would just make a missing driver non-fatal.
clk_enable() is a no-op on ralink-mips, and I'm not sure that
clk_prepare does much either.

Handling the reset issue is a bit harder.
It seems that most bits in the reset register are
 1=assert  0=deassert
but that on some chips, the three PCI reset lines are inverted.
It would be easiest to put a quirk in  arch/mips/ralink/reset.c 
to check the CHIP_REV for the three lines and invert.

It might be cleaner to add some information to devicetree, but I cannot
easily find any precedent for that.

BTW, rather than calling
reset_control_deassert(port->pcie_rst);
reset_control_assert(port->pcie_rst);

maybe we should
reset_control_reset(port->pcie_rst);
and not worry about a delay.

Are you OK to submit patches to address the various issues that I found?

Thanks a lot,
NeilBrown

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

[PATCH] staging: iio: ad5933: finalized device-tree support

2018-11-23 Thread Marcelo Schmitt

Added a of_device_id struct variable and subsequent call to
MODULE_DEVICE_TABLE macro to complete device-tree support for this
driver.

Signed-off-by: Marcelo Schmitt 
---
 drivers/staging/iio/impedance-analyzer/ad5933.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index edb8b540bbf1..19e8b6d2865c 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -771,9 +771,18 @@ static const struct i2c_device_id ad5933_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, ad5933_id);
 
+static const struct of_device_id ad5933_of_match[] = {
+   { .compatible = "analog-devices,ad5933" },
+   { .compatible = "analog-devices,ad5934" },
+   { },
+};
+
+MODULE_DEVICE_TABLE(of, ad5933_of_match);
+
 static struct i2c_driver ad5933_driver = {
.driver = {
.name = "ad5933",
+   .of_match_table = ad5933_of_match,
},
.probe = ad5933_probe,
.remove = ad5933_remove,
-- 
2.17.1

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

Re: [PATCH v6 14/33] staging: mt7621-dts: add sysctl registers base address to pcie

2018-11-23 Thread NeilBrown

On Sun, Nov 04 2018, Sergio Paracuellos wrote:

> Add missing system control registers address in pcie node of
> the device tree.
>
> Signed-off-by: Sergio Paracuellos 
> ---
>  drivers/staging/mt7621-dts/mt7621.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index 2e837e6..6b4bc43 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -397,8 +397,8 @@
>   reg = <0x1e14 0x100 /* host-pci bridge registers */
>   0x1e142000 0x100/* pcie port 0 RC control registers 
> */
>   0x1e143000 0x100/* pcie port 1 RC control registers 
> */
> - 0x1e144000 0x100>;  /* pcie port 2 RC control registers 
> */
> -
> + 0x1e144000 0x100/* pcie port 2 RC control registers 
> */
> + 0x1e00 0x100>;  /* sysctl */

This is no good.  The sysctl register are already claimed by palmbus, so
pci fails to claim it.
The best way to access the sysc registers is to use
 rt_sysc_[rwm]32().

Below is my current fix-up patch to deal with this.

Thanks,
NeilBrown


diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 6b4bc43d8eb6..e1000690bef2 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -398,7 +398,7 @@
0x1e142000 0x100/* pcie port 0 RC control registers 
*/
0x1e143000 0x100/* pcie port 1 RC control registers 
*/
0x1e144000 0x100/* pcie port 2 RC control registers 
*/
-   0x1e00 0x100>;  /* sysctl */
+   >;
#address-cells = <3>;
#size-cells = <2>;
 
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index aa9baa776923..be4680f9b43a 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -172,7 +172,6 @@ struct mt7621_pcie_port {
 /**
  * struct mt7621_pcie - PCIe host information
  * @base: IO Mapped Register Base
- * @sysctl: system control mapped register base
  * @io: IO resource
  * @mem: non-prefetchable memory resource
  * @busn: bus range
@@ -182,7 +181,6 @@ struct mt7621_pcie_port {
  */
 struct mt7621_pcie {
void __iomem *base;
-   void __iomem *sysctl;
struct device *dev;
struct resource io;
struct resource mem;
@@ -397,8 +395,7 @@ set_phy_for_ssc(struct mt7621_pcie_port *port)
 
 static void mt7621_enable_phy(struct mt7621_pcie_port *port)
 {
-   struct mt7621_pcie *pcie = port->pcie;
-   u32 chip_rev_id = ioread32(pcie->sysctl + MT7621_CHIP_REV_ID);
+   u32 chip_rev_id = rt_sysc_r32(MT7621_CHIP_REV_ID);
 
if ((chip_rev_id & 0x) == CHIP_REV_MT7621_E2)
bypass_pipe_rst(port);
@@ -534,16 +531,6 @@ static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
if (IS_ERR(pcie->base))
return PTR_ERR(pcie->base);
 
-   err = of_address_to_resource(node, 4, );
-   if (err) {
-   dev_err(dev, "missing \"reg\" property\n");
-   return err;
-   }
-
-   pcie->sysctl = devm_ioremap_resource(dev, );
-   if (IS_ERR(pcie->sysctl))
-   return PTR_ERR(pcie->sysctl);
-
for_each_available_child_of_node(node, child) {
int slot;
 
@@ -637,11 +624,9 @@ static int mt7621_pcie_register_host(struct 
pci_host_bridge *host,
 
 static void mt7621_set_gpio_mode(struct mt7621_pcie *pcie)
 {
-   u32 reg = ioread32(pcie->sysctl + MT7621_GPIO_MODE);
-
-   reg &= ~(0x3 << 10 | 0x3 << 3);
-   reg |= (BIT(10) | BIT(3));
-   iowrite32(reg, pcie->sysctl + MT7621_GPIO_MODE);
+   rt_sysc_m32(0x3 << 10 | 0x3 << 3,
+   BIT(10) | BIT(3),
+   MT7621_GPIO_MODE);
mdelay(100);
 }
 


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

Re: [PATCH v6 04/33] staging: mt7621-pci: factor out 'mt7621_pcie_enable_port' function

2018-11-23 Thread NeilBrown

On Sun, Nov 04 2018, Sergio Paracuellos wrote:

> Driver probe function is a mess and shall be refactored a lot. At first
> make use of assert and deassert control factoring out a new function
> called 'mt7621_pcie_enable_port'.

Testing continues

there are 2.5 problems with this patch.

Firstly you changed the asserting of reset from

> - ASSERT_SYSRST_PCIE(RALINK_PCIE0_RST | RALINK_PCIE1_RST | 
> RALINK_PCIE2_RST);

to
> + reset_control_assert(port->pcie_rst);
(for each port).
This looks reasonable, but doesn't work.

#define ASSERT_SYSRST_PCIE(val) \
do {\
if (rt_sysc_r32(SYSC_REG_CHIP_REV) == 0x00030101)   \
rt_sysc_m32(0, val, RALINK_RSTCTRL);\
else\
rt_sysc_m32(val, 0, RALINK_RSTCTRL);\
} while (0)

If the CHIP_REV is 0x30101, then we set the bit to assert (and clear to
deassert).
This is what reset_control_assert() does - it maps through to
ralink_assert_device().
My CHIP_REV is 0x30103 - so this does the wrong thing.

Secondly you have moved the updating of RALINK_PCI_PCIMSK_ADDR (I'm
guess that is the import piece) to before the
 read_config(pcie, slot, 0x70c);
This seems to break things.
If I move the read_config/dev_info() inside the new
mt7621_pcie_enable_port(), just after the reset(), it starts working
again.

Finally, the 1/2 problem is that there was previously a 300 msec delay
between asserting reset and deasserting it - you've removed that.
It still seems to work, so maybe it is OK.  But often hardware prefers
the reset to be held down for some minimum time.  So I'd feel more
comfortable having a msleep(100) while the port is in reset.

Below is my current fix-up patch which make the board work again after
this patch.  Swapping 'assert' and 'deassert' is obviously just a hack -
some more proper solution is required.

Thanks,
NeilBrown

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 9be5ca109a1b..6e32fbef9441 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -494,12 +494,16 @@ static int mt7621_pcie_enable_port(struct 
mt7621_pcie_port *port)
return err;
}

-   reset_control_assert(port->pcie_rst);
reset_control_deassert(port->pcie_rst);
+   msleep(100);
+   reset_control_assert(port->pcie_rst);
+
+   val = read_config(pcie, slot, 0x70c);
+   dev_info(dev, "Port %d N_FTS = %x\n", (unsigned int)val, slot);

if ((pcie_port_read(port, RALINK_PCI_STATUS) & 0x1) == 0) {
dev_err(dev, "pcie%d no card, disable it (RST & CLK)\n", slot);
-   reset_control_assert(port->pcie_rst);
+   reset_control_deassert(port->pcie_rst);
rt_sysc_m32(BIT(24 + slot), 0, RALINK_CLKCFG1);
pcie_link_status &= ~(1 << slot);
} else {
@@ -601,12 +605,6 @@ static int mt7621_pci_probe(struct platform_device *pdev)
bypass_pipe_rst(pcie);
set_phy_for_ssc(pcie);

-   list_for_each_entry_safe(port, tmp, >ports, list) {
-   u32 slot = port->slot;
-   val = read_config(pcie, slot, 0x70c);
-   dev_info(dev, "Port %d N_FTS = %x\n", (unsigned int)val, slot);
-   }
-
rt_sysc_m32(0, RALINK_PCIE_RST, RALINK_RSTCTRL);
rt_sysc_m32(0x30, 2 << 4, SYSC_REG_SYSTEM_CONFIG1);

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

[PATCH 1/9] staging: rtl8188eu: cleanup remaining comparsions to true

2018-11-23 Thread Michael Straube

Cleanup remaining comparsions to true.
if (x == true) -> if (x)
if (x != true) -> if (!x)
if (!x == true) -> if (!x)

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c   |  4 +--
 drivers/staging/rtl8188eu/core/rtw_cmd.c  | 10 +++---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 26 +++---
 drivers/staging/rtl8188eu/core/rtw_recv.c | 16 -
 drivers/staging/rtl8188eu/core/rtw_sta_mgt.c  |  2 +-
 .../staging/rtl8188eu/core/rtw_wlan_util.c|  2 +-
 drivers/staging/rtl8188eu/core/rtw_xmit.c |  7 ++--
 drivers/staging/rtl8188eu/include/rtw_mlme.h  |  2 +-
 .../staging/rtl8188eu/os_dep/ioctl_linux.c| 36 +--
 9 files changed, 53 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 1c319c2ca86d..1f232ba6651c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -629,7 +629,7 @@ static void start_bss_network(struct adapter *padapter, u8 
*pbuf)
}
 
/* setting only at  first time */
-   if (pmlmepriv->cur_network.join_res != true) {
+   if (!pmlmepriv->cur_network.join_res) {
/* WEP Key will be set before this function, do not
 * clear CAM.
 */
@@ -756,7 +756,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 
*pbuf,  int len)
 
DBG_88E("%s, len =%d\n", __func__, len);
 
-   if (check_fwstate(pmlmepriv, WIFI_AP_STATE) != true)
+   if (!check_fwstate(pmlmepriv, WIFI_AP_STATE))
return _FAIL;
 
if (len < 0 || len > MAX_IE_SZ)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c 
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index f6dbcf6fe39b..e3e46f7ac834 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -240,7 +240,7 @@ u8 rtw_sitesurvey_cmd(struct adapter  *padapter, struct 
ndis_802_11_ssid *ssid,
struct cmd_priv *pcmdpriv = >cmdpriv;
struct mlme_priv*pmlmepriv = >mlmepriv;
 
-   if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+   if (check_fwstate(pmlmepriv, _FW_LINKED))
rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SCAN, 1);
 
ph2c = kzalloc(sizeof(*ph2c), GFP_ATOMIC);
@@ -820,7 +820,7 @@ static void dynamic_chk_wk_hdl(struct adapter *padapter, u8 
*pbuf, int sz)
pmlmepriv = >mlmepriv;
 
 #ifdef CONFIG_88EU_AP_MODE
-   if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
+   if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
expire_timeout_chk(padapter);
 #endif
 
@@ -836,13 +836,13 @@ static void lps_ctrl_wk_hdl(struct adapter *padapter, u8 
lps_ctrl_type)
struct mlme_priv *pmlmepriv = >mlmepriv;
u8  mstatus;
 
-   if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
-   (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
+   if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) ||
+   check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
 
switch (lps_ctrl_type) {
case LPS_CTRL_SCAN:
-   if (check_fwstate(pmlmepriv, _FW_LINKED) == true) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED)) {
/* connect */
LPS_Leave(padapter);
}
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index e5c8b02e6ab2..b6210d98ee2d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -315,8 +315,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
d_cap = le16_to_cpu(le_dcap);
 
return ((src->Ssid.SsidLength == dst->Ssid.SsidLength) &&
-   ((!memcmp(src->MacAddress, dst->MacAddress, ETH_ALEN)) == true) 
&&
-   ((!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid, 
src->Ssid.SsidLength)) == true) &&
+   (!memcmp(src->MacAddress, dst->MacAddress, ETH_ALEN)) &&
+   (!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid, src->Ssid.SsidLength)) 
&&
((s_cap & WLAN_CAPABILITY_IBSS) ==
(d_cap & WLAN_CAPABILITY_IBSS)) &&
((s_cap & WLAN_CAPABILITY_ESS) ==
@@ -386,8 +386,8 @@ static void update_current_network(struct adapter *adapter, 
struct wlan_bssid_ex
 {
struct  mlme_priv   *pmlmepriv = &(adapter->mlmepriv);
 
-   if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) &&
-   (is_same_network(&(pmlmepriv->cur_network.network), pnetwork))) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED) &&
+   is_same_network(>cur_network.network, pnetwork)) {
update_network(&(pmlmepriv->cur_network.network), pnetwork, 
adapter, true);
rtw_update_protection(adapter, 
(pmlmepriv->cur_network.network.ies) + sizeof(struct ndis_802_11_fixed_ie),

[PATCH 8/9] staging: rtl8188eu: correct indentation

2018-11-23 Thread Michael Straube

Correct indentation to clear a checkpatch warning.
WARNING: suspect code indent for conditional statements (8, 24)

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 824e3c669a46..b048a3b633a9 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1739,7 +1739,7 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 
*in_ie, u8 *out_ie, uint in_
ielength = 12;
if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
-   authmode = _WPA_IE_ID_;
+   authmode = _WPA_IE_ID_;
if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
-- 
2.19.2

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

[PATCH 3/9] staging: rtl8188eu: use func in rtw_mlme.c

2018-11-23 Thread Michael Straube

Use __func__ instead of hardcoded function names.
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 48 +--
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index d5c22a028905..54f05e62da49 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -230,8 +230,9 @@ int rtw_if_up(struct adapter *padapter)
if (padapter->bDriverStopped || padapter->bSurpriseRemoved ||
!check_fwstate(>mlmepriv, _FW_LINKED)) {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
-("rtw_if_up:bDriverStopped(%d) OR 
bSurpriseRemoved(%d)",
-padapter->bDriverStopped, padapter->bSurpriseRemoved));
+("%s:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
+ __func__, padapter->bDriverStopped,
+ padapter->bSurpriseRemoved));
res = false;
} else {
res =  true;
@@ -555,11 +556,13 @@ void rtw_survey_event_callback(struct adapter 
*adapter, u8 *pbuf)
 
pnetwork = (struct wlan_bssid_ex *)pbuf;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, 
("rtw_survey_event_callback, ssid=%s\n",  pnetwork->Ssid.Ssid));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
+("%s, ssid=%s\n", __func__, pnetwork->Ssid.Ssid));
 
len = get_wlan_bssid_ex_sz(pnetwork);
if (len > (sizeof(struct wlan_bssid_ex))) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("\nrtw_survey_event_callback: return a wrong bss ***\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("\n%s: return a wrong bss ***\n", __func__));
return;
}
spin_lock_bh(>lock);
@@ -606,7 +609,8 @@ void rtw_surveydone_event_callback(struct adapter   
*adapter, u8 *pbuf)
pmlmepriv->wps_probe_req_ie = NULL;
}
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, 
("rtw_surveydone_event_callback: fw_state:%x\n\n", get_fwstate(pmlmepriv)));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
+("%s: fw_state:%x\n\n", __func__, get_fwstate(pmlmepriv)));
 
if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY)) {
del_timer_sync(>scan_to_timer);
@@ -695,7 +699,7 @@ static void free_scanqueue(struct   mlme_priv *pmlmepriv)
struct __queue *scan_queue = >scanned_queue;
struct list_head *plist, *phead, *ptemp;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, ("+free_scanqueue\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, ("+%s\n", __func__));
spin_lock_bh(_queue->lock);
spin_lock_bh(_queue->lock);
 
@@ -808,7 +812,7 @@ void rtw_indicate_disconnect(struct adapter *padapter)
 {
struct  mlme_priv *pmlmepriv = >mlmepriv;
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("+rtw_indicate_disconnect\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
_clr_fwstate_(pmlmepriv, _FW_UNDER_LINKING | WIFI_UNDER_WPS);
 
@@ -1159,12 +1163,15 @@ void rtw_stassoc_event_callback(struct adapter 
*adapter, u8 *pbuf)
psta = rtw_get_stainfo(>stapriv, pstassoc->macaddr);
if (psta) {
/* the sta have been in sta_info_queue => do nothing */
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("Error: 
rtw_stassoc_event_callback: sta has been in sta_hash_queue\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("Error: %s: sta has been in sta_hash_queue\n",
+ __func__));
return; /* between drv has received this event before and  fw 
have not yet to set key to CAM_ENTRY) */
}
psta = rtw_alloc_stainfo(>stapriv, pstassoc->macaddr);
if (!psta) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("Can't alloc 
sta_info when rtw_stassoc_event_callback\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("Can't alloc sta_info when %s\n", __func__));
return;
}
/* to do: init sta_info variable */
@@ -1293,7 +1300,7 @@ void rtw_stadel_event_callback(struct adapter *adapter, 
u8 *pbuf)
 
 void rtw_cpwm_event_callback(struct adapter *padapter, u8 *pbuf)
 {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+rtw_cpwm_event_callback 
!!!\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s !!!\n", __func__));
 }
 
 /*
@@ -1574,22 +1581,23 @@ int rtw_set_key(struct adapter *adapter, struct 
security_priv *psecuritypriv, in
if (psecuritypriv->dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
psetkeyparm->algorithm = (unsigned 
char)psecuritypriv->dot118021XGrpPrivacy;

[PATCH 4/9] staging: rtl8188eu: remove rtw_android_set_block()

2018-11-23 Thread Michael Straube

The function rtw_android_set_block() just returns zero. The only user
is the function rtw_android_priv_cmd(). The variable bytes_written is
initialized to zero and not changed before the use of
rtw_android_set_block(). Remove rtw_android_set_block() and it's only
use.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/rtw_android.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/rtw_android.c 
b/drivers/staging/rtl8188eu/os_dep/rtw_android.c
index 34080c0ce14a..2ea2af3286bc 100644
--- a/drivers/staging/rtl8188eu/os_dep/rtw_android.c
+++ b/drivers/staging/rtl8188eu/os_dep/rtw_android.c
@@ -127,12 +127,6 @@ static int android_get_p2p_addr(struct net_device *net, 
char *command,
return ETH_ALEN;
 }
 
-static int rtw_android_set_block(struct net_device *net, char *command,
-int total_len)
-{
-   return 0;
-}
-
 int rtw_android_priv_cmd(struct net_device *net, struct ifreq *ifr, int cmd)
 {
int ret = 0;
@@ -186,8 +180,6 @@ int rtw_android_priv_cmd(struct net_device *net, struct 
ifreq *ifr, int cmd)
priv_cmd.total_len);
break;
case ANDROID_WIFI_CMD_BLOCK:
-   bytes_written = rtw_android_set_block(net, command,
- priv_cmd.total_len);
break;
case ANDROID_WIFI_CMD_RXFILTER_START:
break;
-- 
2.19.2

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

[PATCH 6/9] staging: rtl8188eu: refactor if else statement

2018-11-23 Thread Michael Straube

Refactor if else statement to clear checkpatch warnings.
WARNING: else is not generally useful after a break or return
WARNING: line over 80 characters

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 9cc7d5b8293c..513b6d89a0de 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1758,12 +1758,9 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 
*in_ie, u8 *out_ie, uint in_
}
 
iEntry = SecIsInPMKIDList(adapter, pmlmepriv->assoc_bssid);
-   if (iEntry < 0) {
-   return ielength;
-   } else {
-   if (authmode == _WPA2_IE_ID_)
-   ielength = rtw_append_pmkid(adapter, iEntry, out_ie, 
ielength);
-   }
+   if (iEntry >= 0 && authmode == _WPA2_IE_ID_)
+   ielength = rtw_append_pmkid(adapter, iEntry, out_ie, ielength);
+
return ielength;
 }
 
-- 
2.19.2

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

[PATCH 9/9] staging: rtl8188eu: cleanup lines over 80 characters

2018-11-23 Thread Michael Straube

Cleanup lines over 80 characters by replacing tabs with spaces
or adding appropriate line breaks.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index b048a3b633a9..714f7a70ed64 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -324,7 +324,7 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
(d_cap & WLAN_CAPABILITY_ESS)));
 }
 
-struct wlan_network*rtw_get_oldest_wlan_network(struct __queue 
*scanned_queue)
+struct wlan_network *rtw_get_oldest_wlan_network(struct __queue *scanned_queue)
 {
struct list_head *plist, *phead;
struct wlan_network *pwlan = NULL;
@@ -413,7 +413,7 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
plist = phead->next;
 
while (phead != plist) {
-   pnetwork= container_of(plist, struct wlan_network, 
list);
+   pnetwork = container_of(plist, struct wlan_network, list);
 
if (is_same_network(>network, target))
break;
@@ -451,7 +451,8 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
pnetwork = rtw_alloc_network(pmlmepriv); /*  will 
update scan_time */
 
if (!pnetwork) {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("\n\n\nsomething wrong here\n\n\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+("\n\n\nsomething wrong here\n\n\n"));
goto exit;
}
 
@@ -469,9 +470,9 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
list_add_tail(>list, >queue);
}
} else {
-   /* we have an entry and we are going to update it. But this 
entry may
-* be already expired. In this case we do the same as we found 
a new
-* net and call the new_net handler
+   /* we have an entry and we are going to update it. But this
+* entry may be already expired. In this case we do the same
+* as we found a new net and call the new_net handler
 */
bool update_ie = true;
 
-- 
2.19.2

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

[PATCH 7/9] staging: rtl8188eu: remove return from void function

2018-11-23 Thread Michael Straube

Remove return from a void function to clear a checkpatch warning.
WARNING: void function return statements are not generally useful

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 513b6d89a0de..824e3c669a46 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -592,9 +592,7 @@ void rtw_survey_event_callback(struct adapter   
*adapter, u8 *pbuf)
}
 
 exit:
-
spin_unlock_bh(>lock);
-   return;
 }
 
 void rtw_surveydone_event_callback(struct adapter  *adapter, u8 *pbuf)
-- 
2.19.2

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

[PATCH 5/9] staging: rtl8188eu: cleanup declarations in rtw_mlme.c

2018-11-23 Thread Michael Straube

Replace tabs with spaces, remove spaces, remove blank lines
and break lines appropriatly in declarations.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 130 +++---
 1 file changed, 64 insertions(+), 66 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 54f05e62da49..9cc7d5b8293c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -24,11 +24,11 @@ extern const u8 MCS_rate_1R[16];
 
 int rtw_init_mlme_priv(struct adapter *padapter)
 {
-   int i;
-   u8  *pbuf;
-   struct wlan_network *pnetwork;
-   struct mlme_priv*pmlmepriv = >mlmepriv;
-   int res = _SUCCESS;
+   int i;
+   u8 *pbuf;
+   struct wlan_network *pnetwork;
+   struct mlme_priv *pmlmepriv = >mlmepriv;
+   int res = _SUCCESS;
 
/*  We don't need to memset padapter->XXX to zero, because adapter is 
allocated by vzalloc(). */
 
@@ -179,7 +179,7 @@ void _rtw_free_network_nolock(structmlme_priv 
*pmlmepriv, struct wlan_network *
 struct wlan_network *rtw_find_network(struct __queue *scanned_queue, u8 *addr)
 {
struct list_head *phead, *plist;
-   struct  wlan_network *pnetwork = NULL;
+   struct wlan_network *pnetwork = NULL;
u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
 
if (!memcmp(zero_addr, addr, ETH_ALEN)) {
@@ -259,7 +259,7 @@ u8 *rtw_get_capability_from_ie(u8 *ie)
 
 u16 rtw_get_capability(struct wlan_bssid_ex *bss)
 {
-   __le16  val;
+   __le16 val;
 
memcpy((u8 *), rtw_get_capability_from_ie(bss->ies), 2);
 
@@ -327,8 +327,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst)
 struct wlan_network*rtw_get_oldest_wlan_network(struct __queue 
*scanned_queue)
 {
struct list_head *plist, *phead;
-   struct  wlan_network*pwlan = NULL;
-   struct  wlan_network*oldest = NULL;
+   struct wlan_network *pwlan = NULL;
+   struct wlan_network *oldest = NULL;
 
phead = get_list_head(scanned_queue);
 
@@ -402,11 +402,11 @@ static void update_current_network(struct adapter 
*adapter, struct wlan_bssid_ex
 void rtw_update_scanned_network(struct adapter *adapter, struct wlan_bssid_ex 
*target)
 {
struct list_head *plist, *phead;
-   u32 bssid_ex_sz;
+   u32 bssid_ex_sz;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct __queue *queue = >scanned_queue;
-   struct wlan_network *pnetwork = NULL;
-   struct wlan_network *oldest = NULL;
+   struct wlan_network *pnetwork = NULL;
+   struct wlan_network *oldest = NULL;
 
spin_lock_bh(>lock);
phead = get_list_head(queue);
@@ -722,7 +722,7 @@ static void free_scanqueue(struct   mlme_priv *pmlmepriv)
  */
 void rtw_free_assoc_resources(struct adapter *adapter)
 {
-   struct  mlme_priv *pmlmepriv = >mlmepriv;
+   struct mlme_priv *pmlmepriv = >mlmepriv;
 
spin_lock_bh(>scanned_queue.lock);
rtw_free_assoc_resources_locked(adapter);
@@ -735,8 +735,8 @@ void rtw_free_assoc_resources(struct adapter *adapter)
 void rtw_free_assoc_resources_locked(struct adapter *adapter)
 {
struct wlan_network *pwlan = NULL;
-   struct  mlme_priv *pmlmepriv = >mlmepriv;
-   struct  sta_priv *pstapriv = >stapriv;
+   struct mlme_priv *pmlmepriv = >mlmepriv;
+   struct sta_priv *pstapriv = >stapriv;
struct wlan_network *tgt_network = >cur_network;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, 
("+rtw_free_assoc_resources\n"));
@@ -784,7 +784,7 @@ void rtw_free_assoc_resources_locked(struct adapter 
*adapter)
  */
 void rtw_indicate_connect(struct adapter *padapter)
 {
-   struct mlme_priv*pmlmepriv = >mlmepriv;
+   struct mlme_priv *pmlmepriv = >mlmepriv;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
@@ -810,7 +810,7 @@ void rtw_indicate_connect(struct adapter *padapter)
  */
 void rtw_indicate_disconnect(struct adapter *padapter)
 {
-   struct  mlme_priv *pmlmepriv = >mlmepriv;
+   struct mlme_priv *pmlmepriv = >mlmepriv;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("+%s\n", __func__));
 
@@ -965,12 +965,12 @@ static void rtw_joinbss_update_network(struct adapter 
*padapter, struct wlan_net
 void rtw_joinbss_event_prehandle(struct adapter *adapter, u8 *pbuf)
 {
struct sta_info *ptarget_sta = NULL, *pcur_sta = NULL;
-   struct  sta_priv *pstapriv = >stapriv;
+   struct sta_priv *pstapriv = >stapriv;
struct mlme_priv *pmlmepriv = >mlmepriv;
-   struct wlan_network *pnetwork   = (struct wlan_network *)pbuf;
+   struct wlan_network *pnetwork = (struct wlan_network *)pbuf;
struct wlan_network *cur_network = >cur_network;
-   struct wlan_network *pcur_wlan = NULL, *ptarget_wlan = NULL;
-   unsigned int

[PATCH 2/9] staging: rtl8188eu: remove unnecessary parentheses in rtw_mlme.c

2018-11-23 Thread Michael Straube

Remove unnecessary parentheses reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 120 --
 1 file changed, 63 insertions(+), 57 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index b6210d98ee2d..d5c22a028905 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -39,9 +39,9 @@ int rtw_init_mlme_priv(struct adapter *padapter)
pmlmepriv->cur_network.network.InfrastructureMode = 
Ndis802_11AutoUnknown;
pmlmepriv->scan_mode = SCAN_ACTIVE;/*  1: active, 0: pasive. Maybe 
someday we should rename this varable to "active_mode" (Jeff) */
 
-   spin_lock_init(&(pmlmepriv->lock));
-   _rtw_init_queue(&(pmlmepriv->free_bss_pool));
-   _rtw_init_queue(&(pmlmepriv->scanned_queue));
+   spin_lock_init(>lock);
+   _rtw_init_queue(>free_bss_pool);
+   _rtw_init_queue(>scanned_queue);
 
memset(>assoc_ssid, 0, sizeof(struct ndis_802_11_ssid));
 
@@ -56,9 +56,9 @@ int rtw_init_mlme_priv(struct adapter *padapter)
pnetwork = (struct wlan_network *)pbuf;
 
for (i = 0; i < MAX_BSS_CNT; i++) {
-   INIT_LIST_HEAD(&(pnetwork->list));
+   INIT_LIST_HEAD(>list);
 
-   list_add_tail(&(pnetwork->list), 
&(pmlmepriv->free_bss_pool.queue));
+   list_add_tail(>list, >free_bss_pool.queue);
 
pnetwork++;
}
@@ -137,7 +137,7 @@ static void _rtw_free_network(struct mlme_priv *pmlmepriv, 
struct wlan_network *
unsigned long curr_time;
u32 delta_time;
u32 lifetime = SCANQUEUE_LIFETIME;
-   struct __queue *free_queue = &(pmlmepriv->free_bss_pool);
+   struct __queue *free_queue = >free_bss_pool;
 
if (!pnetwork)
return;
@@ -154,21 +154,21 @@ static void _rtw_free_network(struct mlme_priv 
*pmlmepriv, struct wlan_network *
return;
}
spin_lock_bh(_queue->lock);
-   list_del_init(&(pnetwork->list));
-   list_add_tail(&(pnetwork->list), &(free_queue->queue));
+   list_del_init(>list);
+   list_add_tail(>list, _queue->queue);
spin_unlock_bh(_queue->lock);
 }
 
 void _rtw_free_network_nolock(struct   mlme_priv *pmlmepriv, struct 
wlan_network *pnetwork)
 {
-   struct __queue *free_queue = &(pmlmepriv->free_bss_pool);
+   struct __queue *free_queue = >free_bss_pool;
 
if (!pnetwork)
return;
if (pnetwork->fixed)
return;
-   list_del_init(&(pnetwork->list));
-   list_add_tail(&(pnetwork->list), get_list_head(free_queue));
+   list_del_init(>list);
+   list_add_tail(>list, get_list_head(free_queue));
 }
 
 /*
@@ -354,7 +354,8 @@ void update_network(struct wlan_bssid_ex *dst, struct 
wlan_bssid_ex *src,
rtw_hal_antdiv_rssi_compared(padapter, dst, src); /* this will update 
src.Rssi, need consider again */
 
/* The rule below is 1/5 for sample value, 4/5 for history value */
-   if (check_fwstate(>mlmepriv, _FW_LINKED) && 
is_same_network(&(padapter->mlmepriv.cur_network.network), src)) {
+   if (check_fwstate(>mlmepriv, _FW_LINKED) &&
+   is_same_network(>mlmepriv.cur_network.network, src)) {
/* Take the recvpriv's value for the connected AP*/
ss_final = padapter->recvpriv.signal_strength;
sq_final = padapter->recvpriv.signal_qual;
@@ -384,11 +385,11 @@ void update_network(struct wlan_bssid_ex *dst, struct 
wlan_bssid_ex *src,
 
 static void update_current_network(struct adapter *adapter, struct 
wlan_bssid_ex *pnetwork)
 {
-   struct  mlme_priv   *pmlmepriv = &(adapter->mlmepriv);
+   struct mlme_priv *pmlmepriv = >mlmepriv;
 
if (check_fwstate(pmlmepriv, _FW_LINKED) &&
is_same_network(>cur_network.network, pnetwork)) {
-   update_network(&(pmlmepriv->cur_network.network), pnetwork, 
adapter, true);
+   update_network(>cur_network.network, pnetwork, 
adapter, true);
rtw_update_protection(adapter, 
(pmlmepriv->cur_network.network.ies) + sizeof(struct ndis_802_11_fixed_ie),
  pmlmepriv->cur_network.network.ie_length);
}
@@ -401,8 +402,8 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
 {
struct list_head *plist, *phead;
u32 bssid_ex_sz;
-   struct mlme_priv*pmlmepriv = &(adapter->mlmepriv);
-   struct __queue *queue   = &(pmlmepriv->scanned_queue);
+   struct mlme_priv *pmlmepriv = >mlmepriv;
+   struct __queue *queue = >scanned_queue;
struct wlan_network *pnetwork = NULL;
struct wlan_network *oldest = NULL;
 
@@ -413,7 +414,7 @@ void rtw_update_scanned_network(struct adapter *adapter, 
struct wlan_bssid_ex *t
while (phead != plist) {

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-11-23 Thread Michal Suchánek

On Fri, 23 Nov 2018 12:13:58 +0100
David Hildenbrand  wrote:

> On 28.09.18 17:03, David Hildenbrand wrote:
> > How to/when to online hotplugged memory is hard to manage for
> > distributions because different memory types are to be treated differently.
> > Right now, we need complicated udev rules that e.g. check if we are
> > running on s390x, on a physical system or on a virtualized system. But
> > there is also sometimes the demand to really online memory immediately
> > while adding in the kernel and not to wait for user space to make a
> > decision. And on virtualized systems there might be different
> > requirements, depending on "how" the memory was added (and if it will
> > eventually get unplugged again - DIMM vs. paravirtualized mechanisms).
> > 
> > On the one hand, we have physical systems where we sometimes
> > want to be able to unplug memory again - e.g. a DIMM - so we have to online
> > it to the MOVABLE zone optionally. That decision is usually made in user
> > space.
> > 
> > On the other hand, we have memory that should never be onlined
> > automatically, only when asked for by an administrator. Such memory only
> > applies to virtualized environments like s390x, where the concept of
> > "standby" memory exists. Memory is detected and added during boot, so it
> > can be onlined when requested by the admininistrator or some tooling.
> > Only when onlining, memory will be allocated in the hypervisor.
> > 
> > But then, we also have paravirtualized devices (namely xen and hyper-v
> > balloons), that hotplug memory that will never ever be removed from a
> > system right now using offline_pages/remove_memory. If at all, this memory
> > is logically unplugged and handed back to the hypervisor via ballooning.
> > 
> > For paravirtualized devices it is relevant that memory is onlined as
> > quickly as possible after adding - and that it is added to the NORMAL
> > zone. Otherwise, it could happen that too much memory in a row is added
> > (but not onlined), resulting in out-of-memory conditions due to the
> > additional memory for "struct pages" and friends. MOVABLE zone as well
> > as delays might be very problematic and lead to crashes (e.g. zone
> > imbalance).
> > 
> > Therefore, introduce memory block types and online memory depending on
> > it when adding the memory. Expose the memory type to user space, so user
> > space handlers can start to process only "normal" memory. Other memory
> > block types can be ignored. One thing less to worry about in user space.
> >   
> 
> So I was looking into alternatives.
> 
> 1. Provide only "normal" and "standby" memory types to user space. This
> way user space can make smarter decisions about how to online memory.
> Not really sure if this is the right way to go.
> 
> 
> 2. Use device driver information (as mentioned by Michal S.).
> 
> The problem right now is that there are no drivers for memory block
> devices. The "memory" subsystem has no drivers, so the KOBJ_ADD uevent
> will not contain a "DRIVER" information and we ave no idea what kind of
> memory block device we hold in our hands.
> 
> $ udevadm info -q all -a /sys/devices/system/memory/memory0
> 
>   looking at device '/devices/system/memory/memory0':
> KERNEL=="memory0"
> SUBSYSTEM=="memory"
> DRIVER==""
> ATTR{online}=="1"
> ATTR{phys_device}=="0"
> ATTR{phys_index}==""
> ATTR{removable}=="0"
> ATTR{state}=="online"
> ATTR{valid_zones}=="none"
> 
> 
> If we would provide "fake" drivers for the memory block devices we want
> to treat in a special way in user space (e.g. standby memory on s390x),
> user space could use that information to make smarter decisions.
> 
> Adding such drivers might work. My suggestion would be to let ordinary
> DIMMs be without a driver for now and only special case standby memory
> and eventually paravirtualized memory devices (XEN and Hyper-V).
> 
> Any thoughts?

If we are going to fake the driver information we may as well add the
type attribute and be done with it.

I think the problem with the patch was more with the semantic than the
attribute itself.

What is normal, paravirtualized, and standby memory?

I can understand DIMM device, baloon device, or whatever mechanism for
adding memory you might have.

I can understand "memory designated as standby by the cluster
administrator".

However, DIMM vs baloon is orthogonal to standby and should not be
conflated into one property.

paravirtualized means nothing at all in relationship to memory type and
the desired online policy to me.

Lastly I would suggest if you add any property you add it to *all*
memory that is hotplugged. That way the userspace can detect if it can
rely on the information from your patch or not. Leaving some memory
untagged makes things needlessly vague.

Thanks

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

Re: [PATCH v2 4/8] xen/balloon: mark inflated pages PG_offline

2018-11-23 Thread Juergen Gross

On 22/11/2018 11:06, David Hildenbrand wrote:
> Mark inflated and never onlined pages PG_offline, to tell the world that
> the content is stale and should not be dumped.
> 
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Stefano Stabellini 
> Cc: Andrew Morton 
> Cc: Matthew Wilcox 
> Cc: Michal Hocko 
> Cc: "Michael S. Tsirkin" 
> Signed-off-by: David Hildenbrand 

Reviewed-by: Juergen Gross 


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

[PATCH v2 2/2] media: cedrus: Add HEVC/H.265 decoding support

2018-11-23 Thread Paul Kocialkowski

This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
both uni-directional and bi-directional prediction modes supported.

Field-coded (interlaced) pictures, custom quantization matrices and
10-bit output are not supported at this point.

Signed-off-by: Paul Kocialkowski 
---
 drivers/staging/media/sunxi/cedrus/Makefile   |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  22 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  18 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   9 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 543 ++
 .../staging/media/sunxi/cedrus/cedrus_hw.c|   4 +
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 290 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  10 +
 8 files changed, 896 insertions(+), 2 deletions(-)
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c

diff --git a/drivers/staging/media/sunxi/cedrus/Makefile 
b/drivers/staging/media/sunxi/cedrus/Makefile
index aaf141fc58b6..186cb6d01b67 100644
--- a/drivers/staging/media/sunxi/cedrus/Makefile
+++ b/drivers/staging/media/sunxi/cedrus/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
 
 sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
-cedrus_mpeg2.o cedrus_h264.o
+cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 923aa7bd57f4..e1e610dbe804 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -64,6 +64,24 @@ static const struct cedrus_control cedrus_controls[] = {
.codec  = CEDRUS_CODEC_H264,
.required   = true,
},
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_sps),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_pps),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_slice_params),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
 };
 
 #define CEDRUS_CONTROLS_COUNT  ARRAY_SIZE(cedrus_controls)
@@ -304,6 +322,7 @@ static int cedrus_probe(struct platform_device *pdev)
 
dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
+   dev->dec_ops[CEDRUS_CODEC_H265] = _dec_ops_h265;
 
mutex_init(>dev_mutex);
 
@@ -411,7 +430,8 @@ static const struct cedrus_variant sun8i_a33_cedrus_variant 
= {
 };
 
 static const struct cedrus_variant sun8i_h3_cedrus_variant = {
-   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
 };
 
 static const struct of_device_id cedrus_dt_match[] = {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index fe7e06267d92..1895108222c8 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -27,10 +27,12 @@
 #define CEDRUS_NAME"cedrus"
 
 #define CEDRUS_CAPABILITY_UNTILED  BIT(0)
+#define CEDRUS_CAPABILITY_H265_DEC BIT(1)
 
 enum cedrus_codec {
CEDRUS_CODEC_MPEG2,
CEDRUS_CODEC_H264,
+   CEDRUS_CODEC_H265,
CEDRUS_CODEC_LAST,
 };
 
@@ -65,6 +67,12 @@ struct cedrus_mpeg2_run {
const struct v4l2_ctrl_mpeg2_quantization   *quantization;
 };
 
+struct cedrus_h265_run {
+   const struct v4l2_ctrl_hevc_sps *sps;
+   const struct v4l2_ctrl_hevc_pps *pps;
+   const struct v4l2_ctrl_hevc_slice_params*slice_params;
+};
+
 struct cedrus_run {
struct vb2_v4l2_buffer  *src;
struct vb2_v4l2_buffer  *dst;
@@ -72,6 +80,7 @@ struct cedrus_run {
union {
struct cedrus_h264_run  h264;
struct cedrus_mpeg2_run mpeg2;
+   struct cedrus_h265_run  h265;
};
 };
 
@@ -108,6 +117,14 @@ struct cedrus_ctx {
void*pic_info_buf;
dma_addr_t  pic_info_buf_dma;
} h264;
+   struct {
+   void*mv_col_buf;
+   dma_addr_t  mv_col_buf_addr;
+   ssize_t mv_col_buf_size;
+   ssize_t mv_col_buf_unit_size;
+   void*neighbor_info_buf;
+

[PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

2018-11-23 Thread Paul Kocialkowski

This introduces the required definitions for HEVC decoding support with
stateless VPUs. The controls associated to the HEVC slice format provide
the required meta-data for decoding slices extracted from the bitstream.

This interface comes with the following limitations:
* No custom quantization matrices (scaling lists);
* Support for a single temporal layer only;
* No slice entry point offsets support;
* No conformance window support;
* No VUI parameters support;
* No support for SPS extensions: range, multilayer, 3d, scc, 4 bits;
* No support for PPS extensions: range, multilayer, 3d, scc, 4 bits.

Signed-off-by: Paul Kocialkowski 
---
 Documentation/media/uapi/v4l/biblio.rst   |   9 +
 .../media/uapi/v4l/extended-controls.rst  | 417 ++
 .../media/uapi/v4l/pixfmt-compressed.rst  |  15 +
 .../media/uapi/v4l/vidioc-queryctrl.rst   |  18 +
 .../media/videodev2.h.rst.exceptions  |   3 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  26 ++
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|   6 +
 include/uapi/linux/v4l2-controls.h| 155 +++
 include/uapi/linux/v4l2-controls.h.rej| 187 
 include/uapi/linux/videodev2.h|   7 +
 11 files changed, 657 insertions(+), 187 deletions(-)
 delete mode 100644 include/uapi/linux/v4l2-controls.h.rej

diff --git a/Documentation/media/uapi/v4l/biblio.rst 
b/Documentation/media/uapi/v4l/biblio.rst
index 73aeb7ce47d2..59a98feca3a1 100644
--- a/Documentation/media/uapi/v4l/biblio.rst
+++ b/Documentation/media/uapi/v4l/biblio.rst
@@ -124,6 +124,15 @@ ITU H.264
 
 :author:International Telecommunication Union (http://www.itu.ch)
 
+.. _hevc:
+
+ITU H.265/HEVC
+==
+
+:title: ITU-T Rec. H.265 | ISO/IEC 23008-2 "High Efficiency Video Coding"
+
+:author:International Telecommunication Union (http://www.itu.ch), 
International Organisation for Standardisation (http://www.iso.ch)
+
 .. _jfif:
 
 JFIF
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 87c0d151577f..906ff4f32634 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -2038,6 +2038,423 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``flags``
   -
 
+.. _v4l2-mpeg-hevc:
+
+``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
+Specifies the Sequence Parameter Set fields (as extracted from the
+bitstream) for the associated HEVC slice data.
+These bitstream parameters are defined according to :ref:`hevc`.
+Refer to the specification for the documentation of these fields.
+
+.. c:type:: v4l2_ctrl_hevc_sps
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_hevc_sps
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``chroma_format_idc``
+  -
+* - __u8
+  - ``separate_colour_plane_flag``
+  -
+* - __u16
+  - ``pic_width_in_luma_samples``
+  -
+* - __u16
+  - ``pic_height_in_luma_samples``
+  -
+* - __u8
+  - ``bit_depth_luma_minus8``
+  -
+* - __u8
+  - ``bit_depth_chroma_minus8``
+  -
+* - __u8
+  - ``log2_max_pic_order_cnt_lsb_minus4``
+  -
+* - __u8
+  - ``sps_max_dec_pic_buffering_minus1``
+  -
+* - __u8
+  - ``sps_max_num_reorder_pics``
+  -
+* - __u8
+  - ``sps_max_latency_increase_plus1``
+  -
+* - __u8
+  - ``log2_min_luma_coding_block_size_minus3``
+  -
+* - __u8
+  - ``log2_diff_max_min_luma_coding_block_size``
+  -
+* - __u8
+  - ``log2_min_luma_transform_block_size_minus2``
+  -
+* - __u8
+  - ``log2_diff_max_min_luma_transform_block_size``
+  -
+* - __u8
+  - ``max_transform_hierarchy_depth_inter``
+  -
+* - __u8
+  - ``max_transform_hierarchy_depth_intra``
+  -
+* - __u8
+  - ``scaling_list_enabled_flag``
+  -
+* - __u8
+  - ``amp_enabled_flag``
+  -
+* - __u8
+  - ``sample_adaptive_offset_enabled_flag``
+  -
+* - __u8
+  - ``pcm_enabled_flag``
+  -
+* - __u8
+  - ``pcm_sample_bit_depth_luma_minus1``
+  -
+* - __u8
+  - ``pcm_sample_bit_depth_chroma_minus1``
+  -
+* - __u8
+  - ``log2_min_pcm_luma_coding_block_size_minus3``
+  -
+* - __u8
+  - ``log2_diff_max_min_pcm_luma_coding_block_size``
+  -
+* - __u8
+  - ``pcm_loop_filter_disabled_flag``
+  -
+* - __u8
+  - ``num_short_term_ref_pic_sets``
+  -
+* - __u8
+  - ``long_term_ref_pics_present_flag``
+  -
+* - __u8
+  - ``num_long_term_ref_pics_sps``
+  -
+* - __u8
+  - ``sps_temporal_mvp_enabled_flag``
+  -
+* - __u8
+  - ``strong_intra_smoothing_enabled_flag``
+  -
+
+``V4L2_CID_MPEG_VIDEO_HEVC_PPS (struct)``
+Specifies the

[PATCH v2 0/2] HEVC/H.265 stateless support for V4L2 and Cedrus

2018-11-23 Thread Paul Kocialkowski

This introduces the required bits for supporting HEVC/H.265 both in the
V4L2 framework and the Cedrus VPU driver that concerns Allwinner
devices.

A specific pixel format is introduced for the HEVC slice format and
controls are provided to pass the bitstream metadata to the decoder.
Some bitstream extensions are knowingly not supported at this point.

Since this is the first proposal for stateless HEVC/H.265 support in
V4L2, reviews and comments about the controls definitions are
particularly welcome.

On the Cedrus side, the H.265 implementation covers frame pictures
with both uni-directional and bi-direction prediction modes (P/B
slices). Field pictures (interleaved), scaling lists and 10-bit output
are not supported at this point.

This series is based upon the following series:
* media: cedrus: Add H264 decoding support
* vb2/cedrus: add tag support

Changes since v1:
* Added a H.265 capability to whitelist relevant platforms;
* Switched over to tags instead of buffer indices in the DPB
* Declared variable in their reduced scope as suggested;
* Added the H.265/HEVC spec to the biblio;
* Used in-doc references to the spec and the required APIs;
* Removed debugging leftovers.

Cheers!

Paul Kocialkowski (2):
  media: v4l: Add definitions for the HEVC slice format and controls
  media: cedrus: Add HEVC/H.265 decoding support

 Documentation/media/uapi/v4l/biblio.rst   |   9 +
 .../media/uapi/v4l/extended-controls.rst  | 417 ++
 .../media/uapi/v4l/pixfmt-compressed.rst  |  15 +
 .../media/uapi/v4l/vidioc-queryctrl.rst   |  18 +
 .../media/videodev2.h.rst.exceptions  |   3 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  26 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 drivers/staging/media/sunxi/cedrus/Makefile   |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  22 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  18 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   9 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 543 ++
 .../staging/media/sunxi/cedrus/cedrus_hw.c|   4 +
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 290 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  10 +
 include/media/v4l2-ctrls.h|   6 +
 include/uapi/linux/v4l2-controls.h| 155 +
 include/uapi/linux/v4l2-controls.h.rej| 187 --
 include/uapi/linux/videodev2.h|   7 +
 19 files changed, 1553 insertions(+), 189 deletions(-)
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c
 delete mode 100644 include/uapi/linux/v4l2-controls.h.rej

-- 
2.19.1

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

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-11-23 Thread David Hildenbrand

On 28.09.18 17:03, David Hildenbrand wrote:
> How to/when to online hotplugged memory is hard to manage for
> distributions because different memory types are to be treated differently.
> Right now, we need complicated udev rules that e.g. check if we are
> running on s390x, on a physical system or on a virtualized system. But
> there is also sometimes the demand to really online memory immediately
> while adding in the kernel and not to wait for user space to make a
> decision. And on virtualized systems there might be different
> requirements, depending on "how" the memory was added (and if it will
> eventually get unplugged again - DIMM vs. paravirtualized mechanisms).
> 
> On the one hand, we have physical systems where we sometimes
> want to be able to unplug memory again - e.g. a DIMM - so we have to online
> it to the MOVABLE zone optionally. That decision is usually made in user
> space.
> 
> On the other hand, we have memory that should never be onlined
> automatically, only when asked for by an administrator. Such memory only
> applies to virtualized environments like s390x, where the concept of
> "standby" memory exists. Memory is detected and added during boot, so it
> can be onlined when requested by the admininistrator or some tooling.
> Only when onlining, memory will be allocated in the hypervisor.
> 
> But then, we also have paravirtualized devices (namely xen and hyper-v
> balloons), that hotplug memory that will never ever be removed from a
> system right now using offline_pages/remove_memory. If at all, this memory
> is logically unplugged and handed back to the hypervisor via ballooning.
> 
> For paravirtualized devices it is relevant that memory is onlined as
> quickly as possible after adding - and that it is added to the NORMAL
> zone. Otherwise, it could happen that too much memory in a row is added
> (but not onlined), resulting in out-of-memory conditions due to the
> additional memory for "struct pages" and friends. MOVABLE zone as well
> as delays might be very problematic and lead to crashes (e.g. zone
> imbalance).
> 
> Therefore, introduce memory block types and online memory depending on
> it when adding the memory. Expose the memory type to user space, so user
> space handlers can start to process only "normal" memory. Other memory
> block types can be ignored. One thing less to worry about in user space.
> 

So I was looking into alternatives.

1. Provide only "normal" and "standby" memory types to user space. This
way user space can make smarter decisions about how to online memory.
Not really sure if this is the right way to go.


2. Use device driver information (as mentioned by Michal S.).

The problem right now is that there are no drivers for memory block
devices. The "memory" subsystem has no drivers, so the KOBJ_ADD uevent
will not contain a "DRIVER" information and we ave no idea what kind of
memory block device we hold in our hands.

$ udevadm info -q all -a /sys/devices/system/memory/memory0

  looking at device '/devices/system/memory/memory0':
KERNEL=="memory0"
SUBSYSTEM=="memory"
DRIVER==""
ATTR{online}=="1"
ATTR{phys_device}=="0"
ATTR{phys_index}==""
ATTR{removable}=="0"
ATTR{state}=="online"
ATTR{valid_zones}=="none"


If we would provide "fake" drivers for the memory block devices we want
to treat in a special way in user space (e.g. standby memory on s390x),
user space could use that information to make smarter decisions.

Adding such drivers might work. My suggestion would be to let ordinary
DIMMs be without a driver for now and only special case standby memory
and eventually paravirtualized memory devices (XEN and Hyper-V).

Any thoughts?


-- 

Thanks,

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

Re: [PATCH 1/2] media: v4l: Add definitions for the HEVC slice format and controls

2018-11-23 Thread Paul Kocialkowski

Hi,

On Wed, 2018-10-10 at 17:33 +0900, Tomasz Figa wrote:
> Hi Paul,
> 
> On Tue, Aug 28, 2018 at 5:02 PM Paul Kocialkowski
>  wrote:
> > This introduces the required definitions for HEVC decoding support with
> > stateless VPUs. The controls associated to the HEVC slice format provide
> > the required meta-data for decoding slices extracted from the bitstream.
> > 
> 
> Sorry for being late to the party. Please see my comments inline. Only
> high level, because I don't know too much about HEVC.
> 
> [snip]
> > +``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
> > +Specifies the Sequence Parameter Set fields (as extracted from the
> > +bitstream) for the associated HEVC slice data.
> > +The bitstream parameters are defined according to the ISO/IEC 23008-2 
> > and
> > +ITU-T Rec. H.265 specifications.
> > +
> > +.. c:type:: v4l2_ctrl_hevc_sps
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table:: struct v4l2_ctrl_hevc_sps
> > +:header-rows:  0
> > +:stub-columns: 0
> > +:widths:   1 1 2
> > +
> > +* - __u8
> > +  - ``chroma_format_idc``
> > +  - Syntax description inherited from the specification.
> 
> I wonder if it wouldn't make sense to instead document this in C code
> using kernel-doc and then have the kernel-doc included in the sphinx
> doc. It seems to be possible, according to
> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html .
> 
> Such approach would have the advantage of the person looking through C
> cross reference being able to actually see the documentation of the
> struct in question and also making it easier to ensure the relevant C
> code and documentation are in sync. (Although this is UAPI so it would
> be unlikely to change too often or at all.)

I have somewhat mixed feelings about this. I believe we should be
keeping the video codec control structures as close as we can to the
codec specs (and in the case of H.265, most of the fields are directly
inherited from the spec). So for most of them, the documentation
wouldn't be in the kernel docs but in the spec itself. From that
perspective, it doesn't really help much to move the documentation in
the headers.

> [snip]
> > +``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS (struct)``
> > +Specifies various slice-specific parameters, especially from the NAL 
> > unit
> > +header, general slice segment header and weighted prediction parameter
> > +parts of the bitstream.
> > +The bitstream parameters are defined according to the ISO/IEC 23008-2 
> > and
> > +ITU-T Rec. H.265 specifications.
> 
> In the Chromium H.264 controls, we define this as an array control, so
> that we can include multiple slices in one buffer and each entry of
> the array has an offset field pointing to the part of the buffer that
> contains corresponding slice data. I've mentioned this in the
> discussion on Alex's stateless decoder interface documentation, so
> let's keep the discussion there, though.

Yes definitely. Out current proposals (for H.264 and H.265) still
require "as many macroblocks as needed for a full frame", but we should
definitely move away from that as discussed in the thread you
mentionned. I think this is something we should aim for before declaring
the API as stable.

> [snip]
> > @@ -1696,6 +1708,11 @@ static int std_validate(const struct v4l2_ctrl 
> > *ctrl, u32 idx,
> > case V4L2_CTRL_TYPE_H264_DECODE_PARAMS:
> > return 0;
> > 
> > +   case V4L2_CTRL_TYPE_HEVC_SPS:
> > +   case V4L2_CTRL_TYPE_HEVC_PPS:
> > +   case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> > +   return 0;
> > +
> 
> I wonder to what extent we should be validating this. I can see 3 options:
> 1) Defer validation to drivers completely. - Potentially error prone
> and leading to a lot of code duplication?
> 2) Validate completely. - Might need solving some interesting
> problems, e.g. validating reference frame indices in DPB against
> current state of respective VB2 queue...
> 3) Validate only what we can easily do, defer more complicated
> validation to the drivers. - Potentially a good middle ground?

I definitely agree with you that option 1 is not really desirable, for
the reasons you mentionned.

I would tend to back option 3 with the following suggestion: we should
validate controls for "syntax" (that is, checking that the bitstream
fields take values permitted by the spec) when they are submitted and
leave it up to the driver to deal with requirements on other frames
(validity of the DPB). I don't think we can validate the availability of
reference frames at control submission time anyway since it would be
valid to queue and set controls for frames in reverse decoding order.

What do you think?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: This is a digitally signed message part
___
devel mailing

Re: [PATCH 05/10] staging: erofs: add a full barrier in erofs_workgroup_unfreeze

2018-11-23 Thread Gao Xiang

Hi Andrea,

On 2018/11/23 17:51, Andrea Parri wrote:
> Correct.  This is informally documented in Documentation/atomic_t.txt
> and formalized within tools/memory-model/.
> 
> 
>> I don't know whether my understanding is correct, If I am wrong..please 
>> correct me, or
>> I need to add more detailed code comments to explain in the code?
> Yes, please; please review the above points (including 1. and 3.) and
> try to address them with inline comments.  Maybe (if that matches the
> *behavior*/guarantee you have in mind...) something like:
> 
> [in erofs_workgroup_unfreeze()]
> 
>   /*
>* Orders the store/load to/from [???] and the store to
>* ->refcount performed by the atomic_set() below.
>*
>* Matches the atomic_cmpxchg() in erofs_workgroup_get().
>*
>* Guarantees that if a successful atomic_cmpxchg() reads
>* the value stored by the atomic_set() then [???].
>*/
>   smp_mb();
>   atomic_set(>refcount, v);
> 
> 
> [in erofs_workgroup_get()]
> 
>   /*
>* Orders the load from ->refcount performed by the
>* atomic_cmpxchg() below and the store/load [???].
>*
>* See the comment for the smp_mb() in
>* erofs_workgroup_unfreeze().
>*/
>   if (unlikely(atomic_cmpxchg(>refcount, o, o + 1) != o))
>   goto repeat;
> 

OK, I will add these comments in the next version patchset, will be sent later.
Thanks for your suggestion. :)

Thanks,
Gao Xiang

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

Re: [PATCH 05/10] staging: erofs: add a full barrier in erofs_workgroup_unfreeze

2018-11-23 Thread Andrea Parri

On Fri, Nov 23, 2018 at 10:51:33AM +0800, Gao Xiang wrote:
> Hi Andrea,
> 
> On 2018/11/23 2:50, Andrea Parri wrote:
> > On Thu, Nov 22, 2018 at 06:56:32PM +0800, Gao Xiang wrote:
> >> Hi Greg,
> >>
> >> On 2018/11/22 18:22, Greg Kroah-Hartman wrote:
> >>> Please document this memory barrier.  It does not make much sense to
> >>> me...
> >>
> >> Because we need to make the other observers noticing the latest values 
> >> modified
> >> in this locking period before unfreezing the whole workgroup, one way is 
> >> to use
> >> a memory barrier and the other way is to use ACQUIRE and RELEASE. we 
> >> selected
> >> the first one.
> >>
> >> Hmmm...ok, I will add a simple message to explain this, but I think that is
> >> plain enough for a lock...
> > 
> > Sympathizing with Greg's request, let me add some specific suggestions:
> > 
> >   1. It wouldn't hurt to indicate a pair of memory accesses which are
> >  intended to be "ordered" by the memory barrier in question (yes,
> >  this pair might not be unique, but you should be able to provide
> >  an example).
> > 
> >   2. Memory barriers always come matched by other memory barriers, or
> >  dependencies (it really does not make sense to talk about a full
> >  barrier "in isolation"): please also indicate (an instance of) a
> >  matching barrier or the matching barriers.
> > 
> >   3. How do the hardware threads communicate?  In the acquire/release
> >  pattern you mentioned above, the load-acquire *reads from* a/the
> >  previous store-release, a memory access that follows the acquire
> >  somehow communicate with a memory access preceding the release...
> > 
> >   4. It is a good practice to include the above information within an
> >  (inline) comment accompanying the added memory barrier (in fact,
> >  IIRC, checkpatch.pl gives you a "memory barrier without comment"
> >  warning when you omit to do so); not just in the commit message.
> > 
> > Hope this helps.  Please let me know if something I wrote is unclear,
> 
> Thanks for taking time on the detailed explanation. I think it is helpful for 
> me. :)
> And you are right, barriers should be in pairs, and I think I need to explain 
> more:
> 
> 255 static inline bool erofs_workgroup_get(struct erofs_workgroup *grp, int 
> *ocnt)
> 256 {
> 257 int o;
> 258
> 259 repeat:
> 260 o = erofs_wait_on_workgroup_freezed(grp);
> 261
> 262 if (unlikely(o <= 0))
> 263 return -1;
> 264
> 265 if (unlikely(atomic_cmpxchg(>refcount, o, o + 1) != o)) <- *
> 266 goto repeat;
> imply a memory barrier here
> 267
> 268 *ocnt = o;
> 269 return 0;
> 270 }
> 
> I think atomic_cmpxchg implies a memory barrier semantics when the value 
> comparison (*) succeeds...

Correct.  This is informally documented in Documentation/atomic_t.txt
and formalized within tools/memory-model/.


> 
> I don't know whether my understanding is correct, If I am wrong..please 
> correct me, or
> I need to add more detailed code comments to explain in the code?

Yes, please; please review the above points (including 1. and 3.) and
try to address them with inline comments.  Maybe (if that matches the
*behavior*/guarantee you have in mind...) something like:

[in erofs_workgroup_unfreeze()]

/*
 * Orders the store/load to/from [???] and the store to
 * ->refcount performed by the atomic_set() below.
 *
 * Matches the atomic_cmpxchg() in erofs_workgroup_get().
 *
 * Guarantees that if a successful atomic_cmpxchg() reads
 * the value stored by the atomic_set() then [???].
 */
smp_mb();
atomic_set(>refcount, v);


[in erofs_workgroup_get()]

/*
 * Orders the load from ->refcount performed by the
 * atomic_cmpxchg() below and the store/load [???].
 *
 * See the comment for the smp_mb() in
 * erofs_workgroup_unfreeze().
 */
if (unlikely(atomic_cmpxchg(>refcount, o, o + 1) != o))
goto repeat;

Thanks,
  Andrea


> 
> Thanks,
> Gao Xiang
> 
> 
> > 
> >   Andrea
> > 
> > 
> >>
> >> Thanks,
> >> Gao Xiang
> >>
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 00/33] staging: mt7621-pci: Parse ports info from DT and other minor cleanups

Re: [PATCH v6 14/33] staging: mt7621-dts: add sysctl registers base address to pcie

Re: [PATCH net-next 00/12] switchdev: Convert switchdev_port_obj_{add,del}() to notifiers

Re: [PATCH] staging: iio: ad5933: finalized device-tree support

[PATCH v3 7/7] staging:iio:ad2s90: Move out of staging

[PATCH v3 2/7] staging:iio:ad2s90: Remove spi setup that should be done via dt

[PATCH v3 6/7] staging:iio:ad2s90: Add comment to device state mutex

[PATCH v3 4/7] dt-bindings:iio:resolver: Add docs for ad2s90

[PATCH v3 5/7] staging:iio:ad2s90: Replace license text w/ SPDX identifier

[PATCH v3 3/7] staging:iio:ad2s90: Add max frequency check at probe

[PATCH v3 1/7] staging:iio:ad2s90: Add device tree support

[PATCH v3 0/7] staging:iio:ad2s90: Add dt support and move out of staging

Re: [PATCH v6 00/33] staging: mt7621-pci: Parse ports info from DT and other minor cleanups

[PATCH] staging: iio: ad5933: finalized device-tree support

Re: [PATCH v6 14/33] staging: mt7621-dts: add sysctl registers base address to pcie

Re: [PATCH v6 04/33] staging: mt7621-pci: factor out 'mt7621_pcie_enable_port' function

[PATCH 1/9] staging: rtl8188eu: cleanup remaining comparsions to true

[PATCH 8/9] staging: rtl8188eu: correct indentation

[PATCH 3/9] staging: rtl8188eu: use func in rtw_mlme.c

[PATCH 4/9] staging: rtl8188eu: remove rtw_android_set_block()

[PATCH 6/9] staging: rtl8188eu: refactor if else statement

[PATCH 9/9] staging: rtl8188eu: cleanup lines over 80 characters

[PATCH 7/9] staging: rtl8188eu: remove return from void function

[PATCH 5/9] staging: rtl8188eu: cleanup declarations in rtw_mlme.c

[PATCH 2/9] staging: rtl8188eu: remove unnecessary parentheses in rtw_mlme.c

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

Re: [PATCH v2 4/8] xen/balloon: mark inflated pages PG_offline

[PATCH v2 2/2] media: cedrus: Add HEVC/H.265 decoding support

[PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[PATCH v2 0/2] HEVC/H.265 stateless support for V4L2 and Cedrus

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

Re: [PATCH 1/2] media: v4l: Add definitions for the HEVC slice format and controls

Re: [PATCH 05/10] staging: erofs: add a full barrier in erofs_workgroup_unfreeze

Re: [PATCH 05/10] staging: erofs: add a full barrier in erofs_workgroup_unfreeze

34 matches

Site Navigation

Mail list logo

Footer information