Commit bc033b63bbfeb6c4b4eb0a1d083c650e4a0d2af8 (powerpc/mm: Fix
attribute confusion with htab_bolt_mapping()) moved the check for
whether we should make pages of the linear mapping executable from
htab_bolt_mapping into its callers, including htab_initialize.
A side-effect of this is that the
On Thu, 2008-08-28 at 16:38 +1000, Paul Mackerras wrote:
Commit bc033b63bbfeb6c4b4eb0a1d083c650e4a0d2af8 (powerpc/mm: Fix
attribute confusion with htab_bolt_mapping()) moved the check for
whether we should make pages of the linear mapping executable from
htab_bolt_mapping into its callers,
On Wednesday 27 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
Module parameter names should be short, so just minmax would
be a good name, but better put the module_param() line right
after that. If it's a bool type, I would just leave out the
initialization.
Ok. But leaving
On Wed, Aug 27, 2008 at 09:49:44AM +0200, Wolfram Sang wrote:
On Sat, Aug 23, 2008 at 10:57:21AM +0200, Arnd Bergmann wrote:
On Saturday 23 August 2008, Kevin Diggs wrote:
WARNING: externs should be avoided in .c files
#1137: FILE: powerpc/kernel/cpu/pll_if.c:369:
+ __asm__
On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote:
The following series of patches implement support for a relocatable
kernel by building it as a position-independent executable (PIE).
When the linker is given the -pie flag, it creates an executable that
contains dynamic relocations
On Aug 28, 2008, at 7:12 AM, David Woodhouse wrote:
On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote:
The following series of patches implement support for a relocatable
kernel by building it as a position-independent executable (PIE).
When the linker is given the -pie flag, it creates
On Thu, 28 Aug 2008, David Woodhouse wrote:
On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote:
The following series of patches implement support for a relocatable
kernel by building it as a position-independent executable (PIE).
When the linker is given the -pie flag, it creates an
On Fri, 22 Aug 2008 11:43:35 +0400
Ilya Yanok [EMAIL PROTECTED] wrote:
1. total_memory should be phys_addr_t not unsigned long
2. is_power_of_2() works with u32 so I just inlined (size (size-1)) != 0
instead.
Also this patch fixes default initialization: res-end should be 0x7fff
not
On Thursday 28 August 2008, Josh Boyer wrote:
1. total_memory should be phys_addr_t not unsigned long
2. is_power_of_2() works with u32 so I just inlined (size (size-1)) !=
0 instead.
Also this patch fixes default initialization: res-end should be
0x7fff not 0x8000.
On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
Hi Arjan,
On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote:
The original reported trace was during setup_system which is very early in
the boot.
But, of course, that version didn't have the necessary
On Thu, 2008-08-28 at 15:23 +0100, David Woodhouse wrote:
On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
Hi Arjan,
On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell [EMAIL PROTECTED]
wrote:
The original reported trace was during setup_system which is very early in
Hi, all:
Well, as described before, the problem happens at 0xc434
InstructionAccess+52: stw r12,64(r11). At this moment,
address translation is disabled and physical addresses are used, but r11
contains 0x03072da0 which is a physical address out of the range of 0x0
and 0x01ff. I
On Aug 27, 2008, at 6:43 PM, Scott Wood wrote:
Becky Bruce wrote:
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) ~_PAGE_HASHPTE);
#else
+ /*
+* We have to do the write of the 64b pte as 2 stores. This
+* code
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point and
concluded that I did in fact need the lwarx/stwcx. IIRC, it has to do
with other non-set_pte_at writers not necessarily holding the page table
lock. FYI, the existing 32-bit PTE code is doing atomic
Arnd Bergmann wrote:
On Wednesday 27 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
I think the module_exit() function should leave the frequency in a
well-defined state, so the easiest way to get there is probably
to delete the timer, and then manually set the frequency.
I really
On Thu, Aug 28, 2008 at 05:43:33PM +0800, Li Yang wrote:
+config USB_GADGET_FSL_QE
+ boolean Freescale QE/CPM USB Device Controller
+ depends on FSL_SOC (QUICC_ENGINE || CPM)
+ help
+Some of Freescale PowerPC processors have a Full Speed
+QE/CPM2 USB controller,
On Thursday 28 August 2008, Scott Wood wrote:
On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
I'm facing a situation where I need to call cpm2_clk_setup and
cpm2_set_pin from a device driver compiled as a module. Before
submitting a patch to export both functions, I'd like
David Woodhouse dwmw2 at infradead.org
Fri Aug 29 00:55:07 EST 2008
On Thu, 2008-08-28 at 15:23 +0100, David Woodhouse wrote:
On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
Hi Arjan,
On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell sfr at
canb.auug.org.au wrote:
The
On Thu, 28 Aug 2008, Arnd Bergmann wrote:
Not addressing this driver in particular, but the USB gadget layer in
general: This is a horrible interface, since every gadget driver exports
the same symbols, you can never build a kernel that includes more than
one gadget driver. Even if the
On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
I'm facing a situation where I need to call cpm2_clk_setup and
cpm2_set_pin from a device driver compiled as a module. Before
submitting a patch to export both functions, I'd like to make sure
there isn't a cleaner way to
Laurent Pinchart wrote:
On Thursday 28 August 2008, Scott Wood wrote:
On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
I'm facing a situation where I need to call cpm2_clk_setup and
cpm2_set_pin from a device driver compiled as a module. Before
submitting a patch to export
В Wed, 27 Aug 2008 10:36:20 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] пишет:
On Wed, 27 Aug 2008, Vitaly Bordug wrote:
A published errata for ppc440epx states, that when running Linux
with both EHCI and OHCI modules loaded, the EHCI module experiences
a fatal error when a high-speed
On Thu, 28 Aug 2008, Vitaly Bordug wrote:
This doesn't explain why the fatal error occurs.
On certain 44x set of SoCs, only one controller is able to function,
e.g. technically they are mutually exclusive.
There used to be recommendation to use only hi-speed or full-speed
devices with
On Thu, 28 Aug 2008, Scott Wood wrote:
Alan Stern wrote:
This was done deliberately. The relevant standards state that a USB
device can have no more than one peripheral interface.
Does building a kernel image that can run on different hardware without
rebuilding also violate the
Becky Bruce wrote:
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did in fact need the lwarx/stwcx. IIRC, it
has to do with other non-set_pte_at writers not necessarily
holding the page
Alan Stern wrote:
Your original post mentioned that the 440EPx has only one USB 2.0 host
port. Then how can you use a keyboard and memory stick at the same
time? You'd have to plug them into a hub -- in which case only one
controller would be needed, the one driving the hub. The patch would
Great, so *you* got my email, and I did not. I love our mailserver!
On Aug 28, 2008, at 3:28 PM, Scott Wood wrote:
Becky Bruce wrote:
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did
On Thu, 28 Aug 2008, Steven A. Falco wrote:
Alan Stern wrote:
Your original post mentioned that the 440EPx has only one USB 2.0 host
port. Then how can you use a keyboard and memory stick at the same
time? You'd have to plug them into a hub -- in which case only one
controller would be
On Thursday 28 August 2008, Alan Stern wrote:
On Thu, 28 Aug 2008, Scott Wood wrote:
Alan Stern wrote:
This was done deliberately. The relevant standards state that a USB
device can have no more than one peripheral interface.
Does building a kernel image that can run on different
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did in fact need the lwarx/stwcx. IIRC, it
has to do with other non-set_pte_at writers not necessarily holding
the page table lock.
Alan Stern wrote:
This was done deliberately. The relevant standards state that a USB
device can have no more than one peripheral interface.
Does building a kernel image that can run on different hardware without
rebuilding also violate the relevant standards?
And who's to say that there
I understand what you're saying, I've been here before :) However, I
was never able to convince myself that it's safe without the lwarx/
stwcx. There's hashing code that wanks around with the HASHPTE bit
doing a RMW without holding any lock (other than lwarx/stwcx-ing the
PTE
On Thu, 2008-08-28 at 17:33 -0400, Alan Stern wrote:
Is there some reason why it doesn't work already? All the patch does
is suspend the OHCI root hub when you plug in the memory stick -- but
the root hub should already be suspended.
Unless the memory stick is already plugged in when the
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
The current implementation of fdt_get_path() has a couple of bugs,
fixed by this patch.
First, contrary to its documentation, on success it returns the length
of the node's path, rather than 0. The testcase is correspondingly
wrong, and the patch fixes this as well.
Second, in some
35 matches
Mail list logo
