* Re: mISDN still breaking the allmodconfig build...
From: Marcel Holtmann @ 2008-07-28 1:13 UTC (permalink / raw)
To: David Miller; +Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds
In-Reply-To: <20080727.180736.74131389.davem@davemloft.net>
Hi Dave,
>>> More fallout from the premature mISDN driver merge:
>>>
>>> drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
>>> running on big endian machines now"
>>
>> is that only the HFC driver or the whole mISDN stack?
>>
>> I know that the two old ISDN stacks where really bad on big endian,
>> but my assumption was that we did sort this out in the end.
>
> One of the two mISDN drivers uses the deprecated virt_to_bus()
> interface for handling DMA addresses (that doesn't even work on many
> x86 systems these days) and the other mISDN driver gives the above
> big-endian compile time error.
>
> In short, this driver was not ready for merging at all.
I am not defending it and agree that this driver should have had at
least one test run in linux-next. However mISDN is a whole ISDN stack.
So does mISDN has an issue too or do we only have a really broken
driver. Karsten?
Regards
Marcel
^ permalink raw reply
* Re: mISDN still breaking the allmodconfig build...
From: Marcel Holtmann @ 2008-07-28 1:03 UTC (permalink / raw)
To: David Miller; +Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds
In-Reply-To: <20080727.170235.97056809.davem@davemloft.net>
Hi Dave,
> More fallout from the premature mISDN driver merge:
>
> drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> running on big endian machines now"
is that only the HFC driver or the whole mISDN stack?
I know that the two old ISDN stacks where really bad on big endian,
but my assumption was that we did sort this out in the end.
Regards
Marcel
^ permalink raw reply
* ide pmac breakage
From: Benjamin Herrenschmidt @ 2008-07-28 1:29 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: list linux-ide, linuxppc-dev list
The current ide-pmac upstream is broken. It calls
media_bay_set_ide_infos() with an uninitialized "hwif" argument.
It's not a trivial mistake, there's a chicken-and-egg problem in the
init code in there.
I've locally fixed it with this patch that i'll merge via the powerpc
tree unless you have an objection.
However, the machine crashes when removing the media-bay CD-ROM drive.
Crash appears to be a NULL deref, possibly in elv_may_queue() though
I don't have a clean backtrace yet, working on it...
Cheers,
Ben.
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index c521bf6..fa2be26 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1086,6 +1086,11 @@ static int __devinit pmac_ide_setup_device(pmac_ide_hwif_t *pmif, hw_regs_t *hw)
/* Make sure we have sane timings */
sanitize_timings(pmif);
+ host = ide_host_alloc(&d, hws);
+ if (host == NULL)
+ return -ENOMEM;
+ hwif = host->ports[0];
+
#ifndef CONFIG_PPC64
/* XXX FIXME: Media bay stuff need re-organizing */
if (np->parent && np->parent->name
@@ -1119,11 +1124,11 @@ static int __devinit pmac_ide_setup_device(pmac_ide_hwif_t *pmif, hw_regs_t *hw)
pmif->mdev ? "macio" : "PCI", pmif->aapl_bus_id,
pmif->mediabay ? " (mediabay)" : "", hw->irq);
- rc = ide_host_add(&d, hws, &host);
- if (rc)
+ rc = ide_host_register(host, &d, hws);
+ if (rc) {
+ ide_host_free(host);
return rc;
-
- hwif = host->ports[0];
+ }
return 0;
}
^ permalink raw reply related
* Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
From: James Morris @ 2008-07-28 1:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jeff Garzik, LKML, FUJITA Tomonori, ppc-dev, Paul Mackerras,
Andrew Morton
In-Reply-To: <20080728103253.5256e6c0.sfr@canb.auug.org.au>
On Mon, 28 Jul 2008, Stephen Rothwell wrote:
> I hope that we all can discuss procedures for API changes at the Kernel
> Summit ...
"all" as in, whoever was invited (the only transparent aspect of was a
silly count of # of commits for the initial shortlist), or was on the
committee, or bought seats via sponsorship.
- James (co- maintainer/author of several kernel subsystems over 8+ years
and apparently not invited, because ?)
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: mISDN still breaking the allmodconfig build...
From: Mikael Pettersson @ 2008-07-28 1:57 UTC (permalink / raw)
To: David Miller
Cc: sfr, kkeil, marcel, linux-kernel, linuxppc-dev, akpm, torvalds
In-Reply-To: <20080727.180736.74131389.davem@davemloft.net>
David Miller writes:
> From: Marcel Holtmann <marcel@holtmann.org>
> Date: Mon, 28 Jul 2008 03:03:04 +0200
>
> > > More fallout from the premature mISDN driver merge:
> > >
> > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> > > running on big endian machines now"
> >
> > is that only the HFC driver or the whole mISDN stack?
> >
> > I know that the two old ISDN stacks where really bad on big endian,
> > but my assumption was that we did sort this out in the end.
>
> One of the two mISDN drivers uses the deprecated virt_to_bus()
> interface for handling DMA addresses (that doesn't even work on many
> x86 systems these days) and the other mISDN driver gives the above
> big-endian compile time error.
>
> In short, this driver was not ready for merging at all.
Why on earth does a generic (I hope) protocol driver (some ISDN
thingy in this case) care about endianess at all?
Or has things come to a "the world's an x86" ("the world's a VAX" for
old-timers but add 25+ years or so) situation where the majority of
coders don't even consider that machines might be different from what
they use? If so, a deep sigh of sadness.
(Not that I prefer a particular endianess. My point being that coders
shouldn't make endianess assumptions unless they're really^3 important.)>
^ permalink raw reply
* Re: [PATCH 1/2] leds: make the default trigger name const
From: Trent Piepho @ 2008-07-28 1:56 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-kernel, linuxppc-dev, Richard Purdie, Trent Piepho
In-Reply-To: <20080727231149.1b2508da.sfr@canb.auug.org.au>
On Sun, 27 Jul 2008, Stephen Rothwell wrote:
> On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote:
>>> The default_trigger fields of struct gpio_led and thus struct led_classdev
>>> are pretty much always assigned from a string literal, which means the
>>> string can't be modified. Which is fine, since there is no reason to
>>> modify the string and in fact it never is.
>>>
>>> But they should be marked const to prevent such code from being added, to
>>> prevent warnings if -Wwrite-strings is used and when assigned from a
>>> constant string other than a string literal (which produces a warning under
>>> current kernel compiler flags), and for general good coding practices.
>>>
>>> Signed-off-by: Trent Piepho <tpiepho@freescale.com>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> I would ack this as well, except I am not sure what tree this patch is
> against. In the current powerpc next tree,
It was against powerpc next from Jul 22nd, current at the time I made the
patch. It looks like that file has changed in the last few days. There is a
patch from Anton Vorontsov, "leds: mark led_classdev.default_trigger as
const", which adds const to one of the structs I modified, but doesn't get the
other one (struct gpio_led).
Then another patch from Nate Case added a new LED chip driver, and the
platform data for this driver was added as "generic led platform data", which
I don't entirely agree with. And this new struct didn't make default_trigger
const, probably because it was just copied from the gpio led platform data
with some fields removed (so it's not really that generic then, is it?).
I'll send an updated patch for current powerpc next.
^ permalink raw reply
* Re: ide pmac breakage
From: Benjamin Herrenschmidt @ 2008-07-28 2:02 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: list linux-ide, linuxppc-dev list
In-Reply-To: <1217208596.11188.144.camel@pasglop>
On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote:
> The current ide-pmac upstream is broken. It calls
> media_bay_set_ide_infos() with an uninitialized "hwif" argument.
>
> It's not a trivial mistake, there's a chicken-and-egg problem in the
> init code in there.
>
> I've locally fixed it with this patch that i'll merge via the powerpc
> tree unless you have an objection.
>
> However, the machine crashes when removing the media-bay CD-ROM drive.
>
> Crash appears to be a NULL deref, possibly in elv_may_queue() though
> I don't have a clean backtrace yet, working on it...
Here's a backtrace:
Vector: 300 (Data Access) at [c58b7b80]
pc: c014f264: elv_may_queue+0x10/0x44
lr: c0152750: get_request+0x2c/0x2c0
sp: c58b7c30
msr: 1032
dar: c
dsisr: 40000000
current = 0xc58aaae0
pid = 854, comm = media-bay
enter ? for help
mon> t
[c58b7c40] c0152750 get_request+0x2c/0x2c0
[c58b7c70] c0152a08 get_request_wait+0x24/0xec
[c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
[c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
[c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
[c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
[c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
[c58b7e50] c022395c ide_cd_release+0x80/0x84
[c58b7e70] c0163650 kref_put+0x54/0x6c
[c58b7e80] c0223884 ide_cd_put+0x40/0x5c
[c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
[c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
[c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
[c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
[c58b7f00] c01e7424 device_del+0x104/0x198
[c58b7f20] c01e74d0 device_unregister+0x18/0x30
[c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
[c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
[c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
[c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
[c58b7fd0] c00485c0 kthread+0x48/0x84
[c58b7ff0] c0011b20 kernel_thread+0x44/0x60
^ permalink raw reply
* [PATCH] powerpc/powermac: Use sane default baudrate for SCC debugging
From: Benjamin Herrenschmidt @ 2008-07-28 2:06 UTC (permalink / raw)
To: linuxppc-dev list
When using the "sccdbg" option to route early kernel messages and
xmon to the SCC serial port on PowerMacs, when this wasn't the
configured output port of Open Firmware, we initialize the baudrate
to 57600bps. This isn't a very good default on some powermacs where
both the FW and pmac_zilog will default to 38400. This fixes it to
use the same logic as pmac_zilog to pick a default speed.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c b/arch/powerpc/platforms/powermac/udbg_scc.c
index 47de4d3..572771f 100644
--- a/arch/powerpc/platforms/powermac/udbg_scc.c
+++ b/arch/powerpc/platforms/powermac/udbg_scc.c
@@ -125,13 +125,23 @@ void udbg_scc_init(int force_scc)
out_8(sccc, 0xc0);
/* If SCC was the OF output port, read the BRG value, else
- * Setup for 57600 8N1
+ * Setup for 38400 or 57600 8N1 depending on the machine
*/
if (ch_def != NULL) {
out_8(sccc, 13);
scc_inittab[1] = in_8(sccc);
out_8(sccc, 12);
scc_inittab[3] = in_8(sccc);
+ } else if (machine_is_compatible("RackMac1,1")
+ || machine_is_compatible("RackMac1,2")
+ || machine_is_compatible("MacRISC4")) {
+ /* Xserves and G5s default to 57600 */
+ scc_inittab[1] = 0;
+ scc_inittab[3] = 0;
+ } else {
+ /* Others default to 38400 */
+ scc_inittab[1] = 0;
+ scc_inittab[3] = 1;
}
for (i = 0; i < sizeof(scc_inittab); ++i)
^ permalink raw reply related
* [PATCH v2] leds: make the default trigger name const
From: Trent Piepho @ 2008-07-28 2:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-kernel, linuxppc-dev, Richard Purdie, Trent Piepho
In-Reply-To: <Pine.LNX.4.64.0807271304350.26456@t2.domain.actdsltmp>
The default_trigger fields of struct gpio_led and thus struct led_classdev
are pretty much always assigned from a string literal, which means the
string can't be modified. Which is fine, since there is no reason to
modify the string and in fact it never is.
But they should be marked const to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
---
include/linux/leds.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 519df72..defe693 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -48,7 +48,7 @@ struct led_classdev {
struct device *dev;
struct list_head node; /* LED Device list */
- char *default_trigger; /* Trigger to use */
+ const char *default_trigger; /* Trigger to use */
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
@@ -121,7 +121,7 @@ extern void ledtrig_ide_activity(void);
/* For the leds-gpio driver */
struct gpio_led {
const char *name;
- char *default_trigger;
+ const char *default_trigger;
unsigned gpio;
u8 active_low;
};
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
From: Andrew Morton @ 2008-07-28 3:04 UTC (permalink / raw)
To: James Morris
Cc: Stephen Rothwell, Jeff Garzik, LKML, Tomonori, ppc-dev,
Paul Mackerras, FUJITA
In-Reply-To: <Xine.LNX.4.64.0807281101310.19550@us.intercode.com.au>
On Mon, 28 Jul 2008 11:07:40 +1000 (EST) James Morris <jmorris@namei.org> wrote:
> On Mon, 28 Jul 2008, Stephen Rothwell wrote:
>
> > I hope that we all can discuss procedures for API changes at the Kernel
> > Summit ...
>
> "all" as in, whoever was invited (the only transparent aspect of was a
> silly count of # of commits for the initial shortlist), or was on the
> committee, or bought seats via sponsorship.
>
Yeah.
We do all our work via email. If there's some particular issue that we
feel cannot be resolved effectively via email then I'd really like to
know what that issue is, and why.
> - James (co- maintainer/author of several kernel subsystems over 8+ years
> and apparently not invited, because ?)
- Andrew, who asked everyone two years ago whether we can justify
annual kernel summits, and who still awaits a convincing answer.
But for this particular problem I don't think there's much to be
discussed. It should have been implemented as
s/dma_mapping_error/dma_mapping_error2/g with eventual removal of
dma_mapping_error(). But I failed to appreciate how many
dma_mapping_error()s there are and I failed to predict how many _new_
dma_mapping_error()s would turn up across the -rc phase. So I suck,
what's new?
otoh, I don't reeeeeeealy worry too much about compile errors during
the merge window. People get all hot under the collar and shout at
each other, but they're trivial to find (the compiler tells you!) and
almost always trivial to fix and they are almost always trivially
worked around via config if you hit one during a bisect. Shrug, fix
them and move on.
It's the runtime errors which are far, far, far more of a problem for us.
^ permalink raw reply
* Re: gigantci pages patches
From: Andrew Morton @ 2008-07-28 3:17 UTC (permalink / raw)
To: David Gibson; +Cc: npiggin, Stephen Rothwell, Jon Tollefson, ppc-dev, paulus
In-Reply-To: <20080728010757.GF11318@yookeroo.seuss>
On Mon, 28 Jul 2008 11:07:57 +1000 David Gibson <dwg@au1.ibm.com> wrote:
> On Tue, Jul 22, 2008 at 03:22:36PM -0500, Jon Tollefson wrote:
> > David Gibson wrote:
> > > On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote:
> > >
> > >> Hi all,
> > >>
> > >> Could people take one last look at these patches and if there are no
> > >> issues, please send Ack-bys to Andrew who will push them to Linus for
> > >> 2.6.27.
> > >>
> > >> [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18437
> > >> Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18438
> > >> Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18439
> > >> Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18440
> > >> Patch: [PATCH 5/6 v2] check for overflow
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18441
> > >> Patch: [PATCH 6/6] powerpc: support multiple huge page sizes
> > >> http://patchwork.ozlabs.org/linuxppc/patch?&id=18442
> > >>
> > >
> > > Sorry, I should have looked at these properly when they went past in
> > > May, but obviously I missed them.
> > >
> > > They mostly look ok. I'm a bit confused on 2/6 though - it seems the
> > > new powerpc alloc_bootmem_huge_page() function is specific to the 16G
> > > gigantic pages. But can't that function also get called for the
> > > normal 16M hugepages depending on how the hugepage pool is
> > > initialized.
> > >
> > > Or am I missing something (wouldn't surprise me given my brain's
> > > sluggishness today)?
> > >
> > The alloc_bootmem_huge_page() function is only called for pages >=
> > MAX_ORDER. The 16M pages are always allocated within the generic
> > hugetlbfs code with alloc_pages_node().
>
> Ah, ok. Well, in that case:
>
> Acked-by: David Gibson <dwg@au1.ibm.com>
>
> for the series
OK. Although I'm no longer sure what patches "for the series" refers to.
I am currently retaining
powerpc-implement-pte_special.patch
powerpc-implement-pte_special-update.patch
powerpc-lockless-get_user_pages.patch
and frankly I'm unsure what the status is. I have a note that benh had
concerns about powerpc-lockless-get_user_pages.patch, but iirc they
were waffly and vague ;)
So I'm thinking I'll stick these patches onto my send-to-ben list.
^ permalink raw reply
* Re: gigantci pages patches
From: Benjamin Herrenschmidt @ 2008-07-28 3:19 UTC (permalink / raw)
To: Andrew Morton
Cc: npiggin, Stephen Rothwell, Jon Tollefson, David Gibson, ppc-dev,
paulus
In-Reply-To: <20080727201735.0b141250.akpm@linux-foundation.org>
On Sun, 2008-07-27 at 20:17 -0700, Andrew Morton wrote:
> s
>
> OK. Although I'm no longer sure what patches "for the series" refers to.
>
> I am currently retaining
>
> powerpc-implement-pte_special.patch
> powerpc-implement-pte_special-update.patch
> powerpc-lockless-get_user_pages.patch
>
> and frankly I'm unsure what the status is. I have a note that benh had
> concerns about powerpc-lockless-get_user_pages.patch, but iirc they
> were waffly and vague ;)
>
> So I'm thinking I'll stick these patches onto my send-to-ben list.
Ok, send the latest ones you have to me, and I'll sort things you.
Cheers,
Ben.
^ permalink raw reply
* powerpc/powermac: Fixup default serial port device for pmac_zilog
From: Benjamin Herrenschmidt @ 2008-07-28 3:49 UTC (permalink / raw)
To: linuxppc-dev list
This removes the non-working code in legacy_serial that tried to handle
the powermac SCC ports, and instead add a (now working) function to the
powermac platform code to find the default serial console if any.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 4d96e1d..bd8c838 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -493,18 +493,18 @@ static int __init serial_dev_init(void)
device_initcall(serial_dev_init);
+#ifdef CONFIG_SERIAL_8250_CONSOLE
/*
* This is called very early, as part of console_init() (typically just after
* time_init()). This function is respondible for trying to find a good
* default console on serial ports. It tries to match the open firmware
- * default output with one of the available serial console drivers, either
- * one of the platform serial ports that have been probed earlier by
- * find_legacy_serial_ports() or some more platform specific ones.
+ * default output with one of the available serial console drivers that have
+ * been probed earlier by find_legacy_serial_ports()
*/
static int __init check_legacy_serial_console(void)
{
struct device_node *prom_stdout = NULL;
- int speed = 0, offset = 0;
+ int i, speed = 0, offset = 0;
const char *name;
const u32 *spd;
@@ -548,33 +548,22 @@ static int __init check_legacy_serial_console(void)
if (spd)
speed = *spd;
- if (0)
- ;
-#ifdef CONFIG_SERIAL_8250_CONSOLE
- else if (strcmp(name, "serial") == 0) {
- int i;
- /* Look for it in probed array */
- for (i = 0; i < legacy_serial_count; i++) {
- if (prom_stdout != legacy_serial_infos[i].np)
- continue;
- offset = i;
- speed = legacy_serial_infos[i].speed;
- break;
- }
- if (i >= legacy_serial_count)
- goto not_found;
+ if (strcmp(name, "serial") != 0)
+ goto not_found;
+
+ /* Look for it in probed array */
+ for (i = 0; i < legacy_serial_count; i++) {
+ if (prom_stdout != legacy_serial_infos[i].np)
+ continue;
+ offset = i;
+ speed = legacy_serial_infos[i].speed;
+ break;
}
-#endif /* CONFIG_SERIAL_8250_CONSOLE */
-#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
- else if (strcmp(name, "ch-a") == 0)
- offset = 0;
- else if (strcmp(name, "ch-b") == 0)
- offset = 1;
-#endif /* CONFIG_SERIAL_PMACZILOG_CONSOLE */
- else
+ if (i >= legacy_serial_count)
goto not_found;
- of_node_put(prom_stdout);
+ of_node_put(prom_stdout);
+
DBG("Found serial console at ttyS%d\n", offset);
if (speed) {
@@ -591,3 +580,4 @@ static int __init check_legacy_serial_console(void)
}
console_initcall(check_legacy_serial_console);
+#endif /* CONFIG_SERIAL_8250_CONSOLE */
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 3163544..88ccf3a 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -541,6 +541,78 @@ static int __init pmac_declare_of_platform_devices(void)
}
machine_device_initcall(powermac, pmac_declare_of_platform_devices);
+#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
+/*
+ * This is called very early, as part of console_init() (typically just after
+ * time_init()). This function is respondible for trying to find a good
+ * default console on serial ports. It tries to match the open firmware
+ * default output with one of the available serial console drivers.
+ */
+static int __init check_pmac_serial_console(void)
+{
+ struct device_node *prom_stdout = NULL;
+ int offset = 0;
+ const char *name;
+#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
+ char *devname = "ttyS";
+#else
+ char *devname = "ttyPZ";
+#endif
+
+ pr_debug(" -> check_pmac_serial_console()\n");
+
+ /* The user has requested a console so this is already set up. */
+ if (strstr(boot_command_line, "console=")) {
+ pr_debug(" console was specified !\n");
+ return -EBUSY;
+ }
+
+ if (!of_chosen) {
+ pr_debug(" of_chosen is NULL !\n");
+ return -ENODEV;
+ }
+
+ /* We are getting a weird phandle from OF ... */
+ /* ... So use the full path instead */
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL) {
+ pr_debug(" no linux,stdout-path !\n");
+ return -ENODEV;
+ }
+ prom_stdout = of_find_node_by_path(name);
+ if (!prom_stdout) {
+ pr_debug(" can't find stdout package %s !\n", name);
+ return -ENODEV;
+ }
+ pr_debug("stdout is %s\n", prom_stdout->full_name);
+
+ name = of_get_property(prom_stdout, "name", NULL);
+ if (!name) {
+ pr_debug(" stdout package has no name !\n");
+ goto not_found;
+ }
+
+ if (strcmp(name, "ch-a") == 0)
+ offset = 0;
+ else if (strcmp(name, "ch-b") == 0)
+ offset = 1;
+ else
+ goto not_found;
+ of_node_put(prom_stdout);
+
+ pr_debug("Found serial console at %s%d\n", devname, offset);
+
+ return add_preferred_console(devname, offset, NULL);
+
+ not_found:
+ pr_debug("No preferred console found !\n");
+ of_node_put(prom_stdout);
+ return -ENODEV;
+}
+console_initcall(check_pmac_serial_console);
+
+#endif /* CONFIG_SERIAL_PMACZILOG_CONSOLE */
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
^ permalink raw reply related
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: M. Warner Losh @ 2008-07-28 4:16 UTC (permalink / raw)
To: jonsmirl; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <9e4733910807271500l23fd2b12n940197474a5291df@mail.gmail.com>
In message: <9e4733910807271500l23fd2b12n940197474a5291df@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
: On 7/27/08, Segher Boessenkool <segher@kernel.crashing.org> wrote:
: > >
: > > >
: > > > > compatible = "atmel,24c32wp", "24c32", "eeprom";
: > > > >
: > > >
: > >
: >
: >
: > >
: > > > I know this is just an example; but to keep thinks clear, the second
: > > > and third values in this compatible property are completely bogus (for
: > > > device trees). The manufacturer prefix needs to be present and
: > > > 'eeprom' is far to vague.
: > > >
: > >
: > > Isn't 24c32 a generic, cross manufacturer term used for these devices?
: > >
: >
: > Sure it is. But "compatible" values are a global namespace so care
: > needs to be taken not to cause collisions. One mechanism for that
: > is to use vendor prefixes (and that just shifts the problem so it
: > is less global); another is to choose good names that have a lower
: > chance to collide with the name for another device. And the most
: > important way to prevent collisions is to write up a binding, so
: > everyone knows you have claimed that name. It still needs to be
: > a good name, of course.
: >
: >
: > > What if I have a socket and use a different vendor's chip each week?
: > >
: >
: > You use sockets for your seeproms? Wow :-) But yes, it shouldn't
: > be necessary to put the exact make of the device in the device
: > tree, for such generic devices. It certainly doesn't hurt to do
: > so though (if the exact model is known).
: >
: > A reasonable "compatible" value would be something like
: > "serial-eeprom-24c32".
: > You can go a little bit more generic than that, if you write up in
: > your binding how the driver should figure out the device size and
: > the protocol used.
:
: Matching on "serial-eeprom-24c32" requires me to convince the at24
: authors to add that string as an alias binding for their driver. How
: about "serial-eeprom,24c32" or "generic,24x32"?
Many of the serial eeproms have a common way to access them. There's
a few organizations of eeproms made by a number of different
manufacturers that are actually accessed the same.
Warner
^ permalink raw reply
* Re: Please pull mpc52xx-next
From: Grant Likely @ 2008-07-28 4:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40807271448tb387f06xe380f7941fb7d331@mail.gmail.com>
On Sun, Jul 27, 2008 at 3:48 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Jul 25, 2008 at 10:00 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> Hey Ben, here are a few more patches for .27. I would have had this
>> stuff in earlier, but they depended on another patch that I didn't
>> feel like I should push that was in Andrew's queue.
>>
>> Grant Likely (4):
>> of: adapt of_find_i2c_driver() to be usable by SPI also
>> spi: split up spi_new_device() to allow two stage registration.
>> spi: Add OF binding support for SPI busses
>> powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
>
> Oops, I shouldn't have merged this last one. Please don't pull this
> tree yet. I'll fix it up this evening.
Okay, I've got it sorted out now. Here is the new pull request:
The following changes since commit 024e8ac04453b3525448c31ef39848cf675ba6db:
Roland McGrath (1):
x86_64: fix ia32 AMD syscall audit fast-path
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx next
Grant Likely (3):
of: adapt of_find_i2c_driver() to be usable by SPI also
spi: split up spi_new_device() to allow two stage registration.
spi: Add OF binding support for SPI busses
drivers/of/Kconfig | 6 ++
drivers/of/Makefile | 1 +
drivers/of/base.c | 88 ++++++++++++++++++++++++++++++
drivers/of/of_i2c.c | 64 +---------------------
drivers/of/of_spi.c | 93 +++++++++++++++++++++++++++++++
drivers/spi/spi.c | 139 ++++++++++++++++++++++++++++++++---------------
include/linux/of.h | 1 +
include/linux/of_spi.h | 18 ++++++
include/linux/spi/spi.h | 12 ++++
9 files changed, 317 insertions(+), 105 deletions(-)
create mode 100644 drivers/of/of_spi.c
create mode 100644 include/linux/of_spi.h
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc: Disable 64K huge page support when doing 64K SPU mappings
From: Benjamin Herrenschmidt @ 2008-07-28 6:13 UTC (permalink / raw)
To: linuxppc-dev list
The 64K SPU local store mapping feature is incompatible with the
64K huge pages support due to the inability of some parts of
the memory management to differenciate between them while they
use a different page table format.
For now, disable 64K huge pages when CONFIG_SPU_FS_64K_LS,
in the long run, this can be fixed by making this feature use
the hugetlb page table format.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/mm/hugetlbpage.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/hugetlbpage.c 2008-07-28 15:57:48.000000000 +1000
+++ linux-work/arch/powerpc/mm/hugetlbpage.c 2008-07-28 15:59:25.000000000 +1000
@@ -736,14 +736,21 @@ static int __init hugetlbpage_init(void)
if (!cpu_has_feature(CPU_FTR_16M_PAGE))
return -ENODEV;
+
/* Add supported huge page sizes. Need to change HUGE_MAX_HSTATE
* and adjust PTE_NONCACHE_NUM if the number of supported huge page
* sizes changes.
*/
set_huge_psize(MMU_PAGE_16M);
- set_huge_psize(MMU_PAGE_64K);
set_huge_psize(MMU_PAGE_16G);
+ /* Temporarily disable support for 64K huge pages when 64K SPU local
+ * store support is enabled as the current implementation conflicts.
+ */
+#ifndef CONFIG_SPU_FS_64K_LS
+ set_huge_psize(MMU_PAGE_64K);
+#endif
+
for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) {
if (mmu_huge_psizes[psize]) {
huge_pgtable_cache(psize) = kmem_cache_create(
^ permalink raw reply
* Re: [PATCH 0/6] powerpc topology updates
From: Benjamin Herrenschmidt @ 2008-07-28 6:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1217136295-18693-1-git-send-email-ntl@pobox.com>
On Sun, 2008-07-27 at 00:24 -0500, Nathan Lynch wrote:
> This series consists of a couple of cleanups and a few feature
> additions, all of which are more or less related to system topology
> (threads, cores, caches, sysfs...) These are independent of
> each other except for 4 and 5 (core sibling and core id info).
>
> I'd say the highlights are the last three patches, which add core and
> cache information to sysfs. Here is some example output with the
> patches applied:
Applied with minor changes.
I made cpu_to_l2cache() use of_find_device_by_phandle() which should
work as well on pseries and should have the added advantage of working
on others too (ie. it will use device_node->linux_phandle to do the
compare, which is setup with the base phandle and overriden by the
ibm,phandle if there is one).
I also did a few cleanups of printk's and error checking.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Segher Boessenkool @ 2008-07-28 7:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <9e4733910807271500l23fd2b12n940197474a5291df@mail.gmail.com>
>> A reasonable "compatible" value would be something like
>> "serial-eeprom-24c32".
>> You can go a little bit more generic than that, if you write up in
>> your binding how the driver should figure out the device size and
>> the protocol used.
>
> Matching on "serial-eeprom-24c32" requires me to convince the at24
> authors to add that string as an alias binding for their driver.
No, it requires the IIC subsystem to get fixed and not use OF
"compatible" values as module alias names.
> How
> about "serial-eeprom,24c32" or "generic,24x32"?
Neither "serial-eeprom" nor "generic" is the name of a vendor, so
no. The comma has a well-defined meaning. Why would a comma be
easier than a dash for your device matching code, anyway?
Segher
^ permalink raw reply
* Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Trent Piepho @ 2008-07-28 8:31 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <20080727022116.GN12191@secretlab.ca>
On Sat, 26 Jul 2008, Grant Likely wrote:
> On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote:
>> Add bindings to support LEDs defined as of_platform devices in addition to
>> the existing bindings for platform devices.
>
>> +- gpios : Should specify the LED GPIO.
>
> Question: it is possible/desirable for a single LED to be assigned
> multiple GPIO pins? Say, for a tri-color LED? (I'm fishing for
> opinions; I really don't know if it would be a good idea or not)
Good question. The Linux LED layer has no concept of multi-color LEDs, so
it's more difficult that just adding support to the gpio led driver. I have
a device with a tri-color red/green/orange LED and this posed some
difficulty. It's defined as independent red and greed LEDs, which is mostly
fine, except I wanted it to flash orange. I can make both the red LED and
green LED flash, but there is nothing to insure their flashing remains in
sync.
Other OF bindings allow multiple GPIOs to be listed in a gpios property, so
that's not a problem if someone wants to do that. There would need to be a
way to define what the gpios mean. I don't think it's worthwhile to come up
with a binding for that until there is a real user.
>> +- function : (optional) This parameter, if present, is a string
>> + defining the function of the LED. It can be used to put the LED
>> + under software control, e.g. Linux LED triggers like "heartbeat",
>> + "ide-disk", and "timer". Or it could be used to attach a hardware
>> + signal to the LED, e.g. a SoC that can configured to put a SATA
>> + activity signal on a GPIO line.
>
> This makes me nervous. It exposes Linux internal implementation details
> into the device tree data. If you want to have a property that
> describes the LED usage, then the possible values and meanings should be
> documented here.
Should it be a linux specific property then? I could list all the current
linux triggers, but enumerating every possible function someone might want
to assign to an LED seems hopeless.
>> + led.default_trigger =
>> + of_get_property(child, "linux,default-trigger", NULL);
>
> This isn't in the documented binding. I assume that you mean 'function'
> here?
Looks like I emailed the wrong patch file. That should be changed to
"function" and there are a few cosmetic changes that are missing.
^ permalink raw reply
* Re: mISDN still breaking the allmodconfig build...
From: Karsten Keil @ 2008-07-28 8:40 UTC (permalink / raw)
To: Marcel Holtmann
Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds,
David Miller
In-Reply-To: <7949EA87-4340-4353-AFC9-79A718B95DF0@holtmann.org>
Hi Marcel,
On Mon, Jul 28, 2008 at 03:13:21AM +0200, Marcel Holtmann wrote:
> Hi Dave,
>
> >>>More fallout from the premature mISDN driver merge:
> >>>
> >>>drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> >>>running on big endian machines now"
> >>
> >>is that only the HFC driver or the whole mISDN stack?
> >>
> >>I know that the two old ISDN stacks where really bad on big endian,
> >>but my assumption was that we did sort this out in the end.
> >
> >One of the two mISDN drivers uses the deprecated virt_to_bus()
> >interface for handling DMA addresses (that doesn't even work on many
> >x86 systems these days) and the other mISDN driver gives the above
> >big-endian compile time error.
> >
> >In short, this driver was not ready for merging at all.
>
> I am not defending it and agree that this driver should have had at
> least one test run in linux-next.
Yes my fault, sorry.
> However mISDN is a whole ISDN stack.
> So does mISDN has an issue too or do we only have a really broken
> driver. Karsten?
Yes this is only a issue of the hardware layer not of the stack.
OK the driver are based on the old drivers already in HiSax and for
virt_to_bus() I never got a complain before and yes I already have some patches
to solve the endian issues in the HFC driver, but it was not finaly
confirmed, that all this work now on big endian systems and my PPC system
unfortunately died some time ago, so I did leave it as it is, but with
the wrong option, instead to mark it X86 only I let it break.
On the other side this remained me to check the big endian thing again ;-)
--
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
^ permalink raw reply
* Re: [RFC] cpm_uart: Add generic clock API support to set baudrates
From: Laurent Pinchart @ 2008-07-28 8:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <01409579-8A92-4A16-9C66-7C751BB348E7@kernel.crashing.org>
This patch introduces baudrate setting support via the generic clock API.
When present the optional device tree clock property is used instead of
fsl-cpm-brg. Platforms can then define complex clock schemes, to output
the serial clock on an external pin for instance.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
drivers/serial/cpm_uart/cpm_uart.h | 1 +
drivers/serial/cpm_uart/cpm_uart_core.c | 26 +++++++++++++++++++-------
2 files changed, 20 insertions(+), 7 deletions(-)
On Friday 25 July 2008, Kumar Gala wrote:
> I'm having problems applying due to mailer formatting.
*sigh* I'll definitely have to fix GPG support in kmail. Sorry about the
annoyance.
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index d0c55e2..2e64c03 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -77,6 +77,7 @@ struct uart_cpm_port {
unsigned char *rx_buf;
u32 flags;
void (*set_lineif)(struct uart_cpm_port *);
+ struct clk *clk;
u8 brg;
uint dp_addr;
void *mem_addr;
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index d3c19e5..438e460 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -44,6 +44,7 @@
#include <linux/fs_uart_pd.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
+#include <linux/clk.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -641,7 +642,10 @@ static void cpm_uart_set_termios(struct uart_port *port,
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
- cpm_set_brg(pinfo->brg - 1, baud);
+ if (pinfo->clk)
+ clk_set_rate(pinfo->clk, baud);
+ else
+ cpm_set_brg(pinfo->brg - 1, baud);
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -991,13 +995,21 @@ static int cpm_uart_init_port(struct device_node *np,
int ret;
int i;
- data = of_get_property(np, "fsl,cpm-brg", &len);
- if (!data || len != 4) {
- printk(KERN_ERR "CPM UART %s has no/invalid "
- "fsl,cpm-brg property.\n", np->name);
- return -EINVAL;
+ data = of_get_property(np, "clock", NULL);
+ if (data) {
+ struct clk *clk = clk_get(NULL, (const char*)data);
+ if (!IS_ERR(clk))
+ pinfo->clk = clk;
+ }
+ if (!pinfo->clk) {
+ data = of_get_property(np, "fsl,cpm-brg", &len);
+ if (!data || len != 4) {
+ printk(KERN_ERR "CPM UART %s has no/invalid "
+ "fsl,cpm-brg property.\n", np->name);
+ return -EINVAL;
+ }
+ pinfo->brg = *data;
}
- pinfo->brg = *data;
data = of_get_property(np, "fsl,cpm-command", &len);
if (!data || len != 4) {
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: [PATCHv4] cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Laurent Pinchart @ 2008-07-28 8:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <1C0E875E-1FFA-4FDB-BF87-36D9A03939E0@kernel.crashing.org>
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Cc: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/platforms/Kconfig | 2 +
arch/powerpc/sysdev/cpm2.c | 11 ++++
arch/powerpc/sysdev/cpm_common.c | 123 ++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/cpm.h | 3 +
4 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..7e67e26 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -280,6 +280,8 @@ config CPM2
depends on MPC85xx || 8260
select CPM
select PPC_LIB_RHEAP
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 5a6c5df..9311778 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -377,3 +377,14 @@ void cpm2_set_pin(int port, int pin, int flags)
else
clrbits32(&iop[port].odr, pin);
}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,cpm2-pario-bank")
+ cpm2_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
+
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..b957a48 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -19,6 +19,8 @@
#include <linux/init.h>
#include <linux/of_device.h>
+#include <linux/spinlock.h>
+#include <linux/of.h>
#include <asm/udbg.h>
#include <asm/io.h>
@@ -28,6 +30,10 @@
#include <mm/mmu_decl.h>
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+#include <linux/of_gpio.h>
+#endif
+
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
static u32 __iomem *cpm_udbg_txdesc =
(u32 __iomem __force *)CONFIG_PPC_EARLY_DEBUG_CPM_ADDR;
@@ -198,3 +204,120 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
+
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+
+struct cpm2_ioports {
+ u32 dir, par, sor, odr, dat;
+ u32 res[3];
+};
+
+struct cpm2_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm2_gpio32_chip *
+to_cpm2_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm2_gpio32_chip, mm_gc);
+}
+
+static void cpm2_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+
+ cpm2_gc->cpdata = in_be32(&iop->dat);
+}
+
+static int cpm2_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ return !!(in_be32(&iop->dat) & pin_mask);
+}
+
+static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
+
+ if (value)
+ cpm2_gc->cpdata |= pin_mask;
+ else
+ cpm2_gc->cpdata &= ~pin_mask;
+
+ out_be32(&iop->dat, cpm2_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm2_gc->lock, flags);
+}
+
+static int cpm2_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ setbits32(&iop->dir, pin_mask);
+
+ cpm2_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm2_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ clrbits32(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm2_gpiochip_add32(struct device_node *np)
+{
+ struct cpm2_gpio32_chip *cpm2_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm2_gc = kzalloc(sizeof(*cpm2_gc), GFP_KERNEL);
+ if (!cpm2_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm2_gc->lock);
+
+ mm_gc = &cpm2_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm2_gpio32_save_regs;
+ of_gc->gpio_cells = 2;
+ gc->ngpio = 32;
+ gc->direction_input = cpm2_gpio32_dir_in;
+ gc->direction_output = cpm2_gpio32_dir_out;
+ gc->get = cpm2_gpio32_get;
+ gc->set = cpm2_gpio32_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+#endif /* CONFIG_CPM2 || CONFIG_8xx_GPIO */
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index ede38ff..23b72ee 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -3,6 +3,7 @@
#include <linux/compiler.h>
#include <linux/types.h>
+#include <linux/of.h>
/* Opcodes common to CPM1 and CPM2
*/
@@ -99,4 +100,6 @@ void __iomem *cpm_muram_addr(unsigned long offset);
dma_addr_t cpm_muram_dma(void __iomem *addr);
int cpm_command(u32 command, u8 opcode);
+int cpm2_gpiochip_add32(struct device_node *np);
+
#endif
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: mISDN still breaking the allmodconfig build...
From: Alan Cox @ 2008-07-28 9:20 UTC (permalink / raw)
To: Sean MacLennan
Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds,
David Miller
In-Reply-To: <20080727204805.59f55dda@lappy.seanm.ca>
On Sun, 27 Jul 2008 20:48:05 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Mon, 28 Jul 2008 10:13:42 +1000
> "Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
>
> > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote:
> > > More fallout from the premature mISDN driver merge:
> > >
> > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> > > running on big endian machines now"
> >
> > Lovely...
>
> mISDN is notoriously bad on big endian machines.
In which case it really should not be in Linus tree but in linux-next.
Karsten - will you ask Linus to revert mISDN so it can go into linux-next
instead and get cleaned up in the right place ?
Alan
^ permalink raw reply
* Re: [PATCH 1/2] leds: make the default trigger name const
From: Anton Vorontsov @ 2008-07-28 9:53 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807271304350.26456@t2.domain.actdsltmp>
On Sun, Jul 27, 2008 at 06:56:49PM -0700, Trent Piepho wrote:
> On Sun, 27 Jul 2008, Stephen Rothwell wrote:
> > On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
> >> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote:
> >>> The default_trigger fields of struct gpio_led and thus struct led_classdev
> >>> are pretty much always assigned from a string literal, which means the
> >>> string can't be modified. Which is fine, since there is no reason to
> >>> modify the string and in fact it never is.
> >>>
> >>> But they should be marked const to prevent such code from being added, to
> >>> prevent warnings if -Wwrite-strings is used and when assigned from a
> >>> constant string other than a string literal (which produces a warning under
> >>> current kernel compiler flags), and for general good coding practices.
> >>>
> >>> Signed-off-by: Trent Piepho <tpiepho@freescale.com>
> >> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > I would ack this as well, except I am not sure what tree this patch is
> > against. In the current powerpc next tree,
>
> It was against powerpc next from Jul 22nd, current at the time I made the
> patch. It looks like that file has changed in the last few days. There is a
> patch from Anton Vorontsov, "leds: mark led_classdev.default_trigger as
> const", which adds const to one of the structs I modified, but doesn't get the
> other one (struct gpio_led).
Yes, I posted the patch for my version of OF GPIO LEDs, which didn't use
struct gpio_led's default_trigger.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-28 9:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, Linux Kernel list
Hi Linus !
I lied :-) There is a couple more features coming in. Mostly Roland
tracehook stuff which came in a bit late but since the generic bits
are in and he had some powerpc support ready, we felt like it was
something worth having. There's also some SPI bits from Grant who
were around but took some time to be fully acked and some stuff to
expose our cache topology through sysfs that we wanted but took a
bit longer to finish than expected.
The rest is mostly fixes.
It's all in:
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
(Hopefully no silly non-printable character this time, at least
nothing I manage to spot with evo but who knows...)
Cheers,
Ben.
arch/powerpc/Kconfig | 1
arch/powerpc/kernel/entry_32.S | 17 +-
arch/powerpc/kernel/entry_64.S | 10 +
arch/powerpc/kernel/legacy_serial.c | 44 ++--
arch/powerpc/kernel/process.c | 8 -
arch/powerpc/kernel/prom_init.c | 39 ----
arch/powerpc/kernel/ptrace.c | 54 ++---
arch/powerpc/kernel/setup-common.c | 24 --
arch/powerpc/kernel/setup_64.c | 3
arch/powerpc/kernel/signal.c | 23 ++
arch/powerpc/kernel/smp.c | 119 ++++++++++-
arch/powerpc/kernel/stacktrace.c | 1
arch/powerpc/kernel/sysfs.c | 311 ++++++++++++++++++++++++++++
arch/powerpc/kernel/vio.c | 6 -
arch/powerpc/mm/hugetlbpage.c | 9 +
arch/powerpc/platforms/powermac/setup.c | 72 ++++++
arch/powerpc/platforms/powermac/udbg_scc.c | 12 +
arch/powerpc/platforms/pseries/cmm.c | 8 +
drivers/net/ibmveth.c | 8 -
drivers/of/Kconfig | 6 +
drivers/of/Makefile | 1
drivers/of/base.c | 88 ++++++++
drivers/of/of_i2c.c | 64 ------
drivers/of/of_spi.c | 93 ++++++++
drivers/spi/spi.c | 139 +++++++++----
include/asm-powerpc/pgtable-4k.h | 2
include/asm-powerpc/pgtable-64k.h | 2
include/asm-powerpc/pgtable-ppc32.h | 3
include/asm-powerpc/pgtable-ppc64.h | 4
include/asm-powerpc/ptrace.h | 1
include/asm-powerpc/signal.h | 3
include/asm-powerpc/smp.h | 2
include/asm-powerpc/syscall.h | 84 ++++++++
include/asm-powerpc/thread_info.h | 5
include/asm-powerpc/topology.h | 2
include/linux/of.h | 1
include/linux/of_spi.h | 18 ++
include/linux/spi/spi.h | 12 +
38 files changed, 1039 insertions(+), 260 deletions(-)
create mode 100644 drivers/of/of_spi.c
create mode 100644 include/asm-powerpc/syscall.h
create mode 100644 include/linux/of_spi.h
Benjamin Herrenschmidt (3):
powerpc/powermac: Use sane default baudrate for SCC debugging
powerpc/powermac: Fixup default serial port device for pmac_zilog
powerpc: Disable 64K hugetlb support when doing 64K SPU mappings
Grant Likely (3):
of: adapt of_find_i2c_driver() to be usable by SPI also
spi: split up spi_new_device() to allow two stage registration.
spi: Add OF binding support for SPI busses
Huang Weiyi (1):
powerpc: Removed duplicated include in stacktrace.c
Kumar Gala (2):
powerpc/booke: Clean up the hardware watchpoint support
powerpc: Fix 8xx build failure
Nathan Lynch (7):
powerpc: Fix vio build warnings
powerpc: kill useless SMT code in prom_hold_cpus
powerpc: register_cpu_online should be __cpuinit
powerpc: Update cpu_sibling_maps dynamically
powerpc: Make core sibling information available to userspace
powerpc: Make core id information available to userspace
powerpc: Show processor cache information in sysfs
Nick Piggin (1):
powerpc/mm: Implement _PAGE_SPECIAL & pte_special() for 64-bit
Roland McGrath (5):
powerpc: Call tracehook_signal_handler() when setting up signal frames
powerpc: Make syscall tracing use tracehook.h helpers
powerpc: Add asm/syscall.h with the tracehook entry points
powerpc: Add TIF_NOTIFY_RESUME support for tracehook
powerpc: Enable tracehook for the architecture
Stephen Rothwell (3):
powerpc/pseries: Fix CMO sysdev attribute API change fallout
ibmveth: Fix multiple errors with dma_mapping_error conversion
powerpc/vio: More fallout from dma_mapping_error API change
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox