On Thursday 31 July 2014 05:38 AM, Greg KH wrote:
>
> This patch doesn't apply against my tree at all, what did you make it
> against?
>
> Always work against linux-next, or the staging-next branch of my
> staging.git tree on git.kernel.org.
>
> thanks,
>
> greg k-h
Hi,
I am working on
On Thursday 31 July 2014 05:38 AM, Greg KH wrote:
This patch doesn't apply against my tree at all, what did you make it
against?
Always work against linux-next, or the staging-next branch of my
staging.git tree on git.kernel.org.
thanks,
greg k-h
Hi,
I am working on staging.git. After
On Tuesday 29 July 2014 02:47 PM, Dan Carpenter wrote:
> On Tue, Jul 29, 2014 at 10:05:38AM +0200, Tobias Klauser wrote:
>
>> Wouldn't it be better to annotate the data member in struct tagSCmdRequest
>> with __user instead of introducing all these casts?
Hi,
Yes, having the data member
On Tuesday 29 July 2014 02:47 PM, Dan Carpenter wrote:
On Tue, Jul 29, 2014 at 10:05:38AM +0200, Tobias Klauser wrote:
Wouldn't it be better to annotate the data member in struct tagSCmdRequest
with __user instead of introducing all these casts?
Hi,
Yes, having the data member annotated as
On Thursday 10 July 2014 11:25 AM, Anil Belur wrote:
> From: Anil Belur
>
> - as kfree() internally check for NULL, additional check it not
> required.
>
Sorry - please ignore this patch set, they are already fixed by someone
else recently.
--
To unsubscribe from this list: send the line
On Thursday 10 July 2014 11:25 AM, Anil Belur wrote:
From: Anil Belur ask...@gmail.com
- as kfree() internally check for NULL, additional check it not
required.
Sorry - please ignore this patch set, they are already fixed by someone
else recently.
--
To unsubscribe from this list: send the
On Wednesday 09 July 2014 05:16 PM, Pavel Machek wrote:
> I wonder if it would maek sense to do
> ./include/linux/interrupt.h:#define IRQF_DISABLED 0 to make it extra
> clear that it is nop now? Pavel
yes - it makes sense. there are still a few references to the macro in
the code.
Cheers,
Anil
On Wednesday 09 July 2014 05:16 PM, Pavel Machek wrote:
I wonder if it would maek sense to do
./include/linux/interrupt.h:#define IRQF_DISABLED 0 to make it extra
clear that it is nop now? Pavel
yes - it makes sense. there are still a few references to the macro in
the code.
Cheers,
Anil
--
On Wednesday 09 July 2014 05:18 AM, Greg KH wrote:
> Someone sent this same patch just before you did, sorry :(
>
Ah - no worries - sorry for the noise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wednesday 09 July 2014 05:18 AM, Greg KH wrote:
Someone sent this same patch just before you did, sorry :(
Ah - no worries - sorry for the noise.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Monday 30 June 2014 12:47 AM, Antti Palosaari wrote:
> Moikka!
> That is already fixed by someone else and patch is somewhere Mauro or
> Hans queue.
>
> regards
> Antti
>
Moikka :)
Ah no worries - I could not find the changes with the latest updates.
Thanks
--
To unsubscribe from this list:
On Monday 30 June 2014 12:47 AM, Antti Palosaari wrote:
Moikka!
That is already fixed by someone else and patch is somewhere Mauro or
Hans queue.
regards
Antti
Moikka :)
Ah no worries - I could not find the changes with the latest updates.
Thanks
--
To unsubscribe from this list: send
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
> Doesn't apply :(
Thanks - Its probably because I have included a patch already sent
earlier, will redo this set.
--
To unsubscribe from this list: send the line "unsubscribe
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Doesn't apply :(
Thanks - Its probably because I have included a patch already sent
earlier, will redo this set.
--
To unsubscribe from this list: send the line unsubscribe
> Should be an empty line between variable declarations and code.
Hi Andreas, not sure if you are referring to the same patch as there is
already an empty line present.
823 loff_t size = cl_isize_read(inode);
824 loff_t cur_index
> If you are using min_t(__u32, ...) then there is no need for the
(__u32) cast of LOV_MAX_STRIPE_COUNT, since that is the whole point of
min_t() that the cast is done internally.
Agreed, it makes sense not to cast twice when using min_t().
--
To unsubscribe from this list: send the line
If you are using min_t(__u32, ...) then there is no need for the
(__u32) cast of LOV_MAX_STRIPE_COUNT, since that is the whole point of
min_t() that the cast is done internally.
Agreed, it makes sense not to cast twice when using min_t().
--
To unsubscribe from this list: send the line
Should be an empty line between variable declarations and code.
Hi Andreas, not sure if you are referring to the same patch as there is
already an empty line present.
823 loff_t size = cl_isize_read(inode);
824 loff_t cur_index =
On Tuesday 17 June 2014 07:38 AM, Drokin, Oleg wrote:
> On Jun 16, 2014, at 12:22 PM, Anil Belur wrote:
>
>> From: Anil Belur
>>
>> fixed: WARNING: line over 80 characters, used a new variable 'size_index' to
>> store the offset. Replace "unsigned long" with "u64" type for
> Apparently you
> - result = +1; + result = + 1;
> This looks wrong.
> Here +1 is apparently meant as +1 (compare to -1) to underscore it's positive
> nature.
> If you wanted to drop the +, that'd be fine, I guess, but in your version it
> looks outright wrong to me (I tested and it compiles, though).
>
> Bye,
> + unsigned long cur_index;
> I wonder why move this particular declaration here?
> The only user is still in that one conditional branch anyway.
These changes are for fixing warning of line over 80 chars and indent.
maybe I should change 'unsigned long' to 'u64' keeping the line of code
in
+ unsigned long cur_index;
I wonder why move this particular declaration here?
The only user is still in that one conditional branch anyway.
These changes are for fixing warning of line over 80 chars and indent.
maybe I should change 'unsigned long' to 'u64' keeping the line of code
in
- result = +1; + result = + 1;
This looks wrong.
Here +1 is apparently meant as +1 (compare to -1) to underscore it's positive
nature.
If you wanted to drop the +, that'd be fine, I guess, but in your version it
looks outright wrong to me (I tested and it compiles, though).
Bye,
On Tuesday 17 June 2014 07:38 AM, Drokin, Oleg wrote:
On Jun 16, 2014, at 12:22 PM, Anil Belur wrote:
From: Anil Belur ask...@gmail.com
fixed: WARNING: line over 80 characters, used a new variable 'size_index' to
store the offset. Replace unsigned long with u64 type for
Apparently you
24 matches
Mail list logo
