linux-kernel - Re: [linux-sunxi] Re: [PATCH 04/10] net: stmmac: sunxi platfrom extensions for GMAC in Allwinner A20 SoC's

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Dec 2013 11:27:45 +0800
From:	Chen-Yu Tsai <wens@...e.org>
To:	linux-sunxi <linux-sunxi@...glegroups.com>
Cc:	Srinivas KANDAGATLA <srinivas.kandagatla@...com>,
	Giuseppe Cavallaro <peppe.cavallaro@...com>,
	netdev <netdev@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree <devicetree@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] Re: [PATCH 04/10] net: stmmac: sunxi platfrom
 extensions for GMAC in Allwinner A20 SoC's

Hi,

On Fri, Dec 13, 2013 at 6:38 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:
> On Thu, Dec 12, 2013 at 06:31:43PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Dec 12, 2013 at 5:04 PM, Maxime Ripard
>> <maxime.ripard@...e-electrons.com> wrote:
>> > Hi,
>> >
>> > On Wed, Dec 11, 2013 at 02:45:08PM +0000, srinivas kandagatla wrote:
>> >> >>> 1. .tx_coe
>> >> >>>    This is not exported in the DT bindings.
>> >> >>>    Looking at stmmac code, not setting this seems to disable all
>> >> >>>    checksum offloading.
>> >> >>
>> >> >> Why cant this go via DT as well?
>> >> >
>> >> > If you and Giuseppe are OK with this, why not?
>> >> Am Ok with it.
>> >
>> > Please note that I'm opposed to this until someone explain why putting
>> > it in the DT is relevant (and not just convenient).
>>
>> Checksum offloading is an optional feature[1], implemented starting
>> from version 3.20a. It is not tied to a specific IP version. As such,
>> using a "snps,dwmac-<version>" compatible isn't a good fit here.
>
> No, but we're not in such case. Since we have a compatible of our own,
> we can derive it from that. Putting a property in the DT would only be
> redundant.
>
>> stmmac does auto-detection for optional features on MAC version > 3.50a.
>> This is what Srinivas was referring to.
>>
>> Unfortunately, our MAC is < 3.50a. No auto-detection. We could add a
>> "snps,dwmac-tx-coe" compatible for this, or the seperate DT property.
>>
>> The other way would be to pass the flags in the initial .data with the
>> SoC specific compatible. Other SoCs with the same feature won't be
>> able to reuse the same compatible though.
>
> Which is already pretty much the case, since we have to deal with
> Allwinner specific code and features.
>
> A new compatible is cheap to maintain, a new property is not.

Srinivas,

Let's keep platform data as of_data, so SoC compatibles can pass
hardware feature flags for cores that don't support auto-detection.

We can adjust the callbacks as you suggested, and I added a .free
to complement .setup. Driver private data and platform data are
off limits to the callbacks. My version of the callbacks:

        void (*fix_mac_speed)(void *priv, unsigned int speed);
        void (*bus_setup)(void __iomem *ioaddr);
        void *(*setup)(struct platform_device *pdev);
        void (*free)(struct platform_device *pdev, void *priv);
        int (*init)(struct platform_device *pdev, void *priv);
        void (*exit)(struct platform_device *pdev, void *priv);


Cheers,

ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/