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 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
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 los
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 size
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
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 simulat
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 "vo
> 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;
> >> 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 evolve
> 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
>
> > 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
> 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. B
> > 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 star
> > 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.
>
> 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 t
> 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 m
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 boot
17 matches
Mail list logo
