Re: [PATCH v3] staging: ralink-gdma: Use u32 over uint32_t

2019-03-22 Thread Joe Perches
On Fri, 2019-03-22 at 22:43 +0530, Bharath Vedartham wrote:
> This fixes the checkpatch.pl warning: "Prefer u32 over uint32_t"

Please run your proposed patches through checkpatch before
submitting them.

> Signed-off-by: Bharath Vedartham 
> ---
> Changes since v2
>   - Improved changelog
>   - Thanks for the good feedback. I am a beginner. I will learn
> and grow. :)

More feedback for you.

> diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
> b/drivers/staging/ralink-gdma/ralink-gdma.c
[]
> @@ -157,14 +157,14 @@ static struct gdma_dma_desc *to_gdma_dma_desc(struct 
> virt_dma_desc *vdesc)
>   return container_of(vdesc, struct gdma_dma_desc, vdesc);
>  }
>  
> -static inline uint32_t gdma_dma_read(struct gdma_dma_dev *dma_dev,
> +static inline u32 gdma_dma_read(struct gdma_dma_dev *dma_dev,
>unsigned int reg)

Please realign the line following your change.


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


Re: Help on testing ad5933 driver

2019-03-22 Thread Alexandru Ardelean
On Thu, Mar 21, 2019 at 9:39 PM Marcelo Schmitt
 wrote:
>
> Hello, would anyone mind helping me test ad5933 driver on actual
> hardware?  I went through this
> (https://oslongjourney.github.io/linux-kernel/experiment-one-iio-dummy/)
> tutorial so I was able to load iio_simple_dummy driver, create and
> inspect some dummy devices.  Now, as Jonathan has asked me, I would like
> to test ad5933 driver on an EVAL-AD5933 board which was donated to FLUSP
> (https://flusp.ime.usp.br/).
>
> So far I've been hesitating to plug this device on my Debian distro
> since this
> (https://www.analog.com/media/en/technical-documentation/user-guides/UG-364.pdf)
> user guide for Windows says not to connect it before driver
> installation. Is there something that could harm the board if plugged
> on a computer without a proper driver?
>

You should take into account that a lot of eval boards have their eval
SW written for Windows.
This is something of a legacy-thing, because most corporations have
been running their computers (for work & dev & offices) on Windows.

So, you shouldn't take things ad-literam (to the letter) when reading
stuff for Windows and when writing code for Linux.

> I also didn't understand the hardware configuration showed on this
> (https://wiki.analog.com/resources/tools-software/linux-drivers/iio-impedance-analyzer/ad5933)
> page.

Hmm, that doc was written a while ago.
The newer eval board doesn't look like the one in the wiki.

Also, since the eval SW was targeted for Windows, getting it to work
for Linux (and IIO) implies some hacking/reverse-engineering.
The reason for this (reverse-engineering) is because [traditionally]
eval boards are meant to highlight characteristics of the chip, so if
using Windows, this should be simple.

Unfortunately, the docs aren't helping in this case. So, in this case,
I would get some volt-meter & oscilloscope to help.
It looks to me that U2 is the AD5933 on the eval-board.
Worst case, you can solder directly to the pins and link them to a
Raspberry PI [on the I2C], power, ground, etc.
But, you can take a look at the T1 to T8 (if I didn't miss anything)
and connect to them, and see what each of them is for.
Hopefully, one of those test-points is for I2C, in which case you can
attach wires to them and connect them to a host.
I did not find a good doc for them yet.

But anyway, I would ask some HW guy to help here (because I'm a SW guy
mostly),and get help on figuring out the eval board

>
> Any advice will be greatly appreciated.
> Thanks in advance,
>
> Marcelo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v3] staging: ralink-gdma: Use u32 over uint32_t

2019-03-22 Thread Bharath Vedartham
This fixes the checkpatch.pl warning: "Prefer u32 over uint32_t"

Signed-off-by: Bharath Vedartham 
---
Changes since v2
- Improved changelog
- Thanks for the good feedback. I am a beginner. I will learn
  and grow. :)
---
 drivers/staging/ralink-gdma/ralink-gdma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
b/drivers/staging/ralink-gdma/ralink-gdma.c
index d78042e..7e824d3 100644
--- a/drivers/staging/ralink-gdma/ralink-gdma.c
+++ b/drivers/staging/ralink-gdma/ralink-gdma.c
@@ -157,14 +157,14 @@ static struct gdma_dma_desc *to_gdma_dma_desc(struct 
virt_dma_desc *vdesc)
return container_of(vdesc, struct gdma_dma_desc, vdesc);
 }
 
-static inline uint32_t gdma_dma_read(struct gdma_dma_dev *dma_dev,
+static inline u32 gdma_dma_read(struct gdma_dma_dev *dma_dev,
 unsigned int reg)
 {
return readl(dma_dev->base + reg);
 }
 
 static inline void gdma_dma_write(struct gdma_dma_dev *dma_dev,
- unsigned reg, uint32_t val)
+ unsigned reg, u32 val)
 {
writel(val, dma_dev->base + reg);
 }
@@ -283,7 +283,7 @@ static int rt305x_gdma_start_transfer(struct 
gdma_dmaengine_chan *chan)
struct gdma_dma_dev *dma_dev = gdma_dma_chan_get_dev(chan);
dma_addr_t src_addr, dst_addr;
struct gdma_dma_sg *sg;
-   uint32_t ctrl0, ctrl1;
+   u32 ctrl0, ctrl1;
 
/* verify chan is already stopped */
ctrl0 = gdma_dma_read(dma_dev, GDMA_REG_CTRL0(chan->id));
@@ -361,7 +361,7 @@ static int rt3883_gdma_start_transfer(struct 
gdma_dmaengine_chan *chan)
struct gdma_dma_dev *dma_dev = gdma_dma_chan_get_dev(chan);
dma_addr_t src_addr, dst_addr;
struct gdma_dma_sg *sg;
-   uint32_t ctrl0, ctrl1;
+   u32 ctrl0, ctrl1;
 
/* verify chan is already stopped */
ctrl0 = gdma_dma_read(dma_dev, GDMA_REG_CTRL0(chan->id));
@@ -753,7 +753,7 @@ static void gdma_dma_tasklet(unsigned long arg)
 
 static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_RT305X_GCT, GDMA_REG_GCT_ARBIT_RR);
@@ -767,7 +767,7 @@ static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 
 static void rt3883_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_REG_GCT, GDMA_REG_GCT_ARBIT_RR);
-- 
2.7.4

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


Re: [PATCH v2] staging: ralink-gdma: Change uint32_t to u32

2019-03-22 Thread Greg KH
On Fri, Mar 22, 2019 at 06:35:07PM +0530, Bharath Vedartham wrote:
> Change occurences of uint32_t to u32 to fix checkpatch.pl warnings.
> 
> Signed-off-by: Bharath Vedartham 
> ---
> Changes since v1:
>   - Improved changelog.

I have 3 "v2" patches from you :(

I have no idea which one is the "correct" one, so I am dropping them
all.

Please fix up, and resend a "v3" patch, and only one copy of it.

thanks,

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


Re: [PATCH] spi: mt7621: Move SPI driver out of staging

2019-03-22 Thread Stefan Roese

On 21.03.19 15:25, Mark Brown wrote:

On Thu, Mar 14, 2019 at 12:52:12PM +0100, Stefan Roese wrote:

This looks pretty good, a few trivial issues below but nothing major I
think.


+config SPI_MT7621
+   tristate "MediaTek MT7621 SPI Controller"
+   depends on RALINK
+   help
+ This selects a driver for the MediaTek MT7621 SPI Controller.
+


I'm not seeing any build time dependency on this, please add an ||
COMPILE_TEST to help with build testing.


Okay, will add in v2.
 

@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
+ *


Please make the entire comment a C++ one to


Will change in v2.
 

+ * Some parts are based on spi-orion.c:
+ *   Author: Shadi Ammouri 
+ *   Copyright (C) 2007-2008 Marvell Ltd.


That driver dates from 2008 AFAICT, and had some changes after then?


The spi-orion driver? I didn't check. That's what in the header of
this driver since quite some time. And I didn't want to change any
copyright notices.

BTW: spi-orion still has the same copyright message.
 

+static void mt7621_spi_set_cs(struct spi_device *spi, int enable)
+{
+   struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
+   int cs = spi->chip_select;
+   u32 polar = 0;
+
+   mt7621_spi_reset(rs);
+   if (enable)
+   polar = BIT(cs);
+   mt7621_spi_write(rs, MT7621_SPI_POLAR, polar);
+}


Will doing a reset mess up the rate configuration and stuff that's done
in _prepare(), or is _reset() perhaps not an entirely accurate name?


You are correct. The function name is not really matching its
implementation. Will change in v2.
 

+   list_for_each_entry(t, >transfers, transfer_list)
+   if (t->speed_hz < speed)
+   speed = t->speed_hz;


This should be in the core if it's needed, it's going to be the same for
all drivers.


I'm not sure here, other drivers might set the speed individually for
each "spi_transfer" entry. In this driver its set only once: before
beginning to transfer all entries. So should I really move this into
the core and set all speed_hz values to the minimum one of the list?
 

+   master->setup = mt7621_spi_setup;
+   master->transfer_one_message = mt7621_spi_transfer_one_message;
+   master->bits_per_word_mask = SPI_BPW_MASK(8);
+   master->dev.of_node = pdev->dev.of_node;
+   master->num_chipselect = 2;


The driver should set SPI_CONTROLLER_HALF_DUPLEX in flags.


Will update in v2.
 

+   clk_disable(rs->clk);


This needs to be clk_disable_unprepare() to ensure the clock is
unprepared as well as disabled.


Okay, will change in v2.
 

+   spi_unregister_master(master);


Just use devm_spi_register_controller()?  The _master() name is legacy
and devm_ would make life easier.


Yes, will change in v2.

Thanks for the review.

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


[PATCH] staging: rtl8188eu: remove unnecessary parentheses

2019-03-22 Thread Michael Straube
Remove unnecessary parentheses in rtl8188eu_xmit.c.
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 9e5f23392d58..ab94ad9d608a 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -168,7 +168,7 @@ static s32 update_txdesc(struct xmit_frame *pxmitframe, u8 
*pmem, s32 sz, u8 bag
struct odm_dm_struct *odmpriv = >HalData->odmpriv;
struct tx_desc *ptxdesc = (struct tx_desc *)pmem;
struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
-   struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
+   struct mlme_ext_info *pmlmeinfo = >mlmext_info;
 
if (adapt->registrypriv.mp_mode == 0) {
if ((!bagg_pkt) && (urb_zero_packet_chk(adapt, sz) == 0)) {
@@ -486,23 +486,23 @@ bool rtl8188eu_xmitframe_complete(struct adapter *adapt,
switch (pfirstframe->attrib.priority) {
case 1:
case 2:
-   ptxservq = &(psta->sta_xmitpriv.bk_q);
+   ptxservq = >sta_xmitpriv.bk_q;
phwxmit = pxmitpriv->hwxmits + 3;
break;
case 4:
case 5:
-   ptxservq = &(psta->sta_xmitpriv.vi_q);
+   ptxservq = >sta_xmitpriv.vi_q;
phwxmit = pxmitpriv->hwxmits + 1;
break;
case 6:
case 7:
-   ptxservq = &(psta->sta_xmitpriv.vo_q);
+   ptxservq = >sta_xmitpriv.vo_q;
phwxmit = pxmitpriv->hwxmits;
break;
case 0:
case 3:
default:
-   ptxservq = &(psta->sta_xmitpriv.be_q);
+   ptxservq = >sta_xmitpriv.be_q;
phwxmit = pxmitpriv->hwxmits + 2;
break;
}
-- 
2.21.0

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


[PATCH v2] staging: ralink-gdma: Change uint32_t to u32

2019-03-22 Thread Bharath Vedartham
Change occurences of uint32_t to u32 to fix checkpatch.pl warnings.

Signed-off-by: Bharath Vedartham 
---
Changes since v1:
- Improved changelog.
---
---
 drivers/staging/ralink-gdma/ralink-gdma.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
b/drivers/staging/ralink-gdma/ralink-gdma.c
index 2c19287..7e824d3 100644
--- a/drivers/staging/ralink-gdma/ralink-gdma.c
+++ b/drivers/staging/ralink-gdma/ralink-gdma.c
@@ -157,14 +157,14 @@ static struct gdma_dma_desc *to_gdma_dma_desc(struct 
virt_dma_desc *vdesc)
return container_of(vdesc, struct gdma_dma_desc, vdesc);
 }
 
-static inline uint32_t gdma_dma_read(struct gdma_dma_dev *dma_dev,
+static inline u32 gdma_dma_read(struct gdma_dma_dev *dma_dev,
 unsigned int reg)
 {
return readl(dma_dev->base + reg);
 }
 
 static inline void gdma_dma_write(struct gdma_dma_dev *dma_dev,
- unsigned reg, uint32_t val)
+ unsigned reg, u32 val)
 {
writel(val, dma_dev->base + reg);
 }
@@ -283,7 +283,7 @@ static int rt305x_gdma_start_transfer(struct 
gdma_dmaengine_chan *chan)
struct gdma_dma_dev *dma_dev = gdma_dma_chan_get_dev(chan);
dma_addr_t src_addr, dst_addr;
struct gdma_dma_sg *sg;
-   uint32_t ctrl0, ctrl1;
+   u32 ctrl0, ctrl1;
 
/* verify chan is already stopped */
ctrl0 = gdma_dma_read(dma_dev, GDMA_REG_CTRL0(chan->id));
@@ -753,7 +753,7 @@ static void gdma_dma_tasklet(unsigned long arg)
 
 static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_RT305X_GCT, GDMA_REG_GCT_ARBIT_RR);
@@ -767,7 +767,7 @@ static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 
 static void rt3883_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_REG_GCT, GDMA_REG_GCT_ARBIT_RR);
-- 
2.7.4

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


[PATCH v2] staging: ralink-gdma: Change uint32_t to u32

2019-03-22 Thread Bharath Vedartham
Change occurences of uint32_t to u32 to fix checkpatch.pl warning

Signed-off-by: Bharath Vedartham 
---
Changes since v1:
-Improved the changelog.
---
 drivers/staging/ralink-gdma/ralink-gdma.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
b/drivers/staging/ralink-gdma/ralink-gdma.c
index 2c19287..7e824d3 100644
--- a/drivers/staging/ralink-gdma/ralink-gdma.c
+++ b/drivers/staging/ralink-gdma/ralink-gdma.c
@@ -157,14 +157,14 @@ static struct gdma_dma_desc *to_gdma_dma_desc(struct 
virt_dma_desc *vdesc)
return container_of(vdesc, struct gdma_dma_desc, vdesc);
 }
 
-static inline uint32_t gdma_dma_read(struct gdma_dma_dev *dma_dev,
+static inline u32 gdma_dma_read(struct gdma_dma_dev *dma_dev,
 unsigned int reg)
 {
return readl(dma_dev->base + reg);
 }
 
 static inline void gdma_dma_write(struct gdma_dma_dev *dma_dev,
- unsigned reg, uint32_t val)
+ unsigned reg, u32 val)
 {
writel(val, dma_dev->base + reg);
 }
@@ -283,7 +283,7 @@ static int rt305x_gdma_start_transfer(struct 
gdma_dmaengine_chan *chan)
struct gdma_dma_dev *dma_dev = gdma_dma_chan_get_dev(chan);
dma_addr_t src_addr, dst_addr;
struct gdma_dma_sg *sg;
-   uint32_t ctrl0, ctrl1;
+   u32 ctrl0, ctrl1;
 
/* verify chan is already stopped */
ctrl0 = gdma_dma_read(dma_dev, GDMA_REG_CTRL0(chan->id));
@@ -753,7 +753,7 @@ static void gdma_dma_tasklet(unsigned long arg)
 
 static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_RT305X_GCT, GDMA_REG_GCT_ARBIT_RR);
@@ -767,7 +767,7 @@ static void rt305x_gdma_init(struct gdma_dma_dev *dma_dev)
 
 static void rt3883_gdma_init(struct gdma_dma_dev *dma_dev)
 {
-   uint32_t gct;
+   u32 gct;
 
/* all chans round robin */
gdma_dma_write(dma_dev, GDMA_REG_GCT, GDMA_REG_GCT_ARBIT_RR);
-- 
2.7.4

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


Re: [PATCH] staging: ralink-gdma: Change uint32_t to u32

2019-03-22 Thread Bharath Vedartham
On Fri, Mar 22, 2019 at 01:01:40PM +0300, Dan Carpenter wrote:
> On Fri, Mar 22, 2019 at 12:55:02AM +0530, Bharath Vedartham wrote:
> > This is a follow up on my previous patch. Change occurences of the
>   ^
I did not send a patch set. I should have worded my changelog better.
Thanks for the feedback. This was just one patch.
> Put this sort of information under the --- cut off below the Sign off.
> 
> > stdint type uint32_t to its shortened type u32. This fixed the 
> > checkpatch.pl warning: "Prefer u32 over uint32_t".
> 
> This line is too long.  Limit it to 72 characters.
> 
Yes will do that.
> > 
> > Signed-off-by: Bharath Vedartham 
> > ---
>   ^^^
Got it. Thanks for the feedback.
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[RFC PATCH] staging: most: set_cfg_buffer_size() can be static

2019-03-22 Thread kbuild test robot


Fixes: 7c85575b16e9 ("staging: most: enable configfs support")
Signed-off-by: kbuild test robot 
---
 configfs.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/most/configfs.c b/drivers/staging/most/configfs.c
index cefce69..36d40d7 100644
--- a/drivers/staging/most/configfs.c
+++ b/drivers/staging/most/configfs.c
@@ -31,7 +31,7 @@ struct mdev_link {
char param[MAX_LEN];
 };
 
-int set_cfg_buffer_size(struct mdev_link *link)
+static int set_cfg_buffer_size(struct mdev_link *link)
 {
if (!link->buffer_size)
return -ENODATA;
@@ -39,7 +39,7 @@ int set_cfg_buffer_size(struct mdev_link *link)
link->buffer_size);
 }
 
-int set_cfg_subbuffer_size(struct mdev_link *link)
+static int set_cfg_subbuffer_size(struct mdev_link *link)
 {
if (!link->subbuffer_size)
return -ENODATA;
@@ -47,7 +47,7 @@ int set_cfg_subbuffer_size(struct mdev_link *link)
   link->subbuffer_size);
 }
 
-int set_cfg_dbr_size(struct mdev_link *link)
+static int set_cfg_dbr_size(struct mdev_link *link)
 {
if (!link->dbr_size)
return -ENODATA;
@@ -55,7 +55,7 @@ int set_cfg_dbr_size(struct mdev_link *link)
 link->dbr_size);
 }
 
-int set_cfg_num_buffers(struct mdev_link *link)
+static int set_cfg_num_buffers(struct mdev_link *link)
 {
if (!link->num_buffers)
return -ENODATA;
@@ -63,7 +63,7 @@ int set_cfg_num_buffers(struct mdev_link *link)
link->num_buffers);
 }
 
-int set_cfg_packets_xact(struct mdev_link *link)
+static int set_cfg_packets_xact(struct mdev_link *link)
 {
if (!link->packets_per_xact)
return -ENODATA;
@@ -71,7 +71,7 @@ int set_cfg_packets_xact(struct mdev_link *link)
 link->packets_per_xact);
 }
 
-int set_cfg_direction(struct mdev_link *link)
+static int set_cfg_direction(struct mdev_link *link)
 {
if (!strlen(link->direction))
return -ENODATA;
@@ -79,7 +79,7 @@ int set_cfg_direction(struct mdev_link *link)
  link->direction);
 }
 
