netdev - Re: [PATCH v2] net: sh-eth: Add flag to determine the type of TSU register

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] [day] [month] [year] [list]

Date:   Tue, 2 Jan 2018 20:27:42 +0300
From:   Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:     Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
        netdev@...r.kernel.org
Cc:     yoshihiro.shimoda.uh@...esas.com
Subject: Re: [PATCH v2] net: sh-eth: Add flag to determine the type of TSU
 register

Hello!

On 05/07/2013 09:08 AM, Nobuhiro Iwamatsu wrote:

> Some sh-eth devices may have two ether devices inside.
> And the function of TSU is accessed from each ether device.
> In this case, sh-eth need to remap address using devm_ioremap(),
> without using devm_ioremap_resource().
> tsu_shared_reg of sh_eth_cpu_data is used for this control.
> 
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>
> ---
> V2:
>    - Change variable name from tsu_multi_reg to tsu_shared_reg.
>    - Update commit message.
> 
>   drivers/net/ethernet/renesas/sh_eth.c |   11 ++++++++++-
>   drivers/net/ethernet/renesas/sh_eth.h |    1 +
>   2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 33dc6f2..489be0e 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -2750,7 +2754,12 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>   			ret = -ENODEV;
>   			goto out_release;
>   		}
> -		mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu);
> +
> +		if (mdp->cd->tsu_shared_reg)
> +			mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start,
> +					resource_size(rtsu));

    I now think there's no need for a special flag -- we can just use 'devno' 
(at least for the pure platform devices). The DT probing case remains unsolved 
though (might make sense to look at the resource #0, whether it has 0x800 set 
or not)...

> +		else
> +			mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu);
>   		if (IS_ERR(mdp->tsu_addr)) {
>   			ret = PTR_ERR(mdp->tsu_addr);
>   			goto out_release;

MBR, Sergei