* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Paul Mackerras @ 2006-10-23 10:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1161308835.10524.108.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly and with separate implementations
> for 32 and 64 bits. identify_cpu() is also implemented in assembly and
> separately for 32 and 64 bits.
>
> This patch replaces them with a pair of C functions. The call sites are
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small change, and thus shouldn't cause any
> problem.
Unfortunately this:
> Index: linux-cell/include/asm-powerpc/cputable.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/cputable.h 2006-10-13 16:00:28.000000000 +1000
> +++ linux-cell/include/asm-powerpc/cputable.h 2006-10-13 16:19:51.000000000 +1000
> @@ -89,8 +89,7 @@ struct cpu_spec {
>
> extern struct cpu_spec *cur_cpu_spec;
>
> -extern void identify_cpu(unsigned long offset, unsigned long cpu);
> -extern void do_cpu_ftr_fixups(unsigned long offset);
> +extern struct cpu_spec *identify_cpu(unsigned long offset);
... breaks the ARCH=ppc build.
Paul.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] cell: use ppc_md->power_save instead of cbe_idle_loop
From: Benjamin Herrenschmidt @ 2006-10-23 10:16 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, cbe-oss-dev, Anthony J Marsala
In-Reply-To: <200610231152.07675.arnd.bergmann@de.ibm.com>
> + /*
> + * We need to call cbe_enable_pause_zero on each CPU
> + * before first entering power_save(). The most convenient
> + * place for this is ppc_md->idle, because that is called
> + * right before entering the idle loop.
> + */
> + ppc_md.idle_loop = cbe_enable_pause_zero;
I disagree here... this should be done in setup_cpu() for non-boot CPUs,
and sometime in setup_arch for the boot CPU.
Another option is to have the pm_control bit done once for all CPUs at
boot in setup_arch() or such, and the TSC_CELL SPR bit done
unconditionally in powersave...
Ben.
^ permalink raw reply
* [PATCH] cell: use ppc_md->power_save instead of cbe_idle_loop
From: Arnd Bergmann @ 2006-10-23 9:52 UTC (permalink / raw)
To: linuxppc-dev, paulus, cbe-oss-dev; +Cc: Olof Johansson, Anthony J Marsala
In-Reply-To: <20061020182203.7871d1b1@pb15>
This moves the cell idle function to use the default cpu_idle
with a special power_save callback, like all other platforms
except iSeries already do.
It also makes it possible to disable this power_save function
with a new powerpc-specific boot option "powersave=off".
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Anthony, can you verify that the new options works for you?
I've added this patch to my cell series, and want to submit
it for 2.6.20 if everyone's happy with it.
Index: linux-2.6/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linux-2.6/arch/powerpc/platforms/cell/pervasive.c
@@ -82,51 +82,24 @@ out:
spin_unlock_irq(&cbe_pervasive_lock);
}
-static void cbe_idle(void)
+static void cbe_power_save(void)
{
unsigned long ctrl;
- /* Why do we do that on every idle ? Couldn't that be done once for
- * all or do we lose the state some way ? Also, the pm_control
- * register setting, that can't be set once at boot ? We really want
- * to move that away in order to implement a simple powersave
+ /*
+ * go into low thread priority, medium priority will be
+ * restored for us after wake-up.
*/
- cbe_enable_pause_zero();
+ HMT_low();
- while (1) {
- if (!need_resched()) {
- local_irq_disable();
- while (!need_resched()) {
- /* go into low thread priority */
- HMT_low();
-
- /*
- * atomically disable thread execution
- * and runlatch.
- * External and Decrementer exceptions
- * are still handled when the thread
- * is disabled but now enter in
- * cbe_system_reset_exception()
- */
- ctrl = mfspr(SPRN_CTRLF);
- ctrl &= ~(CTRL_RUNLATCH | CTRL_TE);
- mtspr(SPRN_CTRLT, ctrl);
- }
- /* restore thread prio */
- HMT_medium();
- local_irq_enable();
- }
-
- /*
- * turn runlatch on again before scheduling the
- * process we just woke up
- */
- ppc64_runlatch_on();
-
- preempt_enable_no_resched();
- schedule();
- preempt_disable();
- }
+ /*
+ * atomically disable thread execution and runlatch.
+ * External and Decrementer exceptions are still handled when the
+ * thread is disabled but now enter in cbe_system_reset_exception()
+ */
+ ctrl = mfspr(SPRN_CTRLF);
+ ctrl &= ~(CTRL_RUNLATCH | CTRL_TE);
+ mtspr(SPRN_CTRLT, ctrl);
}
static int cbe_system_reset_exception(struct pt_regs *regs)
@@ -161,6 +134,13 @@ void __init cbe_pervasive_init(void)
if (!cpu_has_feature(CPU_FTR_PAUSE_ZERO))
return;
- ppc_md.idle_loop = cbe_idle;
+ /*
+ * We need to call cbe_enable_pause_zero on each CPU
+ * before first entering power_save(). The most convenient
+ * place for this is ppc_md->idle, because that is called
+ * right before entering the idle loop.
+ */
+ ppc_md.idle_loop = cbe_enable_pause_zero;
+ ppc_md.power_save = cbe_power_save;
ppc_md.system_reset_exception = cbe_system_reset_exception;
}
Index: linux-2.6/arch/powerpc/kernel/idle.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/idle.c
+++ linux-2.6/arch/powerpc/kernel/idle.c
@@ -39,13 +39,20 @@
#define cpu_should_die() 0
#endif
+static int __init powersave_off(char *arg)
+{
+ ppc_md.power_save = NULL;
+ return 0;
+}
+__setup("powersave=off", powersave_off);
+
/*
* The body of the idle task.
*/
void cpu_idle(void)
{
if (ppc_md.idle_loop)
- ppc_md.idle_loop(); /* doesn't return */
+ ppc_md.idle_loop(); /* usually does not return */
set_thread_flag(TIF_POLLING_NRFLAG);
while (1) {
^ permalink raw reply
* RE: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Li Yang-r58472 @ 2006-10-23 9:35 UTC (permalink / raw)
To: Paul Mackerras, Wood Scott-B07421; +Cc: linuxppc-dev
In-Reply-To: <17724.15919.790114.628418@cargo.ozlabs.ibm.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Paul
> Mackerras
> Sent: Monday, October 23, 2006 12:00 PM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] qe_ic: Do a sync when masking interrupts.
>=20
> Scott Wood writes:
>=20
> > This patch causes a sync do be done after masking a QE interrupt, to
> > ensure that the masking has completed before interrupts are enabled.
> > This allows the masking of the cascade IRQ to be removed without
causing
> > spurious interrupts.
>=20
> Hmmm. In general a sync having completed doesn't mean that previous
> MMIO stores have actually got to the device. Reading from a device
> register generally does ensure that previous writes have actually got
> to the device though - could you do that instead? I'm concerned that
> adding the sync is not a robust fix and is possibly only working due
> to fortuitous timing.
But an i/o read will be considerably slower than a sync, and it is in
the critical path of interrupt. I have tested the patch under
relatively heavy Ethernet load, and there is no spurious interrupt.
Maybe it is because the device is an SOC device and MMIO store completes
faster. I'm wondering if there is a standard test method to show if the
faster approach is sufficient or not.
- Leo=20
^ permalink raw reply
* Re: [PATCH] Fix the UCC rx tx clock of QE
From: Paul Mackerras @ 2006-10-23 8:22 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev
In-Reply-To: <995B09A8299C2C44B59866F6391D26351C2E54@zch01exm21.fsl.freescale.net>
Liu Dave-r63238 writes:
> CLK16 of CMXUCR3 and CMXUCR4 registers are missed in
> ucc_set_qe_mux_rxtx().
> This patch adds the CLK16 to the function. MPC8323EMDS board ethernet
> interface
> with RMII is use the CLK16 as the rx and tx clock.
The patch doesn't apply because your mailer has wrecked the
whitespace...
Paul.
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Benjamin Herrenschmidt @ 2006-10-23 6:36 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453B6A84.3050209@bplan-gmbh.de>
Ok, here's a batch of comments. They go on top of the comments I sent
about your device-tree, which you might want to make public.
Also note that the size of the patch is partially due to stale ##
and .orig files :)
In general, one big thing is: Don't bother with re-using the arch/ppc
code, API, .h etc... There is not enough re-use there to justify it (FEC
driver is new, serial can easily be changed, as for USB).
* /proc/ppc64/rtas changes: we need to continue that discussion
separately and ask for paulus point of view. I prefer /proc/powerpc
personally with a /proc/ppc64->/proc/powerpc symlink on 64 bits machines
only.
* mpc5k2_bestcomm.c (& helpers):
- name changes (mpc5200_bestcomm.c would be better)
- location change -> arch/powerpc/sysdev
- look into using rheap instead of your current sram bits (and I don't
care about being compatible with arch/ppc code).
- the whole sdma_io_va/pa/... looks like bullcrap to me. The bestcomm
interface should use the normal dma mapping APIs
- I don't like having those helpers like fec or ata helpers in that
file. I think we need to rethink the API between the bestcomm and the
drivers. I understand that part of this is related to the fact that the
tasks themselves in the bestcomm are tailored for various devices and
with different descriptor formats. That sucks. I suppose we can live
with that for now (with a bit more cleanup) but we should have a healthy
discussion on how to rework the whole thing properly.
In general, I think there's a lot more code in those files that would be
necessary ;)
* mpc5k2.c :
Well, to start with, I don't think we need that file at all :) A lot of
the stuff in there is completely unnecessary provided that you make
better use of the device-tree.
The main thing is: use of_platform devices, not platform devices, so
that you have a linkage with the device-tree. In fact, you could
register of platform devices for every direct children of your "buildin"
node (which is to be renamed, I hope, according to my comments about
your device-tree).
You'll even be able to make good use of some work I've been doing lately
for Cell by adding a call to a single function to the main chrp setup
code that will register for you all those devices. You might want to
keep PCI at the root of the tree for now though that won't even be
necessary.
The core of platform matching code will take care of matching devices to
drivers based on standard OF properties (name,device_type,compatible).
Drivers will use standard prom_parse.c functions to obtain resources
like addresses (instead of directly accessing "reg" property from a
useless helper) etc...
But first, let's get your device-tree in shape :)
* mpc5k2_pic.c :
This should go in arch/powerpc/sysdev (and be renamed as for other
files, something like mpc5200_pic.c would be fine).
There are several issues here, though some of them are definitely
related to the chip design being completely alien to common sense:
- enable/disable/end shouldn't be used that way anymore. use
mask/unmask and set the appropriate IRQ flow handler for your IRQs. That
is, basically, adapt your driver to genirq. That will simplify.
- You need to add an irq host, probably set it as default, with the
appropriate xlate, map, etc... routines as done by other controllers in
2.6.18.
- the if/else bits in enable/disable (to become mask/unmask) should
probably be changed into something a bit more sane. You have a large
freedom of chosing what kind of IRQ "hardware" numbers you use. Since
2.6.18 new irq code, there is no direct relationship anymore between a
linux irq number (virtual irq number) and a HW number manipulated by a
PIC. Thus you can do what you want with those HW numbers, like, for
example, using some top bits to represent the "base" (IRQ0...3, SDMA,
PERP, ...) and use bottom bits for the actual bit in the mask. That will
simplify your mask/unmask implementation.
* chrp/pci.c
I dislike the whole "is_bplan" thingy with ugly magic numbers. The
is_pegasos with 3 values was already on the limit .... In fact, you
probably don't even need it. The whole pcibios_fixup change is useless,
let the fixup code run, it will do no harm, and in fact will be
necessary as soon as you have a correct interrupt-tree anyway. Which
means basically that you shoudn't even need to patch this file...
* chrp/setup.c
Did you do any change to chrp_init2() appart from moving it around ?
Please don't move it for no reason or explain why you did it, it makes
the patch bigger than necessary and more difficult to read.
Why did you add back bits that I removed, like:
+ if (_chrp_type == _CHRP_Pegasos)
+ ppc_md.get_irq = i8259_irq;
This should be handled by the chrp code just fine now (basically 8259
takes over when no mpic was found and sets that callback).
You may have noticed that I changed the code a bit too regaring how irq
controllers are handled in chrp in 2.6.18. You should follow that
instead of bringing back the old scheme. Basically add a
chrp_find_mpc5200_pic or something like that and have it change
ppc_md.get_irq itself if it finds it.
This all init2 vs init_alt business is very ugly. What is your reason
for doing so ? What is chrp_init2 doesn't work for you ? (you should fix
that instead).
* fec driver
(That driver should ultimately be submited to the netdev list & Jeff
Garzik, but here's a fist pass at comments on things that need to be
fixed before you get there).
I'm not sure you have enough files here to justify a subdir. Especially
since you should probably get rid of fec_phy.c and replace it with the
generic PHY code that Andy Fleming wrote in drivers/net/phy/. That old
state machine PHY code from montavista has outlived its usefulness
The driver should be in drivers/net, in fact, it should just be one or
two files: drivers/net/mpc5200_fec.{c,h}
Do not keep #ifdefs around for chrp/non-chrp. I don't want the mpc5200
stuff to have any difference between platforms. The driver wasn't in the
tree before so I don't care about whatevber old API was used by an out
of tree driver in arch/ppc. We are defining an API for use by any
mpc5200 based device under arch/powerpc here, nothing specific to EFIKA
or CHRP.
+ if ( _chrp_type == _CHRP_E5K2 )
+ return (132*1000*1000);
+
Gack ! Make that a property in the device-tree instead. By converting
the driver to be an of_platform device, you'll get your device-node
reference for free anyway.
kfree_skb() -> dev_kfree_skb() afaik. Also, you might want to make sure
you are getting the right irq/non-irq/any version of it depending on the
context you are calling it in.
You are never calling netif_carrier_on/off... might be useful to do so
to inform the kernel about the state of your link... though if you use
the generic PHY layer, it will do it for you.
+ if (status & 0x370000) {
What about using symbolic constants instead ?
virt_to_phys() is deprecated. See my comments in the bestcomm code too,
use the dma mapping API instead.
Your rx code doesn't seem to do the fairly common optimisation of
copying the data to a new skb when it's small enough rather than
allocating a new one and replacing...
fec_interrupt() has some serious coding style issues.
I'm a bit dubious about the implementation of the re-init code... it
looks racy vs. interrupts, and I don't like at all you calling back into
open(). I'd rather have a separate common routine called by both open
and reinit. You may also want to defer that to a work queue.
ethtool ioctls: You are using a deprecated interface. grep for
ethtool_ops for the right way to do it.
+ while(!priv->sequence_done)
+ schedule();
+
This is evil. Don't do that. In fact, you should not need to do it, look
at what other drivers do.
* serial stuff
Pretty much all of the same comments as the fec driver regarding
things like:
+static unsigned long get_ipbfreq(void)
+{
+#ifdef CONFIG_PPC_CHRP
+ if ( _chrp_type == _CHRP_E5K2 )
+ return 132*1000*1000;
+
+ return 0;
+#else
+ return __res.bi_ipbfreq
+#endif
+}
+
Just get rid of the bi case and remove the ifdef. Now howevr that I see
at least 2 drivers having the same function to get this ibp freq I'm
starting to wonder why you don't just put the value in the device-tree
possibly in the parent node ?
Same for the default baudrate. Remove the ifdef gunk. Use the baudrate
that's passed in by the system and possibly implement something akin to
check_legacy_serial_console() in arch/powerpc/kernel/legacy_serial.c to
get proper auto-detect. (I would even accept adding a special case to
detect the mpc5200 serial in there)
Make it an of_platform device anyway, that's better. Just ifdef to be
compatible with the stuff in arch/ppc (I didn't even know we ever merged
that... oh well).
* USB
Do an ohci-ppc-of.c that use an OF platform device for probing
Ben.
^ permalink raw reply
* Re: [PATCH] Fixed up the OF functions to only do PCI stuff if PCI is actually configured
From: Benjamin Herrenschmidt @ 2006-10-23 5:16 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0610161558500.6266@ld0175-tx32.am.freescale.net>
On Mon, 2006-10-16 at 16:03 -0500, Andy Fleming wrote:
> The original problem that inspired this patch was solved quite some time
> ago (Turning off PCI didn't work), but this patch neatens things up a
> little (I think), by putting all the PCI stuff inside a single CONFIG_PCI
> block. It also removes the OF PCI bus matching entries if CONFIG_PCI is
> off.
Looks good to me.
Ben.
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Paul Mackerras @ 2006-10-23 3:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20061019180308.GA24256@ld0162-tx32.am.freescale.net>
Scott Wood writes:
> This patch causes a sync do be done after masking a QE interrupt, to
> ensure that the masking has completed before interrupts are enabled.
> This allows the masking of the cascade IRQ to be removed without causing
> spurious interrupts.
Hmmm. In general a sync having completed doesn't mean that previous
MMIO stores have actually got to the device. Reading from a device
register generally does ensure that previous writes have actually got
to the device though - could you do that instead? I'm concerned that
adding the sync is not a robust fix and is possibly only working due
to fortuitous timing.
Paul.
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Eric Nuckols @ 2006-10-23 0:20 UTC (permalink / raw)
To: eemingliu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F1443E16DEC18B89BFA5881B2030@phx.gbl>
>Dear Eric,
>>Have you tried the function
>>
>>alloc_bootmem_low() early in the boot process in main.c ?
>>
>Yes, it sounds reasonable. With this function, I can reserve a large amount
>of buffer during >booting time. But I think maybe it will be better to put
>this function in the device driver and when >booting time, the driver is
>loaded and the memory part is reserved for later use, right?
Actually, you can only do this at boot time before any of the standard
memory setup routines run.
Consult the linux device drivers book and also do some internet research on
the subject to get the "official" documentation of this functionality. I'd
rather you get the information from these sources than from me, since there
is plenty of room for error when using these functions.
Here's a link I found to the book: (the 2nd Edition)
http://www.xml.com/ldd/chapter/book/ch07.html
>Thanks for your idea so much. It's really helpful.
>Regards
>Ming
_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial!
http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
^ permalink raw reply
* Re: MPC8xx CPM I2C interface driver
From: Vitaly Bordug @ 2006-10-22 22:50 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-embedded
In-Reply-To: <452B626D.8050106@aimsys.nl>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Tue, 10 Oct 2006 11:05:49 +0200
Norbert van Bolhuis wrote:
>
> Is there no MPC8xx CPM I2C interface driver in (latest) linux v2.6 or
> am I mistaken ?
> There's no code for CONFIG_I2C_ALGO8XX.
The answer is - no, there is no stuff in the 2.6 kernel. I used to have the port from 2.4 a while ago (an
improvement to the patches posted here btw) but had no chance to cleanup it and push through lm_sensors.
>
> I've a MPC870 based board and I was hoping for a MPC8xx CPM I2C
> interface driver to be there (allowing user applications to open and
> read/write /dev/i2c-0)
>
You should be able to locate sources in this list's archives. Ping me once more if not, I'll try to dig it out of my HDD then...
> Thanks,
> N.
>
>
>
--
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Nicolas DET @ 2006-10-22 12:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <122A4E06-B8A6-4256-B96E-3811EA93EA25@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
Kumar Gala wrote:
>
> On Oct 20, 2006, at 3:12 AM, Nicolas DET wrote:
>
>> Kumar Gala wrote:
>> >
>> > On Oct 19, 2006, at 7:39 AM, Nicolas DET wrote:
>> >
>> >> This 'big' patch adds support for CHRP/MPC52xx based platform.
>> Here, this is the bPlan's Efika computer
>> (http://www.bplan-gmbh.de/efika_spec_en.html)
>> >
>>
>> > Some high level comments:
>> > 1. lets stick with the 52xx naming, instead of 5k2
>>
>> Ok. Will be done
>>
>> > 2. PIC code needs to be updated for new interrupt model (as well as
>> remove of pt_regs)
>>
>> Ok.
>>
>> > 3. use standard kernel debug macros
>>
>> Loads of changes in the pipe line ;-)
>>
>> > 4. look at replacing sram_allocator w/rheap
>> >
>>
>> This SRAM allocator is the exact same from the original Linux one. In
>> fact, it is the original one. Would it be possible to accept this code
>> as it is and schedule rheap integration later ?
>
> I dont follow, what do you mean by 'original Linux one' ?
>
There is a driver for Linux (not in the official kernel.org tree) for
this chipset. This is the one I'm speaking about
You can find it into various embbeded kernel like MontaVista tree, etc...
By the way, I uploaded the current patch on a private URL:
http://powernico.free.fr/chrpmpc52x_bigone.patch.bz2
If people wish to have a look.
[-- Attachment #2: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* 2.6.19-rc2: known unfixed regressions (v3)
From: Adrian Bunk @ 2006-10-22 12:23 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: alsa-devel, Thierry Vignaud, Greg KH, ak, linux-ide, pavel,
paulus, Jens Axboe, linux-visws-devel, Meelis Roos, Christian,
art, linux-acpi, Michael S. Tsirkin, linux-pci, jgarzik,
Martin Lorenz, Stephen Hemminger, len.brown, discuss, cpufreq,
Alex Romosan, perex, linux-pm, linuxppc-dev, pazke, Jesper Juhl,
Linux Kernel Mailing List, davej, Mark Langsdorf, Prakash Punnoor,
James.Bottomley
In-Reply-To: <Pine.LNX.4.64.0610130941550.3952@g5.osdl.org>
This email lists some known unfixed regressions in 2.6.19-rc2 compared
to 2.6.18 that are not yet fixed Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : ppc prep boot hang
References : http://lkml.org/lkml/2006/10/14/58
Submitter : Meelis Roos <mroos@linux.ee>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
Status : unknown
Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status : unknown
Subject : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown
Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown
Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <tvignaud@mandriva.com>
Status : unknown
Subject : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
http://lkml.org/lkml/2006/10/5/289
Submitter : art@usfltd.com
Status : submitter was asked to git bisect
result of bisecting seems to be wrong
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Status : unknown
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter : Stephen Hemminger <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
Status : Greg is working on a fix
Subject : snd-hda-intel <-> forcedeth MSI problem
References : http://lkml.org/lkml/2006/10/5/40
http://lkml.org/lkml/2006/10/7/164
Submitter : Prakash Punnoor <prakash@punnoor.de>
Status : patches are being discussed
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Ming Liu @ 2006-10-22 11:40 UTC (permalink / raw)
To: rahul.theraja; +Cc: linuxppc-embedded
In-Reply-To: <ff9652ca0610212348p42f46a52w9b147dc3d7ae1838@mail.gmail.com>
Dear Rahul,
>why do you think so ?
>Can't you give the physical address of the allocated memory from
>linux
>kernel to peripheral's DMA.?
>Unless you need to hardcode the physicall address i hope
>virt_to_phys(kmalloc_address) can be given to DMA.
>Sorry if i am still wrong in understanding your requirement.
>
In fact, I have considered this method before. Just to dynamically allocate
such a memory buffer and then tell the peripheral its physical address for
accessing. However, because I really know little about the memory
management in Linux, so I am not sure if the following question could be
guaranteed:
Q. When I dynamically allocate a large amount of memory, I am not sure if I
can allocate a physically continous large amount of memory. For the
peripheral, it hopes the continous physical address, unless it has
scatter-gather function.
I think I must dig deeply into LDD memory management chapter to find the
answer. :)
Of course, I appreciate your idea and suggestion. This is really a
candidate method to solve my problem.
Thanks a lot.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Ming Liu @ 2006-10-22 11:21 UTC (permalink / raw)
To: jrocnuck; +Cc: linuxppc-embedded
In-Reply-To: <BAY117-F26E839E935D9A3C03E365EC8020@phx.gbl>
Dear Eric,
>Have you tried the function
>
>alloc_bootmem_low() early in the boot process in main.c ?
>
Yes, it sounds reasonable. With this function, I can reserve a large amount
of buffer during booting time. But I think maybe it will be better to put
this function in the device driver and when booting time, the driver is
loaded and the memory part is reserved for later use, right?
Thanks for your idea so much. It's really helpful.
Regards
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn
^ permalink raw reply
* Re: help in block drivers
From: Rahul @ 2006-10-22 9:02 UTC (permalink / raw)
To: Fawad Lateef; +Cc: kernelnewbies, Shakthi Kannan, linuxppc-embedded
In-Reply-To: <1e62d1370610192213g7502709ufcc2bce6903040d8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On 10/20/06, Fawad Lateef <fawadlateef@gmail.com> wrote:
>
> Hello Rahul,
>
> First of all please don't do top-posting rather do bottom-posting. For
> more information search google.
oh sorry for that
On 10/19/06, Rahul Theraja <rahul.theraja@gmail.com> wrote:
> > Hello Shakthi Kannan,
> >
> > Thanks for the reply .
> >
> >
> > > > driver. I could not understand why the "sbd_request " is called even
> > though
> > > > i have given only one read call from user space file.
> > >
> > > Block device I/O transfer is done in blocks.
> > >
> > > > And also in the driver, in the function sbd_request() how does the
> > driver
> > > > get the parameters like sector, current_nr_sectors and buffer.
> > >
> > > VFS <-> SCSI <-> Block device?
> > >
>
> I think its VFS<->Buffer-Cache<->Block-Device and if drive is mounted
> then VFS<->FS<->Buffer-Cache<->Block-Device
>
> > > > i could move
> > > > furhter fastly.
> > >
> > > Fastly? IMHO, learning kernel development involves lot of patience.
> > >
> > > SK
> >
> >
> > Is it necessary to use kernel_thread() in block drivers.
> In drivers/block
> > loop.c i could see kernel_thread() being used but in floopy.c it is not
> > used. When is this kernel_thread() function is supposed to be used ? In
> the
> > sbd_device also the kernel_thread() is not used.
> >
>
> First in kernel-2.6.x its better to use kthread_*() rather than
> kernel_thread if threading is needed.
>
> Threading isn't necessary in any device until unless you need it. For
> example if your driver is emulating a device or performing IO directly
> then you don't need it, but if your driver is sending request to a
> device which generates interrupts after completing IO and you want to
> do some extra work after getting IO completion interrupt then you must
> use thread. As threads work in process-context, hence can do sleep and
> lengthy processing but interrupt-context shouldn't sleep or nor do
> long processing.
>
> For getting more understanding about different contexts like process,
> interrupt, softirqs contexts do search google.
>
> > Anyone please kindly clarify my doubts.
> >
>
> I hope you doubts are not clear.
thank you very much for all the help
> Thanks in Advance
> >
> > -Rahul
> >
>
> --
> Fawad Lateef
>
[-- Attachment #2: Type: text/html, Size: 3324 bytes --]
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Rahul @ 2006-10-22 6:48 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F2BA131ED0055064C26658B2020@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]
On 10/21/06, Ming Liu <eemingliu@hotmail.com> wrote:
>
> Dear sudheer,
> About the "mem=xx" argument, I checked it from the website and got such a
> explanation:
>
> This argument has several purposes: The original purpose was to specify
> the
> amount of installed memory (or a value less than that if you wanted to
> limit the amount of memory available to linux).
>
> From the argument above, it says "mem=xx" is to specify the amount of
> memory available to Linux. I am not sure if I am right, but I think if I
> use such an argument, that reserved part (that 5MB you mentioned), is not
> available any more for Linux to access it.
>
> My original meaning is: specify a fixed physical address for a mount of
> memory for reserved use. The point is to make this part of memory fixed in
> the memory of physical address, and then another I/O peripheral could use
> DMA to access such a fixed physical address memory. However if I don't
> reserve such a part, I must let Linux to allocate such a memory part. And
> then Linux will not put it in a fixed physical address
yes
and then the
> peripheral will not know where is this part.
why do you think so ?
Can't you give the physical address of the allocated memory from linux
kernel to peripheral's DMA.?
Unless you need to hardcode the physicall address i hope
virt_to_phys(kmalloc_address) can be given to DMA.
Sorry if i am still wrong in understanding your requirement.
Am I right? Thanks for your idea.
>
> Also other ideas are appreciated.
>
> Regards
> Ming
>
> >Considering your setup as normal desktop, I hope this can be done by
> >giving
> >"mem= xxm" as the boot arguments. Say the dmesg in your system
> >shows "
> >495MB LOWMEM available." . In the boot arguments you can give
> >mem=490m
> >saying the linux to use only 490MB . The rest 5MB can be used later
> >as you
> >wish.
>
> _________________________________________________________________
> 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 3146 bytes --]
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Michael Richardson @ 2006-10-22 0:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY110-F2BA131ED0055064C26658B2020@phx.gbl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On x86, many BIOSs reported the wrong amount of memory.
Either they screwed up and reported too much (which means the system
would crash if it tried to use), or failed to report more than 64MB
of ram through that interface.
(Which was the physical limit on one generation of systems due to number
of pins that came out of processors/support chips/etc.)
The point of mem= is to let you override it.
It only became useful later on to people who wanted contiguous DMA
regions. Frankly: it's a terrible hack.
On any reasonable embedded system you should get yourself sufficiently
involved in the linux memory management, and do it early enough
(i.e. not as a module. Why would you need modules on a single-purpose
embedded system, except because you want to play non-GPL games).
The question about whether or not the MMU is setup is nonsense --- you
don't understand the system properly. mem= is telling the system how
much PHYSICAL memory there is, not how much virtual address space setup.
On some architectures, the kernel gets a 1:1 mapping of all virtual to
physical, on others, you don't. You can trivially add new mappings to
head.S, if you need them very early on, or you can map the physical
spaces afterward if you can deal later on.
- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRTq834CLcPvd0N1lAQJdpQgAo0+sYTTi/FBgyFA3Lyn6HTNZ6xHQ0BMf
40h1B2qXvB0cWeGaHndfXFe04r3w0w/z0RKsjE5ultVxGO/WNBb8gCYDbmA/M4y0
DuTjMh+unn63o7iVwtJbPeSWA8T5KK8RW1y0NNRnwVzMkjzxo2IZbGblwreSXJWg
MF1Hsh79MTfIlpel7BkxFmcBWTUj16W0XQljmyBW6F5zK7DZ5di2WYbWKM+khzVs
ydlems1Nns8Qk8bI8s0Jq8NBx+J1VSV95qRvCtLIAfVyiO9lRZgeozvsB3Ri0cbA
C4usgAL4yUgUPG3DeN9PfL+uVELzWo1CyB7JOiyYDGYDKswau8vmoA==
=4THO
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC] Porting AmigaOne platform code from ppc to powerpc
From: Benjamin Herrenschmidt @ 2006-10-21 23:51 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20061019132423.270440@gmx.net>
On Thu, 2006-10-19 at 15:24 +0200, Gerhard Pircher wrote:
> Hi!
>
> I'm working on the AmigaOne Linux kernel port. The AmigaOne is a G3/G4 desktop system and makes use of U-boot v1.1.0 as firmware. I intend to port the current code base of this platform to the powerpc architecture, but I'm not sure how to address this.
>
> The "problem" is the device tree required by the powerpc architecture. The AmigaOne's U-boot version doesn't support the flattened device tree yet and also requires a special flash rom programmer tool (I guess it adds some sort of dongle code to the flash rom content). Otherwise users won't be able to boot AmigaOS4. Thus using a newer U-boot version is not really an option and AFAIK the OS4 developers are not going to update their U-boot version.
>
> Well, some time ago I read about a CUIMAGE target that can be used to get powerpc-arch kernels working on old U-boot versions by using a precompiled/static device tree. I don't think that this approch makes sense for a desktop platform, which uses different CPUs (750FX, 750GX, 7410, 7450, 7455, etc..), PCI/AGP cards, etc.
>
> Any advice for me in this case?
You can also look at the rework being done currently on zImage wrappers.
Among others, they have the ability to embed a device-tree.
Ben.
^ permalink raw reply
* Re: problem when boot new kernel and ramdisk
From: Wolfgang Denk @ 2006-10-21 23:47 UTC (permalink / raw)
To: tran vanle; +Cc: linuxppc-embedded
In-Reply-To: <20061021094114.40292.qmail@web33012.mail.mud.yahoo.com>
In message <20061021094114.40292.qmail@web33012.mail.mud.yahoo.com> you wrote:
>
> I have just build kernel image and ramdisk for TQM_8xxL
...
> Image Name: Linux-2.6.12-uc0
There is no support for TQM8xxL boards in the context of the 2.6
kernel tree yet. At least, non working support.
> Where error ocur? and how can I fix it ?
Use a 2.4 kernel.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Wish not to seem, but to be, the best." - Aeschylus
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Benjamin Herrenschmidt @ 2006-10-21 23:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <6B8FAF75-44DF-4638-BD7D-AF6BB063F339@kernel.crashing.org>
> > I was just thinking, as this code is alraedy in some Linux tree, we
> > could still use it there, and plan to replace it by a much better
> > one (keeping the API compatible) later on.
>
> Is this in the kernel tree already, I am not coming across it.
Probably only in the WD tree and not even attempted to be merged like
most of the gunk in there...
Ben
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Eric Nuckols @ 2006-10-21 17:48 UTC (permalink / raw)
To: eemingliu, urwithsudheer; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F2BA131ED0055064C26658B2020@phx.gbl>
Have you tried the function
alloc_bootmem_low() early in the boot process in main.c ?
----Original Message Follows----
From: "Ming Liu" <eemingliu@hotmail.com>
To: urwithsudheer@gmail.com
CC: linuxppc-embedded@ozlabs.org
Subject: Re: how to reserve memory in linux?
Date: Sat, 21 Oct 2006 14:22:25 +0000
Dear sudheer,
About the "mem=xx" argument, I checked it from the website and got such a
explanation:
This argument has several purposes: The original purpose was to specify the
amount of installed memory (or a value less than that if you wanted to limit
the amount of memory available to linux).
>From the argument above, it says "mem=xx" is to specify the amount of memory
available to Linux. I am not sure if I am right, but I think if I use such
an argument, that reserved part (that 5MB you mentioned), is not available
any more for Linux to access it.
My original meaning is: specify a fixed physical address for a mount of
memory for reserved use. The point is to make this part of memory fixed in
the memory of physical address, and then another I/O peripheral could use
DMA to access such a fixed physical address memory. However if I don't
reserve such a part, I must let Linux to allocate such a memory part. And
then Linux will not put it in a fixed physical address and then the
peripheral will not know where is this part.
Am I right? Thanks for your idea.
Also other ideas are appreciated.
Regards
Ming
>Considering your setup as normal desktop, I hope this can be done by giving
>"mem= xxm" as the boot arguments. Say the dmesg in your system shows "
>495MB LOWMEM available." . In the boot arguments you can give mem=490m
>saying the linux to use only 490MB . The rest 5MB can be used later as you
>wish.
_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
^ permalink raw reply
* Re: how to reserve memory in linux?
From: Ming Liu @ 2006-10-21 14:22 UTC (permalink / raw)
To: urwithsudheer; +Cc: linuxppc-embedded
In-Reply-To: <12c9fc1a0610202215k67f374d3ie3db3d6cbfb82180@mail.gmail.com>
Dear sudheer,
About the "mem=xx" argument, I checked it from the website and got such a
explanation:
This argument has several purposes: The original purpose was to specify the
amount of installed memory (or a value less than that if you wanted to
limit the amount of memory available to linux).
>From the argument above, it says "mem=xx" is to specify the amount of
memory available to Linux. I am not sure if I am right, but I think if I
use such an argument, that reserved part (that 5MB you mentioned), is not
available any more for Linux to access it.
My original meaning is: specify a fixed physical address for a mount of
memory for reserved use. The point is to make this part of memory fixed in
the memory of physical address, and then another I/O peripheral could use
DMA to access such a fixed physical address memory. However if I don't
reserve such a part, I must let Linux to allocate such a memory part. And
then Linux will not put it in a fixed physical address and then the
peripheral will not know where is this part.
Am I right? Thanks for your idea.
Also other ideas are appreciated.
Regards
Ming
>Considering your setup as normal desktop, I hope this can be done by
>giving
>"mem= xxm" as the boot arguments. Say the dmesg in your system
>shows "
>495MB LOWMEM available." . In the boot arguments you can give
>mem=490m
>saying the linux to use only 490MB . The rest 5MB can be used later
>as you
>wish.
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* problem when boot new kernel and ramdisk
From: tran vanle @ 2006-10-21 9:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
hi every one
I have just build kernel image and ramdisk for TQM_8xxL
I write image into flash at 40400000 and ramdisk at 40580000
I run
=>bootm 40400000 40580000
and i receive
## Booting image at 40400000 ...
Image Name: Linux-2.6.12-uc0
Created: 2006-10-21 3:22:00 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 921020 Bytes = 899.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 40580000 ...
Image Name:
Created: 2006-10-21 7:54:35 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1853670 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 00deb000, end 00faf8e6 ... OK
and stop run , auto start reboot, after that it still run like this
Where error ocur? and how can I fix it ?
Thanks
LeVan
---------------------------------
On Yahoo!7
Photos: Unlimited free storage - keep all your photos in one place!
[-- Attachment #2: Type: text/html, Size: 1598 bytes --]
^ permalink raw reply
* Re: how to reserve memory in linux?
From: a sudheer @ 2006-10-21 5:15 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F990057FF58BF5A4F24763B20D0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
Hello Ming Lu
On 10/20/06, Ming Liu <eemingliu@hotmail.com> wrote:
>
> Dear all,
> My situation is, I want to reserve some amount of memory and make it
> shared
> by both Linux kernel and another hardware peripheral. That is, when I boot
> linux and execute some user space programs, this part of memory should be
> reserved for other use and cannot be used by both the kernel and those
> applications.
Considering your setup as normal desktop, I hope this can be done by giving
"mem= xxm" as the boot arguments. Say the dmesg in your system shows "
495MB LOWMEM available." . In the boot arguments you can give mem=490m
saying the linux to use only 490MB . The rest 5MB can be used later as you
wish.
Please correct if i am wrong.
Thanks
Sudheer
But it could be accessed by Linux with some certain kind of
> application and also be accessed by another hardware peripheral with DMA
> or
> something like that.
>
> I am not sure if I am right but I think it's just like the situation of
> multiprocessing (if we can treat that hardware peripheral as another
> processor, or just use another processor to realize its functions.) and
> that part of memory is just like the hardware shared memory by
> multiprocessor. Am I right?
>
> Then my question is, how to reserve such part of memory in Linux? Does
> Linux has such a function?
>
> I am not falimiar with such a topic, so any hint related to this is
> appreciated.
>
> Thanks for your ideals and suggestions.
>
> Regards
> Ming
>
> _________________________________________________________________
> 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 2554 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] Correct way to format spufs file output.
From: Benjamin Herrenschmidt @ 2006-10-21 1:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Dwayne Grant McConnell, cbe-oss-dev, linux-kernel
In-Reply-To: <200610201638.52404.arnd@arndb.de>
On Fri, 2006-10-20 at 16:38 +0200, Arnd Bergmann wrote:
> On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
> > I think %0xllx is the way to go. I would even advocate changing
> > signal1_type and signal2_type unless it is actually too dangerous.
>
> There is absolutely no reason why these should be hexadecimal, they
> are basically implementing a bool.
>
> > Is there even a case where changing from %llu to %0xllx would break things?
> > Perhaps with the combination of a old library with a new kernel?
>
> Right, a library or some script that has been written assuming there
> is no leading 0x.
We might still want to "broadcast" that we might change that and see how
much gets broken. It's very likely that nothing will.
Ben.
^ 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