linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Geoff Levand <geoffrey.levand@am.sony.com>
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
	ppcdev <linuxppc-dev@ozlabs.org>
Subject: Re: [patch 00/18] PS3 patches for 2.6.23
Date: Mon, 11 Jun 2007 02:08:58 -0500	[thread overview]
Message-ID: <71e5ae7f85657e4ab5bfbc809cab9c60@bga.com> (raw)
In-Reply-To: <466622FA.7030200@am.sony.com>

On Wed Jun 6 12:59:06 EST 2007, Geoff Levand wrote:
> Here is a series I have for 2.6.23.
>
> Patches 1-8 are more or less independent of each other.
> Patches 9-18 are a dependent series of my system bus
> rework patches.

I'm repling to the summary but will pull a few points from the series.

The dependent series is currently split per file.   While this makes it 
easier to see what a given area looks like after all the patches, it 
means that the kernel compile will break during the series.  Breaking 
git bisect is frowned upon, so it will need to be re-split for merge.  
(Or disable the ps3 system bus during the merge of the series).

> [09/18] PS3: System-bus rework
> [10/18] PS3: System-bus uevent
> [11/18] PS3: System-bus modinfo attribute

If you define a module device table and add it to 
scripts/bin/file2alias.c you would not need to create the MOD_ALIAS_xxx 
driver defines.

Should your module alias and matching include the device_type?

Rather than setting core.owner = THIS_MODULE, take the 
pci_driver_register approach where __pci_driver_register takes the 
module name and owner id as arguments that are automatically passed by 
a macro.

> [12/18] PS3: Repository probe cleanups
> [13/18] PS3: USB system-bus rework
> [14/18] PS3: vuart rework

This changes vuart_device->core from struct_device to ps3 system 
device, but doesn't update the drivers.

> [15/18] PS3: sys-manager re-work
> [16/18] PS3: Rework AV settings driver

There are several dev_debug() that still use vuart_device.core not 
.core.core.
Maybe vuart_device.core should be renamed?

The probe routine assigns to the global ps3av without checking if its 
already set.  If a second device caused probe to be called the 
references to the first one would be lost.

> [17/18] PS3: frame buffer system-bus rework
> [18/18] PS3: Device registration routines.

ps3_start_probe_thread should add at least the bus_type to the thread 
name (the thread name is a sprintf va_list format arg; you don't need 
to create a temporary string buffer).

milton

  reply	other threads:[~2007-06-11  7:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06  2:59 [patch 00/18] PS3 patches for 2.6.23 Geoff Levand
2007-06-11  7:08 ` Milton Miller [this message]
2007-06-12  5:03   ` Benjamin Herrenschmidt
2007-06-12 18:22   ` Geoff Levand
2007-06-12 19:25     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=71e5ae7f85657e4ab5bfbc809cab9c60@bga.com \
    --to=miltonm@bga.com \
    --cc=Geert.Uytterhoeven@sonycom.com \
    --cc=geoffrey.levand@am.sony.com \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).