Re: [PATCH] Clarify expression which uses both multiplication and pointer dereference
On Sun, May 17, 2015 at 07:18:42PM +0200, Alex Dowad wrote:
> This fixes a checkpatch style error in vpfe_buffer_queue_setup.
>
> Signed-off-by: Alex Dowad
> ---
> drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> index 06d48d5..04a687c 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -1095,7 +1095,7 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq, const
> struct v4l2_format *fmt,
> size = video->fmt.fmt.pix.sizeimage;
>
> if (vpfe_dev->video_limit) {
> - while (size * *nbuffers > vpfe_dev->video_limit)
> + while (size * (*nbuffers) > vpfe_dev->video_limit)
> (*nbuffers)--;
> }
> if (pipe->state == VPFE_PIPELINE_STREAM_CONTINUOUS) {
Style issue aside, is there a reason not to use
if (size * *nbuffers > vpfe_dev->video_limit)
*nbuffers = vpfe_dev->video_limit / size;
instead?
Michal Kubecek
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: wilc1000: Add SDIO/SPI 802.11 driver
Was the patch sent to the list? Maybe it was rejected for being too large? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Clarify expression which uses both multiplication and pointer dereference
On Mon, May 18, 2015 at 7:51 AM, Michal Kubecek wrote:
> On Sun, May 17, 2015 at 07:18:42PM +0200, Alex Dowad wrote:
>> This fixes a checkpatch style error in vpfe_buffer_queue_setup.
>>
>> Signed-off-by: Alex Dowad
>> ---
>> drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
>> b/drivers/staging/media/davinci_vpfe/vpfe_video.c
>> index 06d48d5..04a687c 100644
>> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
>> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
>> @@ -1095,7 +1095,7 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq, const
>> struct v4l2_format *fmt,
>> size = video->fmt.fmt.pix.sizeimage;
>>
>> if (vpfe_dev->video_limit) {
>> - while (size * *nbuffers > vpfe_dev->video_limit)
>> + while (size * (*nbuffers) > vpfe_dev->video_limit)
>> (*nbuffers)--;
>> }
>> if (pipe->state == VPFE_PIPELINE_STREAM_CONTINUOUS) {
>
> Style issue aside, is there a reason not to use
>
> if (size * *nbuffers > vpfe_dev->video_limit)
> *nbuffers = vpfe_dev->video_limit / size;
>
> instead?
>
I would prefer this.
Cheers,
--Prabhakar Lad
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Clarify expression which uses both multiplication and pointer dereference
On 05/18/2015 10:06 AM, Lad, Prabhakar wrote:
> On Mon, May 18, 2015 at 7:51 AM, Michal Kubecek wrote:
>> On Sun, May 17, 2015 at 07:18:42PM +0200, Alex Dowad wrote:
>>> This fixes a checkpatch style error in vpfe_buffer_queue_setup.
>>>
>>> Signed-off-by: Alex Dowad
>>> ---
>>> drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
>>> b/drivers/staging/media/davinci_vpfe/vpfe_video.c
>>> index 06d48d5..04a687c 100644
>>> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
>>> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
>>> @@ -1095,7 +1095,7 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq, const
>>> struct v4l2_format *fmt,
>>> size = video->fmt.fmt.pix.sizeimage;
>>>
>>> if (vpfe_dev->video_limit) {
>>> - while (size * *nbuffers > vpfe_dev->video_limit)
>>> + while (size * (*nbuffers) > vpfe_dev->video_limit)
>>> (*nbuffers)--;
>>> }
>>> if (pipe->state == VPFE_PIPELINE_STREAM_CONTINUOUS) {
>>
>> Style issue aside, is there a reason not to use
>>
>> if (size * *nbuffers > vpfe_dev->video_limit)
>> *nbuffers = vpfe_dev->video_limit / size;
>>
>> instead?
>>
> I would prefer this.
As far as I can see video_limit is never set at all, so this code (and the
video_limit
field) can just be removed.
I think this is a left-over from old code, long since removed.
Regards,
Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: wilc1000: Add SDIO/SPI 802.11 driver
Le 18/05/2015 10:04, Dan Carpenter a écrit : > Was the patch sent to the list? Maybe it was rejected for being too > large? Yep is seems: it appears on driverdev-devel: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-May/069148.html But it seems not on linux-wireless. Bye, -- Nicolas Ferre ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fixed coding style issues at ieee80211_crypt_wep.c
Also the use a subsystem prefix in the subject: [PATCH] Staging: rtl8192u: whatever... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 03/33] staging: rtl8192e: Mark unaligned memcpy()
On Sun, May 17, 2015 at 10:38:48PM +0200, Mateusz Kulikowski wrote:
> On 15.05.2015 01:14, Dan Carpenter wrote:
> > On Thu, May 14, 2015 at 10:29:39PM +0200, Mateusz Kulikowski wrote:
> >> On 13.05.2015 10:22, Dan Carpenter wrote:
> >>> On Tue, May 12, 2015 at 10:00:13PM +0200, Mateusz Kulikowski wrote:
> On 11.05.2015 10:26, Dan Carpenter wrote:
> >> (...)
> >
> > Which part isn't aligned? I think they both are.
> >
> struct rtllib_rxb *prxb = prxbIndicateArray[j];
>
> struct rtllib_rxb {
> u8 nr_subframes;
> struct sk_buff *subframes[MAX_SUBFRAME_COUNT == 64];
> u8 dst[ETH_ALEN]; // here
> u8 src[ETH_ALEN]; // here
> } __packed;
> (...)
> >
> > I'm not positive it's "by design" though, this is staging code so maybe
> > they just added __packed to every struct. In fact, I'm pretty sure
> > unaligned pointers don't work on some arches so the __packed is probably
> > a bug.
> >
>
> I doubt anyone uses it on anything else than some low cost x86 netbooks.
>
Generally though, there shouldn't be pointers in __packed structs.
__packed means we care about alignment very much, probably more than we
care about speed. So it means we are sharing the data with the hardware
or with userspace which requires a specific layout. We shouldn't be
giving kernel pointers to userspace or the hardware. (These are rules
of thumb).
> I removed __packed and did a small test today (download 10mb of garbage,
> check md5)
> - it doesn't seem to affect driver (on staging-testing, without this
> patchset).
>
> Nevertheless I would prefer to leave it like that for this patch set if it's
> OK with you and perhaps include it for next series I'll work on.
I think Greg asked for a v4 of this patchset? You can leave the code
as is if you want. :) You didn't introduce the bug and I'm not your
boss. :P
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: unisys: fix function declaration format in visorchipset.c
This is a patch that fixes the function declarations in
visorbus/visorchipset.c by removing newlines after the function return
type
Signed-off-by: Wim de With
---
drivers/staging/unisys/visorbus/visorchipset.c | 225 ++---
1 file changed, 85 insertions(+), 140 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index ca22f49..f9192b6 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -63,8 +63,7 @@ static int visorchipset_visorbusregwait = 1; /* default is
on */
static int visorchipset_holdchipsetready;
static unsigned long controlvm_payload_bytes_buffered;
-static int
-visorchipset_open(struct inode *inode, struct file *file)
+static int visorchipset_open(struct inode *inode, struct file *file)
{
unsigned minor_number = iminor(inode);
@@ -74,8 +73,7 @@ visorchipset_open(struct inode *inode, struct file *file)
return 0;
}
-static int
-visorchipset_release(struct inode *inode, struct file *file)
+static int visorchipset_release(struct inode *inode, struct file *file)
{
return 0;
}
@@ -375,8 +373,8 @@ static void controlvm_respond_physdev_changestate(
static void parser_done(struct parser_context *ctx);
-static struct parser_context *
-parser_init_byte_stream(u64 addr, u32 bytes, bool local, bool *retry)
+static struct parser_context *parser_init_byte_stream(u64 addr, u32 bytes,
+ bool local, bool *retry)
{
int allocbytes = sizeof(struct parser_context) + bytes;
struct parser_context *rc = NULL;
@@ -451,8 +449,7 @@ cleanup:
return rc;
}
-static uuid_le
-parser_id_get(struct parser_context *ctx)
+static uuid_le parser_id_get(struct parser_context *ctx)
{
struct spar_controlvm_parameters_header *phdr = NULL;
@@ -473,8 +470,7 @@ enum PARSER_WHICH_STRING {
PARSERSTRING_NAME, /* TODO: only PARSERSTRING_NAME is used ? */
};
-static void
-parser_param_start(struct parser_context *ctx,
+static void parser_param_start(struct parser_context *ctx,
enum PARSER_WHICH_STRING which_string)
{
struct spar_controlvm_parameters_header *phdr = NULL;
@@ -515,8 +511,7 @@ static void parser_done(struct parser_context *ctx)
kfree(ctx);
}
-static void *
-parser_string_get(struct parser_context *ctx)
+static void *parser_string_get(struct parser_context *ctx)
{
u8 *pscan;
unsigned long nscan;
@@ -707,8 +702,7 @@ static ssize_t remaining_steps_store(struct device *dev,
return count;
}
-static void
-bus_info_clear(void *v)
+static void bus_info_clear(void *v)
{
struct visorchipset_bus_info *p = (struct visorchipset_bus_info *) v;
@@ -717,8 +711,7 @@ bus_info_clear(void *v)
memset(p, 0, sizeof(struct visorchipset_bus_info));
}
-static void
-dev_info_clear(void *v)
+static void dev_info_clear(void *v)
{
struct visorchipset_device_info *p =
(struct visorchipset_device_info *) v;
@@ -726,8 +719,8 @@ dev_info_clear(void *v)
memset(p, 0, sizeof(struct visorchipset_device_info));
}
-static struct visorchipset_bus_info *
-bus_find(struct list_head *list, u32 bus_no)
+static struct visorchipset_bus_info *bus_find(struct list_head *list,
+ u32 bus_no)
{
struct visorchipset_bus_info *p;
@@ -739,8 +732,8 @@ bus_find(struct list_head *list, u32 bus_no)
return NULL;
}
-static struct visorchipset_device_info *
-device_find(struct list_head *list, u32 bus_no, u32 dev_no)
+static struct visorchipset_device_info *device_find(struct list_head *list,
+ u32 bus_no, u32 dev_no)
{
struct visorchipset_device_info *p;
@@ -764,8 +757,7 @@ static void busdevices_del(struct list_head *list, u32
bus_no)
}
}
-static u8
-check_chipset_events(void)
+static u8 check_chipset_events(void)
{
int i;
u8 send_msg = 1;
@@ -775,8 +767,7 @@ check_chipset_events(void)
return send_msg;
}
-static void
-clear_chipset_events(void)
+static void clear_chipset_events(void)
{
int i;
/* Clear chipset_events */
@@ -784,8 +775,7 @@ clear_chipset_events(void)
chipset_events[i] = 0;
}
-void
-visorchipset_register_busdev(
+void visorchipset_register_busdev(
struct visorchipset_busdev_notifiers *notifiers,
struct visorchipset_busdev_responders *responders,
struct ultra_vbus_deviceinfo *driver_info)
@@ -809,8 +799,7 @@ visorchipset_register_busdev(
}
EXPORT_SYMBOL_GPL(visorchipset_register_busdev);
-static void
-cleanup_controlvm_structures(void)
+static void cleanup_controlvm_structures(void)
{
struct visorchipset_bus_info *bi, *tmp_bi;
struct visorchipset_device_info *di, *tmp_
[RFC] Driver for Arduino-as-I2C-adapter
Hi, For a project I needed to communicate with external hardware via the I2C protocol. I took a look at the existing drivers in the linux kernel source "drivers/i2c/busses". Instead of buying yet another interface dongle (this time for I2C) I decided to use an Arduino with an apropriate sketch as I2C adapter. Currently I access the I2C adapter (Arduino) via a custom program reading/writing to /dev/ttyACM0. Do you think it would make sense to add an I2C driver to the Linux kernel for an "Arduino as I2C adapter" solution? Or could you propose another solution? Maybe just an "external" module like the nvidia kernel module? greetings, Bernhard -- Wer nicht gelegentlich auch einmal kausalwidrige Dinge zu denken vermag, wird seine Wissenschaft nie um eine neue Idee bereichern können. Max Planck (1858-1947) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: unisys: fix function declaration format in visorchipset.c
On Mon, May 18, 2015 at 11:45:49AM +0200, Wim de With wrote: > This is a patch that fixes the function declarations in > visorbus/visorchipset.c by removing newlines after the function return > type But this is not an error nor it is a coding style error. Instead your patch will now introduce new coding style warnings about: Alignment should match open parenthesis regards sudip > > Signed-off-by: Wim de With > --- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: unisys: fix function declaration format in visorchipset.c
Wim de With writes:
> This is a patch that fixes the function declarations in
> visorbus/visorchipset.c by removing newlines after the function return
> type
This patch doesn't fix things, it makes things worse!
If you want to post patches to this, do it properly and check the output
first.
NACK
Jes
> Signed-off-by: Wim de With
> ---
> drivers/staging/unisys/visorbus/visorchipset.c | 225
> ++---
> 1 file changed, 85 insertions(+), 140 deletions(-)
>
> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
> b/drivers/staging/unisys/visorbus/visorchipset.c
> index ca22f49..f9192b6 100644
> --- a/drivers/staging/unisys/visorbus/visorchipset.c
> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
> @@ -63,8 +63,7 @@ static int visorchipset_visorbusregwait = 1;/*
> default is on */
> static int visorchipset_holdchipsetready;
> static unsigned long controlvm_payload_bytes_buffered;
>
> -static int
> -visorchipset_open(struct inode *inode, struct file *file)
> +static int visorchipset_open(struct inode *inode, struct file *file)
> {
> unsigned minor_number = iminor(inode);
>
> @@ -74,8 +73,7 @@ visorchipset_open(struct inode *inode, struct file *file)
> return 0;
> }
>
> -static int
> -visorchipset_release(struct inode *inode, struct file *file)
> +static int visorchipset_release(struct inode *inode, struct file *file)
> {
> return 0;
> }
> @@ -375,8 +373,8 @@ static void controlvm_respond_physdev_changestate(
>
> static void parser_done(struct parser_context *ctx);
>
> -static struct parser_context *
> -parser_init_byte_stream(u64 addr, u32 bytes, bool local, bool *retry)
> +static struct parser_context *parser_init_byte_stream(u64 addr, u32 bytes,
> + bool local, bool *retry)
This is *way* worse than what was there before.
> {
> int allocbytes = sizeof(struct parser_context) + bytes;
> struct parser_context *rc = NULL;
> @@ -451,8 +449,7 @@ cleanup:
> return rc;
> }
>
> -static uuid_le
> -parser_id_get(struct parser_context *ctx)
> +static uuid_le parser_id_get(struct parser_context *ctx)
> {
> struct spar_controlvm_parameters_header *phdr = NULL;
>
> @@ -473,8 +470,7 @@ enum PARSER_WHICH_STRING {
> PARSERSTRING_NAME, /* TODO: only PARSERSTRING_NAME is used ? */
> };
>
> -static void
> -parser_param_start(struct parser_context *ctx,
> +static void parser_param_start(struct parser_context *ctx,
> enum PARSER_WHICH_STRING which_string)
> {
> struct spar_controlvm_parameters_header *phdr = NULL;
> @@ -515,8 +511,7 @@ static void parser_done(struct parser_context *ctx)
> kfree(ctx);
> }
>
> -static void *
> -parser_string_get(struct parser_context *ctx)
> +static void *parser_string_get(struct parser_context *ctx)
> {
> u8 *pscan;
> unsigned long nscan;
> @@ -707,8 +702,7 @@ static ssize_t remaining_steps_store(struct device *dev,
> return count;
> }
>
> -static void
> -bus_info_clear(void *v)
> +static void bus_info_clear(void *v)
> {
> struct visorchipset_bus_info *p = (struct visorchipset_bus_info *) v;
>
> @@ -717,8 +711,7 @@ bus_info_clear(void *v)
> memset(p, 0, sizeof(struct visorchipset_bus_info));
> }
>
> -static void
> -dev_info_clear(void *v)
> +static void dev_info_clear(void *v)
> {
> struct visorchipset_device_info *p =
> (struct visorchipset_device_info *) v;
> @@ -726,8 +719,8 @@ dev_info_clear(void *v)
> memset(p, 0, sizeof(struct visorchipset_device_info));
> }
>
> -static struct visorchipset_bus_info *
> -bus_find(struct list_head *list, u32 bus_no)
> +static struct visorchipset_bus_info *bus_find(struct list_head *list,
> + u32 bus_no)
> {
> struct visorchipset_bus_info *p;
>
> @@ -739,8 +732,8 @@ bus_find(struct list_head *list, u32 bus_no)
> return NULL;
> }
>
> -static struct visorchipset_device_info *
> -device_find(struct list_head *list, u32 bus_no, u32 dev_no)
> +static struct visorchipset_device_info *device_find(struct list_head *list,
> + u32 bus_no, u32 dev_no)
> {
> struct visorchipset_device_info *p;
>
> @@ -764,8 +757,7 @@ static void busdevices_del(struct list_head *list, u32
> bus_no)
> }
> }
>
> -static u8
> -check_chipset_events(void)
> +static u8 check_chipset_events(void)
> {
> int i;
> u8 send_msg = 1;
> @@ -775,8 +767,7 @@ check_chipset_events(void)
> return send_msg;
> }
>
> -static void
> -clear_chipset_events(void)
> +static void clear_chipset_events(void)
> {
> int i;
> /* Clear chipset_events */
> @@ -784,8 +775,7 @@ clear_chipset_events(void)
> chipset_events[i] = 0;
> }
>
> -void
> -visorchipset_register_busdev(
> +void visorchipset_register_busdev(
> struct visorchipset_busdev_notifiers *notifie
[PATCH] staging: rtl8192e: replace printk with subsystem debug
replace the printk with netdev subsystem debug infrastructure.
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index fe3e7e12..f6e3f83 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -344,7 +344,7 @@ rtllib_rx_frame_decrypt_msdu(struct rtllib_device *ieee,
struct sk_buff *skb,
res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv);
atomic_dec(&crypt->refcnt);
if (res < 0) {
- printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed
(SA= %pM keyidx=%d)\n",
+ netdev_dbg(ieee->dev, "%s: MSDU decryption/MIC verification
failed (SA= %pM keyidx=%d)\n",
ieee->dev->name, hdr->addr2, keyidx);
return -1;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: fix coding style issues
On 16/05/15 05:16, Geliang Tang wrote:
1) Fixed an error found by checkpatch.pl.
ERROR: space required after that ',' (ctx:VxV)
./drivers/ni_mio_common.c:3764
2) Changed "register 0x%x" to "register=0x%x" to keep the consistency
of this file.
3) The kernel version is next-20150515, 4.1.0-rc3.
You shouldn't mention point 3 in the commit message as it will look a
bit strange when it ends up in the commit log. If you need to mention
that, it should go after the commit message, separated from the patch by
a "---" line like this:
Body of commit message goes here.
Signed off by and Cc lines go here.
---
Additional patch commentary goes here.
---
Actual patch goes here.
Git will ignore the additional commentary when the patch is applied.
Signed-off-by: Geliang Tang
---
drivers/staging/comedi/drivers/ni_mio_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 9dfd4e6..6cc304a 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -3761,7 +3761,7 @@ static unsigned int ni_gpct_to_stc_register(struct
comedi_device *dev,
if (reg < ARRAY_SIZE(ni_gpct_to_stc_regmap)) {
regmap = &ni_gpct_to_stc_regmap[reg];
} else {
- dev_warn(dev->class_dev,"%s: unhandled register 0x%x\n",
+ dev_warn(dev->class_dev, "%s: unhandled register=0x%x\n",
__func__, reg);
return 0;
}
Apart from that niggle, the patch looks good!
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: rtl8192e: define macro for use in C file
This macro defines the maximum sequence number for an IEEE802.11 frame. Signed-off-by: Hari Prasath Gujulan Elango --- drivers/staging/rtl8192e/rtllib.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/rtl8192e/rtllib.h b/drivers/staging/rtl8192e/rtllib.h index 3c8b708..9ee0896 100644 --- a/drivers/staging/rtl8192e/rtllib.h +++ b/drivers/staging/rtl8192e/rtllib.h @@ -47,6 +47,7 @@ #define MAX_PRECMD_CNT 16 #define MAX_RFDEPENDCMD_CNT 16 #define MAX_POSTCMD_CNT 16 +#define IEEE80211_MAX_SEQ 4096 #ifndef WIRELESS_SPY #define WIRELESS_SPY -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: rtl8192e: replace hard coded value with macro
replace the hard coded value for the maximum sequence number of a ieee
802.11 frame by a Macro.
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/rtl8192e/rtllib_tx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_tx.c
b/drivers/staging/rtl8192e/rtllib_tx.c
index 3b15963..6325ceb 100644
--- a/drivers/staging/rtl8192e/rtllib_tx.c
+++ b/drivers/staging/rtl8192e/rtllib_tx.c
@@ -326,7 +326,7 @@ static void rtllib_tx_query_agg_cap(struct rtllib_device
*ieee,
goto FORCED_AGG_SETTING;
} else if (pTxTs->bUsingBa == false) {
if
(SN_LESS(pTxTs->TxAdmittedBARecord.BaStartSeqCtrl.field.SeqNum,
- (pTxTs->TxCurSeq+1)%4096))
+ (pTxTs->TxCurSeq+1)%IEEE80211_MAX_SEQ))
pTxTs->bUsingBa = true;
else
goto FORCED_AGG_SETTING;
@@ -525,7 +525,7 @@ u16 rtllib_query_seqnum(struct rtllib_device *ieee, struct
sk_buff *skb,
skb->priority, TX_DIR, true))
return 0;
seqnum = pTS->TxCurSeq;
- pTS->TxCurSeq = (pTS->TxCurSeq+1)%4096;
+ pTS->TxCurSeq = (pTS->TxCurSeq+1)%IEEE80211_MAX_SEQ;
return seqnum;
}
return 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: rtl8192e: define macro for use in C file
Fold this together with the other patch. Do 1 thing per patch, not half a thing per patch. This change makes no sense on its own. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: rtl8192e: define macro for use in C file
On Mon, May 18, 2015 at 03:47:58PM +0300, Dan Carpenter wrote: > Fold this together with the other patch. Do 1 thing per patch, not half > a thing per patch. This change makes no sense on its own. > > regards, > dan carpenter > I didn't think of it. I am sending v2 with both the related changes as a single patch. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2] staging: rtl8192e: replace hard coded value with macro
replace the hard coded value of 4096 with macro which defines the
maximum sequence number of a ieee 802.11 frame.
Signed-off-by: Hari Prasath Gujulan Elango
---
v2: Previously send this as two different patches which is wrong
as the individual patches doesn't make sense.Resending as a single patch
---
drivers/staging/rtl8192e/rtllib.h| 1 +
drivers/staging/rtl8192e/rtllib_tx.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 3c8b708..9ee0896 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -47,6 +47,7 @@
#define MAX_PRECMD_CNT 16
#define MAX_RFDEPENDCMD_CNT 16
#define MAX_POSTCMD_CNT 16
+#define IEEE80211_MAX_SEQ 4096
#ifndef WIRELESS_SPY
#define WIRELESS_SPY
diff --git a/drivers/staging/rtl8192e/rtllib_tx.c
b/drivers/staging/rtl8192e/rtllib_tx.c
index 3b15963..6325ceb 100644
--- a/drivers/staging/rtl8192e/rtllib_tx.c
+++ b/drivers/staging/rtl8192e/rtllib_tx.c
@@ -326,7 +326,7 @@ static void rtllib_tx_query_agg_cap(struct rtllib_device
*ieee,
goto FORCED_AGG_SETTING;
} else if (pTxTs->bUsingBa == false) {
if
(SN_LESS(pTxTs->TxAdmittedBARecord.BaStartSeqCtrl.field.SeqNum,
- (pTxTs->TxCurSeq+1)%4096))
+ (pTxTs->TxCurSeq+1)%IEEE80211_MAX_SEQ))
pTxTs->bUsingBa = true;
else
goto FORCED_AGG_SETTING;
@@ -525,7 +525,7 @@ u16 rtllib_query_seqnum(struct rtllib_device *ieee, struct
sk_buff *skb,
skb->priority, TX_DIR, true))
return 0;
seqnum = pTS->TxCurSeq;
- pTS->TxCurSeq = (pTS->TxCurSeq+1)%4096;
+ pTS->TxCurSeq = (pTS->TxCurSeq+1)%IEEE80211_MAX_SEQ;
return seqnum;
}
return 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] Driver for Arduino-as-I2C-adapter
Hi Bernhard, There are many cheap I2C adapter projects (mostly USB though). One of the simple ones (i2c-tiny-usb) is included in the kernel, while LinkM (https://github.com/todbot/LinkM) stayed userspace. As regarding to cheap serial line based adapters, there are two I have seen before (http://www.gedanken.org.uk/electronics/rs232-converters/i2c.html and http://www.robot-electronics.co.uk/acatalog/USB_I2C.html) and both define a different protocol. Personally I would suggest to try follow one of those protocols to avoid creating a new one and would be happy to see an open sourced Arduino sketch as well. I am afraid handling serial devices within a i2c kernel driver might be tricky and purists probably dislike the idea. Best, Alex Bernhard Kraft wrote: Hi, For a project I needed to communicate with external hardware via the I2C protocol. I took a look at the existing drivers in the linux kernel source "drivers/i2c/busses". Instead of buying yet another interface dongle (this time for I2C) I decided to use an Arduino with an apropriate sketch as I2C adapter. Currently I access the I2C adapter (Arduino) via a custom program reading/writing to /dev/ttyACM0. Do you think it would make sense to add an I2C driver to the Linux kernel for an "Arduino as I2C adapter" solution? Or could you propose another solution? Maybe just an "external" module like the nvidia kernel module? greetings, Bernhard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: Add more help description on Kconfig
This patch adds more help description on android Kconfig for - lowmemory killer - Timed gpio (same for timed output) Signed-off-by: Jagan Teki Cc: Greg Kroah-Hartman Cc: Brian Swetland --- drivers/staging/android/Kconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig index 8feb904..24d657b 100644 --- a/drivers/staging/android/Kconfig +++ b/drivers/staging/android/Kconfig @@ -22,11 +22,20 @@ config ANDROID_TIMED_GPIO tristate "Android timed gpio driver" depends on GPIOLIB && ANDROID_TIMED_OUTPUT default n +---help--- + Unlike generic gpio is to allow programs to access and manipulate gpio + registers from user space, timed output/gpio is a system to allow changing + a gpio pin and restore it automatically after a specified timeout. config ANDROID_LOW_MEMORY_KILLER bool "Android Low Memory Killer" ---help--- - Registers processes to be killed when memory is low + Registers processes to be killed when low memory conditions, this is useful + as there is no particular swap space on android. + + The registered process will kills according to the priorities in android init + scripts (/init.rc), and it defines priority values with minimum free memory size + for each priority. config SYNC bool "Synchronization framework" -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: rtl8712: Use ether_addr_copy() instead of memcpy()
Fixes Warning encounter this by applying checkpatch.pl against this file:
Prefer ether_addr_copy() over memcpy() if the Ethernet addresses
are __aligned(2)
pahole output for respective structures:
- addr->sa_data
struct sockaddr {
sa_family_tsa_family;/* 0 2 */
char sa_data[14]; /* 214 */
/* size: 16, cachelines: 1, members: 2 */
/* last cacheline: 16 bytes */
};
- padapter->eeprompriv.mac_addr
struct _adapter {
struct dvobj_priv dvobjpriv;/* 040 */
struct mlme_priv mlmepriv; /*40 1560 */
/* --- cacheline 25 boundary (1600 bytes) --- */
struct cmd_privcmdpriv; /* 1600 136 */
/* --- cacheline 27 boundary (1728 bytes) was 8 bytes ago --- */
struct evt_privevtpriv; /* 173696 */
/* --- cacheline 28 boundary (1792 bytes) was 40 bytes ago --- */
struct io_queue * pio_queue;/* 1832 8 */
struct xmit_priv xmitpriv; /* 1840 912 */
/* --- cacheline 43 boundary (2752 bytes) --- */
struct recv_priv recvpriv; /* 2752 1088 */
/* --- cacheline 60 boundary (3840 bytes) --- */
struct sta_privstapriv; /* 3840 672 */
/* --- cacheline 70 boundary (4480 bytes) was 32 bytes ago --- */
struct security_priv securitypriv; /* 4512 4816 */
/* --- cacheline 145 boundary (9280 bytes) was 48 bytes ago --- */
struct registry_priv registrypriv; /* 9328 968 */
/* --- cacheline 160 boundary (10240 bytes) was 56 bytes ago --- */
struct wlan_acl_pool acl_list; /* 10296 1536 */
/* --- cacheline 184 boundary (11776 bytes) was 56 bytes ago --- */
struct pwrctrl_privpwrctrlpriv; /* 11832 224 */
/* --- cacheline 188 boundary (12032 bytes) was 24 bytes ago --- */
struct eeprom_priv eeprompriv; /* 12056 508 */
};
struct eeprom_priv {
u8 bautoload_fail_flag; /* 0 1 */
u8 bempty; /* 1 1 */
u8 sys_config; /* 2 1 */
u8 mac_addr[6]; /* 3 6 */
..
};
- pnetdev->dev_addr
dev_addr is interface address infor from generic net_device structure
which is properly aligned and have some patches with this change as well.
"staging: rtl8712: fix Prefer ether_addr_copy() over memcpy()"
(sha1: 36e4d8826b317080e283e4edd08bf8d5ac706f38)
Signed-off-by: Jagan Teki
Cc: Greg Kroah-Hartman
Cc: Larry Finger
Cc: Florian Schilhabel
---
Changes for v2:
- Describe a changelog, to prove address are aligned.
drivers/staging/rtl8712/os_intfs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8712/os_intfs.c
b/drivers/staging/rtl8712/os_intfs.c
index 6e776e5..0d27df6 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -181,7 +181,7 @@ static int r871x_net_set_mac_address(struct net_device
*pnetdev, void *p)
struct sockaddr *addr = p;
if (padapter->bup == false)
- memcpy(pnetdev->dev_addr, addr->sa_data, ETH_ALEN);
+ ether_addr_copy(pnetdev->dev_addr, addr->sa_data);
return 0;
}
@@ -395,8 +395,8 @@ static int netdev_open(struct net_device *pnetdev)
goto netdev_open_error;
if (r8712_initmac == NULL)
/* Use the mac address stored in the Efuse */
- memcpy(pnetdev->dev_addr,
- padapter->eeprompriv.mac_addr, ETH_ALEN);
+ ether_addr_copy(pnetdev->dev_addr,
+ padapter->eeprompriv.mac_addr);
else {
/* We have to inform f/w to use user-supplied MAC
* address.
@@ -412,8 +412,8 @@ static int netdev_open(struct net_device *pnetdev)
* the eeprompriv.mac_addr should store the mac which
* users specify.
*/
- memcpy(padapter->eeprompriv.mac_addr,
- pnetdev->dev_addr, ETH_ALEN);
+ ether_addr_copy(padapter->eeprompriv.mac_addr,
+ pnetdev->dev_addr);
}
if (start_drv_threads(padapter) != _SUCCESS)
goto netdev_open_error;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject
Re: [PATCH v2] staging: rtl8712: Use ether_addr_copy() instead of memcpy()
On Mon, May 18, 2015 at 07:47:06PM +0530, Jagan Teki wrote:
> struct eeprom_priv {
> u8 bautoload_fail_flag; /* 0 1 */
> u8 bempty; /* 1 1 */
> u8 sys_config; /* 2 1 */
> u8 mac_addr[6]; /* 3 6 */
> ..
> };
This means it's not aligned as we want.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
setup_timer is used for timer parameter setup rather than direct
assignment
Signed-off-by: Gnanachandran Dhanapal
---
drivers/staging/rtl8192e/rtllib_module.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_module.c
b/drivers/staging/rtl8192e/rtllib_module.c
index 32cc8df..7ad1541 100644
--- a/drivers/staging/rtl8192e/rtllib_module.c
+++ b/drivers/staging/rtl8192e/rtllib_module.c
@@ -59,9 +59,8 @@ EXPORT_SYMBOL(rt_global_debug_component);
void _setup_timer(struct timer_list *ptimer, void *fun, unsigned long data)
{
- ptimer->function = fun;
- ptimer->data = data;
init_timer(ptimer);
+ setup_timer(ptimer, fun, data);
}
static inline int rtllib_networks_allocate(struct rtllib_device *ieee)
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 34/44] staging: unisys: Prepare vbus_hdr_info to be public
On Sat, May 16, 2015 at 02:22:16PM +0300, Dan Carpenter wrote:
> On Wed, May 13, 2015 at 01:22:28PM -0400, Benjamin Romer wrote:
> > + hdr_info = kzalloc(sizeof(*hdr_info), GFP_KERNEL);
> > + if (!hdr_info) {
> > + rc = NULL;
> > + goto away_mem;
> > + }
> > +
> > dev_set_name(&devdata->dev, "visorbus%d", id);
> > devdata->dev.bus = &visorbus_type;
> > devdata->dev.groups = visorbus_groups;
> > @@ -1344,26 +1352,19 @@ create_bus_instance(struct visorchipset_bus_info
> > *bus_info)
> > POSTCODE_LINUX_3(DEVICE_CREATE_FAILURE_PC, id,
> > POSTCODE_SEVERITY_ERR);
> > rc = NULL;
> > - goto away;
> > + goto away_mem2;
> > }
> > devdata->devno = id;
> > devdata->chan = bus_info->visorchannel;
> > if (bus_info->flags.server) {
> > init_vbus_channel(devdata->chan);
> > } else {
> > - if (get_vbus_header_info(devdata->chan,
> > -&devdata->
> > -vbus_hdr_info) >= 0) {
> > - devdata->vbus_valid = true;
> > - write_vbus_chp_info(devdata->chan,
> > - &devdata->
> > - vbus_hdr_info,
> > - &chipset_driverinfo
> > - );
> > - write_vbus_bus_info(devdata->chan,
> > - &devdata->
> > - vbus_hdr_info,
> > - &clientbus_driverinfo);
> > + if (get_vbus_header_info(devdata->chan, hdr_info) >= 0) {
> > + devdata->vbus_hdr_info = (void *)hdr_info;
> > + write_vbus_chp_info(devdata->chan, hdr_info,
> > + &chipset_driverinfo);
> > + write_vbus_bus_info(devdata->chan, hdr_info,
> > + &clientbus_driverinfo);
> > }
> > }
> > bus_count++;
>
> We still leak hdr_info on some paths.
Agreed. I noticed and fixed this up in patch 37 "Remove server flags".
Simplifying the code made the problem stand out eaiser. I can migrate the
fix to this patch if you want.
Cheers,
Don
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 40/44] staging: unisys: Convert device creation to use visor_device
On Sat, May 16, 2015 at 02:32:33PM +0300, Dan Carpenter wrote:
> On Wed, May 13, 2015 at 01:22:34PM -0400, Benjamin Romer wrote:
> > @@ -1022,29 +997,21 @@ create_visor_device(struct visor_device *bdev,
> > goto away;
> > }
> >
> > - /* note: device_register is simply device_initialize + device_add */
> > - registered1 = true;
> > -
> > rc = register_devmajorminor_attributes(dev);
> > if (rc < 0) {
> > POSTCODE_LINUX_3(DEVICE_REGISTER_FAILURE_PC, chipset_dev_no,
> > DIAG_SEVERITY_ERR);
> > - goto away;
> > + goto away_register;
> > }
> >
> > - registered2 = true;
> > - rc = 0;
> > + list_add_tail(&dev->list_all, &list_all_device_instances);
> > + put_device(&dev->device);
>
> We don't want to call put_device() on the success path. It hopefully
> would have triggered an error if we call remove_visor_device()?
Yup, I agree. Mistake on my part when I was tweaking the failure paths
here. Thanks! Let me respin that patch.
Cheers,
Don
>
> > + return 0;
> >
> > +away_register:
> > + device_unregister(&dev->device);
> > away:
>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 34/44] staging: unisys: Prepare vbus_hdr_info to be public
On Mon, May 18, 2015 at 10:52:25AM -0400, Don Zickus wrote: > On Sat, May 16, 2015 at 02:22:16PM +0300, Dan Carpenter wrote: > > On Wed, May 13, 2015 at 01:22:28PM -0400, Benjamin Romer wrote: > > > > We still leak hdr_info on some paths. > > Agreed. I noticed and fixed this up in patch 37 "Remove server flags". > Simplifying the code made the problem stand out eaiser. I can migrate the > fix to this patch if you want. I don't have strong opinions. I hadn't read 37 when I sent this. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 32/44] staging: unisys: Move channel creation up the stack
On Sat, May 16, 2015 at 02:38:57PM +0300, Dan Carpenter wrote:
> On Wed, May 13, 2015 at 01:22:26PM -0400, Benjamin Romer wrote:
> > --- a/drivers/staging/unisys/visorbus/visorchipset.c
> > +++ b/drivers/staging/unisys/visorbus/visorchipset.c
> > @@ -1197,6 +1197,7 @@ bus_create(struct controlvm_message *inmsg)
> > u32 bus_no = cmd->create_bus.bus_no;
> > int rc = CONTROLVM_RESP_SUCCESS;
> > struct visorchipset_bus_info *bus_info;
> > + struct visorchannel *visorchannel;
> >
> > bus_info = bus_find(&bus_info_list, bus_no);
> > if (bus_info && (bus_info->state.created == 1)) {
> > @@ -1218,18 +1219,21 @@ bus_create(struct controlvm_message *inmsg)
> >
> > POSTCODE_LINUX_3(BUS_CREATE_ENTRY_PC, bus_no, POSTCODE_SEVERITY_INFO);
> >
> > - if (inmsg->hdr.flags.test_message == 1)
> > - bus_info->chan_info.addr_type = ADDRTYPE_LOCALTEST;
> > - else
> > - bus_info->chan_info.addr_type = ADDRTYPE_LOCALPHYSICAL;
> > -
> > bus_info->flags.server = inmsg->hdr.flags.server;
> > - bus_info->chan_info.channel_addr = cmd->create_bus.channel_addr;
> > - bus_info->chan_info.n_channel_bytes = cmd->create_bus.channel_bytes;
> > - bus_info->chan_info.channel_type_uuid =
> > - cmd->create_bus.bus_data_type_uuid;
> > - bus_info->chan_info.channel_inst_uuid = cmd->create_bus.bus_inst_uuid;
> >
> > + visorchannel = visorchannel_create(cmd->create_bus.channel_addr,
> > + cmd->create_bus.channel_bytes,
> > + GFP_KERNEL,
> > + cmd->create_bus.bus_data_type_uuid);
> > +
> > + if (!visorchannel) {
> > + POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus_no,
> > +POSTCODE_SEVERITY_ERR);
> > + rc = -CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
> > + kfree(bus_info);
>
>
> I'm in a very lazy review mood but I can't immediately see how this is
> correct. We're calling kfree(bus_info), but the pointer is still there
> and bus_find() will return it to someone else. Actually it's worse than
> that, because bus_find() will dereference it iterating through the
> &bus_info_list.
Thanks for the review, I am going to half disagree, see lines below. :-)
>
> > + goto cleanup;
> > + }
> > + bus_info->visorchannel = visorchannel;
> > list_add(&bus_info->entry, &bus_info_list);
bus_info gets attached to bus_info_list here, only on success. So you
concern should never happen on the failure case.
What might be confusing you is the bus_info = bus_find() command above.
That is a sanity check to see if bus_info already exists. If it does, the
function fails. If not, bus_info is kzalloc'd and not attached to anything
yet.
That is my half disagreement. ;-)
The half that agrees with you, does show an error in this path. What happens
is the 'goto cleanup' part calls bus_epilog. But because bus_info is still
non-NULL, bus-epilog tries to treat it like valid data, which it isn't
anymore.
So I need to set bus_info to NULL after kfree'ing it. I will respin for
that.
Cheers,
Don
> >
> > POSTCODE_LINUX_3(BUS_CREATE_EXIT_PC, bus_no, POSTCODE_SEVERITY_INFO);
>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fixed coding style issues at ieee80211_crypt_wep.c
On Mon, 2015-05-18 at 11:33 +0300, Dan Carpenter wrote: > Also the use a subsystem prefix in the subject: > > [PATCH] Staging: rtl8192u: whatever... > > > regards, > dan carpenter > Thanku for your comments, I will send an v2 patch version regards, Pedro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 32/44 V2] staging: unisys: Move channel creation up the stack
Instead of creating a channel struct to temporarily hold the channel
info and passing it through multiple functions until the device is
created, just create the channel from the start.
This allows us to remove the channel_info struct.
I noticed 'chan_info.addr_type' was not being used, so I just deleted it.
Signed-off-by: Don Zickus
---
V2: Fix bus/dev_create error path by adding bus/dev_info = NULL (Dan Carpenter)
---
drivers/staging/unisys/visorbus/visorbus_main.c| 87 +++---
drivers/staging/unisys/visorbus/visorbus_private.h | 16 +---
drivers/staging/unisys/visorbus/visorchipset.c | 54 +-
3 files changed, 63 insertions(+), 94 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 5e5859c..da7d4de 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1009,11 +1009,9 @@ EXPORT_SYMBOL_GPL(visorbus_disable_channel_interrupts);
static int
create_visor_device(struct visorbus_devdata *devdata,
struct visorchipset_device_info *dev_info,
- struct visorchipset_channel_info chan_info,
u64 partition_handle)
{
int rc = -1;
- struct visorchannel *visorchannel = NULL;
struct visor_device *dev = NULL;
bool gotten = false, registered1 = false, registered2 = false;
u32 chipset_bus_no = dev_info->bus_no;
@@ -1021,16 +1019,6 @@ create_visor_device(struct visorbus_devdata *devdata,
POSTCODE_LINUX_4(DEVICE_CREATE_ENTRY_PC, chipset_dev_no, chipset_bus_no,
POSTCODE_SEVERITY_INFO);
- /* prepare chan_hdr (abstraction to read/write channel memory) */
- visorchannel = visorchannel_create(chan_info.channel_addr,
- chan_info.n_channel_bytes,
- GFP_KERNEL,
- chan_info.channel_type_uuid);
- if (!visorchannel) {
- POSTCODE_LINUX_3(DEVICE_CREATE_FAILURE_PC, chipset_dev_no,
-DIAG_SEVERITY_ERR);
- goto away;
- }
dev = kmalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
POSTCODE_LINUX_3(DEVICE_CREATE_FAILURE_PC, chipset_dev_no,
@@ -1039,9 +1027,8 @@ create_visor_device(struct visorbus_devdata *devdata,
}
memset(dev, 0, sizeof(struct visor_device));
- dev->visorchannel = visorchannel;
- dev->channel_type_guid = chan_info.channel_type_uuid;
- dev->channel_bytes = chan_info.n_channel_bytes;
+ dev->visorchannel = dev_info->visorchannel;
+ dev->channel_type_guid = dev_info->channel_type_guid;
dev->chipset_bus_no = chipset_bus_no;
dev->chipset_dev_no = chipset_dev_no;
dev->device.parent = &devdata->dev;
@@ -1113,8 +1100,6 @@ away:
unregister_devmajorminor_attributes(dev);
if (gotten)
put_device(&dev->device);
- if (visorchannel)
- visorchannel_destroy(visorchannel);
kfree(dev);
} else {
total_devices_created++;
@@ -1133,7 +1118,7 @@ remove_visor_device(struct visor_device *dev)
}
static struct visor_device *
-find_visor_device_by_channel(u64 channel_physaddr)
+find_visor_device_by_channel(struct visorchannel *channel)
{
struct list_head *listentry, *listtmp;
@@ -1141,8 +1126,7 @@ find_visor_device_by_channel(u64 channel_physaddr)
struct visor_device *dev = list_entry(listentry,
struct visor_device,
list_all);
- if (visorchannel_get_physaddr(dev->visorchannel) ==
- channel_physaddr)
+ if (dev->visorchannel == channel)
return dev;
}
return NULL;
@@ -1362,41 +1346,23 @@ create_bus_instance(struct visorchipset_bus_info
*bus_info)
goto away;
}
devdata->devno = id;
- if ((bus_info->chan_info.channel_addr > 0) &&
- (bus_info->chan_info.n_channel_bytes > 0)) {
- u64 channel_addr = bus_info->chan_info.channel_addr;
- unsigned long n_channel_bytes =
- (unsigned long)
- bus_info->chan_info.n_channel_bytes;
- uuid_le channel_type_guid =
- bus_info->chan_info.channel_type_uuid;
-
- devdata->chan = visorchannel_create(channel_addr,
- n_channel_bytes,
- GFP_KERNEL,
- channel_type_guid);
- if (!devdata->chan) {
- PO
[PATCH 40/44 V2] staging: unisys: Convert device creation to use visor_device
This patch removes the legacy dev_info struct and instead creates
and passes around a traditional struct device.
This allows us to remove a lot of the various look up code and
removes the doubt if the struct exists or not.
Half of the churn is just the conversion of visorchipset_device_info
to visor_device. Various cleanups include re-arranging the failure
paths to make more sense.
Pay attention to the create_visor_device function. This had a lot of
churn to simplify everything.
Lots of functions disappeared because they are not needed any more.
Signed-off-by: Don Zickus
---
V2: Remove the extra put_device(). (Dan Carpenter)
---
drivers/staging/unisys/include/visorbus.h | 8 +-
drivers/staging/unisys/visorbus/visorbus_main.c| 144 +---
drivers/staging/unisys/visorbus/visorbus_private.h | 48 ++-
drivers/staging/unisys/visorbus/visorchipset.c | 149 +
4 files changed, 79 insertions(+), 270 deletions(-)
diff --git a/drivers/staging/unisys/include/visorbus.h
b/drivers/staging/unisys/include/visorbus.h
index e7f9984..581d962 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -43,7 +43,7 @@ struct visor_device;
extern struct bus_type visorbus_type;
typedef void (*visorbus_state_complete_func) (struct visor_device *dev,
- int status, void *dev_info);
+ int status);
struct visorchipset_state {
u32 created:1;
u32 attached:1;
@@ -106,11 +106,9 @@ struct visor_driver {
* fails or completes successfully.
*/
int (*pause)(struct visor_device *dev,
-visorbus_state_complete_func complete_func,
-void *dev_info);
+visorbus_state_complete_func complete_func);
int (*resume)(struct visor_device *dev,
- visorbus_state_complete_func complete_func,
- void *dev_info);
+ visorbus_state_complete_func complete_func);
/** These fields are for private use by the bus driver only. */
struct device_driver driver;
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
b/drivers/staging/unisys/visorbus/visorbus_main.c
index bee626c..2cf11d8 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -95,10 +95,10 @@ static long long bus_count; /** number of bus instances */
static void chipset_bus_create(struct visor_device *bus_info);
static void chipset_bus_destroy(struct visor_device *bus_info);
-static void chipset_device_create(struct visorchipset_device_info *dev_info);
-static void chipset_device_destroy(struct visorchipset_device_info *dev_info);
-static void chipset_device_pause(struct visorchipset_device_info *dev_info);
-static void chipset_device_resume(struct visorchipset_device_info *dev_info);
+static void chipset_device_create(struct visor_device *dev_info);
+static void chipset_device_destroy(struct visor_device *dev_info);
+static void chipset_device_pause(struct visor_device *dev_info);
+static void chipset_device_resume(struct visor_device *dev_info);
/** These functions are implemented herein, and are called by the chipset
* driver to notify us about specific events.
@@ -184,7 +184,6 @@ visorbus_release_busdevice(struct device *xdev)
dev_set_drvdata(xdev, NULL);
kfree(dev);
- kfree(xdev);
}
/** This is called when device_unregister() is called for each child
@@ -754,16 +753,9 @@ away:
* initialized.
*/
if (!dev->responded_to_device_create) {
- struct visorchipset_device_info dev_info;
-
- if (!visorchipset_get_device_info(dev->chipset_bus_no,
- dev->chipset_dev_no,
&dev_info))
- /* hmm, what to do here */
- return rc;
-
dev->responded_to_device_create = true;
if (chipset_responders.device_create)
- (*chipset_responders.device_create)(&dev_info, rc);
+ (*chipset_responders.device_create)(dev, rc);
}
return rc;
}
@@ -948,30 +940,15 @@ EXPORT_SYMBOL_GPL(visorbus_disable_channel_interrupts);
* device.
*/
static int
-create_visor_device(struct visor_device *bdev,
- struct visorchipset_device_info *dev_info)
+create_visor_device(struct visor_device *dev)
{
int rc = -1;
- struct visor_device *dev = NULL;
- bool gotten = false, registered1 = false, registered2 = false;
- u32 chipset_bus_no = dev_info->bus_no;
- u32 chipset_dev_no = dev_info->dev_no;
+ u32 chipset_bus_no = dev->chipset_bus_no;
+ u32 chipset_dev_no = dev->chipset_dev_no;
POSTCODE_LINUX_4(DEVICE_CREATE_ENTRY_PC, chipset_dev_no, chipset_bus_no,
[PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
Merge two pr_debug lines with literal strings splitted across several lines
into one single line, simplifying prism2_wep_init error check code.
Openning braces should never be in a new line, move them to the end of
the previous line.
Removed two useless lines at ieee80211_wep_null.
Signed-off-by: Pedro Marzo Perez
---
.../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 33 --
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 0a17f84..1074916 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -9,6 +9,8 @@
* more details.
*/
+#define pr_fmt(fmt) "ieee80211_crypt_wep: " fmt
+
#include
#include
#include
@@ -19,7 +21,7 @@
#include "ieee80211.h"
#include
-#include
+#include
#include
MODULE_AUTHOR("Jouni Malinen");
@@ -43,20 +45,16 @@ static void *prism2_wep_init(int keyidx)
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
- goto fail;
+ return NULL;
priv->key_idx = keyidx;
priv->tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->tx_tfm)) {
- pr_debug("ieee80211_crypt_wep: could not allocate "
- "crypto API arc4\n");
priv->tx_tfm = NULL;
goto fail;
}
priv->rx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->rx_tfm)) {
- pr_debug("ieee80211_crypt_wep: could not allocate "
- "crypto API arc4\n");
priv->rx_tfm = NULL;
goto fail;
}
@@ -67,14 +65,12 @@ static void *prism2_wep_init(int keyidx)
return priv;
fail:
- if (priv) {
- if (priv->tx_tfm)
- crypto_free_blkcipher(priv->tx_tfm);
- if (priv->rx_tfm)
- crypto_free_blkcipher(priv->rx_tfm);
- kfree(priv);
- }
-
+ pr_debug(pr_fmt("could not allocate crypto API arc4\n"));
+ if (priv->tx_tfm)
+ crypto_free_blkcipher(priv->tx_tfm);
+ if (priv->rx_tfm)
+ crypto_free_blkcipher(priv->rx_tfm);
+ kfree(priv);
return NULL;
}
@@ -142,9 +138,7 @@ static int prism2_wep_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
/* Copy rest of the WEP key (the secret part) */
memcpy(key + 3, wep->key, wep->key_len);
- if (!tcb_desc->bHwSec)
- {
-
+ if (!tcb_desc->bHwSec) {
/* Append little-endian CRC32 and encrypt it to produce ICV */
crc = ~crc32_le(~0, pos, len);
icv = skb_put(skb, 4);
@@ -201,8 +195,7 @@ static int prism2_wep_decrypt(struct sk_buff *skb, int
hdr_len, void *priv)
/* Apply RC4 to data and compute CRC32 over decrypted data */
plen = skb->len - hdr_len - 8;
- if (!tcb_desc->bHwSec)
- {
+ if (!tcb_desc->bHwSec) {
crypto_blkcipher_setkey(wep->rx_tfm, key, klen);
sg_init_one(&sg, pos, plen+4);
@@ -293,6 +286,4 @@ void __exit ieee80211_crypto_wep_exit(void)
void ieee80211_wep_null(void)
{
-// printk(">%s()\n", __func__);
- return;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 32/44] staging: unisys: Move channel creation up the stack
On Mon, May 18, 2015 at 11:20:27AM -0400, Don Zickus wrote: > What might be confusing you is the bus_info = bus_find() command above. Yes. You are right. This was where I got confused. Was in too much of a hurry. Sorry about that. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: Modify if, else if conditions to remove unnecessary equality checks. This change was detected with the help of coccinelle tool.
Signed-off-by: Chaitanya Dhere
Reply-To:
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index d2e8b12..30b0135 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -1364,12 +1364,11 @@ static void ieee80211_associate_complete_wq(struct
work_struct *work)
ieee->LinkDetectInfo.NumRecvDataInPeriod= 1;
}
ieee->link_change(ieee->dev);
- if(ieee->is_silent_reset == 0){
+ if (!ieee->is_silent_reset) {
printk(">normal associate\n");
notify_wx_assoc_event(ieee);
}
- else if(ieee->is_silent_reset == 1)
- {
+ else if (ieee->is_silent_reset) {
printk("==>silent reset associate\n");
ieee->is_silent_reset = false;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: rtl8712: Use ether_addr_copy() instead of memcpy()
On 18 May 2015 at 20:08, Dan Carpenter wrote:
> On Mon, May 18, 2015 at 07:47:06PM +0530, Jagan Teki wrote:
>> struct eeprom_priv {
>> u8 bautoload_fail_flag; /* 0 1 */
>> u8 bempty; /* 1 1 */
>> u8 sys_config; /* 2 1 */
>> u8 mac_addr[6]; /* 3 6 */
>> ..
>> };
>
> This means it's not aligned as we want.
Why size upto mac_addr is 9 and is not divisible by 2 is it?
or the mac_addr size is 6 which is divisible by 2 (__align(2))
this is full pahole:
struct eeprom_priv {
u8 bautoload_fail_flag; /* 0 1 */
u8 bempty; /* 1 1 */
u8 sys_config; /* 2 1 */
u8 mac_addr[6]; /* 3 6 */
u8 config0; /* 9 1 */
u16channel_plan; /*10 2 */
u8 country_string[3];/*12 3 */
u8 tx_power_b[15]; /*1515 */
u8 tx_power_g[15]; /*3015 */
u8 tx_power_a[201]; /*45 201 */
/* --- cacheline 3 boundary (192 bytes) was 54 bytes ago --- */
u8 efuse_eeprom_data[256]; /* 246 256 */
/* XXX 2 bytes hole, try to pack */
/* --- cacheline 7 boundary (448 bytes) was 56 bytes ago --- */
enum RT_CUSTOMER_IDCustomerID; /* 504 4 */
/* size: 508, cachelines: 8, members: 12 */
/* sum members: 506, holes: 1, sum holes: 2 */
/* last cacheline: 60 bytes */
};
thanks!
--
Jagan Teki,
Openedev.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
On Mon, May 18, 2015 at 02:44:15PM +, DHANAPAL, GNANACHANDRAN (G.) wrote:
> setup_timer is used for timer parameter setup rather than direct
> assignment
>
> Signed-off-by: Gnanachandran Dhanapal
your From: name and Signed-off-by: names are not matching. They should
be same.
> ---
> --- a/drivers/staging/rtl8192e/rtllib_module.c
> +++ b/drivers/staging/rtl8192e/rtllib_module.c
> @@ -59,9 +59,8 @@ EXPORT_SYMBOL(rt_global_debug_component);
>
> void _setup_timer(struct timer_list *ptimer, void *fun, unsigned long data)
> {
> - ptimer->function = fun;
> - ptimer->data = data;
> init_timer(ptimer);
> + setup_timer(ptimer, fun, data);
setup_timer is calling __setup_timer which is again calling __init_timer
here we already have an init_timer which is also calling __init_timer.
so now __init_timer gets executed two times for one timer.
regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: rtl8712: Use ether_addr_copy() instead of memcpy()
#include
struct foo {
unsigned char one;
unsigned char two;
unsigned char three;
unsigned char mac_addr[6];
unsigned short channel_plan;
};
int main(void)
{
struct foo *p = NULL;
printf("%x\n", &p->mac_addr);
return 0;
}
This program does not print an even number so the alignment is off.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > Merge two pr_debug lines with literal strings splitted across several lines > into one single line, simplifying prism2_wep_init error check code. > Openning braces should never be in a new line, move them to the end of > the previous line. > Removed two useless lines at ieee80211_wep_null. > When Joe said "Some will say this is doing too many things in a single patch." he meant Greg. Break this up into multiple patches. Especially now that you've added even more stuff to it. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote:
> Merge two pr_debug lines with literal strings splitted across several lines
> into one single line, simplifying prism2_wep_init error check code.
> Openning braces should never be in a new line, move them to the end of
> the previous line.
> Removed two useless lines at ieee80211_wep_null.
Like Joe Perches said in your last patch - you are doing too many things
in a single patch. break it into separate patches each doing a single
change.
>
> Signed-off-by: Pedro Marzo Perez
> ---
> .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 33
> --
> 1 file changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> index 0a17f84..1074916 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> @@ -9,6 +9,8 @@
> * more details.
> */
>
> -
> + pr_debug(pr_fmt("could not allocate crypto API arc4\n"));
this is not right.
regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: rtl8712: Use ether_addr_copy() instead of memcpy()
Fixes Warning encounter this by applying checkpatch.pl against this file:
Prefer ether_addr_copy() over memcpy() if the Ethernet addresses
are __aligned(2)
pahole output for respective structures:
- addr->sa_data
struct sockaddr {
sa_family_tsa_family;/* 0 2 */
char sa_data[14]; /* 214 */
/* size: 16, cachelines: 1, members: 2 */
/* last cacheline: 16 bytes */
};
- pnetdev->dev_addr
dev_addr is interface address infor from generic net_device structure
which is properly aligned and have some patches with this change as well.
"staging: rtl8712: fix Prefer ether_addr_copy() over memcpy()"
(sha1: 36e4d8826b317080e283e4edd08bf8d5ac706f38)
Signed-off-by: Jagan Teki
Cc: Greg Kroah-Hartman
Cc: Larry Finger
Cc: Florian Schilhabel
---
Changes for v3:
- Removed unaligned conversions
Changes for v2:
- Describe a changelog, to prove address are aligned
drivers/staging/rtl8712/os_intfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/os_intfs.c
b/drivers/staging/rtl8712/os_intfs.c
index 6e776e5..d5f4c4d 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -181,7 +181,7 @@ static int r871x_net_set_mac_address(struct net_device
*pnetdev, void *p)
struct sockaddr *addr = p;
if (padapter->bup == false)
- memcpy(pnetdev->dev_addr, addr->sa_data, ETH_ALEN);
+ ether_addr_copy(pnetdev->dev_addr, addr->sa_data);
return 0;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
On Mon, May 18, 2015 at 09:26:03AM -0700, Joe Perches wrote: > On Mon, 2015-05-18 at 21:35 +0530, Sudip Mukherjee wrote: > > On Mon, May 18, 2015 at 02:44:15PM +, DHANAPAL, GNANACHANDRAN (G.) > > wrote: > > > setup_timer is used for timer parameter setup rather than direct > > > assignment > > > > > > Signed-off-by: Gnanachandran Dhanapal > > > > your From: name and Signed-off-by: names are not matching. They should > > be same. > > If there's a specific "From: " in the _body_ of the email, > that's true, but the sender email "From: " header and the > Signed-off-by: line do not have to match. But Greg usually rejects these patches where the sender "From:" header and Signed-off-by: doesnot match. Just for example: https://lkml.org/lkml/2014/11/25/924 regards sudip > > A "From: " line in the email body should only be used when > the patch is from a different sender than the sign-off. > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] Driver for Arduino-as-I2C-adapter
Hi, On 2015-05-18 15:00, Alex Beregszaszi wrote: There are many cheap I2C adapter projects (mostly USB though). One of the simple ones (i2c-tiny-usb) is included in the kernel [...] I knew of the OpenSource project i2c-tiny-usb. But sadly the hardware ist not sold anywhere (At least I didn't find vendors). As regarding to cheap serial line based adapters, there are two I have seen before [...] None of them seems to have kernel drivers available. So I could stick to my own homebrewn Arduino solution. I am afraid handling serial devices within a i2c kernel driver might be tricky and purists probably dislike the idea. Currently there is at least one driver for such a case already in the kernel: drivers/i2c/busses/i2c-taos-evm.c I found it by "grep serio.h" in i2c/busses/. But this driver rather only supports SMBus which is kind of subset of I2C. Or you could call it I2C with more strict requirements upon timing and protocol. In fact this would have been the driver I would have based my work on if someone said: Go on, this is a good thing to include in the kernel. But for now I think I will just publish the Arduino sketch and a sample implementation on how to access I2C devices with it. greetings, Bernhard -- Wer nicht gelegentlich auch einmal kausalwidrige Dinge zu denken vermag, wird seine Wissenschaft nie um eine neue Idee bereichern können. Max Planck (1858-1947) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: core: Fix line over 80 characters
This patch fixes line over 80 characters warninings while
running checkpatch.pl - "WARNING: line over 80 characters"
Signed-off-by: Jagan Teki
Cc: Greg Kroah-Hartman
Cc: Larry Finger
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 52 +++--
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index e65ee6e..02784dd 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -81,12 +81,14 @@ static void update_BCNTIM(struct adapter *padapter)
u8 *pbackup_remainder_ie = NULL;
uint offset, tmp_len, tim_ielen, tim_ie_offset, remainder_ielen;
- p = rtw_get_ie(pie + _FIXED_IE_LENGTH_, _TIM_IE_, &tim_ielen,
pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_);
+ p = rtw_get_ie(pie + _FIXED_IE_LENGTH_, _TIM_IE_, &tim_ielen,
+ pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_);
if (p != NULL && tim_ielen > 0) {
tim_ielen += 2;
premainder_ie = p+tim_ielen;
tim_ie_offset = (int)(p - pie);
- remainder_ielen = pnetwork_mlmeext->IELength -
tim_ie_offset - tim_ielen;
+ remainder_ielen = pnetwork_mlmeext->IELength -
+ tim_ie_offset - tim_ielen;
/* append TIM IE from dst_ie offset */
dst_ie = p;
} else {
@@ -97,7 +99,10 @@ static void update_BCNTIM(struct adapter *padapter)
offset += pnetwork_mlmeext->Ssid.SsidLength + 2;
/* get supported rates len */
- p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
_SUPPORTEDRATES_IE_, &tmp_len, (pnetwork_mlmeext->IELength -
_BEACON_IE_OFFSET_));
+ p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
+ _SUPPORTEDRATES_IE_, &tmp_len,
+ (pnetwork_mlmeext->IELength -
+ _BEACON_IE_OFFSET_));
if (p != NULL)
offset += tmp_len+2;
@@ -106,7 +111,8 @@ static void update_BCNTIM(struct adapter *padapter)
premainder_ie = pie + offset;
- remainder_ielen = pnetwork_mlmeext->IELength - offset -
tim_ielen;
+ remainder_ielen = pnetwork_mlmeext->IELength -
+ offset - tim_ielen;
/* append TIM IE from offset */
dst_ie = pie + offset;
@@ -115,11 +121,13 @@ static void update_BCNTIM(struct adapter *padapter)
if (remainder_ielen > 0) {
pbackup_remainder_ie = rtw_malloc(remainder_ielen);
if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie, premainder_ie,
remainder_ielen);
+ memcpy(pbackup_remainder_ie,
+ premainder_ie, remainder_ielen);
}
*dst_ie++ = _TIM_IE_;
- if ((pstapriv->tim_bitmap&0xff00) &&
(pstapriv->tim_bitmap&0x00fc))
+ if ((pstapriv->tim_bitmap&0xff00) &&
+ (pstapriv->tim_bitmap&0x00fc))
tim_ielen = 5;
else
tim_ielen = 4;
@@ -154,7 +162,8 @@ static void update_BCNTIM(struct adapter *padapter)
set_tx_beacon_cmd(padapter);
}
-void rtw_add_bcn_ie(struct adapter *padapter, struct wlan_bssid_ex *pnetwork,
u8 index, u8 *data, u8 len)
+void rtw_add_bcn_ie(struct adapter *padapter, struct wlan_bssid_ex *pnetwork,
+ u8 index, u8 *data, u8 len)
{
struct ndis_802_11_var_ie *pIE;
u8 bmatch = false;
@@ -168,7 +177,8 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork, u8
if (pIE->ElementID > index) {
break;
- } else if (pIE->ElementID == index) { /* already exist the
same IE */
+ /* already exist the same IE */
+ } else if (pIE->ElementID == index) {
p = (u8 *)pIE;
ielen = pIE->Length;
bmatch = true;
@@ -197,7 +207,8 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork, u8
if (remainder_ielen > 0) {
pbackup_remainder_ie = rtw_malloc(remainder_ielen);
if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie, premainder_ie,
remainder_ielen);
+ memcpy(pbackup_remainder_ie,
+
[PATCH 1/1 linux-next] staging: xgifb: use swap() in XGI_WriteDAC()
Use kernel.h macro definition.
Signed-off-by: Fabian Frederick
---
drivers/staging/xgifb/vb_setmode.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/xgifb/vb_setmode.c
b/drivers/staging/xgifb/vb_setmode.c
index a47395e..3b0b4d3 100644
--- a/drivers/staging/xgifb/vb_setmode.c
+++ b/drivers/staging/xgifb/vb_setmode.c
@@ -1081,24 +1081,17 @@ static void XGI_WriteDAC(unsigned short dl,
unsigned short dh,
struct vb_device_info *pVBInfo)
{
- unsigned short temp, bh, bl;
+ unsigned short bh, bl;
bh = ah;
bl = al;
if (dl != 0) {
- temp = bh;
- bh = dh;
- dh = temp;
- if (dl == 1) {
- temp = bl;
- bl = dh;
- dh = temp;
- } else {
- temp = bl;
- bl = bh;
- bh = temp;
- }
+ swap(bh, dh);
+ if (dl == 1)
+ swap(bl, dh);
+ else
+ swap(bl, bh);
}
outb((unsigned short) dh, pVBInfo->P3c9);
outb((unsigned short) bh, pVBInfo->P3c9);
--
2.4.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
> void _setup_timer(struct timer_list *ptimer, void *fun, unsigned long data)
> {
> - ptimer->function = fun;
> - ptimer->data = data;
> init_timer(ptimer);
> + setup_timer(ptimer, fun, data);
> }
setup_timer also subsumes init_timer. Check the definition. Probably you
can delete this function completely.
julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging: comedi: fix line longer than 80 chars in cb_pcidas64.c
Sudip Mukherjee wrote:
> On Sun, May 17, 2015 at 04:47:23PM +0200, Amaury Denoyelle wrote:
> > This patch fixes coding style errors reported by checkpatch.pl for
> > cb_pcidas64.c, about too long source code lines.
> >
> > Signed-off-by: Amaury Denoyelle
> > ---
>
> > }
> >
> > -/* adjusts the size of hardware fifo (which determines block size for dma
> > xfers) */
> > +/* adjusts the size of hardware fifo
> > + * (which determines block size for dma xfers) */
>
> This is not the style for multi-line comments. Please check CodingStyle
> in Documentation.
>
> > static int set_ai_fifo_size(struct comedi_device *dev, unsigned int
> > num_samples)
> > {
>
> >
> > @@ -1987,8 +1990,8 @@ static unsigned int get_divisor(unsigned int ns,
> > unsigned int flags)
> >
> > /* utility function that rounds desired timing to an achievable time, and
> > * sets cmd members appropriately.
> > - * adc paces conversions from master clock by dividing by (x + 3) where x
> > is 24 bit number
> > - */
> > + * adc paces conversions from master clock by dividing by (x + 3) where x
> > is
> > + * 24 bit number */
> same here
>
> and when you are sending just one patch, you do not need to mention
> [Patch 1/1] in the subject. just mention [Patch]
>
> regards
> sudip
Thanks for your review. I was aware of the coding style for multi-line
comments, but I chose to follow the same convention already used in the source
file.
I submit a new version where I respect the coding style in the comments I
fixed. I editted only multi-line comments that were too long, in order to not
have a messy patch. If you think it's better to be done, maybe I could submit a
two-part patch.
regards,
--
Amaury Denoyelle
From f91eadba14278565683f4ea950e94f69c2822c1d Mon Sep 17 00:00:00 2001
From: Amaury Denoyelle
Date: Sun, 17 May 2015 15:53:50 +0200
Subject: [PATCH v2] Staging: comedi: fix line longer than 80 chars in
cb_pcidas64.c
This patch fixes coding style errors reported by checkpatch.pl for
cb_pcidas64.c, about too long source code lines.
Adjust edited multi-line comments according to kernel coding style
Signed-off-by: Amaury Denoyelle
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c b/drivers/staging/comedi/drivers/cb_pcidas64.c
index a94c33c..dc2d884 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -243,7 +243,8 @@ enum adc_control0_contents {
ADC_SOFT_GATE_BITS = 0x1, /* software gate */
ADC_EXT_GATE_BITS = 0x2, /* external digital gate */
ADC_ANALOG_GATE_BITS = 0x3, /* analog level gate */
- ADC_GATE_LEVEL_BIT = 0x4, /* level-sensitive gate (for digital) */
+ /* level-sensitive gate (for digital) */
+ ADC_GATE_LEVEL_BIT = 0x4,
ADC_GATE_POLARITY_BIT = 0x8, /* gate active low */
ADC_START_TRIG_SOFT_BITS = 0x10,
ADC_START_TRIG_EXT_BITS = 0x20,
@@ -1381,7 +1382,9 @@ static int set_ai_fifo_segment_length(struct comedi_device *dev,
return devpriv->ai_fifo_segment_length;
}
-/* adjusts the size of hardware fifo (which determines block size for dma xfers) */
+/*
+ * adjusts the size of hardware fifo (which determines block size for dma xfers)
+ */
static int set_ai_fifo_size(struct comedi_device *dev, unsigned int num_samples)
{
const struct pcidas64_board *thisboard = dev->board_ptr;
@@ -1588,7 +1591,9 @@ static inline void warn_external_queue(struct comedi_device *dev)
"Use internal AI channel queue (channels must be consecutive and use same range/aref)\n");
}
-/* Their i2c requires a huge delay on setting clock or data high for some reason */
+/*
+ * their i2c requires a huge delay on setting clock or data high for some reason
+ */
static const int i2c_high_udelay = 1000;
static const int i2c_low_udelay = 10;
@@ -1985,9 +1990,11 @@ static unsigned int get_divisor(unsigned int ns, unsigned int flags)
return divisor;
}
-/* utility function that rounds desired timing to an achievable time, and
+/*
+ * utility function that rounds desired timing to an achievable time, and
* sets cmd members appropriately.
- * adc paces conversions from master clock by dividing by (x + 3) where x is 24 bit number
+ * adc paces conversions from master clock by dividing by (x + 3) where x is
+ * 24 bit number
*/
static void check_adc_timing(struct comedi_device *dev, struct comedi_cmd *cmd)
{
--
2.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] Staging: lustre: Fixed typo
In the explanation of the function the name of the function was incorrect Signed-off-by: Adrian Remonda --- drivers/staging/lustre/lustre/ptlrpc/nrs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c b/drivers/staging/lustre/lustre/ptlrpc/nrs.c index 159db41c53a0..43da95f0bce2 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c +++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c @@ -478,7 +478,7 @@ static void nrs_resource_get_safe(struct ptlrpc_nrs *nrs, * * \param resp the resource hierarchy that is being released * - * \see ptlrpcnrs_req_hp_move() + * \see ptlrpc_nrs_req_hp_move() * \see ptlrpc_nrs_req_finalize() */ static void nrs_resource_put_safe(struct ptlrpc_nrs_resource **resp) -- 2.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] Staging: lustre: sparse lock warning fix
Fixed sparse warning: context imbalance in 'nrs_resource_put_safe' -
'different lock contexts for basic block' by releasing the lock on each
iteration of the for loop.
Signed-off-by: Adrian Remonda
---
drivers/staging/lustre/lustre/ptlrpc/nrs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
index 43da95f0bce2..3a1722437ca1 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
@@ -503,13 +503,11 @@ static void nrs_resource_put_safe(struct
ptlrpc_nrs_resource **resp)
if (nrs == NULL) {
nrs = pols[i]->pol_nrs;
- spin_lock(&nrs->nrs_lock);
}
+ spin_lock(&nrs->nrs_lock);
nrs_policy_put_locked(pols[i]);
- }
-
- if (nrs != NULL)
spin_unlock(&nrs->nrs_lock);
+ }
}
/**
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] Staging: lustre: sparse static warning fix
This patch clears the warning given by sparse that the function should be
static.
Done by moving the declaration of the structure 'nrs_core' into the header
'ptlrpc_internal.h'
modified: drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
modified: drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h
Signed-off-by: Adrian Remonda
---
drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 6 --
drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h | 7 +++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
b/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
index aeceef5152ac..300310e064f5 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c
@@ -417,12 +417,6 @@ ptlrpc_lprocfs_threads_max_seq_write(struct file *file,
LPROC_SEQ_FOPS(ptlrpc_lprocfs_threads_max);
/**
- * \addtogoup nrs
- * @{
- */
-extern struct nrs_core nrs_core;
-
-/**
* Translates \e ptlrpc_nrs_pol_state values to human-readable strings.
*
* \param[in] state The policy state
diff --git a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h
b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h
index e07e2aacc62c..f9bfcff2ac9b 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h
+++ b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h
@@ -313,4 +313,11 @@ static inline void ptlrpc_reqset_put(struct
ptlrpc_request_set *set)
/* ptlrpc/nrs_fifo.c */
extern struct ptlrpc_nrs_pol_conf nrs_conf_fifo;
+/**
+ * \addtogoup nrs
+ * @{
+ */
+extern struct nrs_core nrs_core;
+
+
#endif /* PTLRPC_INTERNAL_H */
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] Staging: lustre: sparse static warning fix
This patch clears the warning given by sparse that the function should be static. Done by moving the declaration of the structure 'nrs_conf_fifo' into the header 'ptlrpc_internal.h' modified: drivers/staging/lustre/lustre/ptlrpc/nrs.c modified: drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h Signed-off-by: Adrian Remonda --- drivers/staging/lustre/lustre/ptlrpc/nrs.c | 4 drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c b/drivers/staging/lustre/lustre/ptlrpc/nrs.c index 63a05f4a902d..159db41c53a0 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c +++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c @@ -1698,10 +1698,6 @@ out: return rc; } - -/* ptlrpc/nrs_fifo.c */ -extern struct ptlrpc_nrs_pol_conf nrs_conf_fifo; - /** * Adds all policies that ship with the ptlrpc module, to NRS core's list of * policies \e nrs_core.nrs_policies. diff --git a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h index a66dc3c6da41..e07e2aacc62c 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h +++ b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h @@ -309,4 +309,8 @@ static inline void ptlrpc_reqset_put(struct ptlrpc_request_set *set) if (atomic_dec_and_test(&set->set_refcount)) OBD_FREE_PTR(set); } + +/* ptlrpc/nrs_fifo.c */ +extern struct ptlrpc_nrs_pol_conf nrs_conf_fifo; + #endif /* PTLRPC_INTERNAL_H */ -- 2.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: comedi: fix line longer than 80 chars in cb_pcidas64.c
> Sudip Mukherjee wrote:
>
> > On Sun, May 17, 2015 at 04:47:23PM +0200, Amaury Denoyelle wrote:
> > > This patch fixes coding style errors reported by checkpatch.pl for
> > > cb_pcidas64.c, about too long source code lines.
> > >
> > > Signed-off-by: Amaury Denoyelle
> > > ---
> >
> > > }
> > >
> > > -/* adjusts the size of hardware fifo (which determines block size for
> > > dma xfers) */
> > > +/* adjusts the size of hardware fifo
> > > + * (which determines block size for dma xfers) */
> >
> > This is not the style for multi-line comments. Please check CodingStyle
> > in Documentation.
> >
> > > static int set_ai_fifo_size(struct comedi_device *dev, unsigned int
> > > num_samples)
> > > {
> >
> > >
> > > @@ -1987,8 +1990,8 @@ static unsigned int get_divisor(unsigned int ns,
> > > unsigned int flags)
> > >
> > > /* utility function that rounds desired timing to an achievable time, and
> > > * sets cmd members appropriately.
> > > - * adc paces conversions from master clock by dividing by (x + 3) where
> > > x is 24 bit number
> > > - */
> > > + * adc paces conversions from master clock by dividing by (x + 3) where
> > > x is
> > > + * 24 bit number */
> > same here
> >
> > and when you are sending just one patch, you do not need to mention
> > [Patch 1/1] in the subject. just mention [Patch]
> >
> > regards
> > sudip
>
Looks like I did not properly joined patch with previous mail, so I resend it.
Really sorry for the noise...
So, like I was stated in previous mail;
Thanks for your review. I was aware of the coding style for multi-line
comments, but I chose to follow the same convention already used in the source
file.
I submit a new version where I respect the coding style in the comments I
fixed. I editted only multi-line comments that were too long, in order to not
have a messy patch. If you think it's better to be done, maybe I could submit a
two-part patch.
Signed-off-by: Amaury Denoyelle
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index a94c33c..dc2d884 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -243,7 +243,8 @@ enum adc_control0_contents {
ADC_SOFT_GATE_BITS = 0x1, /* software gate */
ADC_EXT_GATE_BITS = 0x2,/* external digital gate */
ADC_ANALOG_GATE_BITS = 0x3, /* analog level gate */
- ADC_GATE_LEVEL_BIT = 0x4, /* level-sensitive gate (for digital)
*/
+ /* level-sensitive gate (for digital) */
+ ADC_GATE_LEVEL_BIT = 0x4,
ADC_GATE_POLARITY_BIT = 0x8,/* gate active low */
ADC_START_TRIG_SOFT_BITS = 0x10,
ADC_START_TRIG_EXT_BITS = 0x20,
@@ -1381,7 +1382,9 @@ static int set_ai_fifo_segment_length(struct
comedi_device *dev,
return devpriv->ai_fifo_segment_length;
}
-/* adjusts the size of hardware fifo (which determines block size for dma
xfers) */
+/*
+ * adjusts the size of hardware fifo (which determines block size for dma
xfers)
+ */
static int set_ai_fifo_size(struct comedi_device *dev, unsigned int
num_samples)
{
const struct pcidas64_board *thisboard = dev->board_ptr;
@@ -1588,7 +1591,9 @@ static inline void warn_external_queue(struct
comedi_device *dev)
"Use internal AI channel queue (channels must be consecutive
and use same range/aref)\n");
}
-/* Their i2c requires a huge delay on setting clock or data high for some
reason */
+/*
+ * their i2c requires a huge delay on setting clock or data high for some
reason
+ */
static const int i2c_high_udelay = 1000;
static const int i2c_low_udelay = 10;
@@ -1985,9 +1990,11 @@ static unsigned int get_divisor(unsigned int ns,
unsigned int flags)
return divisor;
}
-/* utility function that rounds desired timing to an achievable time, and
+/*
+ * utility function that rounds desired timing to an achievable time, and
* sets cmd members appropriately.
- * adc paces conversions from master clock by dividing by (x + 3) where x is
24 bit number
+ * adc paces conversions from master clock by dividing by (x + 3) where x is
+ * 24 bit number
*/
static void check_adc_timing(struct comedi_device *dev, struct comedi_cmd *cmd)
{
--
2.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/6] vme: DMA improvements
The first item in this submission documents previously introduced
vme_master_mmap() call. Following, there are three fixes for the tsi148
driver's DMA. There was one bug that rendered it imposible to use DMA
lists with more than one item. The other was related to the place where
dma_map_single was called on the first DMA descriptor in the DMA list. The
last bug was about DMA transfer not stopping at interruption by signal,
which is a possible DoS attack vector. I also made an attempt to fix the
same issue in the ca91cx42 driver. I don't have access to this hardware to
test, so this is based only on my understanding of the datasheet (checked
ca91c042's errata as well).
A new /sys/bus/vme/dma0 device with a new ioctl for making DMA transfers
was introduced in vme_user driver. The logic of the function is similar to
the one found in similar existing drivers.
One question that I had while implementing this feature was whether we
should keep vme_dma_attr objects until vme_dma_list_exec() call. API
doesn't specify this, the existing vme bridge drivers copy all information
from attributes during vme_dma_list_add(). So for simplicity this
implementation frees vme_dma_attr's before vme_dma_list_exec() is done.
A simple test against AVM16 board displays speeds around 45 MiB/s for
A32/D32 reads for both BLT and MBLT (with MBLT being slightly faster).
Dmitry Kalinkin (6):
Documentation: mention vme_master_mmap() in VME API
vme: tsi148: fix DMA lists longer that one item
vme: tsi148: fix first DMA item mapping
vme: stop DMA transfer on interruption
staging: vme_user: refactor llseek to switch(){}
staging: vme_user: provide DMA functionality
Documentation/vme_api.txt | 6 ++
drivers/staging/vme/devices/vme_user.c | 188 +++--
drivers/staging/vme/devices/vme_user.h | 11 ++
drivers/vme/bridges/vme_ca91cx42.c | 15 ++-
drivers/vme/bridges/vme_tsi148.c | 42 +---
5 files changed, 237 insertions(+), 25 deletions(-)
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] Documentation: mention vme_master_mmap() in VME API
Signed-off-by: Dmitry Kalinkin Cc: Igor Alekseev --- Documentation/vme_api.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/vme_api.txt b/Documentation/vme_api.txt index ffe6e22..ca5b827 100644 --- a/Documentation/vme_api.txt +++ b/Documentation/vme_api.txt @@ -171,6 +171,12 @@ This functions by reading the offset, applying the mask. If the bits selected in the mask match with the values of the corresponding bits in the compare field, the value of swap is written the specified offset. +Parts of a VME window can be mapped into user space memory using the following +function: + + int vme_master_mmap(struct vme_resource *resource, + struct vm_area_struct *vma) + Slave windows = -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/6] vme: tsi148: fix first DMA item mapping
This moves DMA mapping of the first list element to vme_list_add, the
same place where other elements mappings occur. This prevents extra
mapping or over-unmapping in the cases when vme_list_exec is called more
or less than one time respectively.
Also adds dma_mapping_error check.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
drivers/vme/bridges/vme_tsi148.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 1be4136..03b0755 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -1833,17 +1833,21 @@ static int tsi148_dma_list_add(struct vme_dma_list
*list,
/* Add to list */
list_add_tail(&entry->list, &list->entries);
+ entry->dma_handle = dma_map_single(tsi148_bridge->parent,
+ &entry->descriptor,
+ sizeof(struct tsi148_dma_descriptor), DMA_TO_DEVICE);
+ if (dma_mapping_error(tsi148_bridge->parent, entry->dma_handle)) {
+ dev_err(tsi148_bridge->parent, "DMA mapping error\n");
+ retval = -EINVAL;
+ goto err_dma;
+ }
+
/* Fill out previous descriptors "Next Address" */
if (entry->list.prev != &list->entries) {
- prev = list_entry(entry->list.prev, struct tsi148_dma_entry,
- list);
- /* We need the bus address for the pointer */
- entry->dma_handle = dma_map_single(tsi148_bridge->parent,
- &entry->descriptor,
- sizeof(struct tsi148_dma_descriptor), DMA_TO_DEVICE);
-
reg_split((unsigned long long)entry->dma_handle, &address_high,
&address_low);
+ prev = list_entry(entry->list.prev, struct tsi148_dma_entry,
+ list);
prev->descriptor.dnlau = cpu_to_be32(address_high);
prev->descriptor.dnlal = cpu_to_be32(address_low);
@@ -1851,6 +1855,7 @@ static int tsi148_dma_list_add(struct vme_dma_list *list,
return 0;
+err_dma:
err_dest:
err_source:
err_align:
@@ -1921,10 +1926,6 @@ static int tsi148_dma_list_exec(struct vme_dma_list
*list)
entry = list_first_entry(&list->entries, struct tsi148_dma_entry,
list);
- entry->dma_handle = dma_map_single(tsi148_bridge->parent,
- &entry->descriptor,
- sizeof(struct tsi148_dma_descriptor), DMA_TO_DEVICE);
-
mutex_unlock(&ctrlr->mtx);
reg_split(entry->dma_handle, &bus_addr_high, &bus_addr_low);
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: vme_user: refactor llseek to switch(){}
This makes vme_user_llseek ignore all minors that don't have llseek
implementation.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
drivers/staging/vme/devices/vme_user.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 19ba749..da828f4 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -430,15 +430,17 @@ static loff_t vme_user_llseek(struct file *file, loff_t
off, int whence)
size_t image_size;
loff_t res;
- if (minor == CONTROL_MINOR)
- return -EINVAL;
-
- mutex_lock(&image[minor].mutex);
- image_size = vme_get_size(image[minor].resource);
- res = fixed_size_llseek(file, off, whence, image_size);
- mutex_unlock(&image[minor].mutex);
+ switch (type[minor]) {
+ case MASTER_MINOR:
+ case SLAVE_MINOR:
+ mutex_lock(&image[minor].mutex);
+ image_size = vme_get_size(image[minor].resource);
+ res = fixed_size_llseek(file, off, whence, image_size);
+ mutex_unlock(&image[minor].mutex);
+ return res;
+ }
- return res;
+ return -EINVAL;
}
/*
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] vme: tsi148: fix DMA lists longer that one item
DMA lists on tsi148 weren't processed further than the first item because of the broken logic. This regression was introduced in: ac1a4f2caf7b071 "Staging: VME: Ensure TSI148 link list descriptors..." Signed-off-by: Dmitry Kalinkin Cc: Igor Alekseev --- drivers/vme/bridges/vme_tsi148.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c index 895c2a3..1be4136 100644 --- a/drivers/vme/bridges/vme_tsi148.c +++ b/drivers/vme/bridges/vme_tsi148.c @@ -1844,8 +1844,8 @@ static int tsi148_dma_list_add(struct vme_dma_list *list, reg_split((unsigned long long)entry->dma_handle, &address_high, &address_low); - entry->descriptor.dnlau = cpu_to_be32(address_high); - entry->descriptor.dnlal = cpu_to_be32(address_low); + prev->descriptor.dnlau = cpu_to_be32(address_high); + prev->descriptor.dnlal = cpu_to_be32(address_low); } -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6] vme: stop DMA transfer on interruption
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
drivers/vme/bridges/vme_ca91cx42.c | 15 +--
drivers/vme/bridges/vme_tsi148.c | 15 +--
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 18078ec..ffb8e91 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -1192,7 +1192,7 @@ static int ca91cx42_dma_list_exec(struct vme_dma_list
*list)
{
struct vme_dma_resource *ctrlr;
struct ca91cx42_dma_entry *entry;
- int retval = 0;
+ int retval;
dma_addr_t bus_addr;
u32 val;
struct device *dev;
@@ -1245,9 +1245,19 @@ static int ca91cx42_dma_list_exec(struct vme_dma_list
*list)
iowrite32(val, bridge->base + DGCS);
- wait_event_interruptible(bridge->dma_queue,
+ retval = wait_event_interruptible(bridge->dma_queue,
ca91cx42_dma_busy(ctrlr->parent));
+ if (retval) {
+ val = ioread32(bridge->base + DGCS);
+ iowrite32(val | CA91CX42_DGCS_STOP_REQ, bridge->base + DGCS);
+ /* Wait for the operation to abort */
+ wait_event(bridge->dma_queue,
+ ca91cx42_dma_busy(ctrlr->parent));
+ retval = -EINTR;
+ goto exit;
+ }
+
/*
* Read status register, this register is valid until we kick off a
* new transfer.
@@ -1261,6 +1271,7 @@ static int ca91cx42_dma_list_exec(struct vme_dma_list
*list)
val = ioread32(bridge->base + DCTL);
}
+exit:
/* Remove list from running list */
mutex_lock(&ctrlr->mtx);
list_del(&list->list);
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 03b0755..f6c455e 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -1892,7 +1892,7 @@ static int tsi148_dma_busy(struct vme_bridge
*tsi148_bridge, int channel)
static int tsi148_dma_list_exec(struct vme_dma_list *list)
{
struct vme_dma_resource *ctrlr;
- int channel, retval = 0;
+ int channel, retval;
struct tsi148_dma_entry *entry;
u32 bus_addr_high, bus_addr_low;
u32 val, dctlreg = 0;
@@ -1942,9 +1942,19 @@ static int tsi148_dma_list_exec(struct vme_dma_list
*list)
iowrite32be(dctlreg | TSI148_LCSR_DCTL_DGO, bridge->base +
TSI148_LCSR_DMA[channel] + TSI148_LCSR_OFFSET_DCTL);
- wait_event_interruptible(bridge->dma_queue[channel],
+ retval = wait_event_interruptible(bridge->dma_queue[channel],
tsi148_dma_busy(ctrlr->parent, channel));
+ if (retval) {
+ iowrite32be(dctlreg | TSI148_LCSR_DCTL_ABT, bridge->base +
+ TSI148_LCSR_DMA[channel] + TSI148_LCSR_OFFSET_DCTL);
+ /* Wait for the operation to abort */
+ wait_event(bridge->dma_queue[channel],
+ tsi148_dma_busy(ctrlr->parent, channel));
+ retval = -EINTR;
+ goto exit;
+ }
+
/*
* Read status register, this register is valid until we kick off a
* new transfer.
@@ -1957,6 +1967,7 @@ static int tsi148_dma_list_exec(struct vme_dma_list *list)
retval = -EIO;
}
+exit:
/* Remove list from running list */
mutex_lock(&ctrlr->mtx);
list_del(&list->list);
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/6] staging: vme_user: provide DMA functionality
This introduces a new dma device that provides a single ioctl call that
provides DMA read and write functionality to the user space.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
drivers/staging/vme/devices/vme_user.c | 174 -
drivers/staging/vme/devices/vme_user.h | 11 +++
2 files changed, 183 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index da828f4..aca1e0b 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -79,13 +79,14 @@ static unsigned int bus_num;
* We shall support 4 masters and 4 slaves with this driver.
*/
#define VME_MAJOR 221 /* VME Major Device Number */
-#define VME_DEVS 9 /* Number of dev entries */
+#define VME_DEVS 10 /* Number of dev entries */
#define MASTER_MINOR 0
#define MASTER_MAX 3
#define SLAVE_MINOR4
#define SLAVE_MAX 7
#define CONTROL_MINOR 8
+#define DMA_MINOR 9
#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
@@ -125,7 +126,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
MASTER_MINOR, MASTER_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
- CONTROL_MINOR
+ CONTROL_MINOR, DMA_MINOR
};
@@ -443,6 +444,145 @@ static loff_t vme_user_llseek(struct file *file, loff_t
off, int whence)
return -EINVAL;
}
+static int vme_user_sg_to_dma_list(const struct vme_dma_op *dma_op,
+ struct sg_table *sgt, int sg_count, struct vme_dma_list *dma_list)
+{
+ ssize_t pos = 0;
+ struct scatterlist *sg;
+ int i, ret;
+
+ for_each_sg(sgt->sgl, sg, sg_count, i) {
+ struct vme_dma_attr *pci_attr, *vme_attr, *dest, *src;
+ dma_addr_t hw_address = sg_dma_address(sg);
+ unsigned int hw_len = sg_dma_len(sg);
+
+ vme_attr = vme_dma_vme_attribute(dma_op->vme_addr + pos,
+ dma_op->aspace, dma_op->cycle, dma_op->dwidth);
+ if (!vme_attr)
+ return -ENOMEM;
+
+ pci_attr = vme_dma_pci_attribute(hw_address);
+ if (!pci_attr) {
+ vme_dma_free_attribute(vme_attr);
+ return -ENOMEM;
+ }
+
+ if (dma_op->write) {
+ dest = vme_attr;
+ src = pci_attr;
+ } else {
+ dest = pci_attr;
+ src = vme_attr;
+ }
+
+ ret = vme_dma_list_add(dma_list, src, dest, hw_len);
+
+ /*
+* XXX VME API doesn't mention whether we should keep
+* attributes around
+*/
+ vme_dma_free_attribute(vme_attr);
+ vme_dma_free_attribute(pci_attr);
+
+ if (ret)
+ return ret;
+
+ pos += hw_len;
+ }
+
+ WARN_ON(pos != dma_op->count);
+
+ return 0;
+}
+
+static ssize_t vme_user_dma_ioctl(unsigned int minor,
+ const struct vme_dma_op *dma_op)
+{
+ unsigned int offset = offset_in_page(dma_op->buf_vaddr);
+ unsigned long nr_pages;
+ enum dma_data_direction dir;
+ struct vme_dma_list *dma_list;
+ struct sg_table *sgt = NULL;
+ struct page **pages = NULL;
+ long got_pages;
+ int ret, sg_count;
+
+ /* Overflow check for nr_pages */
+ if (dma_op->count > U32_MAX - 2 * PAGE_SIZE)
+ return -EINVAL;
+
+ /* Prevent WARN from dma_map_sg */
+ if (dma_op->count == 0)
+ return 0;
+
+ nr_pages = (offset + dma_op->count + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ dir = dma_op->write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+
+ pages = kmalloc_array(nr_pages, sizeof(pages[0]), GFP_KERNEL);
+ if (!pages) {
+ ret = -ENOMEM;
+ goto free;
+ }
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt) {
+ ret = -ENOMEM;
+ goto free;
+ }
+
+ dma_list = vme_new_dma_list(image[minor].resource);
+ if (!dma_list) {
+ ret = -ENOMEM;
+ goto free;
+ }
+
+ got_pages = get_user_pages_fast(dma_op->buf_vaddr, nr_pages,
+ !dma_op->write, pages);
+ if (got_pages != nr_pages) {
+ pr_debug("Not all pages were pinned\n");
+ ret = (got_pages < 0) ? got_pages : -EFAULT;
+ goto release_pages;
+ }
+
+ ret = sg_alloc_table_from_pages(sgt, pages, nr_pages,
+ offset, dma_op->count, GFP_KERNEL);
+ if (ret)
+
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, 2015-05-18 at 21:53 +0530, Sudip Mukherjee wrote:
> On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote:
> > Merge two pr_debug lines with literal strings splitted across several lines
> > into one single line, simplifying prism2_wep_init error check code.
> > Openning braces should never be in a new line, move them to the end of
> > the previous line.
> > Removed two useless lines at ieee80211_wep_null.
>
> Like Joe Perches said in your last patch - you are doing too many things
> in a single patch. break it into separate patches each doing a single
> change.
>
Agree
> >
> > Signed-off-by: Pedro Marzo Perez
> > ---
> > .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 33
> > --
> > 1 file changed, 12 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > index 0a17f84..1074916 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > @@ -9,6 +9,8 @@
> > * more details.
> > */
> >
>
> > -
> > + pr_debug(pr_fmt("could not allocate crypto API arc4\n"));
> this is not right.
Completely agree
Will be fixed at v3
>
> regards
> sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, 2015-05-18 at 19:15 +0300, Dan Carpenter wrote: > On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > > Merge two pr_debug lines with literal strings splitted across several lines > > into one single line, simplifying prism2_wep_init error check code. > > Openning braces should never be in a new line, move them to the end of > > the previous line. > > Removed two useless lines at ieee80211_wep_null. > > > > When Joe said "Some will say this is doing too many things in a single > patch." he meant Greg. Break this up into multiple patches. Especially > now that you've added even more stuff to it. > > regards, > dan carpenter Sorry Joe, English is not my mother tongue and I misunderstand your comment, I thought "Some will say this is doing too many things in a single patch" did meant "You are on the limit, but it is ok to send it in one patch" but I see it really means "please, rewrite this whole crap into several patches" :-) So I guess an v3 patch should be a chain of several patches, I think a sensible approach would be three patches 1/3 => rewrite of the error check code 2/3 => remove of the two useless lines at ieee80211_wep_null. 3/3 => move openning braces and correct the indentation of the #include What do you think about it? regards, Pedro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, 2015-05-18 at 23:56 +0200, pmarzo wrote: > On Mon, 2015-05-18 at 19:15 +0300, Dan Carpenter wrote: > > On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > > > Merge two pr_debug lines with literal strings splitted across several > > > lines > > > into one single line, simplifying prism2_wep_init error check code. > > > Openning braces should never be in a new line, move them to the end of > > > the previous line. > > > Removed two useless lines at ieee80211_wep_null. > > > > > > > When Joe said "Some will say this is doing too many things in a single > > patch." he meant Greg. Break this up into multiple patches. Especially > > now that you've added even more stuff to it. > > > > regards, > > dan carpenter > > Sorry Joe, English is not my mother tongue and I misunderstand your > comment, I thought "Some will say this is doing too many things in a > single patch" did meant "You are on the limit, but it is ok to send it > in one patch" but I see it really means "please, rewrite this whole crap > into several patches" :-) What I meant to say was I don't care as much about mixing multiple types of fixes in a single patch as others might. Greg does and generally rejects patches that mix fix types. My preference is to do _all_ whitespace changes in a single patch. If "git diff -w" shows no source code changes, and objdiff shows no object code change, that's a "single type" of change to me. Others disagree and may want whitespace changes broken down into finer-grained blocks. I think it's not necessary to modify the same line multiple times just to get this granularity. btw: using: $ ./scripts/checkpatch.pl -f --strict --fix-inplace \ --types=spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space,space_before_tab,indented_label,parenthesis_alignment \ $file can do this moderately well and there's a trivial script to use checkpatch and git to create a patch series for various checkpatch type style messages. https://lkml.org/lkml/2014/7/11/794 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, 2015-05-18 at 13:04 -0700, Joe Perches wrote: > On Mon, 2015-05-18 at 23:56 +0200, pmarzo wrote: > > On Mon, 2015-05-18 at 19:15 +0300, Dan Carpenter wrote: > > > On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > > > > Merge two pr_debug lines with literal strings splitted across several > > > > lines > > > > into one single line, simplifying prism2_wep_init error check code. > > > > Openning braces should never be in a new line, move them to the end of > > > > the previous line. > > > > Removed two useless lines at ieee80211_wep_null. > > > > > > > > > > When Joe said "Some will say this is doing too many things in a single > > > patch." he meant Greg. Break this up into multiple patches. Especially > > > now that you've added even more stuff to it. > > > > > > regards, > > > dan carpenter > > > > Sorry Joe, English is not my mother tongue and I misunderstand your > > comment, I thought "Some will say this is doing too many things in a > > single patch" did meant "You are on the limit, but it is ok to send it > > in one patch" but I see it really means "please, rewrite this whole crap > > into several patches" :-) > > What I meant to say was I don't care as much about mixing > multiple types of fixes in a single patch as others might. > > Greg does and generally rejects patches that mix fix types. > > My preference is to do _all_ whitespace changes in a single > patch. If "git diff -w" shows no source code changes, and > objdiff shows no object code change, that's a "single type" > of change to me. > > Others disagree and may want whitespace changes broken down > into finer-grained blocks. > > I think it's not necessary to modify the same line multiple > times just to get this granularity. > Thanku Joe, as Greg is the maintainer of the staging tree and is his final decission I will split the patch > btw: using: > > $ ./scripts/checkpatch.pl -f --strict --fix-inplace \ > > --types=spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space,space_before_tab,indented_label,parenthesis_alignment > \ >$file > Nice to see a script programs far better than me :-( > can do this moderately well and there's a trivial script to > use checkpatch and git to create a patch series for various > checkpatch type style messages. > > https://lkml.org/lkml/2014/7/11/794 > > Nice script to check I did not break anything! However I have modified the error check code, so I guess the generated object will be different. I will use it next time I try to correct style issues (that would certainly not be in the near future :-) ) regards, Pedro. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: replace printk with subsystem debug
Hi,
On 18.05.2015 13:27, Gujulan Elango, Hari Prasath (H.) wrote:
> replace the printk with netdev subsystem debug infrastructure.
>
> Signed-off-by: Hari Prasath Gujulan Elango
> ---
> drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
> b/drivers/staging/rtl8192e/rtllib_rx.c
> index fe3e7e12..f6e3f83 100644
> --- a/drivers/staging/rtl8192e/rtllib_rx.c
> +++ b/drivers/staging/rtl8192e/rtllib_rx.c
> @@ -344,7 +344,7 @@ rtllib_rx_frame_decrypt_msdu(struct rtllib_device *ieee,
> struct sk_buff *skb,
> res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv);
> atomic_dec(&crypt->refcnt);
> if (res < 0) {
> - printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed
> (SA= %pM keyidx=%d)\n",
> + netdev_dbg(ieee->dev, "%s: MSDU decryption/MIC verification
> failed (SA= %pM keyidx=%d)\n",
> ieee->dev->name, hdr->addr2, keyidx);
> return -1;
> }
>
I posted it already in one of my patches (v2, v3 - now I'm working on v4 with
this change as well):
https://lkml.org/lkml/2015/5/9/200 <- v3
https://lkml.org/lkml/2015/4/13 <- v2
Regards,
Mateusz
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Tue, 2015-05-19 at 00:35 +0200, pmarzo wrote: > On Mon, 2015-05-18 at 13:04 -0700, Joe Perches wrote: > > btw: using: > > > > $ ./scripts/checkpatch.pl -f --strict --fix-inplace \ > > > > --types=spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space,space_before_tab,indented_label,parenthesis_alignment > > \ > >$file > > > Nice to see a script programs far better than me :-( Nah... The script is a stupid little tool. People like you are much better at making actually useful improvements to code. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Mon, May 18, 2015 at 11:56:08PM +0200, pmarzo wrote: > On Mon, 2015-05-18 at 19:15 +0300, Dan Carpenter wrote: > > On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > > > Merge two pr_debug lines with literal strings splitted across several > > > lines > > > into one single line, simplifying prism2_wep_init error check code. > > > Openning braces should never be in a new line, move them to the end of > > > the previous line. > > > Removed two useless lines at ieee80211_wep_null. > > > > > > > When Joe said "Some will say this is doing too many things in a single > > patch." he meant Greg. Break this up into multiple patches. Especially > > now that you've added even more stuff to it. > > > > regards, > > dan carpenter > > Sorry Joe, English is not my mother tongue and I misunderstand your > comment, I thought "Some will say this is doing too many things in a > single patch" did meant "You are on the limit, but it is ok to send it > in one patch" but I see it really means "please, rewrite this whole crap > into several patches" :-) The line is a fuzzy line. You were maybe on the line, maybe but then you crossed over. > > So I guess an v3 patch should be a chain of several patches, I think a > sensible approach would be three patches > 1/3 => rewrite of the error check code > 2/3 => remove of the two useless lines at ieee80211_wep_null. > 3/3 => move openning braces and correct the indentation of the > #include > > What do you think about it? That sounds fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8192e: Timer setup using macro rather assignment
On Mon, 2015-05-18 at 21:35 +0530, Sudip Mukherjee wrote: > On Mon, May 18, 2015 at 02:44:15PM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > > setup_timer is used for timer parameter setup rather than direct > > assignment > > > > Signed-off-by: Gnanachandran Dhanapal > > your From: name and Signed-off-by: names are not matching. They should > be same. If there's a specific "From: " in the _body_ of the email, that's true, but the sender email "From: " header and the Signed-off-by: line do not have to match. A "From: " line in the email body should only be used when the patch is from a different sender than the sign-off. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/4] Staging: lustre: sparse lock warning fix
On Mon, May 18, 2015 at 08:34:51PM +0200, Adrian Remonda wrote: > Fixed sparse warning: context imbalance in 'nrs_resource_put_safe' - > 'different lock contexts for basic block' by releasing the lock on each > iteration of the for loop. > That changelog doesn't sound correct at all. That's not a correct motivation or explanation. I reviewed the patch and it's likely going to cause dead locks. The code is trying to take the spinlock for the first pointer in the array and release it at the end. Now it takes the first pointer's spinlock a bunch of times (dead lock) and releases it once (will not happen because we are already dead). regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3 v3] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
The checkpatch.pl script reports several errors and warnings at file ieee80211_crypt_wep.c, this series of patches fixes them. Pedro Marzo Perez (3): ieee80211_crypt_wep: Simplify error check code at prism2_wep_init ieee80211_crypt_wep: Remove two useless lines at ieee80211_wep_null ieee80211_crypt_wep: Correct include indentation and openning braces at new line .../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 33 -- 1 file changed, 12 insertions(+), 21 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3 v3] Staging: rtl8192u: Remove two useless lines at ieee80211_wep_null
Removed two lines at ieee80211_wep_null which checkpatch.pl reported as errors.
The first one because it has a C99 comment style and the second one because it
is a void
return which is useless.
Signed-off-by: Pedro Marzo Perez
---
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 388ed3c..2ce7b54 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -289,6 +289,4 @@ void __exit ieee80211_crypto_wep_exit(void)
void ieee80211_wep_null(void)
{
-// printk(">%s()\n", __func__);
- return;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3 v3] Staging: rtl8192u: Correct include indentation and openning braces at new line
Opening braces should never be in a new line.
Correct include indentation.
Signed-off-by: Pedro Marzo Perez
---
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 2ce7b54..4be468c 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -21,7 +21,7 @@
#include "ieee80211.h"
#include
-#include
+#include
#include
MODULE_AUTHOR("Jouni Malinen");
@@ -138,9 +138,7 @@ static int prism2_wep_encrypt(struct sk_buff *skb, int
hdr_len, void *priv)
/* Copy rest of the WEP key (the secret part) */
memcpy(key + 3, wep->key, wep->key_len);
- if (!tcb_desc->bHwSec)
- {
-
+ if (!tcb_desc->bHwSec) {
/* Append little-endian CRC32 and encrypt it to produce ICV */
crc = ~crc32_le(~0, pos, len);
icv = skb_put(skb, 4);
@@ -197,8 +195,7 @@ static int prism2_wep_decrypt(struct sk_buff *skb, int
hdr_len, void *priv)
/* Apply RC4 to data and compute CRC32 over decrypted data */
plen = skb->len - hdr_len - 8;
- if (!tcb_desc->bHwSec)
- {
+ if (!tcb_desc->bHwSec) {
crypto_blkcipher_setkey(wep->rx_tfm, key, klen);
sg_init_one(&sg, pos, plen+4);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3 v3] Staging: rtl8192u: Simplify error check code at prism2_wep_init
Merge two pr_debug lines with literal strings splitted across several lines
into one single line, simplifying prism2_wep_init error check code.
Signed-off-by: Pedro Marzo Perez
---
.../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 0a17f84..388ed3c 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -9,6 +9,8 @@
* more details.
*/
+#define pr_fmt(fmt) "ieee80211_crypt_wep: " fmt
+
#include
#include
#include
@@ -43,20 +45,16 @@ static void *prism2_wep_init(int keyidx)
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
- goto fail;
+ return NULL;
priv->key_idx = keyidx;
priv->tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->tx_tfm)) {
- pr_debug("ieee80211_crypt_wep: could not allocate "
- "crypto API arc4\n");
priv->tx_tfm = NULL;
goto fail;
}
priv->rx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->rx_tfm)) {
- pr_debug("ieee80211_crypt_wep: could not allocate "
- "crypto API arc4\n");
priv->rx_tfm = NULL;
goto fail;
}
@@ -67,14 +65,12 @@ static void *prism2_wep_init(int keyidx)
return priv;
fail:
- if (priv) {
- if (priv->tx_tfm)
- crypto_free_blkcipher(priv->tx_tfm);
- if (priv->rx_tfm)
- crypto_free_blkcipher(priv->rx_tfm);
- kfree(priv);
- }
-
+ pr_debug("could not allocate crypto API arc4\n");
+ if (priv->tx_tfm)
+ crypto_free_blkcipher(priv->tx_tfm);
+ if (priv->rx_tfm)
+ crypto_free_blkcipher(priv->rx_tfm);
+ kfree(priv);
return NULL;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/4] Staging: lustre: sparse static warning fix
On Mon, May 18, 2015 at 08:34:48PM +0200, Adrian Remonda wrote: > This patch clears the warning given by sparse that the function should be > static. > Done by moving the declaration of the structure 'nrs_conf_fifo' into the > header > 'ptlrpc_internal.h' > > modified: drivers/staging/lustre/lustre/ptlrpc/nrs.c > modified: drivers/staging/lustre/lustre/ptlrpc/ptlrpc_internal.h Don't include these lines in the changelog. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: rtl8192u: Fix coding style issues at ieee80211_crypt_wep.c
On Tue, 2015-05-19 at 00:06 +0300, Dan Carpenter wrote: > On Mon, May 18, 2015 at 11:56:08PM +0200, pmarzo wrote: > > On Mon, 2015-05-18 at 19:15 +0300, Dan Carpenter wrote: > > > On Mon, May 18, 2015 at 07:36:23PM +0200, Pedro Marzo Perez wrote: > > > > Merge two pr_debug lines with literal strings splitted across several > > > > lines > > > > into one single line, simplifying prism2_wep_init error check code. > > > > Openning braces should never be in a new line, move them to the end of > > > > the previous line. > > > > Removed two useless lines at ieee80211_wep_null. > > > > > > > > > > When Joe said "Some will say this is doing too many things in a single > > > patch." he meant Greg. Break this up into multiple patches. Especially > > > now that you've added even more stuff to it. > > > > > > regards, > > > dan carpenter > > > > Sorry Joe, English is not my mother tongue and I misunderstand your > > comment, I thought "Some will say this is doing too many things in a > > single patch" did meant "You are on the limit, but it is ok to send it > > in one patch" but I see it really means "please, rewrite this whole crap > > into several patches" :-) > > The line is a fuzzy line. You were maybe on the line, maybe but then > you crossed over. Indeed I did, but this was mainly Joe's fault for giving good ideas about how to refactor the code. Joe,next time be quiet please :-) > > > > > So I guess an v3 patch should be a chain of several patches, I think a > > sensible approach would be three patches > > 1/3 => rewrite of the error check code > > 2/3 => remove of the two useless lines at ieee80211_wep_null. > > 3/3 => move openning braces and correct the indentation of the > > #include > > > > What do you think about it? > > That sounds fine. Ok! > > regards, > dan carpenter regards, Pedro. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: Modify if, else if conditions to remove unnecessary equality checks. This change was detected with the help of coccinelle tool.
On Mon, May 18, 2015 at 04:00:00PM +, Dhere, Chaitanya (C.) wrote: > Signed-off-by: Chaitanya Dhere Your subject line is too long :( Put some information in the change log area here please, above the signed-off-by line. > Reply-To: Why is this here? Please fix up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: unisys: fix function declaration format in visorchipset.c
On 18-5-2015 12:45, Jes Sorensen wrote: > Wim de With writes: >> This is a patch that fixes the function declarations in >> visorbus/visorchipset.c by removing newlines after the function return >> type > > This patch doesn't fix things, it makes things worse! > > If you want to post patches to this, do it properly and check the output > first. > > NACK > > Jes But how is line breaking in function headers supposed to be done? The coding style documentation specifically state the following: "Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list." I really don't want to bother you with trivial patches, especially when they are incorrect, but I am trying to learn something, so I hope you will help me out. Wim ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] [930672e8693a] Task 10 of the Eudyptula Challenge
From: douglasbsf
Fixed Coding Style Problem in drivers/staging/wlan-ng/prism2fw.c
Signed-off-by: douglasbsf
---
drivers/staging/wlan-ng/prism2fw.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2fw.c
b/drivers/staging/wlan-ng/prism2fw.c
index 9408644..27ead4c 100644
--- a/drivers/staging/wlan-ng/prism2fw.c
+++ b/drivers/staging/wlan-ng/prism2fw.c
@@ -708,7 +708,9 @@ static int plugimage(struct imgchunk *fchunk, unsigned int
nfchunks,
continue;
}
- /* Validate plug address against chunk data and identify chunk
*/
+ /* Validate plug address against
+ * chunk data and identify chunk
+ */
for (c = 0; c < nfchunks; c++) {
cstart = fchunk[c].addr;
cend = fchunk[c].addr + fchunk[c].len;
@@ -923,7 +925,8 @@ static int read_fwfile(const struct ihex_binrec *record)
rcnt,
s3info[ns3info].len,
s3info[ns3info].type);
- if (((s3info[ns3info].len - 1) * sizeof(u16)) >
sizeof(s3info[ns3info].info)) {
+ if (((s3info[ns3info].len - 1) * sizeof(u16)) >
+ sizeof(s3info[ns3info].info)) {
pr_err("S3 inforec length too long -
aborting\n");
return 1;
}
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] [930672e8693a] Task 10 of the Eudyptula Challenge
On Tue, May 19, 2015 at 01:50:10AM -0300, Douglas Figueiredo wrote: > From: douglasbsf > > Fixed Coding Style Problem in drivers/staging/wlan-ng/prism2fw.c 1) mention which coding style problem you fixed in the commit message. 2) no need to mention the challenge in the subject, the subject can be something like [PATCH] staging: wlan-ng: fix long line 3) when you are sending a single patch, no need to mention 1/1 and what is that 930672e8693a? my guess its your commit id in your local git. No need to mention that also. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] [930672e8693a] Task 10 of the Eudyptula Challenge
thanks for yours hints. 930672e8693a is my ID on the challenge, I will take care about this things in the future. 2015-05-19 2:03 GMT-03:00 Sudip Mukherjee : > On Tue, May 19, 2015 at 01:50:10AM -0300, Douglas Figueiredo wrote: >> From: douglasbsf >> >> Fixed Coding Style Problem in drivers/staging/wlan-ng/prism2fw.c > > 1) mention which coding style problem you fixed in the commit message. > 2) no need to mention the challenge in the subject, the subject can be > something like [PATCH] staging: wlan-ng: fix long line > 3) when you are sending a single patch, no need to mention 1/1 > > and what is that 930672e8693a? my guess its your commit id in your local > git. No need to mention that also. > > regards > sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: replace printk with subsystem debug
On Mon, May 18, 2015 at 10:29:55PM +0200, Mateusz Kulikowski wrote:
> Hi,
>
> On 18.05.2015 13:27, Gujulan Elango, Hari Prasath (H.) wrote:
> > replace the printk with netdev subsystem debug infrastructure.
> >
> > Signed-off-by: Hari Prasath Gujulan Elango
> > ---
> > drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
> > b/drivers/staging/rtl8192e/rtllib_rx.c
> > index fe3e7e12..f6e3f83 100644
> > --- a/drivers/staging/rtl8192e/rtllib_rx.c
> > +++ b/drivers/staging/rtl8192e/rtllib_rx.c
> > @@ -344,7 +344,7 @@ rtllib_rx_frame_decrypt_msdu(struct rtllib_device
> > *ieee, struct sk_buff *skb,
> > res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv);
> > atomic_dec(&crypt->refcnt);
> > if (res < 0) {
> > - printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed
> > (SA= %pM keyidx=%d)\n",
> > + netdev_dbg(ieee->dev, "%s: MSDU decryption/MIC verification
> > failed (SA= %pM keyidx=%d)\n",
> >ieee->dev->name, hdr->addr2, keyidx);
> > return -1;
> > }
> >
> I posted it already in one of my patches (v2, v3 - now I'm working on v4 with
> this change as well):
> https://lkml.org/lkml/2015/5/9/200 <- v3
> https://lkml.org/lkml/2015/4/13 <- v2
>
> Regards,
> Mateusz
Ok i checked the git log to see if this change has already gone in.I
found a comment stating that printk with KERN_DEBUG shall be left as it
is.So i sent a patch for this.Ok lets drop this duplicate patch then :)
Regards,
Hari Prasath
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3 v3] Staging: rtl8192u: Simplify error check code at prism2_wep_init
On Tue, May 19, 2015 at 01:32:22AM +0200, Pedro Marzo Perez wrote: > Merge two pr_debug lines with literal strings splitted across several lines > into one single line, simplifying prism2_wep_init error check code. I would have split this patch into three. 1) introduce pr_fmt and remove "ieee80211_crypt_wep" from pr_debug 2) return NULL instead of that goto fail. 3) combine two pr_debug into a single at the fail block. But Dan can say if its ok. (I am still taking ideas from Dan about my patches) regards sudip > > Signed-off-by: Pedro Marzo Perez ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] Driver for Arduino-as-I2C-adapter
Dear Bernhard Kraft, 2015-05-18 18:53 GMT+02:00 Bernhard Kraft : > Hi, > > On 2015-05-18 15:00, Alex Beregszaszi wrote: > >> There are many cheap I2C adapter projects (mostly USB though). One of >> the simple ones (i2c-tiny-usb) is included in the kernel [...] > > > I knew of the OpenSource project i2c-tiny-usb. But sadly the hardware ist > not sold anywhere (At least I didn't find vendors). > > >> As regarding to cheap serial line based adapters, there are two I have >> seen before [...] > > > None of them seems to have kernel drivers available. So I could stick to my > own homebrewn Arduino solution. > > >> I am afraid handling serial devices within a i2c kernel driver might be >> tricky and purists probably dislike the idea. > > > Currently there is at least one driver for such a case already in the > kernel: drivers/i2c/busses/i2c-taos-evm.c > > I found it by "grep serio.h" in i2c/busses/. But this driver rather only > supports SMBus which is kind of subset of I2C. Or you could call it I2C with > more strict requirements upon timing and protocol. > > In fact this would have been the driver I would have based my work on if > someone said: Go on, this is a good thing to include in the kernel. Personally, I find the idea very interesting, Arduino is so common that using it a usb/i2c bridge could benefit really a lot of people. Actually I'm think also to spi! > But for now I think I will just publish the Arduino sketch and a sample > implementation on how to access I2C devices with it. Probably we should stick to other protocol driver implementation, but from a rapid analisys, this will be the second in kernel serial to i2c adapter, so I think there is not such a string standard protocol in this field. Please publish your sketch, I think making the driver is really not a complex matter! Count on me for any help, I really like the idea to have my name on such an interesting project! Sincerely, Angelo > > greetings, > Bernhard > -- > Wer nicht gelegentlich auch einmal kausalwidrige Dinge zu denken vermag, > wird seine Wissenschaft nie um eine neue Idee bereichern können. > Max Planck (1858-1947) > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- Profile: http://it.linkedin.com/in/compagnucciangelo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: comedi: fix line longer than 80 chars in cb_pcidas64.c
On Mon, May 18, 2015 at 08:51:29PM +0200, Amaury Denoyelle wrote: > > Sudip Mukherjee wrote: > > > > > On Sun, May 17, 2015 at 04:47:23PM +0200, Amaury Denoyelle wrote: > Thanks for your review. I was aware of the coding style for multi-line > comments, but I chose to follow the same convention already used in the > source file. > > I submit a new version where I respect the coding style in the comments I > fixed. I editted only multi-line comments that were too long, in order to not > have a messy patch. If you think it's better to be done, maybe I could submit > a two-part patch. please send that way. And while replying please linewrap your reply to 72 char. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
