On Mon, 28 Jul 2008 16:31:56 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> > > 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 o
On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote:
> If q->elevator is NULL, the media-bay code might mess up the ref
> counting of the request queue...
Well, all I do is call into Bart's new helpers to scan for or unregister
devices ...
Ben.
_
dtc does not use the input() function in flex. Apparently on some gcc
versions the unused function will cause warnings. Therefore, this
patch removes the function by using the 'noinput' option to flex.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/dtc-lexer.l
==
In commit b6d80a20fc293f3b995c3ce1a6744a5574192125, we renamed all
libfdt functions to be prefixed with fdt_ or _fdt_ to minimise the
chance of collisions with things from whatever package libfdt is
embedded in, pulled into the libfdt build via that environment's
libfdt_env.h.
Except... I missed o
On Mon, Jul 28, 2008 at 05:13:14PM -0400, Vivek Goyal wrote:
>
> o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
> equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
> CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
> u
On Mon, Jul 28, 2008 at 10:28:22PM -0400, Vivek Goyal wrote:
> On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote:
> > On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:
> > > Vivek Goyal <[EMAIL PROTECTED]> writes:
> > >
> > > > Hi All,
> > > >
> > > > How does following
On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> Hi
>
> The powerpc lpar code adds a prefered console at a very early state,
> during arch_setup. This runs even before the console setup from the
> command line and takes preference.
>
> This patch moves the prefered console setup into an
On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote:
> On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <[EMAIL PROTECTED]> writes:
> >
> > > Hi All,
> > >
> > > How does following series of patches look like. I have moved
> > > elfcorehdr_addr out of vmc
On Monday, July 28, 2008 5:52 pm Stephen Rothwell wrote:
> Hi Jesse,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/iommu.c:54: error: static declaration of
> 'iommu_num_pages' follows non-static declaration
> include/linux/iommu-helper.h:11: error:
On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > Hi All,
> >
> > How does following series of patches look like. I have moved
> > elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
> > of crash dump to make sur
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Jesse,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/kernel/iommu.c:54: error: static declaration of 'iommu_num_pages'
follows non-static declaration
include/linux/iommu-helper.h:11: error: previous declaration of
'iommu_num_pages' was here
Caused by comm
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Com
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> +static int move_to_huge_pages(struct linux_binprm *bprm,
> + struct vm_area_struct *vma, unsigned
> long shift)
> +{
> + struct mm_struct *mm = vma->vm_mm;
> + struct vm_area_struct *new_vma;
> +
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> This patch stack introduces a personality flag that indicates the
> kernel
> should setup the stack as a hugetlbfs-backed region. A userspace
> utility
> may set this flag then exec a process whose stack is to be backed by
> hugetlb pages.
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> +static unsigned long personality_page_align(unsigned long addr)
> +{
> + if (current->personality & HUGETLB_STACK)
> +#ifdef CONFIG_STACK_GROWSUP
> + return HPAGE_ALIGN(addr);
> +#else
> + return addr & HP
Can somebody help me with a few indications regarding how to obtain a
relocatable vmlinux when compiling the linux kernel for ppc32 ?
For powerpc, by default, the building process results in an ELF 32-bit
MSB executable statically linked. I saw that for other architectures it
builds, by defaul
On Tue, Jul 29, 2008 at 07:15:36AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-28 at 09:06 -0700, Linus Torvalds wrote:
> >
> > On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> > >
> > > It should be
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> >
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Hi All,
>
> How does following series of patches look like. I have moved
> elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
> of crash dump to make sure that it can be worked with even when
> CONFIG_PROC_VMCORE is disabled and CONFI
On Mon, 28 Jul 2008, Dave Hansen wrote:
> On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
> >
> > This patch stack introduces a personality flag that indicates the
> > kernel
> > should setup the stack as a hugetlbfs-backed region. A userspace
> > utility
> > may set this flag then exec a p
On Mon, 2008-07-28 at 10:20 -0600, Grant Likely wrote:
> On Mon, Jul 28, 2008 at 09:06:35AM -0700, Linus Torvalds wrote:
> >
> >
> > On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> > >
> > > It should be
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> > >
>
On Mon, 2008-07-28 at 09:06 -0700, Linus Torvalds wrote:
>
> On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> >
> > It should be
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> >
> > Ben seems to have copied from one of Paul's pull requests.
>
> Ok, that one wo
On Mon, 2008-07-28 at 08:40 -0700, Linus Torvalds wrote:
>
> On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > It's all in:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> It doesn't really seem to be. I get "Already up-to-date.", and the top
> commi
Hi
The powerpc lpar code adds a prefered console at a very early state,
during arch_setup. This runs even before the console setup from the
command line and takes preference.
This patch moves the prefered console setup into an arch_initcall which
runs later and allows the specification of the cor
On Jul 28, 2008, at 1:50 PM, Paul Gortmaker wrote:
This file contains 8 yr. old board specific information that was for
the now gone ppc implementation, and it pre-dates widespread u-boot
support. Any of the technical details of the board memory map would
be
more appropriately captured in a
> From: Kim Phillips
> Sent: Monday, July 28, 2008 1:31 PM
> > ## Booting kernel from Legacy Image at 01001000 ...
>
> > ## Flattened Device Tree blob at 0100
>
> so the dtb is being loaded only 0x1000 bytes from the kernel,
> yet it's probably bigger than that. Can you try different
> loa
Currently the memory slice that holds the process stack is always initialized
to hold small pages. This patch defines the weak function that is declared
in the previos patch to convert the stack slice to hugetlb pages.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
C
There are two kinds of "Shared" hugetlbfs mappings:
1. using internal vfsmount use ipc/shm.c and shmctl()
2. mmap() of /hugetlbfs/file with MAP_SHARED
There is one kind of private: mmap() of /hugetlbfs/file file with
MAP_PRIVATE
This patch adds a second class of "private" hugetlb-backed map
Currently do_unmap pre-checks the unmapped address range against the
valid address range for the process size. However during initial setup
the stack may actually be outside this range, particularly it may be
initially placed at the 64 bit stack address and later moved to the
normal 32 bit stack l
This patch adds a personality flag that requests hugetlb pages be used for
a processes stack. It adds a helper function that chooses the proper ALIGN
macro based on tthe process personality and calls this function from
setup_arg_pages when aligning the stack address.
Signed-off-by: Andy Whitcroft
This patch allows a processes stack to be backed by huge pages on request.
The personality flag defined in a previous patch should be set before
exec is called for the target process to use a huge page backed stack.
When the hugetlb file is setup to back the stack it is sized to fit the
ulimit for
Certain workloads benefit if their data or text segments are backed by
huge pages. The stack is no exception to this rule but there is no
mechanism currently that allows the backing of a stack reliably with
huge pages. Doing this from userspace is excessively messy and has some
awkward restriction
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
>> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
>>> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
>>> [...]
>>> +- function : (optional) This parameter, if present, is a s
On Mon, Jul 28, 2008 at 2:44 PM, mike zheng <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6
> provided by Freescale. Unfortunate we are using Kernel2.4. Is there
> any exist BSP of this board on Kernel2.4? Or a BSP of similar board on
>
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> > +- function : (optional) This parameter, if present, is a string
> > + defining the function of the L
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> > +- function : (optional) This parameter, if present, is a string
> > + defining the function of the L
This file contains 8 yr. old board specific information that was for
the now gone ppc implementation, and it pre-dates widespread u-boot
support. Any of the technical details of the board memory map would be
more appropriately captured in a dts if I revive it as powerpc anyway.
Signed-off-by: Pau
Hi All,
Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6
provided by Freescale. Unfortunate we are using Kernel2.4. Is there
any exist BSP of this board on Kernel2.4? Or a BSP of similar board on
Kernel2.4?
Thanks in advance,
Mike
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> [...]
> +- 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.
On Mon, 28 Jul 2008 11:10:47 -0500
"Sparks, Sam" <[EMAIL PROTECTED]> wrote:
> ## Booting kernel from Legacy Image at 01001000 ...
> ## Flattened Device Tree blob at 0100
so the dtb is being loaded only 0x1000 bytes from the kernel, yet it's
probably bigger than that. Can you try different l
> From: Grant Likely
> Sent: Monday, July 28, 2008 1:03 PM
> Does your dts source file already have a chosen node? There
> had been an issue where u-boot cacks if chosen was pre-created.
Nope, there is no reference to "chosen" in the dts
--Sam
___
Li
On Mon, Jul 28, 2008 at 10:02:04PM +0400, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > I'd rather see the device tree provide 'hints' toward the expected usage
> > and if a platform needs something specific, then the platform specific
> > code should se
On Mon, Jul 28, 2008 at 12:49:19PM -0500, Sparks, Sam wrote:
> No luck there, either. I ran into a issue with space a year ago, and was
> getting the FDT_ERR_NOSPACE error until I added the -S 0x3000 option.
> This looks like something completely different.
Does your dts source file already have a
On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
[...]
> > >> +- 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",
> > >>
> From: Grant Likely
> Sent: Monday, July 28, 2008 12:17 PM
>
> On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote:
> > Hello All,
> >
> > I am trying to boot the mpc8349-mITX board with Compact
> flash support,
> > and am unable to boot the Linux kernel. Here is the pertinant
> > ver
On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote:
> Hello All,
>
> I am trying to boot the mpc8349-mITX board with Compact flash support,
> and am unable to boot the Linux kernel. Here is the pertinant versioning
> information:
> DTC 1.2.0-rc2-g17773b0e
> U-Boot 1.3.4-rc1-00012-g1953d12
On Mon, Jul 28, 2008 at 01:31:47AM -0700, Trent Piepho wrote:
> 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.
On Mon, Jul 28, 2008 at 11:34:35AM -0500, T Ziomek wrote:
> On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
> . . .
> > Come to think of it, I'd support just removing the zImage symlink
> > entirely to eliminate confusion so that everyone knows that 'make
> > zImage' is the 'make all
On Sun, Jul 27, 2008 at 02:49:28PM -0700, David Brownell wrote:
> On Friday 25 July 2008, Grant Likely wrote:
> > I don't know what to do with these patches. I'd really like to see them
> > in .27, and now that akpm has cleared his queue, the prerequisite patch
> > has been merged so they are read
On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
. . .
> Come to think of it, I'd support just removing the zImage symlink
> entirely to eliminate confusion so that everyone knows that 'make
> zImage' is the 'make all' for default image targets.
That ("zImage" means all default image
On Mon, Jul 28, 2008 at 04:25:54PM +0200, Guillaume Dargaud wrote:
> Hello all,
> there's something I miss here. I'd like to setup a MAC address in
> software at the start of the boot process. I'm trying to figure out where
> this is done in the kernel code.
> I'm on a custom variant of a Xilinx
On Mon, Jul 28, 2008 at 09:06:35AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> >
> > It should be
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> >
> > Ben seems to have copied from one of Paul's pull requests.
>
> Ok, t
Hello All,
I am trying to boot the mpc8349-mITX board with Compact flash support,
and am unable to boot the Linux kernel. Here is the pertinant versioning
information:
DTC 1.2.0-rc2-g17773b0e
U-Boot 1.3.4-rc1-00012-g1953d12
Linux-2.6.26-05752-g93ded9b
I've built the DTB using the following two co
On Tue, 29 Jul 2008, Stephen Rothwell wrote:
>
> It should be
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> Ben seems to have copied from one of Paul's pull requests.
Ok, that one worked for me.
Ben, I'm sure some day you'll get it right on the first try.
Hi Linus,
On Mon, 28 Jul 2008 08:40:44 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > It's all in:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> It doesn't really seem to be. I get "Alrea
On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote:
>
> It's all in:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
It doesn't really seem to be. I get "Already up-to-date.", and the top
commit there seems to be from July 3..
Forgot to push?
> (Hopefully no silly
Fix cut-and-paste error in the size setting for ptrace buffers for VSX.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
===
In PTRACE_GET/SETVSRREGS, we should be using the thread we are
ptracing rather than current.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
==
Below are a few bug fixes for VSX ptrace for 2.6.27.
Thanks to Luis Machado for helping find these with his VSX GDB work.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fix bug where PTRACE_GET/SETVSRREGS are not connected for 32 bit processes.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace32.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
===
On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
> 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-
On Mon, 28 Jul 2008, Ingo Molnar wrote:
> * Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> > I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a
> > private, config-user-invisible, specific-to-a-few-arches thing): what
> > one wants to configure is how far to sacrifice cpu performan
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
> [PATCH] sched: move sched_clock before first use
>
> Move sched_clock() up to stop warning: weak declaration of
> `sched_clock' after first use results in unspecified behavior (if
> -fno-unit-at-a-time).
>
> Signed-off-by: Hugh Dickins <[EMAIL PROTE
Hello all,
there's something I miss here. I'd like to setup a MAC address in software
at the start of the boot process. I'm trying to figure out where this is
done in the kernel code.
I'm on a custom variant of a Xilinx ML405 card, still in PPC arch.
So it appears to be going in the arch/ppc/bo
On Sat, Jul 26, 2008 at 10:36:42PM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2008-07-26 at 12:02 +0100, Hugh Dickins wrote:
> >
> > Hmm, perhaps it is doing sibling calls differently even without the
> > explicit -fno-optimize-sibling-calls (but when I add that option,
> > the vmlinux size do
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
Laurent informed me I missed one CPM related patch:
'cpm2: Rework baud rate generators configuration to support external
clocks.'
- k
to receive the following updates:
On Jul 22, 2008, at 11:00 AM, Laurent Pinchart wrote:
The CPM2 BRG setup functions cpm_setbrg and cpm2_fastbrg don't
support external
clocks. This patch adds a new exported __cpm2_setbrg function that
takes the
clock rate and clock source as extra parameters, and moves
cpm_setbrg and
cpm2_
Karsten Keil wrote:
[...]
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
Karsten, do you have those patches available somewhere ?
I could give it a try on 4xx with a 4s card in the near futur
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
to receive the following updates:
Sorry for taking so long on these. Being at OLS limited patch applying
ability last week. These are some CPM related patches that have
On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote:
i8259 PIC is disabled on MPC8610HPCD boards, thus currently rtc-cmos
driver fails to probe.
To fix the issue, we lookup the device tree for "chrp,iic" and
"pnpPNP,000" compatible devices, and if not found we do not assign RTC
IRQ and assuming
On Jul 24, 2008, at 11:36 AM, Laurent Pinchart wrote:
This patch replaces the get_mctrl/set_mctrl stubs with modem control
line
read/write access through the GPIO lib.
Available modem control lines are described in the device tree using
GPIO
bindings. The driver expect a GPIO pin for each
On Jul 28, 2008, at 3:42 AM, Laurent Pinchart wrote:
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 o
On Jul 28, 2008, at 3:43 AM, Laurent Pinchart wrote:
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
On Sun, Jul 27, 2008 at 12:56:04PM -0700, David Miller wrote:
> Yes, please.
>
> IMHO, this driver was really rushed in and that was a huge mistake.
> If it had gone through linux-next we could have tidied all of this
> stuff up in a less "rushed" manner.
Or just reviewed in at least some way..
_
On Mon, Jul 28, 2008 at 10:20:09AM +0100, Alan Cox wrote:
> On Sun, 27 Jul 2008 20:48:05 -0400
> Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 28 Jul 2008 10:13:42 +1000
> > "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote:
> >
> > > On Sun, 2008-07-27 at 17:02 -0700, David Miller wro
On Sun, Jul 27, 2008 at 06:07:36PM -0700, David Miller wrote:
> From: Marcel Holtmann <[EMAIL PROTECTED]>
> 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
> > > runnin
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 driv
On Mon, 2008-07-28 at 03:03 +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 sta
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 too
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 <[EMAIL PROTECTED]> wrote:
> >> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote:
> >>> The default_trigger fields of struct g
On Sun, 27 Jul 2008 20:48:05 -0400
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Jul 2008 10:13:42 +1000
> "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote:
> > > More fallout from the premature mISDN driver merge:
> > >
> >
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 11
arch/powe
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 Pinchar
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 pos
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
89 matches
Mail list logo
