linux-kernel - Re: [PATCH v3 0/2] Add support for Microchip's pwm fpga core

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 for Android: free password hash cracker in your pocket

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

Message-ID: <13e546a2-37d8-f0a2-4651-d6ecf60de0ef@microchip.com>
Date:   Fri, 17 Jun 2022 13:13:11 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <u.kleine-koenig@...gutronix.de>
CC:     <thierry.reding@...il.com>, <lee.jones@...aro.org>,
        <Daire.McNamara@...rochip.com>, <linux-kernel@...r.kernel.org>,
        <linux-pwm@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
        <Conor.Dooley@...rochip.com>
Subject: Re: [PATCH v3 0/2] Add support for Microchip's pwm fpga core



On 17/06/2022 14:09, Uwe Kleine-König wrote:
> Hello,
> 
> On Fri, Jun 17, 2022 at 11:50:13AM +0000, Conor.Dooley@...rochip.com wrote:
>> On 17/06/2022 12:44, Conor Dooley wrote:
>>> Hey Uwe,
>>> Got a ~v2~ v3 for you...
>>> I added some comments explaining the calculations and a documentation link
>>> so hopefully things are a bit easier to follow.
>>>
>>> Code wise, I went through and sorted out a bunch of issues that cycling
>>> through the different periods/duties threw up. Along the way I found
>>> some other problems - especially with the longer periods which I have
>>> fixed. I also added a write to the sync register in the apply function,
>>> which will resolve to a NOP for channels without "shadow registers".
>>>
>>> Other than that, I managed to ditch the mchp_core_pwm_registers struct
>>> entirely but had to add a short delay before reading back the registers
>>> in order to compute the duty.
>>>
>>> Thanks,
>>> Conor.
>>
>> *sigh* yet again I forgot to mention the potential maintainers conflict
>> with spi-next..
> 
> I'm not a maintainer of a very active subsystem where MAINTAINER
> conflicts are normal, but my expectation up to now was that conflicts in
> that file are quite usual and trivial to resolve such that mentioning
> these isn't very important.
> 

Yeah, I figured such conflicts were rather normal but felt like it was
better to say it just in case.
Thanks,
Conor.