* RE: [PATCH] Add a vga alias node for P1022
From: Zhengxiong Jin @ 2013-11-13 6:28 UTC (permalink / raw)
To: Scott Wood, galak@kernel.crashing.org; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378459957-26334-1-git-send-email-Jason.Jin@freescale.com>
> -----Original Message-----
> From: Jin Zhengxiong-R64188
> Sent: Friday, September 06, 2013 5:33 PM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Jin
> Zhengxiong-R64188
> Subject: [PATCH] Add a vga alias node for P1022
>=20
> From: Jason Jin <Jason.jin@freescale.com>
>=20
> When the vga was set as the stdout and stderr in u-boot, the stdout fixup
> code in u-boot need to find out the vga alias node in dtb.
>=20
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
[Jason Jin-R64188] Any comments about this patch? Thanks.
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-13 2:34 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <1384307175.1403.118.camel__32063.4016803981$1384307228$gmane$org@snotra.buserror.net>
Hello Scott,
On 11/12/2013 07:46 PM, Scott Wood wrote:
> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/12/2013 04:04 PM, Scott Wood wrote:
>>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>>>
>>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>>> ---
>>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>>>> 3 files changed, 35 insertions(+), 188 deletions(-)
>>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>>>
>>> Are we still going to want to have one defconfig if and when we finally
>>> get datapath support upstream? That's a lot of code to add to the 85xx
>>> config just for this one chip.
>>
>> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
>> enabled by default given that just one SoC in that family has the
>> datapath (and we don't plan to put it in another e500v2 based SoC). For
>> regression/automation purposes config fragments should be used
>
> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
> fragment?
Not aware of it
> Do we have any config fragments in the tree so far?
Nope. However, just to make sure, the fragment was my secondary point
and not necessarily as a candidate for upstreaming. My main point was
that the datapath support should simply not be enabled by default in the
mpc85xx_[smp_]defconfig
Cheers,
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 2:01 UTC (permalink / raw)
To: Scott Wood
Cc: shh.xie@gmail.com, Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384307679.1403.122.camel@snotra.buserror.net>
PiBPbiBUdWUsIDIwMTMtMTEtMTIgYXQgMTk6NTEgLTA2MDAsIFhpZSBTaGFvaHVpLUIyMTk4OSB3
cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29k
IFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMyA1
OjU4IEFNDQo+ID4gPiBUbzogc2hoLnhpZUBnbWFpbC5jb20NCj4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+
IEthbmV0a2FyIFNocnV0aS1CNDQ0NTQ7IFhpZSBTaGFvaHVpLUIyMTk4OTsgQnVjdXINCj4gPiA+
IE1hZGFsaW4tQ3Jpc3RpYW4tQjMyNzE2DQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvNF0g
cGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25zDQo+ID4gPg0KPiA+ID4g
T24gTW9uLCAyMDEzLTExLTExIGF0IDE5OjA0ICswODAwLCBzaGgueGllQGdtYWlsLmNvbSB3cm90
ZToNCj4gPiA+ID4gRnJvbTogQW5keSBGbGVtaW5nDQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBuZWVk
IGFuIGV4dHJhIHBhcmFtZXRlciB0byByZWFkIG9yIHdyaXRlIENsYXVzZSA0NSBQSFlzLCBzbyB3
ZQ0KPiA+ID4gPiBuZWVkIGEgZGlmZmVyZW50IEFQSSB3aXRoIHRoZSBleHRyYSBwYXJhbWV0ZXIu
DQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEFuZHkgRmxlbWluZw0KPiA+ID4gPiBT
aWduZWQtb2ZmLWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4g
PiA+DQo+ID4gPiBXaHkgZGlkIHlvdSByZW1vdmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZl
biB0aG91Z2ggaXQncyBubw0KPiA+ID4gbG9uZ2VyIHZhbGlkLCBpdCBoZWxwcyBpZGVudGlmeSB3
aGljaCBzcGVjaWZpYyBwZXJzb24geW91J3JlIHRhbGtpbmcgYWJvdXQuDQo+ID4gPg0KPiA+IFtT
LkhdIEFuZHkncyBlLW1haWwgYWRkcmVzcyBpcyBub3QgdmFsaWQgYW5kIGdpdC1zZW5kLW1haWwg
d2lsbCBmYWlsLCBJIGhhdmUNCj4gdG8gcmVtb3ZlIGl0IHRvIG1ha2UgZ2l0IHdvcmsuDQo+IA0K
PiBUZWxsIGdpdCBzZW5kLWVtYWlsIHRvIG5vdCBpbmNsdWRlIHRoYXQgYWRkcmVzcywgZS5nLiB1
c2luZyAtLXN1cHByZXNzLWNjLCAtLW5vLQ0KPiBzaWduZWQtb2ZmLWJ5LWNjLCAtLXN1cHByZXNz
LWZyb20sIGV0Yy4NCj4gDQpbUy5IXSBPSy4gVGhhbmsgeW91IQ0KDQoNCkJlc3QgUmVnYXJkcywg
DQpTaGFvaHVpIFhpZQ0K
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Emil Medve @ 2013-11-13 1:54 UTC (permalink / raw)
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
Hello Xiao-Hui,
On 11/12/2013 07:51 PM, Shaohui Xie wrote:
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Wednesday, November 13, 2013 5:58 AM
>> To: shh.xie@gmail.com
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
>> Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
>> Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>>
>> On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
>>> From: Andy Fleming
>>>
>>> You need an extra parameter to read or write Clause 45 PHYs, so we
>>> need a different API with the extra parameter.
>>>
>>> Signed-off-by: Andy Fleming
>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>
>> Why did you remove Andy's e-mail address? Even though it's no longer valid, it
>> helps identify which specific person you're talking about.
>>
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Just use Andy's GMail address: afleming@gmail.com
Cheers,
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Scott Wood @ 2013-11-13 1:54 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: shh.xie@gmail.com, Kanetkar Shruti-B44454,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Bucur Madalin-Cristian-B32716
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 13, 2013 5:58 AM
> > To: shh.xie@gmail.com
> > Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
> > Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
> > Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
> >
> > On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
> > > From: Andy Fleming
> > >
> > > You need an extra parameter to read or write Clause 45 PHYs, so we
> > > need a different API with the extra parameter.
> > >
> > > Signed-off-by: Andy Fleming
> > > Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> >
> > Why did you remove Andy's e-mail address? Even though it's no longer valid, it
> > helps identify which specific person you're talking about.
> >
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Tell git send-email to not include that address, e.g. using
--suppress-cc, --no-signed-off-by-cc, --suppress-from, etc.
-Scott
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 1:51 UTC (permalink / raw)
To: Scott Wood, shh.xie@gmail.com
Cc: Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384293487.1403.67.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDU6NTggQU0NCj4gVG86IHNoaC54
aWVAZ21haWwuY29tDQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgt
a2VybmVsQHZnZXIua2VybmVsLm9yZzsgS2FuZXRrYXINCj4gU2hydXRpLUI0NDQ1NDsgWGllIFNo
YW9odWktQjIxOTg5OyBCdWN1ciBNYWRhbGluLUNyaXN0aWFuLUIzMjcxNg0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIDEvNF0gcGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25z
DQo+IA0KPiBPbiBNb24sIDIwMTMtMTEtMTEgYXQgMTk6MDQgKzA4MDAsIHNoaC54aWVAZ21haWwu
Y29tIHdyb3RlOg0KPiA+IEZyb206IEFuZHkgRmxlbWluZw0KPiA+DQo+ID4gWW91IG5lZWQgYW4g
ZXh0cmEgcGFyYW1ldGVyIHRvIHJlYWQgb3Igd3JpdGUgQ2xhdXNlIDQ1IFBIWXMsIHNvIHdlDQo+
ID4gbmVlZCBhIGRpZmZlcmVudCBBUEkgd2l0aCB0aGUgZXh0cmEgcGFyYW1ldGVyLg0KPiA+DQo+
ID4gU2lnbmVkLW9mZi1ieTogQW5keSBGbGVtaW5nDQo+ID4gU2lnbmVkLW9mZi1ieTogU2hhb2h1
aSBYaWUgPFNoYW9odWkuWGllQGZyZWVzY2FsZS5jb20+DQo+IA0KPiBXaHkgZGlkIHlvdSByZW1v
dmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZlbiB0aG91Z2ggaXQncyBubyBsb25nZXIgdmFs
aWQsIGl0DQo+IGhlbHBzIGlkZW50aWZ5IHdoaWNoIHNwZWNpZmljIHBlcnNvbiB5b3UncmUgdGFs
a2luZyBhYm91dC4NCj4gDQpbUy5IXSBBbmR5J3MgZS1tYWlsIGFkZHJlc3MgaXMgbm90IHZhbGlk
IGFuZCBnaXQtc2VuZC1tYWlsIHdpbGwgZmFpbCwgSSBoYXZlIHRvIHJlbW92ZSBpdCB0byBtYWtl
IGdpdCB3b3JrLg0KDQoNCkJlc3QgUmVnYXJkcywgDQpTaGFvaHVpIFhpZQ0K
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/p1010rdb:add P1010RDB-PB platform support
From: Scott Wood @ 2013-11-13 1:50 UTC (permalink / raw)
To: Zhao Qiang; +Cc: tony, devicetree, linuxppc-dev, bcousson
In-Reply-To: <1383791369-29324-1-git-send-email-B45475@freescale.com>
On Thu, 2013-11-07 at 10:29 +0800, Zhao Qiang wrote:
> The P1010RDB-PB is similar to P1010RDB(P1010RDB-PA).
> So, P1010RDB-PB use the same platform file as P1010RDB.
> Then Add support for P1010RDB-PB platform.
>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> arch/powerpc/platforms/85xx/p1010rdb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index 0252961..d6a3dd3 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -66,6 +66,8 @@ static int __init p1010_rdb_probe(void)
>
> if (of_flat_dt_is_compatible(root, "fsl,P1010RDB"))
> return 1;
> + if (of_flat_dt_is_compatible(root, "fsl,P1010RDB-PB"))
> + return 1;
> return 0;
> }
>
This had already been merged into Ben's tree when you reposted it
(without any indication that it was a repost/respin), and is now in
Linus's tree.
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 1:46 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5282B277.4090300@Freescale.com>
On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 11/12/2013 04:04 PM, Scott Wood wrote:
> > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> >> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> >> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
> >>
> >> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> >> ---
> >> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> >> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> >> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> >> 3 files changed, 35 insertions(+), 188 deletions(-)
> >> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >
> > Are we still going to want to have one defconfig if and when we finally
> > get datapath support upstream? That's a lot of code to add to the 85xx
> > config just for this one chip.
>
> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
> enabled by default given that just one SoC in that family has the
> datapath (and we don't plan to put it in another e500v2 based SoC). For
> regression/automation purposes config fragments should be used
Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
fragment? Do we have any config fragments in the tree so far?
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 23:09 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Pan Lijun-B44306, linuxppc-dev@ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B37817C@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-11-12 at 17:05 -0600, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, November 12, 2013 4:52 PM
> > To: Zang Roy-R61911
> > Cc: Pan Lijun-B44306; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> > mpc85xx_smp_defconfig and mpc85xx_defconfig
> >
> > On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> > > > fei.zang=freescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> > > > Sent: Tuesday, November 12, 2013 4:05 PM
> > > > To: Pan Lijun-B44306
> > > > Cc: linuxppc-dev@ozlabs.org
> > > > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig
> > > > into mpc85xx_smp_defconfig and mpc85xx_defconfig
> > > >
> > > > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > > > > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> > > > CONFIG_P1023RDS=y.
> > > > > Merge CONFIG_P1023RDB=y and other relevant configurations into
> > > > mpc85xx_smp_defconfig and mpc85_defconfig.
> > > > >
> > > > > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > > > > ---
> > > > > arch/powerpc/configs/85xx/p1023_defconfig | 188
> > > > > --------------------
> > > > --------
> > > > > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > > > > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > > > > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > > > > 100644 arch/powerpc/configs/85xx/p1023_defconfig
> > > >
> > > > Are we still going to want to have one defconfig if and when we
> > > > finally get datapath support upstream? That's a lot of code to add
> > > > to the 85xx config just for this one chip.
> > > P1023 has dpaa.
> > > Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
> >
> > That's the question I'm asking. Though I suppose we could take a patch
> > like this one for now, and then introduce mpc85xx_dpaa_defconfig when it
> > becomes relevant (which would make clear why the defconfig is separate).
> > p1023 would still work with the non-dpaa defconfigs, but without dpaa
> > support.
>
> It will be hard to find a seat for P1023 in mpc85xx_dpaa_defconfig.
What do you mean?
> P1023 does not have corenet. It has e500v2 core.
> All the other DPAA SOCs have corenet.
> I suggest leaving p1023 defconfig standalone.
I didn't say "mpc85xx_corenet_defconfig", nor did I suggest that
mpc85xx_dpaa_defconfig replace corenet32_defconfig. Perhaps
e500v2_dpaa_defconfig would be a better name. It would effectively be a
standalone p1023 defconfig, but with a name that reflects the reason for
it, and which would accommodate future e500v2 dpaa chips in the unlikely
case that such things are made.
Do you know how large the current SDK datapath code is? Though perhaps
the eventual upstream version will be smaller.
-Scott
^ permalink raw reply
* RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Roy Zang @ 2013-11-12 23:05 UTC (permalink / raw)
To: Scott Wood; +Cc: Lijun Pan, linuxppc-dev@ozlabs.org
In-Reply-To: <1384296734.1403.72.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgNDo1MiBQTQ0KPiBUbzogWmFu
ZyBSb3ktUjYxOTExDQo+IENjOiBQYW4gTGlqdW4tQjQ0MzA2OyBsaW51eHBwYy1kZXZAb3psYWJz
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFYyXSBwb3dlcnBjLzg1eHg6IE1lcmdlIDg1eHgv
cDEwMjNfZGVmY29uZmlnIGludG8NCj4gbXBjODV4eF9zbXBfZGVmY29uZmlnIGFuZCBtcGM4NXh4
X2RlZmNvbmZpZw0KPiANCj4gT24gVHVlLCAyMDEzLTExLTEyIGF0IDE2OjQ5IC0wNjAwLCBaYW5n
IFJveS1SNjE5MTEgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4gPiBGcm9tOiBMaW51eHBwYy1kZXYgW21haWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcyt0
aWUtDQo+ID4gPiBmZWkuemFuZz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFicy5vcmddIE9uIEJl
aGFsZiBPZiBTY290dCBXb29kDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAx
MyA0OjA1IFBNDQo+ID4gPiBUbzogUGFuIExpanVuLUI0NDMwNg0KPiA+ID4gQ2M6IGxpbnV4cHBj
LWRldkBvemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIFYyXSBwb3dlcnBjLzg1
eHg6IE1lcmdlIDg1eHgvcDEwMjNfZGVmY29uZmlnDQo+ID4gPiBpbnRvIG1wYzg1eHhfc21wX2Rl
ZmNvbmZpZyBhbmQgbXBjODV4eF9kZWZjb25maWcNCj4gPiA+DQo+ID4gPiBPbiBNb24sIDIwMTMt
MTEtMTEgYXQgMTM6MjUgLTA2MDAsIExpanVuIFBhbiB3cm90ZToNCj4gPiA+ID4gbXBjODV4eF9z
bXBfZGVmY29uZmlnIGFuZCBtcGM4NXh4X2RlZmNvbmZpZyBhbHJlYWR5IGhhdmUNCj4gPiA+IENP
TkZJR19QMTAyM1JEUz15Lg0KPiA+ID4gPiBNZXJnZSBDT05GSUdfUDEwMjNSREI9eSBhbmQgb3Ro
ZXIgcmVsZXZhbnQgY29uZmlndXJhdGlvbnMgaW50bw0KPiA+ID4gbXBjODV4eF9zbXBfZGVmY29u
ZmlnIGFuZCBtcGM4NV9kZWZjb25maWcuDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6
IExpanVuIFBhbiA8TGlqdW4uUGFuQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+IC0tLQ0KPiA+ID4g
PiAgYXJjaC9wb3dlcnBjL2NvbmZpZ3MvODV4eC9wMTAyM19kZWZjb25maWcgIHwgIDE4OA0KPiA+
ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0tLS0tLS0NCj4gPiA+ID4gIGFyY2gv
cG93ZXJwYy9jb25maWdzL21wYzg1eHhfZGVmY29uZmlnICAgICB8ICAgMTggKysrDQo+ID4gPiA+
ICBhcmNoL3Bvd2VycGMvY29uZmlncy9tcGM4NXh4X3NtcF9kZWZjb25maWcgfCAgIDE3ICsrKw0K
PiA+ID4gPiAgMyBmaWxlcyBjaGFuZ2VkLCAzNSBpbnNlcnRpb25zKCspLCAxODggZGVsZXRpb25z
KC0pICBkZWxldGUgbW9kZQ0KPiA+ID4gPiAxMDA2NDQgYXJjaC9wb3dlcnBjL2NvbmZpZ3MvODV4
eC9wMTAyM19kZWZjb25maWcNCj4gPiA+DQo+ID4gPiBBcmUgd2Ugc3RpbGwgZ29pbmcgdG8gd2Fu
dCB0byBoYXZlIG9uZSBkZWZjb25maWcgaWYgYW5kIHdoZW4gd2UNCj4gPiA+IGZpbmFsbHkgZ2V0
IGRhdGFwYXRoIHN1cHBvcnQgdXBzdHJlYW0/ICBUaGF0J3MgYSBsb3Qgb2YgY29kZSB0byBhZGQN
Cj4gPiA+IHRvIHRoZSA4NXh4IGNvbmZpZyBqdXN0IGZvciB0aGlzIG9uZSBjaGlwLg0KPiA+IFAx
MDIzIGhhcyBkcGFhLg0KPiA+IFdpbGwgbXBjODV4eF9kZWZjb25maWcgb3IgbXBjODV4eF9zbXBf
ZGVmY29uZmlnIHN1cHBvcnQgZHBhYT8NCj4gDQo+IFRoYXQncyB0aGUgcXVlc3Rpb24gSSdtIGFz
a2luZy4gIFRob3VnaCBJIHN1cHBvc2Ugd2UgY291bGQgdGFrZSBhIHBhdGNoDQo+IGxpa2UgdGhp
cyBvbmUgZm9yIG5vdywgYW5kIHRoZW4gaW50cm9kdWNlIG1wYzg1eHhfZHBhYV9kZWZjb25maWcg
d2hlbiBpdA0KPiBiZWNvbWVzIHJlbGV2YW50ICh3aGljaCB3b3VsZCBtYWtlIGNsZWFyIHdoeSB0
aGUgZGVmY29uZmlnIGlzIHNlcGFyYXRlKS4NCj4gcDEwMjMgd291bGQgc3RpbGwgd29yayB3aXRo
IHRoZSBub24tZHBhYSBkZWZjb25maWdzLCBidXQgd2l0aG91dCBkcGFhDQo+IHN1cHBvcnQuDQoN
Ckl0IHdpbGwgYmUgaGFyZCB0byBmaW5kIGEgc2VhdCBmb3IgUDEwMjMgaW4gbXBjODV4eF9kcGFh
X2RlZmNvbmZpZy4NClAxMDIzIGRvZXMgbm90IGhhdmUgY29yZW5ldC4gIEl0IGhhcyBlNTAwdjIg
Y29yZS4gQWxsIHRoZSAgb3RoZXIgRFBBQSBTT0NzIGhhdmUgY29yZW5ldC4NCkkgc3VnZ2VzdCAg
bGVhdmluZyBwMTAyMyBkZWZjb25maWcgc3RhbmRhbG9uZS4NClJveQ0K
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-12 22:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384293891.1403.70.camel__45039.5534084693$1384293935$gmane$org@snotra.buserror.net>
Hello Scott,
On 11/12/2013 04:04 PM, Scott Wood wrote:
> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>
>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>> ---
>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>> 3 files changed, 35 insertions(+), 188 deletions(-)
>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>
> Are we still going to want to have one defconfig if and when we finally
> get datapath support upstream? That's a lot of code to add to the 85xx
> config just for this one chip.
Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
enabled by default given that just one SoC in that family has the
datapath (and we don't plan to put it in another e500v2 based SoC). For
regression/automation purposes config fragments should be used
Cheers,
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 22:52 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Pan Lijun-B44306, linuxppc-dev@ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B37812C@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> > fei.zang=freescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> > Sent: Tuesday, November 12, 2013 4:05 PM
> > To: Pan Lijun-B44306
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> > mpc85xx_smp_defconfig and mpc85xx_defconfig
> >
> > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> > CONFIG_P1023RDS=y.
> > > Merge CONFIG_P1023RDB=y and other relevant configurations into
> > mpc85xx_smp_defconfig and mpc85_defconfig.
> > >
> > > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > > ---
> > > arch/powerpc/configs/85xx/p1023_defconfig | 188 --------------------
> > --------
> > > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > > 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >
> > Are we still going to want to have one defconfig if and when we finally
> > get datapath support upstream? That's a lot of code to add to the 85xx
> > config just for this one chip.
> P1023 has dpaa.
> Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
That's the question I'm asking. Though I suppose we could take a patch
like this one for now, and then introduce mpc85xx_dpaa_defconfig when it
becomes relevant (which would make clear why the defconfig is separate).
p1023 would still work with the non-dpaa defconfigs, but without dpaa
support.
-Scott
^ permalink raw reply
* RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Roy Zang @ 2013-11-12 22:49 UTC (permalink / raw)
To: Scott Wood, Lijun Pan; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1384293891.1403.70.camel@snotra.buserror.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> Sent: Tuesday, November 12, 2013 4:05 PM
> To: Pan Lijun-B44306
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> mpc85xx_smp_defconfig and mpc85xx_defconfig
>=20
> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> CONFIG_P1023RDS=3Dy.
> > Merge CONFIG_P1023RDB=3Dy and other relevant configurations into
> mpc85xx_smp_defconfig and mpc85_defconfig.
> >
> > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > ---
> > arch/powerpc/configs/85xx/p1023_defconfig | 188 --------------------
> --------
> > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > 100644 arch/powerpc/configs/85xx/p1023_defconfig
>=20
> Are we still going to want to have one defconfig if and when we finally
> get datapath support upstream? That's a lot of code to add to the 85xx
> config just for this one chip.
P1023 has dpaa.
Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 22:04 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> 3 files changed, 35 insertions(+), 188 deletions(-)
> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
Are we still going to want to have one defconfig if and when we finally
get datapath support upstream? That's a lot of code to add to the 85xx
config just for this one chip.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Scott Wood @ 2013-11-12 21:58 UTC (permalink / raw)
To: shh.xie; +Cc: Shruti, madalin.bucur, linuxppc-dev, linux-kernel, Shaohui Xie
In-Reply-To: <1384167864-2457-1-git-send-email-shh.xie@gmail.com>
On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
> From: Andy Fleming
>
> You need an extra parameter to read or write Clause 45 PHYs, so
> we need a different API with the extra parameter.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Why did you remove Andy's e-mail address? Even though it's no longer
valid, it helps identify which specific person you're talking about.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
From: Paul Mackerras @ 2013-11-12 21:03 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Aneesh Kumar K.V, kvm@vger.kernel.org
In-Reply-To: <059527B7-DB8B-4A91-AE3B-3ACA834EEFA4@suse.de>
On Tue, Nov 12, 2013 at 07:37:24AM -0500, Alexander Graf wrote:
>
>
> Am 11.11.2013 um 09:08 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>:
>
> > From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> >
> > This patch make sure we inherit the LE bit correctly in different case
> > so that we can run Little Endian distro in PR mode
> >
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> This is not how real hardware works, is it? Could you please point me to the bits in the ISA that indicate that we should preserve the LE bit anywhere? :)
No, it isn't. What we should really be doing depends a bit on what
CPU we're emulating. Older CPUs had an ILE bit in the MSR that got
copied to LE on interrupt. Recent POWER CPUs moved the ILE bit to the
LPCR, so for them we should have an emulated LPCR (and implement
H_SET_MODE for pseries guests so they can control LPCR[ILE]).
Embedded CPUs of course don't have an LE bit, or an ILE bit, since
they control endianness on a per-page basis.
Paul.
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Timur Tabi @ 2013-11-12 20:13 UTC (permalink / raw)
To: Lijun Pan; +Cc: Linuxppc-dev Development
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Mon, Nov 11, 2013 at 1:25 PM, Lijun Pan <Lijun.Pan@freescale.com> wrote:
> +CONFIG_P1023_RDB=y
I think this is the only line you should be adding to the defconfigs.
None of the others should be necessary.
^ permalink raw reply
* [PATCH 01/12] powerpc/windfarm: Remove superfluous name casts
From: Geert Uytterhoeven @ 2013-11-12 19:07 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <1384283245-9419-1-git-send-email-geert@linux-m68k.org>
wf_sensor.name is "const char *"
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/macintosh/windfarm_lm75_sensor.c | 2 +-
drivers/macintosh/windfarm_max6690_sensor.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index 9ef32b3df91f..590214ba736c 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -133,7 +133,7 @@ static int wf_lm75_probe(struct i2c_client *client,
lm->inited = 0;
lm->ds1775 = ds1775;
lm->i2c = client;
- lm->sens.name = (char *)name; /* XXX fix constness in structure */
+ lm->sens.name = name;
lm->sens.ops = &wf_lm75_ops;
i2c_set_clientdata(client, lm);
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 945a25b2f31e..87e439b10318 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -95,7 +95,7 @@ static int wf_max6690_probe(struct i2c_client *client,
}
max->i2c = client;
- max->sens.name = (char *)name; /* XXX fix constness in structure */
+ max->sens.name = name;
max->sens.ops = &wf_max6690_ops;
i2c_set_clientdata(client, max);
--
1.7.9.5
^ permalink raw reply related
* Problem reading and programming memory location...
From: neorf3k @ 2013-11-12 19:23 UTC (permalink / raw)
To: Linux Ppc Dev List Dev List
we have tried to read and program an 8bit register with 32bit address. =
we have mapped it with: ioremap, kmalloc etc=85 and then using: outb, =
iowrite8 etc.. but when we write to it, the value doesn=92t change=85 =
with other memory location is ok.
That is an 8 bit register, located at 0x10020000 in a mpc5200b =
architecture. we are using kernel 2.6.33.=20
what could be?
Thank you
Lorenzo=
^ permalink raw reply
* Re: [PATCH 2/4] phylib: Add generic 10G driver
From: Florian Fainelli @ 2013-11-12 17:53 UTC (permalink / raw)
To: shh.xie
Cc: Shaohui Xie, Shruti, linuxppc-dev, linux-kernel@vger.kernel.org,
madalin.bucur
In-Reply-To: <1384168049-2899-1-git-send-email-shh.xie@gmail.com>
Hello Shaohui,
2013/11/11 <shh.xie@gmail.com>:
> From: Andy Fleming
>
> Very incomplete, but will allow for binding an ethernet controller
> to it.
>
> Also, Add XGMII interface type
So that should be two separate patches, and
drivers/of/of_net.c::of_get_phy_mode() must be updated to know about
XMGII.
>
> Signed-off-by: Andy Fleming
Missing Andy's Signed-off-by tag.
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/phy_device.c | 101 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/phy.h | 1 +
> 2 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 74630e9..30bf2d5 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -32,6 +32,7 @@
> #include <linux/module.h>
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> +#include <linux/mdio.h>
> #include <linux/phy.h>
>
> #include <asm/io.h>
> @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device *phydev)
> return changed;
> }
>
> +int gen10g_config_advert(struct phy_device *dev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_advert);
> +
> +
> /**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_restart_aneg);
>
> +int gen10g_restart_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_restart_aneg);
> +
>
> /**
> * genphy_config_aneg - restart auto-negotiation or write BMCR
> @@ -784,6 +798,13 @@ int genphy_config_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> +int gen10g_config_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_aneg);
> +
> +
> /**
> * genphy_update_link - update link status in @phydev
> * @phydev: target phy_device struct
> @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_read_status);
>
> +int gen10g_read_status(struct phy_device *phydev)
> +{
> + int devad, reg;
> + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> +
> + phydev->link = 1;
> +
> + /* For now just lie and say it's 10G all the time */
> + phydev->speed = 10000;
Can you at least make this a little more proof? Something along:
if (phydev->supported & (SUPPORTED_10000baseT_Full))
phydev->speed = SPEED_10000;
else if (phydev->supported & (SUPPORTED_1000baseT_Full)
phydev->speed = SPEED_1000;
Although ideally we should be reading the relevant registers to figure
out what to do.
> + phydev->duplex = DUPLEX_FULL;
> +
> + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> + if (!(mmd_mask & 1))
> + continue;
> +
> + /* Read twice because link state is latched and a
> + * read moves the current state into the register
> + */
> + phy_read_mmd(phydev, devad, MDIO_STAT1);
> + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> + phydev->link = 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_read_status);
> +
> +
> static int genphy_config_init(struct phy_device *phydev)
> {
> int val;
> @@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device *phydev)
>
> return 0;
> }
> +
> +static int gen10g_config_init(struct phy_device *phydev)
> +{
> + /* Temporarily just say we support everything */
> + phydev->supported = phydev->advertising = SUPPORTED_10000baseT_Full;
For consistency you should set SUPPORTED_TP, 1000baseT_Full does not
make sense for anything but twisted pairs AFAIR.
> +
> + return 0;
> +}
> +
> int genphy_suspend(struct phy_device *phydev)
> {
> int value;
> @@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_suspend);
>
> +int gen10g_suspend(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_suspend);
> +
> +
> int genphy_resume(struct phy_device *phydev)
> {
> int value;
> @@ -989,6 +1055,13 @@ int genphy_resume(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_resume);
>
> +int gen10g_resume(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_resume);
> +
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1129,6 +1202,20 @@ static struct phy_driver genphy_driver = {
> .driver = {.owner= THIS_MODULE, },
> };
>
> +static struct phy_driver gen10g_driver = {
> + .phy_id = 0xffffffff,
> + .phy_id_mask = 0xffffffff,
> + .name = "Generic 10G PHY",
> + .config_init = gen10g_config_init,
> + .features = 0,
This should be updated to be PHY_10GBIT_FEATURES where
PHY_10GBIT_FEATURES is defined to contain at least PHY_GBIT_FEATURES.
> + .config_aneg = gen10g_config_aneg,
> + .read_status = gen10g_read_status,
> + .suspend = gen10g_suspend,
> + .resume = gen10g_resume,
> + .driver = {.owner = THIS_MODULE, },
> +};
> +
> +
> static int __init phy_init(void)
> {
> int rc;
> @@ -1139,13 +1226,25 @@ static int __init phy_init(void)
>
> rc = phy_driver_register(&genphy_driver);
> if (rc)
> - mdio_bus_exit();
> + goto genphy_register_failed;
> +
> + rc = phy_driver_register(&gen10g_driver);
> + if (rc)
> + goto gen10g_register_failed;
> +
> + return rc;
> +
> +gen10g_register_failed:
> + phy_driver_unregister(&genphy_driver);
> +genphy_register_failed:
> + mdio_bus_exit();
As a subsequent patch you could use phy_drivers_register()
>
> return rc;
> }
>
> static void __exit phy_exit(void)
> {
> + phy_driver_unregister(&gen10g_driver);
> phy_driver_unregister(&genphy_driver);
And phy_drivers_unregister() here.
> mdio_bus_exit();
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 684925a..f864004 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -66,6 +66,7 @@ typedef enum {
> PHY_INTERFACE_MODE_RGMII_TXID,
> PHY_INTERFACE_MODE_RTBI,
> PHY_INTERFACE_MODE_SMII,
> + PHY_INTERFACE_MODE_XGMII,
> } phy_interface_t;
>
>
> --
> 1.8.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Florian
^ permalink raw reply
* [PATCH] powerpc/85xx: typo in dts: "interupt" (four devices)
From: Adam Borowski @ 2013-11-12 16:56 UTC (permalink / raw)
To: Mark Rutland, rob.herring, Pawel Moll, Stephen Warren,
Ian Campbell, devicetree, linuxppc-dev
Cc: Adam Borowski
In-Reply-To: <20131112091128.GA2976@e106331-lin.cambridge.arm.com>
These lines were inoperative for four years, which puts some doubt into
their importance, and it's possible the fixed version will regress, but
at the very least they should be removed instead.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
index cc00f4d..c409cba 100644
--- a/arch/powerpc/boot/dts/xcalibur1501.dts
+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
@@ -637,14 +637,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5301.dts b/arch/powerpc/boot/dts/xpedite5301.dts
index 53c1c6a..04cb410 100644
--- a/arch/powerpc/boot/dts/xpedite5301.dts
+++ b/arch/powerpc/boot/dts/xpedite5301.dts
@@ -547,14 +547,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5330.dts b/arch/powerpc/boot/dts/xpedite5330.dts
index 2152259..73f8620 100644
--- a/arch/powerpc/boot/dts/xpedite5330.dts
+++ b/arch/powerpc/boot/dts/xpedite5330.dts
@@ -583,14 +583,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5370.dts b/arch/powerpc/boot/dts/xpedite5370.dts
index 11dbda1..cd0ea2b 100644
--- a/arch/powerpc/boot/dts/xpedite5370.dts
+++ b/arch/powerpc/boot/dts/xpedite5370.dts
@@ -545,14 +545,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
--
1.8.5.rc0
^ permalink raw reply related
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Kumar Gala @ 2013-11-12 16:27 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Nov 11, 2013, at 1:25 PM, Lijun Pan <Lijun.Pan@freescale.com> wrote:
> mpc85xx_smp_defconfig and mpc85xx_defconfig already have =
CONFIG_P1023RDS=3Dy.
> Merge CONFIG_P1023RDB=3Dy and other relevant configurations into =
mpc85xx_smp_defconfig and mpc85_defconfig.
>=20
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023_defconfig | 188 =
----------------------------
> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> 3 files changed, 35 insertions(+), 188 deletions(-)
> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
How much of the changes to mpc85xx_defconfig & mpc85xx_smp_defconfig are =
based on just updating them vs changes for p1023?
Can we do this as two patches. One that updates mpc85xx_defconfig & =
mpc85xx_smp_defconfig and one that makes the p1023 changes. That is =
much easier to review as well.
- k=
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Mark Salter @ 2013-11-12 15:55 UTC (permalink / raw)
To: monstr
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <52824BBC.9020401@monstr.eu>
On Tue, 2013-11-12 at 16:39 +0100, Michal Simek wrote:
> On 11/12/2013 02:22 PM, Mark Salter wrote:
> >
> > arch/arm/include/asm/fixmap.h | 25 ++------
> > arch/hexagon/include/asm/fixmap.h | 40 +------------
> > arch/metag/include/asm/fixmap.h | 32 +----------
> > arch/microblaze/include/asm/fixmap.h | 44 +-------------
> > arch/mips/include/asm/fixmap.h | 33 +----------
> > arch/powerpc/include/asm/fixmap.h | 44 +-------------
> > arch/sh/include/asm/fixmap.h | 39 +------------
> > arch/tile/include/asm/fixmap.h | 33 +----------
> > arch/um/include/asm/fixmap.h | 40 +------------
> > arch/x86/include/asm/fixmap.h | 59 +------------------
> > include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
> > 11 files changed, 125 insertions(+), 371 deletions(-)
> > create mode 100644 include/asm-generic/fixmap.h
>
> Any repo/branch with all these patches will be helpful.
https://github.com/mosalter/linux (fixmap branch)
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Michal Simek @ 2013-11-12 15:39 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384262545-20875-1-git-send-email-msalter@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On 11/12/2013 02:22 PM, Mark Salter wrote:
> Many architectures provide an asm/fixmap.h which defines support for
> compile-time 'special' virtual mappings which need to be made before
> paging_init() has run. This suport is also used for early ioremap
> on x86. Much of this support is identical across the architectures.
> This patch consolidates all of the common bits into asm-generic/fixmap.h
> which is intended to be included from arch/*/include/asm/fixmap.h.
>
> This has been compiled on x86, arm, powerpc, and sh, but tested
> on x86 only.
>
> Mark Salter (11):
> Add generic fixmap.h
> x86: use generic fixmap.h
> arm: use generic fixmap.h
> hexagon: use generic fixmap.h
> metag: use generic fixmap.h
> microblaze: use generic fixmap.h
> mips: use generic fixmap.h
> powerpc: use generic fixmap.h
> sh: use generic fixmap.h
> tile: use generic fixmap.h
> um: use generic fixmap.h
>
> arch/arm/include/asm/fixmap.h | 25 ++------
> arch/hexagon/include/asm/fixmap.h | 40 +------------
> arch/metag/include/asm/fixmap.h | 32 +----------
> arch/microblaze/include/asm/fixmap.h | 44 +-------------
> arch/mips/include/asm/fixmap.h | 33 +----------
> arch/powerpc/include/asm/fixmap.h | 44 +-------------
> arch/sh/include/asm/fixmap.h | 39 +------------
> arch/tile/include/asm/fixmap.h | 33 +----------
> arch/um/include/asm/fixmap.h | 40 +------------
> arch/x86/include/asm/fixmap.h | 59 +------------------
> include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
> 11 files changed, 125 insertions(+), 371 deletions(-)
> create mode 100644 include/asm-generic/fixmap.h
Any repo/branch with all these patches will be helpful.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] Add generic fixmap.h
From: Arnd Bergmann @ 2013-11-12 13:46 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384262545-20875-2-git-send-email-msalter@redhat.com>
On Tuesday 12 November 2013, Mark Salter wrote:
> Many architectures provide an asm/fixmap.h which defines support for
> compile-time 'special' virtual mappings which need to be made before
> paging_init() has run. This suport is also used for early ioremap
> on x86. Much of this support is identical across the architectures.
> This patch consolidates all of the common bits into asm-generic/fixmap.h
> which is intended to be included from arch/*/include/asm/fixmap.h.
Good idea,
Acked-by: Arnd Bergmann <arnd@arndb.de>
On Tuesday 12 November 2013, Mark Salter wrote:
> +static __always_inline unsigned long fix_to_virt(const unsigned int idx)
> +{
> + /*
> + * this branch gets completely eliminated after inlining,
> + * except when someone tries to use fixaddr indices in an
> + * illegal way. (such as mixing up address types or using
> + * out-of-range indices).
> + *
> + * If it doesn't get removed, the linker will complain
> + * loudly with a reasonably clear error message..
> + */
> + if (idx >= __end_of_fixed_addresses)
> + __this_fixmap_does_not_exist();
> +
You might be able to turn this into the more readable BUILD_BUG_ON().
Arnd
^ 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