46dcfc8 (ARM: Update mach-types) removes used machine types
Subsystems (3)
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
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
Quoted 7 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
(quoted diff) +0
-2-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821
Quoted 6 lines
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.
Quoted 19 lines · Russell King - ARM Linux
Quoted 7 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
(quoted diff) +0
-2-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821Quoted 6 lines
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.
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. 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
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
Quoted 20 lines · Uwe Kleine-K?nig
Quoted 19 lines · Russell King - ARM Linux
Quoted 7 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
(quoted diff) +0
-2-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. 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
Quoted 3 lines
Best regards
Uwe
Quoted 24 lines · Marek Vasut
Quoted 23 lines · Uwe Kleine-K?nig
Quoted 21 lines · Russell King - ARM Linux
Quoted 7 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
(quoted diff) +0
-2-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821Quoted 6 lines
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 theMACH_xxxparts. If they don't, they will not exist in future updates.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 30 lines · Russell King - ARM Linux
Quoted 29 lines · Marek Vasut
Quoted 28 lines · Uwe Kleine-K?nig
Quoted 18 lines · Russell King - ARM Linux
Quoted 9 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd
MACH_EUKREA_CPUIMX25EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sdMACH_EUKREA_CPUIMX35EUKREA_CPUIMX352821Quoted 7 lines
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?!
Quoted 6 lines
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 theMACH_xxxparts. If they don't, they will not exist in future updates.Ah, I wasn't aware of that requirement.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 35 lines · Marek Vasut
Quoted 34 lines · Russell King - ARM Linux
Quoted 33 lines · Marek Vasut
Quoted 23 lines · Uwe Kleine-K?nig
Quoted 22 lines · Russell King - ARM Linux
Quoted 9 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd
MACH_EUKREA_CPUIMX25EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sdMACH_EUKREA_CPUIMX35EUKREA_CPUIMX352821Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. 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,
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 39 lines · Russell King - ARM Linux
Quoted 38 lines · Marek Vasut
Quoted 37 lines · Russell King - ARM Linux
Quoted 35 lines · Marek Vasut
Quoted 23 lines · Uwe Kleine-K?nig
Quoted 22 lines · Russell King - ARM Linux
Quoted 9 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd
MACH_EUKREA_CPUIMX25EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sdMACH_EUKREA_CPUIMX35EUKREA_CPUIMX352821Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. 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?
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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.
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee07d.en.html
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Russell King - ARM Linux
Quoted 4 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
Quoted 2 lines · Marek Vasut
Quoted 1 line · Uwe Kleine-K?nig
On Mon, Aug 22, 2011 at 09:17:49AM +0100, Russell King - ARM Linux
Quoted 42 lines · wrote:
Quoted 42 lines
Quoted 41 lines
Quoted 32 lines
Quoted 32 lines
Quoted 31 lines
Quoted 19 lines · Uwe Kleine-K?nig
Quoted 10 lines
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd
MACH_EUKREA_CPUIMX25EUKREA_CPUIMX252820 -eukrea_cpuimx35sdMACH_EUKREA_CPUIMX35EUKREA_CPUIMX352821Quoted 7 lines
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?!Quoted 7 lines
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 theMACH_xxxparts. 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?
Quoted 6 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee07d.en.ht
ml
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
Quoted 5 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee07d.en.ht
ml
Quoted 7 lines
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.
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee07d.e
n.ht mlRussell, calm down please.
Quoted 8 lines
Quoted 5 lines
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 6 lines
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 ?
Quoted 11 lines
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.
Quoted 21 lines · Marek Vasut
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee07d.e
n.ht mlRussell, calm down please.
Quoted 8 lines
Quoted 5 lines
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 1 line
Quoted 7 lines
Quoted 5 lines
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.
Quoted 27 lines · Russell King - ARM Linux
Quoted 26 lines · Marek Vasut
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee0
7d.e n.ht mlRussell, calm down please.
Quoted 8 lines
Quoted 5 lines
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 5 lines
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*.
Quoted 3 lines
Quoted 1 line
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?
Quoted 28 lines · Marek Vasut
Quoted 27 lines · Russell King - ARM Linux
Quoted 26 lines · Marek Vasut
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee0
7d.e n.ht mlRussell, calm down please.
Quoted 8 lines
Quoted 5 lines
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 5 lines
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*.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 38 lines · Russell King - ARM Linux
Quoted 28 lines · Marek Vasut
Quoted 27 lines · Russell King - ARM Linux
Quoted 26 lines · Marek Vasut
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Marek Vasut
Quoted 3 lines · Russell King - ARM Linux
For further reading, see:
http://lists.arm.linux.org.uk/lurker/message/20110815.085325.ae6ee0
7d.e n.ht mlRussell, calm down please.
Quoted 8 lines
Quoted 5 lines
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 5 lines
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*.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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?
Quoted 8 lines
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 orMACH_TYPEsymbol.
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"?
Quoted 22 lines
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
_ontheirpart_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
Hi Russell,
Le 22/08/2011 14:56, Russell King - ARM Linux a ?crit :
Quoted 39 lines · Marek Vasut
Quoted 38 lines · Russell King - ARM Linux
Quoted 37 lines · Marek Vasut
Quoted 35 lines · Uwe Kleine-K?nig
Quoted 23 lines · Russell King - ARM Linux
Quoted 22 lines · Uwe Kleine-K?nig
Quoted 9 lines
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
-eukrea_cpuimx25sd
MACH_EUKREA_CPUIMX25EUKREA_CPUIMX25
2820 -eukrea_cpuimx35sdMACH_EUKREA_CPUIMX35EUKREA_CPUIMX352821Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. 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?
Quoted 9 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 2 lines · Eric B?nard
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.
PATCH 1/1 cpuimx* boards: fix mach-types errors
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.
--- 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(-)
arch/arm/mach-imx/mach-cpuimx27.c +1 -1
@@ -310,7 +310,7 @@ static struct sys_timer eukrea_cpuimx27_timer = { .init = eukrea_cpuimx27_timer_init, }; -MACHINE_START (CPUIMX27 ,"EUKREA CPUIMX27" ) +MACHINE_START (EUKREA_CPUIMX27 ,"EUKREA CPUIMX27" ) .boot_params = MX27_PHYS_OFFSET + 0x100, .map_io = mx27_map_io, .init_early = imx27_init_early,
arch/arm/mach-imx/mach-cpuimx35.c +1 -1
@@ -192,7 +192,7 @@ struct sys_timer eukrea_cpuimx35_timer = { .init = eukrea_cpuimx35_timer_init, }; -MACHINE_START (EUKREA_CPUIMX35 ,"Eukrea CPUIMX35" ) +MACHINE_START (EUKREA_CPUIMX35SD ,"Eukrea CPUIMX35" )/* Maintainer: Eukrea Electromatique */ .boot_params = MX3x_PHYS_OFFSET + 0x100, .map_io = mx35_map_io,
arch/arm/mach-imx/mach-eukrea_cpuimx25.c +1 -1
@@ -161,7 +161,7 @@ static struct sys_timer eukrea_cpuimx25_timer = { .init = eukrea_cpuimx25_timer_init, }; -MACHINE_START (EUKREA_CPUIMX25 ,"Eukrea CPUIMX25" ) +MACHINE_START (EUKREA_CPUIMX25SD ,"Eukrea CPUIMX25" )/* Maintainer: Eukrea Electromatique */ .boot_params = MX25_PHYS_OFFSET + 0x100, .map_io = mx25_map_io,
arch/arm/tools/mach-types +3 -3
@@ -351,7 +351,7 @@ centro MACH_CENTRO CENTRO 1944 nokia_rx51 MACH_NOKIA_RX51 NOKIA_RX51 1955 omap_zoom2 MACH_OMAP_ZOOM2 OMAP_ZOOM2 1967 cpuat9260 MACH_CPUAT9260 CPUAT9260 1973 -eukrea_cpuimx27 MACH_CPUIMX27 CPUIMX27 1975 +eukrea_cpuimx27 MACH_EUKREA_CPUIMX27 EUKREA_CPUIMX27 1975 acs5k MACH_ACS5K ACS5K 1982 snapper_9260 MACH_SNAPPER_9260 SNAPPER_9260 1987 dsm320 MACH_DSM320 DSM320 1988
@@ -476,8 +476,8 @@ cns3420vb MACH_CNS3420VB CNS3420VB 2776 omap4_panda MACH_OMAP4_PANDA OMAP4_PANDA 2791 ti8168evm MACH_TI8168EVM TI8168EVM 2800 teton_bga MACH_TETON_BGA TETON_BGA 2816 -eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821 +eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25SD EUKREA_CPUIMX25SD 2820 +eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35SD EUKREA_CPUIMX35SD 2821 eukrea_cpuimx51sd MACH_EUKREA_CPUIMX51SD EUKREA_CPUIMX51SD 2822 eukrea_cpuimx51 MACH_EUKREA_CPUIMX51 EUKREA_CPUIMX51 2823 smdkc210 MACH_SMDKC210 SMDKC210 2838
Signature · 1 line
1.7.6
PATCH 1/1 cpuimx* boards: fix mach-types errors
Quoted 3 lines · Eric B?nard
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.
PATCH 1/1 cpuimx* boards: fix mach-types errors
Le 22/08/2011 16:37, Russell King - ARM Linux a ?crit :
Quoted 7 lines · Eric B?nard
Quoted 3 lines
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?
submitted as patch 7051/1
Thanks,
Eric
Quoted 27 lines · Russell King - ARM Linux
Quoted 26 lines · Marek Vasut
Quoted 25 lines · Uwe Kleine-K?nig
Quoted 19 lines · Russell King - ARM Linux
Quoted 7 lines · Uwe Kleine-K?nig
Hello Russell,
your commit 46dcfc8 that is in today's next among other changes does:
(quoted diff) +0
-2-eukrea_cpuimx25sd MACH_EUKREA_CPUIMX25 EUKREA_CPUIMX25 2820 -eukrea_cpuimx35sd MACH_EUKREA_CPUIMX35 EUKREA_CPUIMX35 2821Quoted 6 lines
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.
Quoted 2 lines
The requirement is that the
machine_is_xxx()must match theMACH_xxxparts. If they don't, they will not exist in future updates.Ah, I wasn't aware of that requirement.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.