Currently we return IRQ_NONE from the context fault handler if the FSR
doesn't actually have the fault bit set (some sort of miswired
interrupt?) or if the client doesn't register an IOMMU fault handler.
However, registering a client fault handler is optional, so telling the
interrupt framework tha
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte
>> long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte
> long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the sam
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.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned l
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.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call whe
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > 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
On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> 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 b
On 25-09-15, 20:49, Johannes Berg wrote:
> Ok, then, but that means Rafael is completely wrong ...
> debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> it can't be on the stack. You also don't get a call when it changes.
Ahh, ofcourse. My bad as well...
I think we can change
> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and
> > doing
> >
> > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
> > > *)&first_ec->gpe))
> > > goto error;
> > > if (!debugfs_create_bool("use_global_lock", 0444,
> > > dev_dir,
> > > -
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's c
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
Err, surely that wasn't what Rafael meant, since it's clearly
impossible to use a pointer to the stack, assign to
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 (mostly).
That
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 passing a local variable to deb
On 25/09/2015 03:49, Wu, Feng wrote:
> Hi Paolo,
>
> Thanks for your review on this series! I'd like to confirm this series (plus
> the patch fixing the compilation error) is okay to you and I don't need to
> do extra things for it, right?
Yes, can you check if branch vtd-pi of
git://git.kernel
16 matches
Mail list logo
