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]
Message-ID: <874d171d-9ac2-4937-85cc-9c8e076cab44@microchip.com>
Date: Thu, 22 Feb 2024 05:17:30 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <Pier.Beruto@...emi.com>, <andrew@...n.ch>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <Steen.Hegelund@...rochip.com>,
	<netdev@...r.kernel.org>, <Horatiu.Vultur@...rochip.com>,
	<Woojung.Huh@...rochip.com>, <Nicolas.Ferre@...rochip.com>,
	<UNGLinuxDriver@...rochip.com>, <Thorsten.Kummermehr@...rochip.com>,
	<Selvamani.Rajagopal@...emi.com>
Subject: Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x
 MACPHY Serial Interface

On 21/02/24 5:51 pm, Piergiorgio Beruto wrote:
> [Some people who received this message don't often get email from pier.beruto@...emi.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi all,
> thank you for this discussion.
> 
> Since this framework is supposed to be a base for every potential OA-TC6 MACPHY implementation, I propose this could be a joint work.
> Selvamani and I spotted some points in the code where we could optimize the performance and we would like to add the required changes to accommodate all potential implementations.
> 
> Would it be possible to share with the group the latest patches?

Hi Piergiorgio,

Good to hear! Yes I agree with you, let's work together. We really 
appreciate your efforts on this.

As I already replied to Andrew, we too did some implementation changes 
proposed by our internal reviewers to optimize the performance and 
improve the code quality. Also we are in the final stage of the internal 
review and to avoid unnecessary confusions between the versions we don't 
recommend to share an intermediate version. Definitely the next version 
(v3) is going to hit the mainline in the next couple of days so that you 
can give your comments. My team with our internal reviewers are 
extremely working hard to make it happen.

Thanks for your patience.

Best regards,
Parthiban V
> 
> Thanks,
> Piergiorgio
> 
> -----Original Message-----
> From: Parthiban.Veerasooran@...rochip.com <Parthiban.Veerasooran@...rochip.com>
> Sent: 21 February, 2024 06:15
> To: andrew@...n.ch
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com; Steen.Hegelund@...rochip.com; netdev@...r.kernel.org; Horatiu.Vultur@...rochip.com; Woojung.Huh@...rochip.com; Nicolas.Ferre@...rochip.com; UNGLinuxDriver@...rochip.com; Thorsten.Kummermehr@...rochip.com; Piergiorgio Beruto <Pier.Beruto@...emi.com>; Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>
> Subject: Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface
> 
> [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.
> 
> On 19/02/24 8:00 pm, Andrew Lunn wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>>> Hi Andrew,
>>>
>>>    From Microchip side, we haven't stopped/postponed this framework
>>> development. We are already working on it. It is in the final stage now.
>>> We are doing internal reviews right now and we expect that in 3 weeks
>>> time frame in the mainline again. We will send a new version (v3) of
>>> this patch series soon.
>>
>> Hi Parthiban
>>
>> It is good to here you are still working on it.
>>
>> A have a few comments about how Linux mainline works. It tends to be
>> very iterative. Cycles tend to be fast. You will probably get review
>> comments within a couple of days of posting code. You often see
>> developers posting a new version within a few days, maybe a week. If
>> reviewers have asked for large changes, it can take longer, but
>> general, the cycles are short.
>>
>> When you say you need three weeks for internal review, that to me
>> seems very slow. Is it so hard to get access to internal reviewers? Do
>> you have a very formal review process? More waterfall than iterative
>> development? I would suggest you try to keep your internal reviews
>> fast and low overhead, because you will be doing it lots of times as
>> we iterate the framework.
> 
> Hi Andrew,
> 
> We understand your concern. We are working on this task with full focus.
> Initially there were some implementation change proposal from our internal reviewers to improve the performance and code quality.
> Consequently the testing of the new implementation took some while to bring it to a good shape.
> 
> Our internal reviewers Steen Hegelund and Horatiu Vultur are actively participating in reviewing my patches. I already have talked to them and we are in progress together to get the next version ready for the submission. We are trying our level best and working hard to push the next set of patches to the mainline as soon as possible.
> 
> Best regards,
> Parthiban V
>>
>>           Andrew
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