From: Wolfram Sang <hidden> Date: 2011-10-08 19:26:21
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
Signed-off-by: Gwenhael Goavec-Merou <redacted>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
Regards,
Wolfram
--
1.7.3.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
1.7.3.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux <hidden> Date: 2011-10-08 22:07:22
On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
quoted
Signed-off-by: Gwenhael Goavec-Merou <redacted>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
The thing is - read the comments at the top of the file. There's hints
there as to what will happen if you patch the file. The hint is
'automatically generated'. So when I next update the file, any patches
done to the file will be wiped out.
Hi,
On Sat, 8 Oct 2011 21:27:30 +0200
Wolfram Sang [off-list ref] wrote:
On Sat, Oct 08, 2011 at 05:19:49PM +0200, Gwenhael Goavec-Merou wrote:
quoted
Signed-off-by: Gwenhael Goavec-Merou <redacted>
Out of curiosity, no devices on the bus?
Devices present on this modules's I2C bus don't have mailined kernel drivers or
don't need one (in that case /dev/i2c-xx is used). This module can be plugged
on a baseboard adding some stuff on I2C but this will be part of another patch
adding the baseboard description.
Gwenhael
Other than that, looks OK to me:
Acked-by: Wolfram Sang <redacted>
--
1.7.3.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Oct 08, 2011 at 11:07:22PM +0100, Russell King - ARM Linux wrote:
On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
quoted
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
quoted
Signed-off-by: Gwenhael Goavec-Merou <redacted>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
The thing is - read the comments at the top of the file. There's hints
there as to what will happen if you patch the file. The hint is
'automatically generated'. So when I next update the file, any patches
done to the file will be wiped out.
Currently the id is still missing in your for-next branch and it is
marked as "mainlined" on http://www.arm.linux.org.uk/developer/machines/
(906).
That means that the next update should include the id, right? Maybe it's
worth to add it already earlier with the patch Gwenhael proposed as
without it mx1_defconfig is broken. After f32609c5a035 it even breaks
imx_v4_v5_defconfig.
BTW is there a way to see the mach-types file as it would land in
linux.git if it were updated now?
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-10-13 09:59:15
On Thu, Oct 13, 2011 at 11:06:09AM +0200, Uwe Kleine-K?nig wrote:
On Sat, Oct 08, 2011 at 11:07:22PM +0100, Russell King - ARM Linux wrote:
quoted
On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
quoted
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
quoted
Signed-off-by: Gwenhael Goavec-Merou <redacted>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
The thing is - read the comments at the top of the file. There's hints
there as to what will happen if you patch the file. The hint is
'automatically generated'. So when I next update the file, any patches
done to the file will be wiped out.
Currently the id is still missing in your for-next branch and it is
marked as "mainlined" on http://www.arm.linux.org.uk/developer/machines/
(906).
That means that the next update should include the id, right?
Not if it's a buggered entry - which it doesn't appear to be. The problem
is that now that I've stopped manually editing out the buggered entries,
favouring doing it automatically, any update to the file ends up breaking
the damned thing for someone.
It's rather too late in the cycle for me to commit an update now - I
suspect doing so will upset a lot of people.
From: Russell King - ARM Linux <hidden> Date: 2011-10-17 08:44:21
On Thu, Oct 13, 2011 at 11:06:09AM +0200, Uwe Kleine-K?nig wrote:
On Sat, Oct 08, 2011 at 11:07:22PM +0100, Russell King - ARM Linux wrote:
quoted
On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
quoted
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
quoted
Signed-off-by: Gwenhael Goavec-Merou <redacted>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
The thing is - read the comments at the top of the file. There's hints
there as to what will happen if you patch the file. The hint is
'automatically generated'. So when I next update the file, any patches
done to the file will be wiped out.
Currently the id is still missing in your for-next branch and it is
marked as "mainlined" on http://www.arm.linux.org.uk/developer/machines/
(906).
That means that the next update should include the id, right? Maybe it's
worth to add it already earlier with the patch Gwenhael proposed as
without it mx1_defconfig is broken. After f32609c5a035 it even breaks
imx_v4_v5_defconfig.
BTW is there a way to see the mach-types file as it would land in
linux.git if it were updated now?
http://www.arm.linux.org.uk/developer/machines/download.php?q=1
will be the exact file if I were to update it right now (that's the
URL it's retrieved from.)
One of the problems we now have is that I no longer have visibility
of platforms going into mainline (I only find out after they've been
merged into mainline), so I've no way to update the database with
that information before I do an update - my information will be up
to three months out of date. This in turn means that the 12 month
grace period can expire and the entries deleted from the merged file
_after_ they've been merged and queued up elsewhere.
As I've already said, this has now become one very big unmanagable
problem. It needs someone to spend a lot of time at each update
manually verifying every addition and removal (and kicking those
people who botch their entries up - which given my interpretation of
the data protection act means it can only be me).
I haven't committed an update since August, and at this point in the
cycle, I'm not going to before this merge window - the risks of breaking
something already merged or queued up are just too great to consider
doing so now.
Longer term, I don't have an answer to this problem - I don't think
there is a workable answer to a distributed development model with
a centralized ID database with a grace period on 'unused' entries.
From: Russell King - ARM Linux <hidden> Date: 2011-10-17 09:17:49
On Mon, Oct 17, 2011 at 09:44:21AM +0100, Russell King - ARM Linux wrote:
http://www.arm.linux.org.uk/developer/machines/download.php?q=1
will be the exact file if I were to update it right now (that's the
URL it's retrieved from.)
One of the problems we now have is that I no longer have visibility
of platforms going into mainline (I only find out after they've been
merged into mainline), so I've no way to update the database with
that information before I do an update - my information will be up
to three months out of date. This in turn means that the 12 month
grace period can expire and the entries deleted from the merged file
_after_ they've been merged and queued up elsewhere.
As I've already said, this has now become one very big unmanagable
problem. It needs someone to spend a lot of time at each update
manually verifying every addition and removal (and kicking those
people who botch their entries up - which given my interpretation of
the data protection act means it can only be me).
I haven't committed an update since August, and at this point in the
cycle, I'm not going to before this merge window - the risks of breaking
something already merged or queued up are just too great to consider
doing so now.
Longer term, I don't have an answer to this problem - I don't think
there is a workable answer to a distributed development model with
a centralized ID database with a grace period on 'unused' entries.
And while we're discussing this issue...
+v7pxa_dt MACH_V7PXA_DT V7PXA_DT 3794
+v7mmp_dt MACH_V7MMP_DT V7MMP_DT 3795
Why do we have DT-based IDs being registered? DT does not use machine
IDs in any shape or form. For DT platforms, machine_is_xxx() must not
be used because it's meaningless.
#define DT_MACHINE_START(_name, _namestr) \
static const struct machine_desc __mach_desc_##_name \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = ~0, \
.name = _namestr,
Note the .nr = ~0 there.
-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
ARM Linux
Sent: Monday, October 17, 2011 2:14 PM
To: Uwe Kleine-K?nig
Cc: Sascha Hauer; Wolfram Sang; linux-arm-
kernel at lists.infradead.org; Gwenhael Goavec-Merou
Subject: Re: [PATCH 1/2] [ARM] mach-types: Re-add apf9328
[...]
quoted
BTW is there a way to see the mach-types file as it would land in
linux.git if it were updated now?
I had registered a new mach-id for Texas Instruments' AM335X processor
http://www.arm.linux.org.uk/developer/machines/list.php?id=3589
I had given the machine name as " TI AM335 EVM", the machine type as "am335xevm"
and the directory suffix as "omap".
The type macro (machine_is_am335xevm()) and the Kconfig macro (CONFIG_MACH_AM335XEVM) are correct.
But the machine type variable for this is showing up as incorrect.
Instead of MACH_TYPE_AM335XEVM it is shown as MACH_TYPE_AM355XEVM.
^^ ^^
Since the machine type variable is auto-generated can you please tell me what could have gone wrong and how to fix it?
Regards,
Vaibhav
From: Russell King - ARM Linux <hidden> Date: 2011-10-21 18:03:47
On Fri, Oct 21, 2011 at 03:40:21PM +0530, Bedia, Vaibhav wrote:
I had registered a new mach-id for Texas Instruments' AM335X processor
http://www.arm.linux.org.uk/developer/machines/list.php?id=3589
I had given the machine name as " TI AM335 EVM", the machine type as
"am335xevm" and the directory suffix as "omap".
The type macro (machine_is_am335xevm()) and the Kconfig macro
(CONFIG_MACH_AM335XEVM) are correct. But the machine type variable for
this is showing up as incorrect.
Instead of MACH_TYPE_AM335XEVM it is shown as MACH_TYPE_AM355XEVM.
^^ ^^
No idea - it is generated by a script and I'd be very surprised if the
script knew enough about this stuff to perturb it in that way.
Since the machine type variable is auto-generated can you please tell
me what could have gone wrong and how to fix it?
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, October 21, 2011 11:34 PM
To: Bedia, Vaibhav
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 1/2] [ARM] mach-types: Re-add apf9328
I've just fixed it.
From: Russell King - ARM Linux <hidden> Date: 2011-10-25 11:47:22
On Tue, Oct 25, 2011 at 11:36:04AM +0200, gwenhael.goavec wrote:
ping
This is what your email headers are saying:
From: "gwenhael.goavec" <redacted>
Cc: "gwenhael.goavec" <redacted>,
linux-arm-kernel at lists.infradead.org,
Sascha Hauer [off-list ref],
Uwe Kleine-K_nig [off-list ref],
Russell King - ARM Linux [off-list ref]
There is no to: header, so I've no idea _who_ you're expecting to respond
in a meaningful way to your ping. As this is an imx patch, I assume
Sascha.