On Sun, 6 Jul 2008 03:02:59 +0300 Pekka Enberg wrote:
> On Sat, Jul 05, 2008 at 08:41:39PM +0200, Vegard Nossum wrote:
> >> Single letters are bad because it hurts readability and limits the
> >> usefulness of the extension.
>
> On Sat, Jul 5, 2008 at 9:52 PM, Matthew Wilcox <[EMAIL PROTECTED]> w
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yeah, agreed, combined it's not an x86 topic anymore.
>
> [ There's some lkml trouble so i've missed the earlier patch. I'm not
> sure the email problem is on my side, see how incomplete the
> discussion is on lkml.org as well:
>
> http://lk
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jul 2008, Ingo Molnar wrote:
> >
> > applied (with the commit message below) to tip/x86/debug for v2.6.27
> > merging, thanks Linus. Can i add your SOB too?
>
> Sure, add my S-O-B. But I hope/assuem that you also added my earlier
> patch
On Sun, 6 Jul 2008, Ingo Molnar wrote:
>
> applied (with the commit message below) to tip/x86/debug for v2.6.27
> merging, thanks Linus. Can i add your SOB too?
Sure, add my S-O-B. But I hope/assuem that you also added my earlier patch
that added the support for '%pS' too? I'm not entirely su
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Still all happily untested, of course. And still with no actual
> > users converted.
>
> Ok, it's tested, and here's an example usage conversion.
>
> The diffstat pretty much says it all. It _does_ change the format of
> the stack trace entry a
On Sat, 2008-07-05 at 17:15 -0700, Grant Erickson wrote:
> + union {
> + /* Registers unique to EMAC4 implementations */
> + struct {
> + u32 iaht1; /* Reset, R */
> + u32 iaht2; /* Reset, R */
> +
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs ha
On Sat, Jul 05, 2008 at 08:41:39PM +0200, Vegard Nossum wrote:
>> Single letters are bad because it hurts readability and limits the
>> usefulness of the extension.
On Sat, Jul 5, 2008 at 9:52 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> I think you need a little warning noise that goes off in
Linus Torvalds wrote:
On Fri, 4 Jul 2008, Linus Torvalds wrote:
Still all happily untested, of course. And still with no actual users
converted.
Ok, it's tested, and here's an example usage conversion.
The diffstat pretty much says it all. It _does_ change the format of the
stack trace entr
On Sat, 2008-07-05 at 02:18 -0700, Grant Erickson wrote:
> --- a/drivers/net/ibm_newemac/emac.h
> +++ b/drivers/net/ibm_newemac/emac.h
> @@ -41,14 +41,7 @@ struct emac_regs {
> u32 vtpid; /* Reset, R, T */
> u32 vtci; /* Reset, R, T */
> u32 ptr;
On Fri, 4 Jul 2008, Linus Torvalds wrote:
>
> Still all happily untested, of course. And still with no actual users
> converted.
Ok, it's tested, and here's an example usage conversion.
The diffstat pretty much says it all. It _does_ change the format of the
stack trace entry a bit, but I do
On Sat, 2008-07-05 at 23:51 +0200, Arnd Bergmann wrote:
>
> It turned out that the firmware sets up the south bridge to never set the 'S'
> bit on incoming transactions, which overrides the IOPTE_SO_RW bits, on all
> existing cell hardware.
>
> This weak ordering gives the same ordering guarantee
On Saturday 05 July 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-07-05 at 15:43 +1000, Michael Ellerman wrote:
> > > The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all
> > > IOTPEs
> > > (for both the dynamic and fixed mappings) which enforces strong ordering
> > > of
>
On Sat, Jul 05, 2008 at 08:41:39PM +0200, Vegard Nossum wrote:
> Single letters are bad because it hurts readability and limits the
> usefulness of the extension.
I think you need a little warning noise that goes off in your head that
means "I might be overdesigning this". Linus' code is elegant
On Sat, 5 Jul 2008, Jan Engelhardt wrote:
>
> So, and what do you do when you run out of alphanumeric characters?
Did you actually look at my patch?
It's not a single alnum character. It's an arbitrary sequence of alnum
characters. IOW, my patch allows
%p6N
or something like that fo
On Sat, Jul 5, 2008 at 7:56 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jul 2008, Vegard Nossum wrote:
>> On Sat, Jul 5, 2008 at 1:33 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> > How about %p{feature}?
>
> No.
>
> I _expressly_ chose '%p[alphanumeric]*' because it's basically
>
On Saturday 2008-07-05 19:56, Linus Torvalds wrote:
>> >
>> > How about %p{feature}?
>
>No.
>
>I _expressly_ chose '%p[alphanumeric]*' because it's basically
>totally insane to have that in a *real* printk() string: the end result
>would be totally unreadable.
So, and what do you do when you ru
On Sat, 5 Jul 2008, Vegard Nossum wrote:
> On Sat, Jul 5, 2008 at 1:33 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >
> > On Saturday 2008-07-05 00:01, Andrew Morton wrote:
> >>
> >>We don't know how much interest there would be in churning NIPQUAD from
> >>the net guys. Interestingly, there
Hi,
On Jul 4, 2008, at 7:54 AM, Robert Jennings wrote:
To support Cooperative Memory Overcommitment (CMO), we need to check
for failure from some of the tce hcalls.
These changes for the pseries platform affect the powerpc
architecture;
patches for the other affected platforms are included
On Sat, Jul 5, 2008 at 3:32 AM, André Schwarz
<[EMAIL PROTECTED]> wrote:
> It's a MPC5200B. I thought that the "b"-Option has already out of use after
> reading about this a few weeks ago ... maybe I misinterpreted.
No, I'm *toying* with the idea, but I haven't decided yet.
> > I think it would b
On Saturday 2008-07-05 15:50, Vegard Nossum wrote:
>
>I think the most elegant solution would be a macro similar to the
>initcall macros, that adds the custom extensions to a table which is
>defined by a special linker section. This allows complete
>decentralization, but I don't think it's possibl
On Sat, Jul 5, 2008 at 3:24 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Saturday 2008-07-05 14:52, Vegard Nossum wrote:
>>> On Saturday 2008-07-05 00:01, Andrew Morton wrote:
We don't know how much interest there would be in churning NIPQUAD from
the net guys. Interestingly,
On Sat, Jul 5, 2008 at 1:33 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Saturday 2008-07-05 00:01, Andrew Morton wrote:
>>
>>We don't know how much interest there would be in churning NIPQUAD from
>>the net guys. Interestingly, there's also %C (wint_t) which is a
>>32-bit quantity. So we
On Saturday 2008-07-05 14:52, Vegard Nossum wrote:
>> On Saturday 2008-07-05 00:01, Andrew Morton wrote:
>>>
>>>We don't know how much interest there would be in churning NIPQUAD from
>>>the net guys. Interestingly, there's also %C (wint_t) which is a
>>>32-bit quantity. So we could just go and
On Saturday 05 July 2008 00:01, Andrew Morton wrote:
> > > We also jump through hoops to print things like sector_t and
> > > resource_size_t. They always need to be cast to `unsiged long long',
> > > which generates additional stack space and text in some setups.
> >
> > The thing is that GCC ch
On Saturday 2008-07-05 00:01, Andrew Morton wrote:
>
>We don't know how much interest there would be in churning NIPQUAD from
>the net guys. Interestingly, there's also %C (wint_t) which is a
>32-bit quantity. So we could just go and say "%C prints an ipv4
>address" and be done with it. But the
Hi Scott,
>> I'm going to move all the Freescale SoC related bindings into this new
>> file. One of the aspects of the new file is we will NOT having an
>> ordinal heading index.
>
> How about splitting up like this:
>
> Documentation/powerpc/device-tree/fsl/cpm.txt
> Documentation/powerpc/de
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
Documentation/powerpc/device-tree/fsl/cpm/gpio.txt | 38
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/device-tree/fsl/cpm/gpio.txt
diff --git a/Documentation/powerpc/devic
Grant,
thanks for the quick feedback - I'll try to improve.
Hopefully monday morning will be on time
Comments inline.
regards,
André
Grant Likely wrote:
On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Giga
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs ha
30 matches
Mail list logo
