On Sat, Oct 06, 2012 at 05:04:33PM +0100, Mans Rullgard wrote:
> On 5 October 2012 23:42, Russell King - ARM Linux
> wrote:
> > On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
> >> The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
>
On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
> The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
> which is assumed to be aligned, and the cast overrides the packed attribute
> from the struct. Dereferencing these cast expressions must be done with the
>
On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> > Does it matter? I'm just relaying the argument against adding __packed
> > which was used before we were forced (by the networking folk) to implement
>
On Fri, Oct 05, 2012 at 09:37:38AM +0100, Mans Rullgard wrote:
> On 5 October 2012 09:33, Russell King - ARM Linux
> wrote:
> > On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 09:24, Russell King - ARM Linux
> >> wrote:
> &
On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> On 5 October 2012 09:24, Russell King - ARM Linux
> wrote:
> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> wrote:
> &
On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> On 5 October 2012 08:12, Russell King - ARM Linux
> wrote:
> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 02:56, Rob Herring wrote:
> >> > This struct is
On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> On 5 October 2012 02:56, Rob Herring wrote:
> > This struct is the IP header, so a struct ptr is just set to the
> > beginning of the received data. Since ethernet headers are 14 bytes,
> > often the IP header is not aligned unless t
On Fri, Sep 02, 2011 at 04:47:35PM +0200, Ulrich Weigand wrote:
> Assume the scenario you initally describe, where a first signal is
> ignored and leads to system call restart. With your latest patch,
> you call into syscall_restart which sets everything up to restart
> the call (with interrupts d
On Fri, Sep 02, 2011 at 07:40:34PM +0200, Ulrich Weigand wrote:
> Russell King - ARM Linux wrote on 09/02/2011
> 07:22:59 PM:
> > On Fri, Sep 02, 2011 at 04:47:35PM +0200, Ulrich Weigand wrote:
> > > Assume the scenario you initally describe, where a first signal is
>
On Thu, Sep 01, 2011 at 03:41:22PM +0200, Ulrich Weigand wrote:
> The problem now occurs if at point [0.] the target process just
> happened to be blocked in a restartable system call. For this
> sequence to then work as expected, two things have to happen:
>
> - at point [3.], the kernel must *n
On Tue, Dec 07, 2010 at 03:06:51PM +, Dave Martin wrote:
> Hi,
>
> On Tue, Dec 7, 2010 at 11:04 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Dec 07, 2010 at 10:45:42AM +, Dave Martin wrote:
> >> Yes-- though I didn't elaborate on it. You need a p
On Tue, Dec 07, 2010 at 10:45:42AM +, Dave Martin wrote:
> Yes-- though I didn't elaborate on it. You need a packager that can
> understand, say, that a binary built for ARMv5 EABI can interoperate
> with ARMv7 binaries etc.
> Again, I've heard it suggested that RPM can handle this, but I have
On Fri, Dec 03, 2010 at 04:28:27PM +, Dave Martin wrote:
> For on-SoC peripherals, this can be managed through the driver
> framework in the kernel, but for functional blocks of the CPU itself
> which are used by instruction set extensions, such as NEON or other
> media accelerators, it would b
13 matches
Mail list logo
