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:   Wed, 10 Jul 2019 13:05:20 +0800
From:   Jiangfeng Xiao <xiaojiangfeng@...wei.com>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        <davem@...emloft.net>, <robh+dt@...nel.org>,
        <yisen.zhuang@...wei.com>, <salil.mehta@...wei.com>,
        <mark.rutland@....com>, <dingtianhong@...wei.com>
CC:     <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <leeyou.li@...wei.com>,
        <nixiaoming@...wei.com>, <jianping.liu@...wei.com>,
        <xiekunxun@...wei.com>
Subject: Re: [PATCH v2 05/10] net: hisilicon: HI13X1_GMAX need dreq reset at
 first



On 2019/7/9 21:48, Jiangfeng Xiao wrote:
> 
> 
> On 2019/7/9 17:35, Sergei Shtylyov wrote:
>> Hello!
>>
>> On 09.07.2019 6:31, Jiangfeng Xiao wrote:
>>
[...]
>>> @@ -853,6 +867,15 @@ static int hip04_mac_probe(struct platform_device *pdev)
>>>           goto init_fail;
>>>       }
>>>   +#if defined(CONFIG_HI13X1_GMAC)
>>> +    res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> +    priv->sysctrl_base = devm_ioremap_resource(d, res);
>>
>>    There's devm_platform_ioremap_resource() now.
> 
> Thank you for your review, Great issue, which makes my code more concise.
> 
> I will fix it in v3. Or submit a patch to modify it separately, if maintainer
> applies this patch series.
> 
I decided to wait for this series of patches to sync to the mainline
and then fix this based on the mainline.

Because the mainline does not currently have this part of the code,
if I submit the changes, and the patch is accidentally merged into
another branch or another maintainer to handle, a conflict will occur.

As we all know, maintianer has to deal with many commits every day,
I don't want to increase the burden of maintainer.

So I decided to wait until the patch is synced to the mainline
and then modify it, which is more safe.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