-int set_cfg_datatype(struct mdev_link *link)
+static int set_cfg_datatype(struct mdev_link *link)
 {
if (!strlen(link->datatype))
return -ENODATA;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 05/14] staging: most: enable configfs support

2019-03-22 Thread kbuild test robot
Hi Christian,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v5.1-rc1 next-20190321]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christian-Gromm/staging-most-switch-to-configfs/20190322-075523
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/most/configfs.c:34:5: sparse: symbol 'set_cfg_buffer_size' 
>> was not declared. Should it be static?
>> drivers/staging/most/configfs.c:42:5: sparse: symbol 
>> 'set_cfg_subbuffer_size' was not declared. Should it be static?
>> drivers/staging/most/configfs.c:50:5: sparse: symbol 'set_cfg_dbr_size' was 
>> not declared. Should it be static?
>> drivers/staging/most/configfs.c:58:5: sparse: symbol 'set_cfg_num_buffers' 
>> was not declared. Should it be static?
>> drivers/staging/most/configfs.c:66:5: sparse: symbol 'set_cfg_packets_xact' 
>> was not declared. Should it be static?
>> drivers/staging/most/configfs.c:74:5: sparse: symbol 'set_cfg_direction' was 
>> not declared. Should it be static?
>> drivers/staging/most/configfs.c:82:5: sparse: symbol 'set_cfg_datatype' was 
>> not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 01/14] staging: most: add new file configfs.c

2019-03-22 Thread Dan Carpenter
On Thu, Mar 21, 2019 at 02:26:02PM +0100, Christian Gromm wrote:
> +static ssize_t mdev_link_direction_store(struct config_item *item,
> +  const char *page, size_t count)
> +{
> + struct mdev_link *mdev_link = to_mdev_link(item);
> + char *buf = (char *)page;
> +
> + if (strcmp(buf, "dir_rx\n") && strcmp(buf, "rx\n") &&
> + strcmp(buf, "dir_tx\n") && strcmp(buf, "tx\n"))

Please use sysfs_streq() here instead of strcmp().  It's ugly to
require that the input has a \n char.  Same for everything.

regards,
dan carpenter

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


Re: [PATCH 01/14] staging: most: add new file configfs.c

2019-03-22 Thread Dan Carpenter
On Thu, Mar 21, 2019 at 02:26:02PM +0100, Christian Gromm wrote:
> This patch adds the file configfs.c to the driver directory. The file
> registers the necessary subsystems with configfs in order to move the
> driver configuration from sysfs to configfs.
> 
> Signed-off-by: Christian Gromm 
> ---
>  drivers/staging/most/configfs.c | 659 
> 
>  1 file changed, 659 insertions(+)
>  create mode 100644 drivers/staging/most/configfs.c
> 
> diff --git a/drivers/staging/most/configfs.c b/drivers/staging/most/configfs.c
> new file mode 100644
> index 000..cefce69
> --- /dev/null
> +++ b/drivers/staging/most/configfs.c
> @@ -0,0 +1,659 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * configfs.c - Implementation of configfs interface to the driver stack
> + *
> + * Copyright (C) 2013-2015 Microchip Technology Germany II GmbH & Co. KG
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_LEN 30
> +
> +struct mdev_link {
> + struct config_item item;
> + int create;
> + u16 num_buffers;
> + u16 buffer_size;
> + u16 subbuffer_size;
> + u16 packets_per_xact;
> + u16 dbr_size;
> + char datatype[MAX_LEN];
> + char direction[MAX_LEN];
> + char name[MAX_LEN];
> + char mdev[MAX_LEN];
> + char channel[MAX_LEN];
> + char comp[MAX_LEN];
> + char param[MAX_LEN];
> +};
> +
> +int set_cfg_buffer_size(struct mdev_link *link)
   ^^^
Please run Sparse over your code.  This should be static.

> +{
> + if (!link->buffer_size)
> + return -ENODATA;
> + return most_set_cfg_buffer_size(link->mdev, link->channel,
> + link->buffer_size);
> +}
> +
> +int set_cfg_subbuffer_size(struct mdev_link *link)
> +{
> + if (!link->subbuffer_size)
> + return -ENODATA;
> + return most_set_cfg_subbuffer_size(link->mdev, link->channel,
> +link->subbuffer_size);
> +}
> +
> +int set_cfg_dbr_size(struct mdev_link *link)
> +{
> + if (!link->dbr_size)
> + return -ENODATA;
> + return most_set_cfg_dbr_size(link->mdev, link->channel,
> +  link->dbr_size);
> +}
> +
> +int set_cfg_num_buffers(struct mdev_link *link)
> +{
> + if (!link->num_buffers)
> + return -ENODATA;
> + return most_set_cfg_num_buffers(link->mdev, link->channel,
> + link->num_buffers);
> +}
> +
> +int set_cfg_packets_xact(struct mdev_link *link)
> +{
> + if (!link->packets_per_xact)
> + return -ENODATA;
> + return most_set_cfg_packets_xact(link->mdev, link->channel,
> +  link->packets_per_xact);
> +}
> +
> +int set_cfg_direction(struct mdev_link *link)
> +{
> + if (!strlen(link->direction))
> + return -ENODATA;
> + return most_set_cfg_direction(link->mdev, link->channel,
> +   link->direction);
> +}
> +
> +int set_cfg_datatype(struct mdev_link *link)
> +{
> + if (!strlen(link->datatype))
> + return -ENODATA;
> + return most_set_cfg_datatype(link->mdev, link->channel,
> +  link->datatype);
> +}
> +
> +static int (*set_config_val[])(struct mdev_link *link) = {
> + set_cfg_buffer_size,
> + set_cfg_subbuffer_size,
> + set_cfg_dbr_size,
> + set_cfg_num_buffers,
> + set_cfg_packets_xact,
> + set_cfg_direction,
> + set_cfg_datatype,
> +};
> +
> +static inline struct mdev_link *to_mdev_link(struct config_item *item)
  ^^
No need to mark this as inline.  The compiler is smart enough to do it
automatically.

> +{
> + return item ? container_of(item, struct mdev_link, item) : NULL;

None of the callers check the return...  Just do:

return container_of(item, struct mdev_link, item);


> +}
> +
> +static ssize_t mdev_link_create_show(struct config_item *item, char *page)
> +{
> + return sprintf(page, "%d\n", to_mdev_link(item)->create);
> +}
> +
> +static ssize_t mdev_link_create_store(struct config_item *item,
> +   const char *page, size_t count)
> +{
> + struct mdev_link *mdev_link = to_mdev_link(item);
> + u16 tmp;
> + int ret;
> + int i;
> + char *p = (char *)page;
> +
> + ret = kstrtou16(p, 0, );
> + if (ret)
> + return ret;
> + if (tmp > 1)
> + return -ERANGE;
> +
> + for (i = 0; i < ARRAY_SIZE(set_config_val); i++) {
> + ret = set_config_val[i](mdev_link);
> + if (ret < 0) {
> + pr_err("Config failed\n");

This error message is not very useful.

> + return ret;
> + }
> + }
> +
> + if (!mdev_link->mdev || !mdev_link->channel || !mdev_link->comp) {
 

Re: [PATCH] Staging: comedi: ni_mio_common.c: Added blank line after declarations

2019-03-22 Thread Ian Abbott

On 21/03/2019 19:18, Arash Fotouhi wrote:

Added blank line after declarations.

Signed-off-by: Arash Fotouhi 
---
  drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 5edf59a..c6aff8f 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -2110,6 +2110,7 @@ static int ni_ai_cmdtest(struct comedi_device *dev, 
struct comedi_subdevice *s,
  
  	if (cmd->scan_begin_src == TRIG_TIMER) {

unsigned int tmp = cmd->scan_begin_arg;
+
cmd->scan_begin_arg =
ni_timer_to_ns(dev, ni_ns_to_timer(dev,
   cmd->scan_begin_arg,
@@ -2120,6 +2121,7 @@ static int ni_ai_cmdtest(struct comedi_device *dev, 
struct comedi_subdevice *s,
if (cmd->convert_src == TRIG_TIMER) {
if (!devpriv->is_611x && !devpriv->is_6143) {
unsigned int tmp = cmd->convert_arg;
+
cmd->convert_arg =
ni_timer_to_ns(dev, ni_ns_to_timer(dev,
   cmd->convert_arg,



Looks good, thanks.

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott  || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268.  Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: Help on testing ad5933 driver

2019-03-22 Thread Dan Carpenter
On Thu, Mar 21, 2019 at 04:39:13PM -0300, Marcelo Schmitt wrote:
> Hello, would anyone mind helping me test ad5933 driver on actual
> hardware?  I went through this
> (https://oslongjourney.github.io/linux-kernel/experiment-one-iio-dummy/)
> tutorial so I was able to load iio_simple_dummy driver, create and
> inspect some dummy devices.  Now, as Jonathan has asked me, I would like
> to test ad5933 driver on an EVAL-AD5933 board which was donated to FLUSP
> (https://flusp.ime.usp.br/).
> 
> So far I've been hesitating to plug this device on my Debian distro
> since this
> (https://www.analog.com/media/en/technical-documentation/user-guides/UG-364.pdf)
> user guide for Windows says not to connect it before driver
> installation. Is there something that could harm the board if plugged
> on a computer without a proper driver?

The kernel shouldn't be bricking hardware...  Hardware used to be easier
to brick in olden times...

regards,
dan carpenter

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


Re: [PATCH] staging: ralink-gdma: Change uint32_t to u32

2019-03-22 Thread Dan Carpenter
On Fri, Mar 22, 2019 at 12:55:02AM +0530, Bharath Vedartham wrote:
> This is a follow up on my previous patch. Change occurences of the
  ^
Put this sort of information under the --- cut off below the Sign off.

> stdint type uint32_t to its shortened type u32. This fixed the checkpatch.pl 
> warning: "Prefer u32 over uint32_t".

This line is too long.  Limit it to 72 characters.

> 
> Signed-off-by: Bharath Vedartham 
> ---
  ^^^

regards,
dan carpenter

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