Re: [PATCH RFC] staging: Add driver to communicate with the T2 Security Chip

[Aditya Garg <gargaditya08@live.com>]

> On 9 Mar 2025, at 3:54 PM, gregkh@linuxfoundation.org wrote:
> 
> On Sun, Mar 09, 2025 at 10:12:06AM +0000, Aditya Garg wrote:
>> 
>> 
>>>> On 9 Mar 2025, at 3:26 PM, gregkh@linuxfoundation.org wrote:
>>> 
>>> On Sun, Mar 09, 2025 at 09:52:43AM +0000, Aditya Garg wrote:
>>>> 
>>>> 
>>>>>> On 9 Mar 2025, at 3:21 PM, gregkh@linuxfoundation.org wrote:
>>>>> 
>>>>> On Sun, Mar 09, 2025 at 09:41:29AM +0000, Aditya Garg wrote:
>>>>>> 
>>>>>> 
>>>>>>>> On 9 Mar 2025, at 3:09 PM, gregkh@linuxfoundation.org wrote:
>>>>>>> 
>>>>>>> On Sun, Mar 09, 2025 at 09:28:01AM +0000, Aditya Garg wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> On 9 Mar 2025, at 2:46 PM, gregkh@linuxfoundation.org wrote:
>>>>>>>>> 
>>>>>>>>> On Sun, Mar 09, 2025 at 09:03:29AM +0000, Aditya Garg wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> On 9 Mar 2025, at 2:24 PM, gregkh@linuxfoundation.org wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Sun, Mar 09, 2025 at 08:40:31AM +0000, Aditya Garg wrote:
>>>>>>>>>>>> From: Paul Pawlowski <paul@mrarm.io>
>>>>>>>>>>>> 
>>>>>>>>>>>> This patch adds a driver named apple-bce, to add support for the T2
>>>>>>>>>>>> Security Chip found on certain Macs.
>>>>>>>>>>>> 
>>>>>>>>>>>> The driver has 3 main components:
>>>>>>>>>>>> 
>>>>>>>>>>>> BCE (Buffer Copy Engine) - this is what the files in the root directory
>>>>>>>>>>>> are for. This estabilishes a basic communication channel with the T2.
>>>>>>>>>>>> VHCI and Audio both require this component.
>>>>>>>>>>> 
>>>>>>>>>>> So this is a new "bus" type?  Or a platform resource?  Or something
>>>>>>>>>>> else?
>>>>>>>>>> 
>>>>>>>>>> It's a PCI device
>>>>>>>>> 
>>>>>>>>> Great, but then is the resources split up into smaller drivers that then
>>>>>>>>> bind to it?  How does the other devices talk to this?
>>>>>>>> 
>>>>>>>> We technically can split up these 3 into separate drivers and put then into their own trees.
>>>>>>> 
>>>>>>> That's fine, but you say that the bce code is used by the other drivers,
>>>>>>> right?  So there is some sort of "tie" between these, and that needs to
>>>>>>> be properly conveyed in the device tree in sysfs as that will be
>>>>>>> required for proper resource management.
>>>>>> 
>>>>>> Yes there needs to be a tie, basically first establish a communication with the t2 using bce and then the other 2 come into the picture. I did get a basic idea from what the maintainers want, and this will be some work to do. Thanks for your inputs!
>>>>> 
>>>>> If there is "communication" then that's a bus in the driver model
>>>>> scheme, so just use that, right?
>>>> 
>>>> So basically RE the whole driver to see what exactly should be use?
>>> 
>>> I'm sorry, I can not parse this.
>> 
>> 
>> I was asking that should I introduce a completely new bus instead of
>> pci and probably reverse engineer the original macOS driver to see
>> what exactly is going on there?
> 
> No, if it's a PCI device on a PCI bus, then use the PCI api for all of
> that.
> 
> It's what that PCI device "exposes" here, are the other devices, like
> the USB host controller, hanging off of that, or are they real PCI
> devices as well?
> 
> What exactly does this BCE driver do?
> 
>> I might not have been clear, but I'm not the author of this patch.
> 
> That's fine, but why doesn't the original author want to do this work?

Lack of motivation I suppose. The driver was getting more and more annoying to fix bugs IIRC.
> Have you asked them if they want this code included in the kernel tree?

He had permitted me to send whatever I want upstream in a conversation.
> Who is going to do the maintenance for it and who is going to answer
> questions like the ones I have here?

I cannot answer this rn, I suppose I acknowledged my lack of Maintainers being added. Since I am a part of a small group of developers who aim to bring support for t2 macs, one of us will take up. Currently I am just trying to get an overview which can guide me further on what can be improved as far as maintainers are concerned.
> 
> And again, what is with the new user/kernel api being added?  What is
> all of that for?

Please give me time to read the driver a bit more, so that I can answer it better. I need to find the notes of the author who actually wrote the driver.
> 
> thanks,
> 
> greg k-h