[PATCH] staging: mt7621-mmc: Add blank line after declaration

2018-10-08 Thread Jaakko Tyynismaa
Add blank line after declaration.
Reported by checkpatch.

Signed-off-by: Jaakko Tyynismaa 
---
 drivers/staging/mt7621-mmc/sd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 4a216b9e6d91..c872ebb802f4 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -2041,6 +2041,7 @@ static int msdc_drv_remove(struct platform_device *pdev)
 static void msdc_drv_pm(struct platform_device *pdev, pm_message_t state)
 {
struct mmc_host *mmc = platform_get_drvdata(pdev);
+
if (mmc) {
struct msdc_host *host = mmc_priv(mmc);
msdc_pm(state, (void *)host);
-- 
2.17.1

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


Re: [PATCH 03/21] media: davinci_vpfe: fix vpfe_ipipe_init() error handling

2018-10-08 Thread Joel Fernandes
On Fri, Apr 06, 2018 at 10:23:04AM -0400, Mauro Carvalho Chehab wrote:
> As warned:
>   drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init() 
> error: we previously assumed 'res' could be null (see line 1797)
> 
> There's something wrong at vpfe_ipipe_init():
> 
> 1) it caches the resourse_size() from from the first region
>and reuses to the second region;
> 
> 2) the "res" var is overriden 3 times;
> 
> 3) at free logic, it assumes that "res->start" is not
>overriden by platform_get_resource(pdev, IORESOURCE_MEM, 6),
>but that's not true, as it can even be NULL there.
> 
> This patch fixes the above issues by:
> 
> a) store the resources used by release_mem_region() on
>a separate var;
> 
> b) stop caching resource_size(), using the function where
>needed.
> 
> Signed-off-by: Mauro Carvalho Chehab 

I ran coccicheck on a 4.14.74 stable kernel and noticed that 'res' can be
NULL in vpfe_ipipe_init. It looks like this patch is not included in the 4.14
stable series. Can this patch be applied? I applied it myself and it applies
cleanly, but I have no way to test it.

That 'res->start' error_release could end up a NULL pointer deref.

 - Joel

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


Hallo mein Geliebter bitte ich brauche deine Assistentin

2018-10-08 Thread Gertrude Robert


Hallo mein Geliebter.

Ich grüße dich mit dem Namen unseres Herrn Jesus Christus. Es ist wahr, dass 
dieser Brief als Überraschung zu dir kommen kann. Dennoch bitte ich Sie 
demütig, mir Ihre Aufmerksamkeit zu schenken und mich gut zu hören. Mein Name 
ist Frau Gertrude aus den Vereinigten Staaten von Amerika. Ich bin verheiratet 
mit Herrn Robert Hermann, der im Jahr 2002 mit unserer Botschaft in Deutschland 
gearbeitet hat und auch für 16 Jahre in einer Botschaft in London gearbeitet 
hat, bevor er starb.

Wir waren 25 Jahre ohne Kind verheiratet, bevor er nach kurzer Krankheit starb. 
Seit seinem Tod entschied ich mich aufgrund meines religiösen Glaubens nicht 
wieder zu heiraten. Als mein verstorbener Mann noch am Leben war, hinterlegte 
er die Summe von $ 10.500.000,00 (Zehn Millionen Fünfhunderttausend US-Dollar) 
bei einer Bank hier in Amerika. Zurzeit befindet sich dieses Geld noch in der 
Obhut der Bank. Kürzlich sagte mir mein Doktor, dass ich wegen meiner 
Krebserkrankung für die nächsten vier Monate nicht durchhalten würde.

Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, dieses Geld an 
Kirchen, Organisationen oder gute Menschen zu spenden, die dieses Geld nutzen 
werden, so wie ich es hier unterrichten werde.

Ich möchte, dass Sie dieses Geld für Kirchen, Wohltätigkeitsorganisationen, 
Waisenhäuser, Witwen und andere Bedürftige verwenden. Ich habe diese 
Entscheidung getroffen, weil ich kein Kind habe, das dieses Geld erbt. Außerdem 
sind die Verwandten meines Mannes mir nicht nahe, da ich ein Krebsproblem habe 
und es ihr Wunsch war, mich tot zu sehen, um seinen Reichtum zu erben, da wir 
kein Kind haben. Diese Leute sind dieses Erbe nicht wert. Aus diesem Grund 
nehme ich die Entscheidung, dich zu kontaktieren und spende diesen Fond an 
dich, damit du ihn für die Wohltätigkeitsarbeit verwenden kannst.
Ich möchte, dass Sie 30% des Gesamtbetrags für sich selbst übernehmen.
Wenn Sie sicher sind, dass Sie diesen Fonds in Übereinstimmung mit den 
Anweisungen verwenden,

Sobald ich Ihre Antwort erhalten habe, werde ich Ihnen den Kontakt der Bank 
hier in den Vereinigten Staaten von Amerika geben, wo dieses Geld hinterlegt 
ist. Ich werde der Bank auch ein Bewilligungsschreiben ausstellen, das Ihnen 
den gegenwärtigen Begünstigten dieses Geldes beweisen wird. Ich möchte auch, 
dass du mich immer in deine Gebete bringst.

Jede Verzögerung in Ihrer Antwort kann mir Raum geben, nach einem anderen guten 
Menschen zu diesem Zweck zu suchen. Bitte versichern Sie mir, dass Sie sich wie 
oben beschrieben verhalten werden.

Danke und verbleibe gesegnet.

Deine Schwester im Herrn,

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


Hallo mein Geliebter bitte ich brauche deine Assistentin

2018-10-08 Thread Gertrude Robert


Hallo mein Geliebter.

Ich grüße dich mit dem Namen unseres Herrn Jesus Christus. Es ist wahr, dass 
dieser Brief als Überraschung zu dir kommen kann. Dennoch bitte ich Sie 
demütig, mir Ihre Aufmerksamkeit zu schenken und mich gut zu hören. Mein Name 
ist Frau Gertrude aus den Vereinigten Staaten von Amerika. Ich bin verheiratet 
mit Herrn Robert Hermann, der im Jahr 2002 mit unserer Botschaft in Deutschland 
gearbeitet hat und auch für 16 Jahre in einer Botschaft in London gearbeitet 
hat, bevor er starb.

Wir waren 25 Jahre ohne Kind verheiratet, bevor er nach kurzer Krankheit starb. 
Seit seinem Tod entschied ich mich aufgrund meines religiösen Glaubens nicht 
wieder zu heiraten. Als mein verstorbener Mann noch am Leben war, hinterlegte 
er die Summe von $ 10.500.000,00 (Zehn Millionen Fünfhunderttausend US-Dollar) 
bei einer Bank hier in Amerika. Zurzeit befindet sich dieses Geld noch in der 
Obhut der Bank. Kürzlich sagte mir mein Doktor, dass ich wegen meiner 
Krebserkrankung für die nächsten vier Monate nicht durchhalten würde.

Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, dieses Geld an 
Kirchen, Organisationen oder gute Menschen zu spenden, die dieses Geld nutzen 
werden, so wie ich es hier unterrichten werde.

Ich möchte, dass Sie dieses Geld für Kirchen, Wohltätigkeitsorganisationen, 
Waisenhäuser, Witwen und andere Bedürftige verwenden. Ich habe diese 
Entscheidung getroffen, weil ich kein Kind habe, das dieses Geld erbt. Außerdem 
sind die Verwandten meines Mannes mir nicht nahe, da ich ein Krebsproblem habe 
und es ihr Wunsch war, mich tot zu sehen, um seinen Reichtum zu erben, da wir 
kein Kind haben. Diese Leute sind dieses Erbe nicht wert. Aus diesem Grund 
nehme ich die Entscheidung, dich zu kontaktieren und spende diesen Fond an 
dich, damit du ihn für die Wohltätigkeitsarbeit verwenden kannst.
Ich möchte, dass Sie 30% des Gesamtbetrags für sich selbst übernehmen.
Wenn Sie sicher sind, dass Sie diesen Fonds in Übereinstimmung mit den 
Anweisungen verwenden,

Sobald ich Ihre Antwort erhalten habe, werde ich Ihnen den Kontakt der Bank 
hier in den Vereinigten Staaten von Amerika geben, wo dieses Geld hinterlegt 
ist. Ich werde der Bank auch ein Bewilligungsschreiben ausstellen, das Ihnen 
den gegenwärtigen Begünstigten dieses Geldes beweisen wird. Ich möchte auch, 
dass du mich immer in deine Gebete bringst.

Jede Verzögerung in Ihrer Antwort kann mir Raum geben, nach einem anderen guten 
Menschen zu diesem Zweck zu suchen. Bitte versichern Sie mir, dass Sie sich wie 
oben beschrieben verhalten werden.

Danke und verbleibe gesegnet.

Deine Schwester im Herrn,

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


Re: [PATCH v4 10/11] media: imx: Allow interweave with top/bottom lines swapped

2018-10-08 Thread Steve Longerbeam

Hi Philipp,


On 10/05/2018 03:43 AM, Philipp Zabel wrote:

Hi Steve,

On Thu, 2018-10-04 at 11:54 -0700, Steve Longerbeam wrote:

Allow sequential->interlaced interweaving but with top/bottom
lines swapped to the output buffer.

This can be accomplished by adding one line length to IDMAC output
channel address, with a negative line length for the interlace offset.

This is to allow the seq-bt -> interlaced-bt transformation, where
bottom lines are still dominant (older in time) but with top lines
first in the interweaved output buffer.

With this support, the CSI can now allow seq-bt at its source pads,
e.g. the following transformations are allowed in CSI from sink to
source:

seq-tb -> seq-bt
seq-bt -> seq-bt
alternate -> seq-bt

Suggested-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/imx-ic-prpencvf.c | 17 +++-
  drivers/staging/media/imx/imx-media-csi.c   | 46 +
  2 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index cf76b0432371..1499b0c62d74 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -106,6 +106,8 @@ struct prp_priv {
u32 frame_sequence; /* frame sequence counter */
bool last_eof;  /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
+   u32 interweave_offset; /* interweave line offset to swap
+ top/bottom lines */

We have to store this instead of using vdev->fmt.fmt.bytesperline
because this potentially is the pre-rotation stride instead?


interweave_offset was used by prp_vb2_buf_done() below, but in fact
that function is passed the non-rotation IDMAC channel (priv->out_ch)
_only_ if rotation is not enabled, so it is actually safe to use
vdev->fmt.fmt.bytesperline for the interweave offset in
prp_vb2_buf_done().

So I've gotten rid of interweave_offset in both imx-ic-prpencvf.c and
imx-media-csi.c, and replaced with a boolean interweave_swap as you
suggested. I agree it is much cleaner.
  



diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 679295da5dde..592f7d6edec1 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -114,6 +114,8 @@ struct csi_priv {
u32 frame_sequence; /* frame sequence counter */
bool last_eof;   /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
+   u32 interweave_offset; /* interweave line offset to swap
+ top/bottom lines */

This doesn't seem necessary. Since there is no rotation here, the offset
is just vdev->fmt.fmt.pix.bytesperline if interweave_swap is enabled.
Maybe turn this into a bool interweave_swap?


Agreed.




struct completion last_eof_comp;
  };
  
@@ -286,7 +288,8 @@ static void csi_vb2_buf_done(struct csi_priv *priv)

if (ipu_idmac_buffer_is_ready(priv->idmac_ch, priv->ipu_buf_num))
ipu_idmac_clear_buffer(priv->idmac_ch, priv->ipu_buf_num);
  
-	ipu_cpmem_set_buffer(priv->idmac_ch, priv->ipu_buf_num, phys);

+   ipu_cpmem_set_buffer(priv->idmac_ch, priv->ipu_buf_num,
+phys + priv->interweave_offset);
  }
  
  static irqreturn_t csi_idmac_eof_interrupt(int irq, void *dev_id)

