Re: [PATCH v4 4/5] staging/android: refactor SYNC_IOC_FILE_INFO
On Fri, Feb 26, 2016 at 03:31:46PM -0300, Gustavo Padovan wrote:
> +no_fences:
> + info->num_fences = sync_file->num_fences;
>
> - if (copy_to_user((void __user *)arg, info, len))
> + if (copy_to_user((void __user *)arg, info, sizeof(*info)))
> ret = -EFAULT;
> else
> ret = 0;
We need to kfree(fence_info) here.
> diff --git a/drivers/staging/android/uapi/sync.h
> b/drivers/staging/android/uapi/sync.h
> index f0b41ce..9aad623 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -42,21 +42,20 @@ struct sync_fence_info {
>
> /**
> * struct sync_file_info - data returned from fence info ioctl
> - * @len: ioctl caller writes the size of the buffer its passing in.
> - * ioctl returns length of sync_file_info returned to
> - * userspace including pt_info.
> * @name:name of fence
> * @status: status of fence. 1: signaled 0:active <0:error
> * @num_fences number of fences in the sync_file
> + * @len: ioctl caller writes the size of the buffer its passing in.
> + * ioctl returns length of all fence_infos summed.
> * @sync_fence_info: array of sync_fence_info for every fence in the
> sync_file
The documentation needs updating.
> */
> struct sync_file_info {
> - __u32 len;
> charname[32];
> __s32 status;
> __u32 num_fences;
> + __u32 len;
>
> - __u8sync_fence_info[0];
> + __u64 sync_fence_info;
> };
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/5] staging/android: add num_fences field to struct sync_file_info
This breaks userspace. You used to be able to figure it out from info->len - sizeof(struct sync_file_info). regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: slicoss: change memory allocation style in slicoss.c
You can't send two patches with the same subject. Just combine them into one patch anyway. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: add ethtool support for set and get of settings
From: Ben Hutchings Date: Mon, 29 Feb 2016 22:34:38 + > On Mon, 2016-02-29 at 17:09 -0500, David Miller wrote: >> From: Simon Xiao >> Date: Thu, 25 Feb 2016 15:24:08 -0800 >> >> > This patch allows the user to set and retrieve speed and duplex of the >> > hv_netvsc device via ethtool. >> > >> > Example: >> > $ ethtool eth0 >> > Settings for eth0: >> > ... >> > Speed: Unknown! >> > Duplex: Unknown! (255) >> > ... >> > $ ethtool -s eth0 speed 1000 duplex full >> > $ ethtool eth0 >> > Settings for eth0: >> > ... >> > Speed: 1000Mb/s >> > Duplex: Full >> > ... >> > >> > This is based on patches by Roopa Prabhu and Nikolay Aleksandrov. >> > >> > Signed-off-by: Simon Xiao >> >> Applied, thanks. > > I missed this due to flu, but now I look at it - I don't see the point. > Link speed isn't meaingful for a memory-based transport, so "unknown" > is correct. The link is effectively full duplex though. > > If the issue is that ethtool is a bit shouty about unknowns, let's > consider changing that in ethtool, not teaching drivers to lie. The issue is that certain bonding modes do not work properly without a speed being reported by a device. We're doing this for other "virtual" devices already thanks to changes that went in last week, so there is precedence. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: add ethtool support for set and get of settings
On Mon, 2016-02-29 at 17:09 -0500, David Miller wrote: > From: Simon Xiao > Date: Thu, 25 Feb 2016 15:24:08 -0800 > > > This patch allows the user to set and retrieve speed and duplex of the > > hv_netvsc device via ethtool. > > > > Example: > > $ ethtool eth0 > > Settings for eth0: > > ... > > Speed: Unknown! > > Duplex: Unknown! (255) > > ... > > $ ethtool -s eth0 speed 1000 duplex full > > $ ethtool eth0 > > Settings for eth0: > > ... > > Speed: 1000Mb/s > > Duplex: Full > > ... > > > > This is based on patches by Roopa Prabhu and Nikolay Aleksandrov. > > > > Signed-off-by: Simon Xiao > > Applied, thanks. I missed this due to flu, but now I look at it - I don't see the point. Link speed isn't meaingful for a memory-based transport, so "unknown" is correct. The link is effectively full duplex though. If the issue is that ethtool is a bit shouty about unknowns, let's consider changing that in ethtool, not teaching drivers to lie. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: add ethtool support for set and get of settings
From: Simon Xiao Date: Thu, 25 Feb 2016 15:24:08 -0800 > This patch allows the user to set and retrieve speed and duplex of the > hv_netvsc device via ethtool. > > Example: > $ ethtool eth0 > Settings for eth0: > ... > Speed: Unknown! > Duplex: Unknown! (255) > ... > $ ethtool -s eth0 speed 1000 duplex full > $ ethtool eth0 > Settings for eth0: > ... > Speed: 1000Mb/s > Duplex: Full > ... > > This is based on patches by Roopa Prabhu and Nikolay Aleksandrov. > > Signed-off-by: Simon Xiao Applied, thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Hi Maarten,
2016-02-29 Maarten Lankhorst :
> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> > optimize buffer allocation. In the new approach the ioctl needs to be called
> > twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
> >
> > The first call should pass num_fences = 0, the kernel will then fill
> > info->num_fences. Userspace receives back the number of fences and
> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> > info->sync_fence_info.
> >
> > It then call the ioctl again passing num_fences received in
> > info->num_fences.
> > The kernel checks if info->num_fences > 0 and if yes it fill
> > info->sync_fence_info with an array containing all fence_infos.
> >
> > info->len now represents the length of the buffer sync_fence_info points
> > to. Also, info->sync_fence_info was converted to __u64 pointer.
> >
> > An example userspace code would be:
> >
> > struct sync_file_info *info;
> > int err, size, num_fences;
> >
> > info = malloc(sizeof(*info));
> >
> > memset(info, 0, sizeof(*info));
> >
> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > num_fences = info->num_fences;
> >
> > if (num_fences) {
> > memset(info, 0, sizeof(*info));
> Would this memset still be needed if we didn't check for nulls in
> info->status and info->name ?
>
> Seems to me that it could be skipped in that case.
Yes, I agree.
> > size = sizeof(struct sync_fence_info) * num_fences;
> > info->len = size;
> > info->num_fences = num_fences;
> > info->sync_fence_info = (uint64_t) calloc(num_fences,
> > sizeof(struct
> > sync_fence_info));
> >
> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > }
> >
> > v2: fix fence_info memory leak
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/staging/android/sync.c | 52
> > +
> > drivers/staging/android/uapi/sync.h | 9 +++
> > 2 files changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> > index dc5f382..2379f23 100644
> > --- a/drivers/staging/android/sync.c
> > +++ b/drivers/staging/android/sync.c
> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence,
> > void *data, int size)
> > static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> > unsigned long arg)
> > {
> > - struct sync_file_info *info;
> > + struct sync_file_info in, *info;
> > + struct sync_fence_info *fence_info = NULL;
> > __u32 size;
> > __u32 len = 0;
> = 0 unneeded.
> > int ret, i;
> >
> > - if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> > + if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> > return -EFAULT;
> >
> > - if (size < sizeof(struct sync_file_info))
> > - return -EINVAL;
> > + if (in.status || strcmp(in.name, "\0"))
> > + return -EFAULT;
> These members always get written by the fence ioctl, I'm not sure it adds
> value to have them explicitly zero'd out by userspace.
> > - if (size > 4096)
> > - size = 4096;
> > + if (in.num_fences && !in.sync_fence_info)
> > + return -EFAULT;
> This check is unneeded, it will happen in the copy_to_user call anyway.
> > - info = kzalloc(size, GFP_KERNEL);
> > + info = kzalloc(sizeof(*info), GFP_KERNEL);
> > if (!info)
> > return -ENOMEM;
> >
> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct
> > sync_file *sync_file,
> > if (info->status >= 0)
> > info->status = !info->status;
> >
> > - info->num_fences = sync_file->num_fences;
> > + /*
> > +* Passing num_fences = 0 means that userspace want to know how
> > +* many fences are in the sync_file to be able to allocate a buffer to
> > +* fit all sync_fence_infos and call the ioctl again with the buffer
> > +* assigned to info->sync_fence_info. The second call pass the
> > +* num_fences value received in the first call.
> > +*/
> > + if (!in.num_fences)
> > + goto no_fences;
> > +
> > + size = sync_file->num_fences * sizeof(*fence_info);
> > + if (in.len != size) {
> > + ret = -EFAULT;
> > + goto out;
> > + }
> Maybe check for in.len < size, and set set to size?
>
>
> > - len = sizeof(struct sync_file_info);
> > + fence_info = kzalloc(size, GFP_KERNEL);
> > + if (!fence_info) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> >
> > for (i = 0; i < sync_file->num_fences; ++i) {
> > struct fence *fence = sync_file->cbs[i].fence;
> >
> > - ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> > +
Re: [patch] PCI: hv: potential use after free
You're right. My bad. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INFORMAÇÃO IMPORTANTE RE: Consultoria de Investimento em sua Localidade.
Oi Amigo, INFORMAÇÃO IMPORTANTE Nossa família está interessada em investir fundos em sua localidade. Mais informações para você se interessou. Saudações, Sir Henry Neville Lindley Keswick Presidente da Jardine Matheson Holdings Ltd https://en.wikipedia.org/wiki/Keswick_family ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: unisys: Update MAINTAINERS file
Benjamin Romer is no longer an s-Par maintainer. Changes from v1: - Fixed spelling in comment of my name. - Obtained signoff from Benjamin Romer (currently at bro...@comcast.net) David Kershner (1): staging: unisys: Update MAINTAINERS file drivers/staging/unisys/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: unisys: Update MAINTAINERS file
Benjamin Romer is no longer a maintainer for the s-Par drivers. David Kershner will now be the maintainer. Signed-off-by: David Kershner Signed-off-by: Benjamin Romer --- drivers/staging/unisys/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/unisys/MAINTAINERS b/drivers/staging/unisys/MAINTAINERS index c9cef0b..cc46e37 100644 --- a/drivers/staging/unisys/MAINTAINERS +++ b/drivers/staging/unisys/MAINTAINERS @@ -1,5 +1,5 @@ Unisys s-Par drivers -M: Ben Romer +M: David Kershner S: Maintained F: Documentation/s-Par/overview.txt F: Documentation/s-Par/proc-entries.txt -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [patch] PCI: hv: potential use after free
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Saturday, February 27, 2016 2:44 AM
> To: KY Srinivasan ; Jake Oshins
>
> Cc: Haiyang Zhang ; Bjorn Helgaas
> ; de...@linuxdriverproject.org; linux-
> p...@vger.kernel.org; linux-ker...@vger.kernel.org; kernel-
> janit...@vger.kernel.org
> Subject: [patch] PCI: hv: potential use after free
>
> If we throw away the very last item on the list, then we could end up
> with a use after free of "dr".
>
> Fixes: 15ca17645f19 ('PCI: hv: Add paravirtual PCI front-end for Microsoft
> Hyper-V VMs')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 9391dee..9b66ffe 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1397,6 +1397,7 @@ static void pci_devices_present_work(struct
> work_struct *work)
> /* Throw this away if the list still has stuff in it. */
> if (!list_empty(&hbus->dr_list)) {
> kfree(dr);
> + dr = NULL;
> continue;
> }
> }
Thanks for looking at this. I do truly appreciate it. But the code here
removes dr from the list and then, before freeing it, checks to see that it was
not the last entry in the list. The list lock is still held and the list is
not empty even after removing dr from it.
(I suspect that you're going to tell me that I'm missing something here.
Please do. I'll appreciate it even more.)
Thanks,
Jake
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: FW: [PATCH] staging: unisys: Update MAINTAINERS file
On Mon, 2016-02-29 at 17:02 +, Kershner, David A wrote: > > On Mon, Feb 29, 2016 at 10:24:06AM -0500, David Kershner wrote: > > > Benjamin Romer is no longer a mainta.iner for the s-Par drivers. David > > > Kershenr will now be the maintainer > > > Signed-off-by: David Kershner > > > --- > > > drivers/staging/unisys/MAINTAINERS | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Can I get a signed-off-by from Ben to validate this? > > Signed-off-by: Benjamin Romer Hopefully my personal address is okay, I've submitted patches with it in th e past. -- Ben ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INFORMAÇÃO IMPORTANTE RE: Consultoria de Investimento em sua Localidade.
Oi Amigo, INFORMAÇÃO IMPORTANTE Nossa família está interessada em investir fundos em sua localidade. Mais informações para você se interessou. Saudações, Sir Henry Neville Lindley Keswick Presidente da Jardine Matheson Holdings Ltd https://en.wikipedia.org/wiki/Keswick_family ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INFORMAÇÃO IMPORTANTE RE: Consultoria de Investimento em sua Localidade.
Oi Amigo, INFORMAÇÃO IMPORTANTE Nossa família está interessada em investir fundos em sua localidade. Mais informações para você se interessou. Saudações, Sir Henry Neville Lindley Keswick Presidente da Jardine Matheson Holdings Ltd https://en.wikipedia.org/wiki/Keswick_family ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: Update MAINTAINERS file
Benjamin Romer is no longer a maintainer for the s-Par drivers. David Kershenr will now be the maintainer. Signed-off-by: David Kershner --- drivers/staging/unisys/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/unisys/MAINTAINERS b/drivers/staging/unisys/MAINTAINERS index c9cef0b..cc46e37 100644 --- a/drivers/staging/unisys/MAINTAINERS +++ b/drivers/staging/unisys/MAINTAINERS @@ -1,5 +1,5 @@ Unisys s-Par drivers -M: Ben Romer +M: David Kershner S: Maintained F: Documentation/s-Par/overview.txt F: Documentation/s-Par/proc-entries.txt -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: nvec: Fixed 12 code style checks and changed udelay() to usleep_range() on 2 lines
Hi,
Sure thanks for pointing that out. I’ll send in a small patch for the problems
in the following order.
1) Null Comparison
2) License declaration
Hopefully maybe you guys can tell me what else is needed. Thanks for being so
supportive!
Regards,
Parth Sane
> On 29-Feb-2016, at 5:00 PM, Marc Dietrich wrote:
>
> Hi Parth,
>
> please also cc de...@linuxdriverproject.org next time.
>
> Some comments below.
>
> Am Freitag, 26. Februar 2016, 15:24:21 CET schrieb Parth Sane:
>> 1)Null comparison
>> 2)Extra Line after curly braces
>> 3)Changed udelay to udelay_range
>> 4)BUG_ON to WARN_ON to avoid crashing kernel
>> 5)Removed copyright notice as recommended by checkpatch script
>>
>> Signed-off-by: Parth Sane
>> ---
>> drivers/staging/nvec/nvec-keytable.h | 13 -
>> drivers/staging/nvec/nvec.c | 18 +-
>> drivers/staging/nvec/nvec_paz00.c| 1 -
>> 3 files changed, 9 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/nvec/nvec-keytable.h
>> b/drivers/staging/nvec/nvec-keytable.h index 1dc22cb..9f369d5 100644
>> --- a/drivers/staging/nvec/nvec-keytable.h
>> +++ b/drivers/staging/nvec/nvec-keytable.h
>> @@ -6,19 +6,6 @@
>> *
>> * Copyright (c) 2009, NVIDIA Corporation.
>> *
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License as published by
>> - * the Free Software Foundation; either version 2 of the License, or
>> - * (at your option) any later version.
>> - *
>> - * This program is distributed in the hope that it will be useful, but
>> WITHOUT - * ANY WARRANTY; without even the implied warranty of
>> MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> General Public License for - * more details.
>> - *
>> - * You should have received a copy of the GNU General Public License along
>> - * with this program; if not, write to the Free Software Foundation, Inc.,
>> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>> */
>>
>> static unsigned short code_tab_102us[] = {
>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>> index c335ae2..03dbc09 100644
>> --- a/drivers/staging/nvec/nvec.c
>> +++ b/drivers/staging/nvec/nvec.c
>> @@ -1,4 +1,4 @@
>> -/*
>> +2/*
>
> stray "2"
>
>> * NVEC: NVIDIA compliant embedded controller interface
>> *
>> * Copyright (C) 2011 The AC100 Kernel Team
>> @@ -264,7 +264,7 @@ int nvec_write_async(struct nvec_chip *nvec, const
>> unsigned char *data,
>>
>> msg = nvec_msg_alloc(nvec, NVEC_MSG_TX);
>>
>> -if (msg == NULL)
>> +if (!msg)
>> return -ENOMEM;
>>
>> msg->data[0] = size;
>> @@ -620,7 +620,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> } else {I had sent a patch for the staging nvec driver. It had
>> some
> checkpatch
>
>> nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
>> /* Should not happen in a normal world */
>> -if (unlikely(nvec->rx == NULL)) {
>> +if (unlikely(!nvec->rx)) {
>> nvec->state = 0;
>> break;
>> }
>> @@ -631,7 +631,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> break;
>> case 2: /* first byte after command */
>> if (status == (I2C_SL_IRQ | RNW | RCVD)) {
>> -udelay(33);
>> +usleep_range(32, 33);
>> if (nvec->rx->data[0] != 0x01) {
>> dev_err(nvec->dev,
>> "Read without prior read command\n");
>> @@ -641,11 +641,11 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> nvec_msg_free(nvec, nvec->rx);
>> nvec->state = 3;
>> nvec_tx_set(nvec);
>> -BUG_ON(nvec->tx->size < 1);
>> +WARN_ON(nvec->tx->size < 1);
>> to_send = nvec->tx->data[0];
>> nvec->tx->pos = 1;
>> } else if (status == (I2C_SL_IRQ)) {
>> -BUG_ON(nvec->rx == NULL);
>> +WARN_ON(!nvec->rx);
>> nvec->rx->data[1] = received;
>> nvec->rx->pos = 2;
>> nvec->state = 4;
>
>
> Laura Garcia Liebana sent a a fix for this a few days ago.
> So please remove this hunk.
>
>> @@ -663,8 +663,8 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> } else {
>> dev_err(nvec->dev, "tx buffer underflow on %p (%u >
>> %u)\n",
>> nvec->tx,
>> -(uint) (nvec->tx ? nvec->tx->pos : 0),
>> -(uint) (nvec->tx ? nvec->tx->size : 0));
>> +(uint)(nvec->tx ? nvec->tx->pos : 0),
>> +(uint)
Re: [PATCH] staging: nvec: Fixed 12 code style checks and changed udelay() to usleep_range() on 2 lines
Hi,
Am Montag, 29. Februar 2016, 17:21:14 CET schrieb Parth Sane:
> Hi,
> As per the previous email, I understand that some patches were
> unnecessary(For example the fix for the spaces ).
not sure what you mean here. I was referring to the BUG_ON removal not the
space changes.
It's common (or better a rule) on linux mailing lists to add comments below
the concerning block. Top-posts (putting comments or replies on top of
concerning block) are disliked.
See: http://kernelnewbies.org/mailinglistguidelines
> But it was a bit
> confusing. Can someone please let me know which patches are needed and
> which are not?
you should not send patches which others already did.
Marc
> > On 29-Feb-2016, at 5:00 PM, Marc Dietrich wrote:
> >
> > Hi Parth,
> >
> > please also cc de...@linuxdriverproject.org next time.
> >
> > Some comments below.
> >
> > Am Freitag, 26. Februar 2016, 15:24:21 CET schrieb Parth Sane:
> >> 1)Null comparison
> >> 2)Extra Line after curly braces
> >> 3)Changed udelay to udelay_range
> >> 4)BUG_ON to WARN_ON to avoid crashing kernel
> >> 5)Removed copyright notice as recommended by checkpatch script
> >>
> >> Signed-off-by: Parth Sane
> >> ---
> >> drivers/staging/nvec/nvec-keytable.h | 13 -
> >> drivers/staging/nvec/nvec.c | 18 +-
> >> drivers/staging/nvec/nvec_paz00.c| 1 -
> >> 3 files changed, 9 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/staging/nvec/nvec-keytable.h
> >> b/drivers/staging/nvec/nvec-keytable.h index 1dc22cb..9f369d5 100644
> >> --- a/drivers/staging/nvec/nvec-keytable.h
> >> +++ b/drivers/staging/nvec/nvec-keytable.h
> >> @@ -6,19 +6,6 @@
> >>
> >> *
> >> * Copyright (c) 2009, NVIDIA Corporation.
> >> *
> >>
> >> - * This program is free software; you can redistribute it and/or modify
> >> - * it under the terms of the GNU General Public License as published by
> >> - * the Free Software Foundation; either version 2 of the License, or
> >> - * (at your option) any later version.
> >> - *
> >> - * This program is distributed in the hope that it will be useful, but
> >> WITHOUT - * ANY WARRANTY; without even the implied warranty of
> >> MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >> General Public License for - * more details.
> >> - *
> >> - * You should have received a copy of the GNU General Public License
> >> along
> >> - * with this program; if not, write to the Free Software Foundation,
> >> Inc.,
> >> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> >>
> >> */
> >>
> >> static unsigned short code_tab_102us[] = {
> >> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> >> index c335ae2..03dbc09 100644
> >> --- a/drivers/staging/nvec/nvec.c
> >> +++ b/drivers/staging/nvec/nvec.c
> >> @@ -1,4 +1,4 @@
> >> -/*
> >> +2/*
> >
> > stray "2"
> >
> >> * NVEC: NVIDIA compliant embedded controller interface
> >> *
> >> * Copyright (C) 2011 The AC100 Kernel Team
> >>
> >> @@ -264,7 +264,7 @@ int nvec_write_async(struct nvec_chip *nvec, const
> >> unsigned char *data,
> >>
> >>msg = nvec_msg_alloc(nvec, NVEC_MSG_TX);
> >>
> >> - if (msg == NULL)
> >> + if (!msg)
> >>
> >>return -ENOMEM;
> >>
> >>msg->data[0] = size;
> >>
> >> @@ -620,7 +620,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> >>
> >>} else {I had sent a patch for the staging nvec driver. It had
> >> some
> >
> > checkpatch
> >
> >>nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
> >>/* Should not happen in a normal world */
> >>
> >> - if (unlikely(nvec->rx == NULL)) {
> >> + if (unlikely(!nvec->rx)) {
> >>
> >>nvec->state = 0;
> >>break;
> >>
> >>}
> >>
> >> @@ -631,7 +631,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> >>
> >>break;
> >>
> >>case 2: /* first byte after command */
> >>
> >>if (status == (I2C_SL_IRQ | RNW | RCVD)) {
> >>
> >> - udelay(33);
> >> + usleep_range(32, 33);
> >>
> >>if (nvec->rx->data[0] != 0x01) {
> >>
> >>dev_err(nvec->dev,
> >>
> >>"Read without prior read command\n");
> >>
> >> @@ -641,11 +641,11 @@ static irqreturn_t nvec_interrupt(int irq, void
> >> *dev)
> >>
> >>nvec_msg_free(nvec, nvec->rx);
> >>nvec->state = 3;
> >>nvec_tx_set(nvec);
> >>
> >> - BUG_ON(nvec->tx->size < 1);
> >> + WARN_ON(nvec->tx->size < 1);
> >>
> >>to_send = nvec->tx->data[0];
> >>nvec->tx->pos = 1;
> >>
> >>} else if (status == (I2C_SL_IRQ)) {
> >>
INFORMAÇÃO IMPORTANTE RE: Consultoria de Investimento em sua Localidade.
Oi, Temos planejado investir alguns fundos no seu país. Responder se você estiver interessado. Saudações, Sir Henry Neville Lindley Keswick Presidente da Jardine Matheson Holdings Ltd https://en.wikipedia.org/wiki/Keswick_family == Hi friend, Our family is interested in investing funds in your locality. More information for you interest . Greetings, Sir Henry Neville Lindley Keswick Chairman of Jardine Matheson Holdings Ltd https://en.wikipedia.org/wiki/Keswick_family ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lowmemorykiller: fix 2 checks that checkpatch complained
From: Sandeep Jain
Specifically:
lowmemorykiller.c:53: CHECK: use a blank line after enum declarations
lowmemorykiller.c:60: CHECK: use a blank line after enum declarations
Signed-off-by: Sandeep Jain
---
drivers/staging/android/lowmemorykiller.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 4b8a56c..2509e5d 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -50,6 +50,7 @@ static short lowmem_adj[6] = {
6,
12,
};
+
static int lowmem_adj_size = 4;
static int lowmem_minfree[6] = {
3 * 512,/* 6MB */
@@ -57,6 +58,7 @@ static int lowmem_minfree[6] = {
4 * 1024, /* 16MB */
16 * 1024, /* 64MB */
};
+
static int lowmem_minfree_size = 4;
static unsigned long lowmem_deathpending_timeout;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: nvec: Fixed 12 code style checks and changed udelay() to usleep_range() on 2 lines
Hi,
As per the previous email, I understand that some patches were unnecessary(For
example the fix for the spaces ). But it was a bit confusing. Can someone
please let me know which patches are needed and which are not?
Regards,
Parth Sane
> On 29-Feb-2016, at 5:00 PM, Marc Dietrich wrote:
>
> Hi Parth,
>
> please also cc de...@linuxdriverproject.org next time.
>
> Some comments below.
>
> Am Freitag, 26. Februar 2016, 15:24:21 CET schrieb Parth Sane:
>> 1)Null comparison
>> 2)Extra Line after curly braces
>> 3)Changed udelay to udelay_range
>> 4)BUG_ON to WARN_ON to avoid crashing kernel
>> 5)Removed copyright notice as recommended by checkpatch script
>>
>> Signed-off-by: Parth Sane
>> ---
>> drivers/staging/nvec/nvec-keytable.h | 13 -
>> drivers/staging/nvec/nvec.c | 18 +-
>> drivers/staging/nvec/nvec_paz00.c| 1 -
>> 3 files changed, 9 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/nvec/nvec-keytable.h
>> b/drivers/staging/nvec/nvec-keytable.h index 1dc22cb..9f369d5 100644
>> --- a/drivers/staging/nvec/nvec-keytable.h
>> +++ b/drivers/staging/nvec/nvec-keytable.h
>> @@ -6,19 +6,6 @@
>> *
>> * Copyright (c) 2009, NVIDIA Corporation.
>> *
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License as published by
>> - * the Free Software Foundation; either version 2 of the License, or
>> - * (at your option) any later version.
>> - *
>> - * This program is distributed in the hope that it will be useful, but
>> WITHOUT - * ANY WARRANTY; without even the implied warranty of
>> MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> General Public License for - * more details.
>> - *
>> - * You should have received a copy of the GNU General Public License along
>> - * with this program; if not, write to the Free Software Foundation, Inc.,
>> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>> */
>>
>> static unsigned short code_tab_102us[] = {
>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>> index c335ae2..03dbc09 100644
>> --- a/drivers/staging/nvec/nvec.c
>> +++ b/drivers/staging/nvec/nvec.c
>> @@ -1,4 +1,4 @@
>> -/*
>> +2/*
>
> stray "2"
>
>> * NVEC: NVIDIA compliant embedded controller interface
>> *
>> * Copyright (C) 2011 The AC100 Kernel Team
>> @@ -264,7 +264,7 @@ int nvec_write_async(struct nvec_chip *nvec, const
>> unsigned char *data,
>>
>> msg = nvec_msg_alloc(nvec, NVEC_MSG_TX);
>>
>> -if (msg == NULL)
>> +if (!msg)
>> return -ENOMEM;
>>
>> msg->data[0] = size;
>> @@ -620,7 +620,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> } else {I had sent a patch for the staging nvec driver. It had
>> some
> checkpatch
>
>> nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
>> /* Should not happen in a normal world */
>> -if (unlikely(nvec->rx == NULL)) {
>> +if (unlikely(!nvec->rx)) {
>> nvec->state = 0;
>> break;
>> }
>> @@ -631,7 +631,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> break;
>> case 2: /* first byte after command */
>> if (status == (I2C_SL_IRQ | RNW | RCVD)) {
>> -udelay(33);
>> +usleep_range(32, 33);
>> if (nvec->rx->data[0] != 0x01) {
>> dev_err(nvec->dev,
>> "Read without prior read command\n");
>> @@ -641,11 +641,11 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> nvec_msg_free(nvec, nvec->rx);
>> nvec->state = 3;
>> nvec_tx_set(nvec);
>> -BUG_ON(nvec->tx->size < 1);
>> +WARN_ON(nvec->tx->size < 1);
>> to_send = nvec->tx->data[0];
>> nvec->tx->pos = 1;
>> } else if (status == (I2C_SL_IRQ)) {
>> -BUG_ON(nvec->rx == NULL);
>> +WARN_ON(!nvec->rx);
>> nvec->rx->data[1] = received;
>> nvec->rx->pos = 2;
>> nvec->state = 4;
>
>
> Laura Garcia Liebana sent a a fix for this a few days ago.
> So please remove this hunk.
>
>> @@ -663,8 +663,8 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> } else {
>> dev_err(nvec->dev, "tx buffer underflow on %p (%u >
>> %u)\n",
>> nvec->tx,
>> -(uint) (nvec->tx ? nvec->tx->pos : 0),
>> -(uint) (nvec->tx ? nvec->tx->size : 0));
>> +(uint)(nvec->tx ? nvec->tx->pos : 0),
>> +(uint)(nvec->tx ? nvec->t
[PATCH] Staging: slicoss: changes memory allocation style in slicoss.c
This is a patch to slicoss.c that changes the memory allocation style as identified by checkpatch.pl Signed-off-by: Ben Marsh --- drivers/staging/slicoss/slicoss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index 30aa45a..275ac63 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -1806,7 +1806,7 @@ static int slic_mcast_add_list(struct adapter *adapter, char *address) } /* Doesn't already exist. Allocate a structure to hold it */ - mcaddr = kmalloc(sizeof(struct mcast_address), GFP_ATOMIC); + mcaddr = kmalloc(sizeof(*mcaddr), GFP_ATOMIC); if (mcaddr == NULL) return 1; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: slicoss: memory allocation style change in slicoss.c
This is a patch to slicoss.c to change the memory allocation style as
identified by checkpatch.pl
Signed-off-by: Ben Marsh
---
drivers/staging/slicoss/slicoss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index d5c259e..30aa45a 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3049,7 +3049,7 @@ static u32 slic_card_locate(struct adapter *adapter)
}
if (!physcard) {
/* no structure allocated for this physical card yet */
- physcard = kzalloc(sizeof(struct physcard), GFP_ATOMIC);
+ physcard = kzalloc(sizeof(*physcard), GFP_ATOMIC);
if (!physcard) {
if (card_hostid == SLIC_HOSTID_DEFAULT)
kfree(card);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: nvec: Fixed 12 code style checks and changed udelay() to usleep_range() on 2 lines
Hi Parth,
please also cc de...@linuxdriverproject.org next time.
Some comments below.
Am Freitag, 26. Februar 2016, 15:24:21 CET schrieb Parth Sane:
> 1)Null comparison
> 2)Extra Line after curly braces
> 3)Changed udelay to udelay_range
> 4)BUG_ON to WARN_ON to avoid crashing kernel
> 5)Removed copyright notice as recommended by checkpatch script
>
> Signed-off-by: Parth Sane
> ---
> drivers/staging/nvec/nvec-keytable.h | 13 -
> drivers/staging/nvec/nvec.c | 18 +-
> drivers/staging/nvec/nvec_paz00.c| 1 -
> 3 files changed, 9 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/staging/nvec/nvec-keytable.h
> b/drivers/staging/nvec/nvec-keytable.h index 1dc22cb..9f369d5 100644
> --- a/drivers/staging/nvec/nvec-keytable.h
> +++ b/drivers/staging/nvec/nvec-keytable.h
> @@ -6,19 +6,6 @@
> *
> * Copyright (c) 2009, NVIDIA Corporation.
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful, but
> WITHOUT - * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> General Public License for - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along
> - * with this program; if not, write to the Free Software Foundation, Inc.,
> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> */
>
> static unsigned short code_tab_102us[] = {
> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> index c335ae2..03dbc09 100644
> --- a/drivers/staging/nvec/nvec.c
> +++ b/drivers/staging/nvec/nvec.c
> @@ -1,4 +1,4 @@
> -/*
> +2/*
stray "2"
> * NVEC: NVIDIA compliant embedded controller interface
> *
> * Copyright (C) 2011 The AC100 Kernel Team
> @@ -264,7 +264,7 @@ int nvec_write_async(struct nvec_chip *nvec, const
> unsigned char *data,
>
> msg = nvec_msg_alloc(nvec, NVEC_MSG_TX);
>
> - if (msg == NULL)
> + if (!msg)
> return -ENOMEM;
>
> msg->data[0] = size;
> @@ -620,7 +620,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> } else {I had sent a patch for the staging nvec driver. It had
> some
checkpatch
> nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
> /* Should not happen in a normal world */
> - if (unlikely(nvec->rx == NULL)) {
> + if (unlikely(!nvec->rx)) {
> nvec->state = 0;
> break;
> }
> @@ -631,7 +631,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> break;
> case 2: /* first byte after command */
> if (status == (I2C_SL_IRQ | RNW | RCVD)) {
> - udelay(33);
> + usleep_range(32, 33);
> if (nvec->rx->data[0] != 0x01) {
> dev_err(nvec->dev,
> "Read without prior read command\n");
> @@ -641,11 +641,11 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> nvec_msg_free(nvec, nvec->rx);
> nvec->state = 3;
> nvec_tx_set(nvec);
> - BUG_ON(nvec->tx->size < 1);
> + WARN_ON(nvec->tx->size < 1);
> to_send = nvec->tx->data[0];
> nvec->tx->pos = 1;
> } else if (status == (I2C_SL_IRQ)) {
> - BUG_ON(nvec->rx == NULL);
> + WARN_ON(!nvec->rx);
> nvec->rx->data[1] = received;
> nvec->rx->pos = 2;
> nvec->state = 4;
Laura Garcia Liebana sent a a fix for this a few days ago.
So please remove this hunk.
> @@ -663,8 +663,8 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> } else {
> dev_err(nvec->dev, "tx buffer underflow on %p (%u >
> %u)\n",
> nvec->tx,
> - (uint) (nvec->tx ? nvec->tx->pos : 0),
> - (uint) (nvec->tx ? nvec->tx->size : 0));
> + (uint)(nvec->tx ? nvec->tx->pos : 0),
> + (uint)(nvec->tx ? nvec->tx->size : 0));
> nvec->state = 0;
> }
> break;
> @@ -719,7 +719,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>* We experience less incomplete messages with this delay than without
>* it, but we don't know why. Help is appreciated.
>*/
> - udelay(100);
> + usleep_range(99, 100);
[PATCH] Staging: slicoss: change memory allocation style in slicoss.c
This is a patch to slicoss.c to change the memory allocation style as
identified by checkpatch.pl
Signed-off-by: Ben Marsh
---
drivers/staging/slicoss/slicoss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 69edd0d..d5c259e 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2998,7 +2998,7 @@ static u32 slic_card_locate(struct adapter *adapter)
/* Initialize a new card structure if need be */
if (card_hostid == SLIC_HOSTID_DEFAULT) {
- card = kzalloc(sizeof(struct sliccard), GFP_KERNEL);
+ card = kzalloc(sizeof(*card), GFP_KERNEL);
if (card == NULL)
return -ENOMEM;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: slicoss: change memory allocation style in slicoss.c
This is a patch to slicoss.c to change the memory allocation style in slicoss.c as found by checkpatch.pl Signed-off-by: Ben Marsh --- drivers/staging/slicoss/slicoss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index a91c60a..69edd0d 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -880,7 +880,7 @@ static int slic_upr_queue_request(struct adapter *adapter, struct slic_upr *upr; struct slic_upr *uprqueue; - upr = kmalloc(sizeof(struct slic_upr), GFP_ATOMIC); + upr = kmalloc(sizeof(*upr), GFP_ATOMIC); if (!upr) return -ENOMEM; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: rtllib_softmac.c: Remove multiple blank lines
On Sunday 28 February 2016 08:18 PM, Tapan Prakash T wrote:
> Fixed blank lines issues reported by checkpatch.pl
Hi,
I can see that you have sent 3 patches for the same file. But they are
sent as separate patches. So, this might be confusing for the maintainer.
So, in this case these are some points you need to keep in mind:
1. You can send a single patch for the same warnings/errors in the same
file or directory covering all occurrences.
2. If you want to send patches for different errors in a single file then you
need to send a patch in the form of a patchset.
I think this should help you with understanding my point in a better way:
https://www.kernel.org/doc/Documentation/SubmittingPatches
> Signed-off-by: Tapan Prakash T
> ---
> drivers/staging/rtl8192e/rtllib_softmac.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
> b/drivers/staging/rtl8192e/rtllib_softmac.c
> index 25b5b5e..b40298b 100644
> --- a/drivers/staging/rtl8192e/rtllib_softmac.c
> +++ b/drivers/staging/rtl8192e/rtllib_softmac.c
> @@ -13,7 +13,6 @@
> * released under the GPL
> */
>
> -
> #include "rtllib.h"
>
> #include
> @@ -25,7 +24,6 @@
>
> static void rtllib_sta_wakeup(struct rtllib_device *ieee, short nl);
>
> -
> static short rtllib_is_54g(struct rtllib_network *net)
> {
> return (net->rates_ex_len > 0) || (net->rates_len > 4);
--
Vaishali
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 39/52] mtd: nand: jz4780: switch to mtd_ooblayout_ops
Hi Boris,
On 26/02/16 00:57, Boris Brezillon wrote:
Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/jz4780_nand.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/nand/jz4780_nand.c b/drivers/mtd/nand/jz4780_nand.c
index e1c016c..b86a579 100644
--- a/drivers/mtd/nand/jz4780_nand.c
+++ b/drivers/mtd/nand/jz4780_nand.c
@@ -56,8 +56,6 @@ struct jz4780_nand_chip {
struct nand_chip chip;
struct list_head chip_list;
- struct nand_ecclayout ecclayout;
-
struct gpio_desc *busy_gpio;
struct gpio_desc *wp_gpio;
unsigned int reading: 1;
@@ -165,8 +163,7 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip
*nand, struct device *de
struct nand_chip *chip = &nand->chip;
struct mtd_info *mtd = nand_to_mtd(chip);
struct jz4780_nand_controller *nfc =
to_jz4780_nand_controller(chip->controller);
- struct nand_ecclayout *layout = &nand->ecclayout;
- u32 start, i;
+ int eccbytes;
chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
(chip->ecc.strength / 8);
@@ -201,23 +198,17 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip
*nand, struct device *de
return 0;
/* Generate ECC layout. ECC codes are right aligned in the OOB area. */
- layout->eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
+ eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
- if (layout->eccbytes > mtd->oobsize - 2) {
+ if (eccbytes > mtd->oobsize - 2) {
dev_err(dev,
"invalid ECC config: required %d ECC bytes, but only %d are
available",
- layout->eccbytes, mtd->oobsize - 2);
+ eccbytes, mtd->oobsize - 2);
return -EINVAL;
}
- start = mtd->oobsize - layout->eccbytes;
- for (i = 0; i < layout->eccbytes; i++)
- layout->eccpos[i] = start + i;
-
- layout->oobfree[0].offset = 2;
- layout->oobfree[0].length = mtd->oobsize - layout->eccbytes - 2;
+ mtd->ooblayout = &nand_ooblayout_lp_ops;
- chip->ecc.layout = layout;
return 0;
}
With your patch applied [0] that you gave me earlier in the patchset, I
am able to boot to userland on my Ci20 (jz4780_{nand,bch}) with a NAND
rootfs. So, dependant upon that patch (or equivalent) being added to
this patchset:
Tested-by: Harvey Hunt
Thanks,
Harvey
[0] http://code.bulix.org/36oytz-91960
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 07/52] mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
Hi Boris, On 26/02/16 18:33, Boris Brezillon wrote: Hi Harvey, On Fri, 26 Feb 2016 15:17:28 + Harvey Hunt wrote: Hi Boris, On 26/02/16 15:10, Boris Brezillon wrote: Hi Harvey, On Fri, 26 Feb 2016 14:35:08 + Harvey Hunt wrote: [...] I'll look into this more later today, but wanted to run it by you in case you have any thoughts. Can you apply this patch [1], and let me know if you see the additional trace? I applied the patch, the following is the (unchanged) output: [0.256375] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x88 [0.262887] nand: Micron MT29F64G08CBAAAWP [0.266995] nand: 8192 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 448 [0.274881] jz4780-nand 1b00.nand-controller: using hardware BCH (strength 24, size 1024, bytes 42) [0.289046] Bad block table not found for chip 0 [0.297769] Bad block table not found for chip 0 [0.302425] Scanning device for bad blocks [0.320239] Bad eraseblock 90 at 0x0b40 [0.324934] Bad eraseblock 91 at 0x0b60 [0.931054] Bad eraseblock 4092 at 0x0001ff80 [0.935917] Bad eraseblock 4093 at 0x0001ffa0 [0.944660] nand_bbt: error while writing bad block table -34 [0.950448] jz4780-nand: probe of 1b00.nand-controller failed with error -34 [0.958079] UBI error: cannot open mtd 3, error -19 [0.962788] UBI error: cannot open mtd 4, error -19[0.970229] clk: Not disabling unused clocks Can you test with this one [1]? [1]http://code.bulix.org/36oytz-91960 With that patch applied, my Ci20 successfully boots again. Thanks for looking into it :-) Harvey ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wilc1000: wilc_wlan_if.h: remove unused functions
This patch removes the unused functions anymore related to the configuration
of the bus interface clock speed.
Signed-off-by: Tony Cho
---
drivers/staging/wilc1000/wilc_wlan_if.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h
b/drivers/staging/wilc1000/wilc_wlan_if.h
index fbe34eb..f19ecb5 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -918,8 +918,6 @@ typedef enum {
struct wilc;
int wilc_wlan_init(struct net_device *dev);
-void wilc_bus_set_max_speed(void);
-void wilc_bus_set_default_speed(void);
u32 wilc_get_chipid(struct wilc *wilc, bool update);
#endif
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: util: fix a race with daemons startup
KY Srinivasan writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Thursday, February 18, 2016 5:35 AM
>> To: de...@linuxdriverproject.org
>> Cc: KY Srinivasan ; Haiyang Zhang
>> ; Olaf Hering ; Cathy Avery
>>
>> Subject: [PATCH] Drivers: hv: util: fix a race with daemons startup
>>
>> Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
>> interrupt context") removed direct *_transaction.state = HVUTIL_READY
>> assignments from *_handle_handshake() functions introducing the following
>> race: if a userspace daemon connects before we get first non-negotiation
>> request from the server hv_poll_channel() won't set transaction state to
>> HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
>> the first real request from the server. Solve the issue by transferring
>> the transaction state to HVUTIL_READY directly from all handshake
>> functions.
>>
>> Fixes: 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
>> interrupt context")
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/hv_fcopy.c| 1 +
>> drivers/hv/hv_kvp.c | 1 +
>> drivers/hv/hv_snapshot.c | 1 +
>> 3 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
>> index c37a71e..e18b85b 100644
>> --- a/drivers/hv/hv_fcopy.c
>> +++ b/drivers/hv/hv_fcopy.c
>> @@ -108,6 +108,7 @@ static int fcopy_handle_handshake(u32 version)
>> return -EINVAL;
>> }
>> pr_debug("FCP: userspace daemon ver. %d registered\n", version);
>> +fcopy_transaction.state = HVUTIL_READY;
>> hv_poll_channel(fcopy_transaction.recv_channel,
>> fcopy_poll_wrapper);
>> return 0;
>> }
>> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
>> index d4ab81b..1162afb 100644
>> --- a/drivers/hv/hv_kvp.c
>> +++ b/drivers/hv/hv_kvp.c
>> @@ -154,6 +154,7 @@ static int kvp_handle_handshake(struct hv_kvp_msg
>> *msg)
>> pr_debug("KVP: userspace daemon ver. %d registered\n",
>> KVP_OP_REGISTER);
>> kvp_register(dm_reg_value);
>> +kvp_transaction.state = HVUTIL_READY;
>> hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
>>
>> return 0;
>> diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
>> index 67def4a..489203b 100644
>> --- a/drivers/hv/hv_snapshot.c
>> +++ b/drivers/hv/hv_snapshot.c
>> @@ -113,6 +113,7 @@ static int vss_handle_handshake(struct hv_vss_msg
>> *vss_msg)
>> default:
>> return -EINVAL;
>> }
>> +vss_transaction.state = HVUTIL_READY;
>> hv_poll_channel(vss_transaction.recv_channel, vss_poll_wrapper);
>> pr_debug("VSS: userspace daemon ver. %d registered\n",
>> dm_reg_value);
>> return 0;
>
> Vitaly, there is a simpler and a safer fix to this issue - stash away the
> channel pointer early on and so we don't
> need to set it on each transaction. This would address the issue on
> hand here.
Yes, thanks, this is also an option.
> This would also eliminate
> setting the state only in the interrupt handler. I am putting together a
> batch of patches to send and if it is
> ok with you, I will drop this patch and include a patch on the lines
> described above.
>
Thanks!
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Hi Gustavo,
On 27 February 2016 at 15:25, Gustavo Padovan
wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov :
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 21:00, Gustavo Padovan wrote:
>> > From: Gustavo Padovan
>> >
>> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
>> > optimize buffer allocation. In the new approach the ioctl needs to be
>> > called
>> > twice to retrieve the array of fence_infos pointed by
>> > info->sync_fence_info.
>> >
>> I might have misunderstood things but I no one says you "need" to call
>> it twice - you can just request a "random" amount of fences_info. Upon
>> return (if num_fences was non zero) it will report how many fence_info
>> were retrieved.
>
> Right, I don't see any problem doing it in one request, I just didn't
> think about that in the new proposal. I'll update the code and commit
> message accordinly.
>
>>
>> > The first call should pass num_fences = 0, the kernel will then fill
>> > info->num_fences. Userspace receives back the number of fences and
>> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
>> > info->sync_fence_info.
>> >
>> > It then call the ioctl again passing num_fences received in
>> > info->num_fences.
>> "calls"
>>
>> > The kernel checks if info->num_fences > 0 and if yes it fill
>> > info->sync_fence_info with an array containing all fence_infos.
>> >
>> The above sentence sounds a bit strange. I believe you meant to say
>> something like "Then the kernel fills the fence_infos array with data.
>> One should read back the actual number from info->num_fences." ?
>>
>> > info->len now represents the length of the buffer sync_fence_info points
>> > to.
>> Now that I think about it, I'm wondering if there'll be a case where
>> len != info->num_fences * sizeof(struct sync_file_info). If that's not
>> possible one could just drop len and nicely simplify things.
>>
>> > Also, info->sync_fence_info was converted to __u64 pointer.
>> >
>> ... pointer to prevent 32bit compatibility issues.
>>
>> > An example userspace code would be:
>> >
>> > struct sync_file_info *info;
>> > int err, size, num_fences;
>> >
>> > info = malloc(sizeof(*info));
>> >
>> > memset(info, 0, sizeof(*info));
>> >
>> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> > num_fences = info->num_fences;
>> >
>> > if (num_fences) {
>> > memset(info, 0, sizeof(*info));
>> > size = sizeof(struct sync_fence_info) * num_fences;
>> > info->len = size;
>> > info->num_fences = num_fences;
>> > info->sync_fence_info = (uint64_t) calloc(num_fences,
>> > sizeof(struct
>> > sync_fence_info));
>> >
>> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> > }
>> >
>> > v2: fix fence_info memory leak
>> >
>> > Signed-off-by: Gustavo Padovan
>> > ---
>> > drivers/staging/android/sync.c | 52
>> > +
>> > drivers/staging/android/uapi/sync.h | 9 +++
>> > 2 files changed, 45 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/staging/android/sync.c
>> > b/drivers/staging/android/sync.c
>> > index dc5f382..2379f23 100644
>> > --- a/drivers/staging/android/sync.c
>> > +++ b/drivers/staging/android/sync.c
>> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence,
>> > void *data, int size)
>> > static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>> > unsigned long arg)
>> > {
>> > - struct sync_file_info *info;
>> > + struct sync_file_info in, *info;
>> > + struct sync_fence_info *fence_info = NULL;
>> > __u32 size;
>> > __u32 len = 0;
>> > int ret, i;
>> >
>> > - if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
>> > + if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
>> s/*info/in/
>>
>> > return -EFAULT;
>> >
>> > - if (size < sizeof(struct sync_file_info))
>> > - return -EINVAL;
>> > + if (in.status || strcmp(in.name, "\0"))
>> Afaict these two are outputs, so we should be checking them ?
>
> Hmm. Maybe not.
>
>>
>> > + return -EFAULT;
>> >
>> As originally, input validation should return -EINVAL on error.
>>
>>
>> > - if (size > 4096)
>> > - size = 4096;
>> > + if (in.num_fences && !in.sync_fence_info)
>> > + return -EFAULT;
>> >
>> Ditto.
>>
>> > - info = kzalloc(size, GFP_KERNEL);
>> > + info = kzalloc(sizeof(*info), GFP_KERNEL);
>> > if (!info)
>> > return -ENOMEM;
>> >
>> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct
>> > sync_file *sync_file,
>> > if (info->status >= 0)
>> > info->status = !info->status;
>> >
>> > - info->num_fences = sync_file->num_
Re: [PATCH v4 3/5] staging/android: remove redundant comments on sync_merge_data
Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/uapi/sync.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/uapi/sync.h
> b/drivers/staging/android/uapi/sync.h
> index dd0dd84..f0b41ce 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -21,9 +21,9 @@
> * @fence: returns the fd of the new fence to userspace
> */
> struct sync_merge_data {
> - __s32 fd2; /* fd of second fence */
> - charname[32]; /* name of new fence */
> - __s32 fence; /* fd on newly created fence */
> + __s32 fd2;
> + charname[32];
> + __s32 fence;
> };
>
> /**
For the first 3 patches:
Reviewed-by: Maarten Lankhorst
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 5/5] staging/android: add flags member to sync ioctl structs
Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/sync.c | 7 ++-
> drivers/staging/android/uapi/sync.h | 6 ++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 837cff5..54fd5ab 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
> *sync_file,
> goto err_put_fd;
> }
>
> + if (data.flags) {
> + err = -EFAULT;
> + goto err_put_fd;
> + }
-EINVAL
> fence2 = sync_file_fdget(data.fd2);
> if (!fence2) {
> err = -ENOENT;
> @@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file
> *sync_file,
> if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> return -EFAULT;
>
> - if (in.status || strcmp(in.name, "\0"))
> + if (in.status || in.flags || strcmp(in.name, "\0"))
> return -EFAULT;
-EINVAL
> if (in.num_fences && !in.sync_fence_info)
> diff --git a/drivers/staging/android/uapi/sync.h
> b/drivers/staging/android/uapi/sync.h
> index 9aad623..f56a6c2 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -19,11 +19,13 @@
> * @fd2: file descriptor of second fence
> * @name:name of new fence
> * @fence: returns the fd of the new fence to userspace
> + * @flags: merge_data flags
> */
> struct sync_merge_data {
> __s32 fd2;
> charname[32];
> __s32 fence;
> + __u32 flags;
> };
>
> /**
> @@ -31,12 +33,14 @@ struct sync_merge_data {
> * @obj_name:name of parent sync_timeline
> * @driver_name: name of driver implementing the parent
> * @status: status of the fence 0:active 1:signaled <0:error
> + * @flags: fence_info flags
> * @timestamp_ns:timestamp of status change in nanoseconds
> */
> struct sync_fence_info {
> charobj_name[32];
> chardriver_name[32];
> __s32 status;
> + __u32 flags;
> __u64 timestamp_ns;
> };
>
> @@ -44,6 +48,7 @@ struct sync_fence_info {
> * struct sync_file_info - data returned from fence info ioctl
> * @name:name of fence
> * @status: status of fence. 1: signaled 0:active <0:error
> + * @flags: sync_file_info flags
> * @num_fences number of fences in the sync_file
> * @len: ioctl caller writes the size of the buffer its passing in.
> * ioctl returns length of all fence_infos summed.
> @@ -52,6 +57,7 @@ struct sync_fence_info {
> struct sync_file_info {
> charname[32];
> __s32 status;
> + __u32 flags;
> __u32 num_fences;
> __u32 len;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>
> The first call should pass num_fences = 0, the kernel will then fill
> info->num_fences. Userspace receives back the number of fences and
> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> info->sync_fence_info.
>
> It then call the ioctl again passing num_fences received in info->num_fences.
> The kernel checks if info->num_fences > 0 and if yes it fill
> info->sync_fence_info with an array containing all fence_infos.
>
> info->len now represents the length of the buffer sync_fence_info points
> to. Also, info->sync_fence_info was converted to __u64 pointer.
>
> An example userspace code would be:
>
> struct sync_file_info *info;
> int err, size, num_fences;
>
> info = malloc(sizeof(*info));
>
> memset(info, 0, sizeof(*info));
>
> err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> num_fences = info->num_fences;
>
> if (num_fences) {
> memset(info, 0, sizeof(*info));
Would this memset still be needed if we didn't check for nulls in info->status
and info->name ?
Seems to me that it could be skipped in that case.
> size = sizeof(struct sync_fence_info) * num_fences;
> info->len = size;
> info->num_fences = num_fences;
> info->sync_fence_info = (uint64_t) calloc(num_fences,
> sizeof(struct
> sync_fence_info));
>
> err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> }
>
> v2: fix fence_info memory leak
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/sync.c | 52
> +
> drivers/staging/android/uapi/sync.h | 9 +++
> 2 files changed, 45 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..2379f23 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence,
> void *data, int size)
> static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> unsigned long arg)
> {
> - struct sync_file_info *info;
> + struct sync_file_info in, *info;
> + struct sync_fence_info *fence_info = NULL;
> __u32 size;
> __u32 len = 0;
= 0 unneeded.
> int ret, i;
>
> - if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> + if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> return -EFAULT;
>
> - if (size < sizeof(struct sync_file_info))
> - return -EINVAL;
> + if (in.status || strcmp(in.name, "\0"))
> + return -EFAULT;
These members always get written by the fence ioctl, I'm not sure it adds value
to have them explicitly zero'd out by userspace.
> - if (size > 4096)
> - size = 4096;
> + if (in.num_fences && !in.sync_fence_info)
> + return -EFAULT;
This check is unneeded, it will happen in the copy_to_user call anyway.
> - info = kzalloc(size, GFP_KERNEL);
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info)
> return -ENOMEM;
>
> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file
> *sync_file,
> if (info->status >= 0)
> info->status = !info->status;
>
> - info->num_fences = sync_file->num_fences;
> + /*
> + * Passing num_fences = 0 means that userspace want to know how
> + * many fences are in the sync_file to be able to allocate a buffer to
> + * fit all sync_fence_infos and call the ioctl again with the buffer
> + * assigned to info->sync_fence_info. The second call pass the
> + * num_fences value received in the first call.
> + */
> + if (!in.num_fences)
> + goto no_fences;
> +
> + size = sync_file->num_fences * sizeof(*fence_info);
> + if (in.len != size) {
> + ret = -EFAULT;
> + goto out;
> + }
Maybe check for in.len < size, and set set to size?
> - len = sizeof(struct sync_file_info);
> + fence_info = kzalloc(size, GFP_KERNEL);
> + if (!fence_info) {
> + ret = -ENOMEM;
> + goto out;
> + }
>
> for (i = 0; i < sync_file->num_fences; ++i) {
> struct fence *fence = sync_file->cbs[i].fence;
>
> - ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> + ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> +size - len);
>
> if (ret < 0)
> goto out;
> @@ -540,14
