On Tue, Mar 26, 2013 at 5:34 PM, Yinghai Lu wrote:
> On Tue, Mar 26, 2013 at 2:54 PM, Bjorn Helgaas wrote:
>
>> Where are we at with this? I don't see Sarah's patch in the tree, and
>> I haven't applied any changes, so my guess is this is still broken.
>
> Yes, the fix is in the linus tree.
>
>
On Tue, Mar 26, 2013 at 5:34 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Mar 26, 2013 at 2:54 PM, Bjorn Helgaas bhelg...@google.com wrote:
Where are we at with this? I don't see Sarah's patch in the tree, and
I haven't applied any changes, so my guess is this is still broken.
Yes, the
On Tue, Mar 26, 2013 at 2:54 PM, Bjorn Helgaas wrote:
> Where are we at with this? I don't see Sarah's patch in the tree, and
> I haven't applied any changes, so my guess is this is still broken.
Yes, the fix is in the linus tree.
On Tue, Mar 5, 2013 at 3:41 PM, Sarah Sharp
wrote:
> On Fri, Mar 01, 2013 at 08:41:13AM +0100, Hannes Reinecke wrote:
>> On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
>> >[+cc Andy]
>> >
>> >3) I don't understand why the xhci init fails in the first place. It
>> >looks like the "request interrupt
On Tue, Mar 5, 2013 at 3:41 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
On Fri, Mar 01, 2013 at 08:41:13AM +0100, Hannes Reinecke wrote:
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
3) I don't understand why the xhci init fails in the first place. It
looks like the
On Tue, Mar 26, 2013 at 2:54 PM, Bjorn Helgaas bhelg...@google.com wrote:
Where are we at with this? I don't see Sarah's patch in the tree, and
I haven't applied any changes, so my guess is this is still broken.
Yes, the fix is in the linus tree.
On Fri, Mar 01, 2013 at 08:41:13AM +0100, Hannes Reinecke wrote:
> On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
> >[+cc Andy]
> >
> >3) I don't understand why the xhci init fails in the first place. It
> >looks like the "request interrupt 255 failed" message is from
> >xhci_try_enable_msi(), but
On Fri, Mar 01, 2013 at 08:41:13AM +0100, Hannes Reinecke wrote:
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
3) I don't understand why the xhci init fails in the first place. It
looks like the request interrupt 255 failed message is from
xhci_try_enable_msi(), but that function
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke h...@suse.de wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_
On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke h...@suse.de wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke wrote:
> On 02/20/2013 05:57 PM, Yinghai Lu wrote:
>>
>> On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
>>> Apparently this device is meant to use MSI _only_ so the BIOS developer
>>> didn't feel the need to assign
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke h...@suse.de wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to
On 02/26/2013 02:29 PM, David Härdeman wrote:
On Thu, Feb 21, 2013 at 07:53:14AM +0100, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
it seems you mess pin with interrupt line.
current code:
unsigned char irq;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN,
On Thu, Feb 21, 2013 at 07:53:14AM +0100, Hannes Reinecke wrote:
>On 02/20/2013 05:57 PM, Yinghai Lu wrote:
>>it seems you mess pin with interrupt line.
>>
>>current code:
>> unsigned char irq;
>>
>> pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
>> dev->pin = irq;
>>
On Thu, Feb 21, 2013 at 07:53:14AM +0100, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
it seems you mess pin with interrupt line.
current code:
unsigned char irq;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, irq);
dev-pin = irq;
if (irq)
On 02/26/2013 02:29 PM, David Härdeman wrote:
On Thu, Feb 21, 2013 at 07:53:14AM +0100, Hannes Reinecke wrote:
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
it seems you mess pin with interrupt line.
current code:
unsigned char irq;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN,
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
It is
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
>>
> Apparently this device is meant to use MSI _only_ so the BIOS developer
> didn't feel the need to assign an INTx here.
>
> According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
>> It is recommended that devices implement
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
It is recommended that devices
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled
On 02/19/2013 08:40 PM, Yinghai Lu wrote:
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost,
On Tue, Feb 19, 2013 at 12:47:32PM -0700, Bjorn Helgaas wrote:
> On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke wrote:
> > The PCI config space reseves a byte for the interrupt line,
> > so irq 255 actually refers to 'not set'.
> > However, the 'irq' field for struct pci_dev is an integer,
> >
On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke wrote:
> The PCI config space reseves a byte for the interrupt line,
> so irq 255 actually refers to 'not set'.
> However, the 'irq' field for struct pci_dev is an integer,
> so the original meaning is lost, causing the system to
> assign an
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke wrote:
> The PCI config space reseves a byte for the interrupt line,
> so irq 255 actually refers to 'not set'.
> However, the 'irq' field for struct pci_dev is an integer,
> so the original meaning is lost, causing the system to
> assign an
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke h...@suse.de wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an
On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke h...@suse.de wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an
On Tue, Feb 19, 2013 at 12:47:32PM -0700, Bjorn Helgaas wrote:
On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke h...@suse.de wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
On 02/19/2013 08:40 PM, Yinghai Lu wrote:
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke h...@suse.de wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning
On Mon, Feb 18, 2013 at 11:09:53AM +0100, Hannes Reinecke wrote:
>The PCI config space reseves a byte for the interrupt line,
>so irq 255 actually refers to 'not set'.
>However, the 'irq' field for struct pci_dev is an integer,
>so the original meaning is lost, causing the system to
>assign an
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an interrupt '255', which fails.
So we should _not_ assign an interrupt
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an interrupt '255', which fails.
So we should _not_ assign an interrupt
On Mon, Feb 18, 2013 at 11:09:53AM +0100, Hannes Reinecke wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an
34 matches
Mail list logo
