follow.
>
> As a stop gap use netif_rx_any_context() which invokes the correct code
> path depending on context and confines the in_interrupt() usage to core
> code.
>
> Signed-off-by: Sebastian Andrzej Siewior
> Signed-off-by: Thomas Gleixner
> Acked-by: Kalle Valo
e the narrow side edge to hit with. Users have
tried the large flat surface behind the display, but the display tends
to fail after five to ten hits. It will depend on the tiger.
--
James Cameron
http://quozl.netrek.org/
e the narrow side edge to hit with. Users have
tried the large flat surface behind the display, but the display tends
to fail after five to ten hits. It will depend on the tiger.
--
James Cameron
http://quozl.netrek.org/
t; +static int olpc_xo175_ec_resume(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > + unsigned char x = 0;
> >
> > u8
> >
>
t; +static int olpc_xo175_ec_resume(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > + unsigned char x = 0;
> >
> > u8
> >
>
If this won't boot for you, we may need fixes for older FW.
Let me know what you need there; with a patch, and if it isn't too
extensive I could spin a new build. We're not producing these models,
so I don't _have_ to keep the factory test code working.
https://github.com/quozl/openfirmware
--
James Cameron
http://quozl.netrek.org/
If this won't boot for you, we may need fixes for older FW.
Let me know what you need there; with a patch, and if it isn't too
extensive I could spin a new build. We're not producing these models,
so I don't _have_ to keep the factory test code working.
https://github.com/quozl/openfirmware
--
James Cameron
http://quozl.netrek.org/
s?
>
> Could I get prepared binary zImage for testing?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
James Cameron
http://quozl.netrek.org/
s?
>
> Could I get prepared binary zImage for testing?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
James Cameron
http://quozl.netrek.org/
lay. Love your work! From my notes, SSP2 is
0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in
OpenFirmware or CForth once clocks are on.
--
James Cameron
http://quozl.netrek.org/
lay. Love your work! From my notes, SSP2 is
0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in
OpenFirmware or CForth once clocks are on.
--
James Cameron
http://quozl.netrek.org/
");
> - pr_cont("\n");
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id,
> interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
;
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id,
> interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote:
> 08.06.2016 02:51, James Cameron пишет:
> >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote:
> >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote:
> >>>Hi!
> >>>
On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote:
> 08.06.2016 02:51, James Cameron пишет:
> >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote:
> >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote:
> >>>Hi!
> >>>
eal race or I have missed something?
>
> Yeah, it looks like it should be grabbing priv->driver_lock before
> clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to
> submit a patch after testing? Do you have any of that hardware?
I've hardware, with serial console.
Can test any patch, on USB (8388) or SDIO (8686).
--
James Cameron
http://quozl.netrek.org/
eal race or I have missed something?
>
> Yeah, it looks like it should be grabbing priv->driver_lock before
> clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to
> submit a patch after testing? Do you have any of that hardware?
I've hardware, with serial console.
Can test any patch, on USB (8388) or SDIO (8686).
--
James Cameron
http://quozl.netrek.org/
.nos...@oracle.com>
> Link: https://lkml.org/lkml/2015/12/17/666
> Cc: Eric Dumazet <eric.duma...@gmail.com>
> Cc: Sasha Levin <sasha.le...@oracle.com>
> Cc: David Miller <da...@davemloft.net>
Reviewed-by: James Cameron <qu...@laptop.org>
(An old DECnet
https://lkml.org/lkml/2015/12/17/666
> Cc: Eric Dumazet
> Cc: Sasha Levin
> Cc: David Miller
Reviewed-by: James Cameron
(An old DECnet application programmer from way back, ah what fun!)
> ---
> net/decnet/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> dif
some devices didn't have them, some
didn't seem to be good data.
>
> Anyway if we cannot completely rely on the SFDP tables we could still use
> DT properties but we should no longer expect to guess all hardware parameters
> from the JEDEC ID alone.
We solved this problem by not using our SPI Flash from the kernel, but
that's not the best outcome. ;-)
>
> Best regards,
>
> Cyrille
--
James Cameron
http://quozl.netrek.org/
some devices didn't have them, some
didn't seem to be good data.
>
> Anyway if we cannot completely rely on the SFDP tables we could still use
> DT properties but we should no longer expect to guess all hardware parameters
> from the JEDEC ID alone.
We solved this problem by not using our SPI Flash from the kernel, but
that's not the best outcome. ;-)
>
> Best regards,
>
> Cyrille
--
James Cameron
http://quozl.netrek.org/
resting, we're back to this symptom again.
Nice to see this fix.
Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this
driver. Tracked at OLPC as #12694.
--
James Cameron
http://quozl.netrek.org/
resting, we're back to this symptom again.
Nice to see this fix.
Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this
driver. Tracked at OLPC as #12694.
--
James Cameron
http://quozl.netrek.org/
02_11_packet() is called) that the debugging
> enter/leave functions are balanced.
>
> Signed-off-by: Dan Williams
Reviewed-by: James Cameron
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
() is called) that the debugging
enter/leave functions are balanced.
Signed-off-by: Dan Williams d...@redhat.com
Reviewed-by: James Cameron qu...@laptop.org
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
ule/rules" and
"s/following/followed".
On the other hand, no other driver mentions this implementation detail
of IW_IS_SET in declaration of iw_priv_args, so perhaps the whole
comment block should be removed.
Either way;
Reviewed-by: James Cameron
p.s. nice to see you ag
this implementation detail
of IW_IS_SET in declaration of iw_priv_args, so perhaps the whole
comment block should be removed.
Either way;
Reviewed-by: James Cameron qu...@laptop.org
p.s. nice to see you again.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line
a result, the maximum size
> + of the decompressed kernel image is limited by the size of the
> + reserved memory space (the difference of the two contiguous memory
> + addresses).
Same here.
> +
> + If want more functions or some debug options, the decompressed ker
MOVE_RAMDISK_OFFSET_M
+ int Set the move offset of ramdisk (in Mbytes)
+ range 5 100
+ default 20
+ depends on MOVE_RAMDISK
+ help
+ Specify the move offset of the ramdisk, if want a bigger kernel,
please
+ Increase this size.
--
1.7.10.4
--
James
On Fri, Dec 06, 2013 at 02:34:17PM +0400, Sergei Ianovich wrote:
> On Fri, 2013-12-06 at 20:53 +1100, James Cameron wrote:
> > I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64)
> > after the patch was applied to olpc-kernel/arm-3.5 but, as you say it
> > do
_PXA_CONSOLE option. I've updated all
> in-kernel users. However, out-of-kernel configs will no longer provide
> serial console, unless manually reconfigured. Is this the case we should
> worry about?
OLPC holds an out-of-kernel config (xo_4_defconfig); but no, I don't
think we'd have troubl
2xx-uart turned out to be a clone of
> 8250_core driver.
>
> Workaround for Erratum #19 according to Marvel(R) PXA270M Processor
> Specification Update (April 19, 2010) is dropped. 8250_core reads
> from FIFO immediately after checking DR bit in LSR.
Reviewed-by: James Cameron
Tha
to be a clone of
8250_core driver.
Workaround for Erratum #19 according to Marvel(R) PXA270M Processor
Specification Update (April 19, 2010) is dropped. 8250_core reads
from FIFO immediately after checking DR bit in LSR.
Reviewed-by: James Cameron qu...@laptop.org
Thanks.
(for my notes
provide
serial console, unless manually reconfigured. Is this the case we should
worry about?
OLPC holds an out-of-kernel config (xo_4_defconfig); but no, I don't
think we'd have trouble with this. Go for it.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send
On Fri, Dec 06, 2013 at 02:34:17PM +0400, Sergei Ianovich wrote:
On Fri, 2013-12-06 at 20:53 +1100, James Cameron wrote:
I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64)
after the patch was applied to olpc-kernel/arm-3.5 but, as you say it
doesn't change, perhaps
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote:
> On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> > pxa2xx-uart was a separate uart platform driver. It was declaring
> > the same device names and numbers as 8250 driver. As a result,
> > it
ll = serial_in(up, UART_DLL);
> - WARN_ON(dll != (quot & 0xff));
If this is no longer needed, serial_pxa_dl_write can be removed
because it is same as default_serial_dl_write.
I did not check the other errata work arounds.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: sen
ear. I
have tried changing command line to console=ttyS0,115200.
1. http://dev.laptop.org/~quozl/y/1VojGn.txt (diff relative to
olpc-kernel/arm-3.5)
2. http://dev.laptop.org/~quozl/z/1VojLz.txt (dmesg)
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line
command line to console=ttyS0,115200.
1. http://dev.laptop.org/~quozl/y/1VojGn.txt (diff relative to
olpc-kernel/arm-3.5)
2. http://dev.laptop.org/~quozl/z/1VojLz.txt (dmesg)
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
, serial_pxa_dl_write can be removed
because it is same as default_serial_dl_write.
I did not check the other errata work arounds.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote:
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
pxa2xx-uart was a separate uart platform driver. It was declaring
the same device names and numbers as 8250 driver. As a result,
it was impossible to use 8250
My problems with ENOPROTOOPT were due to lack of coffee. They were
caused by ICMP protocol unreachable responses from the test server
because I'd taken away it's pppd. My mistake.
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
> I've asked James Cameron, pptp project lead, to
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
> I've asked James Cameron, pptp project lead, to try a test to force
> the server side to issue a CCP DOWN, to make sure the client-side
> kernel ppp_generic module does the right thing and drops packets.
I'm stil
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
I've asked James Cameron, pptp project lead, to try a test to force
the server side to issue a CCP DOWN, to make sure the client-side
kernel ppp_generic module does the right thing and drops packets.
I'm still working on this; tried
My problems with ENOPROTOOPT were due to lack of coffee. They were
caused by ICMP protocol unreachable responses from the test server
because I'd taken away it's pppd. My mistake.
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
I've asked James Cameron, pptp project lead, to try
45 matches
Mail list logo
