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
| ||
|
Date: Sun, 13 Mar 2016 12:04:41 +0800 From: Caesar Wang <caesar.upstream@...il.com> To: Sergei Shtylyov <sergei.shtylyov@...entembedded.com> Cc: Caesar Wang <caesar.upstream@...il.com>, Mark Rutland <mark.rutland@....com>, Heiko Stuebner <heiko@...ech.de>, Alexander Kochetkov <al.kochet@...il.com>, Michael Turquette <mturquette@...libre.com>, linux-clk@...r.kernel.org, Russell King <linux@....linux.org.uk>, zhengxing <zhengxing@...k-chips.com>, linux-rockchip@...ts.infradead.org, Caesar Wang <wxt@...k-chips.com>, devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>, Ian Campbell <ijc+devicetree@...lion.org.uk>, Kumar Gala <galak@...eaurora.org>, Rob Herring <robh+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org, Jiri Kosina <trivial@...nel.org>, netdev@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>, linux-kernel@...r.kernel.org, keescook@...gle.com, "David S. Miller" <davem@...emloft.net>, leozwang@...gle.com Subject: Re: [PATCH 0/6] arc_emac: fixes the emac issues oand cleanup emac drivers 在 2016年03月12日 02:46, Sergei Shtylyov 写道: > Hello. > > On 03/11/2016 05:48 PM, Caesar Wang wrote: > > [...] > >>>> Hi Rob, David: >>>> PATCH[1/6-2/6]: ====> >>>> net: arc_emac: make the rockchip emac document more compatible >>>> net: arc_emac: add phy-reset-* are optional for device tree >>>> >>>> The patches change the rockchip emac document for more compatible and >>>> Add the phy-reset-* property for document. >>>> >>>> This patch adds the following property for arc_emac. >>>> >>>> phy-reset-* include the following: >>>> 1) phy-reset-gpios: >>>> The phy-reset-gpios is an optional property for arc emac device >>>> tree boot. >>>> Change the binding document to match the driver code. >>>> >>>> 2) phy-reset-duration: >>>> Different boards may require different phy reset duration. Add >>>> property >>>> phy-reset-duration for device tree probe, so that the boards that need >>>> a longer reset duration can specify it in their device tree. >>>> >>>> 3) phy-reset-active-high: >>>> We need that for a custom hardware that needs the reverse reset >>>> sequence. >>> >>> Why not infer this from the "phy-reset-gpios" prop? >> >> See: >> https://patchwork.kernel.org/patch/8564511/ > > >> phy-reset-active-high : If present then the reset sequence using the >> GPIO >> specified in the "phy-reset-gpios" property is reversed (H=reset >> state, >> L=operation state). > > Referring to your own suggested bindings isn't an answer. If the > driver that you're copying from here (fec) had a reason to handle the > GPIO sense with the help of an extra prop (legacy code), it doesn't > mean your new driver needs to mimic this as well, AFAIU... I know your suggestion is a fair request. Oh, that copy from the 'freescale/fec_main.c' .... So, The exist way was old and unwise in mainline. :( wxt@nb:~/kernel/drivers/net/ethernet$ ag reset-gpios micrel/ks8851.c 1427: gpio = of_get_named_gpio_flags(spi->dev.of_node, "reset-gpios", arc/emac_main.c 787: phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0); 797: dev_err(dev, "failed to get phy-reset-gpios: %d\n", err); arc/emac_main.c~ 784: phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0); 794: dev_err(dev, "failed to get phy-reset-gpios: %d\n", err); davicom/dm9000.c 1451: reset_gpios = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0, freescale/fec_main.c 3206: phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0); 3216: dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err); cadence/macb.c 2958: int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0); ... Anyway, I will update it with your suggestion. Thanks, Caesar > >> Thanks, >> >> Caesar > > MBR, Sergei > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@...ts.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Thanks, Caesar
Powered by blists - more mailing lists