linux-kernel - Re: [PATCH v6 1/1] iio/scmi: Add reading "raw" attribute.

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.