@@ -396,10 +399,10 @@ static void csi_idmac_unsetup_vb2_buf(struct csi_priv 
*priv,
  static int csi_idmac_setup_channel(struct csi_priv *priv)
  {
struct imx_media_video_dev *vdev = priv->vdev;
+   bool passthrough, interweave, interweave_swap;
const struct imx_media_pixfmt *incc;
struct v4l2_mbus_framefmt *infmt;
struct v4l2_mbus_framefmt *outfmt;
-   bool passthrough, interweave;
struct ipu_image image;
u32 passthrough_bits;
u32 passthrough_cycles;
@@ -433,6 +436,8 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
 */
interweave = V4L2_FIELD_IS_INTERLACED(image.pix.field) &&
V4L2_FIELD_IS_SEQUENTIAL(outfmt->field);
+   interweave_swap = interweave &&
+   image.pix.field == V4L2_FIELD_INTERLACED_BT;

Although this could just as well be recalculated in csi_vb2_buf_done.


In the future yes, when we add support for alternate mode (I assume
that's what you are getting at?).



Apart from that,

Reviewed-by: Philipp Zabel 


Thanks.

Steve

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


Re: [PATCH v4 03/11] gpu: ipu-v3: Add planar support to interlaced scan

2018-10-08 Thread Steve Longerbeam




On 10/05/2018 02:48 AM, Philipp Zabel wrote:

On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:

To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be doubled, since a single chroma line
is shared by two luma lines.

Signed-off-by: Steve Longerbeam 
---
  drivers/gpu/ipu-v3/ipu-cpmem.c  | 26 +++--
  drivers/staging/media/imx/imx-ic-prpencvf.c |  3 ++-
  drivers/staging/media/imx/imx-media-csi.c   |  3 ++-
  include/video/imx-ipu-v3.h  |  3 ++-
  4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index a9d2501500a1..d41df8034c5b 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -273,9 +273,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 
u_off, u32 v_off)
  }
  EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
  
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)

+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+  u32 pixelformat)
  {
-   u32 ilo, sly;
+   u32 ilo, sly, sluv;
  
  	if (stride < 0) {

stride = -stride;
@@ -286,9 +287,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, 
int stride)
  
  	sly = (stride * 2) - 1;
  
+	switch (pixelformat) {

+   case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
+   sluv = stride / 2 - 1;
+   break;
+   case V4L2_PIX_FMT_NV12:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_YUV422P:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_NV16:
+   sluv = stride * 2 - 1;
+   break;
+   default:
+   sluv = 0;
+   break;
+   }
+
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
+   if (sluv)
+   ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
  };
  EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);

[...]

Reviewed-by: Philipp Zabel 

and

Acked-by: Philipp Zabel 

to be merged with the rest of the series via the media tree. I'll take
care not to introduce nontrivial conflicts in imx-drm.


Ok thanks.

Hans, for v5 I will just include the two IPU patches as before. As Philipp
stated, he is OK with merging them to the media tree (after his ack of
course), along with the rest of the patches in this series.

Steve


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


[PATCH v3] staging: iio: adt7316: fix parenthesis alignment

2018-10-08 Thread Renato Lui Geh

This patch fixes most "Alignment should match open parenthesis" check
warnings found by checkpatch.pl in the addac/adt7316 driver.

Signed-off-by: Renato Lui Geh 
---
drivers/staging/iio/addac/adt7316.c | 462 ++--
drivers/staging/iio/addac/adt7316.h |   2 +-
2 files changed, 233 insertions(+), 231 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index 3f22d1088713..2f8a122f475d 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -217,8 +217,8 @@ struct adt7316_limit_regs {
};

