diff mbox

arm: msm: remove board file for Nexus One (ie. mahimahi)

Message ID 1400101656.9826.4.camel@x220 (mailing list archive)
State New, archived
Headers show

Commit Message

Paul Bolle May 14, 2014, 9:07 p.m. UTC
Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
mahimahi)") added just board-mahimahi.c. It did not add
board-mahimahi.h, Makefile changes or Kconfig changes.

Four years have passed and this file is still dangling. Remove it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Untested. But what to test here?

 arch/arm/mach-msm/board-mahimahi.c | 88 --------------------------------------
 1 file changed, 88 deletions(-)
 delete mode 100644 arch/arm/mach-msm/board-mahimahi.c

Comments

Daniel Walker May 15, 2014, 5:44 p.m. UTC | #1
On Wed, May 14, 2014 at 11:07:36PM +0200, Paul Bolle wrote:
> Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
> mahimahi)") added just board-mahimahi.c. It did not add
> board-mahimahi.h, Makefile changes or Kconfig changes.
> 
> Four years have passed and this file is still dangling. Remove it.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Untested. But what to test here?
> 

I don't mine if Sapphire gets removed, but I'm working on this one now.. So I don't want it deleted.

Daniel
Paul Bolle May 15, 2014, 6:10 p.m. UTC | #2
Daniel,

On Thu, 2014-05-15 at 17:44 +0000, dwalker@fifo99.com wrote:
> On Wed, May 14, 2014 at 11:07:36PM +0200, Paul Bolle wrote:
> > Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
> > mahimahi)") added just board-mahimahi.c. It did not add
> > board-mahimahi.h, Makefile changes or Kconfig changes.
> > 
> > Four years have passed and this file is still dangling. Remove it.
> > 
> > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > ---
> > Untested. But what to test here?
> > 
> I don't mine if Sapphire gets removed,

Could you ACK that patch, please?

>  but I'm working on this one now..

That's good to hear.

>  So I don't want it deleted.

This is not something I get to decide. Nevertheless, given that this
file shouldn't have been merged to begin with, I'd appreciate it if some
deadline could be agreed upon.

That being said, I'm not sure how having just this file in mainline
helps your development efforts. It seems it did receive some updates
for, well, treewide stuff. But it surely didn't get build coverage or
runtime testing. So would you lose much if it only remains in your
development tree?


Paul Bolle
Daniel Walker May 15, 2014, 9:57 p.m. UTC | #3
On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> Daniel,
> 
> On Thu, 2014-05-15 at 17:44 +0000, dwalker@fifo99.com wrote:
> > On Wed, May 14, 2014 at 11:07:36PM +0200, Paul Bolle wrote:
> > > Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
> > > mahimahi)") added just board-mahimahi.c. It did not add
> > > board-mahimahi.h, Makefile changes or Kconfig changes.
> > > 
> > > Four years have passed and this file is still dangling. Remove it.
> > > 
> > > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > > ---
> > > Untested. But what to test here?
> > > 
> > I don't mine if Sapphire gets removed,
> 
> Could you ACK that patch, please?

I don't mind if it gets removed, but I wouldn't ACK it's removal ..
 
> >  but I'm working on this one now..
> 
> That's good to hear.
> 
> >  So I don't want it deleted.
> 
> This is not something I get to decide. Nevertheless, given that this
> file shouldn't have been merged to begin with, I'd appreciate it if some
> deadline could be agreed upon.

I think I merged it actually, but there's no rules about what gets merged. How when what order, etc.
It's all free form.

> That being said, I'm not sure how having just this file in mainline
> helps your development efforts. It seems it did receive some updates
> for, well, treewide stuff. But it surely didn't get build coverage or
> runtime testing. So would you lose much if it only remains in your
> development tree?

It's effort to remove it.. Your asking for it to get removed, then re-added.. That sounds
like a fairly large amount of effort vs just leaving it in place.

Daniel
Paul Bolle May 19, 2014, 11:53 a.m. UTC | #4
Daniel,

On Thu, 2014-05-15 at 21:57 +0000, dwalker@fifo99.com wrote:
> On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> > This is not something I get to decide. Nevertheless, given that this
> > file shouldn't have been merged to begin with, I'd appreciate it if some
> > deadline could be agreed upon.
> 
> I think I merged it actually, but there's no rules about what gets merged. How when what order, etc.
> It's all free form.

There do not seem to be formal rules. But there surely are some
requirements for code to be added. One of the requirements is, I think,
that it should build. This file cannot be built: it is not wired into a
Makefile and it also includes, what appears to be, its own header file,
but that header is not part of the tree.

Even the most dubious of code in drivers/staging is expected to "compile
properly"!

> > That being said, I'm not sure how having just this file in mainline
> > helps your development efforts. It seems it did receive some updates
> > for, well, treewide stuff. But it surely didn't get build coverage or
> > runtime testing. So would you lose much if it only remains in your
> > development tree?
> 
> It's effort to remove it.. Your asking for it to get removed, then re-added.. That sounds
> like a fairly large amount of effort vs just leaving it in place.

Yes, it takes some effort to remove code. And it will also take effort
to re-add that code later. But I think that's a risk one runs with code
that has clearly never been buildable.


