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]
Date:   Sun, 24 Oct 2021 10:23:38 +0300
From:   Andriy Tryshnivskyy <andriy.tryshnivskyy@...nsynergy.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     jbhayana@...gle.com, lars@...afoo.de, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, Vasyl.Vavrychuk@...nsynergy.com
Subject: Re: [PATCH v6 1/1] iio/scmi: Add reading "raw" attribute.


>>> On Tue, 19 Oct 2021 10:59:49 +0300
>>> Andriy Tryshnivskyy <andriy.tryshnivskyy@...nsynergy.com> wrote:
>>>
>>>> Add IIO_CHAN_INFO_RAW to the mask and implement corresponding
>>>> reading "raw" attribute in scmi_iio_read_raw.
>>>> Introduce new type IIO_VAL_INT_64 to read 64-bit value
>>>> for "raw" attribute.
>>>>
>>> Change log needs to be below the --- otherwise we'll store it forever
>>> in git.  A linked tag (which will be generated when I apply)
>>> is sufficient for this sort of historical info.
>>>
>> Sorry, this is my first patch, I was not aware of that.
>> Thanks for the explanation.
>> Quick question: since next version will include 2 patches,
>> I guess a change log should be moved back to the cover letter, right?
> It's a trade off for which there are no firm rules.
> Sometimes changes are well isolated in individual patches, in which case
> the best bet is to put the change logs in each patch, sometimes they are
> more global things that affect the whole series in which case the change
> log is best in the cover letter.
>
> However, for a given series pick one or other style (don't mix!) as
> otherwise it would get really confusing.  Mostly no one really minds
> where the log is as long as we can find it easily.
>
> Jonathan

thank you for the clarification!

best regards,
Andriy.

Powered by blists - more mailing lists