<wens>
montjoie: I should restate that we need a solution this week, preferably not at the end of the week
<montjoie>
ok mripard already asked for it on ML
<wens>
montjoie: please ask mripard. I have some other personal matters to deal with
<montjoie>
just I remove mdio-mux
<montjoie>
wens: with andrew answer, what do you think about two seperate mdio ?
<montjoie>
now the real question, does it is faster...
<montjoie>
and RSA work on A83t \o/
<montjoie>
yes that was I mean to say
<willmore>
montjoie, in specification documents, "MAY" indicated an optional requirement. "SHOULD" is a manditory requirement.
<montjoie>
wens: I am a bit lost on what to do now. Does just I try to send the serie updated with your comments ?
<montjoie>
I think it will finish in arch/arm
<montjoie>
search for dma_map_single for example in Linux source
<montjoie>
so you need to do what do DMA API, flush the cacheline
<chrisf_>
montjoie: I don't have an API ;)
<montjoie>
chrisf_: if you do DMA, you need to use the API for it:)
<chrisf_>
montjoie: seems my H5 problems are because I haven't implemented dma_map/unmap. If I put my descriptor in SRAM C the length error goes away :)
<montjoie>
all other mdio-mux dont care also of xMIII
<montjoie>
but it will be more work
<montjoie>
like we just called mmio-mux-regmap-select(bus)
<montjoie>
what I understand is that mmio-mux-regmap will remove some code from dwmac-sun8i
<montjoie>
wens: how do you understand AndrewLunn comment ? MAY ou SHOULD ?
<montjoie>
nothing more
<montjoie>
MoeIcenowy: yes, just add phy-is-integrated
<MoeIcenowy>
montjoie: thus should I add phy-is-integrated to the V3s EPHY?
2017-08-20
<montjoie>
ouch got an if (err) return err; that return when err = 0
<montjoie>
MoeIcenowy: no, since V3s could do only internal, they are no intereset in representing a mdio which will never be used
<MoeIcenowy>
montjoie: should I care the mdio mux when writing the V3s DT?
<chrisf__>
montjoie: I'll be interested to hear how you get on.
<montjoie>
and no iommu
<montjoie>
chrisf__: I am setupping an H5 for testing CE on it.
<montjoie>
pfff with the same UART dongle, RX/TX is inverted between bpim3 and a H5 board. At least someone lie on RX/TX location
2017-08-18
<wens>
montjoie: mdio-parent-bus is optional
<wens>
montjoie: ok, I didn't know there was already a binding for mdio-mux
<montjoie>
chrisf_: I expect to have my crypto/engine patch merged soon, so in a few days I will send sun8i-ce code for review (and perhaps it will be merged in a few release)
<montjoie>
yes 4bytes
<montjoie>
chrisf_: len is in block
<montjoie>
chrisf_: new branch sun8i-ce-wip_next-20170817
<chrisf_>
montjoie: AES decrypt. I've been looking very closely at your github!
<montjoie>
(and it is a good time to update it)
<montjoie>
chrisf_: you could see what I do on my github
<montjoie>
chrisf_: which type of task do you run ?
<montjoie>
and I cannot remove parent mdio as mdio-mux "mdio-parent-bus" is mandatory
<montjoie>
wens: current usage of mdio-mux seems as to keep mdio type
<montjoie>
yes but with mux of_phy_find_device does not find the PHY...
<wens>
montjoie: you will probably need to ask rob to look at it specifically?
<montjoie>
I work on it in case of...
<montjoie>
but mdio-mux does not work out of the box and stmmac will need some more patch
<montjoie>
wens: lets see if my last serie will be accepted. If not we will probably need mdio-mux (which I agree with rob is probably the right way)
2017-08-17
<wens>
montjoie: it will be -rc6 this weekend. we need to sort this out by next week or I'm going to revert H3 EMAC support
<montjoie>
wens: rob made an anwser, I am checking mdio mux in case of...
<montjoie>
:)
<montjoie>
ouch what happened! klined!
2017-08-16
<igraltist>
montjoie: ok
<montjoie>
igraltist: no
2017-08-15
<montjoie>
MoeIcenowy: not yet
<MoeIcenowy>
montjoie: have you sent the dwmac-sun8i ephy patches?
2017-08-14
<montjoie>
In fact I wish to have a column for that in the support matrix or other wiki way
<montjoie>
I want to do some secureboot optee, which SoC is the best for that ? I ask that because I saw some task about H3 thaa cannot be boot in secure mode
<montjoie>
and since PAX have some part in assembly... ARM support is not evident
<montjoie>
grsec is beyond framework with PAX.
<montjoie>
:) I didnt wanted to start the troll about grsec availlability:)
<montjoie>
I think it should works, depend on what grsec patch you have (against which kernel)
<montjoie>
fugitive: grsec supports arm ?
<montjoie>
property on dt node is simple
<montjoie>
the correct way is probably to create two MDIO node but it requires some(lot) of hack of stmmac
<montjoie>
but on this thread, long delay seems a goal
<montjoie>
wens: yes, I try to wait...
<wens>
montjoie: still, Rob hasn't answered what to do about the internal phy node
<wens>
montjoie: you should probably pick the doc patch from net-next, and include it in your series for netdev
<montjoie>
wens: it seems that rockship integrated PHY is merged, so I will resend my series without the doc patch and with property on board DT
2017-08-12
<MoeIcenowy>
montjoie: P.S. it
<MoeIcenowy>
montjoie: when udhcpc is in definite "sending discover" I unplugged the cable, no link down infomation is shown, however a warning appeared "NETDEV WATCHDOG: eth0 (dwmac-sun8i): transmit queue 0 timed out"
<MoeIcenowy>
montjoie: I'm retrying dwmac-sun8i on R40
2017-08-11
<wens>
montjoie: that would work
<montjoie>
wens: or put phy-is-integrated in board dts
<MoeIcenowy>
montjoie: not yet released
<montjoie>
no H6 user manual ?
<montjoie>
I can propose it, in my mail
<montjoie>
wens: or another solution, split mdio in two
<montjoie>
ok
<wens>
montjoie: Rob and Mark Rutland (mostly Rob). Florian comments on ethernet related dt changes, so add him as well?
<montjoie>
wens: I will make answer another to your last mail. Does rob is the right target ? (since it is a DT problem)
<wens>
montjoie: I don't think that would pass review by dt maintainers
<montjoie>
wens: and using @integrated ?
<montjoie>
I read DT spec in case I see a solution
<montjoie>
I pick 31, but I fear that hack would be rejected
<montjoie>
like @FF ?
<montjoie>
seldom used address ?
<wens>
montjoie: then move the internal phy to a seldom used address, like I mentioned before
<montjoie>
wens: deleting property on all external phy is horrible
<wens>
montjoie: right now it works, because external phy is rgmii, and that is the last thing set
<montjoie>
there are something I have difficulty to understand
<montjoie>
wens: so on bpim2+ integrated and external phy is merged. how dtc know which phy-mode etc.. to use ?
<montjoie>
not bad
<montjoie>
KotCzarny: yes
<wens>
montjoie: it doesn't match the policy on device node names
<KotCzarny>
montjoie: did you miss zidoo h6 box announcement?
<montjoie>
would love to do the driver for that:)
<montjoie>
pcie!!!
<montjoie>
wens: what do you think with my idea ? nodename: integrated-phy
2017-08-10
<montjoie>
igraltist: didnt get it but only get 5.4.0
<montjoie>
wens: just sent!
<montjoie>
wens: I have 3 patchs one binddoc, one for h3 dt, and one for stmmac
<montjoie>
patch for doc is ready:)
<wens>
montjoie: since we need it for netdev, as opposed to them sending it for net-next, you should probably also do the "phy-is-integrated" generic binding part
<montjoie>
wens: we got an answer \o/
2017-08-09
<montjoie>
inf: allwinner,leds-active-high is iinvalid try "/delete-property/ allwinner,leds-active-low;"
<montjoie>
:)
<inf>
time to take a walk or something... thank you very much montjoie :)