Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the other
deletions?!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 08:17:49
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the other
deletions?!
No. They're removed because they're broken (look at them) - I've added
additional checks so I don't have to waste _significant_ time fixing
the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the other
deletions?!
No. They're removed because they're broken (look at them) - I've added
additional checks so I don't have to waste _significant_ time fixing
the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
From: Marek Vasut <hidden> Date: 2011-08-22 11:18:25
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've added
additional checks so I don't have to waste _significant_ time fixing
the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the machine
so they can come up with fix?
Cheers
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 12:49:30
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've added
additional checks so I don't have to waste _significant_ time fixing
the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the machine
so they can come up with fix?
From: Marek Vasut <hidden> Date: 2011-08-22 12:54:55
On Monday, August 22, 2011 02:49:30 PM Russell King - ARM Linux wrote:
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes
does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35
EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are
actually used
(arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've
added additional checks so I don't have to waste _significant_ time
fixing the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the
machine so they can come up with fix?
I've no idea which get killed off, sorry.
This EUKREA thing from what I understood was removed from the machine database
and broke things.
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 12:55:41
On Mon, Aug 22, 2011 at 01:49:30PM +0100, Russell King - ARM Linux wrote:
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820
-eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are actually
used (arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've added
additional checks so I don't have to waste _significant_ time fixing
the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the machine
so they can come up with fix?
I've no idea which get killed off, sorry.
... and how about people *TALK* to me when they fuck up their entries in
the machine database.
TBH, the way I feel _right_ _now_ over it is that people who don't get
what they deserve, and their stuff breaks. Again, my perspective is
that that is their own fault, and they will have to live with it.
Given all this whinging - first about people throwing stuff into the
kernel without the corresponding stuff in the mach-types file first, and
now this, I'm *seriously* considering killing the damned thing off
completely and not doing any further updates to the file anymore. It's
just *far* too much hastle to deal with given all the absolute shite
that's now there.
And if I'm not allowed to sort it out in an automated way then I'm
just going to give up with it and shut the entire thing down.
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 12:56:53
On Mon, Aug 22, 2011 at 02:54:55PM +0200, Marek Vasut wrote:
On Monday, August 22, 2011 02:49:30 PM Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes
does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35
EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are
actually used
(arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've
added additional checks so I don't have to waste _significant_ time
fixing the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the
machine so they can come up with fix?
I've no idea which get killed off, sorry.
This EUKREA thing from what I understood was removed from the machine database
and broke things.
So? The entry was broken. The entry was changed after submission. There
was no communication with me to fix things up. Therefore I _do_ _not_
_care_ about it.
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 13:01:19
On Mon, Aug 22, 2011 at 01:56:53PM +0100, Russell King - ARM Linux wrote:
On Mon, Aug 22, 2011 at 02:54:55PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 02:49:30 PM Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes
does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35
EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are
actually used
(arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've
added additional checks so I don't have to waste _significant_ time
fixing the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the
machine so they can come up with fix?
I've no idea which get killed off, sorry.
This EUKREA thing from what I understood was removed from the machine database
and broke things.
So? The entry was broken. The entry was changed after submission. There
was no communication with me to fix things up. Therefore I _do_ _not_
_care_ about it.
From: Eric Bénard <hidden> Date: 2011-08-22 13:04:01
Hi Russell,
Le 22/08/2011 14:56, Russell King - ARM Linux a ?crit :
On Mon, Aug 22, 2011 at 02:54:55PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 02:49:30 PM Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes
does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35
EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are
actually used
(arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to double-check the
other deletions?!
No. They're removed because they're broken (look at them) - I've
added additional checks so I don't have to waste _significant_ time
fixing the entries time and time again.
The requirement is that the machine_is_xxx() must match the MACH_xxx
parts. If they don't, they will not exist in future updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off the
machine so they can come up with fix?
I've no idea which get killed off, sorry.
This EUKREA thing from what I understood was removed from the machine database
and broke things.
So? The entry was broken. The entry was changed after submission. There
was no communication with me to fix things up. Therefore I _do_ _not_
_care_ about it.
I did this mistake quite a long time ago just after submission.
I'll come back to you to fix this in a short time, sorry for the annoyance.
Thanks,
Eric
From: Marek Vasut <hidden> Date: 2011-08-22 13:16:00
On Monday, August 22, 2011 03:01:19 PM Russell King - ARM Linux wrote:
On Mon, Aug 22, 2011 at 01:56:53PM +0100, Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 02:54:55PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 02:49:30 PM Russell King - ARM Linux wrote:
quoted
On Mon, Aug 22, 2011 at 01:18:25PM +0200, Marek Vasut wrote:
quoted
On Monday, August 22, 2011 10:33:29 AM Uwe Kleine-K?nig wrote:
quoted
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux
wrote:
quoted
quoted
quoted
quoted
quoted
quoted
On Mon, Aug 22, 2011 at 10:10:00AM +0200, Uwe Kleine-K?nig wrote:
quoted
Hello Russell,
your commit 46dcfc8 that is in today's next among other
changes does:
-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25
EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd
MACH_EUKREA_CPUIMX35
EUKREA_CPUIMX35 2821
These two are both marked as "mainlined" on
http://www.arm.linux.org.uk/developer/machines/ and both are
actually used
(arch/arm/mach-imx/mach-{eukrea_cpuimx25,cpuimx35.c})
Can you please add them back? Maybe it's worth to
double-check the other deletions?!
No. They're removed because they're broken (look at them) -
I've added additional checks so I don't have to waste
_significant_ time fixing the entries time and time again.
The requirement is that the machine_is_xxx() must match the
MACH_xxx parts. If they don't, they will not exist in future
updates.
Ah, I wasn't aware of that requirement.
Eric, these machine types are owned by you. Do you care to follow
up?
Hi Russell,
maybe it'd be worth at least pinging the people before you kill off
the machine so they can come up with fix?
I've no idea which get killed off, sorry.
This EUKREA thing from what I understood was removed from the machine
database and broke things.
So? The entry was broken. The entry was changed after submission.
There was no communication with me to fix things up. Therefore I _do_
_not_ _care_ about it.
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then wait ... if
they don't reply in a week (two weeks?) then remove their stuff. And make that a
policy.
What do you think ?
Cheers
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? Which entries are causing problems? That's the whole
bloody point.
There's just far too much of it. The amount of effort required to sort
through this file each time it needs to be updated has become *excessive*.
The amount of effort required to go through the file and identify which
entries are broken is *excessive*. The amount of effort required to
find who to email is *excessive*.
I don't have a few days to do that - and I'm not going to repeat it
every time the file needs to be updated anymore.
So either I drop the change and we go back to having gplugd broken, or
we keep the change and have the Eureka stuff broken. Anything else is
far too much hastle.
Given that the gplugd folk have sorted out their problems, and its the
Eureka stuff which doesn't conform, I'd rather that Eureka was broken
rather than gplugd.
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? Which entries are causing problems? That's the whole
bloody point.
Isn't the email in your database? You can't just script that ?
There's just far too much of it. The amount of effort required to sort
through this file each time it needs to be updated has become *excessive*.
The amount of effort required to go through the file and identify which
entries are broken is *excessive*. The amount of effort required to
find who to email is *excessive*.
Why not write a script for that ?
I don't have a few days to do that - and I'm not going to repeat it
every time the file needs to be updated anymore.
So either I drop the change and we go back to having gplugd broken, or
we keep the change and have the Eureka stuff broken. Anything else is
far too much hastle.
Given that the gplugd folk have sorted out their problems, and its the
Eureka stuff which doesn't conform, I'd rather that Eureka was broken
rather than gplugd.
Well then can't you split the change in two to avoid breaking both? We don't
want to introduce breakage, do we.
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? Which entries are causing problems? That's the whole
bloody point.
Isn't the email in your database? You can't just script that ?
quoted
There's just far too much of it. The amount of effort required to sort
through this file each time it needs to be updated has become *excessive*.
The amount of effort required to go through the file and identify which
entries are broken is *excessive*. The amount of effort required to
find who to email is *excessive*.
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? Which entries are causing problems? That's the whole
bloody point.
Isn't the email in your database? You can't just script that ?
quoted
There's just far too much of it. The amount of effort required to sort
through this file each time it needs to be updated has become
*excessive*. The amount of effort required to go through the file and
identify which entries are broken is *excessive*. The amount of
effort required to find who to email is *excessive*.
Why not write a script for that ?
No, I don't have the time at present.
You're the head maintainer here and ARM is a rising architecture. If you can't
cope with that, you have a growing community of very competent people here.
Maybe someone will be willing to take over eventually? It'll relieve some
pressure from you too, what do you think?
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? Which entries are causing problems? That's the whole
bloody point.
Isn't the email in your database? You can't just script that ?
quoted
There's just far too much of it. The amount of effort required to sort
through this file each time it needs to be updated has become
*excessive*. The amount of effort required to go through the file and
identify which entries are broken is *excessive*. The amount of
effort required to find who to email is *excessive*.
Why not write a script for that ?
No, I don't have the time at present.
You're the head maintainer here and ARM is a rising architecture. If you can't
cope with that, you have a growing community of very competent people here.
Maybe someone will be willing to take over eventually? It'll relieve some
pressure from you too, what do you think?
Hello. Do you even understand the issue you're talking about?
There is a problem _right_ _now_ with the mach-types file.
That problem was caused by gplugd being merged without its entry being in
the mach-types file - which was omitted - by way of editing by hand, along
with shit loads of other entries - because of the fuckup with the
machine_is_xxx() name not matching the configuration or MACH_TYPE symbol.
So, rather than wasting a *significant* amount of time hand editing the
file at every update (which is precisely why I haven't been updating the
bloody thing) I've built it into the script so that entries which do not
conform are automatically omitted.
Problem solved.
Any remaining problems are down to the maintainers not talking to me and,
if you haven't realised yet, I have _zero_ sympathy for that especially
when it doesn't take much effort _on their part_ to do.
It's got nothing to do with ARM being a rising architecture. It's about
maintainers doing the right thing, behaving in the right way and taking
responsibility for their fuckups. Putting the pain where the pain should
be - in the platform maintainers lap, not in my lap.
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 13:55:41
On Mon, Aug 22, 2011 at 03:04:01PM +0200, Eric B?nard wrote:
I did this mistake quite a long time ago just after submission.
I'll come back to you to fix this in a short time, sorry for the annoyance.
If you can sort out a fix to rename the constants against current
-rc, I'll slip it in before the commit which should fix the problem
transparently. I'll have to update the database via SQL though...
what joy.
Russell, calm down please.
Maybe it'd be better to just email the people with broken stuff, then
wait ... if they don't reply in a week (two weeks?) then remove their
stuff. And make that a policy.
What do you think ?
Who do I email? ?Which entries are causing problems? ?That's the whole
bloody point.
Isn't the email in your database? You can't just script that ?
quoted
There's just far too much of it. ?The amount of effort required to sort
through this file each time it needs to be updated has become
*excessive*. The amount of effort required to go through the file and
identify which entries are broken is *excessive*. ?The amount of
effort required to find who to email is *excessive*.
Why not write a script for that ?
No, I don't have the time at present.
You're the head maintainer here and ARM is a rising architecture. If you can't
cope with that, you have a growing community of very competent people here.
Maybe someone will be willing to take over eventually? It'll relieve some
pressure from you too, what do you think?
Hello. ?Do you even understand the issue you're talking about?
There is a problem _right_ _now_ with the mach-types file.
That problem was caused by gplugd being merged without its entry being in
the mach-types file - which was omitted - by way of editing by hand, along
with shit loads of other entries - because of the fuckup with the
machine_is_xxx() name not matching the configuration or MACH_TYPE symbol.
Grrrr.... as the original guilty one who stirred this whole pile of
sh*t up, should
I keep my mouth shut up on this? ;-)
True that it's a stupid mistake for code to use non-matched machine entries
and it's fair to simply remove them.
Yet I guess what us sub-maintainers would like to know is the correct way
to amend this (after the incorrect entry being removed), and to better help
with "getting it right"?
So, rather than wasting a *significant* amount of time hand editing the
file at every update (which is precisely why I haven't been updating the
bloody thing) I've built it into the script so that entries which do not
conform are automatically omitted.
Problem solved.
Any remaining problems are down to the maintainers not talking to me and,
if you haven't realised yet, I have _zero_ sympathy for that especially
when it doesn't take much effort _on their part_ to do.
It's got nothing to do with ARM being a rising architecture. ?It's about
maintainers doing the right thing, behaving in the right way and taking
responsibility for their fuckups. ?Putting the pain where the pain should
be - in the platform maintainers lap, not in my lap.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Eric Bénard <hidden> Date: 2011-08-22 14:19:53
I made some changes to the entry in the ARM Machine Registry after
submission which was the wrong thing to do.
This patch should help to fix this error.
Signed-off-by: Eric B?nard <redacted>
---
arch/arm/mach-imx/mach-cpuimx27.c | 2 +-
arch/arm/mach-imx/mach-cpuimx35.c | 2 +-
arch/arm/mach-imx/mach-eukrea_cpuimx25.c | 2 +-
arch/arm/tools/mach-types | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2011-08-22 14:37:01
On Mon, Aug 22, 2011 at 04:19:53PM +0200, Eric B?nard wrote:
I made some changes to the entry in the ARM Machine Registry after
submission which was the wrong thing to do.
This patch should help to fix this error.
Looks fine. Could you throw it in the patch system please?
Thanks.
From: Eric Bénard <hidden> Date: 2011-08-22 14:43:24
Le 22/08/2011 16:37, Russell King - ARM Linux a ?crit :
On Mon, Aug 22, 2011 at 04:19:53PM +0200, Eric B?nard wrote:
quoted
I made some changes to the entry in the ARM Machine Registry after
submission which was the wrong thing to do.
This patch should help to fix this error.
Looks fine. Could you throw it in the patch system please?