From: Fabio Estevam <redacted>
There is no need for adding board related entries into dt_board_compat.
Leave only the SoC entry.
This way we do not need to patch a C file when adding dt support for a new board.
Signed-off-by: Fabio Estevam <redacted>
---
arch/arm/mach-imx/imx51-dt.c | 1 -
arch/arm/mach-imx/imx53-dt.c | 4 ----
arch/arm/mach-imx/mach-imx6q.c | 3 ---
3 files changed, 0 insertions(+), 8 deletions(-)
From: Fabio Estevam <redacted>
There is no need for adding board related entries into dt_board_compat.
Leave only the SoC entry.
This way we do not need to patch a C file when adding dt support for a new board.
Signed-off-by: Fabio Estevam <redacted>
---
arch/arm/mach-mxs/mach-mxs.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
From: Fabio Estevam <redacted>
There is no need for adding board related entries into dt_board_compat.
Leave only the SoC entry.
This way we do not need to patch a C file when adding dt support for a new
board.
Signed-off-by: Fabio Estevam <redacted>
---
arch/arm/mach-mxs/mach-mxs.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
Shawn,
Is this ok with you?
Sascha
On Sun, Jun 17, 2012 at 11:04:15AM -0300, Fabio Estevam wrote:
quoted hunk
From: Fabio Estevam <redacted>
There is no need for adding board related entries into dt_board_compat.
Leave only the SoC entry.
This way we do not need to patch a C file when adding dt support for a new board.
Signed-off-by: Fabio Estevam <redacted>
---
arch/arm/mach-imx/imx51-dt.c | 1 -
arch/arm/mach-imx/imx53-dt.c | 4 ----
arch/arm/mach-imx/mach-imx6q.c | 3 ---
3 files changed, 0 insertions(+), 8 deletions(-)
I change my mind. Though it's really a pity to lose a concentrated
place maintaining a full list of compatible strings of all supported
board, I'm more concerned by the dt_board_compat matching efficiency
when the table gets longer.
So, Fabio, can you please resend the patches against v3.6-rc?
--
Regards,
Shawn
I change my mind. Though it's really a pity to lose a concentrated
place maintaining a full list of compatible strings of all supported
board, I'm more concerned by the dt_board_compat matching efficiency
when the table gets longer.
So, Fabio, can you please resend the patches against v3.6-rc?
What about the board quirks that are present there?
Best regards,
Marek Vasut
I change my mind. Though it's really a pity to lose a concentrated
place maintaining a full list of compatible strings of all supported
board, I'm more concerned by the dt_board_compat matching efficiency
when the table gets longer.
So, Fabio, can you please resend the patches against v3.6-rc?
What about the board quirks that are present there?
They don't need to be done since they're usually driver-specific or
unit-specific; DTs should include these at the appropriate places. For
the MX51 Babbage entry all it did was set up all the iomux which is
now done via pinctrl and DT, so it can go. The rest, well, this is
more a quirk of the chip, and what should happen is, if it can be
moved to a bootloader, do it, and set up a quirk as a property in that
device like fsl,mc13xxx-uses-rtc - although in that particular example
I dare say that should be an rtc node under the pmic entry rather than
a property, at least for now it shows you can pick up a property that
changes the behavior of a device without it being in a mach-specific
file.
There may actually be some boards that need some specific, low-level
hacks to make work that will need entering but, for now, this doesn't
need to be. They can be removed and when those specific hacks appear,
their compatibles and new code to support the hacks can be added back
in.
--
Matt Sealey [off-list ref]
Product Development Analyst, Genesi USA, Inc.
I change my mind. Though it's really a pity to lose a concentrated
place maintaining a full list of compatible strings of all supported
board, I'm more concerned by the dt_board_compat matching efficiency
when the table gets longer.
I think this is needless churn. You can't say board entries are never
needed. Perhaps we've been overly active in adding all compatible
strings before they are needed. When you add a new board, it is fine to
match against the soc string without changing the kernel, but the dtb
should still have a more specific string. Then if you need to add
something board specific later, you can add the match entry and
corresponding board specific code.
Rob
On Mon, Aug 13, 2012 at 04:48:11PM -0500, Rob Herring wrote:
I think this is needless churn. You can't say board entries are never
needed. Perhaps we've been overly active in adding all compatible
strings before they are needed. When you add a new board, it is fine to
match against the soc string without changing the kernel, but the dtb
should still have a more specific string. Then if you need to add
something board specific later, you can add the match entry and
corresponding board specific code.
I probably haven't made myself clear. What I'm asking for is merely
removing the board compatible string from dt_board_compat, not from
dtb. Every single board will still have its specific compatible string
defined in its dts.
--
Regards,
Shawn