* Re: Build failure on treeboot-walnut.c
From: maxime louvel @ 2008-02-18 15:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
Kumar Gala wrote:
> $ make V=1
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage powerpc-unknown-linux-gnu-gcc -m32
>- Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
>- Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float
-pipe
>- fomit-frame-pointer -fno-builtin -fPIC -nostdinc -isystem
> /_TOOLS_/.dist0/gnu-
gcc-4.0.2-binutils-2.16.1-glibc-2.3.6-e300c2-powerpc-unknown-linux-gnu/i686-
pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/4.0.2/include -
Iarch/powerpc/boot -I/temp/kumar.484/arch/powerpc/boot -mcpu=405 -c -o
> arch/powerpc/boot/treeboot-walnut.o arch/powerpc/boot/treeboot-walnut.c
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/gcc-
4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/config/tc-ppc.c
> line 1314 in ppc_setup_opcodes
> Please report this bug.
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make: *** [uImage] Error 2
>
>ARCH=ppc64? WTF? I specifically said ARCH=powerpc on the make command
line.
I have got the exact same problem.
Has the problem been sovled ?
I am trying to compile a 2.6.24 kernel (vanilla + some board specific stuff)
with a vanilla gcc-4.1.2 with the flag -msoft-float.
cheers,
Maxime
--
Maxime Louvel
0044 7964 5555 80
43 Allen road
Whitemore reans
WV60AW Wolverhampton
United Kingdom
[-- Attachment #2: Type: text/html, Size: 1657 bytes --]
^ permalink raw reply
* Re: Linker error: no init_fcc_ioports
From: Scott Wood @ 2008-02-18 15:58 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AAC0@xmb-sjc-212.amer.cisco.com>
On Fri, Feb 15, 2008 at 06:05:36PM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi
> Our platform is based on mpc8541cds, I am using Linux 2.6.24 from
> powerpc git tree.
> I tried to compile the kernel to include the fcc Ethernet controller and
> I got the following
> linker errors:
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
>
> arch/powerpc/sysdev/built-in.o: In function `fs_enet_of_init':
> arch/powerpc/sysdev/fsl_soc.c:853: undefined reference to
> `init_fcc_ioports'
> arch/powerpc/sysdev/fsl_soc.c:853: undefined reference to
> `init_fcc_ioports'
You need to select PPC_CPM_NEW_BINDING from your board's kconfig entry
(and make sure you comply with the new CPM bindings, and that all pins
are set up by firmware or platform code).
-Scott
^ permalink raw reply
* Re: Sequoia NAND - others missing?
From: Steve Heflin @ 2008-02-18 16:18 UTC (permalink / raw)
To: Linuxppc-embedded
Looking at the "arch/ppc/platforms/4xx/sequoia.c" from 2.6.14
MontaVista, I also see ECC error handling, a Serial RTC device, UART4
to UART11. It doesn't look like those are supported in the current
"arch/powerpc/platforms/44x/sequoia" ?
Regarding the nftd NAND driver, I see a device table hookup in
"arch/powerpc/platforms/44x/warp-nand.c". Am I right in saying that
file is a perfect template from which to generate sequoia-nand.c ?
thanks,
Steve
At 03:56 PM 2/17/2008, you wrote:
>On Sun, 17 Feb 2008 10:27:22 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > Are there other devices (beside the NAND Flash Controller) that exist
> > on the AMCC-440EPx chip and are not supported by the current
> > Linux-2.6.25 ARCH=powerpc?
>
>i2c, GPIO, the security stuff (if your version has that), and GPT.
>Thought GPT has never really been supported in any kernel that I
>remember.
>
>Patches for i2c and GPIO are floating around somewhere I think. Just
>need to get them polished up and device-tree compliant.
>
>josh
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH-RESEND] next-20080218 build failure at pmac_ide_macio_attach ()
From: Kamalesh Babulal @ 2008-02-18 17:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: sfr, linux-ide, linux-kernel, Kamalesh Babulal, linuxppc-dev
In-Reply-To: <jeodae4acy.fsf@sykes.suse.de>
On Mon, Feb 18, 2008 at 03:17:49PM +0100, Andreas Schwab wrote:
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> writes:
>
.
.
<snip>
> Just remove the cast.
>
> Andreas.
Resending the patch after making the changes Andreas said.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Andreas Schwab <schwab@suse.de>
--
--- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 22:24:49.000000000 +0530
+++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 22:25:10.000000000 +0530
@@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
int irq, rc;
hw_regs_t hw;
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
@@ -1229,7 +1229,7 @@ pmac_ide_pci_attach(struct pci_dev *pdev
return -ENODEV;
}
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Anton Vorontsov @ 2008-02-18 17:37 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven, Andrew Morton
In-Reply-To: <19805.1203355811@turing-police.cc.vt.edu>
On Mon, Feb 18, 2008 at 12:30:11PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> > I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> > Both resolve endianess at driver level. Actually, both handle it by setting special
> > bits so the graphics chip itself reorder bytes to transform foreign endianess.
> > I understand that this patch is for chips which cannot reorder bytes by themselves.
>
> Does anybody know of such a chip that's actually available in the wild?
LE Fujitsu mb86277 (MINT) on the BE MPC8360E.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: How to describe FPGA-based devices in the device tree ?
From: Scott Wood @ 2008-02-18 17:47 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200802181343.54989.laurentp@cse-semaphore.com>
On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> bcsr@3,0 {
> device_type = "board-control";
> reg = <3 0 00000020>;
> };
No device_type. Needs a compatible.
>
> fpga@4,0 {
> reg = <4 0 00010000>;
> };
> };
>
> The fourth device is a FPGA that contains several IP cores such as an
> interrupt controller and a SD/MMC host controller. If I understand things
> correctly, each IP core should have its own node in the device tree to allow
> proper binding with device drivers.
Correct.
> As booting-without-of.txt describes the localbus node ranges as
> corresponding to a single chipselect and covering the entire chipselect
> access window, I can't have nodes for each IP core as children of the
> localbus node.
That does not follow. The ranges entry has to cover the whole chipselect,
but there's no one-to-one correspondence between nodes and ranges entries.
There's nothing wrong with doing this:
fpga@4,0 {
compatible = "foo,bar";
reg = <4 0 00010000>;
};
fpga@4,10000 {
compatible = "foo,baz";
reg = <4 00010000 00010000>;
};
fpga@4,20000 {
compatible = "foo,blah";
reg = <4 00020000 00010000>;
};
> Should I put IP core nodes as children of the FPGA node ?
You could do that as well.
> If so, how do I map addresses at the FPGA level ? A ranges property in the
> FPGA node would let me map addresses in the FPGA scope to the localbus
> scope. However, as the localbus scope use the chipselect number as its
> first address cell and 0 as its second address cell,
The second cell is the address within the chipselect. If it were always
zero, it wouldn't be there at all.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Valdis.Kletnieks @ 2008-02-18 18:11 UTC (permalink / raw)
To: David Howells
Cc: Adrian Bunk, Roel Kluin, lkml, Willy Tarreau, linuxppc-dev,
Geert Uytterhoeven, cbe-oss-dev, Arjan van de Ven
In-Reply-To: <12131.1203344830@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch instruction a measure of probability whether the branch
> will be taken.
What does gcc do the 99.998% of the time we don't have likely/unlikely coded?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* arch_initcall time
From: Sean MacLennan @ 2008-02-18 18:28 UTC (permalink / raw)
To: LinuxPPC-dev
I need to call i2c_register_board_info for the new i2c style ad7414
driver. This needs to be called at arch initcall time. Currently I just
do this:
static int __init warp_arch_init(void)
{
i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
return 0;
}
arch_initcall(warp_arch_init);
It works, but is there a "better" place to put this? None of the other
powerpc platforms make this call and I want to get it right, so that
others don't blindly follow my example ;)
I kept the name vague rather than specific in case more drivers need to
be setup this way in the future.
Cheers,
Sean
^ permalink raw reply
* Re: How to describe FPGA-based devices in the device tree ?
From: Grant Likely @ 2008-02-18 18:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080218174701.GA3835@loki.buserror.net>
On Feb 18, 2008 10:47 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> > Should I put IP core nodes as children of the FPGA node ?
>
> You could do that as well.
I'd recommend doing that, then your subnodes are isolated from changes
to the bus attachment (chipselect). (really an insignificant point,
but I think it is a more logical layout).
So, something like this:
fpga@4,0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 4 0 00100000>;
/* breakdown of 'ranges' fields: */
/* "0": start address of internal range */
/* "4 0": start address of external range (chip select 4, address 0) */
/* "00100000: size of range */
iocore@0 {
compatible = "foo,bar";
reg = <0 00010000>;
};
iocore@10000 {
compatible = "foo,bar";
reg = <10000 00010000>;
};
iocore@20000 {
compatible = "foo,bar";
reg = <20000 00010000>;
};
};
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: arch_initcall time
From: Grant Likely @ 2008-02-18 18:31 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47B9CE4D.1020303@pikatech.com>
On Feb 18, 2008 11:28 AM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> I need to call i2c_register_board_info for the new i2c style ad7414
> driver. This needs to be called at arch initcall time. Currently I just
> do this:
>
> static int __init warp_arch_init(void)
> {
> i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> return 0;
> }
> arch_initcall(warp_arch_init);
Yes, this is the right thing to do, but use machine_arch_initcall()
instead so that it doesn't get called if it is not your board.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Valdis.Kletnieks @ 2008-02-18 17:30 UTC (permalink / raw)
To: Krzysztof Helt
Cc: linux-fbdev-devel, adaplas, linux-kernel, linuxppc-dev,
Geert Uytterhoeven, Andrew Morton
In-Reply-To: <20080218081847.e9e65f2f.krzysztof.h1@poczta.fm>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> Both resolve endianess at driver level. Actually, both handle it by setting special
> bits so the graphics chip itself reorder bytes to transform foreign endianess.
> I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: arch_initcall time
From: Grant Likely @ 2008-02-18 18:32 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <fa686aa40802181031s4ba6ec4eie949040f0bf23ad6@mail.gmail.com>
On Feb 18, 2008 11:31 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Feb 18, 2008 11:28 AM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> > I need to call i2c_register_board_info for the new i2c style ad7414
> > driver. This needs to be called at arch initcall time. Currently I just
> > do this:
> >
> > static int __init warp_arch_init(void)
> > {
> > i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> > return 0;
> > }
> > arch_initcall(warp_arch_init);
>
> Yes, this is the right thing to do, but use machine_arch_initcall()
> instead so that it doesn't get called if it is not your board.
That being said, I believe there is infrastructure to handle the
creation of your i2c board info from the device tree. Your i2c board
info should not be hard coded.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Arjan van de Ven @ 2008-02-18 18:33 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Adrian Bunk, Roel Kluin, lkml, Willy Tarreau, linuxppc-dev,
Geert Uytterhoeven, cbe-oss-dev
In-Reply-To: <26571.1203358266@turing-police.cc.vt.edu>
On Mon, 18 Feb 2008 13:11:06 -0500
Valdis.Kletnieks@vt.edu wrote:
> On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
>
> > __builtin_expect() is useful on FRV where you _have_ to give each
> > branch and conditional branch instruction a measure of probability
> > whether the branch will be taken.
>
> What does gcc do the 99.998% of the time we don't have
> likely/unlikely coded?
see Andi's email.
It gets the exact same hints that 95%+ of the kernels unlikely/likely get you,
because the heuristics in it are usually the same as the kernel programmers
heuristics.
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: arch_initcall time
From: Olof Johansson @ 2008-02-18 18:42 UTC (permalink / raw)
To: Grant Likely; +Cc: LinuxPPC-dev, Sean MacLennan
In-Reply-To: <fa686aa40802181032lffff9e2yf079c277c250b430@mail.gmail.com>
On Mon, Feb 18, 2008 at 11:32:14AM -0700, Grant Likely wrote:
> On Feb 18, 2008 11:31 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Feb 18, 2008 11:28 AM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> > > I need to call i2c_register_board_info for the new i2c style ad7414
> > > driver. This needs to be called at arch initcall time. Currently I just
> > > do this:
> > >
> > > static int __init warp_arch_init(void)
> > > {
> > > i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> > > return 0;
> > > }
> > > arch_initcall(warp_arch_init);
> >
> > Yes, this is the right thing to do, but use machine_arch_initcall()
> > instead so that it doesn't get called if it is not your board.
>
> That being said, I believe there is infrastructure to handle the
> creation of your i2c board info from the device tree. Your i2c board
> info should not be hard coded.
Jon Smirl's patches? Not yet, unfortunately. It didn't make .25, but
maybe for .26.
(I will need to do it specifically on my platform, like fsl_soc already
does, as a stopgap until then).
-Olof
^ permalink raw reply
* Re: arch_initcall time
From: Josh Boyer @ 2008-02-18 18:49 UTC (permalink / raw)
To: Olof Johansson; +Cc: LinuxPPC-dev, Sean MacLennan
In-Reply-To: <20080218184240.GA17898@lixom.net>
On Mon, 18 Feb 2008 12:42:40 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Mon, Feb 18, 2008 at 11:32:14AM -0700, Grant Likely wrote:
> > On Feb 18, 2008 11:31 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On Feb 18, 2008 11:28 AM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> > > > I need to call i2c_register_board_info for the new i2c style ad7414
> > > > driver. This needs to be called at arch initcall time. Currently I just
> > > > do this:
> > > >
> > > > static int __init warp_arch_init(void)
> > > > {
> > > > i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> > > > return 0;
> > > > }
> > > > arch_initcall(warp_arch_init);
> > >
> > > Yes, this is the right thing to do, but use machine_arch_initcall()
> > > instead so that it doesn't get called if it is not your board.
> >
> > That being said, I believe there is infrastructure to handle the
> > creation of your i2c board info from the device tree. Your i2c board
> > info should not be hard coded.
>
> Jon Smirl's patches? Not yet, unfortunately. It didn't make .25, but
> maybe for .26.
>
> (I will need to do it specifically on my platform, like fsl_soc already
> does, as a stopgap until then).
That, and Sean is still working on getting the iic device-tree-compliant driver through as
well :)
josh
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 1/3] Fix Unlikely(x) == y
From: Andrew Pinski @ 2008-02-18 19:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Adrian Bunk, Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev,
Willy Tarreau, Arjan van de Ven
In-Reply-To: <Pine.LNX.4.64.0802181500410.13406@vixen.sonytel.be>
On Feb 18, 2008 6:01 AM, Geert Uytterhoeven
<Geert.Uytterhoeven@sonycom.com> wrote:
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will soon become gcc 4.3) already does
> > transformations like replacing loops with divisions [1]).
Yes but the issue is one optimization inside GCC does not take into
account the probability in one case.
And really there is a bug in the linux kernel for not implementing the
long long divide function (or really using libgcc) but that is a
different story and is part of the issue there anyways.
-- Pinski
^ permalink raw reply
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-02-18 19:47 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <20080215214018.EA724CB0046@mail174-sin.bigfish.com>
Hello.
Stephen Neuendorffer wrote:
>>>Instead of attempting to come up with a generic description
>>>of this, I recommend just naming it after the actual device instance;
>>>something like compatible="xlnx,opb-uart16550";
>> Well, that means that we'll need a to add a code which "glues" the chip to
>>8250.c driver... well, of_serial.c could be that glue layer if we add to it
>>the ability to recognize Xilinx UART... well, legacy_serial.c could be taught
>>that trick too...
>> Well, we could also add the new compatible, but still claim "ns16550"
>>compatibility...
> This actually makes more sense to me... I'd rather have the code set
> the reg-shift than have it explicitly set in the device tree anyway.
> The compatibility set should include (at the least):
> opb_uart16550_v1_00_c
> opb_uart16550_v1_00_d
> opb_uart16550_v1_00_e
> plb_uart16550_v1_00_c
> xps_uart16550_v1_00_a
Sounds like too much? Couldn't this be handled via the "model" prop?
> I think this is somewhat independent of Sergei's arguments that generic
> ns16550 devices should allow having a reg-shift set....
> Steve
WBR, Sergei
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Jean Delvare @ 2008-02-18 20:15 UTC (permalink / raw)
To: benh; +Cc: parabelboi, Christian Krafft, linux-kernel, linuxppc-dev
In-Reply-To: <1202935374.7296.44.camel@pasglop>
Hi Ben,
On Thu, 14 Feb 2008 07:42:54 +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-02-13 at 18:35 +0100, Christian Krafft wrote:
> > sensors_detect crashes kernel on PowerPC, as it pokes directly to memory.
For the records, sensors-detect accesses I/O ports, not memory.
> > This patch adds a check_legacy_ioports to read_port and write_port.
> > It will now return ENXIO, instead of oopsing.
> >
> > Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
> The problem is that this prevents using /proc/ioports to access PCI
> IO space, which might be useful.
Maybe Christian's patch can be improved to not do the check on these?
As long as /dev/port exists, it seems reasonable that the kernel should
behave, no matter what I/O ports are accessed from user-space.
> I hate that sensors_detect.. or for that matter any other userland code
> that pokes random ports like that. It should die.
What do you propose as a replacement?
And how is userland code poking at random ports different from kernel
code poking at random ports? We could move sensors-detect inside the
kernel (and I have some plan to do that) but I fail to see how this
would solve this particular problem.
> > Index: linux.git/drivers/char/mem.c
> > ===================================================================
> > --- linux.git.orig/drivers/char/mem.c
> > +++ linux.git/drivers/char/mem.c
> > @@ -566,8 +566,13 @@ static ssize_t read_port(struct file * f
> > char __user *tmp = buf;
> >
> > if (!access_ok(VERIFY_WRITE, buf, count))
> > - return -EFAULT;
> > + return -EFAULT;
> > +
> > while (count-- > 0 && i < 65536) {
> > +#ifdef CONFIG_PPC_MERGE
> > + if (check_legacy_ioport(i))
> > + return -ENXIO;
> > +#endif
> > if (__put_user(inb(i),tmp) < 0)
> > return -EFAULT;
> > i++;
> > @@ -585,6 +590,7 @@ static ssize_t write_port(struct file *
> >
> > if (!access_ok(VERIFY_READ,buf,count))
> > return -EFAULT;
> > +
> > while (count-- > 0 && i < 65536) {
> > char c;
> > if (__get_user(c, tmp)) {
> > @@ -592,6 +598,10 @@ static ssize_t write_port(struct file *
> > break;
> > return -EFAULT;
> > }
> > +#ifdef CONFIG_PPC_MERGE
> > + if (check_legacy_ioport(i))
> > + return -ENXIO;
> > +#endif
> > outb(c,i);
> > i++;
> > tmp++;
--
Jean Delvare
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Benjamin Herrenschmidt @ 2008-02-18 20:42 UTC (permalink / raw)
To: Jean Delvare; +Cc: parabelboi, Christian Krafft, linux-kernel, linuxppc-dev
In-Reply-To: <20080218211519.2b159ade@hyperion.delvare>
> Maybe Christian's patch can be improved to not do the check on these?
> As long as /dev/port exists, it seems reasonable that the kernel should
> behave, no matter what I/O ports are accessed from user-space.
nonsense.
/dev/mem exists for example, but you are still not supposed to go
bang all over the place in it.
> > I hate that sensors_detect.. or for that matter any other userland code
> > that pokes random ports like that. It should die.
>
> What do you propose as a replacement?
Dunno, something less scary, like knowing where your sensors are on a
given machine... honestly, it's just scary the risk you guys are taking
by banging random IO ports.
At the very least, that shouldn't be done on non-x86.
> And how is userland code poking at random ports different from kernel
> code poking at random ports? We could move sensors-detect inside the
> kernel (and I have some plan to do that) but I fail to see how this
> would solve this particular problem.
It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
Ben.
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Jean Delvare @ 2008-02-18 20:58 UTC (permalink / raw)
To: benh; +Cc: parabelboi, Christian Krafft, linux-kernel, linuxppc-dev
In-Reply-To: <1203367323.6740.21.camel@pasglop>
On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
>
> > Maybe Christian's patch can be improved to not do the check on these?
> > As long as /dev/port exists, it seems reasonable that the kernel should
> > behave, no matter what I/O ports are accessed from user-space.
>
> nonsense.
>
> /dev/mem exists for example, but you are still not supposed to go
> bang all over the place in it.
You should at least be able to read from it without crashing the
machine. Of course writing is a different story.
> > > I hate that sensors_detect.. or for that matter any other userland code
> > > that pokes random ports like that. It should die.
> >
> > What do you propose as a replacement?
>
> Dunno, something less scary, like knowing where your sensors are on a
> given machine...
You mean, having a complete database for the, what, 4000 PC
motherboards out there? And maintaining it day after day? _This_ sounds
much scarier to me than the current situation.
> honestly, it's just scary the risk you guys are taking
> by banging random IO ports.
I don't remember anyone reporting problems with this in the past 3 or 4
years, so it doesn't seem to be a big problem in practice.
> At the very least, that shouldn't be done on non-x86.
I am surprised that anyone would actually run sensors-detect on
non-x86... Non-PC hardware usually doesn't have sensors driven by
"hwmon" drivers anyway, or people know what they have and do not need
detection. But I would be totally fine with updating sensors-detect to
skip some of the probes on non-x86 hardware. There are basically
3 /dev/port probes that are done currently:
* Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
* Legacy PC hardware monitoring chips at 0x290-0x297.
* IPMI interface at 0x0ca3 and 0x0cab (read-only).
Please tell me which ones should be skipped on PowerPC.
Christian, can you tell me which of these probes caused trouble for you?
> > And how is userland code poking at random ports different from kernel
> > code poking at random ports? We could move sensors-detect inside the
> > kernel (and I have some plan to do that) but I fail to see how this
> > would solve this particular problem.
>
> It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
The same could be done for user-space (or at the /dev/port level.)
--
Jean Delvare
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Arjan van de Ven @ 2008-02-18 21:04 UTC (permalink / raw)
To: Jean Delvare; +Cc: parabelboi, linux-kernel, linuxppc-dev, Christian Krafft
In-Reply-To: <20080218215842.66bb004f@hyperion.delvare>
On Mon, 18 Feb 2008 21:58:42 +0100
Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
> >
> > > Maybe Christian's patch can be improved to not do the check on
> > > these? As long as /dev/port exists, it seems reasonable that the
> > > kernel should behave, no matter what I/O ports are accessed from
> > > user-space.
> >
> > nonsense.
> >
> > /dev/mem exists for example, but you are still not supposed to go
> > bang all over the place in it.
>
> You should at least be able to read from it without crashing the
> machine. Of course writing is a different story.
keep dreaming. This is not how /dev/mem works today, not on x86 and very likely not on ppc either.
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Benjamin Herrenschmidt @ 2008-02-18 21:05 UTC (permalink / raw)
To: Jean Delvare; +Cc: parabelboi, Christian Krafft, linux-kernel, linuxppc-dev
In-Reply-To: <20080218215842.66bb004f@hyperion.delvare>
>
> * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
>
> * Legacy PC hardware monitoring chips at 0x290-0x297.
>
> * IPMI interface at 0x0ca3 and 0x0cab (read-only).
>
> Please tell me which ones should be skipped on PowerPC.
Skip the whole thing. I consider that on a powerpc linux port, the
platform is responsible for telling drivers where things are (via the
device tree generally)
> Christian, can you tell me which of these probes caused trouble for you?
>
> > > And how is userland code poking at random ports different from kernel
> > > code poking at random ports? We could move sensors-detect inside the
> > > kernel (and I have some plan to do that) but I fail to see how this
> > > would solve this particular problem.
> >
> > It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
>
> The same could be done for user-space (or at the /dev/port level.)
Well, there are -other- legit usages of /dev/port...
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Michael Ellerman @ 2008-02-18 21:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev, Geert Uytterhoeven,
Willy Tarreau, Arjan van de Ven
In-Reply-To: <20080218141340.GB667@cs181133002.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > >
> > > This means it generates faster code with a current gcc for your platform.
> > >
> > > But a future gcc might e.g. replace the whole loop with a division
> > > (gcc SVN head (that will soon become gcc 4.3) already does
> > > transformations like replacing loops with divisions [1]).
> >
> > Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(),
> > if it doesn't live up to its promise?
>
> That's a different issue.
>
> My point here is that we do not know how the latest gcc available in the
> year 2010 might transform this code, and how a likely/unlikely placed
> there might influence gcc's optimizations then.
You're right, we don't know. But if giving the compiler _more_
information causes it to produce vastly inferior code then we should be
filing gcc bugs. After all the unlikely/likely is just a hint, if gcc
knows better it can always ignore it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Clemens Koller @ 2008-02-18 23:35 UTC (permalink / raw)
To: linux-fbdev-devel
Cc: adaplas, Krzysztof Helt, linux-kernel, linuxppc-dev,
Geert Uytterhoeven, Andrew Morton
In-Reply-To: <19805.1203355811@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu schrieb:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
>> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
>> Both resolve endianess at driver level. Actually, both handle it by setting special
>> bits so the graphics chip itself reorder bytes to transform foreign endianess.
>> I understand that this patch is for chips which cannot reorder bytes by themselves.
>
> Does anybody know of such a chip that's actually available in the wild? Or are
> we writing drivers for speculative possible chips?
>
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Regards,
Clemens
^ permalink raw reply
* Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: Clemens Koller @ 2008-02-18 23:51 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0802180845m3287e30bi42f57b0a2522983f@mail.gmail.com>
Hi, Magendra!
- please don't top-post!
- and please keep the list on CC:
mahendra varman schrieb:
> Sir,
> I have enabled the necessary configs for ISP1562
>
> The IRQ number is 39 and while probing the driver correctly assigns the
> IRQ number
>
> but if i insert a device in usb port iam getting error as
>
> Unlink after no-IRQ? "
> "Controller is probably using the wrong IRQ"
>
> Although the interrupt number assignment is correct why it gives the
> above message ?
Well, that seems odd. What kind of cpu / platform / hardware are you using?
Please send the output of `lspci -vv` and `cat /proc/cpuinfo`
If you have the ISP1562 attached to PCI, I guess the interrupt assignments
are wrong or the IRQ line is broken.
Regards,
Clemens
^ 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