* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
@ 2011-09-15 14:50 ` Jean-Christophe PLAGNIOL-VILLARD
2011-09-16 7:31 ` Russell King - ARM Linux
2011-09-15 15:26 ` Arnd Bergmann
` (4 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-15 14:50 UTC (permalink / raw)
To: linux-arm-kernel
On 11:25 Thu 15 Sep , Russell King - ARM Linux wrote:
> I'm going to be merging a mach-types update (the cut-down and the
> policy-conforming version) for the next merge window. This will mean
> that things WILL BREAK, and I will not notice that things have broken.
>
> In order to fix this, entries need to be fixed to conform to the
> requirements - where the machine_is_xxx() name is the same as the
> MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
>
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means is that it
> is _important_ to get the core platform support in _first_ before any
> drivers which may make use of this.
>
> The following will be deleted from the file this time around are:
> -ts_x09 MACH_TS209 TS209 1565
> -at572d940hfek MACH_AT572D940HFEB AT572D940HFEB 1783
can be dropped the at572d940hfek as the at572d940hf is drop from mainline
Russell an you confirm you will re-add the usb-a9g20 and the folowing one
usb_a9g20 MACH_USB_A9G20 USB_A9G20 1841
qil_a9g20 MACH_QIL_A9G20 QIL_A9G20 1844
tny_a9260 MACH_TNY_A9260 TNY_A9260 2058
tny_a9g20 MACH_TNY_A9G20 TNY_A9G20 2059
tny_a9263 MACH_TNY_A9263 TNY_A9263 2140
I'm working on there port mainline
I add the usb_a9g20 recently and will continue in the following weeks
Best Regards,
J.
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-15 14:50 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-09-16 7:31 ` Russell King - ARM Linux
2011-09-17 2:51 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-16 7:31 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 04:50:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:25 Thu 15 Sep , Russell King - ARM Linux wrote:
> > I'm going to be merging a mach-types update (the cut-down and the
> > policy-conforming version) for the next merge window. This will mean
> > that things WILL BREAK, and I will not notice that things have broken.
> >
> > In order to fix this, entries need to be fixed to conform to the
> > requirements - where the machine_is_xxx() name is the same as the
> > MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
> >
> > Moreover, entries older than 12 months which have not been merged will
> > be removed. It is not possible to automatically check for machine_is_xxx()
> > usages as these could conflict with other architectures, and I'm
> > certainly NOT checking for them by hand (I estimate that'd take a
> > significant amount of manual effort to do.) What that means is that it
> > is _important_ to get the core platform support in _first_ before any
> > drivers which may make use of this.
> >
> > The following will be deleted from the file this time around are:
> > -ts_x09 MACH_TS209 TS209 1565
> > -at572d940hfek MACH_AT572D940HFEB AT572D940HFEB 1783
> can be dropped the at572d940hfek as the at572d940hf is drop from mainline
>
> Russell an you confirm you will re-add the usb-a9g20 and the folowing one
>
> usb_a9g20 MACH_USB_A9G20 USB_A9G20 1841
> qil_a9g20 MACH_QIL_A9G20 QIL_A9G20 1844
> tny_a9260 MACH_TNY_A9260 TNY_A9260 2058
> tny_a9g20 MACH_TNY_A9G20 TNY_A9G20 2059
> tny_a9263 MACH_TNY_A9263 TNY_A9263 2140
Here's the two relevent question:
1. have they been submitted or edited within the last 12 months? No.
2. are they merged into mainline? No.
So will they be in the update? No.
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-16 7:31 ` Russell King - ARM Linux
@ 2011-09-17 2:51 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 18+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-17 2:51 UTC (permalink / raw)
To: linux-arm-kernel
On 08:31 Fri 16 Sep , Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 04:50:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:25 Thu 15 Sep , Russell King - ARM Linux wrote:
> > > I'm going to be merging a mach-types update (the cut-down and the
> > > policy-conforming version) for the next merge window. This will mean
> > > that things WILL BREAK, and I will not notice that things have broken.
> > >
> > > In order to fix this, entries need to be fixed to conform to the
> > > requirements - where the machine_is_xxx() name is the same as the
> > > MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
> > >
> > > Moreover, entries older than 12 months which have not been merged will
> > > be removed. It is not possible to automatically check for machine_is_xxx()
> > > usages as these could conflict with other architectures, and I'm
> > > certainly NOT checking for them by hand (I estimate that'd take a
> > > significant amount of manual effort to do.) What that means is that it
> > > is _important_ to get the core platform support in _first_ before any
> > > drivers which may make use of this.
> > >
> > > The following will be deleted from the file this time around are:
> > > -ts_x09 MACH_TS209 TS209 1565
> > > -at572d940hfek MACH_AT572D940HFEB AT572D940HFEB 1783
> > can be dropped the at572d940hfek as the at572d940hf is drop from mainline
> >
> > Russell an you confirm you will re-add the usb-a9g20 and the folowing one
> >
> > usb_a9g20 MACH_USB_A9G20 USB_A9G20 1841
> > qil_a9g20 MACH_QIL_A9G20 QIL_A9G20 1844
> > tny_a9260 MACH_TNY_A9260 TNY_A9260 2058
> > tny_a9g20 MACH_TNY_A9G20 TNY_A9G20 2059
> > tny_a9263 MACH_TNY_A9263 TNY_A9263 2140
>
> Here's the two relevent question:
> 1. have they been submitted or edited within the last 12 months? No.
> 2. are they merged into mainline? No.
>
> So will they be in the update? No.
agreed but I've receive the hardware just recently so I add them one by one
the usb_a9g20 is the first and already in Arnd tree
so If you can re-add the otherone it will be nice
they will come soon
Best Regards,
J.
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
2011-09-15 14:50 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-09-15 15:26 ` Arnd Bergmann
2011-09-15 19:11 ` Russell King - ARM Linux
2011-09-15 18:05 ` Olof Johansson
` (3 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Arnd Bergmann @ 2011-09-15 15:26 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 15 September 2011, Russell King - ARM Linux wrote:
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means is that it
> is important to get the core platform support in first before any
> drivers which may make use of this.
Hi Russell,
I've just tried checking the machine_is_xxx() values in the kernel for
the list you posted and found just two that are actually being used:
arch/arm/mach-orion5x/ts209-setup.c: if (machine_is_ts_x09())
arch/arm/mach-kirkwood/sheevaplug-setup.c: if (machine_is_sheeva_esata())
Would it be possible to just fix these to use the correct form instead,
along with the respective mach-types change?
Arnd
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-15 15:26 ` Arnd Bergmann
@ 2011-09-15 19:11 ` Russell King - ARM Linux
2011-09-15 19:32 ` Nicolas Pitre
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 05:26:02PM +0200, Arnd Bergmann wrote:
> On Thursday 15 September 2011, Russell King - ARM Linux wrote:
> > Moreover, entries older than 12 months which have not been merged will
> > be removed. It is not possible to automatically check for machine_is_xxx()
> > usages as these could conflict with other architectures, and I'm
> > certainly NOT checking for them by hand (I estimate that'd take a
> > significant amount of manual effort to do.) What that means is that it
> > is important to get the core platform support in first before any
> > drivers which may make use of this.
>
> Hi Russell,
>
> I've just tried checking the machine_is_xxx() values in the kernel for
> the list you posted and found just two that are actually being used:
>
> arch/arm/mach-orion5x/ts209-setup.c: if (machine_is_ts_x09())
> arch/arm/mach-kirkwood/sheevaplug-setup.c: if (machine_is_sheeva_esata())
>
> Would it be possible to just fix these to use the correct form instead,
> along with the respective mach-types change?
That would of course be the preferred way, but I need to know which
way they're supposed to be - the current disagreement in the names
doesn't suggest which is the right one.
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-15 19:11 ` Russell King - ARM Linux
@ 2011-09-15 19:32 ` Nicolas Pitre
0 siblings, 0 replies; 18+ messages in thread
From: Nicolas Pitre @ 2011-09-15 19:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 15 Sep 2011, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 05:26:02PM +0200, Arnd Bergmann wrote:
> > On Thursday 15 September 2011, Russell King - ARM Linux wrote:
> > > Moreover, entries older than 12 months which have not been merged will
> > > be removed. It is not possible to automatically check for machine_is_xxx()
> > > usages as these could conflict with other architectures, and I'm
> > > certainly NOT checking for them by hand (I estimate that'd take a
> > > significant amount of manual effort to do.) What that means is that it
> > > is important to get the core platform support in first before any
> > > drivers which may make use of this.
> >
> > Hi Russell,
> >
> > I've just tried checking the machine_is_xxx() values in the kernel for
> > the list you posted and found just two that are actually being used:
> >
> > arch/arm/mach-orion5x/ts209-setup.c: if (machine_is_ts_x09())
> > arch/arm/mach-kirkwood/sheevaplug-setup.c: if (machine_is_sheeva_esata())
> >
> > Would it be possible to just fix these to use the correct form instead,
> > along with the respective mach-types change?
>
> That would of course be the preferred way, but I need to know which
> way they're supposed to be - the current disagreement in the names
> doesn't suggest which is the right one.
Here's what I'd suggest:
diff --git a/arch/arm/mach-kirkwood/sheevaplug-setup.c b/arch/arm/mach-kirkwood/sheevaplug-setup.c
index 17de0bf53c..d989c0d1f9 100644
--- a/arch/arm/mach-kirkwood/sheevaplug-setup.c
+++ b/arch/arm/mach-kirkwood/sheevaplug-setup.c
@@ -107,7 +107,7 @@ static void __init sheevaplug_init(void)
kirkwood_init();
/* setup gpio pin select */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_mpp_conf(sheeva_esata_mpp_config);
else
kirkwood_mpp_conf(sheevaplug_mpp_config);
@@ -123,11 +123,11 @@ static void __init sheevaplug_init(void)
kirkwood_ge00_init(&sheevaplug_ge00_data);
/* honor lower power consumption for plugs with out eSATA */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_sata_init(&sheeva_esata_sata_data);
/* enable sd wp and sd cd on plugs with esata */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_sdio_init(&sheeva_esata_mvsdio_data);
else
kirkwood_sdio_init(&sheevaplug_mvsdio_data);
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c9831614e3..8588c08bbd 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -179,7 +179,7 @@ static struct hw_pci qnap_ts209_pci __initdata = {
static int __init qnap_ts209_pci_init(void)
{
- if (machine_is_ts_x09())
+ if (machine_is_ts209())
pci_common_init(&qnap_ts209_pci);
return 0;
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index fff68d0d52..fae8c3b527 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -268,7 +268,7 @@ dns323 MACH_DNS323 DNS323 1542
omap3_beagle MACH_OMAP3_BEAGLE OMAP3_BEAGLE 1546
nokia_n810 MACH_NOKIA_N810 NOKIA_N810 1548
pcm038 MACH_PCM038 PCM038 1551
-ts_x09 MACH_TS209 TS209 1565
+ts209 MACH_TS209 TS209 1565
at91cap9adk MACH_AT91CAP9ADK AT91CAP9ADK 1566
mx31moboard MACH_MX31MOBOARD MX31MOBOARD 1574
terastation_pro2 MACH_TERASTATION_PRO2 TERASTATION_PRO2 1584
@@ -449,7 +449,7 @@ guruplug MACH_GURUPLUG GURUPLUG 2659
spear310 MACH_SPEAR310 SPEAR310 2660
spear320 MACH_SPEAR320 SPEAR320 2661
aquila MACH_AQUILA AQUILA 2676
-sheeva_esata MACH_ESATA_SHEEVAPLUG ESATA_SHEEVAPLUG 2678
+esata_sheevaplug MACH_ESATA_SHEEVAPLUG ESATA_SHEEVAPLUG 2678
msm7x30_surf MACH_MSM7X30_SURF MSM7X30_SURF 2679
ea2478devkit MACH_EA2478DEVKIT EA2478DEVKIT 2683
terastation_wxl MACH_TERASTATION_WXL TERASTATION_WXL 2697
Nicolas
^ permalink raw reply related [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
2011-09-15 14:50 ` Jean-Christophe PLAGNIOL-VILLARD
2011-09-15 15:26 ` Arnd Bergmann
@ 2011-09-15 18:05 ` Olof Johansson
2011-09-16 10:27 ` Richard Cochran
` (2 subsequent siblings)
5 siblings, 0 replies; 18+ messages in thread
From: Olof Johansson @ 2011-09-15 18:05 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 3:25 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> The following will be deleted from the machine database:
>
> ?tegra ? ? ? ? ? ? ? ? ? MACH_TEGRA ? ? ? ? ? ? ?TEGRA ? ? ? ? ? ? ? ? ? 3738
>
> as it doesn't conform to the policy of this being a _platform_ database
> not a _soc_ database.
Yes, please. It looks like it has been renamed 'peaboy' now but it
still seems bogus. Maybe 3739 is meant to supersede it.
-Olof
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
` (2 preceding siblings ...)
2011-09-15 18:05 ` Olof Johansson
@ 2011-09-16 10:27 ` Richard Cochran
2011-09-18 15:44 ` Arnd Bergmann
2011-09-17 14:28 ` Pedanekar, Hemant
2011-09-19 23:13 ` H Hartley Sweeten
5 siblings, 1 reply; 18+ messages in thread
From: Richard Cochran @ 2011-09-16 10:27 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 11:25:28AM +0100, Russell King - ARM Linux wrote:
> -devixp MACH_DEVIXP DEVIXP 2885
> -miccpt MACH_MICCPT MICCPT 2886
> -mic256 MACH_MIC256 MIC256 2887
Russell,
I had posted support for these some time ago, and shortly thereafter
the whole "clean up the ARM mess" campaign started. I did not follow
up on posting a second time, for fear of adding more churn.
So, my question is, what can I do to keep these in the list?
Can I get plain old board setup files merged (like three of the
following) ...
arch/arm/mach-ixp4xx/Kconfig | 8 +
arch/arm/mach-ixp4xx/Makefile | 2 +
arch/arm/mach-ixp4xx/include/mach/uncompress.h | 2 +-
arch/arm/mach-ixp4xx/miccpt-pci.c | 78 +++++++++
arch/arm/mach-ixp4xx/miccpt-setup.c | 219 ++++++++++++++++++++++++
5 files changed, 308 insertions(+), 1 deletions(-)
or would I have to somehow upgrade to DT?
Thanks,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-16 10:27 ` Richard Cochran
@ 2011-09-18 15:44 ` Arnd Bergmann
2011-09-19 15:51 ` Richard Cochran
0 siblings, 1 reply; 18+ messages in thread
From: Arnd Bergmann @ 2011-09-18 15:44 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 16 September 2011 12:27:54 Richard Cochran wrote:
> On Thu, Sep 15, 2011 at 11:25:28AM +0100, Russell King - ARM Linux wrote:
> > -devixp MACH_DEVIXP DEVIXP 2885
> > -miccpt MACH_MICCPT MICCPT 2886
> > -mic256 MACH_MIC256 MIC256 2887
>
> Russell,
>
> I had posted support for these some time ago, and shortly thereafter
> the whole "clean up the ARM mess" campaign started. I did not follow
> up on posting a second time, for fear of adding more churn.
>
> So, my question is, what can I do to keep these in the list?
>
> Can I get plain old board setup files merged (like three of the
> following) ...
>
> arch/arm/mach-ixp4xx/Kconfig | 8 +
> arch/arm/mach-ixp4xx/Makefile | 2 +
> arch/arm/mach-ixp4xx/include/mach/uncompress.h | 2 +-
> arch/arm/mach-ixp4xx/miccpt-pci.c | 78 +++++++++
> arch/arm/mach-ixp4xx/miccpt-setup.c | 219 ++++++++++++++++++++++++
> 5 files changed, 308 insertions(+), 1 deletions(-)
>
> or would I have to somehow upgrade to DT?
Post them for review again. The rules for new boards are much stricter
now, but we still allow them to get merged if they look good enough.
ixp4xx is not a very active platform, which means that it will take
a while before converting it to device tree probing becomes a priority,
so I would not object adding one board there. It's quite different for
platforms that are still used for new hardware development and have
lots of new boards waiting to get merged.
Arnd
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
` (3 preceding siblings ...)
2011-09-16 10:27 ` Richard Cochran
@ 2011-09-17 14:28 ` Pedanekar, Hemant
2011-09-17 14:34 ` Russell King - ARM Linux
2011-09-19 23:13 ` H Hartley Sweeten
5 siblings, 1 reply; 18+ messages in thread
From: Pedanekar, Hemant @ 2011-09-17 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
linux-arm-kernel-bounces at lists.infradead.org wrote on :
> I'm going to be merging a mach-types update (the cut-down and the
> policy-conforming version) for the next merge window. This will mean
> that things WILL BREAK, and I will not notice that things have broken.
>
> In order to fix this, entries need to be fixed to conform to the
> requirements - where the machine_is_xxx() name is the same as the
> MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
>
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means
> is that it
> is _important_ to get the core platform support in _first_ before any
> drivers which may make use of this.
>
> The following will be deleted from the file this time around are:
[...]
> -ti8148evm MACH_TI8148EVM TI8148EVM 3004
I guess this was removed due to being older than 12 months.
But since I had submitted v1 (see [1]) and am working on v2 post review, can you
please suggest how to go about it as I will need the above for adding support
for TI8148 EVM?
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53457.html
Thanks.
Hemant
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-17 14:28 ` Pedanekar, Hemant
@ 2011-09-17 14:34 ` Russell King - ARM Linux
2011-09-19 14:51 ` Pedanekar, Hemant
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-17 14:34 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote:
> But since I had submitted v1 (see [1]) and am working on v2 post review, can you
> please suggest how to go about it as I will need the above for adding support
> for TI8148 EVM?
The answer you require is in this statement:
# This is a cut-down version of the file; it contains only machines that
# are merged into mainline or have been edited in the machine database
# within the last 12 months. References to machine_is_NAME() do not count!
which highlights the policy. The key thing there is "edited".
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-17 14:34 ` Russell King - ARM Linux
@ 2011-09-19 14:51 ` Pedanekar, Hemant
0 siblings, 0 replies; 18+ messages in thread
From: Pedanekar, Hemant @ 2011-09-19 14:51 UTC (permalink / raw)
To: linux-arm-kernel
Russell King - ARM Linux wrote on Saturday, September 17, 2011 8:04 PM:
> On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote:
>> But since I had submitted v1 (see [1]) and am working on v2 post review,
>> can you please suggest how to go about it as I will need the above for
>> adding support for TI8148 EVM?
>
> The answer you require is in this statement:
>
> # This is a cut-down version of the file; it contains only
> machines that
> # are merged into mainline or have been edited in the machine database
> # within the last 12 months. References to machine_is_NAME()
> do not count!
>
> which highlights the policy. The key thing there is "edited".
Thanks, got it.
Hemant
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-09-15 10:25 READ THIS: the next mach-types update Russell King - ARM Linux
` (4 preceding siblings ...)
2011-09-17 14:28 ` Pedanekar, Hemant
@ 2011-09-19 23:13 ` H Hartley Sweeten
2011-10-17 10:56 ` Russell King - ARM Linux
5 siblings, 1 reply; 18+ messages in thread
From: H Hartley Sweeten @ 2011-09-19 23:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday, September 15, 2011 3:25 AM, Russell King wrote:
>
> I'm going to be merging a mach-types update (the cut-down and the
> policy-conforming version) for the next merge window. This will mean
> that things WILL BREAK, and I will not notice that things have broken.
>
> In order to fix this, entries need to be fixed to conform to the
> requirements - where the machine_is_xxx() name is the same as the
> MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
>
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means is that it
> is _important_ to get the core platform support in _first_ before any
> drivers which may make use of this.
Russell,
I posted support for MACH_VISION_EP9307 back in March and it's in your
patch tracker as 6851/1. I assumed it was still there because of the
work to clean up the ARM tree.
Is it possible to still get this patch merged and add the following
back to mach-types:
vision_ep9307 MACH_VISION_EP9307 VISION_EP9307 1578
Thanks,
Hartley
^ permalink raw reply [flat|nested] 18+ messages in thread* READ THIS: the next mach-types update
2011-09-19 23:13 ` H Hartley Sweeten
@ 2011-10-17 10:56 ` Russell King - ARM Linux
2011-10-17 11:22 ` Arnd Bergmann
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-10-17 10:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 19, 2011 at 06:13:11PM -0500, H Hartley Sweeten wrote:
> Russell,
>
> I posted support for MACH_VISION_EP9307 back in March and it's in your
> patch tracker as 6851/1. I assumed it was still there because of the
> work to clean up the ARM tree.
It was.
I've forwarded it to Arnd more than a week ago after discussing it with
Arnd, but I've heard nothing back as yet. I'm not sure what's happening
with it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-10-17 10:56 ` Russell King - ARM Linux
@ 2011-10-17 11:22 ` Arnd Bergmann
2011-10-17 16:57 ` H Hartley Sweeten
0 siblings, 1 reply; 18+ messages in thread
From: Arnd Bergmann @ 2011-10-17 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 17 October 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 06:13:11PM -0500, H Hartley Sweeten wrote:
> > Russell,
> >
> > I posted support for MACH_VISION_EP9307 back in March and it's in your
> > patch tracker as 6851/1. I assumed it was still there because of the
> > work to clean up the ARM tree.
>
> It was.
>
> I've forwarded it to Arnd more than a week ago after discussing it with
> Arnd, but I've heard nothing back as yet. I'm not sure what's happening
> with it.
>
Sorry, I missed it in my previous round of merges. I've put it into the
next/board branch now so it will show up in linux-next and I'll submit
it together with the other board-specific updates in the merge window.
Arnd
^ permalink raw reply [flat|nested] 18+ messages in thread
* READ THIS: the next mach-types update
2011-10-17 11:22 ` Arnd Bergmann
@ 2011-10-17 16:57 ` H Hartley Sweeten
0 siblings, 0 replies; 18+ messages in thread
From: H Hartley Sweeten @ 2011-10-17 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, October 17, 2011 4:23 AM, Arnd Bergmann wrote:
> On Monday 17 October 2011, Russell King - ARM Linux wrote:
>> On Mon, Sep 19, 2011 at 06:13:11PM -0500, H Hartley Sweeten wrote:
>>> Russell,
>>>
>>> I posted support for MACH_VISION_EP9307 back in March and it's in your
>>> patch tracker as 6851/1. I assumed it was still there because of the
>>> work to clean up the ARM tree.
>>
>> It was.
>>
>> I've forwarded it to Arnd more than a week ago after discussing it with
>> Arnd, but I've heard nothing back as yet. I'm not sure what's happening
>> with it.
>>
>
> Sorry, I missed it in my previous round of merges. I've put it into the
> next/board branch now so it will show up in linux-next and I'll submit
> it together with the other board-specific updates in the merge window.
Thanks! I'll keep an eye out for it.
Regards,
Hartley
^ permalink raw reply [flat|nested] 18+ messages in thread