* RE: IRQ2 and IRQ 3
From: Bhushan Bharat-R65777 @ 2011-10-18 15:03 UTC (permalink / raw)
To: smitha.vanga@wipro.com, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE016391@HYD-MKD-MBX4.wipro.com>
Hi,=20
For detail please look at ePAPR specification.
Say i2c interrupt number is 21 then you can try
"interrupts =3D <21 8>;" in device tree.
Thanks
-Bharat
> -----Original Message-----
> From: smitha.vanga@wipro.com [mailto:smitha.vanga@wipro.com]
> Sent: Tuesday, October 18, 2011 2:35 PM
> To: Bhushan Bharat-R65777; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: IRQ2 and IRQ 3
>=20
> Yes , there is a vector numbe defined in the specifications .
>=20
> IRQ2 - 20
> IRQ3 - 21
>=20
> But I don't know how to specify them in the .dts file .
>=20
> Regards,
> Smitha
> Please do not print this email unless it is absolutely necessary.
>=20
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s)
> and may contain proprietary, confidential or privileged information. If
> you are not the intended recipient, you should not disseminate,
> distribute or copy this e-mail. Please notify the sender immediately and
> destroy all copies of this message and any attachments.
>=20
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>=20
> www.wipro.com
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-10-18 12:30 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list,
David S. Miller
In-Reply-To: <D79CB818-C14E-4C8D-9A8D-42B39ADE20B2@kernel.crashing.org>
On Tue, Oct 18, 2011 at 06:43:13AM -0500, Kumar Gala wrote:
>
> >> Robin,
> >>
> >> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
> >
> > The decision was due to the fact there is no true "generic" fsl.flexcan
> > chip free of any SOC implementation and therefore not something which
> > could be separately defined. That decision was made by Grant Likely.
> > I will inline that email below.
> >
> > Robin
>
>
> Thanks, I'll look into this internally at FSL. I think its confusing as hell to have "fsl,p1010-flexcan" in an ARM .dts and don't think any reasonable ARM customer of FSL would know to put a PPC SOC name in their .dts. I'll ask the HW guys what's going on so we can come up with a bit more generic name so we don't have to constantly change this. Even if its just:
Grants argument was that there should then be a fsl,zeba-flexcan which
would define each arm based soc. The match string could be there and
the devicetree binding would match on each equivalent.
Robin
>
> fsl,ppc-flexcan & fsl,arm-flexcan.
>
> > On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
> >> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt@sgi.com> wrote:
> >>> Grant,
> >>>
> >>> Earlier, you had asked for a more specific name for the compatible
> >>> property of the Freescale flexcan device. I still have not gotten a
> >>> more specific answer. Hopefully Marc can give you more details about
> >>> the flexcan implementations.
> >>
> >> If there is no ip core version, then just stick with the
> >> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
> >> flexcan is flexcan, but hardware engineers like to change things.
> >> Trying to be too generic in compatible values will just lead to
> >> problems in the future.
> >
> > Thanks,
> > Robin
>
> - k
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-10-18 11:48 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, linux-can, socketcan-core, Robin Holt,
PPC list, David S. Miller
In-Reply-To: <D79CB818-C14E-4C8D-9A8D-42B39ADE20B2@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On 10/18/2011 01:43 PM, Kumar Gala wrote:
> Thanks, I'll look into this internally at FSL. I think its confusing
> as hell to have "fsl,p1010-flexcan" in an ARM .dts and don't think
> any reasonable ARM customer of FSL would know to put a PPC SOC name
> in their .dts. I'll ask the HW guys what's going on so we can come
> up with a bit more generic name so we don't have to constantly change
> this. Even if its just:
>
> fsl,ppc-flexcan & fsl,arm-flexcan.
If you talk the HW guys ask them for a name for the coldfire flexcan
core, too please ;)
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Kumar Gala @ 2011-10-18 11:43 UTC (permalink / raw)
To: Robin Holt
Cc: netdev, U Bhaskar-B22300, socketcan-core, PPC list,
David S. Miller
In-Reply-To: <20111018094328.GC22814@sgi.com>
>> Robin,
>>=20
>> Do you remember why we went with just 'fsl,p1010-flexcan' as the =
device tree compatible? Do we feel the flex can on P1010 isn't the same =
as on MPC5xxx? or the ARM SoCs?
>=20
> The decision was due to the fact there is no true "generic" =
fsl.flexcan
> chip free of any SOC implementation and therefore not something which
> could be separately defined. That decision was made by Grant Likely.
> I will inline that email below.
>=20
> Robin
Thanks, I'll look into this internally at FSL. I think its confusing as =
hell to have "fsl,p1010-flexcan" in an ARM .dts and don't think any =
reasonable ARM customer of FSL would know to put a PPC SOC name in their =
.dts. I'll ask the HW guys what's going on so we can come up with a bit =
more generic name so we don't have to constantly change this. Even if =
its just:
fsl,ppc-flexcan & fsl,arm-flexcan.
> On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
>> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt@sgi.com> wrote:
>>> Grant,
>>>=20
>>> Earlier, you had asked for a more specific name for the compatible
>>> property of the Freescale flexcan device. I still have not gotten a
>>> more specific answer. Hopefully Marc can give you more details =
about
>>> the flexcan implementations.
>>=20
>> If there is no ip core version, then just stick with the
>> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
>> flexcan is flexcan, but hardware engineers like to change things.
>> Trying to be too generic in compatible values will just lead to
>> problems in the future.
>=20
> Thanks,
> Robin
- k=
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-10-18 9:43 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list,
David S. Miller
In-Reply-To: <16FBAA47-5133-43A1-80CE-C6D63B79FB5D@kernel.crashing.org>
On Tue, Oct 18, 2011 at 12:44:07AM -0500, Kumar Gala wrote:
>
> On Aug 16, 2011, at 10:32 PM, Robin Holt wrote:
>
> > David,
> >
> > The following set of patches have been reviewed by the above parties and
> > all comments have been integrated. Although the patches stray from the
> > drivers/net/can directory, the diversions are related to changes for
> > the flexcan driver.
> >
> > The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
> >
> > Could you please queue these up for the next appropriate push to Linus'
> > tree?
> >
> > Thanks,
> > Robin Holt
>
> Robin,
>
> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
The decision was due to the fact there is no true "generic" fsl.flexcan
chip free of any SOC implementation and therefore not something which
could be separately defined. That decision was made by Grant Likely.
I will inline that email below.
Robin
On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt@sgi.com> wrote:
> > Grant,
> >
> > Earlier, you had asked for a more specific name for the compatible
> > property of the Freescale flexcan device. I still have not gotten a
> > more specific answer. Hopefully Marc can give you more details about
> > the flexcan implementations.
>
> If there is no ip core version, then just stick with the
> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
> flexcan is flexcan, but hardware engineers like to change things.
> Trying to be too generic in compatible values will just lead to
> problems in the future.
Thanks,
Robin
^ permalink raw reply
* Re: IRQ2 and IRQ 3
From: Vineeth @ 2011-10-18 9:10 UTC (permalink / raw)
To: smitha.vanga, linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE016391@HYD-MKD-MBX4.wipro.com>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
interrupts <IRQ_NO,POLARITY>
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
On Tue, Oct 18, 2011 at 2:35 PM, <smitha.vanga@wipro.com> wrote:
> Yes , there is a vector numbe defined in the specifications .
>
> IRQ2 - 20
> IRQ3 - 21
>
> But I don't know how to specify them in the .dts file .
>
> Regards,
> Smitha
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 2054 bytes --]
^ permalink raw reply
* RE: IRQ2 and IRQ 3
From: smitha.vanga @ 2011-10-18 9:05 UTC (permalink / raw)
To: R65777, B07421; +Cc: linuxppc-dev
In-Reply-To: <B8D6CA50DACE9E4AAADE9A4D56FBAAE623BEB3@039-SN1MPN1-005.039d.mgd.msft.net>
Yes , there is a vector numbe defined in the specifications .
IRQ2 - 20
IRQ3 - 21
But I don't know how to specify them in the .dts file .
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email.
www.wipro.com
^ permalink raw reply
* RE: IRQ2 and IRQ 3
From: Bhushan Bharat-R65777 @ 2011-10-18 8:58 UTC (permalink / raw)
To: smitha.vanga@wipro.com, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE01637C@HYD-MKD-MBX4.wipro.com>
Hi,
Is not some interrupt vector number defined for i2c in your soc specificati=
on(IIRC mpc9247 and I do not have this).
Thanks
-Bharat
> -----Original Message-----
> From: smitha.vanga@wipro.com [mailto:smitha.vanga@wipro.com]
> Sent: Tuesday, October 18, 2011 1:36 PM
> To: Wood Scott-B07421; Bhushan Bharat-R65777
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: IRQ2 and IRQ 3
>=20
>=20
>=20
> Hi ,
>=20
> I want to use IRQ2 and IRQ3 in my driver. How do I add them in the device
> tree file.
>=20
> Regard,
> Smitha
>=20
> Please do not print this email unless it is absolutely necessary.
>=20
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s)
> and may contain proprietary, confidential or privileged information. If
> you are not the intended recipient, you should not disseminate,
> distribute or copy this e-mail. Please notify the sender immediately and
> destroy all copies of this message and any attachments.
>=20
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>=20
> www.wipro.com
^ permalink raw reply
* RE: IRQ2 and IRQ 3
From: smitha.vanga @ 2011-10-18 8:06 UTC (permalink / raw)
To: B07421, R65777; +Cc: linuxppc-dev
Hi ,
I want to use IRQ2 and IRQ3 in my driver. How do I add them in the device tr=
ee file.
Regard,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email.
www.wipro.com
^ permalink raw reply
* IRQ2 and IRQ 3
From: smitha.vanga @ 2011-10-18 8:05 UTC (permalink / raw)
To: B07421; +Cc: linuxppc-dev
In-Reply-To: <B8D6CA50DACE9E4AAADE9A4D56FBAAE623B55D@039-SN1MPN1-005.039d.mgd.msft.net>
Hi ,
I want to use IRQ2 and IRQ3 in my driver. How do I add them in the device tr=
ee file.
Regard,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email.
www.wipro.com
^ permalink raw reply
* Re: FW: P4080 device tree problems with fsl dpaa ...
From: Thomas De Schampheleire @ 2011-10-18 7:57 UTC (permalink / raw)
To: Robert Sciuk; +Cc: linuxppc-dev
In-Reply-To: <2DD52030B5146141BEB762A11AE97C4CF6E2E7@SPQCEXC05.exfo.com>
Hi Robert,
On Mon, Oct 17, 2011 at 8:34 PM, Robert Sciuk <robert.sciuk@exfo.com> wrote=
:
>
>
>> -----Original Message-----
>> From: patrickdepinguin@gmail.com [mailto:patrickdepinguin@gmail.com] On
>> Behalf Of Thomas De Schampheleire
>> Sent: Monday, October 17, 2011 5:01 AM
>> To: Robert Sciuk
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Subject: Re: FW: P4080 device tree problems with fsl dpaa ...
>>
>> Hi Robert,
>
> [my stuff snipped]
>>
>> > I have no idea what an OH binding is, what it might look like, and
>> what it entails, but I think that it might be a significant factor in
>> our not seeing a working interface. =A0Has anyone any experience with
>> dpaa device trees, and configuration? =A0Any pointers? =A0Any docs? Shot=
s
>> in the dark?
>>
>> We are using a device tree on p4080 with a dpaa configuration, yes.
>> I also don't know about the OH bindings, but I have a vague memory of
>> us having that message too, and it not being a real problem.
>>
>
> Other indicators concur with your assessment, and suggest that I back tho=
se nodes out as well.
>
>
>> What I do know is that the device tree is very easy to get wrong, and
>> that it should match your hardware precisely. I'm not using the same
>> configuration as you are (there are no MDIO devices between our phy
>> and dTSEC) so the device tree looks a little different.
>
> Would it be possible to have a look at the relevant portions of your dev =
tree?
>
>
Sure.
The following snippets are for two SGMII devices on the second FMAN:
First the ports:
// RX
fman1_rx2: port@8a000 {
compatible =3D
"fsl,p4080-fman-port-1g-rx", "fsl,fman-port-1g-rx";
reg =3D <0x8a000 0x1000>;
fsl,liodn =3D <0x2d>;
// Logical Input/Output Device Number used by PAMU
cell-index =3D <2>;
// 1G index
};
fman1_rx3: port@8b000 {
compatible =3D
"fsl,p4080-fman-port-1g-rx", "fsl,fman-port-1g-rx";
reg =3D <0x8b000 0x1000>;
fsl,liodn =3D <0x2e>;
// Logical Input/Output Device Number used by PAMU
cell-index =3D <3>;
// 1G index
};
// TX
fman1_tx2: port@aa000 {
compatible =3D
"fsl,p4080-fman-port-1g-tx", "fsl,fman-port-1g-tx";
reg =3D <0xaa000 0x1000>;
fsl,qman-channel-id =3D <0x63>;
// Direct-HW-Portal 1: SP3
cell-index =3D <2>;
// 1G index
};
fman1_tx3: port@ab000 {
compatible =3D
"fsl,p4080-fman-port-1g-tx", "fsl,fman-port-1g-tx";
reg =3D <0xab000 0x1000>;
fsl,qman-channel-id =3D <0x64>;
// Direct-HW-Portal 1: SP4
cell-index =3D <3>;
// 1G index
};
Then the TSECs:
enet7: ethernet@e4000 { // dTSEC3
compatible =3D "fsl,p4080-fman-1g-mac",
"fsl,fman-1g-mac";
reg =3D <0xe4000 0x1000>;
fixed-link =3D <7 1 1000 0 0>;
// Use fixed settings because there is no MDIO bus between
SOC and PHY
local-mac-address =3D [00 BA 0B AB 00 0A];
fsl,port-handles =3D <&fman1_rx2
&fman1_tx2>; // RX + TX port
phy-connection-type =3D "sgmii";
// 1Gb
cell-index =3D <2>;
};
enet8: ethernet@e6000 { // dTSEC4
compatible =3D "fsl,p4080-fman-1g-mac",
"fsl,fman-1g-mac";
reg =3D <0xe6000 0x1000>;
fixed-link =3D <8 1 1000 0 0>;
// Use fixed settings because there is no MDIO bus between
SOC and PHY
local-mac-address =3D [00 BA 0B AB 00 0B];
fsl,port-handles =3D <&fman1_rx3
&fman1_tx3>; // RX + TX port
phy-connection-type =3D "sgmii";
// 1Gb
cell-index =3D <3>;
};
The ethernet devices in the fsl,dpaa node:
ethernet@7 {
compatible =3D "fsl,p4080-dpa-ethernet",
"fsl,dpa-ethernet";
fsl,qman-channel =3D <&qportal0>;
fsl,fman-mac =3D <&enet7>;
};
ethernet@8 {
compatible =3D "fsl,p4080-dpa-ethernet",
"fsl,dpa-ethernet";
fsl,qman-channel =3D <&qportal0>;
fsl,fman-mac =3D <&enet8>;
>
>>
>> Are you using the reference design or is this custom?
>
> This is a custom design, and is an ATCA blade.
>
>
>> Did you have a look at the device tree in the linux kernel sources?
>> (arch/powerpc/boot/dts/p4080.dts). Does this configuration match
>> yours? In that configuration, there are separate nodes of type
>> p4080ds-mdio, inside the main mdio node.
>
> We actually used the 36 bit tree (we plan to ship the boards with 16G ini=
tially, and up to 32G eventually). =A0I've also re-worked the tree from the=
LTIB (System Builder) in an attempt to get this to work. =A0Our design dif=
fers significantly from the P4080DS in that there exists no MUX between the=
bus and phy ... and there is no PIXIS FPGA to do all the clocking and star=
tup stuff.
I have to admit that I'm not an export at the DPAA part either. My
colleague who is is on holiday, unfortunately.
In our case, we needed the 'fixed-link' settings because of the
absence of an MDIO, and I also initially made the mistake of
registering the devices on the wrong FMAN.
For RX, I also had some problems receiving frames correctly. Setting
the source MAC address correctly fixed that problem.
But you seem to have problems with TX...
>
> I've modified u-boot to assign mac addresses based upon our OUI, and the =
MACs all seem to be configured properly coming out of firmware, the ifconfi=
g on the Linux side recognizes all of our 6 interfaces ...
>
>
>>
>> Is your phy configured correctly? Are there any boot messages about
>> this? Can you check its registers?
>> The same for the mdio.
>
> There is some question about the TBI initialization, and we are tracing t=
hat as we speak ...
>
>>
>> Some generic pointers:
>> * If you set CONFIG_PROC_DEVICETREE in the kernel config, you can read
>> out the device-tree at runtime in /proc/device-tree. This helps in
>> verifying whether the nodes you programmed actually appear in the
>> running system.
>
> Ack.
>
>>
>> * The /sys/devices directory can also be useful in identifying
>> potential problems for unfound devices (which does not appear to be
>> your case).
>>
>
> Ack. =A0Also using /proc/interrupts ...
>
>
>> * Can you step through the code, e.g. with a JTAG debugger? Try
>> following the transmit path in the dpaa_eth driver. Maybe something
>> errors out prematurely.
>>
>
> With some headaches ... using codewarrior, and getting assembly level tra=
cing ...
Also, did you check in the dTSEC/FMAN/BMAN for relevant counter
registers? Do you find proof that the packets make it as far as the
dTSEC? (then maybe there is a problem in the link between dTSEC and
PHY).
Are there counters in the PHY that can indicate that packets or no
packets are received?
Which version of the kernel and associated Freescale patches are you using?
How and what type of packets are you sending? Raw MAC frames, IP? Are
you using custom code, or can you try things like ping?
If you are using IP, I trust you checked the Linux configuration (like
assigning a valid IP address to the interface and making sure the
routing table is correct).
Best regards,
Thomas
^ permalink raw reply
* Re: linux-3.0.4, mv643xx_eth troubles on Pegasos2 G4
From: Gabriel Paubert @ 2011-10-18 7:19 UTC (permalink / raw)
To: nello martuscielli; +Cc: linuxppc-dev, acrux
In-Reply-To: <CABMX=WzPuhBywZTJShnM5W1Y2cqMOr=2BuJTKecsyfCp73Ko7g@mail.gmail.com>
On Mon, Oct 17, 2011 at 11:40:54PM +0200, nello martuscielli wrote:
> i'm trying to enable marvel gigabit ethernet support but it doesn't work.
> Here my dmesg instead my config is attached.
[snipped]
> via_rhine: v1.10-LK1.5.0 2010-10-09 Written by Donald Becker
> mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> uhci_hcd 0000:00:0c.2: irq 9, io base 0x00001040
> sysfs: cannot create duplicate filename '/class/mdio_bus/0'
I have 2 Pegasos running 3.0, but in my case mv643xx_eth is non-modular
and /sys/class/mdio_bus/0 exists and points to
../../devices/platform/mv643xx_eth.0/mdio_bus/0
which is correct as far as I can say.
Is it a regression from 3.0 or not? Try to make it non modular and see
what happens. If it is a regression, could you try to bisect it?
I won't be close enough to the machines to do a regression
hunt myself before a week or 3 (really, maybe next week,
I don't yet know, but for sure starting on Nov 8th).
>
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
> ------------[ cut here ]------------
> WARNING: at fs/sysfs/dir.c:455
> Modules linked in: snd_via82xx(+) snd_ac97_codec mv643xx_eth(+)
> via_rhine(+) i2c_viapro(+) ac97_bus ohci_hcd(+) snd_mpu401_uart
> uhci_hcd(+) snd_rawmidi
> NIP: c00fa718 LR: c00fa718 CTR: 00000000
> REGS: ef271c00 TRAP: 0700 Not tainted (3.0.4)
> MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22004428 XER: 00000000
> TASK = ef294c60[94] 'modprobe' THREAD: ef270000
> GPR00: c00fa718 ef271cb0 ef294c60 00000042 c0008904 00000001 00000000 00000000
> GPR08: c06b6bd8 00000000 22004482 ef271c70 22004422 10024440 1000ba68 00000000
> GPR16: 1000ba44 bf83e324 00000000 1000ba58 00000000 104410ec 00000a30 00000000
> GPR24: c0059210 00000124 00000000 00000001 ef271cd8 ef2ba480 ffffffef ef344000
> NIP [c00fa718] sysfs_add_one+0x88/0xa0
> LR [c00fa718] sysfs_add_one+0x88/0xa0
> Call Trace:
> [ef271cb0] [c00fa718] sysfs_add_one+0x88/0xa0 (unreliable)
> [ef271cd0] [c00faff4] sysfs_do_create_link+0x134/0x1e0
> [ef271d00] [c0392cf8] device_add+0x204/0x544
> [ef271d40] [c03d67e4] mdiobus_register+0xa4/0x198
> [ef271d60] [f26785a4] mv643xx_eth_shared_probe+0x144/0x428 [mv643xx_eth]
> [ef271d80] [c039685c] platform_drv_probe+0x20/0x30
> [ef271d90] [c0395578] driver_probe_device+0xe4/0x198
> [ef271db0] [c039569c] __driver_attach+0x70/0x98
> [ef271dd0] [c0394614] bus_for_each_dev+0x60/0x90
> [ef271e00] [c03951d0] driver_attach+0x24/0x34
> [ef271e10] [c0394d9c] bus_add_driver+0xbc/0x23c
> [ef271e30] [c0395ac8] driver_register+0xb8/0x144
> [ef271e50] [c0396bb4] platform_driver_register+0x68/0x78
> [ef271e60] [f2680024] mv643xx_eth_init_module+0x24/0x80 [mv643xx_eth]
> [ef271e80] [c000402c] do_one_initcall+0xe0/0x1c0
> [ef271eb0] [c005b438] sys_init_module+0x1600/0x17f4
> [ef271f40] [c0012df8] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff62ac0
> LR = 0x10003f2c
> Instruction dump:
> 807c0000 7fe4fb78 4bfff469 3c80c060 3884f131 4bf2051d 809d0010 4bf20515
> 7c641b78 3c60c060 3863f0fe 484650f9 <0fe00000> 7fe3fb78 4bfa8009 39610020
> ---[ end trace cebed1f190337b77 ]---
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: UHCI Host Controller
> usb usb2: Manufacturer: Linux 3.0.4 uhci_hcd
> usb usb2: SerialNumber: 0000:00:0c.2
> hub 2-0:1.0: USB hub found
> mii_bus 0 failed to register
> mv643xx_eth: probe of mv643xx_eth.0 failed with error -12
> hub 2-0:1.0: 2 ports detected
> ohci_hcd 0000:00:05.0: OHCI Host Controller
> ohci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 3
> Unable to handle kernel paging request for data at address 0x00000000
> ohci_hcd 0000:00:05.0: irq 9, io mem 0x80000000
> Faulting instruction address: 0xf267b3a8
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT CHRP
> Modules linked in: snd_via82xx(+) snd_ac97_codec mv643xx_eth(+)
> via_rhine(+) i2c_viapro(+) ac97_bus ohci_hcd(+) snd_mpu401_uart
> uhci_hcd(+) snd_rawmidi
> NIP: f267b3a8 LR: f267b3a0 CTR: c0394ff4
> REGS: ef271c90 TRAP: 0300 Tainted: G W (3.0.4)
> MSR: 00009032 <EE,ME,IR,DR> CR: 84004448 XER: 00000000
> DAR: 00000000, DSISR: 40000000
> TASK = ef294c60[94] 'modprobe' THREAD: ef270000
> GPR00: 00000000 ef271d40 ef294c60 00000000 eec003c0 eec00005 ef24bb3c 00000000
> GPR08: ef24bb28 ef8a7600 ffffffff 00000001 44004442 10024440 1000ba68 00000000
> GPR16: 1000ba44 bf83e324 00000000 1000ba58 00000000 104410ec 00000a30 00000000
> GPR24: c0059210 c06b68c0 00000020 c06b68b8 fffffff4 eec00000 c06b6740 eec003c0
> NIP [f267b3a8] mv643xx_eth_probe+0x98/0x604 [mv643xx_eth]
> LR [f267b3a0] mv643xx_eth_probe+0x90/0x604 [mv643xx_eth]
> Call Trace:
> [ef271d40] [f267b394] mv643xx_eth_probe+0x84/0x604 [mv643xx_eth] (unreliable)
> [ef271d80] [c039685c] platform_drv_probe+0x20/0x30
> [ef271d90] [c0395578] driver_probe_device+0xe4/0x198
> [ef271db0] [c039569c] __driver_attach+0x70/0x98
> [ef271dd0] [c0394614] bus_for_each_dev+0x60/0x90
> [ef271e00] [c03951d0] driver_attach+0x24/0x34
> [ef271e10] [c0394d9c] bus_add_driver+0xbc/0x23c
> [ef271e30] [c0395ac8] driver_register+0xb8/0x144
> [ef271e50] [c0396bb4] platform_driver_register+0x68/0x78
> [ef271e60] [f2680034] mv643xx_eth_init_module+0x34/0x80 [mv643xx_eth]
> [ef271e80] [c000402c] do_one_initcall+0xe0/0x1c0
> [ef271eb0] [c005b438] sys_init_module+0x1600/0x17f4
> [ef271f40] [c0012df8] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff62ac0
> LR = 0x10003f2c
> Instruction dump:
> 7c7d1b79 41820530 3bfd03c0 3b3b0008 7fe4fb78 7f23cb78 48001101 807e0000
> 38630008 48001505 907d03c0 817e0004
> 556b502a 396b0400 7d605a14
> usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
> usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb3: Product: OHCI Host Controller
> usb usb3: Manufacturer: Linux 3.0.4 ohci_hcd
> usb usb3: SerialNumber: 0000:00:05.0
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 3 ports detected
> vt596_smbus 0000:00:0c.4: SMBUS: Error: Host SMBus controller not
> enabled! - upgrade BIOS or use force=1
> VIA 82xx Audio 0000:00:0c.5: enabling device (0000 -> 0001)
> ---[ end trace cebed1f190337b78 ]---
> via-rhine 0000:00:0d.0: enabling device (0000 -> 0003)
> via-rhine 0000:00:0d.0: eth0: VIA Rhine II at 0x80001900,
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Wolfgang Grandegger @ 2011-10-18 7:13 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list,
David S. Miller
In-Reply-To: <16FBAA47-5133-43A1-80CE-C6D63B79FB5D@kernel.crashing.org>
Hi Kumar,
On 10/18/2011 07:44 AM, Kumar Gala wrote:
>
> On Aug 16, 2011, at 10:32 PM, Robin Holt wrote:
>
>> David,
>>
>> The following set of patches have been reviewed by the above parties and
>> all comments have been integrated. Although the patches stray from the
>> drivers/net/can directory, the diversions are related to changes for
>> the flexcan driver.
>>
>> The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
>>
>> Could you please queue these up for the next appropriate push to Linus'
>> tree?
>>
>> Thanks,
>> Robin Holt
>
> Robin,
>
> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
The MPC5xxx SOCs have a MSCAN controller, which is different to the
Flexcan and handled by another driver. But the Flexcan's on the
Freescale ARM SOCs are identical and supported by that driver as well
and "fsl,flexcan" would work *perfectly*. Actually Grant instructed use
to be more explicit and use "fsl,p1010-flexcan". Anyway,
"fsl,p1010-flexcan" should work on ARM SOCs if the source frequency is
provided via boot loader or the DTS file. Compatibility was one of our
main concerns.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Kumar Gala @ 2011-10-18 5:44 UTC (permalink / raw)
To: Robin Holt
Cc: netdev, U Bhaskar-B22300, socketcan-core, PPC list,
David S. Miller
In-Reply-To: <1313551944-28603-1-git-send-email-holt@sgi.com>
On Aug 16, 2011, at 10:32 PM, Robin Holt wrote:
> David,
>=20
> The following set of patches have been reviewed by the above parties =
and
> all comments have been integrated. Although the patches stray from =
the
> drivers/net/can directory, the diversions are related to changes for
> the flexcan driver.
>=20
> The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
>=20
> Could you please queue these up for the next appropriate push to =
Linus'
> tree?
>=20
> Thanks,
> Robin Holt
Robin,
Do you remember why we went with just 'fsl,p1010-flexcan' as the device =
tree compatible? Do we feel the flex can on P1010 isn't the same as on =
MPC5xxx? or the ARM SoCs?
- k=
^ permalink raw reply
* RE: I2c-cpm driver not working
From: Bhushan Bharat-R65777 @ 2011-10-18 4:05 UTC (permalink / raw)
To: smitha.vanga@wipro.com, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE015E0E@HYD-MKD-MBX4.wipro.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.or=
g
> [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> smitha.vanga@wipro.com
> Sent: Monday, October 17, 2011 1:48 PM
> To: Bhushan Bharat-R65777; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: I2c-cpm driver not working
>=20
>=20
> Hi Bhusan,
>=20
> Below is i2c node in the device tree.
>=20
> i2c@11860 {
> compatible =3D "fsl-i2c-cpm";
> device_type =3D "i2c";
> reg =3D <11860 20 8afc 2>;
> interrupts =3D <1 8>;
> interrupt-parent =3D <10c00>;
> #address-cells =3D <1>;
> #size-cells =3D <0>;
> cell-index =3D <0>;
> fsl,cpm-command =3D <29600000>;
>=20
>=20
> };
>=20
This looks ok to me, I hope you provides proper reg, interrupt number, pola=
rity and sense (as per you mpc9247 specification)?
Thanks
-Bharat
>=20
> Regards,
> Smitha
> Please do not print this email unless it is absolutely necessary.
>=20
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s)
> and may contain proprietary, confidential or privileged information. If
> you are not the intended recipient, you should not disseminate,
> distribute or copy this e-mail. Please notify the sender immediately and
> destroy all copies of this message and any attachments.
>=20
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>=20
> www.wipro.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: David Miller @ 2011-10-17 23:09 UTC (permalink / raw)
To: dpmcgee; +Cc: linuxppc-dev, linux-kernel, paulus
In-Reply-To: <1318892723-19401-1-git-send-email-dpmcgee@gmail.com>
From: Dan McGee <dpmcgee@gmail.com>
Date: Mon, 17 Oct 2011 18:05:23 -0500
> Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
> hold true as the value returned by get_random_int() will in fact be
> different every single call. Remove the comment and simplify the code
> back to its original desired form.
>
> This reverts commit a5adc91a4b44b5d1 which is no longer necessary and
> also fixes the sparc code that copied this same adjustment.
>
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
For sparc part:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: Dan McGee @ 2011-10-17 23:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, linux-kernel, David Miller
In-Reply-To: <20111017.185357.1185691091043314919.davem@davemloft.net>
Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
hold true as the value returned by get_random_int() will in fact be
different every single call. Remove the comment and simplify the code
back to its original desired form.
This reverts commit a5adc91a4b44b5d1 which is no longer necessary and
also fixes the sparc code that copied this same adjustment.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
arch/powerpc/mm/mmap_64.c | 14 +++-----------
arch/sparc/kernel/sys_sparc_64.c | 6 +++---
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/mm/mmap_64.c b/arch/powerpc/mm/mmap_64.c
index 5a783d8..67a42ed 100644
--- a/arch/powerpc/mm/mmap_64.c
+++ b/arch/powerpc/mm/mmap_64.c
@@ -53,14 +53,6 @@ static inline int mmap_is_legacy(void)
return sysctl_legacy_va_layout;
}
-/*
- * Since get_random_int() returns the same value within a 1 jiffy window,
- * we will almost always get the same randomisation for the stack and mmap
- * region. This will mean the relative distance between stack and mmap will
- * be the same.
- *
- * To avoid this we can shift the randomness by 1 bit.
- */
static unsigned long mmap_rnd(void)
{
unsigned long rnd = 0;
@@ -68,11 +60,11 @@ static unsigned long mmap_rnd(void)
if (current->flags & PF_RANDOMIZE) {
/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (long)(get_random_int() % (1<<(22-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
else
- rnd = (long)(get_random_int() % (1<<(29-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
}
- return (rnd << PAGE_SHIFT) * 2;
+ return rnd << PAGE_SHIFT;
}
static inline unsigned long mmap_base(void)
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 908b47a..c2c03c8 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -368,11 +368,11 @@ static unsigned long mmap_rnd(void)
if (current->flags & PF_RANDOMIZE) {
unsigned long val = get_random_int();
if (test_thread_flag(TIF_32BIT))
- rnd = (val % (1UL << (22UL-PAGE_SHIFT)));
+ rnd = (val % (1UL << (23UL-PAGE_SHIFT)));
else
- rnd = (val % (1UL << (29UL-PAGE_SHIFT)));
+ rnd = (val % (1UL << (30UL-PAGE_SHIFT)));
}
- return (rnd << PAGE_SHIFT) * 2;
+ return rnd << PAGE_SHIFT;
}
void arch_pick_mmap_layout(struct mm_struct *mm)
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: David Miller @ 2011-10-17 22:53 UTC (permalink / raw)
To: dpmcgee; +Cc: linuxppc-dev, linux-kernel, paulus
In-Reply-To: <CAEik5nPXQXESnNLJCWd48LLiEYsN6MgnjKhd_a4SMHFGHBbm8w@mail.gmail.com>
From: Dan McGee <dpmcgee@gmail.com>
Date: Mon, 17 Oct 2011 17:43:11 -0500
> Aha, I wasn't aware this was also being done elsewhere as there was no
> comment to tip me off. I found the one in
> arch/sparc/kernel/sys_sparc_64.c (mmap_rnd) and have fixed that
> locally and will resend, but I'm not seeing get_random_int() in use
> anywhere else in that architecture so I'm not quite sure where your
> second mentioned location is- or did you just mean the two calls 2
> lines apart in mmap_rnd()?
My bad, I thought we had implemented address randomization on 32-bit
sparc as well, unfortunately we haven't even though sparc64 has it
for 32-bit compat tasks.
That should be fixed at some point, but is outside of the scope of
what you're doing.
Thanks!
^ permalink raw reply
* Re: [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: Dan McGee @ 2011-10-17 22:43 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-kernel, paulus
In-Reply-To: <20111017.175141.1489173261757833533.davem@davemloft.net>
On Mon, Oct 17, 2011 at 4:51 PM, David Miller <davem@davemloft.net> wrote:
> From: Dan McGee <dpmcgee@gmail.com>
> Date: Mon, 17 Oct 2011 15:17:36 -0500
>
>> Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
>> hold true as the value returned by get_random_int() will in fact be
>> different every single call. Remove the comment and simplify the code
>> back to its original desired form.
>>
>> This reverts commit a5adc91a4b44b5d1 which is no longer necessary.
>>
>> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
>
> Can you please fix up all the other architectures which use the same
> logic, because they have simply copied over what powerpc does?
>
> At a minimum, Sparc has two such locations.
Aha, I wasn't aware this was also being done elsewhere as there was no
comment to tip me off. I found the one in
arch/sparc/kernel/sys_sparc_64.c (mmap_rnd) and have fixed that
locally and will resend, but I'm not seeing get_random_int() in use
anywhere else in that architecture so I'm not quite sure where your
second mentioned location is- or did you just mean the two calls 2
lines apart in mmap_rnd()?
I also did a quick glance over every other usage and didn't seen any
other architectures doing anything funky, even in a slightly different
way.
-Dan
^ permalink raw reply
* Re: [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: David Miller @ 2011-10-17 21:51 UTC (permalink / raw)
To: dpmcgee; +Cc: linuxppc-dev, linux-kernel, paulus
In-Reply-To: <1318882661-26859-1-git-send-email-dpmcgee@gmail.com>
From: Dan McGee <dpmcgee@gmail.com>
Date: Mon, 17 Oct 2011 15:17:36 -0500
> Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
> hold true as the value returned by get_random_int() will in fact be
> different every single call. Remove the comment and simplify the code
> back to its original desired form.
>
> This reverts commit a5adc91a4b44b5d1 which is no longer necessary.
>
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Can you please fix up all the other architectures which use the same
logic, because they have simply copied over what powerpc does?
At a minimum, Sparc has two such locations.
^ permalink raw reply
* linux-3.0.4, mv643xx_eth troubles on Pegasos2 G4
From: nello martuscielli @ 2011-10-17 21:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: acrux
[-- Attachment #1: Type: text/plain, Size: 15628 bytes --]
i'm trying to enable marvel gigabit ethernet support but it doesn't work.
Here my dmesg instead my config is attached.
root@peg2:~# dmesg
:08.0: supports D1 D2
pci 0001:01:08.1: [1002:5940] type 0 class 0x000380
pci 0001:01:08.1: reg 10: [mem 0xd0000000-0xd7ffffff pref]
pci 0001:01:08.1: reg 14: [mem 0xc8010000-0xc801ffff]
pci 0001:01:08.1: supports D1 D2
PCI 0000:00 Cannot reserve Legacy IO [io 0x0000-0x0fff]
PCI: max bus depth: 0 pci_try_num: 1
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0x80000000-0xbfffffff]
pci_bus 0001:01: resource 0 [io 0xffff0000-0xffffffff]
pci_bus 0001:01: resource 1 [mem 0xc0000000-0xdfffffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0001:01:08.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0001:01:08.0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
Bluetooth: Core ver 2.16
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
pci 0000:00:0c.1: Fixing VIA IDE, force legacy mode on
PCI: CLS 128 bytes, default 32
rtasd: scan rate is 0, not scanning
Thermal assist unit not available
highmem bounce pool size: 64 pages
NTFS driver 2.1.30 [Flags: R/W].
JFS: nTxBlock = 8044, nTxLock = 64358
SGI XFS with ACLs, security attributes, large block/inode numbers, no
debug enabled
Btrfs loaded
msgmni has been set to 1499
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: No ATY,RefCLK property !
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
radeonfb: PLL min 20000 max 40000
i2c i2c-1: unable to read EDID block.
i2c i2c-1: unable to read EDID block.
i2c i2c-1: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Console: switching to colour frame buffer device 100x37
radeonfb (0001:01:08.0): ATI Radeon 5960 "Y`"
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x2f8 (irq = 0) is a 16550A
Generic non-volatile memory driver v1.1
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x3BC
parport0: PC-style at 0x3bc, irq 7 [PCSPP]
parport0: Device ID was 64 bytes while device told it would be 63 bytes
parport0 (addr 0): SCSI adapter, IMG VP1
parport_pc: VIA parallel port: io=0x3BC, irq=7
brd: module loaded
loop: module loaded
pata_via 0000:00:0c.1: version 0.3.4
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/100 cmd 0x1000 ctl 0x100c bmdma 0x1020 irq 14
ata2: PATA max UDMA/100 cmd 0x1010 ctl 0x101c bmdma 0x1028 irq 15
Fixed MDIO Bus: probed
firewire_ohci 0000:00:01.0: enabling device (0000 -> 0003)
firewire_ohci: Added fw-ohci device 0000:00:01.0, OHCI v1.0, 8 IR + 8
IT contexts, quirks 0x11
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:05.1: enabling device (0000 -> 0002)
ehci_hcd 0000:00:05.1: EHCI Host Controller
ehci_hcd 0000:00:05.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:05.1: irq 9, io mem 0x80001800
ehci_hcd 0000:00:05.1: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 3.0.4 ehci_hcd
usb usb1: SerialNumber: 0000:00:05.1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
i2c /dev entries driver
ata1.00: ATA-6: ST340810A, 3.39, max UDMA/100
ata1.00: 78165360 sectors, multi 0: LBA
lirc_dev: IR Remote Control driver registered, major 251
atkbd serio0: keyboard reset failed on isa0060/serio0
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
ata1.00: configured for UDMA/100
IR RC5 (streamzap) protocol handler initialized
IR LIRC bridge handler initialized
Linux video capture interface: v2.00
device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
scsi 0:0:0:0: Direct-Access ATA ST340810A 3.39 PQ: 0 ANSI: 5
usbcore: registered new interface driver usbhid
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 78165360 512-byte logical blocks: (40.0 GB/37.2 GiB)
sd 0:0:0:0: [sda] Write Protect is off
atkbd serio1: keyboard reset failed on isa0060/serio1
usbhid: USB HID core driver
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ALSA device list:
No soundcards found.
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata2.00: ATAPI: SAMSUNG CDRW/DVD SM-352B, T807, max UDMA/33
ata2.00: configured for UDMA/33
scsi 1:0:0:0: CD-ROM SAMSUNG CDRW/DVD SM-352B T807 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 1x/52x writer cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg1 type 5
REISERFS (device sda5): found reiserfs format "3.6" with standard journal
REISERFS (device sda5): using ordered data mode
REISERFS (device sda5): journal params: device sda5, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
REISERFS (device sda5): checking transaction log (sda5)
REISERFS (device sda5): Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly on device 8:5.
devtmpfs: mounted
Freeing unused kernel memory: 220k init
firewire_core: created device fw0: GUID 0011060000004b2f, S400
udevd[57]: starting version 173
uhci_hcd: USB Universal Host Controller Interface driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd 0000:00:0c.2: enabling device (0000 -> 0001)
uhci_hcd 0000:00:0c.2: UHCI Host Controller
uhci_hcd 0000:00:0c.2: new USB bus registered, assigned bus number 2
via_rhine: v1.10-LK1.5.0 2010-10-09 Written by Donald Becker
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
uhci_hcd 0000:00:0c.2: irq 9, io base 0x00001040
sysfs: cannot create duplicate filename '/class/mdio_bus/0'
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:455
Modules linked in: snd_via82xx(+) snd_ac97_codec mv643xx_eth(+)
via_rhine(+) i2c_viapro(+) ac97_bus ohci_hcd(+) snd_mpu401_uart
uhci_hcd(+) snd_rawmidi
NIP: c00fa718 LR: c00fa718 CTR: 00000000
REGS: ef271c00 TRAP: 0700 Not tainted (3.0.4)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22004428 XER: 00000000
TASK = ef294c60[94] 'modprobe' THREAD: ef270000
GPR00: c00fa718 ef271cb0 ef294c60 00000042 c0008904 00000001 00000000 00000000
GPR08: c06b6bd8 00000000 22004482 ef271c70 22004422 10024440 1000ba68 00000000
GPR16: 1000ba44 bf83e324 00000000 1000ba58 00000000 104410ec 00000a30 00000000
GPR24: c0059210 00000124 00000000 00000001 ef271cd8 ef2ba480 ffffffef ef344000
NIP [c00fa718] sysfs_add_one+0x88/0xa0
LR [c00fa718] sysfs_add_one+0x88/0xa0
Call Trace:
[ef271cb0] [c00fa718] sysfs_add_one+0x88/0xa0 (unreliable)
[ef271cd0] [c00faff4] sysfs_do_create_link+0x134/0x1e0
[ef271d00] [c0392cf8] device_add+0x204/0x544
[ef271d40] [c03d67e4] mdiobus_register+0xa4/0x198
[ef271d60] [f26785a4] mv643xx_eth_shared_probe+0x144/0x428 [mv643xx_eth]
[ef271d80] [c039685c] platform_drv_probe+0x20/0x30
[ef271d90] [c0395578] driver_probe_device+0xe4/0x198
[ef271db0] [c039569c] __driver_attach+0x70/0x98
[ef271dd0] [c0394614] bus_for_each_dev+0x60/0x90
[ef271e00] [c03951d0] driver_attach+0x24/0x34
[ef271e10] [c0394d9c] bus_add_driver+0xbc/0x23c
[ef271e30] [c0395ac8] driver_register+0xb8/0x144
[ef271e50] [c0396bb4] platform_driver_register+0x68/0x78
[ef271e60] [f2680024] mv643xx_eth_init_module+0x24/0x80 [mv643xx_eth]
[ef271e80] [c000402c] do_one_initcall+0xe0/0x1c0
[ef271eb0] [c005b438] sys_init_module+0x1600/0x17f4
[ef271f40] [c0012df8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff62ac0
LR = 0x10003f2c
Instruction dump:
807c0000 7fe4fb78 4bfff469 3c80c060 3884f131 4bf2051d 809d0010 4bf20515
7c641b78 3c60c060 3863f0fe 484650f9 <0fe00000> 7fe3fb78 4bfa8009 39610020
---[ end trace cebed1f190337b77 ]---
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 3.0.4 uhci_hcd
usb usb2: SerialNumber: 0000:00:0c.2
hub 2-0:1.0: USB hub found
mii_bus 0 failed to register
mv643xx_eth: probe of mv643xx_eth.0 failed with error -12
hub 2-0:1.0: 2 ports detected
ohci_hcd 0000:00:05.0: OHCI Host Controller
ohci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 3
Unable to handle kernel paging request for data at address 0x00000000
ohci_hcd 0000:00:05.0: irq 9, io mem 0x80000000
Faulting instruction address: 0xf267b3a8
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT CHRP
Modules linked in: snd_via82xx(+) snd_ac97_codec mv643xx_eth(+)
via_rhine(+) i2c_viapro(+) ac97_bus ohci_hcd(+) snd_mpu401_uart
uhci_hcd(+) snd_rawmidi
NIP: f267b3a8 LR: f267b3a0 CTR: c0394ff4
REGS: ef271c90 TRAP: 0300 Tainted: G W (3.0.4)
MSR: 00009032 <EE,ME,IR,DR> CR: 84004448 XER: 00000000
DAR: 00000000, DSISR: 40000000
TASK = ef294c60[94] 'modprobe' THREAD: ef270000
GPR00: 00000000 ef271d40 ef294c60 00000000 eec003c0 eec00005 ef24bb3c 00000000
GPR08: ef24bb28 ef8a7600 ffffffff 00000001 44004442 10024440 1000ba68 00000000
GPR16: 1000ba44 bf83e324 00000000 1000ba58 00000000 104410ec 00000a30 00000000
GPR24: c0059210 c06b68c0 00000020 c06b68b8 fffffff4 eec00000 c06b6740 eec003c0
NIP [f267b3a8] mv643xx_eth_probe+0x98/0x604 [mv643xx_eth]
LR [f267b3a0] mv643xx_eth_probe+0x90/0x604 [mv643xx_eth]
Call Trace:
[ef271d40] [f267b394] mv643xx_eth_probe+0x84/0x604 [mv643xx_eth] (unreliable)
[ef271d80] [c039685c] platform_drv_probe+0x20/0x30
[ef271d90] [c0395578] driver_probe_device+0xe4/0x198
[ef271db0] [c039569c] __driver_attach+0x70/0x98
[ef271dd0] [c0394614] bus_for_each_dev+0x60/0x90
[ef271e00] [c03951d0] driver_attach+0x24/0x34
[ef271e10] [c0394d9c] bus_add_driver+0xbc/0x23c
[ef271e30] [c0395ac8] driver_register+0xb8/0x144
[ef271e50] [c0396bb4] platform_driver_register+0x68/0x78
[ef271e60] [f2680034] mv643xx_eth_init_module+0x34/0x80 [mv643xx_eth]
[ef271e80] [c000402c] do_one_initcall+0xe0/0x1c0
[ef271eb0] [c005b438] sys_init_module+0x1600/0x17f4
[ef271f40] [c0012df8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff62ac0
LR = 0x10003f2c
Instruction dump:
7c7d1b79 41820530 3bfd03c0 3b3b0008 7fe4fb78 7f23cb78 48001101 807e0000
38630008 48001505 907d03c0 817e0004
556b502a 396b0400 7d605a14
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 3.0.4 ohci_hcd
usb usb3: SerialNumber: 0000:00:05.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
vt596_smbus 0000:00:0c.4: SMBUS: Error: Host SMBus controller not
enabled! - upgrade BIOS or use force=1
VIA 82xx Audio 0000:00:0c.5: enabling device (0000 -> 0001)
---[ end trace cebed1f190337b78 ]---
via-rhine 0000:00:0d.0: enabling device (0000 -> 0003)
via-rhine 0000:00:0d.0: eth0: VIA Rhine II at 0x80001900,
00:0b:2f:4f:65:7b, IRQ 9
via-rhine 0000:00:0d.0: eth0: MII PHY found at address 16, status
0x786d advertising 01e1 Link 45e1
uhci_hcd 0000:00:0c.3: enabling device (0000 -> 0001)
uhci_hcd 0000:00:0c.3: UHCI Host Controller
uhci_hcd 0000:00:0c.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:0c.3: irq 9, io base 0x00001060
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 3.0.4 uhci_hcd
usb usb4: SerialNumber: 0000:00:0c.3
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 4-1: new low speed USB device number 2 using uhci_hcd
usb 4-1: New USB device found, idVendor=062a, idProduct=0102
usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-1: Product: Wireless Keyboard & Mouse
usb 4-1: Manufacturer: MOSART Semi.
input: MOSART Semi. Wireless Keyboard & Mouse as
/devices/pci0000:00/0000:00:0c.3/usb4/4-1/4-1:1.0/input/input0
generic-usb 0003:062A:0102.0001: input,hidraw0: USB HID v1.10 Keyboard
[MOSART Semi. Wireless Keyboard & Mouse] on usb-0000:00:0c.3-1/input0
input: MOSART Semi. Wireless Keyboard & Mouse as
/devices/pci0000:00/0000:00:0c.3/usb4/4-1/4-1:1.1/input/input1
generic-usb 0003:062A:0102.0002: input,hiddev0,hidraw1: USB HID v1.10
Mouse [MOSART Semi. Wireless Keyboard & Mouse] on
usb-0000:00:0c.3-1/input1
REISERFS (device sda6): found reiserfs format "3.6" with standard journal
REISERFS (device sda6): using ordered data mode
REISERFS (device sda6): journal params: device sda6, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
REISERFS (device sda6): checking transaction log (sda6)
REISERFS (device sda6): Using r5 hash to sort names
REISERFS (device sda7): found reiserfs format "3.6" with standard journal
REISERFS (device sda7): using ordered data mode
REISERFS (device sda7): journal params: device sda7, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
REISERFS (device sda7): checking transaction log (sda7)
REISERFS (device sda7): Using r5 hash to sort names
Adding 499996k swap on /dev/sda1. Priority:-1 extents:1 across:499996k
imm: Version 2.05 (for Linux 2.4.0)
imm: Found device at ID 6, Attempting to use SPP
imm: Communication established at 0x3bc with ID 6 using SPP
scsi2 : Iomega VPI2 (imm) interface
scsi 2:0:6:0: Direct-Access IOMEGA ZIP 100 PLUS J.66 PQ: 0 ANSI: 2
sd 2:0:6:0: Attached scsi generic sg2 type 0
sd 2:0:6:0: [sdb] Attached SCSI removable disk
via-rhine 0000:00:0d.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
ata1.00: configured for UDMA/100
ata1: EH complete
eth0: no IPv6 routers present
--
Power Mac G4 AGP 450MHz - CRUX PPC (32bit)
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 14842 bytes --]
^ permalink raw reply
* [PATCH] powerpc/mm: remove hack in mmap randomize layout
From: Dan McGee @ 2011-10-17 20:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, linux-kernel, Dan McGee
Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
hold true as the value returned by get_random_int() will in fact be
different every single call. Remove the comment and simplify the code
back to its original desired form.
This reverts commit a5adc91a4b44b5d1 which is no longer necessary.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
arch/powerpc/mm/mmap_64.c | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/mm/mmap_64.c b/arch/powerpc/mm/mmap_64.c
index 5a783d8..67a42ed 100644
--- a/arch/powerpc/mm/mmap_64.c
+++ b/arch/powerpc/mm/mmap_64.c
@@ -53,14 +53,6 @@ static inline int mmap_is_legacy(void)
return sysctl_legacy_va_layout;
}
-/*
- * Since get_random_int() returns the same value within a 1 jiffy window,
- * we will almost always get the same randomisation for the stack and mmap
- * region. This will mean the relative distance between stack and mmap will
- * be the same.
- *
- * To avoid this we can shift the randomness by 1 bit.
- */
static unsigned long mmap_rnd(void)
{
unsigned long rnd = 0;
@@ -68,11 +60,11 @@ static unsigned long mmap_rnd(void)
if (current->flags & PF_RANDOMIZE) {
/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (long)(get_random_int() % (1<<(22-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
else
- rnd = (long)(get_random_int() % (1<<(29-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
}
- return (rnd << PAGE_SHIFT) * 2;
+ return rnd << PAGE_SHIFT;
}
static inline unsigned long mmap_base(void)
--
1.7.7
^ permalink raw reply related
* RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
From: Bounine, Alexandre @ 2011-10-17 19:39 UTC (permalink / raw)
To: Vinod Koul, Jassi Brar; +Cc: akpm, linux-kernel, Dan, linuxppc-dev
In-Reply-To: <1318870884.23438.174.camel@vkoul-udesk3>
T24gTW9uLCBPY3QgMTcsIDIwMTEgYXQgMTowMSBQTSwgVmlub2QgS291bCA8dmlub2Qua291bEBp
bnRlbC5jb20+IHdyb3RlOg0KPiANCj4gT24gTW9uLCAyMDExLTEwLTE3IGF0IDIxOjIyICswNTMw
LCBKYXNzaSBCcmFyIHdyb3RlOg0KPiA+IE9uIDE1IE9jdG9iZXIgMjAxMSAyMzowNSwgVmlub2Qg
S291bCA8dmlub2Qua291bEBpbnRlbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gPiBBbm90aGVyIGFs
dGVybmF0ZSBhcHByb2FjaCBjb3VsZCBiZSB0byBhZGQgb25lIG1vcmUgYXJndW1lbnQgdG8NCj4g
PiA+IHByZXBfc2xhdmVfc2cgQVBJIHdoaWNoIGFsbG93cyB1cyB0byBwYXNzIGFkZGl0aW9uYWwg
cnVudGltZQ0KPiBzcGVjaWZpYw0KPiA+ID4gcGFyYW1ldGVycy4gVGhpcyBjYW4gYmUgTlVMTCBh
bmQgdW51c2VkIGZvciBleGlzdGluZyBkcml2ZXJzIGFuZA0KPiB1c2VkIGluDQo+ID4gPiBSSU8g
YW5kIGFueSBmdXR1cmUgc3Vic3lzdGVtcyB3aGljaCB3YW50IHRvIHVzZSBkbWFlbmdpbmUuDQo+
ID4gPiBUaG91Z2h0cy4uLj8NCj4gPiA+DQo+ID4gVGhhdCBkb2Vzbid0IHNvdW5kIG11Y2ggZGlm
ZmVyZW50IHRoYW4gcGFzc2luZyB0aGUgZGF0YSB2aWENCj4gPiBkbWFfY2hhbi5wcml2YXRlIGR1
cmluZyBwcmVwX3NsYXZlX3NnLiBPbmx5IG5vdyB3ZSBhZGQgdG8NCj4gPiB0aGUgbnVtYmVyIG9m
IGFyZ3VtZW50cy4NCj4gWWVzIGFncmVlZCwgYnV0IHdlIGFscmVhZHkgZGVjaWRlZCBhbmQgbWFy
a2VkIGl0IGFzIGRlcHJlY2lhdGVkLg0KPiANCj4gPiBBbmQgdGhlbiBlaXRoZXIgdGhpcyBhcmd1
bWVudCB3b3VsZCBiZSBSYXBpZElPIHNwZWNpZmljICh1bmZhaXINCj4gPiB0byBvdGhlciB1c2Vy
cykgb3IgZ2VuZXJpYy4gSW4gbGF0dGVyIGNhc2Ugd2hhdCB3b3VsZCBpdCBsb29rIGxpa2UgPw0K
PiBNeSBpbml0aWFsIHRob3VnaHRzIHdlcmUgdG8gYWRkIGFuIGFyZ3VtZW50IHdoaWNoIG9ubHkg
dGhlIHNwZWNpZmljDQo+IGRtYWMNCj4ga25vd3MgaG93dG8gZGVjb2RlIGFuZCBpcyBmaWxsZWQg
YnkgaXRzIGNsaWVudC4gQXMgaSBzYWlkIGZvciBleGlzdGluZw0KPiB1c2VycyBhbmQgcGVvcGxl
IHdobyBkb24ndCByZXF1aXJlIGR5bmFtaWMgaW5mb3JtYXRpb24gd291bGRuJ3QgYm90aGVyLg0K
PiBUaGUgcHJvcw0KPiAgLSBhbGxvd3MgdXMgdG8gc3VwcG9ydCBSSU8ga2luZCBvZiBzdWJzeXN0
ZW1zIHdoZXJlIG9uZSBuZWVkcyB0byBwYXNzDQo+IHN1YnN5c3RlbSBzcGVjaWZpYyBpbmZvcm1h
dGlvbiBmb3IgcHJvZ3JhbWluZyB0aGUgZG1hYw0KPiAgLSBkb2Vzbid0IHJlcXVpcmUgdXMgdG8g
YWRkIHN1YnN5c3RlbSBzcGVjaWZpYyBzdHVmZiBpbiBkbWFlbmdpbmUsDQo+IHRvZGF5IGl0cyBS
SU8gdG9tb3Jyb3cgc29tZSBvdGhlciBmb2xrcyBtYXkgd2FudCB0byBhZGQuIFdlIHdhbnQgdG8N
Cj4gbWFpbnRhaW4gZG1hZW5naW5lIGFzIGEgZ2VuZXJpYyBmcmFtZXdvcmssIHdoaWxlIGFsc28g
dHJ5aW5nIHRvIHN1cHBvcnQNCj4gbXVsdGlwbGUgYXVkaWVuY2VzLg0KPiBDb25zOg0KPiAgLSB0
aGVyZSBpcyBubyBndWFyYW50ZWU7ICBkbWFjIGV4cGVjdHMgZm9vIGFuZCBjbGllbnRzIHBhc3Mg
YmFyDQo+IA0KVGhpcyB3YXMgbXkgY29uY2VybiB0aGF0IEkgbWVudGlvbmVkIGluIHRoZSBiZWdp
bm5pbmcgb2YgdGhpcyB0aHJlYWQ6DQpob3cgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGRpZmZl
cmVudCB0eXBlcyBvZiBzbGF2ZSBjaGFubmVscy4gQXQgdGhhdA0KdGltZSB3ZSBkZWNpZGVkIHRo
YXQgY2hhbm5lbCBmaWx0ZXJpbmcgcm91dGluZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQNCnRvIHBy
b3Blcmx5IGlkZW50aWZ5IGEgc3VpdGFibGUgY2hhbm5lbC4gQW5kIHRoaXMgaXMgdHJ1ZSAtIGlm
IFJJTyBmaWx0ZXINCmRldGVjdHMgcmVnaXN0ZXJlZCBSYXBpZElPIGNhcGFibGUgRE1BIGNoYW5u
ZWwgaXQgc2hvdWxkIGJlIHNhZmUgdG8gcGFzcw0KYSBwYXJhbWV0ZXIgc3BlY2lmaWMgdG8gUklP
IGNsaWVudCBpbXBsZW1lbnRhdGlvbi4gICANCg0KSWYgd2Ugd2FudCB0byBwcm90ZWN0IHB1cmUg
c2xhdmUgY2hhbm5lbHMgZnJvbSBtaXhpbmcgd2l0aCBzb21lIHNwZWNpZmljDQppbXBsZW1lbnRh
dGlvbnMgd2UgbWF5IGNvbnNpZGVyIGFkZGluZyBuZXcgdmFsdWVzIGZvciBkbWFfdHJhbnNhY3Rp
b25fdHlwZQ0KYXMgaXQgZG9uZSBmb3IgUmFwaWRJTyAoRE1BX1JBUElESU8sIERNQV9GT08sIERN
QV9CQVIgZXRjLikuDQpUaGlzIHdheSB3ZSBtYXkga2VlcCBzaW5nbGUgQVBJIHdpdGggZXh0cmEg
YXJndW1lbnQgYW5kIGRpZmZlcmVudGlhdGUNCmJldHdlZW4gImZsYXZvcnMiIG9mIERNQV9TTEFW
RSB0byBtYWtlIGRlY2lzaW9ucyBhYm91dCB1c2Ugb2YgdGhhdA0KZXh0cmEgcGFyYW1ldGVyLiBF
LmcuIGNoYW5uZWxzIHJlZ2lzdGVyZWQgYXMgRE1BX1NMQVZFIHdpbGwgaWdub3JlDQp0aGUgbmV3
IHBhcmFtZXRlciAocHVyZSBzbGF2ZSBtb2RlKSwgRE1BX1JBUElESU8gYW5kIERNQV9GT08gdXNl
IGl0DQphY2NvcmRpbmcgdG8gdGhlICJmbGF2b3IiLiAgDQoNClllcywgSSBhbSBwbGFubmluZyB0
byBkcm9wIHRoYXQgZmxhZyBmcm9tIHRoZSBjdXJyZW50IFJJTyBpbXBsZW1lbnRhdGlvbiBidXQN
Ckl0IG1heSBoYXZlIGEgbmV3IG1lYW5pbmcgaWYgcHJlcF9zbGF2ZV9zZygpIGdldHMgdGhlIGV4
dHJhIGFyZ3VtZW50LiAgDQoNCj4gSSBhbSBva2F5IGlmIHdlIGhhdmUgYWx0ZXJuYXRlIHdheSB0
byBzdXBwb3J0IHRoaXMgd2l0aCBhYm92ZSBnb2FsIDopDQo+IA0KPiAtLQ0KPiB+Vmlub2QNCg0K
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-17 18:50 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, linux-kernel
In-Reply-To: <20111017182345.GA14416@suse.de>
On Mon, Oct 17, 2011 at 11:23:45AM -0700, Greg KH wrote:
> On Mon, Oct 17, 2011 at 08:03:51PM +0200, Hans J. Koch wrote:
> > On Mon, Oct 17, 2011 at 07:18:59PM +0200, Hans J. Koch wrote:
> > > On Mon, Oct 17, 2011 at 11:00:55AM -0500, Kumar Gala wrote:
> > > >
> > > > On Oct 14, 2011, at 1:31 PM, Hans J. Koch wrote:
> > > >
> > > > > On Thu, Oct 13, 2011 at 10:50:58AM -0500, Kumar Gala wrote:
> > > > >> From: Kai Jiang <Kai.Jiang@freescale.com>
> > > > >>
> > > > >> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> > > > >> extend the width of 'addr' in struct uio_mem. Numerous platforms like
> > > > >> embedded PPC, ARM, and X86 have support for systems with larger physical
> > > > >> address than logical.
> > > > >>
> > > > >> Since 'addr' may contain a physical, logical, or virtual address the
> > > > >> easiest solution is to just change the type to 'phys_addr_t' which
> > > > >> should always be greater than or equal to the sizeof(void *) such that
> > > > >> it can properly hold any of the address types.
> > > > >>
> > > > >> For physical address we can support up to a 44-bit physical address on a
> > > > >> typical 32-bit system as we utilize remap_pfn_range() for the mapping of
> > > > >> the memory region and pfn's are represnted by shifting the address by
> > > > >> the page size (typically 4k).
> > > > >>
> > > > >> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
> > > > >> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > > >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > > > >
> > > > > Signed-off-by: "Hans J. Koch" <hjk@hansjkoch.de>
> > > > >
> > > > > That looks good to me. There's an unnecessary cast (see below), but I fixed that
> > > > > on the way.
> > > > >
> > > > > Greg, please pull this from branch uio-for-gregkh from
> > > > >
> > > > > git://hansjkoch.de/git/linux-hjk
> > > > >
> > > > > Thanks,
> > > > > Hans
> > > >
> > > > I think removing that cast is wrong:
> > > >
> > > > drivers/uio/uio.c: In function 'uio_vma_fault':
> > > > drivers/uio/uio.c:637:26: warning: cast to pointer from integer of different size
> > >
> > > Hmm, on what platform did you see this? I tested on 32bit-x86 and didn't get
> > > any warnings.
> >
> > OK, you're right. I turned on CONFIG_HIGHMEM64G and got that warning. Damned x86...
> >
> > Greg, can you fix it, or should I send the patch again?
>
> Please send it again.
>From 30767223785a2ea412bd31a00a4534051af1f5dd Mon Sep 17 00:00:00 2001
From: Kai Jiang <Kai.Jiang@freescale.com>
Date: Fri, 14 Oct 2011 20:04:43 +0200
Subject: [PATCH] uio: Support physical addresses >32 bits on 32-bit systems
From: Kai Jiang <Kai.Jiang@freescale.com>
To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem. Numerous platforms like
embedded PPC, ARM, and X86 have support for systems with larger physical
address than logical.
Since 'addr' may contain a physical, logical, or virtual address the
easiest solution is to just change the type to 'phys_addr_t' which
should always be greater than or equal to the sizeof(void *) such that
it can properly hold any of the address types.
For physical address we can support up to a 44-bit physical address on a
typical 32-bit system as we utilize remap_pfn_range() for the mapping of
the memory region and pfn's are represnted by shifting the address by
the page size (typically 4k).
Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Hans J. Koch <hjk@hansjkoch.de>
---
Documentation/DocBook/uio-howto.tmpl | 2 +-
drivers/uio/uio.c | 7 +++----
include/linux/uio_driver.h | 7 +++++--
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index 7c4b514d..54883de 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also
</para></listitem>
<listitem><para>
-<varname>unsigned long addr</varname>: Required if the mapping is used.
+<varname>phys_addr_t addr</varname>: Required if the mapping is used.
Fill in the address of your memory block. This address is the one that
appears in sysfs.
</para></listitem>
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d2efe82..dc27d89 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr);
}
static ssize_t map_size_show(struct uio_mem *mem, char *buf)
@@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr & ~PAGE_MASK);
}
struct map_sysfs_entry {
@@ -634,8 +634,7 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev->info->mem[mi].addr + offset);
else
- page = vmalloc_to_page((void *)idev->info->mem[mi].addr
- + offset);
+ page = vmalloc_to_page((void *)(unsigned long)idev->info->mem[mi].addr + offset);
get_page(page);
vmf->page = page;
return 0;
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 665517c..fd99ff9 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -23,7 +23,10 @@ struct uio_map;
/**
* struct uio_mem - description of a UIO memory region
* @name: name of the memory region for identification
- * @addr: address of the device's memory
+ * @addr: address of the device's memory (phys_addr is used since
+ * addr can be logical, virtual, or physical & phys_addr_t
+ * should always be large enough to handle any of the
+ * address types)
* @size: size of IO
* @memtype: type of memory addr points to
* @internal_addr: ioremap-ped version of addr, for driver internal use
@@ -31,7 +34,7 @@ struct uio_map;
*/
struct uio_mem {
const char *name;
- unsigned long addr;
+ phys_addr_t addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Greg KH @ 2011-10-17 18:23 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, Kai Jiang, linux-kernel
In-Reply-To: <20111017180350.GC13919@local>
On Mon, Oct 17, 2011 at 08:03:51PM +0200, Hans J. Koch wrote:
> On Mon, Oct 17, 2011 at 07:18:59PM +0200, Hans J. Koch wrote:
> > On Mon, Oct 17, 2011 at 11:00:55AM -0500, Kumar Gala wrote:
> > >
> > > On Oct 14, 2011, at 1:31 PM, Hans J. Koch wrote:
> > >
> > > > On Thu, Oct 13, 2011 at 10:50:58AM -0500, Kumar Gala wrote:
> > > >> From: Kai Jiang <Kai.Jiang@freescale.com>
> > > >>
> > > >> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> > > >> extend the width of 'addr' in struct uio_mem. Numerous platforms like
> > > >> embedded PPC, ARM, and X86 have support for systems with larger physical
> > > >> address than logical.
> > > >>
> > > >> Since 'addr' may contain a physical, logical, or virtual address the
> > > >> easiest solution is to just change the type to 'phys_addr_t' which
> > > >> should always be greater than or equal to the sizeof(void *) such that
> > > >> it can properly hold any of the address types.
> > > >>
> > > >> For physical address we can support up to a 44-bit physical address on a
> > > >> typical 32-bit system as we utilize remap_pfn_range() for the mapping of
> > > >> the memory region and pfn's are represnted by shifting the address by
> > > >> the page size (typically 4k).
> > > >>
> > > >> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
> > > >> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > > >
> > > > Signed-off-by: "Hans J. Koch" <hjk@hansjkoch.de>
> > > >
> > > > That looks good to me. There's an unnecessary cast (see below), but I fixed that
> > > > on the way.
> > > >
> > > > Greg, please pull this from branch uio-for-gregkh from
> > > >
> > > > git://hansjkoch.de/git/linux-hjk
> > > >
> > > > Thanks,
> > > > Hans
> > >
> > > I think removing that cast is wrong:
> > >
> > > drivers/uio/uio.c: In function 'uio_vma_fault':
> > > drivers/uio/uio.c:637:26: warning: cast to pointer from integer of different size
> >
> > Hmm, on what platform did you see this? I tested on 32bit-x86 and didn't get
> > any warnings.
>
> OK, you're right. I turned on CONFIG_HIGHMEM64G and got that warning. Damned x86...
>
> Greg, can you fix it, or should I send the patch again?
Please send it again.
^ 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