[PATCH 1/3] staging: ccree: Replace kzalloc with devm_kzalloc
From: Suniel Mahesh
It is recommended to use managed function devm_kzalloc, which
simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace kzalloc with devm_kzalloc.
(b) drop kfree(), because memory allocated with devm_kzalloc() is
automatically freed on driver detach, otherwise it leads to a double
free.
(c) remove unnecessary blank lines.
Signed-off-by: Suniel Mahesh
---
Note:
- Patch was tested and built(ARCH=arm) on next-20170714.
No build issues reported, however it was not tested on
real hardware.
---
drivers/staging/ccree/ssi_driver.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index 78709b92..f231ecf 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -224,13 +224,15 @@ static int init_cc_resources(struct platform_device
*plat_dev)
struct resource *req_mem_cc_regs = NULL;
void __iomem *cc_base = NULL;
bool irq_registered = false;
- struct ssi_drvdata *new_drvdata = kzalloc(sizeof(struct ssi_drvdata),
GFP_KERNEL);
+ struct ssi_drvdata *new_drvdata;
struct device *dev = &plat_dev->dev;
struct device_node *np = dev->of_node;
u32 signature_val;
int rc = 0;
- if (unlikely(!new_drvdata)) {
+ new_drvdata = devm_kzalloc(&plat_dev->dev, sizeof(struct ssi_drvdata),
+ GFP_KERNEL);
+ if (!new_drvdata) {
SSI_LOG_ERR("Failed to allocate drvdata");
rc = -ENOMEM;
goto init_cc_res_err;
@@ -431,10 +433,8 @@ static int init_cc_resources(struct platform_device
*plat_dev)
resource_size(new_drvdata->res_mem));
new_drvdata->res_mem = NULL;
}
- kfree(new_drvdata);
dev_set_drvdata(&plat_dev->dev, NULL);
}
-
return rc;
}
@@ -475,8 +475,6 @@ static void cleanup_cc_resources(struct platform_device
*plat_dev)
drvdata->cc_base = NULL;
drvdata->res_mem = NULL;
}
-
- kfree(drvdata);
dev_set_drvdata(&plat_dev->dev, NULL);
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] staging: ccree: Employ devm_* functions, remove redundant code
From: Suniel Mahesh Hi This patch series replaces the current API's which request for device resources in driver probe, with devm_*() functions of the kernel framework as recommended by the kernel community. Doing so simplifies driver cleanup paths and code organization. The current set of API's whch request for device resources are not device managed. The devm_*() functions of the kernel framework are kernel managed resources which the kernel tracks and then automatically releases them when the device goes away. Patch 1/3, replaces kzalloc with devm_kzalloc, kfree's and blank lines are removed accordingly. Patch 2/3, utilizes devm_ioremap_resource for map and unmap of device resources. request_mem_region(), ioremap() and corresponding error handling is replaced with devm_ioremap_resource(). release_mem_region() and iounmap() are dropped. A struct member in struct ssi_drvdata is dropped as it seemed redundant. Log messages adjusted accordingly. Patch 3/3, replaces platform_get_resource(), request_irq() and corresponding error handling with platform_get_irq() and devm_request_irq(). free_irq is not required any more, devm_request_irq() free's it on driver detach. A struct member in struct ssi_drvdata and a bool variable in driver probe are dropped as they seemed redundant. Changed type of a member in struct ssi_drvdata to use it with platform_get_irq(). Log messages adjusted accordingly. Note: Patch was tested and built(ARCH=arm) on next-20170714. No build issues reported, however it was not tested on real hardware. Please drop any patch if they break the flow. As per my analysis these changes should not create a problem. Thanks, Suniel Suniel Mahesh (3): staging: ccree: Replace kzalloc with devm_kzalloc staging: ccree: Convert to devm_ioremap_resource for map, unmap staging: ccree: Use platform_get_irq and devm_request_irq drivers/staging/ccree/ssi_driver.c | 92 +++--- drivers/staging/ccree/ssi_driver.h | 4 +- 2 files changed, 26 insertions(+), 70 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: ccree: Convert to devm_ioremap_resource for map, unmap
From: Suniel Mahesh
It is recommended to use managed function devm_ioremap_resource(),
which simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace request_mem_region(), ioremap() and corresponding error
handling with devm_ioremap_resource().
(b) remove struct resource pointer(res_mem) in struct ssi_drvdata as it
seems redundant, use struct resource pointer which is defined locally and
adjust return value of platform_get_resource() accordingly.
(c) release_mem_region() and iounmap() are dropped, since devm_ioremap_
resource() releases and unmaps mem region on driver detach.
(d) adjust log messages accordingly and remove any blank lines.
Signed-off-by: Suniel Mahesh
---
Note:
- Patch was tested and built(ARCH=arm) on next-20170714.
No build issues reported, however it was not tested on
real hardware.
---
drivers/staging/ccree/ssi_driver.c | 59 ++
drivers/staging/ccree/ssi_driver.h | 1 -
2 files changed, 15 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index f231ecf..dca0ce8 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -247,34 +247,21 @@ static int init_cc_resources(struct platform_device
*plat_dev)
dev_set_drvdata(&plat_dev->dev, new_drvdata);
/* Get device resources */
/* First CC registers space */
- new_drvdata->res_mem = platform_get_resource(plat_dev, IORESOURCE_MEM,
0);
- if (unlikely(!new_drvdata->res_mem)) {
- SSI_LOG_ERR("Failed getting IO memory resource\n");
- rc = -ENODEV;
- goto init_cc_res_err;
- }
- SSI_LOG_DEBUG("Got MEM resource (%s): start=0x%llX end=0x%llX\n",
- new_drvdata->res_mem->name,
- (unsigned long long)new_drvdata->res_mem->start,
- (unsigned long long)new_drvdata->res_mem->end);
+ req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
/* Map registers space */
- req_mem_cc_regs = request_mem_region(new_drvdata->res_mem->start,
resource_size(new_drvdata->res_mem), "arm_cc7x_regs");
- if (unlikely(!req_mem_cc_regs)) {
- SSI_LOG_ERR("Couldn't allocate registers memory region at "
-"0x%08X\n", (unsigned
int)new_drvdata->res_mem->start);
- rc = -EBUSY;
- goto init_cc_res_err;
- }
- cc_base = ioremap(new_drvdata->res_mem->start,
resource_size(new_drvdata->res_mem));
- if (unlikely(!cc_base)) {
- SSI_LOG_ERR("ioremap[CC](0x%08X,0x%08X) failed\n",
- (unsigned int)new_drvdata->res_mem->start, (unsigned
int)resource_size(new_drvdata->res_mem));
- rc = -ENOMEM;
+ new_drvdata->cc_base = devm_ioremap_resource(&plat_dev->dev,
+req_mem_cc_regs);
+ if (IS_ERR(new_drvdata->cc_base)) {
+ rc = PTR_ERR(new_drvdata->cc_base);
goto init_cc_res_err;
}
- SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n",
&new_drvdata->res_mem->start, cc_base);
- new_drvdata->cc_base = cc_base;
-
+ SSI_LOG_DEBUG("Got MEM resource (%s): start=0x%llX end=0x%llX\n",
+ req_mem_cc_regs->name,
+ (unsigned long long)req_mem_cc_regs->start,
+ (unsigned long long)req_mem_cc_regs->end);
+ SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n",
+ &req_mem_cc_regs->start, new_drvdata->cc_base);
+ cc_base = new_drvdata->cc_base;
/* Then IRQ */
new_drvdata->res_irq = platform_get_resource(plat_dev, IORESOURCE_IRQ,
0);
if (unlikely(!new_drvdata->res_irq)) {
@@ -421,17 +408,9 @@ static int init_cc_resources(struct platform_device
*plat_dev)
#ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
#endif
-
- if (req_mem_cc_regs) {
- if (irq_registered) {
- free_irq(new_drvdata->res_irq->start,
new_drvdata);
- new_drvdata->res_irq = NULL;
- iounmap(cc_base);
- new_drvdata->cc_base = NULL;
- }
- release_mem_region(new_drvdata->res_mem->start,
- resource_size(new_drvdata->res_mem));
- new_drvdata->res_mem = NULL;
+ if (irq_registered) {
+ free_irq(new_drvdata->res_irq->start, new_drvdata);
+ new_drvdata->res_irq = NULL;
}
dev_set_drvdata(&plat_dev->dev, NULL);
}
@@ -467,14 +446,6 @@ static void cleanup_cc_resources(struct platform_device
*plat_dev)
cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
dr
[PATCH 3/3] staging: ccree: Use platform_get_irq and devm_request_irq
From: Suniel Mahesh
It is recommended to use managed function devm_request_irq(),
which simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace platform_get_resource(), request_irq() and corresponding
error handling with platform_get_irq() and devm_request_irq().
(b) remove struct resource pointer(res_irq) in struct ssi_drvdata as
it seems redundant.
(c) change type of member irq in struct ssi_drvdata from unsigned int
to int, as return type of platform_get_irq is int and can be used in
error handling.
(d) remove irq_registered variable from driver probe as it seems
redundant.
(e) free_irq is not required any more, devm_request_irq() free's it
on driver detach.
(f) adjust log messages accordingly and remove any blank lines.
Signed-off-by: Suniel Mahesh
---
Note:
- Patch was tested and built(ARCH=arm) on next-20170714.
No build issues reported, however it was not tested on
real hardware.
---
drivers/staging/ccree/ssi_driver.c | 29 +
drivers/staging/ccree/ssi_driver.h | 3 +--
2 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index dca0ce8..11b62d0 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -223,7 +223,6 @@ static int init_cc_resources(struct platform_device
*plat_dev)
{
struct resource *req_mem_cc_regs = NULL;
void __iomem *cc_base = NULL;
- bool irq_registered = false;
struct ssi_drvdata *new_drvdata;
struct device *dev = &plat_dev->dev;
struct device_node *np = dev->of_node;
@@ -263,25 +262,22 @@ static int init_cc_resources(struct platform_device
*plat_dev)
&req_mem_cc_regs->start, new_drvdata->cc_base);
cc_base = new_drvdata->cc_base;
/* Then IRQ */
- new_drvdata->res_irq = platform_get_resource(plat_dev, IORESOURCE_IRQ,
0);
- if (unlikely(!new_drvdata->res_irq)) {
+ new_drvdata->irq = platform_get_irq(plat_dev, 0);
+ if (new_drvdata->irq < 0) {
SSI_LOG_ERR("Failed getting IRQ resource\n");
- rc = -ENODEV;
+ rc = new_drvdata->irq;
goto init_cc_res_err;
}
- rc = request_irq(new_drvdata->res_irq->start, cc_isr,
-IRQF_SHARED, "arm_cc7x", new_drvdata);
- if (unlikely(rc != 0)) {
- SSI_LOG_ERR("Could not register to interrupt %llu\n",
- (unsigned long long)new_drvdata->res_irq->start);
+ rc = devm_request_irq(&plat_dev->dev, new_drvdata->irq, cc_isr,
+ IRQF_SHARED, "arm_cc7x", new_drvdata);
+ if (rc) {
+ SSI_LOG_ERR("Could not register to interrupt: %d\n",
+ new_drvdata->irq);
goto init_cc_res_err;
}
init_completion(&new_drvdata->icache_setup_completion);
- irq_registered = true;
- SSI_LOG_DEBUG("Registered to IRQ (%s) %llu\n",
- new_drvdata->res_irq->name,
- (unsigned long long)new_drvdata->res_irq->start);
+ SSI_LOG_DEBUG("Registered to IRQ: %d\n", new_drvdata->irq);
new_drvdata->plat_dev = plat_dev;
@@ -408,10 +404,6 @@ static int init_cc_resources(struct platform_device
*plat_dev)
#ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
#endif
- if (irq_registered) {
- free_irq(new_drvdata->res_irq->start, new_drvdata);
- new_drvdata->res_irq = NULL;
- }
dev_set_drvdata(&plat_dev->dev, NULL);
}
return rc;
@@ -441,11 +433,8 @@ static void cleanup_cc_resources(struct platform_device
*plat_dev)
#ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
#endif
-
fini_cc_regs(drvdata);
cc_clk_off(drvdata);
- free_irq(drvdata->res_irq->start, drvdata);
- drvdata->res_irq = NULL;
dev_set_drvdata(&plat_dev->dev, NULL);
}
diff --git a/drivers/staging/ccree/ssi_driver.h
b/drivers/staging/ccree/ssi_driver.h
index 4b38fe2..6fcd151 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -129,9 +129,8 @@ struct ssi_crypto_req {
* @fw_ver:SeP loaded firmware version
*/
struct ssi_drvdata {
- struct resource *res_irq;
void __iomem *cc_base;
- unsigned int irq;
+ int irq;
u32 irq_mask;
u32 fw_ver;
/* Calibration time of start/stop
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Sat, Jul 15, 2017 at 01:15:43PM +0200, Marcus Wolf wrote: > Hi Greg, > > thanks for your reply :-) > > Today I moved the documentation and header files to drivers/staging/pi433 and > fromated it as a single patch. > > Cheers, > > Marcus I still need it in a format I can apply it in (i.e. proper subject, changelog text, signed-off-by, etc.) Can you do that? Also, for staging drivers, I need a TODO file, much like the existing drivers/staging/*/TODO files saying what needs to be done with the code in order to get it out of staging. And finally, your patch seemed to have the whitespace corrupted and was line-wrapped, making it impossible to apply even if I could have :( thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/14] staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
On Fri, 14 Jul 2017 11:31:03 +0200
Arnd Bergmann wrote:
> gcc-7 points out an older regression:
>
> drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
> drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean
> context, did you mean '<' ? [-Werror=int-in-bool-context]
>
> The original code had 'unsigned short' here, but incorrectly got
> converted to 'bool'. This reverts the regression and uses a normal
> type instead.
>
> Fixes: 29148543c521 ("staging:iio:resolver:ad2s1210 minimal chan spec
> conversion.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
Thanks Arnd,
Applied to the fixes-togreg branch of iio.git.
Jonathan
> ---
> drivers/staging/iio/resolver/ad2s1210.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> b/drivers/staging/iio/resolver/ad2s1210.c
> index a6a8393d6664..3e00df74b18c 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -472,7 +472,7 @@ static int ad2s1210_read_raw(struct iio_dev *indio_dev,
>long m)
> {
> struct ad2s1210_state *st = iio_priv(indio_dev);
> - bool negative;
> + u16 negative;
> int ret = 0;
> u16 pos;
> s16 vel;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
Hi! It's me again. Seems like I also need help on sending the email :-/ I checked the whitespace/line wrap problem, but couldn't find any suspicious lines. What I did: * Looked into my outbox - the copy of my mail to you seems to be okay... * I sent the patch once again (just to me) - result: Seems to be fine, too. Maybe you can bounce back my mail? Maybe I'll get an idea what went wrong, if I see the smashed code... Cheers, Marcus > Greg KH hat am 15. Juli 2017 um 13:24 > geschrieben: > > > On Sat, Jul 15, 2017 at 01:15:43PM +0200, Marcus Wolf wrote: > > Hi Greg, > > > > thanks for your reply :-) > > > > Today I moved the documentation and header files to drivers/staging/pi433 > > and > > fromated it as a single patch. > > > > Cheers, > > > > Marcus > > I still need it in a format I can apply it in (i.e. proper subject, > changelog text, signed-off-by, etc.) Can you do that? > > Also, for staging drivers, I need a TODO file, much like the existing > drivers/staging/*/TODO files saying what needs to be done with the code > in order to get it out of staging. > > And finally, your patch seemed to have the whitespace corrupted and was > line-wrapped, making it impossible to apply even if I could have :( > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Sat, Jul 15, 2017 at 02:59:25PM +0200, Marcus Wolf wrote: > Hi! > > It's me again. Seems like I also need help on sending the email :-/ > > I checked the whitespace/line wrap problem, but couldn't find any suspicious > lines. > > What I did: > * Looked into my outbox - the copy of my mail to you seems to be okay... > * I sent the patch once again (just to me) - result: Seems to be fine, too. > > Maybe you can bounce back my mail? Maybe I'll get an idea what went wrong, if > I > see the smashed code... You sent the patch in html format, which caused all of the whitespace corruption. html will not work for kernel patches for obvious reasons :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Sat, Jul 15, 2017 at 03:10:48PM +0200, Marcus Wolf wrote: > Hi! > > Ok. Thanks for the info. Didn't observe that. > I'll give the old patch another try. > > I will send a new patch as soon, as I know. how to produce the > poper format (with subjects, signing and so on). Documentation/SubmittingPatches should have all of the information you need for this type of thing. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Sat, Jul 15, 2017 at 03:40:30PM +0200, Marcus Wolf wrote: > Hi Greg, > > I absolutly agree. My patch should meet the needs of an official patch. Again, don't use html email :) > But I don't know about the exact needs. Can you please help me? What is needed > / missing in my patch and how do I produce it? > Maybe you can pass me a link, where I can read, what to do? The link I sent you, Documentation/SubmittingPatches in the kernel source tree, should contain everything you need to know. As a minimum you need a good subject, a good changelog body text, and a signed-off-by: line. The file should tell you all about how to create this. If you have specific questions after reading that about these things, please let us know. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] lustre: check copy_from_iter/copy_to_iter return code
On Fri, 14 Jul 2017, Al Viro wrote:
> On Thu, Jul 13, 2017 at 10:57:59PM +0200, Arnd Bergmann wrote:
>
> > Thanks for testing it!
> >
> > That means we did not copy any data and the kernel continues with
> > an uninitialized buffer, right? The problem may be the definition of
> >
> > struct kib_immediate_msg {
> > struct lnet_hdr ibim_hdr;/* portals header */
> > char ibim_payload[0]; /* piggy-backed payload */
> > } WIRE_ATTR;
> >
> > The check that Al added will try to ensure that we don't write
> > beyond the size of the ibim_payload[] array, which unfortunately
> > is defined as a zero-byte array, so I can see why it will now
> > fail. However, it's already broken in mainline now, with or without
> > my patch.
> >
> > Are you able to come up with a fix that avoids the warning in
> > 'allmodconfig' and makes the function do something reasonable
> > again?
Yes, I'm testing a fix right now which I will merge with the original
patch. Greg this patch will need to be sent to Linus as well so the
kernel release isn't broken for users.
> Might make sense to try and use valid C99 for "array of indefinite
> size as the last member", i.e.
> struct kib_immediate_msg {
> struct lnet_hdr ibim_hdr;/* portals header */
> char ibim_payload[]; /* piggy-backed payload */
> } WIRE_ATTR;
>
> Zero-sized array as the last member is gcc hack predating that;
> looks like gcc gets confused into deciding that it knows the distance
> from the end of object...
I did some profiling and found gcc was doing the right thing. That
should be updated to a C99 flexable array in a latter patch.
> Said that, are we really guaranteed the IBLND_MSG_SIZE bytes
> in there?
This is what the real bug was. In the current code we are telling
copy_from_iter and copy_to_iter that the number of bytes are always
IBLND_MSG_SIZE. Arnd thought this was always the size so in his
patch he was testing the returned result of copy_[from|to]_iter to
IBLND_MSG_SIZE. This nearly always failed since variable sized messages
are being created. The zero size I initially saw was from doing pings.
When I later tested with pushing I/O packets of other sizes were
observed but none of them were IBLND_MSG_SIZE in size so they failed to
transmit. As soon as I'm done testing I will send a patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: ko2iblnd: check copy_from_iter/copy_to_iter return code
From: Arnd Bergmann
We now get a helpful warning for code that calls copy_{from,to}_iter
without checking the return value, introduced by commit aa28de275a24
("iov_iter/hardening: move object size checks to inlined part").
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
'kiblnd_send':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1643:2: error: ignoring
return value of 'copy_from_iter', declared with attribute warn_unused_result
[-Werror=unused-result]
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
'kiblnd_recv':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1744:3: error: ignoring
return value of 'copy_to_iter', declared with attribute warn_unused_result
[-Werror=unused-result]
In case we get short copies here, we may get incorrect behavior.
I've added failure handling for both rx and tx now, returning
-EFAULT as expected.
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
Signed-off-by: James Simmons
---
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c| 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 85b242e..8fc191d 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1640,8 +1640,13 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
ibmsg = tx->tx_msg;
ibmsg->ibm_u.immediate.ibim_hdr = *hdr;
- copy_from_iter(&ibmsg->ibm_u.immediate.ibim_payload, IBLND_MSG_SIZE,
- &from);
+ rc = copy_from_iter(&ibmsg->ibm_u.immediate.ibim_payload, payload_nob,
+ &from);
+ if (rc != payload_nob) {
+ kiblnd_pool_free_node(&tx->tx_pool->tpo_pool, &tx->tx_list);
+ return -EFAULT;
+ }
+
nob = offsetof(struct kib_immediate_msg, ibim_payload[payload_nob]);
kiblnd_init_tx_msg(ni, tx, IBLND_MSG_IMMEDIATE, nob);
@@ -1741,8 +1746,14 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
break;
}
- copy_to_iter(&rxmsg->ibm_u.immediate.ibim_payload,
-IBLND_MSG_SIZE, to);
+ rc = copy_to_iter(&rxmsg->ibm_u.immediate.ibim_payload, rlen,
+ to);
+ if (rc != rlen) {
+ rc = -EFAULT;
+ break;
+ }
+
+ rc = 0;
lnet_finalize(ni, lntmsg, 0);
break;
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: lustre: fix all braces issues reported by checkpatch
Cleanup all braces that was reported by checkpatch. The only
issue not fixed up is in mdc_lock.c. Removing the braces in
the case of mdc_lock.c will break the build.
Signed-off-by: James Simmons
--
v1) Initial patch
v2) Rebased against latest staging-next tree
---
drivers/staging/lustre/lustre/fld/fld_cache.c | 3 ++-
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 9 +
drivers/staging/lustre/lustre/llite/vvp_dev.c | 5 +++--
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index b852fed..adaa094 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -348,9 +348,10 @@ static void fld_cache_overlap_handle(struct fld_cache
*cache,
f_curr->fce_range.lsr_end = new_start;
fld_cache_entry_add(cache, f_new, &f_curr->fce_list);
- } else
+ } else {
CERROR("NEW range =" DRANGE " curr = " DRANGE "\n",
PRANGE(range), PRANGE(&f_curr->fce_range));
+ }
}
struct fld_cache_entry
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
index ddb4642..181025d 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
@@ -1029,11 +1029,11 @@ void ldlm_grant_lock(struct ldlm_lock *lock, struct
list_head *work_list)
if (work_list && lock->l_completion_ast)
ldlm_add_ast_work_item(lock, NULL, work_list);
- if (res->lr_type == LDLM_PLAIN || res->lr_type == LDLM_IBITS)
+ if (res->lr_type == LDLM_PLAIN || res->lr_type == LDLM_IBITS) {
ldlm_grant_lock_with_skiplist(lock);
- else if (res->lr_type == LDLM_EXTENT)
+ } else if (res->lr_type == LDLM_EXTENT) {
ldlm_extent_add_lock(res, lock);
- else if (res->lr_type == LDLM_FLOCK) {
+ } else if (res->lr_type == LDLM_FLOCK) {
/*
* We should not add locks to granted list in the following
cases:
* - this is an UNLOCK but not a real lock;
@@ -1045,8 +1045,9 @@ void ldlm_grant_lock(struct ldlm_lock *lock, struct
list_head *work_list)
ldlm_is_test_lock(lock) || ldlm_is_flock_deadlock(lock))
return;
ldlm_resource_add_lock(res, &res->lr_granted, lock);
- } else
+ } else {
LBUG();
+ }
ldlm_pool_add(&ldlm_res_to_ns(res)->ns_pool, lock);
}
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c
b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index 8e45672..2b60699 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -591,9 +591,10 @@ static void *vvp_pgcache_start(struct seq_file *f, loff_t
*pos)
env = cl_env_get(&refcheck);
if (!IS_ERR(env)) {
sbi = f->private;
- if (sbi->ll_site->ls_obj_hash->hs_cur_bits > 64 - PGC_OBJ_SHIFT)
+ if (sbi->ll_site->ls_obj_hash->hs_cur_bits >
+ 64 - PGC_OBJ_SHIFT) {
pos = ERR_PTR(-EFBIG);
- else {
+ } else {
*pos = vvp_pgcache_find(env, &sbi->ll_cl->cd_lu_dev,
*pos);
if (*pos == ~0ULL)
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: lustre: fix all braces issues reported by checkpatch
On Sat, 2017-07-15 at 11:39 -0400, James Simmons wrote: > Cleanup all braces that was reported by checkpatch. The only > issue not fixed up is in mdc_lock.c. Removing the braces in > the case of mdc_lock.c will break the build. what checkpatch warning in mdc_locks.c is that? $ ./scripts/checkpatch.pl -f --terse --nosummary drivers/staging/lustre/lustre/mdc/mdc_locks.c drivers/staging/lustre/lustre/mdc/mdc_locks.c:590: WARNING: line over 80 characters drivers/staging/lustre/lustre/mdc/mdc_locks.c:600: WARNING: line over 80 characters drivers/staging/lustre/lustre/mdc/mdc_locks.c:637: WARNING: line over 80 characters ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
Am Sa, 15.07.2017, 15:47 schrieb Greg KH:
> On Sat, Jul 15, 2017 at 03:40:30PM +0200, Marcus Wolf wrote:
>> Hi Greg,
>>
Hi Greg,
now I added a TODO file and did a manual patchwork with lines of the old patch
(git format-patch master --stdout -p > pi433_patch) and the newer patch (git
diff master > pi433_patch). Stil don't know how to retreive multiple commits
in one single patch directly from git :-/
I did my best to meet a lot of rules of the link, you send me.If
there is stil something essential wrong or missing, please excuse and let me
know.
Especially I was in doubt about the verbosity of the change log. If you'd like
to see the list of features of the driver over there (please see my first mail),
let me know and I'll add.
Sorry for posting in HTML once again on last mail. Now I changed the frontend
of my
mailtool. Hope this works better. If not, excuse and let me know.
I Think about moving to gits mail function for my next patches.
Cheers,
Marcus
From: Marcus Wolf
Date: Tue,15 Jul 2017 17:52:06 +0100
Subject: [PATCH 1/1] drivers/staging/pi433: New driver
Added a driver for the pi433 radio module
(see https://www.pi433.de/en.html for details).
Signed-off-by: Marcus Wolf
Tested-by: Marcus Wolf on Raspbian, running
Kernel v4.12
---
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 268d4e6..fdf060c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -110,4 +110,6 @@ source "drivers/staging/ccree/Kconfig"
source "drivers/staging/typec/Kconfig"
+source "drivers/staging/pi433/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index b93e6f5..998f644 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_KS7010) += ks7010/
obj-$(CONFIG_GREYBUS) += greybus/
obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/
obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
+obj-$(CONFIG_PI433)+= pi433/
diff --git a/drivers/staging/pi433/Documentation/devicetree/pi433-overlay.dts
b/drivers/staging/pi433/Documentation/devicetree/pi433-overlay.dts
new file mode 100644
index 000..004b502
--- /dev/null
+++ b/drivers/staging/pi433/Documentation/devicetree/pi433-overlay.dts
@@ -0,0 +1,53 @@
+// Definitions for Pi433
+/dts-v1/;
+/plugin/;
+
+/ {
+compatible = "bcm,bcm2835", "bcm,bcm2708", "bcm,bcm2709";
+
+fragment@0 {
+target = <&spi0>;
+__overlay__ {
+status = "okay";
+
+spidev@0{
+status = "disabled";
+};
+
+spidev@1{
+status = "disabled";
+};
+};
+};
+
+ fragment@1 {
+ target = <&gpio>;
+ __overlay__ {
+ pi433_pins: pi433_pins {
+ brcm,pins = <7 25 24>;
+ brcm,function = <0 0 0>; // in in in
+ };
+ };
+ };
+
+ fragment@2 {
+ target = <&spi0>;
+ __overlay__ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ pi433: pi433@0 {
+ compatible = "Smarthome-Wolf,pi433";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ status = "okay";
+
+ pinctrl-0 = <&pi433_pins>;
+ DIO0-gpio = <&gpio 24 0>;
+ DIO1-gpio = <&gpio 25 0>;
+ DIO2-gpio = <&gpio 7 0>;
+ };
+ };
+ };
+};
diff --git a/drivers/staging/pi433/Documentation/devicetree/pi433.txt
b/drivers/staging/pi433/Documentation/devicetree/pi433.txt
new file mode 100644
index 000..14197c6
--- /dev/null
+++ b/drivers/staging/pi433/Documentation/devicetree/pi433.txt
@@ -0,0 +1,62 @@
+* Smarthome-Wolf Pi433 - a 433MHz radio module/shield for Raspberry Pi (see
www.pi433.de)
+
+Required properties:
+- compatible: must be "Smarthome-Wolf,pi433"
+- reg: chip select of SPI Interface
+- DIOx-gpio must be dedicated to the GPIO, connected with DIOx of the RFM69
module
+
+
+Example:
+
+With the following lines in gpio-section, the gpio pins, connected with pi433
are
+reserved/declared.
+
+&gpio{
+ [...]
+
+ pi433_pins: pi433_pins {
+ brcm,pins = <7 25 24>;
+ brcm,function = <0 0 0>; // in in in
+ };
+
+ [...]
+}
+
+With the following lines in spi section, the device pi433 is declared.
+It consists of the three gpio pins and an spi interface (here chip select 0)
+
+&spi0{
+ [...]
+
+ pi433: pi433@0 {
+ compatible = "Smarthome-Wolf,pi433";
Re: [PATCH 1/1] drivers/staging/pi433: New driver (fwd)
Please check on lines 894 and 688 (not shown) for the issues mentioned
below.
Note that the ifs and {s in the following code snippet don't always follow
the kernel coding style, eg on line 901.
julia
-- Forwarded message --
Date: Sun, 16 Jul 2017 04:35:49 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH 1/1] drivers/staging/pi433: New driver
Hi Wolf,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.12 next-20170714]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Wolf-Entwicklungen/drivers-staging-pi433-New-driver/20170716-021625
:: branch date: 2 hours ago
:: commit date: 2 hours ago
>> drivers/staging/pi433/pi433_if.c:894:18-21: ERROR: device is NULL but
>> dereferenced.
--
>> drivers/staging/pi433/pi433_if.c:688:5-19: WARNING: Unsigned expression
>> compared with zero: bytes_received >= 0
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 6b5d85fc273ec7c19addf7770155414da647de7e
vim +894 drivers/staging/pi433/pi433_if.c
6b5d85fc Wolf Entwicklungen 2017-07-15 883
6b5d85fc Wolf Entwicklungen 2017-07-15 884 static int pi433_open(struct inode
*inode, struct file *filp)
6b5d85fc Wolf Entwicklungen 2017-07-15 885 {
6b5d85fc Wolf Entwicklungen 2017-07-15 886 struct pi433_device *device;
6b5d85fc Wolf Entwicklungen 2017-07-15 887 struct pi433_instance
*instance;
6b5d85fc Wolf Entwicklungen 2017-07-15 888
6b5d85fc Wolf Entwicklungen 2017-07-15 889 mutex_lock(&minor_lock);
6b5d85fc Wolf Entwicklungen 2017-07-15 890 device = idr_find(&pi433_idr,
iminor(inode));
6b5d85fc Wolf Entwicklungen 2017-07-15 891
6b5d85fc Wolf Entwicklungen 2017-07-15 892 mutex_unlock(&minor_lock);
6b5d85fc Wolf Entwicklungen 2017-07-15 893 if (!device) {
6b5d85fc Wolf Entwicklungen 2017-07-15 @894 dev_dbg(device->dev,
"device: minor %d unknown.\n", iminor(inode));
6b5d85fc Wolf Entwicklungen 2017-07-15 895 return -ENODEV;
6b5d85fc Wolf Entwicklungen 2017-07-15 896 }
6b5d85fc Wolf Entwicklungen 2017-07-15 897
6b5d85fc Wolf Entwicklungen 2017-07-15 898 if (!device->rx_buffer) {
6b5d85fc Wolf Entwicklungen 2017-07-15 899 device->rx_buffer =
kmalloc(MAX_MSG_SIZE, GFP_KERNEL);
6b5d85fc Wolf Entwicklungen 2017-07-15 900 if (!device->rx_buffer)
6b5d85fc Wolf Entwicklungen 2017-07-15 901 {
6b5d85fc Wolf Entwicklungen 2017-07-15 902
dev_dbg(device->dev, "open/ENOMEM\n");
6b5d85fc Wolf Entwicklungen 2017-07-15 903 return -ENOMEM;
6b5d85fc Wolf Entwicklungen 2017-07-15 904 }
6b5d85fc Wolf Entwicklungen 2017-07-15 905 }
6b5d85fc Wolf Entwicklungen 2017-07-15 906
6b5d85fc Wolf Entwicklungen 2017-07-15 907 device->users++;
6b5d85fc Wolf Entwicklungen 2017-07-15 908 instance =
kzalloc(sizeof(*instance), GFP_KERNEL);
6b5d85fc Wolf Entwicklungen 2017-07-15 909 if (!instance)
6b5d85fc Wolf Entwicklungen 2017-07-15 910 {
6b5d85fc Wolf Entwicklungen 2017-07-15 911
kfree(device->rx_buffer);
6b5d85fc Wolf Entwicklungen 2017-07-15 912 device->rx_buffer =
NULL;
6b5d85fc Wolf Entwicklungen 2017-07-15 913 return -ENOMEM;
6b5d85fc Wolf Entwicklungen 2017-07-15 914 }
6b5d85fc Wolf Entwicklungen 2017-07-15 915
6b5d85fc Wolf Entwicklungen 2017-07-15 916 /* setup instance data*/
6b5d85fc Wolf Entwicklungen 2017-07-15 917 instance->device = device;
6b5d85fc Wolf Entwicklungen 2017-07-15 918 instance->tx_cfg.bit_rate =
4711;
6b5d85fc Wolf Entwicklungen 2017-07-15 919 // TODO: fill instance->tx_cfg;
6b5d85fc Wolf Entwicklungen 2017-07-15 920
6b5d85fc Wolf Entwicklungen 2017-07-15 921 /* instance data as context */
6b5d85fc Wolf Entwicklungen 2017-07-15 922 filp->private_data = instance;
6b5d85fc Wolf Entwicklungen 2017-07-15 923 nonseekable_open(inode, filp);
6b5d85fc Wolf Entwicklungen 2017-07-15 924
6b5d85fc Wolf Entwicklungen 2017-07-15 925 return 0;
6b5d85fc Wolf Entwicklungen 2017-07-15 926 }
6b5d85fc Wolf Entwicklungen 2017-07-15 927
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: lustre: fix all braces issues reported by checkpatch
> On Sat, 2017-07-15 at 11:39 -0400, James Simmons wrote:
> > Cleanup all braces that was reported by checkpatch. The only
> > issue not fixed up is in mdc_lock.c. Removing the braces in
> > the case of mdc_lock.c will break the build.
>
> what checkpatch warning in mdc_locks.c is that?
>
> $ ./scripts/checkpatch.pl -f --terse --nosummary
> drivers/staging/lustre/lustre/mdc/mdc_locks.c
> drivers/staging/lustre/lustre/mdc/mdc_locks.c:590: WARNING: line over 80
> characters
> drivers/staging/lustre/lustre/mdc/mdc_locks.c:600: WARNING: line over 80
> characters
> drivers/staging/lustre/lustre/mdc/mdc_locks.c:637: WARNING: line over 80
> characters
For 4.11-xxx kernels I was seeing
WARNING: braces {} are not necessary for any arm of this statement
#914: FILE: drivers/staging/lustre/lustre/mdc/mdc_locks.c:914:
+ if (it->it_op & IT_CREAT) {
[...]
+ } else if (it->it_op == IT_OPEN) {
[...]
+ } else {
[...]
Now it doesn't show up.___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Sat, Jul 15, 2017 at 07:05:04PM +0200, Wolf Entwicklungen wrote: > Am Sa, 15.07.2017, 15:47 schrieb Greg KH: > > On Sat, Jul 15, 2017 at 03:40:30PM +0200, Marcus Wolf wrote: > >> Hi Greg, > >> > > Hi Greg, > > now I added a TODO file and did a manual patchwork with lines of the old patch > (git format-patch master --stdout -p > pi433_patch) and the newer patch (git > diff master > pi433_patch). Stil don't know how to retreive multiple commits > in one single patch directly from git :-/ > I did my best to meet a lot of rules of the link, you send me.If > there is stil something essential wrong or missing, please excuse and let me > know. > > Especially I was in doubt about the verbosity of the change log. If you'd like > to see the list of features of the driver over there (please see my first > mail), > let me know and I'll add. Can you resend it without all of this stuff here, a patch email should just contain the patch itself, look at all of the examples on the mailing lists for how they look. > From: Marcus Wolf > Date: Tue,15 Jul 2017 17:52:06 +0100 > Subject: [PATCH 1/1] drivers/staging/pi433: New driver > > Added a driver for the pi433 radio module > (see https://www.pi433.de/en.html for details). > Signed-off-by: Marcus Wolf Need a blank line before signed-off-by. > Tested-by: Marcus Wolf on Raspbian, running > Kernel v4.12 No need for a tested-by from something that wrote, that is implied :) Almost there... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
