On 29/11/2022 09:27, Atish Kumar Patra wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, Nov 28, 2022 at 11:32 PM <conor.doo...@microchip.com> wrote:
>>
>> On 29/11/2022 07:08, Andrew Jones wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>>> content is safe
>>>
>>> On Mon, Nov 28, 2022 at 09:10:03PM +0000, conor.doo...@microchip.com wrote:
>>>> On 28/11/2022 20:41, Atish Kumar Patra wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>>>> the content is safe
>>>>>
>>>>> On Mon, Nov 28, 2022 at 12:38 PM <conor.doo...@microchip.com> wrote:
>>>>>>
>>>>>> On 28/11/2022 20:16, Atish Kumar Patra wrote:
>>>>>>> On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley
>>>>>>> <conor.doo...@microchip.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
>>>>>>>>> Qemu virt machine can support few cache events and cycle/instret
>>>>>>>>> counters.
>>>>>>>>> It also supports counter overflow for these events.
>>>>>>>>>
>>>>>>>>> Add a DT node so that OpenSBI/Linux kernel is aware of the virt
>>>>>>>>> machine
>>>>>>>>> capabilities. There are some dummy nodes added for testing as well.
>>>>>>>>
>>>>>>>> Hey Atish!
>>>>>>>>
>>>>>>>> I was fiddling with dumping the virt machine dtb again today to check
>>>>>>>> some dt-binding changes I was making for the isa string would play
>>>>>>>> nicely with the virt machine & I noticed that this patch has introduced
>>>>>>>> a new validation failure:
>>>>>>>>
>>>>>>>> ./build/qemu-system-riscv64 -nographic -machine virt,dumpdtb=qemu.dtb
>>>>>>>>
>>>>>>>> dt-validate -p
>>>>>>>> ../linux/Documentation/devicetree/bindings/processed-schema.json
>>>>>>>> qemu.dtb
>>>>>>>> /home/conor/stuff/qemu/qemu.dtb: soc: pmu:
>>>>>>>> {'riscv,event-to-mhpmcounters': [[1, 1, 524281, 2, 2, 524284, 65561,
>>>>>>>> 65561, 524280, 65563, 65563, 524280, 65569, 65569, 524280, 0, 0, 0, 0,
>>>>>>>> 0]], 'compatible': ['riscv,pmu']} should not be valid under {'type':
>>>>>>>> 'object'}
>>>>>>>> From schema:
>>>>>>>> /home/conor/.local/lib/python3.10/site-packages/dtschema/schemas/simple-bus.yaml
>>>>>>>>
>>>>>>>> I assume this is the aforementioned "dummy" node & you have no
>>>>>>>> intention
>>>>>>>> of creating a binding for this?
>>>>>>>>
>>>>>>>
>>>>>>> It is a dummy node from Linux kernel perspective. OpenSbi use this
>>>>>>> node to figure out the hpmcounter mappings.
>>>>>>
>>>>>> Aye, but should it not have a binding anyway, since they're not
>>>>>> meant to be linux specific?
>>>>>>
>>>>> It is documented in OpenSBI.
>>>>> https://github.com/riscv-software-src/opensbi/blob/master/docs/pmu_support.md
>>>>>
>>>>> Are you suggesting that any non-Linux specific DT nodes should be part
>>>>> of Linux DT binding as well ?
>>>>
>>>> I thought the point was that they were *not* meant to be linux specific,
>>>> just happening to be housed there.
>>>>
>>>
>>> I'm not sure if there's an official policy on where DT nodes should be
>>> specified, but it looks like Samuel's opinion is that they should live
>>> in the Linux kernel, whether they're used there or not [1].
>>>
>>> [1] http://lists.infradead.org/pipermail/opensbi/2022-October/003522.html
>>
>> Yah, that was also my understanding. See also U-Boot moving to unify
>> their custom bindings into the linux repo:
>> https://lore.kernel.org/linux-devicetree/20220930001410.2802843-1-...@chromium.org/
>>
>
> This adds the U-Boot specific DT properties to the dts schema itself,
> not Linux kernel DT bindings.
Yeah, sorry. I muddled things up a little there. My point was that they
are trying to get to a stage where dt-validate and those tools work for
them too. I'm not sure were I said "linux repo" rather than "dt-schema
repo" when I double checked the file paths in the link before pasting it
to make sure it was the dt-schema one.. I blame it being early.
> I am not opposed to adding PMU DT bindings to Linux but there should
> be a clear policy on this.
> What about OpenSBI domain DT bindings ?
> If every other DT based open source project starts adding their DT
> binding to the Linux kernel, that may go downhill pretty soon.
Maybe I am misunderstanding, but I had thought the goal was to get to
user-independent bindings. Rob and Krzysztof certainly labour the point
that the bindings should not reflect how one operating system's drivers
would like to see them & u-boot or FreeBSD using a property is grounds
for it not being removed from the bindings in the linux tree.
I'll go and actually ask Rob.
