* Re: basic and stupid question on wait_event and wake_up
From: Domen Puncer @ 2007-08-13 9:31 UTC (permalink / raw)
To: Ming Liu; +Cc: Linuxppc-embedded
In-Reply-To: <BAY138-F307C7D793CEC734113D325B2DC0@phx.gbl>
On 13/08/07 09:22 +0000, Ming Liu wrote:
> Dear Momen,
> OK. I see now. So you mean condition is only to judge whether a sleeping
> process could be waken up or not when wake_up() is executed in other
> processes or interrupt handlers. What really wakes the process up is still
> the function of wake_up, right? We just execute wake_up() and then check if
> condition is true. If yes, the process will leave its sleeping and wake up;
> if not, it keep sleeping. Am I right?
Right.
Domen
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Laurent Pinchart @ 2007-08-13 9:30 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: domen.puncer
In-Reply-To: <BAY138-F307C7D793CEC734113D325B2DC0@phx.gbl>
On Monday 13 August 2007 11:22, Ming Liu wrote:
> Dear Momen,
> OK. I see now. So you mean condition is only to judge whether a sleeping
> process could be waken up or not when wake_up() is executed in other
> processes or interrupt handlers. What really wakes the process up is still
> the function of wake_up, right? We just execute wake_up() and then check if
> condition is true. If yes, the process will leave its sleeping and wake up;
> if not, it keep sleeping. Am I right?
Actually, the process will wake up every time you call wake_up(). It will then
evaluate the condition. If the condition is true, the process will return
from wait_event. If the condition is false, it will go back to sleep.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Ming Liu @ 2007-08-13 9:22 UTC (permalink / raw)
To: domen.puncer; +Cc: Linuxppc-embedded
In-Reply-To: <20070813084736.GF13994@moe.telargo.com>
Dear Momen,
OK. I see now. So you mean condition is only to judge whether a sleeping
process could be waken up or not when wake_up() is executed in other
processes or interrupt handlers. What really wakes the process up is still
the function of wake_up, right? We just execute wake_up() and then check if
condition is true. If yes, the process will leave its sleeping and wake up;
if not, it keep sleeping. Am I right?
BR
Ming
>From: Domen Puncer <domen.puncer@telargo.com>
>To: Ming Liu <eemingliu@hotmail.com>
>CC: Linuxppc-embedded@ozlabs.org
>Subject: Re: basic and stupid question on wait_event and wake_up
>Date: Mon, 13 Aug 2007 10:47:36 +0200
>
>On 13/08/07 08:33 +0000, Ming Liu wrote:
> > Dear Domen,
> > Thanks for your reply first.
> >
> > >I understand it this way:
> > >- condition
> > > Just checking the condition is one way (if you don't have a wake_up
> > > source, like an interrupt), but that's not really what wait_event
does.
> > > It would be something like
> > > while (condition) {
> > > msleep(10);
> > > }
> > > There was some talk on poll_wait(), but I don't know what happened
to
> > > it.
> >
> > So you mean in my senario (wake the process up in the interrupt
handler), I
> > needn't to use wake_up at all? A "condition == true" in the interrupt
> > handler is enough to wake the sleeping process up? Am I right?
>
>No.
>Without the wake_up(), wait_event() would (normally) just wait
>... and wait... and wait...
>When you set your task_state to TASK_{UN,}INTERRUPTIBLE you need to have
>a way to wake it up again.
>
>That's why I used msleep(10) in my example. It would check condition every
>10 ms.
>
> >
> > I checked the source code in linux/wait.h and here is the defination of
> > wait_event:
> >
> > #define __wait_event(wq, condition)
> > do {
> > DEFINE_WAIT(__wait);
> > for (;;) { \
> > prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);
> > if (condition)
> > break;
> > schedule();
> > }
> > finish_wait(&wq, &__wait);
> > } while (0)
> >
> > #define wait_event(wq, condition)
> > do {
> > if (condition)
> > break;
> > __wait_event(wq, condition);
> > } while (0)
> >
> > >From the source code, it seems like that this mechanism doesn't use
> > msleep(), like what you mentioned, to release its executing. Instead,
it
> > uses schedule() to do that.
>
>msleep() was just an example of how to do polling wait. Didn't mean to
>confuze you there, sorry.
>
> >
> >
> > >- wake_up
> > > Just wake_up isn't enough, you get a race:
> > > | interrupt handler | process |
> > > ------------------------------------------
> > > | do_something() | |
> > > | wake_up() | |
> > > | ... | wait on wq |
> > >
> > > And so you have a process waiting on waitqueue, that just missed the
> > > wakeup. Obviously should not be used.
> > >
> > >- wake_up & condition
> > > | interrupt handler | process |
> > > ------------------------------------------
> > > | flag = 1 | |
> > > | wake_up() | |
> > > | ... | wait_event |
> > > | ... | flag = 0 |
> > >
> > > This will work properly and if wait_event misses a wake_up, the
> > > condition check (flag) will kick in before putting it to sleep.
> > >
> >
> > Thanks for your explaining on the race problem. I can understand this
now.
> > However I still cannot understand, is such a problem: In the above
figures
> > for my case, if flag=1 could wake the process up, then what's the use
of
> > wake_up()? From my understanding if the condition turns true, then the
> > process which depends on this condition will be waken up. Thus what's
the
> > exact use of wake_up()? Also in my program, I tried to remove wake_up()
> > sentence and it seems that there is no difference on the result.
>
>As explained above, flag = 1 does not wake up the process, it just makes
>sure you don't have miss-the-wakeup race.
>
>
> Domen
>
> >
> > Thanks for the explanation.
> >
> > BR
> > Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Domen Puncer @ 2007-08-13 8:47 UTC (permalink / raw)
To: Ming Liu; +Cc: Linuxppc-embedded
In-Reply-To: <BAY138-F35B86412B7E7CB4869F265B2DC0@phx.gbl>
On 13/08/07 08:33 +0000, Ming Liu wrote:
> Dear Domen,
> Thanks for your reply first.
>
> >I understand it this way:
> >- condition
> > Just checking the condition is one way (if you don't have a wake_up
> > source, like an interrupt), but that's not really what wait_event does.
> > It would be something like
> > while (condition) {
> > msleep(10);
> > }
> > There was some talk on poll_wait(), but I don't know what happened to
> > it.
>
> So you mean in my senario (wake the process up in the interrupt handler), I
> needn't to use wake_up at all? A "condition == true" in the interrupt
> handler is enough to wake the sleeping process up? Am I right?
No.
Without the wake_up(), wait_event() would (normally) just wait
... and wait... and wait...
When you set your task_state to TASK_{UN,}INTERRUPTIBLE you need to have
a way to wake it up again.
That's why I used msleep(10) in my example. It would check condition every
10 ms.
>
> I checked the source code in linux/wait.h and here is the defination of
> wait_event:
>
> #define __wait_event(wq, condition)
> do {
> DEFINE_WAIT(__wait);
> for (;;) { \
> prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);
> if (condition)
> break;
> schedule();
> }
> finish_wait(&wq, &__wait);
> } while (0)
>
> #define wait_event(wq, condition)
> do {
> if (condition)
> break;
> __wait_event(wq, condition);
> } while (0)
>
> >From the source code, it seems like that this mechanism doesn't use
> msleep(), like what you mentioned, to release its executing. Instead, it
> uses schedule() to do that.
msleep() was just an example of how to do polling wait. Didn't mean to
confuze you there, sorry.
>
>
> >- wake_up
> > Just wake_up isn't enough, you get a race:
> > | interrupt handler | process |
> > ------------------------------------------
> > | do_something() | |
> > | wake_up() | |
> > | ... | wait on wq |
> >
> > And so you have a process waiting on waitqueue, that just missed the
> > wakeup. Obviously should not be used.
> >
> >- wake_up & condition
> > | interrupt handler | process |
> > ------------------------------------------
> > | flag = 1 | |
> > | wake_up() | |
> > | ... | wait_event |
> > | ... | flag = 0 |
> >
> > This will work properly and if wait_event misses a wake_up, the
> > condition check (flag) will kick in before putting it to sleep.
> >
>
> Thanks for your explaining on the race problem. I can understand this now.
> However I still cannot understand, is such a problem: In the above figures
> for my case, if flag=1 could wake the process up, then what's the use of
> wake_up()? From my understanding if the condition turns true, then the
> process which depends on this condition will be waken up. Thus what's the
> exact use of wake_up()? Also in my program, I tried to remove wake_up()
> sentence and it seems that there is no difference on the result.
As explained above, flag = 1 does not wake up the process, it just makes
sure you don't have miss-the-wakeup race.
Domen
>
> Thanks for the explanation.
>
> BR
> Ming
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Ming Liu @ 2007-08-13 8:33 UTC (permalink / raw)
To: domen.puncer; +Cc: Linuxppc-embedded
In-Reply-To: <20070813075423.GE13994@moe.telargo.com>
Dear Domen,
Thanks for your reply first.
>I understand it this way:
>- condition
> Just checking the condition is one way (if you don't have a wake_up
> source, like an interrupt), but that's not really what wait_event does.
> It would be something like
> while (condition) {
> msleep(10);
> }
> There was some talk on poll_wait(), but I don't know what happened to
> it.
So you mean in my senario (wake the process up in the interrupt handler), I
needn't to use wake_up at all? A "condition == true" in the interrupt
handler is enough to wake the sleeping process up? Am I right?
I checked the source code in linux/wait.h and here is the defination of
wait_event:
#define __wait_event(wq, condition)
do { DEFINE_WAIT(__wait);
for (;;) { \
prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);
if (condition)
break;
schedule();
}
finish_wait(&wq, &__wait);
} while (0)
#define wait_event(wq, condition)
do {
if (condition)
break;
__wait_event(wq, condition);
} while (0)
>From the source code, it seems like that this mechanism doesn't use
msleep(), like what you mentioned, to release its executing. Instead, it
uses schedule() to do that.
>- wake_up
> Just wake_up isn't enough, you get a race:
> | interrupt handler | process |
> ------------------------------------------
> | do_something() | |
> | wake_up() | |
> | ... | wait on wq |
>
> And so you have a process waiting on waitqueue, that just missed the
> wakeup. Obviously should not be used.
>
>- wake_up & condition
> | interrupt handler | process |
> ------------------------------------------
> | flag = 1 | |
> | wake_up() | |
> | ... | wait_event |
> | ... | flag = 0 |
>
> This will work properly and if wait_event misses a wake_up, the
> condition check (flag) will kick in before putting it to sleep.
>
Thanks for your explaining on the race problem. I can understand this now.
However I still cannot understand, is such a problem: In the above figures
for my case, if flag=1 could wake the process up, then what's the use of
wake_up()? From my understanding if the condition turns true, then the
process which depends on this condition will be waken up. Thus what's the
exact use of wake_up()? Also in my program, I tried to remove wake_up()
sentence and it seems that there is no difference on the result.
Thanks for the explanation.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, mporter, linuxppc-embedded, linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 0862965..38810b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2804,6 +2804,8 @@ M: mporter@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: arch/ppc/syslib/ppc4xx_*
+F: include/asm-ppc/ppc4xx_*
LINUX FOR POWERPC BOOT CODE
P: Tom Rini
^ permalink raw reply related
* [PATCH] [295/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, linuxppc-embedded, linux-kernel, galak, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 896c8bf..a289176 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2829,6 +2829,7 @@ M: galak@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: arch/ppc/syslib/ppc83xx_*
LINUX FOR POWERPC PA SEMI PWRFICIENT
P: Olof Johansson
^ permalink raw reply related
* [PATCH] [294/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC8XX
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, marcelo, linuxppc-embedded, linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index e295b18..896c8bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2821,6 +2821,7 @@ M: marcelo@kvack.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: arch/ppc/syslib/ppc8xx*
LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX
P: Kumar Gala
^ permalink raw reply related
* [PATCH] [293/2many] MAINTAINERS - LINUX FOR POWERPC BOOT CODE
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: trini, torvalds, linuxppc-embedded, linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 38810b7..e295b18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2813,6 +2813,7 @@ M: trini@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: arch/ppc/boot/
LINUX FOR POWERPC EMBEDDED PPC8XX
P: Marcelo Tosatti
^ permalink raw reply related
* Re: basic and stupid question on wait_event and wake_up
From: Domen Puncer @ 2007-08-13 7:54 UTC (permalink / raw)
To: Ming Liu; +Cc: Linuxppc-embedded
In-Reply-To: <BAY138-F25C6B0625737531B77D706B2E30@phx.gbl>
On 12/08/07 13:57 +0000, Ming Liu wrote:
> Dear all,
> I am reading LDD(V3) chapter 6 on the topic of wait_event(queue, conditio=
n)=20
> and wake_up(queue) functions. I am quite confused on the sayings. One is=
=20
> "Until condition evaluates to a true value, the process continues to=20
> sleep", which looks like that 'condition' is the one who wake up the=20
> process from its sleeping. However the other saying is "The basic functio=
n=20
> that wakes up sleeping processes is called wake_up, and wake_up wakes up=
=20
> all processes waiting on the given queue" So who is the exact one to wake=
=20
> the sleeping process up at all, condition or wake_up? From my=20
> understanding, if the condition becomes true, then the sleeping process=
=20
> will leave its sleeping status and wake up. Then what's the use of wake_u=
p=20
> function?=20
I understand it this way:
- condition
Just checking the condition is one way (if you don't have a wake_up
source, like an interrupt), but that's not really what wait_event does.
It would be something like
while (condition) {
msleep(10);
}
There was some talk on poll_wait(), but I don't know what happened to
it.
- wake_up
Just wake_up isn't enough, you get a race:
| interrupt handler | process |
------------------------------------------
| do_something() | |
| wake_up() | |
| ... | wait on wq |
And so you have a process waiting on waitqueue, that just missed the
wakeup. Obviously should not be used.
- wake_up & condition
| interrupt handler | process |
------------------------------------------
| flag =3D 1 | |
| wake_up() | |
| ... | wait_event |
| ... | flag =3D 0 |
This will work properly and if wait_event misses a wake_up, the
condition check (flag) will kick in before putting it to sleep.
>=20
> My senario could be described as: in my char device driver, I use one ioc=
tl=20
> command to initiate a DMA transfer. After all related registers are=20
> initiated, this process will be put to sleep for saving CPU cycles. In th=
e=20
> interrupt handler which is for a DMA_done, I wake that process up and=20
> resume its following executing. With this method, in my application progr=
am=20
> if I release a DMA initiation command, it is a Blocking operation and it=
=20
> will wait until the DMA transfer is done.=20
Looks like you should use the "wake_up and condition" option.
Domen
>=20
> Perhaps my question is quite simple or basic. Thanks for any explanation=
=20
> and comment on this topic in my senario from you experts. Thanks a lot.
>=20
> Br
> Ming
>=20
> _________________________________________________________________
> =E4=B8=8E=E8=81=94=E6=9C=BA=E7=9A=84=E6=9C=8B=E5=8F=8B=E8=BF=9B=E8=A1=8C=
=E4=BA=A4=E6=B5=81=EF=BC=8C=E8=AF=B7=E4=BD=BF=E7=94=A8 MSN Messenger: http=
://messenger.msn.com/cn =20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Domen Puncer @ 2007-08-13 7:21 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, linuxppc-embedded, netdev
In-Reply-To: <20070810130225.GE3375@ghostprotocols.net>
On 10/08/07 10:02 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 10, 2007 at 11:51:53AM +0200, Domen Puncer escreveu:
> > +static u8 null_mac[6];
>
> const
OK.
...
> > +static void fec_set_paddr(struct net_device *dev, u8 *mac)
> > +{
> > + struct fec_priv *priv = netdev_priv(dev);
> > + struct mpc52xx_fec __iomem *fec = priv->fec;
> > +
> > + out_be32(&fec->paddr1, *(u32*)(&mac[0]));
> > + out_be32(&fec->paddr2, (*(u16*)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
>
> spaces after the types on casts to pointers
I assume you mean: out_be32(&fec->paddr1, *(u32 *)(&mac[0]));
>
> > +}
> > +
> > +static void fec_get_paddr(struct net_device *dev, u8 *mac)
> > +{
> > + struct fec_priv *priv = netdev_priv(dev);
> > + struct mpc52xx_fec __iomem *fec = priv->fec;
> > +
> > + *(u32*)(&mac[0]) = in_be32(&fec->paddr1);
> > + *(u16*)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
>
> ditto
OK.
>
> > +}
> > +
> > +static int fec_set_mac_address(struct net_device *dev, void *addr)
> > +{
> > + struct sockaddr *sock = (struct sockaddr *)addr;
>
> no need for a cast, addr is a void pointer
Right, missed this one.
>
> > +
> > + memcpy(dev->dev_addr, sock->sa_data, dev->addr_len);
> > +
> > + fec_set_paddr(dev, sock->sa_data);
> > + return 0;
>
> Why always return 0? make it void
Because struct net_device->set_mac_address's prototype is like that.
>
> > +}
> > +
> > +static void fec_free_rx_buffers(struct bcom_task *s)
> > +{
> > + struct sk_buff *skb;
> > +
> > + while (!bcom_queue_empty(s)) {
> > + skb = bcom_retrieve_buffer(s, NULL, NULL);
> > + kfree_skb(skb);
> > + }
> > +}
> > +
> > +static int fec_alloc_rx_buffers(struct bcom_task *rxtsk)
> > +{
> > + while (!bcom_queue_full(rxtsk)) {
> > + struct sk_buff *skb;
> > + struct bcom_fec_bd *bd;
> > +
> > + skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
> > + if (skb == 0)
>
> Test against NULL
Right. I also fixed other stuff sparse reports.
>
> > + return -EAGAIN;
> > +
...
> > +
> > + if (new_state && netif_msg_link(priv)) {
> > + phy_print_status(phydev);
> > + }
>
> No need for {}, this if has only one statement
OK.
...
> > +static int __init
> > +mpc52xx_fec_init(void)
> > +{
> > + int ret;
> > + if ((ret = fec_mdio_init())) {
>
> Why not:
>
> int ret = fec_mdio_init();
> if (ret) {
>
> Less parenthesis, looks more clear
I prefer it like that too.
Thanks Arnaldo!
Any other comments on code functionality, design?
Domen
^ permalink raw reply
* Re: [PATCH] [43/2many] MAINTAINERS - AOA (Apple Onboard Audio) ALSA DRIVER
From: Michael Ellerman @ 2007-08-13 6:54 UTC (permalink / raw)
To: joe; +Cc: linuxppc-dev, johannes, torvalds, linux-kernel, akpm
In-Reply-To: <46bff8b4.nGsvrO+zx5IWj+A6%joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 724 bytes --]
On Sun, 2007-08-12 at 23:22 -0700, joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e2e88f3..016f342 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -420,6 +420,7 @@ M: johannes@sipsolutions.net
> L: linuxppc-dev@ozlabs.org
> L: alsa-devel@alsa-project.org (subscribers-only)
> S: Maintained
> +F: sound/oao/
Should be aoa.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [381/2many] MAINTAINERS - POWERPC 4xx EMAC DRIVER
From: joe @ 2007-08-13 6:34 UTC (permalink / raw)
To: torvalds, netdev, linuxppc-embedded, linux-kernel, ebs, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d30368..f526cf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3659,6 +3659,7 @@ W: http://kernel.ebshome.net/emac/
L: linuxppc-embedded@ozlabs.org
L: netdev@vger.kernel.org
S: Maintained
+F: drivers/net/ibm_emac/
PNP SUPPORT
P: Adam Belay
^ permalink raw reply related
* [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT
From: joe @ 2007-08-13 6:34 UTC (permalink / raw)
To: torvalds, linuxppc-dev, linux-kernel, geoffrey.levand,
cbe-oss-dev, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 4fe48a0..62b6ede 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3746,6 +3746,12 @@ M: geoffrey.levand@am.sony.com
L: linuxppc-dev@ozlabs.org
L: cbe-oss-dev@ozlabs.org
S: Supported
+F: arch/powerpc/boot/ps3*
+F: arch/powerpc/platforms/ps3/
+F: drivers/*/ps3*
+F: drivers/ps3/
+F: drivers/usb/host/*ps3.c
+F: include/asm-powerpc/ps3*
PVRUSB2 VIDEO4LINUX DRIVER
P: Mike Isely
^ permalink raw reply related
* [PATCH] [193/2many] MAINTAINERS - FREESCALE SOC FS_ENET DRIVER
From: joe @ 2007-08-13 6:27 UTC (permalink / raw)
To: vbordug, torvalds, pantelis.antoniou, netdev, linuxppc-embedded,
linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index e06f478..2ef0ec4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1859,6 +1859,8 @@ M: vbordug@ru.mvista.com
L: linuxppc-embedded@ozlabs.org
L: netdev@vger.kernel.org
S: Maintained
+F: drivers/net/fs_enet/
+F: include/linus/fs_enet_pd.h
FREESCALE HIGHSPEED USB DEVICE DRIVER
P: Li Yang
^ permalink raw reply related
* [PATCH] [194/2many] MAINTAINERS - FREESCALE HIGHSPEED USB DEVICE DRIVER
From: joe @ 2007-08-13 6:27 UTC (permalink / raw)
To: torvalds, linuxppc-embedded, linux-usb-devel, linux-kernel, leoli,
akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ef0ec4..944316a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1868,6 +1868,7 @@ M: leoli@freescale.com
L: linux-usb-devel@lists.sourceforge.net
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: drivers/usb/gadget/fsl_usb2_udc.c
FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
P: Li Yang
^ permalink raw reply related
* [PATCH] [195/2many] MAINTAINERS - FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
From: joe @ 2007-08-13 6:27 UTC (permalink / raw)
To: torvalds, netdev, linuxppc-embedded, linux-kernel, leoli, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 944316a..35f1636 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1876,6 +1876,7 @@ M: leoli@freescale.com
L: netdev@vger.kernel.org
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: drivers/net/ucc_geth*
FILE LOCKING (flock() and fcntl()/lockf())
P: Matthew Wilcox
^ permalink raw reply related
* [PATCH] [298/2many] MAINTAINERS - LINUX FOR 64BIT POWERPC
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, paulus, paulus, linuxppc-dev, linux-kernel, anton,
anton, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d10932..36c4960 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2857,6 +2857,9 @@ M: anton@au.ibm.com
W: http://www.penguinppc.org/ppc64/
L: linuxppc-dev@ozlabs.org
S: Supported
+F: arch/powerpc/configs/ppc64_defconfig
+F: arch/powerpc/kernel/proc_ppc64.c
+F: include/asm-powerpc/pgtable-ppc64.h
LINUX SECURITY MODULE (LSM) FRAMEWORK
P: Chris Wright
^ permalink raw reply related
* [PATCH] [43/2many] MAINTAINERS - AOA (Apple Onboard Audio) ALSA DRIVER
From: joe @ 2007-08-13 6:22 UTC (permalink / raw)
To: torvalds, linuxppc-dev, linux-kernel, johannes, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index e2e88f3..016f342 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -420,6 +420,7 @@ M: johannes@sipsolutions.net
L: linuxppc-dev@ozlabs.org
L: alsa-devel@alsa-project.org (subscribers-only)
S: Maintained
+F: sound/oao/
APM DRIVER
P: Stephen Rothwell
^ permalink raw reply related
* [PATCH] [296/2many] MAINTAINERS - LINUX FOR POWERPC PA SEMI PWRFICIENT
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, olof, linuxppc-dev, linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index a289176..6fdca8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2837,6 +2837,7 @@ M: olof@lixom.net
W: http://www.pasemi.com/
L: linuxppc-dev@ozlabs.org
S: Supported
+F: arch/powerpc/platforms/pasemi/
LLC (802.2)
P: Arnaldo Carvalho de Melo
^ permalink raw reply related
* [PATCH] [291/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED MPC52XX
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, tnt, linuxppc-embedded, linuxppc-dev, linux-kernel,
akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 8282088..0862965 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2795,6 +2795,8 @@ W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
L: linuxppc-embedded@ozlabs.org
S: Maintained
+F: arch/powerpc/platforms/52xx/
+F: include/asm-powerpc/mpc52xx.h
LINUX FOR POWERPC EMBEDDED PPC4XX
P: Matt Porter
^ permalink raw reply related
* [PATCH] [290/2many] MAINTAINERS - LINUX FOR POWER MACINTOSH
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, linuxppc-dev, linux-kernel, benh, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 1d1da70..8282088 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2784,6 +2784,8 @@ M: benh@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
S: Maintained
+F: arch/powerpc/platforms/powermac
+F: include/asm-powerpc/pmac_*
LINUX FOR POWERPC EMBEDDED MPC52XX
P: Sylvain Munaut
^ permalink raw reply related
* [PATCH] [289/2many] MAINTAINERS - LINUX FOR POWERPC
From: joe @ 2007-08-13 6:31 UTC (permalink / raw)
To: torvalds, paulus, linuxppc-dev, linux-kernel, akpm
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index c643ebe..1d1da70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2775,6 +2775,8 @@ W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
S: Supported
+F: arch/powerpc
+F: include/asm-powerpc/
LINUX FOR POWER MACINTOSH
P: Benjamin Herrenschmidt
^ permalink raw reply related
* Re: DTC 1.0.0 Release Coming?
From: Stephen Rothwell @ 2007-08-13 1:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Loeliger, Paul Mackerras, Jon
In-Reply-To: <20070812092627.GB6803@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Sun, 12 Aug 2007 19:26:27 +1000 David Gibson <dwg@au1.ibm.com> wrote:
>
> On Fri, Aug 10, 2007 at 06:35:46PM -0700, Geoff Levand wrote:
> >
> > We could also ship a generated .S file (dtc -O asm -o ps3-dt.S
> > ps3.dts), which would be easier to maintain in the source tree than a
> > binary file, then use something like this in the wrapper script:
> >
> > ${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S
> > ${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb
> >
> > Untested, but it seems like it would work.
>
> Yes, I'm aware of that option and am considering it.
Seems like a better option than a binary blob ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: David Gibson @ 2007-08-12 9:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <18109.2103.507694.281225@cargo.ozlabs.ibm.com>
On Sat, Aug 11, 2007 at 10:52:07AM +1000, Paul Mackerras wrote:
> David Gibson writes:
>
> > We decided that since a formal dtc release was imminent, it would be
> > simpler to make dtc a new kernel build requirement, rather than
> > integrate the substantial blob of dtc code into the kernel tree and
> > then have to deal with the maintenance / synchronization issues
> > between the in-kernel and upstream versions.
>
> Um, what I thought we decided was to ship a pre-built .dtb for ps3
> (once its dts settles down), and make dtc a kernel build requirement
> only for embedded platforms.
Oh, yes, sorry forgot that detail.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox