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
> > > ---
> >
disregard this patch, I sent the wrong file. v3 coming.
-- Ben
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Tue, 2016-02-23 at 19:16 +0300, Dan Carpenter wrote:
> When you're reviewing, you only have to care about the most recent
> allocation. After this point we need to call put_device(). After
> this
> point we need to call unregister. The "goto unregister" is pretty
> obvious what it does so it
On Sat, 2016-02-13 at 01:01 +0300, Dan Carpenter wrote:
> I looked at the Smatch warnings, plus some bonus stuff I'm still
> working
> on.
>
> drivers/staging/unisys/include/iochannel.h:592 add_physinfo_entries()
> warn: inconsistent indenting
> drivers/staging/unisys/include/iochannel.h:596 add_p
Greg,
Thank you very much for taking our patches. All of us here appreciate
it a lot. :)
It looks to me like our driver set is clean as far as
checkpatch.pl is concerned - there's one error, which was said to be
acceptable as it was, and a small number of checks that can't be
made any prettier.
On Mon, 2016-02-08 at 22:39 +0530, Sudip Mukherjee wrote:
> maybe this is better where you have single exit point and so only one
> spin_unlock_irqrestore().
We discussed this before. I don't want to put any of the goto messes
back in because I don't think it shortens the code or makes it any
sim
On Sun, 2016-02-07 at 14:03 -0800, Greg KH wrote:
> On Fri, Jan 29, 2016 at 10:21:26AM -0500, Benjamin Romer wrote:
> > This patch series cleans up all the remaining issues reported by
> > checkpatch.pl that can be fixed. The series was rebased against
> > the current contents of staging-next.
>
>
On Mon, 2016-01-25 at 20:22 +, Hugo Camboulive wrote:
> alloc_etherdev() calls alloc_netdev_mqs(), which
> already uses kzalloc/vzalloc.
>
> This clears a sparse warning :
> drivers/staging/unisys/visornic/visornic_main.c:1366:15: warning:
> memset with byte count of 1460112
>
> Signed-off-by
On 01/07/2016 04:34 AM, Dan Carpenter wrote:
queue_delayed_work() returns bool, not negative error codes. It returns
false if the work has already been queued or true otherwise. Since
we don't care about that, we can just remove the test.
Signed-off-by: Dan Carpenter
Tested with s-Par, wor
On 12/01/2015 10:57 AM, Dan Carpenter wrote:
What I meant was that I'm generally opposed to "common exit paths".
Mixing all the exit paths together often makes the code more complicated
and leads to errors. That makes sense from a common sense perspective
that doing many things is more difficult
On 12/01/2015 03:00 AM, Dan Carpenter wrote:
Doing One Err style error handling is often a mistake but it's ok here.
Why is it okay here? I don't understand why this function would be any
different than the other places where the code used a goto.
If we *have* to change it I would prefer tha
On 11/17/2015 05:18 PM, Greg KH wrote:
On Tue, Nov 17, 2015 at 09:57:58AM -0500, Benjamin Romer wrote:
This patch series adds a centralized infrastructure and device support
for channel interrupts sent to s-Par virtual devices. With these changes,
the visorhba device is ~80% faster than with onl
On 10/12/2015 11:51 PM, Greg KH wrote:
On Mon, Oct 12, 2015 at 03:19:47PM -0400, Benjamin Romer wrote:
From: David Kershner
Convert from pragma to __packed
Signed-off-by: David Kershner
Signed-off-by: Benjamin Romer
---
drivers/staging/unisys/visorbus/vmcallinterface.h | 4 +---
1 file c
On 10/02/2015 05:40 AM, Greg KH wrote:
Please generate patches with the -M flag, so that it is easy to see that
you are moving files around, not just removing and adding them somewhere
else.
Can you fix this up and resend the series starting with this patch?
Will do, do I need to v2 them? Or j
On 09/23/2015 01:00 PM, Greg KH wrote:
v4:
* remove all BUG() and BUG_ON() - do not crash the kernel
You just deleted them? No taking into account that you should just
handle issues like this in a run-time-safe way instead?
Removing them altogether was a better way to handle the prob
On 09/04/2015 09:41 AM, Sudip Mukherjee wrote:
Any new developments can only go in rc1 release. 4.3 merge window is
already open so new developments cannot be added to 4.3-rc1. New codes
has to go to 4.4-rc1.
4.3-rc2 - 4.3-rc7 (or 8) can only have fixes.
I don't think any of the patches in this s
On 09/02/2015 08:40 PM, Greg KH wrote:
These aren't all "fixes" so I can't just add them to the 4.3-final
release, but some look like they should go there. So please split this
into two different series and resend, one for 4.3-final and one for
4.4-rc1.
Greg,
We've been running and testing wi
Please disregard this version, it assumes that the kthread_park() patch
was present. I will send a v3.
-- Ben
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi Greg,
I was wondering if you'd had a chance to take a look at this patch, and
if you had any additional comments? It should have all of your previous
comments addressed. :)
-- Ben
___
devel mailing list
de...@linuxdriverproject.org
http://driverd
On 06/01/2015 06:17 PM, Drew Fustini wrote:
On Mon, Jun 01, 2015 at 02:34:16PM -0400, Ben Romer wrote:
Would you mind if I sent a second version of this patch with it
rebased against my last set of patches, so it will apply?
Please go ahead.
thanks,
drew
Sorry, never mind, it looks like
On 05/28/2015 10:04 PM, Drew Fustini wrote:
Add static declarations to statisfy sparse warnings in:
drivers/staging/unisys/visorbus/visorbus_main.c
Hi,
I'd really like to take this patch, but it doesn't apply at the end of
the current set of patches I'm working with, and if I put it ahead
As the actually intended timeout is not documented and msecs_to_jiffies
timeouts can be a factor 10 different from the current effective timeout
this needs to be checked by someone who knows the details of this driver
in any case it should be passed in a HZ independent manner.
I need an ack from
On 05/08/2015 04:52 AM, Dan Carpenter wrote:
I'm finished going through these patches. Pretty decent over all.
My only comment was that there were three? places where we introduced a
bug and then fixed it in a later patch. I kind of wish the fix were
folded into the original patch. I don't kn
On 05/06/2015 08:15 AM, Dan Carpenter wrote:
Also there were some unrelated changes. Benjamin, you should have
complained about those when the patch was first sent. That's like the
most obvious thing to check when you're reviewing patches.
I'm sorry, I don't understand what part of this is un
On 04/30/2015 10:36 AM, Greg KH wrote:
Because patch 08 didn't apply, this one has fuzz problems, and the reset
in the series doesn't apply. Can you refresh against my tree and resend
the rest?
Will do, thanks for taking these. :)
-- Ben
___
devel
On 03/26/2015 09:47 AM, Ben Romer wrote:
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that ha
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that happens.
Ben/David?
I'll test them today. :)
-- B
devendra.aaru wrote:
> You might consider not using camel case letters..
The purpose of patch 8 is to fix spacing errors across the entire file. The
camelcase names are fixed in later patches.
-- Ben
___
devel mailing list
de...@linuxdriverproject.org
Sudip Mukherjee wrote:
> fixed sparse warning : context imbalance in 'destroy_device'
> unexpected unlock
> this patch will generate warning from checkpatch for
> lines over 80 character , but since those are user-visible strings
> so it was not modified.
>
> Signed-off-by
Greg KH wrote:
>
> Really
>
Obviously not, I'm sorry. :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Greg KH wrote:
> What happened to the idea of only creating the sysfs files _if_ it is
> needed? You are always creating these files, and then can return
> -ENODEV if the device really isn't there, that's not what you should do
> for a sysfs file. If the file is present, it should return data,
31 matches
Mail list logo
