And there is of course the puzzle of why there exists simultaneously
driver shutdown() and suspend(PMSG_FREEZE) methods as I believed they
are defined to do exactly the same thing.
No puzzle; that's not how they're defined. Both of them cause the
device to quiesce that device's activity.
Some PCI devices lose all configuration (including BARs) when
transitioning from D3hot-D0. This leaves such a device in an
inaccessible state. The patch below causes the BARs to be restored
when enabling such a device, so that its driver will be able to
access it.
Hmm, I wonder if I missed
Date: Tue, 12 Jul 2005 08:19:43 +0100
From: Russell King [EMAIL PROTECTED]
On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
and stop
whining about certain non-errors (details in the patch comments).
Please explain what the whining is (details were missing from the
patch
ttyS0 at MMIO 0xfffb (irq = 46) is a ST16654
serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0
IRQ47): -28
serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0
IRQ15): -28
Thanks, that's exactly what I wanted to know.
-28 is
The idea is _not_ to register them on boards that only have a
single RS232 connector. The fix was just having the 8250 code
understand that it should only register ports that are real.
The tty code doesn't work like that. You must know how many ports
you want right from the start.
That
How well would _this_ notion of an operating point scale up?
I have this feeling that it's maybe better attuned to scale down
sorts of problems (maybe cell phones) than to a big NUMA box. I can
see how a batch scheduled server might want to fire up only enough
components to run the next
If my Prolific USB-Serialadapter plugged in on reboot
the ehci_hcd driver complains about a Hand-off bug in Bios.
- snip
ehci_hcd :00:1d.7: EHCI Host Controller
ehci_hcd :00:1d.7: debug port 1
ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem is that I see the PCI quirks code has evolved even farther
from the
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at
Phoenix, FWIW;
That was me.
Thanks. It's good to have BIOS experts involved too. :)
the problem is that I see the PCI quirks code has evolved
even farther
Date: Sun, 31 Jul 2005 19:02:09 -0700
From: [EMAIL PROTECTED]
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem
Well I like this a bit better, but it's still in transition from
the old I2C style stuff over to a newer driver model based one.
(As other folk have noted, with the bus v. adapter confusion.)
- Can you make the SPI messages work with an async API?
It suffices to have a callback and a void *
> Some PCI devices lose all configuration (including BARs) when
> transitioning from D3hot->D0. This leaves such a device in an
> inaccessible state. The patch below causes the BARs to be restored
> when enabling such a device, so that its driver will be able to
> access it.
Hmm, I wonder if I
> Date: Tue, 12 Jul 2005 08:19:43 +0100
> From: Russell King <[EMAIL PROTECTED]>
>
> On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
> > and stop
> > whining about certain non-errors (details in the patch comments).
>
> Please explain what the whining is (details were missing from
> > ttyS0 at MMIO 0xfffb (irq = 46) is a ST16654
> > serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0
> > IRQ47): -28
> > serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0
> > IRQ15): -28
>
> Thanks, that's exactly what I wanted to know.
>
> > The idea is _not_ to register them on boards that only have a
> > single RS232 connector. The fix was just having the 8250 code
> > understand that it should only register ports that are real.
>
> The tty code doesn't work like that. You must know how many ports
> you want right from the
> > If my Prolific USB-Serialadapter plugged in on reboot
> > the ehci_hcd driver complains about a Hand-off bug in Bios.
> >
> > -> snip
> >
> > ehci_hcd :00:1d.7: EHCI Host Controller
> > ehci_hcd :00:1d.7: debug port 1
> >
> > ehci_hcd :00:1d.7: BIOS handoff failed (104,
> Date: Sun, 31 Jul 2005 16:02:44 -0700
> From: Greg KH <[EMAIL PROTECTED]>
>
> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > I think that "continuing" codepath came from someone at Phoenix, FWIW;
> > the problem is that I see the PCI quirks code has evolved even farther
>
> >> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> >> > I think that "continuing" codepath came from someone at
> >> > Phoenix, FWIW;
>
> That was me.
Thanks. It's good to have BIOS experts involved too. :)
> >> > the problem is that I see the PCI quirks code has
> Date: Sun, 31 Jul 2005 19:02:09 -0700
> From: [EMAIL PROTECTED]
>
> > Date: Sun, 31 Jul 2005 16:02:44 -0700
> > From: Greg KH <[EMAIL PROTECTED]>
> >
> > On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > > I think that "continuing" codepath came from someone at Phoenix,
Well I like this a bit better, but it's still in transition from
the old I2C style stuff over to a newer driver model based one.
(As other folk have noted, with the "bus" v. "adapter" confusion.)
- Can you make the SPI messages work with an async API?
It suffices to have a callback and a
How well would _this_ notion of an operating point scale up?
I have this feeling that it's maybe better attuned to "scale down"
sorts of problems (maybe cell phones) than to a big NUMA box. I can
see how a batch scheduled server might want to fire up only enough
components to run the next
> And there is of course the puzzle of why there exists simultaneously
> driver shutdown() and suspend(PMSG_FREEZE) methods as I believed they
> are defined to do exactly the same thing.
No puzzle; that's not how they're defined. Both of them cause the
device to quiesce that device's activity.
FWIW, I have a dual-proc SuperMicro motherboard P3DM3 with integrated
Adaptec SCSI and Intel 8255x built-in NIC.
Sometimes on a cold boot I get the "kernel: eth0: card reports no RX
buffers" that repeats, but if I follow it with a warm boot the message
doesn't appear (even on subsequent warm
Found testing board with AX88772B devices.
Signed-off-by: David B. Robins <li...@davidrobins.net>
---
drivers/net/usb/asix_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 75d6f26..07
On 2015-10-05 06:31, David Miller wrote:
From: "David B. Robins" <li...@davidrobins.net>
Date: Wed, 30 Sep 2015 16:20:04 -0400
If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will
return
but not clear rx->size. rx points to driver private data. A later cal
On 2016-05-03 00:55, John Stultz wrote:
In testing with HiKey, we found that since commit 3f30b158eba5c60
(asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
noise during network transfers:
[ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was
On 2016-05-03 17:16, Dean Jenkins wrote:
On 03/05/16 15:42, David B. Robins wrote:
I don't think the first one is giving you problems (except as
triggered by the second) but I had concerns about the second myself
(and emailed the author off-list, but received no reply), and we did
not take
On 2016-05-04 03:58, Dean Jenkins wrote:
On 04/05/16 01:28, David B. Robins wrote:
Here is the code snippet from the patch with my annotations between #
#, I will try to explain my intentions. Feel free to point out any
flaws:
if (rx->remaining && (rx->remaining + size
FWIW, I have a dual-proc SuperMicro motherboard P3DM3 with integrated
Adaptec SCSI and Intel 8255x built-in NIC.
Sometimes on a cold boot I get the "kernel: eth0: card reports no RX
buffers" that repeats, but if I follow it with a warm boot the message
doesn't appear (even on subsequent warm
On 2015-10-05 06:31, David Miller wrote:
From: "David B. Robins"
Date: Wed, 30 Sep 2015 16:20:04 -0400
If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will
return
but not clear rx->size. rx points to driver private data. A later call
assumes that nonzero s
On 2016-05-04 03:58, Dean Jenkins wrote:
On 04/05/16 01:28, David B. Robins wrote:
Here is the code snippet from the patch with my annotations between #
#, I will try to explain my intentions. Feel free to point out any
flaws:
if (rx->remaining && (rx->remaining + size
On 2016-05-03 00:55, John Stultz wrote:
In testing with HiKey, we found that since commit 3f30b158eba5c60
(asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
noise during network transfers:
[ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was
On 2016-05-03 17:16, Dean Jenkins wrote:
On 03/05/16 15:42, David B. Robins wrote:
I don't think the first one is giving you problems (except as
triggered by the second) but I had concerns about the second myself
(and emailed the author off-list, but received no reply), and we did
not take
Found testing board with AX88772B devices.
Signed-off-by: David B. Robins
---
drivers/net/usb/asix_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 75d6f26..079069a 100644
--- a/drivers/n
34 matches
Mail list logo
