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

From: Aditya Garg
Date: Sun Mar 09 2025 - 05:41:49 EST




> On 9 Mar 2025, at 3:09 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>
> On Sun, Mar 09, 2025 at 09:28:01AM +0000, Aditya Garg wrote:
>>
>>
>>>> On 9 Mar 2025, at 2:46 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>>>
>>> On Sun, Mar 09, 2025 at 09:03:29AM +0000, Aditya Garg wrote:
>>>>
>>>>
>>>>>> On 9 Mar 2025, at 2:24 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>>>>>
>>>>> On Sun, Mar 09, 2025 at 08:40:31AM +0000, Aditya Garg wrote:
>>>>>> From: Paul Pawlowski <paul@xxxxxxxx>
>>>>>>
>>>>>> 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!
>
> thanks,
>
> greg k-h