Bartlomiej Zolnierkiewicz wrote:
> Factor out code unregistering devices from ide_unregister() to
> ide_port_unregister_devices().
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
___
Bartlomiej Zolnierkiewicz wrote:
> * Factor out devices init from ide_init_port_data() to
> ide_port_init_devices_data().
> While at it:
> * Add explicit clearing of IDE device structure.
> There should be no functionality changes caused by this patch.
> Signed-off-by: Bartlomiej Zolnierkiew
Ppc cores by Freescale are using the configuration field instead of the
major revision field for their major revision number. Those field
definitions come from include/asm-powerpc/reg.h.
Look at the pdf below and you will see that PVR_MAJ() does a wrong shift
for ppc cores by Freescale. This pa
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to of_iomap for the driver name? If it
is non-null also d
On Sunday 10 February 2008, Jon Smirl wrote:
> of_iomap doesn't implicitly do a request_mem_region(). How should
> request_mem_region() be handled? When using of_iomap you don't get the
> length of the region back so it isn't easy to call request_mem_region.
>
> What about adding a third param to
On 2/9/08, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Sunday 10 February 2008, Jon Smirl wrote:
> > of_iomap doesn't implicitly do a request_mem_region(). How should
> > request_mem_region() be handled? When using of_iomap you don't get the
> > length of the region back so it isn't easy to call
On Sunday 10 February 2008, Jon Smirl wrote:
> On 2/9/08, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> > On Sunday 10 February 2008, Jon Smirl wrote:
> > > of_iomap doesn't implicitly do a request_mem_region(). How should
> > > request_mem_region() be handled? When using of_iomap you don't get the
>
On Saturday 09 February 2008, Sean MacLennan wrote:
> If anybody has suggestions on better ways to do this, fire away.
I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.
The o
Arnd Bergmann wrote:
> I guess the cleanest solution would be to include two complete device trees
> for this platform, and then choose the correct one in cuboot-warp.c based
> on the board revision.
>
> The obvious disadvantage of this is that you'd get two device trees
> that you need to keep in
