Arthur Marsh wrote on 24/09/15 15:26:
Jiang Liu wrote on 24/09/15 13:58:
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
I've applied the patch, rebuilt the kernel and verified that it allows
unloading of the
On 25 September 2015 at 15:19, Rafael J. Wysocki wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.
It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte.
That required
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64-bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.
Fix that by changing type of 'global_lock'
Hi Linus,
Here are the outstanding target-pending fixes for v4.3-rc3 code.
Please go ahead and pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master
This includes a iser-target series from Jenny + Sagi @ Mellanox that
addresses the few remaining active I/O
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> >
7 matches
Mail list logo