Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> The main motivation was to have the arch in control of as much direct
> register writing as possible. Even though our HV does allow us to write
> to config space, it's not obviously safe for Linux to be flipping bits
> and also calling the HV to
On Wed, 2007-03-28 at 00:39 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > It's an arch detail whether MSI irqs need to be masked using the PCI
> > MSI registers.
>
> Agreed. It isn't an arch detail that they need to be unmasked in
> the pci configuration
On Wed, 2007-03-28 at 00:39 -0600, Eric W. Biederman wrote:
Michael Ellerman [EMAIL PROTECTED] writes:
It's an arch detail whether MSI irqs need to be masked using the PCI
MSI registers.
Agreed. It isn't an arch detail that they need to be unmasked in
the pci configuration space.
I
Michael Ellerman [EMAIL PROTECTED] writes:
The main motivation was to have the arch in control of as much direct
register writing as possible. Even though our HV does allow us to write
to config space, it's not obviously safe for Linux to be flipping bits
and also calling the HV to configure
Michael Ellerman <[EMAIL PROTECTED]> writes:
> It's an arch detail whether MSI irqs need to be masked using the PCI
> MSI registers.
Agreed. It isn't an arch detail that they need to be unmasked in
the pci configuration space.
I assume this patch is motivated just to make arch support easier
Michael Ellerman [EMAIL PROTECTED] writes:
It's an arch detail whether MSI irqs need to be masked using the PCI
MSI registers.
Agreed. It isn't an arch detail that they need to be unmasked in
the pci configuration space.
I assume this patch is motivated just to make arch support easier
and
6 matches
Mail list logo
