* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Darrick J. Wong @ 2008-03-10 18:13 UTC (permalink / raw)
To: Roel Kluin; +Cc: Colin Leroy, lkml, linuxppc-dev
In-Reply-To: <47D5068F.8050709@tiscali.nl>
On Mon, Mar 10, 2008 at 10:59:43AM +0100, Roel Kluin wrote:
> > The & 0xff here is bogus anyway; temp is only ever used as an u8,
> > so just declare it as that, or do proper overflow/underflow checking
> > on it. The patch will need testing on hardware too, since it changes
> > behaviour (it should be a bugfix, but who knows).
>
> Maybe someone can test this?
I did. No regressions observed and it fixes that bug as well. Sorry I
didn't catch it earlier... :/
Acked-by: Darrick J. Wong <djwong@us.ibm.com>
--D
^ permalink raw reply
* Please pull from 'for-2.6.25' [updated]
From: Kumar Gala @ 2008-03-10 18:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8379_mds.dts | 70 ++
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/wrapper | 6
arch/powerpc/configs/adder875-redboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875-uboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875_defconfig | 813 ++++++++++++++++++++++++
arch/powerpc/kernel/head_8xx.S | 30
arch/powerpc/platforms/83xx/mpc837x_mds.c | 8
arch/powerpc/platforms/Kconfig | 1
arch/powerpc/platforms/Kconfig.cputype | 7
arch/powerpc/sysdev/qe_lib/qe.c | 7
arch/ppc/kernel/head_8xx.S | 30
include/asm-powerpc/pgtable-ppc32.h | 8
include/asm-ppc/pgtable.h | 8
16 files changed, 1105 insertions(+), 1635 deletions(-)
Andy Fleming (1):
[POWERPC] 83xx: Make 83xx perfmon support selectable
Ionut Nicu (1):
[POWERPC] QE: Make qe_get_firmware_info reentrant
Jeremy McNicoll (1):
[POWERPC] 85xx: sbc8548 - Fix incorrect PCI-X and PCI interrupt map
Li Yang (2):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
[POWERPC] 83xx: Add local bus device nodes to MPC837xMDS device trees.
Scott Wood (1):
[POWERPC] 8xx: Fix wrapper platform for adder875, and combine defconfigs.
Timur Tabi (1):
[POWERPC] QE: Fix QE firmware uploading limit
Vitaly Bordug (1):
[POWERPC] 8xx: fix swap
Yuri Tikhonov (1):
[PPC] 8xx: swap bug-fix
^ permalink raw reply
* RE: OF compatible MTD platform RAM driver ?
From: Rune Torgersen @ 2008-03-10 17:00 UTC (permalink / raw)
To: Laurent Pinchart, linuxppc-dev; +Cc: ben, linux-mtd
In-Reply-To: <200803101606.39184.laurentp@cse-semaphore.com>
linuxppc-dev-bounces+runet=3Dinnovsys.com@ozlabs.org wrote:
> Hi everybody,
>=20
> as part of a ARCH=3Dppc to ARCH=3Dpowerpc migration process, I'm
> looking for an
> OpenFirmware compatible way to handle a RAM-based MTD device.
>=20
> On the platform_device based ppc architecture, the
> drivers/mtd/maps/plat-ram.c
> driver handled "mtd-ram" platform devices. There is no such
> driver for the
> OF-based powerpc architecture.
>=20
> As a temporary workaround I hacked the physmap_of driver to
> handle "direct-mapped" OF devices oh type "ram" by adding a
> corresponding entry in the of_flash_match[] array. This seems to work
> fine.=20
>=20
> What would be the preferred way to handle OF-compatible RAM-based MTD
> devices ? The 3 ways I can think of are
>=20
> 1. porting the plat-ram driver to OF (the driver isn't used
> in the kernel tree
> but I suspect it is used by out-of-tree boards)
>=20
> 2. creating a new plat-ram-of driver, much like the
> physmap_of driver comes
> from the physmap driver
>=20
> 3. extending the physmap_of driver to handle RAM devices (in
> which case
> references to "flash" in the function names should probably
> be replaced
> by "mtd")
>=20
> I live option 3 better so far.
>=20
> Has anyone already worked on this ? Is there any defined
> device tree mapping
> for MTD RAM devices ?
>=20
> Best regards,
We ran ito the same issue.=20
We did option 3, as it was efinetly the easiest,
here is the sram entry in our dts:
sram@9,0 {
device_type =3D "rom";
compatible =3D "direct-mapped";
probe-type =3D "RAM";
reg =3D <9 0 20000>;
bank-width =3D <2>;
device-width =3D <2>;
#address-cells =3D <1>;
#size-cells =3D <1>;
partition@0 {
label =3D "SRAM";
reg =3D <0 20000>;
};
here is the change to physmap_of.c:
diff --git a/drivers/mtd/maps/physmap_of.c
b/drivers/mtd/maps/physmap_of.c
old mode 100644
new mode 100755
index aeed9ea..687ef54
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -201,6 +201,8 @@ static struct mtd_info * __devinit
obsolete_probe(struct of_device *dev,
return do_map_probe("cfi_probe", map);
} else if (strcmp(of_probe, "JEDEC") =3D=3D 0) {
return do_map_probe("jedec_probe", map);
+ } else if (strcmp(of_probe, "RAM") =3D=3D 0) {
+ return do_map_probe("map_ram", map);
} else {
if (strcmp(of_probe, "ROM") !=3D 0)
dev_warn(&dev->dev, "obsolete_probe: don't know
probe "
^ permalink raw reply related
* Re: Confused about usercopy_64.c
From: Andreas Schwab @ 2008-03-10 16:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47D56419.6000704@freescale.com>
Timur Tabi <timur@freescale.com> writes:
> I'm confused about something in usercopy_64.c:
>
> unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> if (likely(access_ok(VERIFY_READ, from, n)))
> n = __copy_from_user(to, from, n);
> else
> memset(to, 0, n);
> return n;
> }
>
> If access_ok() returns false, then that means that we cannot copy the data from
> user-space. So why are we returning 'n'?
To tell the caller that the function failed. The result is the number
of bytes _left_ to be copying, ie. zero means success.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Confused about usercopy_64.c
From: Olof Johansson @ 2008-03-10 16:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47D56419.6000704@freescale.com>
On Mon, Mar 10, 2008 at 11:38:49AM -0500, Timur Tabi wrote:
> I'm confused about something in usercopy_64.c:
>
> unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> if (likely(access_ok(VERIFY_READ, from, n)))
> n = __copy_from_user(to, from, n);
> else
> memset(to, 0, n);
> return n;
> }
>
> If access_ok() returns false, then that means that we cannot copy the data from
> user-space. So why are we returning 'n'? Shouldn't we return zero, to let the
> caller know that the function failed?
copy_from_user() returns number of bytes _not_ copied.
-Olof
^ permalink raw reply
* Confused about usercopy_64.c
From: Timur Tabi @ 2008-03-10 16:38 UTC (permalink / raw)
To: linuxppc-dev
I'm confused about something in usercopy_64.c:
unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
{
if (likely(access_ok(VERIFY_READ, from, n)))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
}
If access_ok() returns false, then that means that we cannot copy the data from
user-space. So why are we returning 'n'? Shouldn't we return zero, to let the
caller know that the function failed?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-10 15:13 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803101501.34439.jens@de.ibm.com>
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
I will try it and will post the results back.
Thanks Jens.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-10 15:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ben, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c
driver handled "mtd-ram" platform devices. There is no such driver for the
OF-based powerpc architecture.
As a temporary workaround I hacked the physmap_of driver to
handle "direct-mapped" OF devices oh type "ram" by adding a corresponding
entry in the of_flash_match[] array. This seems to work fine.
What would be the preferred way to handle OF-compatible RAM-based MTD
devices ? The 3 ways I can think of are
1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree
but I suspect it is used by out-of-tree boards)
2. creating a new plat-ram-of driver, much like the physmap_of driver comes
from the physmap driver
3. extending the physmap_of driver to handle RAM devices (in which case
references to "flash" in the function names should probably be replaced
by "mtd")
I live option 3 better so far.
Has anyone already worked on this ? Is there any defined device tree mapping
for MTD RAM devices ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v3] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2008-03-10 15:02 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <200803101205.16158.laurentp@cse-semaphore.com>
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It extends the "[PATCH v3] using mii-bitbang on different processor ports".
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..3285f58 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2003,10 +2003,14 @@ platforms are moved over to use the flattened-device-tree model.
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
- fsl,cpm2-mdio-bitbang (reg is port C registers)
+ fsl,cpm2-mdio-bitbang
Properties for fsl,cpm2-mdio-bitbang:
- fsl,mdio-pin : pin of port C controlling mdio data
- fsl,mdc-pin : pin of port C controlling mdio clock
+ The first reg resource is the I/O port register block on which MDC
+ resides. The second reg resource is the I/O port register block on
+ which MDIO resides. If there is only one reg resource, it is used for
+ both MDIO and MDC.
+ fsl,mdio-pin : pin of chosen port for controlling mdio data
+ fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
^ permalink raw reply related
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Kumar Gala @ 2008-03-10 14:39 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204934343-5235-1-git-send-email-afleming@freescale.com>
On Mar 7, 2008, at 5:59 PM, Andy Fleming wrote:
> Not all e300 cores support the performance monitors, and the ones
> that don't will be confused by the mf/mtpmr instructions. This
> allows the support to be optional, so the 8349 can turn it off
> while the 8379 can turn it on. Sadly, those aren't config options,
> so it will be left to the defconfigs and the users to make that
> determination.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
>
> Ugh. The previous version was a little hasty. Needed to base off
> PPC_83xx rather than 83xx
>
> arch/powerpc/platforms/Kconfig | 1 -
> arch/powerpc/platforms/Kconfig.cputype | 7 ++++++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Kumar Gala @ 2008-03-10 14:39 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200802021047.32055.yur@emcraft.com>
On Feb 2, 2008, at 1:47 AM, Yuri Tikhonov wrote:
>
> Hello,
>
> Here is the patch which makes Linux-2.6 swap routines operate
> correctly on
> the ppc-8xx-based machines.
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
applied.
- k
^ permalink raw reply
* Query about Kernel Load address
From: Akhilesh Soni @ 2008-03-10 13:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
I''ve ported u-boot-1.1.1 sucessfully on my IBM STBx25xx rewood6 platform (ppc405 core). Earlier in the ppcboot I used to load the zImage.treeboot directly via the bootloader and it used to relocate and run.
But with u-boot which image I should use and which address I should load the image. My board has 64 MB of RAM and out of which 32 MB is mapped at 0x0000000 and another 32MB is mapped at 0xA0000000. The U-boot code is located at 0x1fe2000 in RAM.
Also is there any 2.6 kernel source supporting redwood6 IBM STBx25xx platform.
Thanx in advance.
Regards,
Akhilesh
[-- Attachment #2: Type: text/html, Size: 1425 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Jens Osterkamp @ 2008-03-10 14:01 UTC (permalink / raw)
To: linuxppc-dev, luisgpm
Cc: Jan Kratochvil, Paul Mackerras, Roland McGrath, Arnd Bergmann
In-Reply-To: <1205110432.10078.5.camel@gargoyle>
On Monday 10 March 2008, Luis Machado wrote:
> > Yes, I know. I tried it on the PS3 first and couldn't reproduce
> > the bug he saw on the blade.
>
> Arnd,
>
> Do we have any news on this topic?
>
> I've seen this happening quite often within GDB when using hardware
> watchpoints on a shared variable in a threaded (7+ threads) binary.
> Sometimes the watchpoint won't trigger, even though the monitored
> variable's value was modified.
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
already did this. Uli Weigand found this back in November. I submitted
a patch for this which went into 2.6.25-rc4.
Can you please try again with rc4 ?
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-03-10 13:17 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <200803101205.16158.laurentp@cse-semaphore.com>
Am Montag, den 10.03.2008, 12:05 +0100 schrieb Laurent Pinchart:
> Your documentation patch states that
>
> "The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC."
>
> If I'm not mistaken the code uses the first reg resource for MDC and the
> second reg resource for MDIO. Which one should be fixed, the doc or the
> code ?
>
> Best regards,
>
Ooops... Sorry...
You are right: the first is MDC, second MDIO.
I have to fix the docu, it would be simpler.
Thank you and best regards
Sergej.
^ permalink raw reply
* Re: DTC 1.1.0 Release!
From: Geert Uytterhoeven @ 2008-03-10 12:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JI5CO-0002Y1-A1@jdl.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1001 bytes --]
Hi John,
On Thu, 24 Jan 2008, Jon Loeliger wrote:
> You may find it using git here:
>
> git://www.jdl.com/software/dtc
>
> A tarball snap-shot is also available here:
>
> http://www.jdl.com/software/dtc-1.1.0.tgz
>
> Please let me know if there are problems with it!
It looks like www.jdl.com got wiped out? I cannot get dtc anymore from your
site, both git and http (default apache page) fail?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-10 12:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080307162135.GC10545@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
On Friday 07 March 2008 17:21, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> > The CPM dual port ram was defined in the device tree as follows (copied
> > from the MPC8272ADS board device tree).
> >
> > muram@0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <0 0 10000>;
> >
> > data@0 {
> > compatible = "fsl,cpm-muram-data";
> > reg = <0 2000 9800 800>;
> > };
> > };
> >
> > Changing the reg property to
> >
> > reg = <80 1f80 9800 800>;
> >
> > fixed my problem.
>
> Perhaps there's an SMC1 running with its parameter RAM at offset zero?
Good guess. U-Boot configured SMC1 with its parameter RAM at offset 0.
> > Does anyone have any clue regarding what could write to the dpram ? I
> > thought about some CPM peripheral set up by the boot loader, but my board
> > initialization code calls cpm2_reset() long before initializing SCC1.
>
> cpm2_reset() doesn't currently actually reset the CPM, for some reason
> (unlike cpm1). This should probably be fixed, though then we'd have to
> deal with assigning SMC parameter RAM addresses ourselves.
I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any
reason not to rset the CPM in cpm2_reset() ?
How should SMC parameter RAM assignment be handled ? I'm not very familiar
with the CPM1, but for CPM2 the cpm_uart driver could easily cpm_dpalloc()
parameter RAM.
> For now, the above fix should be done on any board with an active SMC
> device (assuming SMC parameter RAM at zero, as u-boot sets it; other
> bootloaders may need to exempt a different region).
Thanks for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-03-10 11:05 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <1205135421.3837.1.camel@p60365-ste>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Monday 10 March 2008 08:50, Sergej Stepanov wrote:
> > Acked-by: Scott Wood <scottwood@freescale.com>, if I haven't already.
> >
> > -Scott
>
> I thought, you did it.
> Thank you.
Your documentation patch states that
"The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC."
If I'm not mistaken the code uses the first reg resource for MDC and the
second reg resource for MDIO. Which one should be fixed, the doc or the
code ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 9:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Colin Leroy, Darrick J. Wong, lkml, linuxppc-dev
In-Reply-To: <64d5b5e6dfd0d1820d21db323ef88e25@kernel.crashing.org>
Segher Boessenkool wrote:
>> diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
>> index 9587869..8ea7da2 100644
>> --- a/drivers/hwmon/adt7473.c
>> +++ b/drivers/hwmon/adt7473.c
>> @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
>> *dev,
>> struct i2c_client *client = to_i2c_client(dev);
>> struct adt7473_data *data = i2c_get_clientdata(client);
>> int temp = simple_strtol(buf, NULL, 10);
>> - temp = temp && 0xFF;
>> + temp &= 0xFF;
>>
>> mutex_lock(&data->lock);
>> data->max_duty_at_overheat = temp;
>
> The & 0xff here is bogus anyway; temp is only ever used as an u8,
> so just declare it as that, or do proper overflow/underflow checking
> on it. The patch will need testing on hardware too, since it changes
> behaviour (it should be a bugfix, but who knows).
Maybe someone can test this?
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) & 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Segher Boessenkool @ 2008-03-10 9:13 UTC (permalink / raw)
To: Roel Kluin; +Cc: Colin Leroy, lkml, linuxppc-dev
In-Reply-To: <47D4EFC1.1050403@tiscali.nl>
> diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
> index 9587869..8ea7da2 100644
> --- a/drivers/hwmon/adt7473.c
> +++ b/drivers/hwmon/adt7473.c
> @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
> *dev,
> struct i2c_client *client = to_i2c_client(dev);
> struct adt7473_data *data = i2c_get_clientdata(client);
> int temp = simple_strtol(buf, NULL, 10);
> - temp = temp && 0xFF;
> + temp &= 0xFF;
>
> mutex_lock(&data->lock);
> data->max_duty_at_overheat = temp;
The & 0xff here is bogus anyway; temp is only ever used as an u8,
so just declare it as that, or do proper overflow/underflow checking
on it. The patch will need testing on hardware too, since it changes
behaviour (it should be a bugfix, but who knows).
Segher
^ permalink raw reply
* RE: TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-03-10 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080308012738.0C3D9247AF@gemini.denx.de>
Wolfgang wrote:
>>=20
>> I thought about this possible solution (adding resource description to=20
>> device tree), but as far as I understood, the device tree was intended t=
o=20
>> describe the microcontroller peripherals and tqm5200, based on the mpc52=
00=20
>> is sold out also without sm501, so that's why I discarded this option.
>
>=20
> The device tree describes the hardware, and the TQM5200 (with SM501)
> and the TQM5200S (without the SM501) are two different boards and
> need different device trees.
>=20
So I got it wrong... Good to know. Once I had something working I can give =
it=20
a try and make a different device tree for TQM5200 and TQM5200S and try
to initialize the SM501 using of_platform api.
>=20
> And, Pedro - could you please restrict your line length to some 70+
> characters or so? Thanks.
Ups, sorry. I'll do it since now.
> Best regards,
>=20
> Wolfgang Denk
>
Best regards,
Pedro L. Dominguez.
=20
> --=20
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> "The greatest warriors are the ones who fight for peace."
> - Holly Near
_________________________________________________________________
Tecnolog=EDa, moda, motor, viajes,=85suscr=EDbete a nuestros boletines para=
estar siempre a la =FAltima
Guapos y guapas, clips musicales y estrenos de cine. =
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 8:22 UTC (permalink / raw)
To: benh; +Cc: Colin Leroy, linuxppc-dev, lkml
In-Reply-To: <1205136413.8621.3.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-10 at 08:46 +0100, Colin Leroy wrote:
>> On Mon, 10 Mar 2008 01:04:33 +0100, Roel Kluin wrote:
>>
>>> logical-bitwise & confusion
>> Looks good to me, but I'm not really maintaining that anymore :-)
>> I'm not sure who does, Cc:ing Benjamin as he'll probably know.
>
> Nobody is U suspect...
>
> Send it to the list linuxppc-dev@ozlabs.org, it should be picked up
> anyway.
(linuxppc-dev CC'd)
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..8ea7da2 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+ temp &= 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-03-10 7:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20080307163747.GF10545@ld0162-tx32.am.freescale.net>
> Acked-by: Scott Wood <scottwood@freescale.com>, if I haven't already.
>=20
> -Scott
I thought, you did it.
Thank you.
--=20
Dipl.-Ing. Sergej Stepanov=20
Software-Entwicklung
IDS GmbH=20
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,=20
D-76275 Ettlingen=20
T. (0) 72 43/2 18-615=20
F. (0) 72 43/2 18-100=20
E. Sergej.Stepanov@ids.de
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503=20
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Stephen Rothwell @ 2008-03-10 6:35 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <47D4D686.8010101@denx.de>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
Hi,
On Mon, 10 Mar 2008 07:34:46 +0100 Heiko Schocher <hs@denx.de> wrote:
>
> >> +static struct of_device_id __initdata of_bus_ids[] = {
> >
> > Make this __initdata, please.
>
> Hmm.. it is __initdata, or? But I fix it to:
OOPS, brain not working again after break :-)
sorry.
> static __initdata struct of_device_id of_bus_ids[]
It is right either way. But linux/init.h says it should go just before
the '=' sign.
> I will send a overworked patch.
Nice :-) ("overworked" means "having too much work to do" - I think you
meant "reworked")
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Heiko Schocher @ 2008-03-10 6:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080310143217.11e2b10f.sfr@canb.auug.org.au>
Hello Stephen,
Stephen Rothwell wrote:
> On Sun, 09 Mar 2008 10:56:29 +0100 Heiko Schocher <hs@denx.de> wrote:
>> +++ b/arch/powerpc/platforms/8xx/mgsuvd.c
>>
>> +#include <asm/of_platform.h>
>
> You should include linux/of_platform.h (not asm/)
Ok.
>> +static struct cpm_pin mgsuvd_pins[] = {
>
> Make this __initdata, please.
Argh... forgot this.
[...]
>> +static struct of_device_id __initdata of_bus_ids[] = {
>
> Make this __initdata, please.
Hmm.. it is __initdata, or? But I fix it to:
static __initdata struct of_device_id of_bus_ids[]
>> +static int __init declare_of_platform_devices(void)
>> +{
>> + if (!machine_is(mgsuvd))
>> + return 0;
>> +
>> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
>> +
>> + return 0;
>> +}
>> +device_initcall(declare_of_platform_devices);
>
> This should be "machine_device_initcall(mgsuvd,
> declare_of_platform_devices);" then you don't need the machine_is() check
> above.
Ok
I will send a overworked patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Heiko Schocher @ 2008-03-10 6:33 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20080309195914.69d51e68@kernel.crashing.org>
Hello Vitaly,
Vitaly Bordug wrote:
> Heiko Schocher wrote:
>> the following patch adds support for the MPC852 based mgsuvd board
>> from keymile.
> Looks good overall. Please add supported/working/not working etc SoC devices state along with the patch
> description. Also a few really small comments below...
OK.
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
[...]
>> +
>> + PowerPC,866@0 {
> But it's mpc852, isn't it?
Yes your are right.
>> + device_type = "cpu";
>> + reg = <0>;
>> + d-cache-line-size = <d#16>;
>> + i-cache-line-size = <d#16>;
>> + d-cache-size = <d#8192>;
>> + i-cache-size = <d#8192>;
>> + timebase-frequency = <0>; /* Filled in by
>> u-boot */
>> + bus-frequency = <0>; /* Filled in by u-boot
>> */
>> + clock-frequency = <0>; /* Filled in by
>> u-boot */
>> + interrupts = <f 2>; // decrementer
>> interrupt
> I would like all the comments to be consistent C style (because that's it for the most other dts'es).
Okay, I fix this, and send a new patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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