Paul Bolle
Daniel Walker May 19, 2014, 2:30 p.m. UTC | #5
On Mon, May 19, 2014 at 01:53:28PM +0200, Paul Bolle wrote:
> Daniel,
> 
> On Thu, 2014-05-15 at 21:57 +0000, dwalker@fifo99.com wrote:
> > On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> > > This is not something I get to decide. Nevertheless, given that this
> > > file shouldn't have been merged to begin with, I'd appreciate it if some
> > > deadline could be agreed upon.
> > 
> > I think I merged it actually, but there's no rules about what gets merged. How when what order, etc.
> > It's all free form.
> 
> There do not seem to be formal rules. But there surely are some
> requirements for code to be added. One of the requirements is, I think,
> that it should build. This file cannot be built: it is not wired into a
> Makefile and it also includes, what appears to be, its own header file,
> but that header is not part of the tree.

The requirements are created by the maintainers.. In this case I would have expected
support for this phone much sooner, and there are in fact patches on the list to support
it which just haven't been merged yet. 

> Even the most dubious of code in drivers/staging is expected to "compile
> properly"!

But mach-msm isn't staging, different rules apply there.

Daniel
Ivan T. Ivanov May 20, 2014, 6:43 a.m. UTC | #6
On Mon, 2014-05-19 at 14:30 +0000, dwalker@fifo99.com wrote:
> On Mon, May 19, 2014 at 01:53:28PM +0200, Paul Bolle wrote:

<snip>

> 
> > Even the most dubious of code in drivers/staging is expected to "compile
> > properly"!
> 
> But mach-msm isn't staging, different rules apply there.

Heh, different rules you say: "Please send me a patches 
which even didn't compile". This is most relaxed reading
of Documentation/SubmittingPatches that I have heard :-)

Ivan

> 
> Daniel
Pavel Machek May 29, 2014, 6:29 p.m. UTC | #7
On Thu 2014-05-15 20:10:13, Paul Bolle wrote:
> Daniel,
> 
> On Thu, 2014-05-15 at 17:44 +0000, dwalker@fifo99.com wrote:
> > On Wed, May 14, 2014 at 11:07:36PM +0200, Paul Bolle wrote:
> > > Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
> > > mahimahi)") added just board-mahimahi.c. It did not add
> > > board-mahimahi.h, Makefile changes or Kconfig changes.
> > > 
> > > Four years have passed and this file is still dangling. Remove it.
> > > 
> > > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > > ---
> > > Untested. But what to test here?
> > > 
> > I don't mine if Sapphire gets removed,
> 
> Could you ACK that patch, please?
> 
> >  but I'm working on this one now..
> 
> That's good to hear.
> 
> >  So I don't want it deleted.
> 
> This is not something I get to decide. Nevertheless, given that this
> file shouldn't have been merged to begin with, I'd appreciate it if some
> deadline could be agreed upon.

Daniel is working on solving that. That should be enough. It is not as
the file is great problem to anybody.

If it is not fixed within year, you may want to retransmit your patch.

									Pavel
diff mbox

Patch

diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
deleted file mode 100644
index 7d9981cb400e..000000000000
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ /dev/null
@@ -1,88 +0,0 @@ 
-/* linux/arch/arm/mach-msm/board-mahimahi.c
- *
- * Copyright (C) 2009 Google, Inc.
- * Copyright (C) 2009 HTC Corporation.
- * Author: Dima Zavin <dima@android.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/delay.h>
-#include <linux/gpio.h>
-#include <linux/init.h>
-#include <linux/input.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include <asm/setup.h>
-
-#include <mach/hardware.h>
-
-#include "board-mahimahi.h"
-#include "devices.h"
-#include "proc_comm.h"
-#include "common.h"
-
-static uint debug_uart;
-
-module_param_named(debug_uart, debug_uart, uint, 0);
-
-static struct platform_device *devices[] __initdata = {
-#if !defined(CONFIG_MSM_SERIAL_DEBUGGER)
-	&msm_device_uart1,
-#endif
-	&msm_device_uart_dm1,
-	&msm_device_nand,
-};
-
-static void __init mahimahi_init(void)
-{
-	platform_add_devices(devices, ARRAY_SIZE(devices));
-}
-
-static void __init mahimahi_fixup(struct tag *tags, char **cmdline,
-				  struct meminfo *mi)
-{
-	mi->nr_banks = 2;
-	mi->bank[0].start = PHYS_OFFSET;
-	mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
-	mi->bank[0].size = (219*1024*1024);
-	mi->bank[1].start = MSM_HIGHMEM_BASE;
-	mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
-	mi->bank[1].size = MSM_HIGHMEM_SIZE;
-}
-
-static void __init mahimahi_map_io(void)
-{
-	msm_map_common_io();
-	msm_clock_init();
-}
-
-static void __init mahimahi_init_late(void)
-{
-	smd_debugfs_init();
-}
-
-void msm_timer_init(void);
-
-MACHINE_START(MAHIMAHI, "mahimahi")
-	.atag_offset	= 0x100,
-	.fixup		= mahimahi_fixup,
-	.map_io		= mahimahi_map_io,
-	.init_irq	= msm_init_irq,
-	.init_machine	= mahimahi_init,
-	.init_late	= mahimahi_init_late,
-	.init_time	= msm_timer_init,
-MACHINE_END