static ssize_t adt7316_show_enabled(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+   struct device_attribute *attr,
+   char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -227,7 +227,7 @@ static ssize_t adt7316_show_enabled(struct device *dev,
}

static ssize_t _adt7316_store_enabled(struct adt7316_chip_info *chip,
-   int enable)
+ int enable)
{
u8 config1;
int ret;
@@ -247,9 +247,9 @@ static ssize_t _adt7316_store_enabled(struct 
adt7316_chip_info *chip,
}

static ssize_t adt7316_store_enabled(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+struct device_attribute *attr,
+const char *buf,
+size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -272,8 +272,8 @@ static IIO_DEVICE_ATTR(enabled, 0644,
0);

static ssize_t adt7316_show_select_ex_temp(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+  struct device_attribute *attr,
+  char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -285,9 +285,9 @@ static ssize_t adt7316_show_select_ex_temp(struct device 
*dev,
}

static ssize_t adt7316_store_select_ex_temp(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+   struct device_attribute *attr,
+   const char *buf,
+   size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -316,8 +316,8 @@ static IIO_DEVICE_ATTR(select_ex_temp, 0644,
0);

static ssize_t adt7316_show_mode(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+struct device_attribute *attr,
+char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -329,9 +329,9 @@ static ssize_t adt7316_show_mode(struct device *dev,
}

static ssize_t adt7316_store_mode(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -357,8 +357,8 @@ static IIO_DEVICE_ATTR(mode, 0644,
0);

static ssize_t adt7316_show_all_modes(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+ struct device_attribute *attr,
+ char *buf)
{
return sprintf(buf, "single_channel\nround_robin\n");
}
@@ -366,8 +366,8 @@ static ssize_t adt7316_show_all_modes(struct device *dev,
static IIO_DEVICE_ATTR(all_modes, 0444, adt7316_show_all_modes, NULL, 0);

static ssize_t adt7316_show_ad_channel(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+  struct device_attribute *attr,
+  char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -382,7 +382,7 @@ static ssize_t adt7316_show_ad_channel(struct device *dev,
return sprintf(buf, "1 - Internal Temperature\n");
case ADT7316_AD_SINGLE_CH_EX:
if (((chip->id & ID_FAMILY_MASK) == ID_ADT75XX) &&
-   (chip->config1 & 

Re: [PATCH v2] staging: iio: adt7316: fix parenthesis alignment

2018-10-08 Thread Fabio Estevam
Hi Renato,

On Mon, Oct 8, 2018 at 7:02 PM Renato Lui Geh  wrote:
>
> This patch fixes most "Alignment should match open parenthesis" check
> warnings found by checkpatch.pl in the addac/adt7316 driver.
> ---

You missed your Signed-off-by tag, which is also reported by checkpatch.pl :-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2] staging: iio: adt7316: fix parenthesis alignment

2018-10-08 Thread Renato Lui Geh

This patch fixes most "Alignment should match open parenthesis" check
warnings found by checkpatch.pl in the addac/adt7316 driver.
---
drivers/staging/iio/addac/adt7316.c | 462 ++--
drivers/staging/iio/addac/adt7316.h |   2 +-
2 files changed, 233 insertions(+), 231 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index 3f22d1088713..2f8a122f475d 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -217,8 +217,8 @@ struct adt7316_limit_regs {
};

static ssize_t adt7316_show_enabled(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+   struct device_attribute *attr,
+   char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -227,7 +227,7 @@ static ssize_t adt7316_show_enabled(struct device *dev,
}

static ssize_t _adt7316_store_enabled(struct adt7316_chip_info *chip,
-   int enable)
+ int enable)
{
u8 config1;
int ret;
@@ -247,9 +247,9 @@ static ssize_t _adt7316_store_enabled(struct 
adt7316_chip_info *chip,
}

static ssize_t adt7316_store_enabled(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+struct device_attribute *attr,
+const char *buf,
+size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -272,8 +272,8 @@ static IIO_DEVICE_ATTR(enabled, 0644,
0);

static ssize_t adt7316_show_select_ex_temp(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+  struct device_attribute *attr,
+  char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -285,9 +285,9 @@ static ssize_t adt7316_show_select_ex_temp(struct device 
*dev,
}

static ssize_t adt7316_store_select_ex_temp(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+   struct device_attribute *attr,
+   const char *buf,
+   size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -316,8 +316,8 @@ static IIO_DEVICE_ATTR(select_ex_temp, 0644,
0);

static ssize_t adt7316_show_mode(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+struct device_attribute *attr,
+char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -329,9 +329,9 @@ static ssize_t adt7316_show_mode(struct device *dev,
}

static ssize_t adt7316_store_mode(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t len)
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -357,8 +357,8 @@ static IIO_DEVICE_ATTR(mode, 0644,
0);

static ssize_t adt7316_show_all_modes(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+ struct device_attribute *attr,
+ char *buf)
{
return sprintf(buf, "single_channel\nround_robin\n");
}
@@ -366,8 +366,8 @@ static ssize_t adt7316_show_all_modes(struct device *dev,
static IIO_DEVICE_ATTR(all_modes, 0444, adt7316_show_all_modes, NULL, 0);

static ssize_t adt7316_show_ad_channel(struct device *dev,
-   struct device_attribute *attr,
-   char *buf)
+  struct device_attribute *attr,
+  char *buf)
{
struct iio_dev *dev_info = dev_to_iio_dev(dev);
struct adt7316_chip_info *chip = iio_priv(dev_info);
@@ -382,7 +382,7 @@ static ssize_t adt7316_show_ad_channel(struct device *dev,
return sprintf(buf, "1 - Internal Temperature\n");
case ADT7316_AD_SINGLE_CH_EX:
if (((chip->id & ID_FAMILY_MASK) == ID_ADT75XX) &&
-   (chip->config1 & ADT7516_SEL_AIN1_2_EX_TEMP_MASK) == 0)
+  

Re: [PATCH v4 02/11] gpu: ipu-csi: Swap fields according to input/output field types

2018-10-08 Thread Steve Longerbeam

Hi Philipp,


On 10/05/2018 02:44 AM, Philipp Zabel wrote:

Hi Steve,

On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:



+
+   /* framelines for NTSC / PAL */
+   height = (std & V4L2_STD_525_60) ? 525 : 625;

I think this is a bit convoluted. Instead of initializing std, then
possibly changing it, and then comparing to the inital value, and then
checking it again to determine the new height, why not just:

if (width == 720 && height == 480) {
std = V4L2_STD_NTSC;
height = 525;
} else if (width == 720 && height == 576) {
std = V4L2_STD_PAL;
height = 625;
} else {
dev_err(csi->ipu->dev,
"Unsupported interlaced video mode\n");
ret = -EINVAL;
goto out_unlock;
}

?


Yes that was a bit convoluted, fixed.



  
  	/*

 * if cycles is set, we need to handle this over multiple cycles as
 * generic/bayer data
 */
-   if (is_parallel_bus(>upstream_ep) && incc->cycles) {
-   if_fmt.width *= incc->cycles;

If the input format width passed to ipu_csi_init_interface is not
multiplied by the number of cycles per pixel anymore, width in the
CSI_SENS_FRM_SIZE register will be set to the unmultiplied value from
infmt.
This breaks 779680e2e793 ("media: imx: add support for RGB565_2X8 on
parallel bus").


Oops, that was a mistake, thanks for catching, fixed.

Steve

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


Re: [PATCH v2] staging: iio: ad2s1210: fix 'assignment operator' style checks

2018-10-08 Thread Jonathan Cameron
On Mon,  8 Oct 2018 00:29:38 -0300
Matheus Tavares  wrote:

> This patch fixes all "Assignment operator '=' should be on the previous
> line" checks found in ad2s1210.c with checkpatch.pl.
> 
> Signed-off-by: Matheus Tavares 
Great, thanks for sorting this out and coming back with a V2 so quickly.

Applied to the togreg branch of iio.git which is initially pushed out as
testing for the autobuilders to play with it.

We are late in the current kernel cycle, so this will probably not go
upstream until the merge window after the one that will open in a few
weeks time.

Thanks,

Jonathan

> ---
> Changes in v2: In v1, tabs were accidentally converted to whitespaces.
> Now, tabs were preserved.
> 
>  drivers/staging/iio/resolver/ad2s1210.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c 
> b/drivers/staging/iio/resolver/ad2s1210.c
> index ac13b99bd9cb..d4b1c2c010f2 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -301,8 +301,8 @@ static ssize_t ad2s1210_store_control(struct device *dev,
>   "ad2s1210: write control register fail\n");
>   goto error_ret;
>   }
> - st->resolution
> - = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> + st->resolution =
> + ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
>   if (st->pdata->gpioin) {
>   data = ad2s1210_read_resolution_pin(st);
>   if (data != st->resolution)
> @@ -363,8 +363,8 @@ static ssize_t ad2s1210_store_resolution(struct device 
> *dev,
>   dev_err(dev, "ad2s1210: setting resolution fail\n");
>   goto error_ret;
>   }
> - st->resolution
> - = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> + st->resolution =
> + ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
>   if (st->pdata->gpioin) {
>   data = ad2s1210_read_resolution_pin(st);
>   if (data != st->resolution)

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


RE: staging: android: ion: aligned allocation support

2018-10-08 Thread Skidanov, Alexey


> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Monday, October 08, 2018 21:26
> To: Skidanov, Alexey ;
> de...@driverdev.osuosl.org
> Cc: Sumit Semwal 
> Subject: Re: staging: android: ion: aligned allocation support
> 
> On 10/03/2018 01:03 PM, Alexey Skidanov wrote:
> >
> >
> > On 10/03/2018 09:07 PM, Laura Abbott wrote:
> >> On 10/02/2018 07:27 AM, Alexey Skidanov wrote:
> >>> Hi,
> >>>
> >>> Sometimes HW requires memory buffer to be aligned in order to be used
> >>> properly.  Of course, we may overcome the lack of aligned allocation
> >>> support, but we may easily add it because CMA and gen_pool (used by
> >>> several heaps) already support it.
> >>>
> >>> Does someone have an objection to add it?
> >>>
> >>> Thanks,
> >>> Alexey
> >>>
> >>
> >> The alignment option was removed from the allocation API before
> >> because the most common heap (system heap) didn't support it
> >> and it was causing more confusion. We've already mangled the
> >> ABI once so I really don't want to break it again. I'm not
> >> opposed to adding alignment support for the CMA via the allocation
> >> flags.
> > Currently, the flags member is used to define the way the buffer will be
> > mapped - cached or uncached. So,if I understand you correct, we need to
> > add ION_FLAG_ALIGNED flag and to share 32 bit field between flags and
> > flags specific data (alignment value) ?
> >
> 
> Yes, that's what I was thinking.
Excellent. I will prepare the patch.
> 
> > I'm probably going to remove the carveout and chunk heap because
> >> nobody has stepped up to figure out how to tie allocation of those
> >> to device tree or another method.
> >>
> >> Thanks,
> >> Laura
> >
> > Thanks,
> > Alexey
> >
Thanks,
Alexey
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 4.4 028/113] staging: android: ashmem: Fix mmap size validation

2018-10-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Alistair Strachan 

[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]

The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.

Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.

Cc: Todd Kjos 
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: kernel-t...@android.com
Cc: Joel Fernandes 
Signed-off-by: Alistair Strachan 
Acked-by: Joel Fernandes (Google) 
Reviewed-by: Martijn Coenen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/android/ashmem.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -370,6 +370,12 @@ static int ashmem_mmap(struct file *file
goto out;
}
 
+   /* requested mapping size larger than object size */
+   if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask)) &
 calc_vm_prot_bits(PROT_MASK))) {


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


Re: staging: android: ion: aligned allocation support

2018-10-08 Thread Laura Abbott

On 10/03/2018 01:03 PM, Alexey Skidanov wrote:



On 10/03/2018 09:07 PM, Laura Abbott wrote:

On 10/02/2018 07:27 AM, Alexey Skidanov wrote:

Hi,

Sometimes HW requires memory buffer to be aligned in order to be used
properly.  Of course, we may overcome the lack of aligned allocation
support, but we may easily add it because CMA and gen_pool (used by
several heaps) already support it.

Does someone have an objection to add it?

Thanks,
Alexey



The alignment option was removed from the allocation API before
because the most common heap (system heap) didn't support it
and it was causing more confusion. We've already mangled the
ABI once so I really don't want to break it again. I'm not
opposed to adding alignment support for the CMA via the allocation
flags.

Currently, the flags member is used to define the way the buffer will be
mapped - cached or uncached. So,if I understand you correct, we need to
add ION_FLAG_ALIGNED flag and to share 32 bit field between flags and
flags specific data (alignment value) ?



Yes, that's what I was thinking.


I'm probably going to remove the carveout and chunk heap because

nobody has stepped up to figure out how to tie allocation of those
to device tree or another method.

Thanks,
Laura


Thanks,
Alexey



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


Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-08 Thread Andy Lutomirski
On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti  wrote:
>
> On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti  wrote:
> > >
> > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > > For better or for worse, I'm trying to understand this code.  So far,
> > > > I've come up with this patch:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx=14fd71e12b1c4492a06f368f75041f263e6862bf
> > > >
> > > > Is it correct, or am I missing some subtlety?
> > >
> > > The master clock, when initialized, has a pair
> > >
> > > masterclockvalues=(TSC value, time-of-day data).
> > >
> > > When updating the guest clock, we only update relative to (TSC value)
> > > that was read on masterclock initialization.
> >
> > I don't see the problem.  The masterclock data is updated here:
> >
> > host_tsc_clocksource = kvm_get_time_and_clockread(
> > >master_kernel_ns,
> > >master_cycle_now);
> >
> > kvm_get_time_and_clockread() gets those values from
> > do_monotonic_boot(), which, barring bugs, should cause
> > get_kvmclock_ns() to return exactly the same thing as
> > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> > roundabout manner.
> >
> > So what am I missing?  Is there actually something wrong with my patch?
>
> For the bug mentioned in the comment not to happen, you must only read
> TSC and add it as offset to (TSC value, time-of-day data).
>
> Its more than "a roundabout manner".
>
> Read the comment again.
>

I read the comment three more times and even dug through the git
history.  It seems like what you're saying is that, under certain
conditions (which arguably would be bugs in the core Linux timing
code), actually calling ktime_get_boot_ns() could be non-monotonic
with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
for VM timing as such -- it's used for the IOCTL interfaces for
updating the time offset.  So can you explain how my patch is
incorrect?

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


Re: [PATCH] staging: bcm2835-camera: remove extraneous setting of dev->colourfx.enable

2018-10-08 Thread Dave Stevenson
 Hi Stefan.

Thanks for forwarding as the linux-rpi-kernel list hasn't sent it to me as yet.

On Mon, 8 Oct 2018 at 16:48, Stefan Wahren  wrote:
>
> Hi Colin,
>
> Am 08.10.2018 um 16:50 schrieb Colin King:
> > From: Colin Ian King 
> >
> > Currently dev->colourfx.enable is being set twice, hence the first
> > occurrance is redundant and can be removed, so remove it. This minor
> > issue was introduced by commit 7b3ad5abf027 ("staging: Import the
> > BCM2835 MMAL-based V4L2 camera driver.").
> >
> > Detected by CoverityScan CID#1419711 ("Unused value")
> >
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/staging/vc04_services/bcm2835-camera/controls.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c 
> > b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > index a2c55cb2192a..99831dd4365d 100644
> > --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > @@ -588,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev *dev,
> >
> >   control = >component[MMAL_COMPONENT_CAMERA]->control;
> >
> > - dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
> >   dev->colourfx.enable = ctrl->val & 0xff;
> >
> >   ret = vchiq_mmal_port_parameter_set(dev->instance, control,
>
> as long as the current behavior is correct, i'm okay with this patch.
> But the byte masking looks suspicious, so i hope Dave can clarify that.

It's writing to the wrong structure member.
The function is used on the V4L2 control V4L2_CID_COLORFX_CBCR, which
is defined as:
V4L2_CID_COLORFX_CBCR (integer)
Determines the Cb and Cr coefficients for V4L2_COLORFX_SET_CBCR color
effect. Bits [7:0] of the supplied 32 bit value are interpreted as Cr
component, bits [15:8] as Cb component and bits [31:16] must be zero.

ctrl->val should therefore be setting dev->colourfx.u and
dev->colourfx.v with those masks. dev->colourfx.enable field should
have been set when going through ctrl_set_image_effect for contol
V4L2_CID_COLORFX set to V4L2_COLORFX_SET_CBCR.

I've confirmed with qv4l2 that that is what is wrong. That's only been
lurking there for almost 5 years - shows how often these weirder
effects get used.
I don't mind whether Colin's patch gets merged and then fixed up, or
drop Colin's patch and apply the correct logic via a new patch.

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


Re: [v3, 6/6] net: dpaa2: fix and improve dpaa2-ptp driver

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:30 +0800

> This patch is to fix and improve dpaa2-ptp driver
> in some places.
> 
> - Fixed the return for some functions.
> - Replaced kzalloc with devm_kzalloc.
> - Removed dev_set_drvdata(dev, NULL).
> - Made ptp_dpaa2_caps const.
> 
> Signed-off-by: Yangbo Lu 

Applied.

You can make things much easier for me and everyone else if you provide
a proper "[PATCH 0/N] ..." header posting with your patch series.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [v3, 3/6] net: dpaa2: fix dependency of config FSL_DPAA2_ETH

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:27 +0800

> The NETDEVICES dependency and ETHERNET dependency hadn't
> been required since dpaa2-eth was moved out of staging.
> Also allowed COMPILE_TEST for dpaa2-eth.
> 
> Signed-off-by: Yangbo Lu 

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


Re: [v3, 5/6] net: dpaa2: remove unused code for dprtc

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:29 +0800

> This patch is to removed unused code for dprtc.
> This code will be re-added along with more features
> of dpaa2-ptp added.
> 
> Signed-off-by: Yangbo Lu 

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


Re: [v3, 4/6] net: dpaa2: rename rtc as ptp in dpaa2-ptp driver

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:28 +0800

> In dpaa2-ptp driver, it's odd to use rtc in names of
> some functions and structures except these dprtc APIs.
> This patch is to use ptp instead of rtc in names.
> 
> Signed-off-by: Yangbo Lu 

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


Re: [v3, 2/6] MAINTAINERS: update files maintained under DPAA2 PTP/ETHERNET

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:26 +0800

> The files maintained under DPAA2 PTP/ETHERNET needs to
> be updated since dpaa2 ptp driver had been moved into
> drivers/net/ethernet/freescale/dpaa2/.
> 
> Signed-off-by: Yangbo Lu 

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


Re: [v3, 1/6] net: dpaa2: move DPAA2 PTP driver out of staging/

2018-10-08 Thread David Miller
From: Yangbo Lu 
Date: Mon,  8 Oct 2018 15:44:25 +0800

> This patch is to move DPAA2 PTP driver out of staging/
> since the dpaa2-eth had been moved out.
> 
> Signed-off-by: Yangbo Lu 

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


Re: [PATCH] staging: bcm2835-camera: remove extraneous setting of dev->colourfx.enable

2018-10-08 Thread Dave Stevenson
On Mon, 8 Oct 2018 at 18:09, Stefan Wahren  wrote:
>
> Hi Dave,
>
> > Dave Stevenson  hat am 8. Oktober 2018 um 
> > 18:51 geschrieben:
> >
> >
> >  Hi Stefan.
> >
> > Thanks for forwarding as the linux-rpi-kernel list hasn't sent it to me as 
> > yet.
>
> AFAIK every mail with more than 5 recipients will be delayed.
>
> >
> > On Mon, 8 Oct 2018 at 16:48, Stefan Wahren  wrote:
> > >
> > > Hi Colin,
> > >
> > > Am 08.10.2018 um 16:50 schrieb Colin King:
> > > > From: Colin Ian King 
> > > >
> > > > Currently dev->colourfx.enable is being set twice, hence the first
> > > > occurrance is redundant and can be removed, so remove it. This minor
> > > > issue was introduced by commit 7b3ad5abf027 ("staging: Import the
> > > > BCM2835 MMAL-based V4L2 camera driver.").
> > > >
> > > > Detected by CoverityScan CID#1419711 ("Unused value")
> > > >
> > > > Signed-off-by: Colin Ian King 
> > > > ---
> > > >  drivers/staging/vc04_services/bcm2835-camera/controls.c | 1 -
> > > >  1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c 
> > > > b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > > index a2c55cb2192a..99831dd4365d 100644
> > > > --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > > +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > > @@ -588,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev 
> > > > *dev,
> > > >
> > > >   control = >component[MMAL_COMPONENT_CAMERA]->control;
> > > >
> > > > - dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
> > > >   dev->colourfx.enable = ctrl->val & 0xff;
> > > >
> > > >   ret = vchiq_mmal_port_parameter_set(dev->instance, control,
> > >
> > > as long as the current behavior is correct, i'm okay with this patch.
> > > But the byte masking looks suspicious, so i hope Dave can clarify that.
> >
> > It's writing to the wrong structure member.
> > The function is used on the V4L2 control V4L2_CID_COLORFX_CBCR, which
> > is defined as:
> > V4L2_CID_COLORFX_CBCR (integer)
> > Determines the Cb and Cr coefficients for V4L2_COLORFX_SET_CBCR color
> > effect. Bits [7:0] of the supplied 32 bit value are interpreted as Cr
> > component, bits [15:8] as Cb component and bits [31:16] must be zero.
> >
> > ctrl->val should therefore be setting dev->colourfx.u and
> > dev->colourfx.v with those masks. dev->colourfx.enable field should
> > have been set when going through ctrl_set_image_effect for contol
> > V4L2_CID_COLORFX set to V4L2_COLORFX_SET_CBCR.
> >
> > I've confirmed with qv4l2 that that is what is wrong. That's only been
> > lurking there for almost 5 years - shows how often these weirder
> > effects get used.
> > I don't mind whether Colin's patch gets merged and then fixed up, or
> > drop Colin's patch and apply the correct logic via a new patch.
>
> no this patch shouldn't be applied. Does it mean you want to send the proper 
> one?

Want to - not really. Ought to - I guess so.
I've got a bunch of checkpatch and other fixes to come too, so once
I've got a mainline kernel build back up and running I'll roll them
all up and blitz the list.

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


Re: [PATCH] staging: bcm2835-camera: remove extraneous setting of dev->colourfx.enable

2018-10-08 Thread Stefan Wahren
Hi Dave,

> Dave Stevenson  hat am 8. Oktober 2018 um 
> 18:51 geschrieben:
> 
> 
>  Hi Stefan.
> 
> Thanks for forwarding as the linux-rpi-kernel list hasn't sent it to me as 
> yet.

AFAIK every mail with more than 5 recipients will be delayed.

> 
> On Mon, 8 Oct 2018 at 16:48, Stefan Wahren  wrote:
> >
> > Hi Colin,
> >
> > Am 08.10.2018 um 16:50 schrieb Colin King:
> > > From: Colin Ian King 
> > >
> > > Currently dev->colourfx.enable is being set twice, hence the first
> > > occurrance is redundant and can be removed, so remove it. This minor
> > > issue was introduced by commit 7b3ad5abf027 ("staging: Import the
> > > BCM2835 MMAL-based V4L2 camera driver.").
> > >
> > > Detected by CoverityScan CID#1419711 ("Unused value")
> > >
> > > Signed-off-by: Colin Ian King 
> > > ---
> > >  drivers/staging/vc04_services/bcm2835-camera/controls.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c 
> > > b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > index a2c55cb2192a..99831dd4365d 100644
> > > --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > > @@ -588,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev *dev,
> > >
> > >   control = >component[MMAL_COMPONENT_CAMERA]->control;
> > >
> > > - dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
> > >   dev->colourfx.enable = ctrl->val & 0xff;
> > >
> > >   ret = vchiq_mmal_port_parameter_set(dev->instance, control,
> >
> > as long as the current behavior is correct, i'm okay with this patch.
> > But the byte masking looks suspicious, so i hope Dave can clarify that.
> 
> It's writing to the wrong structure member.
> The function is used on the V4L2 control V4L2_CID_COLORFX_CBCR, which
> is defined as:
> V4L2_CID_COLORFX_CBCR (integer)
> Determines the Cb and Cr coefficients for V4L2_COLORFX_SET_CBCR color
> effect. Bits [7:0] of the supplied 32 bit value are interpreted as Cr
> component, bits [15:8] as Cb component and bits [31:16] must be zero.
> 
> ctrl->val should therefore be setting dev->colourfx.u and
> dev->colourfx.v with those masks. dev->colourfx.enable field should
> have been set when going through ctrl_set_image_effect for contol
> V4L2_CID_COLORFX set to V4L2_COLORFX_SET_CBCR.
> 
> I've confirmed with qv4l2 that that is what is wrong. That's only been
> lurking there for almost 5 years - shows how often these weirder
> effects get used.
> I don't mind whether Colin's patch gets merged and then fixed up, or
> drop Colin's patch and apply the correct logic via a new patch.

no this patch shouldn't be applied. Does it mean you want to send the proper 
one?

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


[PATCH v3] staging: erofs: add SPDX identifer

2018-10-08 Thread Loic Tourlonias
Add SPDX identifier to simplify header and remove whole license text

Signed-off-by: Loic Tourlonias 

---

v2 -> v3:

- Revert undesired new line suppression,
- Fix patch format

v1 -> v2:

Move SPDX identifier to first line and change comment delimiter

 drivers/staging/erofs/lz4defs.h | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h
index 00a0b58a0871..3b8a694d2ac8 100644
--- a/drivers/staging/erofs/lz4defs.h
+++ b/drivers/staging/erofs/lz4defs.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: BSD-2-Clause*/
 #ifndef __LZ4DEFS_H__
 #define __LZ4DEFS_H__
 
@@ -6,27 +7,7 @@
 
  * LZ4 - Fast LZ compression algorithm
  * Copyright (C) 2011-2016, Yann Collet.
- * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above
- * copyright notice, this list of conditions and the following disclaimer
- * in the documentation and/or other materials provided with the
- * distribution.
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
  * You can contact the author at :
  * - LZ4 homepage : http://www.lz4.org
  * - LZ4 source repository : https://github.com/lz4/lz4
-- 
2.17.1

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


Re: [PATCH] staging: bcm2835-camera: remove extraneous setting of dev->colourfx.enable

2018-10-08 Thread Stefan Wahren
Hi Colin,

Am 08.10.2018 um 16:50 schrieb Colin King:
> From: Colin Ian King 
>
> Currently dev->colourfx.enable is being set twice, hence the first
> occurrance is redundant and can be removed, so remove it. This minor
> issue was introduced by commit 7b3ad5abf027 ("staging: Import the
> BCM2835 MMAL-based V4L2 camera driver.").
>
> Detected by CoverityScan CID#1419711 ("Unused value")
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/vc04_services/bcm2835-camera/controls.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c 
> b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> index a2c55cb2192a..99831dd4365d 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> @@ -588,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev *dev,
>  
>   control = >component[MMAL_COMPONENT_CAMERA]->control;
>  
> - dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
>   dev->colourfx.enable = ctrl->val & 0xff;
>  
>   ret = vchiq_mmal_port_parameter_set(dev->instance, control,

as long as the current behavior is correct, i'm okay with this patch.
But the byte masking looks suspicious, so i hope Dave can clarify that.

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


Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-08 Thread Marcelo Tosatti
On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti  wrote:
> >
> > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > For better or for worse, I'm trying to understand this code.  So far,
> > > I've come up with this patch:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx=14fd71e12b1c4492a06f368f75041f263e6862bf
> > >
> > > Is it correct, or am I missing some subtlety?
> >
> > The master clock, when initialized, has a pair
> >
> > masterclockvalues=(TSC value, time-of-day data).
> >
> > When updating the guest clock, we only update relative to (TSC value)
> > that was read on masterclock initialization.
> 
> I don't see the problem.  The masterclock data is updated here:
> 
> host_tsc_clocksource = kvm_get_time_and_clockread(
> >master_kernel_ns,
> >master_cycle_now);
> 
> kvm_get_time_and_clockread() gets those values from
> do_monotonic_boot(), which, barring bugs, should cause
> get_kvmclock_ns() to return exactly the same thing as
> ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> roundabout manner.
> 
> So what am I missing?  Is there actually something wrong with my patch?

For the bug mentioned in the comment not to happen, you must only read
TSC and add it as offset to (TSC value, time-of-day data).

Its more than "a roundabout manner".

Read the comment again.

> 
> 
> >
> > See the following comment on x86.c:
> 
> I read that comment, and it's not obvious to me how it's related.


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


Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-08 Thread Marcelo Tosatti
On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> For better or for worse, I'm trying to understand this code.  So far,
> I've come up with this patch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx=14fd71e12b1c4492a06f368f75041f263e6862bf
> 
> Is it correct, or am I missing some subtlety?

"In the non-fallback case, a bunch of gnarly arithmetic is done: a
hopefully matched pair of (TSC, boot time) is read, then all locks
are dropped, then the TSC frequency is read, a branch new multiplier
and shift is read, and the result is turned into a time.

This seems quite racy to me.  Because locks are not held, I don't
see what keeps TSC frequency used in sync with the master clock
data."

If tsc_khz changes, the host TSC clocksource will not be used, which 
disables masterclock:

if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
(val == CPUFREQ_POSTCHANGE && freq->old >
freq->new)) {
*lpj = cpufreq_scale(loops_per_jiffy_ref, ref_freq,
freq->new);

tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq,
freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
mark_tsc_unstable("cpufreq changes");

In which case it ends up in:

-   spin_lock(>pvclock_gtod_sync_lock);
-   if (!ka->use_master_clock) {
-   spin_unlock(>pvclock_gtod_sync_lock);
-   return ktime_get_boot_ns() + ka->kvmclock_offset;
-   }

masterclock -> non masterclock transition sets
a REQUEST bit on each vCPU, so as to invalidate any previous
clock reads.

static void kvm_gen_update_masterclock(struct kvm *kvm)
{
#ifdef CONFIG_X86_64
int i;
struct kvm_vcpu *vcpu;
struct kvm_arch *ka = >arch;

spin_lock(>pvclock_gtod_sync_lock);
kvm_make_mclock_inprogress_request(kvm);
/* no guest entries from this point */
pvclock_update_vm_gtod_copy(kvm);

kvm_for_each_vcpu(i, vcpu, kvm)
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);

/* guest entries allowed */
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);

spin_unlock(>pvclock_gtod_sync_lock);
#endif



/*
 * If the host uses TSC clock, then passthrough TSC as stable
 * to the guest.
 */
host_tsc_clocksource = kvm_get_time_and_clockread(
>master_kernel_ns,
>master_cycle_now);

ka->use_master_clock = host_tsc_clocksource && vcpus_matched
&& !ka->backwards_tsc_observed
&& !ka->boot_vcpu_runs_old_kvmclock;




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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Gao Xiang
Hi Loic,

On 2018/10/8 23:00, loïc tourlonias wrote:
> Hi Gao,
> On Mon, Oct 8, 2018 at 4:48 PM Gao Xiang  wrote:
>>
>> Hi Greg,
>>
>> On 2018/10/8 22:43, Greg Kroah-Hartman wrote:
>>> On Mon, Oct 08, 2018 at 10:36:39PM +0800, Gao Xiang wrote:
 Hi Greg,

 On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
> Why delete that line?
>
> But wait, why do we even have this file at all?  What's wrong with the
> lib/lz4/ code that we have in the kernel today?  Shouldn't the code
> using these files be moved over to use the lib/ code instead and this
> file be deleted?

 EROFS uses customized LZ4 decompression code for now (which has been 
 offically
 supported in lz4 1.8.3, I have updated it in
 https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
 if it is shown up in Linux 4.20, I will remove all the customized LZ4 
 decompression code),
 but lib/ code lz4def.h isn't export to include/.
>>>
>>> It should show up in 4.20, so you should be able to remove this all
>>> then.
>>
>> Yes, that is correct. I will fix it in 4.20 if the updated LZ4 is already 
>> there. :)
> 
> So no need to update the patch since the file will be removed. Am I correct?
> 
> Too bad, I'll make my first patch later... ^^

I think you could make the patch if you want :)
It is up to Greg whether take this patch or not since it is actually a cleanup 
attempt.

I will also do more cleanups beside my current work, yet EROFS is now busy in 
productization.

Thanks,
Gao Xiang

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread loïc tourlonias
Hi Gao,
On Mon, Oct 8, 2018 at 4:48 PM Gao Xiang  wrote:
>
> Hi Greg,
>
> On 2018/10/8 22:43, Greg Kroah-Hartman wrote:
> > On Mon, Oct 08, 2018 at 10:36:39PM +0800, Gao Xiang wrote:
> >> Hi Greg,
> >>
> >> On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
> >>> Why delete that line?
> >>>
> >>> But wait, why do we even have this file at all?  What's wrong with the
> >>> lib/lz4/ code that we have in the kernel today?  Shouldn't the code
> >>> using these files be moved over to use the lib/ code instead and this
> >>> file be deleted?
> >>
> >> EROFS uses customized LZ4 decompression code for now (which has been 
> >> offically
> >> supported in lz4 1.8.3, I have updated it in
> >> https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
> >> if it is shown up in Linux 4.20, I will remove all the customized LZ4 
> >> decompression code),
> >> but lib/ code lz4def.h isn't export to include/.
> >
> > It should show up in 4.20, so you should be able to remove this all
> > then.
>
> Yes, that is correct. I will fix it in 4.20 if the updated LZ4 is already 
> there. :)

So no need to update the patch since the file will be removed. Am I correct?

Too bad, I'll make my first patch later... ^^

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


[PATCH] staging: bcm2835-camera: remove extraneous setting of dev->colourfx.enable

2018-10-08 Thread Colin King
From: Colin Ian King 

Currently dev->colourfx.enable is being set twice, hence the first
occurrance is redundant and can be removed, so remove it. This minor
issue was introduced by commit 7b3ad5abf027 ("staging: Import the
BCM2835 MMAL-based V4L2 camera driver.").

Detected by CoverityScan CID#1419711 ("Unused value")

Signed-off-by: Colin Ian King 
---
 drivers/staging/vc04_services/bcm2835-camera/controls.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c 
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index a2c55cb2192a..99831dd4365d 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -588,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev *dev,
 
control = >component[MMAL_COMPONENT_CAMERA]->control;
 
-   dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
dev->colourfx.enable = ctrl->val & 0xff;
 
ret = vchiq_mmal_port_parameter_set(dev->instance, control,
-- 
2.17.1

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Gao Xiang
Hi Greg,

On 2018/10/8 22:43, Greg Kroah-Hartman wrote:
> On Mon, Oct 08, 2018 at 10:36:39PM +0800, Gao Xiang wrote:
>> Hi Greg,
>>
>> On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
>>> Why delete that line?
>>>
>>> But wait, why do we even have this file at all?  What's wrong with the
>>> lib/lz4/ code that we have in the kernel today?  Shouldn't the code
>>> using these files be moved over to use the lib/ code instead and this
>>> file be deleted?
>>
>> EROFS uses customized LZ4 decompression code for now (which has been 
>> offically
>> supported in lz4 1.8.3, I have updated it in
>> https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
>> if it is shown up in Linux 4.20, I will remove all the customized LZ4 
>> decompression code),
>> but lib/ code lz4def.h isn't export to include/.
> 
> It should show up in 4.20, so you should be able to remove this all
> then.

Yes, that is correct. I will fix it in 4.20 if the updated LZ4 is already 
there. :)

Thanks,
Gao Xiang

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Greg Kroah-Hartman
On Mon, Oct 08, 2018 at 10:36:39PM +0800, Gao Xiang wrote:
> Hi Greg,
> 
> On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
> > Why delete that line?
> > 
> > But wait, why do we even have this file at all?  What's wrong with the
> > lib/lz4/ code that we have in the kernel today?  Shouldn't the code
> > using these files be moved over to use the lib/ code instead and this
> > file be deleted?
> 
> EROFS uses customized LZ4 decompression code for now (which has been offically
> supported in lz4 1.8.3, I have updated it in
> https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
> if it is shown up in Linux 4.20, I will remove all the customized LZ4 
> decompression code),
> but lib/ code lz4def.h isn't export to include/.

It should show up in 4.20, so you should be able to remove this all
then.

thanks,

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Gao Xiang



On 2018/10/8 22:36, Gao Xiang wrote:
> Hi Greg,
> 
> On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
>> Why delete that line?
>>
>> But wait, why do we even have this file at all?  What's wrong with the
>> lib/lz4/ code that we have in the kernel today?  Shouldn't the code
>> using these files be moved over to use the lib/ code instead and this
>> file be deleted?
> 
> EROFS uses customized LZ4 decompression code for now (which has been offically
> supported in lz4 1.8.3, I have updated it in
> https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
> if it is shown up in Linux 4.20, I will remove all the customized LZ4 
> decompression code),
> but lib/ code lz4def.h isn't export to include/.

Please refer to https://github.com/lz4/lz4/issues/566 for more details the 
reason why
EROFS uses the different implementation rather than the current lib/lz4/ code 
in the kernel today
(it will be changed in the next Linux version if the updated code works fine.)

Thanks,
Gao Xiang

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Gao Xiang
Hi Greg,

On 2018/10/8 22:22, Greg Kroah-Hartman wrote:
> Why delete that line?
> 
> But wait, why do we even have this file at all?  What's wrong with the
> lib/lz4/ code that we have in the kernel today?  Shouldn't the code
> using these files be moved over to use the lib/ code instead and this
> file be deleted?

EROFS uses customized LZ4 decompression code for now (which has been offically
supported in lz4 1.8.3, I have updated it in
https://ozlabs.org/~akpm/mmots/broken-out/lib-lz4-update-lz4-decompressor-module.patch
if it is shown up in Linux 4.20, I will remove all the customized LZ4 
decompression code),
but lib/ code lz4def.h isn't export to include/.

Thanks,
Gao Xiang

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


Re: [PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Greg Kroah-Hartman
On Mon, Oct 08, 2018 at 04:14:09PM +0200, Loic Tourlonias wrote:
> Add SPDX identifier to simplify header and remove whole license text
> 
> v1 -> v2:
> 
> Move SPDX identifier to first line and change comment delimiter

The "changes" need to go below the --- line.

> 
> Signed-off-by: Loic Tourlonias 
> ---
>  drivers/staging/erofs/lz4defs.h | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h
> index 00a0b58a0871..cdacc57e6a08 100644
> --- a/drivers/staging/erofs/lz4defs.h
> +++ b/drivers/staging/erofs/lz4defs.h
> @@ -1,32 +1,12 @@
> +/* SPDX-License-Identifier: BSD-2-Clause*/
>  #ifndef __LZ4DEFS_H__
>  #define __LZ4DEFS_H__
> -
>  /*

Why delete that line?

But wait, why do we even have this file at all?  What's wrong with the
lib/lz4/ code that we have in the kernel today?  Shouldn't the code
using these files be moved over to use the lib/ code instead and this
file be deleted?

thanks,

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


[PATCH v2] staging: erofs: add SPDX identifer

2018-10-08 Thread Loic Tourlonias
Add SPDX identifier to simplify header and remove whole license text

v1 -> v2:

Move SPDX identifier to first line and change comment delimiter

Signed-off-by: Loic Tourlonias 
---
 drivers/staging/erofs/lz4defs.h | 24 ++--
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h
index 00a0b58a0871..cdacc57e6a08 100644
--- a/drivers/staging/erofs/lz4defs.h
+++ b/drivers/staging/erofs/lz4defs.h
@@ -1,32 +1,12 @@
+/* SPDX-License-Identifier: BSD-2-Clause*/
 #ifndef __LZ4DEFS_H__
 #define __LZ4DEFS_H__
-
 /*
  * lz4defs.h -- common and architecture specific defines for the kernel usage
 
  * LZ4 - Fast LZ compression algorithm
  * Copyright (C) 2011-2016, Yann Collet.
- * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above
- * copyright notice, this list of conditions and the following disclaimer
- * in the documentation and/or other materials provided with the
- * distribution.
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
  * You can contact the author at :
  * - LZ4 homepage : http://www.lz4.org
  * - LZ4 source repository : https://github.com/lz4/lz4
-- 
2.17.1

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


Re: [PATCH] staging: erofs: add SPDX identifer

2018-10-08 Thread Greg Kroah-Hartman
On Mon, Oct 08, 2018 at 09:20:55PM +0800, Gao Xiang wrote:
> Hi Loic,
> 
> On 2018/10/8 18:41, Loic Tourlonias wrote:
> > Add SPDX identifier to simplify header and remove whole license text
> > 
> > Signed-off-by: Loic Tourlonias 
> > ---
> >  drivers/staging/erofs/lz4defs.h | 23 ++-
> >  1 file changed, 2 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/staging/erofs/lz4defs.h 
> > b/drivers/staging/erofs/lz4defs.h
> > index 00a0b58a0871..bdb1022981d8 100644
> > --- a/drivers/staging/erofs/lz4defs.h
> > +++ b/drivers/staging/erofs/lz4defs.h
> > @@ -1,32 +1,13 @@
> >  #ifndef __LZ4DEFS_H__
> >  #define __LZ4DEFS_H__
> >  
> > +// SPDX-License-Identifier: BSD-2-Clause
> 
> For *.h files, it seems SPDX Identifier should be /* SPDX-License-Identifier: 
> */
> rather than // SPDX-License-Identifier:

That is correct.

> And I think it should be placed at the first line of the line, but I am not 
> sure of that.

Yes, it has to be the first line.

The documentation for the SPDX lines in the kernel describe all of this.

thanks,

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


Re: [PATCH] staging: erofs: add SPDX identifer

2018-10-08 Thread Gao Xiang
Hi Loic,

On 2018/10/8 18:41, Loic Tourlonias wrote:
> Add SPDX identifier to simplify header and remove whole license text
> 
> Signed-off-by: Loic Tourlonias 
> ---
>  drivers/staging/erofs/lz4defs.h | 23 ++-
>  1 file changed, 2 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h
> index 00a0b58a0871..bdb1022981d8 100644
> --- a/drivers/staging/erofs/lz4defs.h
> +++ b/drivers/staging/erofs/lz4defs.h
> @@ -1,32 +1,13 @@
>  #ifndef __LZ4DEFS_H__
>  #define __LZ4DEFS_H__
>  
> +// SPDX-License-Identifier: BSD-2-Clause

For *.h files, it seems SPDX Identifier should be /* SPDX-License-Identifier: */
rather than // SPDX-License-Identifier:

And I think it should be placed at the first line of the line, but I am not 
sure of that.

Thanks,
Gao Xiang

>  /*
>   * lz4defs.h -- common and architecture specific defines for the kernel usage
>  
>   * LZ4 - Fast LZ compression algorithm
>   * Copyright (C) 2011-2016, Yann Collet.
> - * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions are
> - * met:
> - *   * Redistributions of source code must retain the above copyright
> - * notice, this list of conditions and the following disclaimer.
> - *   * Redistributions in binary form must reproduce the above
> - * copyright notice, this list of conditions and the following disclaimer
> - * in the documentation and/or other materials provided with the
> - * distribution.
> - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
>   * You can contact the author at :
>   *   - LZ4 homepage : http://www.lz4.org
>   *   - LZ4 source repository : https://github.com/lz4/lz4
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: erofs: adds a space around '*'

2018-10-08 Thread Gustavo A. R. Silva
Hi,

On 10/8/18 1:45 PM, Daeseok Youn wrote:
> fix checkpatch.pl error:
> ERROR: need consistent spacing around '*' (ctx:WxV)
> +   memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);
> 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/staging/erofs/unzip_vle_lz4.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/erofs/unzip_vle_lz4.c 
> b/drivers/staging/erofs/unzip_vle_lz4.c
> index f5b665f..501cfe0 100644
> --- a/drivers/staging/erofs/unzip_vle_lz4.c
> +++ b/drivers/staging/erofs/unzip_vle_lz4.c
> @@ -181,7 +181,7 @@ int z_erofs_vle_unzip_vmap(struct page **compressed_pages,
>   for (i = 0; i < clusterpages; ++i) {
>   void *t = kmap_atomic(compressed_pages[i]);
>  
> - memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);
> + memcpy(vin + PAGE_SIZE * i, t, PAGE_SIZE);
>   kunmap_atomic(t);
>   }
>   } else if (clusterpages == 1)
> 

This exact fix was applied to linux-next some days ago:

commit ea0b2d429bd82ec152d286a0c026ebcaa4154ccc

Make sure you are working from linux-next rather than from mainline.

See this link: https://www.kernel.org/doc/man-pages/linux-next.html

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


[PATCH] staging: erofs: adds a space around '*'

2018-10-08 Thread Daeseok Youn
fix checkpatch.pl error:
ERROR: need consistent spacing around '*' (ctx:WxV)
+   memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);

Signed-off-by: Daeseok Youn 
---
 drivers/staging/erofs/unzip_vle_lz4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/unzip_vle_lz4.c 
b/drivers/staging/erofs/unzip_vle_lz4.c
index f5b665f..501cfe0 100644
--- a/drivers/staging/erofs/unzip_vle_lz4.c
+++ b/drivers/staging/erofs/unzip_vle_lz4.c
@@ -181,7 +181,7 @@ int z_erofs_vle_unzip_vmap(struct page **compressed_pages,
for (i = 0; i < clusterpages; ++i) {
void *t = kmap_atomic(compressed_pages[i]);
 
-   memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);
+   memcpy(vin + PAGE_SIZE * i, t, PAGE_SIZE);
kunmap_atomic(t);
}
} else if (clusterpages == 1)
-- 
2.7.4

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


[PATCH] staging: erofs: add SPDX identifer

2018-10-08 Thread Loic Tourlonias
Add SPDX identifier to simplify header and remove whole license text

Signed-off-by: Loic Tourlonias 
---
 drivers/staging/erofs/lz4defs.h | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h
index 00a0b58a0871..bdb1022981d8 100644
--- a/drivers/staging/erofs/lz4defs.h
+++ b/drivers/staging/erofs/lz4defs.h
@@ -1,32 +1,13 @@
 #ifndef __LZ4DEFS_H__
 #define __LZ4DEFS_H__
 
+// SPDX-License-Identifier: BSD-2-Clause
 /*
  * lz4defs.h -- common and architecture specific defines for the kernel usage
 
  * LZ4 - Fast LZ compression algorithm
  * Copyright (C) 2011-2016, Yann Collet.
- * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above
- * copyright notice, this list of conditions and the following disclaimer
- * in the documentation and/or other materials provided with the
- * distribution.
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
  * You can contact the author at :
  * - LZ4 homepage : http://www.lz4.org
  * - LZ4 source repository : https://github.com/lz4/lz4
-- 
2.17.1

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


Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

2018-10-08 Thread Frieder Schrempf

Hi,

On 27.09.2018 10:14, Maxime Ripard wrote:

On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote:

On 26-09-18 16:44, Frieder Schrempf wrote:

Hi,

On Fri, Feb 09, 2018 at 03:01:00PM +0100, Ulf Hansson wrote:

[...]


I'd like to know if any progress has been made on that problem

(I may

have missed patches).
Had you had the time to look at the issue?


I have looked at the issue, but not manage to cook some patches

for it.


However, it's on my top of my TODO list for mmc. No promises, but
perhaps and hopefully I manage to get something posted during the
coming release cycle.


I would be interested in a ESP8089 driver in mainline and that's why I want to 
pick up this discussion.

What is the current status of the "mmc_reprobe_device" implementation, that 
Hans was explaining and Ulf wanted to provide some months ago?


Ulf did eventually write a new way to deal with this and then Quentin
did manage to get the esp8089 driver to work with it, the new function
to use for this is added by this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=1433269c4d2461be1f36db5dbb453976b38996ff

I'm not sure what the status of upstreaming the ep8089 driver is now
that we've this in place.

Quentin, do you have a version of the esp8089 driver somewhere
which will work correctly with the new mmc_sw_reset() function?

Also what is the status of adding this driver to say staging?


IIRC, we tried to get it into staging, and we got told that it was too
nice for staging at this point. So we're basically stuck somewhere
between staging and !staging, with the driver being too nice for the
former, and not nice enough for the latter :)


Ok, and is there someone willing to continue upstreaming the driver? 
Maybe someone can rebase and resend the latest approach?


After all it looks like a lot of work has already been done.

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


Re: [PATCH V3 2/13] KVM/MMU: Add tlb flush with range helper function

2018-10-08 Thread Tianyu Lan
Hi Paolo:
  Thanks for your review. Sorry for later response due to holiday.

On Mon, Oct 1, 2018 at 11:26 PM Paolo Bonzini  wrote:
>
> On 27/09/2018 05:48, Tianyu Lan wrote:
> > +
> > + if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
> > + /*
> > +  * Read tlbs_dirty before flushing tlbs in order
> > +  * to track dirty tlbs during flushing.
> > +  */
> > + long dirty_count = smp_load_acquire(>tlbs_dirty);
> > +
> > + ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
> > + cmpxchg(>tlbs_dirty, dirty_count, 0);
>
> This is wrong, because it's not the entire TLB that is flushed.  So you
> cannot do the cmpxchg here.

Yes, nice catch. Will update in the next version.


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


RE: [v3, 3/6] net: dpaa2: fix dependency of config FSL_DPAA2_ETH

2018-10-08 Thread Ioana Ciocoi Radulescu
> -Original Message-
> From: Yangbo Lu 
> Sent: Monday, October 8, 2018 10:44 AM
> To: linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org;
> net...@vger.kernel.org; Richard Cochran ;
> David S . Miller ; Ioana Ciocoi Radulescu
> ; Greg Kroah-Hartman
> ; Andrew Lunn 
> Cc: Y.b. Lu 
> Subject: [v3, 3/6] net: dpaa2: fix dependency of config FSL_DPAA2_ETH
> 
> The NETDEVICES dependency and ETHERNET dependency hadn't
> been required since dpaa2-eth was moved out of staging.
> Also allowed COMPILE_TEST for dpaa2-eth.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v3:
>   - Added this patch.
> ---
>  drivers/net/ethernet/freescale/dpaa2/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig
> b/drivers/net/ethernet/freescale/dpaa2/Kconfig
> index 67e6461..a7f365d 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/Kconfig
> +++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
> @@ -1,7 +1,7 @@
>  config FSL_DPAA2_ETH
>   tristate "Freescale DPAA2 Ethernet"
>   depends on FSL_MC_BUS && FSL_MC_DPIO
> - depends on NETDEVICES && ETHERNET
> + depends on ARCH_LAYERSCAPE || COMPILE_TEST

Dependency on ARCH_LAYERSCAPE and COMPILE_TEST (for some architectures)
is already implied through FSL_MC_BUS.

Thanks,
Ioana

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


Re: [PATCH] staging: emxx_udc: remove unused code

2018-10-08 Thread Gustavo A. R. Silva
Hi,

On 10/8/18 9:33 AM, Loic Tourlonias wrote:
> Remove useless code inside if_0 endif
> 
> Signed-off-by: Loic Tourlonias 
> ---
>  drivers/staging/emxx_udc/emxx_udc.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/staging/emxx_udc/emxx_udc.h 
> b/drivers/staging/emxx_udc/emxx_udc.h
> index 8337e38c238a..78fa60192a14 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.h
> +++ b/drivers/staging/emxx_udc/emxx_udc.h
> @@ -10,10 +10,6 @@
>  
>  
> /*---*/
>  /*- Default undef */
> -#if 0
> -#define DEBUG
> -#define UDC_DEBUG_DUMP
> -#endif
>  

Don't remove that code. This is a common practice for debugging.

Whenever the developer needs to debug something in the whole driver, he/she
just has to change that #if 0 to #if 1 and then all the code under DEBUG
and UDC_DEBUG_DUMP will be enabled.

Notice that UDC_DEBUG_DUMP is being used in drivers/staging/emxx_udc/emxx_udc.c

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


RE: [v2, 1/5] net: dpaa2: move DPAA2 PTP driver out of staging/

2018-10-08 Thread Y.b. Lu
Let me just add an additional patch in v3.
I had sent the new v3 patch-set out. Please help to review.

Thanks a lot.

Best regards,
Yangbo Lu

> -Original Message-
> From: Y.b. Lu
> Sent: Monday, October 8, 2018 11:11 AM
> To: 'Andrew Lunn' ; Ioana Ciocoi Radulescu
> 
> Cc: linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org;
> net...@vger.kernel.org; Richard Cochran ;
> David S . Miller ; Ioana Ciocoi Radulescu
> ; Greg Kroah-Hartman
> 
> Subject: RE: [v2, 1/5] net: dpaa2: move DPAA2 PTP driver out of staging/
> 
> Hi Andrew,
> 
> Sorry for late. Just come back from holiday.
> 
> Hi Ioana,
> 
> Could you generate an additional patch for dpaa2_eth to address Andrew's
> comments?
> There was also a warning when checked patch. FSL_DPAA2_ETH needed more
> description.
> 
> WARNING: please write a paragraph that describes the config symbol fully
> #66: FILE: drivers/net/ethernet/freescale/dpaa2/Kconfig:1:
> +config FSL_DPAA2_ETH
> 
> Thanks a lot.
> 
> Best regards,
> Yangbo Lu
> 
> > -Original Message-
> > From: Andrew Lunn 
> > Sent: Sunday, September 30, 2018 3:46 AM
> > To: Y.b. Lu 
> > Cc: linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org;
> > net...@vger.kernel.org; Richard Cochran ;
> > David S . Miller ; Ioana Ciocoi Radulescu
> > ; Greg Kroah-Hartman
> > 
> > Subject: Re: [v2, 1/5] net: dpaa2: move DPAA2 PTP driver out of
> > staging/
> >
> > > +++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
> > > @@ -0,0 +1,15 @@
> > > +config FSL_DPAA2_ETH
> > > + tristate "Freescale DPAA2 Ethernet"
> > > + depends on FSL_MC_BUS && FSL_MC_DPIO
> >
> > Could you add in here COMPILE_TEST?
> >
> > > + depends on NETDEVICES && ETHERNET
> >
> > With the move out of staging, i don't think these two are required.
> >
> >  Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[v3, 2/6] MAINTAINERS: update files maintained under DPAA2 PTP/ETHERNET

2018-10-08 Thread Yangbo Lu
The files maintained under DPAA2 PTP/ETHERNET needs to
be updated since dpaa2 ptp driver had been moved into
drivers/net/ethernet/freescale/dpaa2/.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Updated files rtc* as dpaa2-ptp*.
Changes for v3:
- Fixed typo dpaa-ptp*. Should be dpaa2-ptp*.
---
 MAINTAINERS |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 86e83ea..54e719d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4529,7 +4529,11 @@ DPAA2 ETHERNET DRIVER
 M: Ioana Radulescu 
 L: net...@vger.kernel.org
 S: Maintained
-F: drivers/net/ethernet/freescale/dpaa2
+F: drivers/net/ethernet/freescale/dpaa2/dpaa2-eth*
+F: drivers/net/ethernet/freescale/dpaa2/dpni*
+F: drivers/net/ethernet/freescale/dpaa2/dpkg.h
+F: drivers/net/ethernet/freescale/dpaa2/Makefile
+F: drivers/net/ethernet/freescale/dpaa2/Kconfig
 
 DPAA2 ETHERNET SWITCH DRIVER
 M: Ioana Radulescu 
@@ -4540,9 +4544,10 @@ F:   drivers/staging/fsl-dpaa2/ethsw
 
 DPAA2 PTP CLOCK DRIVER
 M: Yangbo Lu 
-L: linux-ker...@vger.kernel.org
+L: net...@vger.kernel.org
 S: Maintained
-F: drivers/staging/fsl-dpaa2/rtc
+F: drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp*
+F: drivers/net/ethernet/freescale/dpaa2/dprtc*
 
 DPT_I2O SCSI RAID DRIVER
 M: Adaptec OEM Raid Solutions 
-- 
1.7.1

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


[v3, 1/6] net: dpaa2: move DPAA2 PTP driver out of staging/

2018-10-08 Thread Yangbo Lu
This patch is to move DPAA2 PTP driver out of staging/
since the dpaa2-eth had been moved out.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Renamed files rtc.* as dpaa2-ptp.*.
Changes for v3:
- Added more help info for config FSL_DPAA2_ETH.
---
 drivers/net/ethernet/freescale/Kconfig |9 +
 drivers/net/ethernet/freescale/dpaa2/Kconfig   |   17 +
 drivers/net/ethernet/freescale/dpaa2/Makefile  |6 --
 .../ethernet/freescale/dpaa2/dpaa2-ptp.c}  |2 +-
 .../ethernet/freescale/dpaa2/dpaa2-ptp.h}  |0
 .../ethernet/freescale/dpaa2}/dprtc-cmd.h  |0
 .../rtc => net/ethernet/freescale/dpaa2}/dprtc.c   |0
 .../rtc => net/ethernet/freescale/dpaa2}/dprtc.h   |0
 drivers/staging/fsl-dpaa2/Kconfig  |8 
 drivers/staging/fsl-dpaa2/Makefile |1 -
 drivers/staging/fsl-dpaa2/rtc/Makefile |7 ---
 11 files changed, 23 insertions(+), 27 deletions(-)
 create mode 100644 drivers/net/ethernet/freescale/dpaa2/Kconfig
 rename drivers/{staging/fsl-dpaa2/rtc/rtc.c => 
net/ethernet/freescale/dpaa2/dpaa2-ptp.c} (99%)
 rename drivers/{staging/fsl-dpaa2/rtc/rtc.h => 
net/ethernet/freescale/dpaa2/dpaa2-ptp.h} (100%)
 rename drivers/{staging/fsl-dpaa2/rtc => 
net/ethernet/freescale/dpaa2}/dprtc-cmd.h (100%)
 rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.c 
(100%)
 rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.h 
(100%)
 delete mode 100644 drivers/staging/fsl-dpaa2/rtc/Makefile

diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index 7a30276..d3a62bc 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -96,13 +96,6 @@ config GIANFAR
  on the 8540.
 
 source "drivers/net/ethernet/freescale/dpaa/Kconfig"
-
-config FSL_DPAA2_ETH
-   tristate "Freescale DPAA2 Ethernet"
-   depends on FSL_MC_BUS && FSL_MC_DPIO
-   depends on NETDEVICES && ETHERNET
-   ---help---
- Ethernet driver for Freescale DPAA2 SoCs, using the
- Freescale MC bus driver
+source "drivers/net/ethernet/freescale/dpaa2/Kconfig"
 
 endif # NET_VENDOR_FREESCALE
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig 
b/drivers/net/ethernet/freescale/dpaa2/Kconfig
new file mode 100644
index 000..67e6461
--- /dev/null
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -0,0 +1,17 @@
+config FSL_DPAA2_ETH
+   tristate "Freescale DPAA2 Ethernet"
+   depends on FSL_MC_BUS && FSL_MC_DPIO
+   depends on NETDEVICES && ETHERNET
+   help
+ This is the DPAA2 Ethernet driver supporting Freescale SoCs
+ with DPAA2 (DataPath Acceleration Architecture v2).
+ The driver manages network objects discovered on the Freescale
+ MC bus.
+
+config FSL_DPAA2_PTP_CLOCK
+   tristate "Freescale DPAA2 PTP Clock"
+   depends on FSL_DPAA2_ETH && POSIX_TIMERS
+   select PTP_1588_CLOCK
+   help
+ This driver adds support for using the DPAA2 1588 timer module
+ as a PTP clock.
diff --git a/drivers/net/ethernet/freescale/dpaa2/Makefile 
b/drivers/net/ethernet/freescale/dpaa2/Makefile
index 9315ecd..2f424e0 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Makefile
+++ b/drivers/net/ethernet/freescale/dpaa2/Makefile
@@ -3,9 +3,11 @@
 # Makefile for the Freescale DPAA2 Ethernet controller
 #
 
-obj-$(CONFIG_FSL_DPAA2_ETH) += fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_ETH)+= fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK)  += fsl-dpaa2-ptp.o
 
-fsl-dpaa2-eth-objs:= dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-eth-objs := dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-ptp-objs := dpaa2-ptp.o dprtc.o
 
 # Needed by the tracing framework
 CFLAGS_dpaa2-eth.o := -I$(src)
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
similarity index 99%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.c
rename to drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index 0d52cb8..2e90d5a 100644
--- a/drivers/staging/fsl-dpaa2/rtc/rtc.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#include "rtc.h"
+#include "dpaa2-ptp.h"
 
 struct ptp_dpaa2_priv {
struct fsl_mc_device *rtc_mc_dev;
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.h 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.h
rename to drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h 
b/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h
rename to drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc.c 
b/drivers/net/ethernet/freescale/dpaa2/dprtc.c
similarity 

[v3, 5/6] net: dpaa2: remove unused code for dprtc

2018-10-08 Thread Yangbo Lu
This patch is to removed unused code for dprtc.
This code will be re-added along with more features
of dpaa2-ptp added.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added this patch.
Changes for v3:
- None.
---
 drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h |   97 
 drivers/net/ethernet/freescale/dpaa2/dprtc.c |  507 --
 drivers/net/ethernet/freescale/dpaa2/dprtc.h |  119 -
 3 files changed, 0 insertions(+), 723 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h 
b/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
index db6a473..9af4ac7 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
@@ -7,10 +7,6 @@
 #ifndef _FSL_DPRTC_CMD_H
 #define _FSL_DPRTC_CMD_H
 
-/* DPRTC Version */
-#define DPRTC_VER_MAJOR2
-#define DPRTC_VER_MINOR0
-
 /* Command versioning */
 #define DPRTC_CMD_BASE_VERSION 1
 #define DPRTC_CMD_ID_OFFSET4
@@ -20,105 +16,17 @@
 /* Command IDs */
 #define DPRTC_CMDID_CLOSE  DPRTC_CMD(0x800)
 #define DPRTC_CMDID_OPEN   DPRTC_CMD(0x810)
-#define DPRTC_CMDID_CREATE DPRTC_CMD(0x910)
-#define DPRTC_CMDID_DESTROYDPRTC_CMD(0x990)
-#define DPRTC_CMDID_GET_API_VERSIONDPRTC_CMD(0xa10)
-
-#define DPRTC_CMDID_ENABLE DPRTC_CMD(0x002)
-#define DPRTC_CMDID_DISABLEDPRTC_CMD(0x003)
-#define DPRTC_CMDID_GET_ATTR   DPRTC_CMD(0x004)
-#define DPRTC_CMDID_RESET  DPRTC_CMD(0x005)
-#define DPRTC_CMDID_IS_ENABLED DPRTC_CMD(0x006)
 
-#define DPRTC_CMDID_SET_IRQ_ENABLE DPRTC_CMD(0x012)
-#define DPRTC_CMDID_GET_IRQ_ENABLE DPRTC_CMD(0x013)
-#define DPRTC_CMDID_SET_IRQ_MASK   DPRTC_CMD(0x014)
-#define DPRTC_CMDID_GET_IRQ_MASK   DPRTC_CMD(0x015)
-#define DPRTC_CMDID_GET_IRQ_STATUS DPRTC_CMD(0x016)
-#define DPRTC_CMDID_CLEAR_IRQ_STATUS   DPRTC_CMD(0x017)
-
-#define DPRTC_CMDID_SET_CLOCK_OFFSET   DPRTC_CMD(0x1d0)
 #define DPRTC_CMDID_SET_FREQ_COMPENSATION  DPRTC_CMD(0x1d1)
 #define DPRTC_CMDID_GET_FREQ_COMPENSATION  DPRTC_CMD(0x1d2)
 #define DPRTC_CMDID_GET_TIME   DPRTC_CMD(0x1d3)
 #define DPRTC_CMDID_SET_TIME   DPRTC_CMD(0x1d4)
-#define DPRTC_CMDID_SET_ALARM  DPRTC_CMD(0x1d5)
-#define DPRTC_CMDID_SET_PERIODIC_PULSE DPRTC_CMD(0x1d6)
-#define DPRTC_CMDID_CLEAR_PERIODIC_PULSE   DPRTC_CMD(0x1d7)
-#define DPRTC_CMDID_SET_EXT_TRIGGERDPRTC_CMD(0x1d8)
-#define DPRTC_CMDID_CLEAR_EXT_TRIGGER  DPRTC_CMD(0x1d9)
-#define DPRTC_CMDID_GET_EXT_TRIGGER_TIMESTAMP  DPRTC_CMD(0x1dA)
-
-/* Macros for accessing command fields smaller than 1byte */
-#define DPRTC_MASK(field)\
-   GENMASK(DPRTC_##field##_SHIFT + DPRTC_##field##_SIZE - 1, \
-   DPRTC_##field##_SHIFT)
-#define dprtc_get_field(var, field)  \
-   (((var) & DPRTC_MASK(field)) >> DPRTC_##field##_SHIFT)
 
 #pragma pack(push, 1)
 struct dprtc_cmd_open {
__le32 dprtc_id;
 };
 
-struct dprtc_cmd_destroy {
-   __le32 object_id;
-};
-
-#define DPRTC_ENABLE_SHIFT 0
-#define DPRTC_ENABLE_SIZE  1
-
-struct dprtc_rsp_is_enabled {
-   u8 en;
-};
-
-struct dprtc_cmd_get_irq {
-   __le32 pad;
-   u8 irq_index;
-};
-
-struct dprtc_cmd_set_irq_enable {
-   u8 en;
-   u8 pad[3];
-   u8 irq_index;
-};
-
-struct dprtc_rsp_get_irq_enable {
-   u8 en;
-};
-
-struct dprtc_cmd_set_irq_mask {
-   __le32 mask;
-   u8 irq_index;
-};
-
-struct dprtc_rsp_get_irq_mask {
-   __le32 mask;
-};
-
-struct dprtc_cmd_get_irq_status {
-   __le32 status;
-   u8 irq_index;
-};
-
-struct dprtc_rsp_get_irq_status {
-   __le32 status;
-};
-
-struct dprtc_cmd_clear_irq_status {
-   __le32 status;
-   u8 irq_index;
-};
-
-struct dprtc_rsp_get_attributes {
-   __le32 pad;
-   __le32 id;
-};
-
-struct dprtc_cmd_set_clock_offset {
-   __le64 offset;
-};
-
 struct dprtc_get_freq_compensation {
__le32 freq_compensation;
 };
@@ -127,11 +35,6 @@ struct dprtc_time {
__le64 time;
 };
 
-struct dprtc_rsp_get_api_version {
-   __le16 major;
-   __le16 minor;
-};
-
 #pragma pack(pop)
 
 #endif /* _FSL_DPRTC_CMD_H */
diff --git a/drivers/net/ethernet/freescale/dpaa2/dprtc.c 
b/drivers/net/ethernet/freescale/dpaa2/dprtc.c
index 68ae6ff..c13e09b 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dprtc.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dprtc.c
@@ -74,452 +74,6 @@ int dprtc_close(struct fsl_mc_io *mc_io,
 }
 
 /**
- * dprtc_create() - Create the DPRTC object.
- * @mc_io: Pointer to MC portal's I/O object
- * @dprc_token:Parent container token; '0' for default container
- * @cmd_flags: Command flags; one or more of 

[v3, 6/6] net: dpaa2: fix and improve dpaa2-ptp driver

2018-10-08 Thread Yangbo Lu
This patch is to fix and improve dpaa2-ptp driver
in some places.

- Fixed the return for some functions.
- Replaced kzalloc with devm_kzalloc.
- Removed dev_set_drvdata(dev, NULL).
- Made ptp_dpaa2_caps const.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added this patch.
Changes for v3:
- None.
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c |   25 --
 1 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index c73eef2..84b942b 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -46,7 +46,7 @@ static int ptp_dpaa2_adjfreq(struct ptp_clock_info *ptp, s32 
ppb)
  mc_dev->mc_handle, tmr_add);
if (err)
dev_err(dev, "dprtc_set_freq_compensation err %d\n", err);
-   return 0;
+   return err;
 }
 
 static int ptp_dpaa2_adjtime(struct ptp_clock_info *ptp, s64 delta)
@@ -61,17 +61,15 @@ static int ptp_dpaa2_adjtime(struct ptp_clock_info *ptp, 
s64 delta)
err = dprtc_get_time(mc_dev->mc_io, 0, mc_dev->mc_handle, );
if (err) {
dev_err(dev, "dprtc_get_time err %d\n", err);
-   return 0;
+   return err;
}
 
now += delta;
 
err = dprtc_set_time(mc_dev->mc_io, 0, mc_dev->mc_handle, now);
-   if (err) {
+   if (err)
dev_err(dev, "dprtc_set_time err %d\n", err);
-   return 0;
-   }
-   return 0;
+   return err;
 }
 
 static int ptp_dpaa2_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
@@ -87,12 +85,12 @@ static int ptp_dpaa2_gettime(struct ptp_clock_info *ptp, 
struct timespec64 *ts)
err = dprtc_get_time(mc_dev->mc_io, 0, mc_dev->mc_handle, );
if (err) {
dev_err(dev, "dprtc_get_time err %d\n", err);
-   return 0;
+   return err;
}
 
ts->tv_sec = div_u64_rem(ns, 10, );
ts->tv_nsec = remainder;
-   return 0;
+   return err;
 }
 
 static int ptp_dpaa2_settime(struct ptp_clock_info *ptp,
@@ -111,10 +109,10 @@ static int ptp_dpaa2_settime(struct ptp_clock_info *ptp,
err = dprtc_set_time(mc_dev->mc_io, 0, mc_dev->mc_handle, ns);
if (err)
dev_err(dev, "dprtc_set_time err %d\n", err);
-   return 0;
+   return err;
 }
 
-static struct ptp_clock_info ptp_dpaa2_caps = {
+static const struct ptp_clock_info ptp_dpaa2_caps = {
.owner  = THIS_MODULE,
.name   = "DPAA2 PTP Clock",
.max_adj= 512000,
@@ -136,7 +134,7 @@ static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
u32 tmr_add = 0;
int err;
 
-   ptp_dpaa2 = kzalloc(sizeof(*ptp_dpaa2), GFP_KERNEL);
+   ptp_dpaa2 = devm_kzalloc(dev, sizeof(*ptp_dpaa2), GFP_KERNEL);
if (!ptp_dpaa2)
return -ENOMEM;
 
@@ -182,8 +180,6 @@ static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
 err_free_mcp:
fsl_mc_portal_free(mc_dev->mc_io);
 err_exit:
-   kfree(ptp_dpaa2);
-   dev_set_drvdata(dev, NULL);
return err;
 }
 
@@ -198,9 +194,6 @@ static int dpaa2_ptp_remove(struct fsl_mc_device *mc_dev)
dprtc_close(mc_dev->mc_io, 0, mc_dev->mc_handle);
fsl_mc_portal_free(mc_dev->mc_io);
 
-   kfree(ptp_dpaa2);
-   dev_set_drvdata(dev, NULL);
-
return 0;
 }
 
-- 
1.7.1

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


[v3, 3/6] net: dpaa2: fix dependency of config FSL_DPAA2_ETH

2018-10-08 Thread Yangbo Lu
The NETDEVICES dependency and ETHERNET dependency hadn't
been required since dpaa2-eth was moved out of staging.
Also allowed COMPILE_TEST for dpaa2-eth.

Signed-off-by: Yangbo Lu 
---
Changes for v3:
- Added this patch.
---
 drivers/net/ethernet/freescale/dpaa2/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig 
b/drivers/net/ethernet/freescale/dpaa2/Kconfig
index 67e6461..a7f365d 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -1,7 +1,7 @@
 config FSL_DPAA2_ETH
tristate "Freescale DPAA2 Ethernet"
depends on FSL_MC_BUS && FSL_MC_DPIO
-   depends on NETDEVICES && ETHERNET
+   depends on ARCH_LAYERSCAPE || COMPILE_TEST
help
  This is the DPAA2 Ethernet driver supporting Freescale SoCs
  with DPAA2 (DataPath Acceleration Architecture v2).
-- 
1.7.1

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


[v3, 4/6] net: dpaa2: rename rtc as ptp in dpaa2-ptp driver

2018-10-08 Thread Yangbo Lu
In dpaa2-ptp driver, it's odd to use rtc in names of
some functions and structures except these dprtc APIs.
This patch is to use ptp instead of rtc in names.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added this patch.
Changes for v3:
- Modified commit message.
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index 2e90d5a..c73eef2 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -12,7 +12,7 @@
 #include "dpaa2-ptp.h"
 
 struct ptp_dpaa2_priv {
-   struct fsl_mc_device *rtc_mc_dev;
+   struct fsl_mc_device *ptp_mc_dev;
struct ptp_clock *clock;
struct ptp_clock_info caps;
u32 freq_comp;
@@ -23,7 +23,7 @@ static int ptp_dpaa2_adjfreq(struct ptp_clock_info *ptp, s32 
ppb)
 {
struct ptp_dpaa2_priv *ptp_dpaa2 =
container_of(ptp, struct ptp_dpaa2_priv, caps);
-   struct fsl_mc_device *mc_dev = ptp_dpaa2->rtc_mc_dev;
+   struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
struct device *dev = _dev->dev;
u64 adj;
u32 diff, tmr_add;
@@ -53,7 +53,7 @@ static int ptp_dpaa2_adjtime(struct ptp_clock_info *ptp, s64 
delta)
 {
struct ptp_dpaa2_priv *ptp_dpaa2 =
container_of(ptp, struct ptp_dpaa2_priv, caps);
-   struct fsl_mc_device *mc_dev = ptp_dpaa2->rtc_mc_dev;
+   struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
struct device *dev = _dev->dev;
s64 now;
int err = 0;
@@ -78,7 +78,7 @@ static int ptp_dpaa2_gettime(struct ptp_clock_info *ptp, 
struct timespec64 *ts)
 {
struct ptp_dpaa2_priv *ptp_dpaa2 =
container_of(ptp, struct ptp_dpaa2_priv, caps);
-   struct fsl_mc_device *mc_dev = ptp_dpaa2->rtc_mc_dev;
+   struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
struct device *dev = _dev->dev;
u64 ns;
u32 remainder;
@@ -100,7 +100,7 @@ static int ptp_dpaa2_settime(struct ptp_clock_info *ptp,
 {
struct ptp_dpaa2_priv *ptp_dpaa2 =
container_of(ptp, struct ptp_dpaa2_priv, caps);
-   struct fsl_mc_device *mc_dev = ptp_dpaa2->rtc_mc_dev;
+   struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
struct device *dev = _dev->dev;
u64 ns;
int err = 0;
@@ -129,7 +129,7 @@ static int ptp_dpaa2_settime(struct ptp_clock_info *ptp,
.settime64  = ptp_dpaa2_settime,
 };
 
-static int rtc_probe(struct fsl_mc_device *mc_dev)
+static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
 {
struct device *dev = _dev->dev;
struct ptp_dpaa2_priv *ptp_dpaa2;
@@ -153,7 +153,7 @@ static int rtc_probe(struct fsl_mc_device *mc_dev)
goto err_free_mcp;
}
 
-   ptp_dpaa2->rtc_mc_dev = mc_dev;
+   ptp_dpaa2->ptp_mc_dev = mc_dev;
 
err = dprtc_get_freq_compensation(mc_dev->mc_io, 0,
  mc_dev->mc_handle, _add);
@@ -187,7 +187,7 @@ static int rtc_probe(struct fsl_mc_device *mc_dev)
return err;
 }
 
-static int rtc_remove(struct fsl_mc_device *mc_dev)
+static int dpaa2_ptp_remove(struct fsl_mc_device *mc_dev)
 {
struct ptp_dpaa2_priv *ptp_dpaa2;
struct device *dev = _dev->dev;
@@ -204,26 +204,26 @@ static int rtc_remove(struct fsl_mc_device *mc_dev)
return 0;
 }
 
-static const struct fsl_mc_device_id rtc_match_id_table[] = {
+static const struct fsl_mc_device_id dpaa2_ptp_match_id_table[] = {
{
.vendor = FSL_MC_VENDOR_FREESCALE,
.obj_type = "dprtc",
},
{}
 };
-MODULE_DEVICE_TABLE(fslmc, rtc_match_id_table);
+MODULE_DEVICE_TABLE(fslmc, dpaa2_ptp_match_id_table);
 
-static struct fsl_mc_driver rtc_drv = {
+static struct fsl_mc_driver dpaa2_ptp_drv = {
.driver = {
.name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
-   .probe = rtc_probe,
-   .remove = rtc_remove,
-   .match_id_table = rtc_match_id_table,
+   .probe = dpaa2_ptp_probe,
+   .remove = dpaa2_ptp_remove,
+   .match_id_table = dpaa2_ptp_match_id_table,
 };
 
-module_fsl_mc_driver(rtc_drv);
+module_fsl_mc_driver(dpaa2_ptp_drv);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("DPAA2 PTP Clock Driver");
-- 
1.7.1

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


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-08 Thread Oscar Salvador
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add latency by 60%. Modify external
> providers of online callback to align with the change.
> 
> Signed-off-by: Arun KS 

Looks good to me.

Reviewed-by: Oscar Salvador 

Just one thing below:
  
> @@ -1331,7 +1331,7 @@ void __init __free_pages_bootmem(struct page *page, 
> unsigned long pfn,
>  {
>   if (early_page_uninitialised(pfn))
>   return;
> - return __free_pages_boot_core(page, order);
> + return __free_pages_core(page, order);

__free_pages_core is void, so I guess we do not need that return there.
Probably the code generated is the same though.
-- 
Oscar Salvador
SUSE L3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: emxx_udc: remove unused code

2018-10-08 Thread Loic Tourlonias
Remove useless code inside if_0 endif

Signed-off-by: Loic Tourlonias 
---
 drivers/staging/emxx_udc/emxx_udc.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.h 
b/drivers/staging/emxx_udc/emxx_udc.h
index 8337e38c238a..78fa60192a14 100644
--- a/drivers/staging/emxx_udc/emxx_udc.h
+++ b/drivers/staging/emxx_udc/emxx_udc.h
@@ -10,10 +10,6 @@
 
 /*---*/
 /*- Default undef */
-#if 0
-#define DEBUG
-#define UDC_DEBUG_DUMP
-#endif
 
 /*- Default define */
 #defineUSE_DMA 1
-- 
2.17.1

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