> Really now, this is basic fixes and cleanups,
I agree to this view to some degree.
> you have been asked many times in the past to move on beyond these,
It is more useful when more severe bugs or bigger software improvements can be
found.
Which source code clean-ups are picked better up by o
> I added some Acked- and Reviewed-by tags last time.
I noticed this of course.
> Did the patches change
Yes. - The amount of source code which I touched in this software module
is different for the second series.
> or why didn't you add them?
I imagined that your acknowledgements to the pre
On Sat, Aug 13, 2016 at 10:12:20PM +0200, SF Markus Elfring wrote:
> > I am not an upstream path.
> > Greg KH generally serves that function here.
> > My suggestion would be to resend the entire patchset as V(n+1).
>
> I am curious if it would make sense to reduce the mail traffic a bit by
> find
> You might have noticed I also wrote in the same reply:
>
> "All of these pr_fmt uses are redundant as pr_err already does pr_fmt"
I admit that I made another software development mistake there. - It might not
matter much
when a final fix could be to get rid of the three affected logging calls
On Sat, 2016-08-13 at 21:30 +0200, SF Markus Elfring wrote:
> >
> > I think pr_ is OK if reworking the code
> > to support dev_ is not easy.
> Thanks for this explanation. - It sounds more constructive than the previous
> short
> feedback "Not correct".
How do you need your food prepared?
Do ot
> I think pr_ is OK if reworking the code
> to support dev_ is not easy.
Thanks for this explanation. - It sounds more constructive than the previous
short
feedback "Not correct".
>> Would you accept that another update will be appended to the discussed patch
>> series?
>
> No. Patches shoul
On Thu, Aug 11, 2016 at 07:17:12AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
>
> Further update suggestions were taken into account
Which ones? Please describe them to ease review.
> after a patch was applied from static source code analysis.
I added some Acked- and Reviewed-by ta
From: Colin Ian King
priv is being dereferenced before a check for it being null
is made, so there is a possibililty a null pointer deference
can occur. Instead, only dereference priv if it is non-null.
Signed-off-by: Colin Ian King
---
drivers/staging/ks7010/ks7010_sdio.c | 4 ++--
1 file cha
Rather than keeping a pointer, a flag, and reference count, use RCU and existing
device reference count to protect the synthetic to VF relationship.
One other change is that injected packets must be accounted for on the synthetic
device otherwise the statistics will be lost. The VF device driver
This is how I think it should be fixed, but not tested yet.
Subjec: netvsc: use device not module reference counts
Fix how the cross-device reference counting is handled. When VF is
associated with the synthetic interface, the VF driver module should
still be able to be unloaded. The module unl
On Sat, 2016-08-13 at 13:10 +0200, SF Markus Elfring wrote:
> > > Prefer usage of the macro "pr_err" over the interface "printk".
> > Not correct
> A checkpatch warning like "PREFER_PR_LEVEL" can point additional
> possibilities out
> for this use case.
> Would you like to introduce any of the hig
The workqueue is being used to run deferred work for the android binder.
The "binder_deferred_workqueue" queues only a single work item and hence
does not require ordering. Also, this workqueue is not being used on a
memory recliam path. Hence, the singlethreaded workqueue has been
replaced with t
>> Prefer usage of the macro "pr_err" over the interface "printk".
> Not correct
A checkpatch warning like "PREFER_PR_LEVEL" can point additional possibilities
out
for this use case.
Would you like to introduce any of the higher level logging functions instead?
>> diff --git a/drivers/staging/k
On Aug 12, 2016, at 22:30, Jes Sorensen wrote:
> sunbing writes:
>> On Aug 11, 2016, at 23:25, Jes Sorensen wrote:
>>
>>> Bing Sun writes:
Fixed sparse parse error:
Expected constant expression in case statement.
Signed-off-by: Bing Sun
---
drivers/staging/rtl
14 matches
Mail list logo