According to my schematics, on Lite5200 board ethernet phy uses address
0 (all ADDR lines are pulled down). With this change I can talk to
onboard phy (LXT971) and correctly use autonegotiation.
Signed-off-by: Dmitry Eremin-Solenikov
Cc: René Bürgel
Cc: Paul Mackerras
Cc: Grant Likely
Cc: Yoge
According to my schematics, on Lite5200 board ethernet phy uses address
0 (all ADDR lines are pulled down). With this change I can talk to
onboard phy (LXT971) and correctly use autonegotiation.
Signed-off-by: Dmitry Eremin-Solenikov
Cc: René Bürgel
Cc: Paul Mackerras
Cc: Grant Likely
Cc: Yoge
Hello List Members,
I have tried multiple versions/branches and git repos (torvalds,
benh/{next,master}, denx, pengutronix, ...) to get a 2.6.34 or HEAD
version of that repos that compiles w/o errors when the CAN subsystem
is enabled and the MPC5xxx onboard driver is selected starting with
the lit
On Wed, 2010-06-09 at 08:05 -0400, Josh Boyer wrote:
> On Wed, Jun 09, 2010 at 01:02:39PM +0200, Christoph Egger wrote:
> >CONFIG_PPC47x should actually be spelled CONFIG_PPC_47x as reported by
> >Andreas Schwab.
> >
> >Signed-off-by: Christoph Egger
>
> Thanks, I'll pull this one in and get it m
> And which one is "good" or "better" for CAN+MPC52xx if that's
> different?
The mainline kernel works fine here with Phytec based MPC5xxx-boards. Some
custom boards, too. You probably already know that it is always best to
stay as close to mainline as possible ;) Maybe just the lite-support is
sl
On Wednesday 09 June 2010, Sukadev Bhattiprolu wrote:
> Albert and Randy point out that this would require #ifdefs in the
> application code that intends to be portable across say IA64 and x86.
>
> Can we instead have all architectures specify [base, size] ?
No objections from me on that.
On 06/10/2010 10:41 AM, Roman Fietze wrote:
> Hello List Members,
>
> I have tried multiple versions/branches and git repos (torvalds,
> benh/{next,master}, denx, pengutronix, ...) to get a 2.6.34 or HEAD
> version of that repos that compiles w/o errors when the CAN subsystem
> is enabled and the
Hello Wolfram,
On Thursday 10 June 2010 10:59:23 Wolfram Sang wrote:
> The mainline kernel works fine here with Phytec based MPC5xxx-boards.
Reading your answer made me hope again, and I just pulled the newest
HEAD from the mainline kernel and tried it once more. Now it compiles.
Thanks for retr
On Thu, Jun 10, 2010 at 08:29:08AM +0200, Richard Cochran wrote:
> On Wed, Jun 09, 2010 at 11:32:19PM +0400, Anton Vorontsov wrote:
> > Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a ("gianfar: Add
> > hardware RX timestamping support"), the driver no longer works on
> > at least MPC8313ERDB
On 06/10/2010 11:29 AM, Roman Fietze wrote:
> Hello Wolfram,
>
> On Thursday 10 June 2010 10:59:23 Wolfram Sang wrote:
>
>> The mainline kernel works fine here with Phytec based MPC5xxx-boards.
>
> Reading your answer made me hope again, and I just pulled the newest
> HEAD from the mainline kern
On Thu, Jun 10, 2010 at 01:31:59PM +0400, Anton Vorontsov wrote:
> > No, we did not set TMR_CTRL[TE].
>
> So, you deliberately violate the spec and expect it to work
> everywhere? :-)
Sometimes one must read the manual with a grain of salt ;)
> > > Also, I recall that Freescale BSPs were explici
On Thu, Jun 10, 2010 at 12:22:26PM +0200, Richard Cochran wrote:
[...]
> > U-Boot 1.1.6 (Oct 9 2007 - 20:42:39) MPC83XX
> ...
> > CPU: MPC8313E, Rev: 10 at 333.333 MHz
>
> We have a newer CPU revision:
>
>U-Boot 1.3.0 (Dec 23 2008 - 13:38:14) MPC83XX
>CPU: e300c3, MPC8313E, Rev: 21 at
From: Amit Shah
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problemat
On Thu, Jun 10, 2010 at 04:14:21PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-06-09 at 08:35 -0400, Josh Boyer wrote:
> > On Wed, Jun 09, 2010 at 12:00:21PM +0200, Christoph Egger wrote:
> > >CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
> > >references for it from the so
On Wed, Jun 09, 2010 at 03:55:59PM +0530, K.Prasad wrote:
> + if (!((bp->attr.bp_addr <= dar) &&
> + (dar <= (bp->attr.bp_addr + bp->attr.bp_len {
> + /*
> + * This exception is triggered not because of a memory access
> + * on the monitored v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've dug up and revived my old Mac Mini (PPC) and been trying to get it
to work again. I was looking at getting the system to suspend to ram,
but it didn't seem to be working. So, I tried to trace down the problem.
I took a look at the kernel code, an
SIOCGMIIREG and SIOCSMIIREG access a user data structure via a void
pointer to user space. So, we need copy_from_user and copy_to_user
to move the data.
Signed-off-by: Steven A. Falco
---
I believe there is a bug in the way the ibm_newemac driver handles the
SIOCGMIIREG (and SIOCSMIIREG) ioctl
On Thu, Jun 10, 2010 at 12:17 AM, Benjamin Herrenschmidt
wrote:
>
>> You just introduced an unnamed structure of device + resources,
>> it isn't declared anywhere but in the code itself (either via
>> &foo[1] or buf + sizeof(*foo)).
>>
>> You're not the only one who hacks (or at least have to
>> u
On Thursday 10 June 2010, Steven A. Falco wrote:
> I believe there is a bug in the way the ibm_newemac driver handles the
> SIOCGMIIREG (and SIOCSMIIREG) ioctl. The problem is that emac_ioctl
> is handed a "struct ifreq *rq" which contains a user-land pointer to
> an array of 16-bit integers.
Did
On Thu, Jun 10, 2010 at 12:44 AM, Benjamin Herrenschmidt
wrote:
> On Tue, 2010-06-08 at 08:10 -0600, Grant Likely wrote:
>> Certain Apple machines don't use the ranges property correctly, but the
>> workaround should not be applied on other architectures. This patch
>> disables the workaround for
On Thu, Jun 10, Benjamin Herrenschmidt wrote:
> I still don't like it very much.. why not chmod'ing it +x instead ? :-)
I looked at a few other scripts in the source tree, they are called with
$(CONFIG_SHELL) , or perl , or awk or even sh .
So my change adds some sort of consistency and makes p
In message:
Grant Likely writes:
: On Thu, Jun 10, 2010 at 12:17 AM, Benjamin Herrenschmidt
: wrote:
: >
: >> You just introduced an unnamed structure of device + resources,
: >> it isn't declared anywhere but in the code itself (either via
: >> &foo[1] or buf + sizeof(*foo)).
: >>
:
On 06/10/2010 10:31 AM, Arnd Bergmann wrote:
>
> On Thursday 10 June 2010, Steven A. Falco wrote:
>> I believe there is a bug in the way the ibm_newemac driver handles the
>> SIOCGMIIREG (and SIOCSMIIREG) ioctl. The problem is that emac_ioctl
>> is handed a "struct ifreq *rq" which contains a use
From: Matthias Fuchs
This patch adds a gpio driver for MPC512X PowerPCs.
It has been tested on our CAN-CBX-CPU5201 module that
uses a MPC5121 CPU. This platform comes with a couple of
LEDs and configuration switches that have been used for testing.
Signed-off-by: Matthias Fuchs
Signed-off-by:
In message: <20100610154741.ga7...@oksana.dev.rtsoft.ru>
Anton Vorontsov writes:
: On Thu, Jun 10, 2010 at 09:13:57AM -0600, M. Warner Losh wrote:
: [...]
: > : >> I told you several ways of how to improve the code (based on
: > : >> the ideas from drivers/base/, so the ideas aren't ev
On Thu, Jun 10, 2010 at 09:13:57AM -0600, M. Warner Losh wrote:
[...]
> : >> I told you several ways of how to improve the code (based on
> : >> the ideas from drivers/base/, so the ideas aren't even mine,
> : >> fwiw).
> : >
> : > I tend to agree with Anton here.
> :
> : The reason I'm confident
From: Matthias Fuchs
This patch adds a gpio driver for MPC512X PowerPCs.
It has been tested on our CAN-CBX-CPU5201 module that
uses a MPC5121 CPU. This platform comes with a couple of
LEDs and configuration switches that have been used for testing.
Signed-off-by: Matthias Fuchs
Signed-off-by:
On Thu, Jun 10, 2010 at 9:47 AM, Anton Vorontsov wrote:
> On Thu, Jun 10, 2010 at 09:13:57AM -0600, M. Warner Losh wrote:
> [...]
>> : >> I told you several ways of how to improve the code (based on
>> : >> the ideas from drivers/base/, so the ideas aren't even mine,
>> : >> fwiw).
>> : >
>> : > I
Hi kostas,
You need to verify that the driver version of serial and Ethernet (probably
X-LLTEMAC) provided in the virtex440.dts matches version used in kernel.
Look for "compatible = " in the drivers. You can probably use EDK
11.2 as it is the latest from Xilinx.
Have you generated your own DTS a
On Thu, Jun 10, 2010 at 10:01:40AM -0600, M. Warner Losh wrote:
[...]
> But this requires extra, bogus fields in the structure
False. The [0] field isn't bogus, it has a defined meaning.
It says: here is some amount of resouces may be allocated.
> and creates a bogus sizeof issue.
Creates? False
On Thu, Jun 10, 2010 at 12:32 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2010-06-04 at 15:13 -0600, Grant Likely wrote:
>> This series is based on Linus' current tree. It eliminate struct
>> of_device in preparation for the merge of of_platform_bus_type and
>> platform_bus_type.
>>
>> Assuming t
On Thursday 10 June 2010, Steven A. Falco wrote:
> > The ifreq structure passed into the ndo_ioctl function is in kernel
> > space, it gets copied there by net/core/dev.c:dev_ioctl().
> > emac_ioctl only accesses the data in that structure, so a copy_from_user
> > is wrong here as far as I can tell
On Thu, Jun 10, 2010 at 10:30:26AM -0600, Grant Likely wrote:
[...]
> C)
> struct of_device *alloc_function(int num_res)
> {
> struct device *ofdev;
> struct resource *res;
> ofdev = kzalloc(sizeof(*ofdev), GFP_KERNEL)
> if (!ofdev)
> return NULL;
> res =
In message: <20100610165243.ga18...@oksana.dev.rtsoft.ru>
Anton Vorontsov writes:
: On Thu, Jun 10, 2010 at 10:01:40AM -0600, M. Warner Losh wrote:
: [...]
: > But this requires extra, bogus fields in the structure
:
: False. The [0] field isn't bogus, it has a defined meaning.
: It s
Wow, there is some serious bikeshedding going on with this argument
about structures and arrays .
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Jun 10, 2010 at 11:09 AM, Mitch Bradley wrote:
> Wow, there is some serious bikeshedding going on with this argument about
> structures and arrays .
I know! Isn't it fun?
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://li
On Thu, Jun 10, 2010 at 11:10 AM, Anton Vorontsov
wrote:
> On Thu, Jun 10, 2010 at 10:30:26AM -0600, Grant Likely wrote:
> [...]
>> res = kzalloc((sizeof(*res) * num_res), GFP_KERNEL);
>> if (!res) {
>> kfree(ofdev); /* or goto an error unwind label */
>> r
(cc's trimmed and rpjday added)
On Wed, 2010-06-09 at 11:58 +0200, Christoph Egger wrote:
> I've been running a check on the arch/powerpc sourcetree for
> config Items not defined in Kconfig and found5 such chases.
Are you aware of
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
On 06/10/2010 01:03 PM, Arnd Bergmann wrote:
>
> On Thursday 10 June 2010, Steven A. Falco wrote:
>>> The ifreq structure passed into the ndo_ioctl function is in kernel
>>> space, it gets copied there by net/core/dev.c:dev_ioctl().
>>> emac_ioctl only accesses the data in that structure, so a cop
On 10 Jun 2010, at 23:07, Grant Likely wrote:
> To me, this seems firmly in the realm of silicon bug workaround.
> Considering that the pins aren't relocatable (ie, the GPIO numbers
> never change), I've got no problem having the GPIO reset logic added
> to arch/powerpc/platforms/52xx and hard cod
On 06/10/2010 04:35 PM, Arnd Bergmann wrote:
>
> It seems that your program is wrong. On my PC here, it also shows zero,
> while mii-tool works fine.
>
You are correct. I didn't realize I should embed the data
in the ifr_data area - I thought I needed to pass a pointer.
Now I see why you avoid
Enables support for HMC initiated partition hibernation. This is
a firmware assisted hibernation, since the firmware handles writing
the memory out to disk, along with other partition information,
so we just mimic suspend to ram.
Signed-off-by: Brian King
---
arch/powerpc/Kconfig
On Wed, Jun 9, 2010 at 4:30 AM, Mark Brown
wrote:
> On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
>> In message
>> you wrote:
>
>> > Would making a change in uboot be a better solution? Eric, can you
>> > verify if changing uboot also fixes the problem?
>
>> To me it seems bette
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=16178
for your bug report, please add your address to the CC list in there, thanks!
On niedziela, 6 czerwca 2010 o 17:06:54 Sachin Sant wrote:
> While executing LTP Controller tests(memcg regression) on
> a POWER6 box came
Partition hibernation will use some of the same code as is
currently used for Live Partition Migration. This function
further abstracts this code such that code outside of rtas.c
can utilize it. It also changes the error field in the suspend
me data structure to be an atomic type, since it is set
Hi Grant,
On Thu, 10 Jun 2010 15:48:42 -0600
Grant Likely wrote:
> On Thu, Jun 10, 2010 at 10:21 AM, Anatolij Gustschin wrote:
> > From: Matthias Fuchs
> >
> > This patch adds a gpio driver for MPC512X PowerPCs.
> >
> > It has been tested on our CAN-CBX-CPU5201 module that
> > uses a MPC5121 C
On Tue, Jun 8, 2010 at 10:46 AM, Eric Millbrandt
wrote:
> Allow device drivers to safely modify port-config. This allows device drivers
> access to gpio pins to manually bit-bang slave devices.
>
> Signed-off-by: Eric Millbrandt
Unfortunately, still too much exposure of port-config to drivers f
On Wed, Jun 9, 2010 at 9:39 AM, Eric Millbrandt
wrote:
> The implementation of the ac97 "cold" reset is flawed. If the sync and
> output lines are high when reset is asserted the attached ac97 device
> may go into test mode. Avoid this by reconfiguring the psc to gpio mode
> and generating the r
On Thursday 10 June 2010 21:47:27 Steven A. Falco wrote:
> On 06/10/2010 01:03 PM, Arnd Bergmann wrote:
> > Still unconvinced.
>
> Ok - here is the user-space program I am using to test this. It simply
> uses the ioctl to peek and poke the phy. If I run it on an unmodified
> kernel, and I read t
On Thu, Jun 10, 2010 at 10:21 AM, Anatolij Gustschin wrote:
> From: Matthias Fuchs
>
> This patch adds a gpio driver for MPC512X PowerPCs.
>
> It has been tested on our CAN-CBX-CPU5201 module that
> uses a MPC5121 CPU. This platform comes with a couple of
> LEDs and configuration switches that ha
On Thu, Jun 10, 2010 at 5:14 PM, Mark Brown
wrote:
> On 10 Jun 2010, at 23:07, Grant Likely wrote:
>
>> To me, this seems firmly in the realm of silicon bug workaround.
>> Considering that the pins aren't relocatable (ie, the GPIO numbers
>> never change), I've got no problem having the GPIO reset
On Thu, Jun 10, 2010 at 12:40 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2010-06-04 at 15:21 -0600, Grant Likely wrote:
>> Merge common implementation of of_irq_map_one(). Rename it to
>> __of_irq_map_one() so that arch code can either use the stock
>> implementation, or override it to handle pl
Hi Srikant,
Thanks for your help. I checked the driver versions and they seem ok. The
problem is that when I download the linux image the program counter is not set
to the address of boot sector of linux kernel, so linux doesn't boot. On the
other hand with the ML507 everything works perfectly.
Hi John,
On Thu, 10 Jun 2010 13:03:00 +0200 John Kacur wrote:
>
> From: Amit Shah
>
> Alan pointed out a race in the code where hvc_remove is invoked. The
> recent virtio_console work is the first user of hvc_remove().
I am not sure where this comes from (linuxppc-dev only got 5/5) but this
pa
On Thu, 2010-06-10 at 08:28 -0600, Grant Likely wrote:
> On Thu, Jun 10, 2010 at 12:44 AM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2010-06-08 at 08:10 -0600, Grant Likely wrote:
> >> Certain Apple machines don't use the ranges property correctly, but the
> >> workaround should not be applied o
On Thu, 2010-06-10 at 10:01 -0600, M. Warner Losh wrote:
> : Oh, come on. Both constructions are binary equivalent.
> :
> : So how can people seriously be with *that* code:
> :
> : dev->resource = (void *)&dev[1];
> :
> : which, semantically, is a nonsense and asks for a fix.
>
> It isn't
On Thu, 2010-06-10 at 10:46 -0600, Grant Likely wrote:
>
> It shouldn't need any fixing because I'm not touching the driver side
> of the equation (unlike the last breakage where macio_driver had its
> own copy of the match table which I missed). In fact, there aren't
> even any logic changes oth
On Thu, 2010-06-10 at 17:36 -0600, Grant Likely wrote:
>
> Okay. I had been trying to avoid #ifdefs in the common code, but
> you're probably right. I'll rework.
Not even ifdef's ... just move the quirk map there. You can always
#define the quirk variable to 0 on archs that have no quirks, to
Hi guys,
I encountered a PCIe problem under linux, the two PCIe bus on my board seems
work, at least I can access the registers through the PCIe bus, however the dma
for the PCIe bus can't work, so I just dumped the pci device, but I am
curiously to find there is no regions displayed on PCIe co
On Thu, 10 Jun 2010 22:00:57 +0200
Maciej Rutecki wrote:
> I created a Bugzilla entry at
> https://bugzilla.kernel.org/show_bug.cgi?id=16178
> for your bug report, please add your address to the CC list in there, thanks!
>
Hmm... It seems a panic in SLUB or SLAB.
Is .config available ?
-Kame
On Thu, Jun 10, 2010 at 7:16 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2010-06-10 at 10:46 -0600, Grant Likely wrote:
>>
>> It shouldn't need any fixing because I'm not touching the driver side
>> of the equation (unlike the last breakage where macio_driver had its
>> own copy of the match table
KAMEZAWA Hiroyuki wrote:
On Thu, 10 Jun 2010 22:00:57 +0200
Maciej Rutecki wrote:
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=16178
for your bug report, please add your address to the CC list in there, thanks!
Hmm... It seems a panic in SLUB or SLAB.
I
On Thu, 2010-06-10 at 14:23 +0200, Christoph Egger wrote:
> On Thu, Jun 10, 2010 at 04:14:21PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 08:35 -0400, Josh Boyer wrote:
> > > On Wed, Jun 09, 2010 at 12:00:21PM +0200, Christoph Egger wrote:
> > > >CONFIG_SMP_750 doesn't exist in
63 matches
Mail list logo
