[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PN3PR01MB95970E60B250F91CA8E12720B8D72@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
Date: Sun, 9 Mar 2025 09:52:43 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "joro@...tes.org"
<joro@...tes.org>, "will@...nel.org" <will@...nel.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>,
"linux-staging@...ts.linux.dev" <linux-staging@...ts.linux.dev>, Linux Kernel
Mailing List <linux-kernel@...r.kernel.org>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
Aun-Ali Zaidi <admin@...eit.net>, "paul@...rm.io" <paul@...rm.io>, Orlando
Chamberlain <orlandoch.dev@...il.com>
Subject: Re: [PATCH RFC] staging: Add driver to communicate with the T2
Security Chip
> On 9 Mar 2025, at 3:21 PM, gregkh@...uxfoundation.org wrote:
>
> On Sun, Mar 09, 2025 at 09:41:29AM +0000, Aditya Garg wrote:
>>
>>
>>>> On 9 Mar 2025, at 3:09 PM, gregkh@...uxfoundation.org wrote:
>>>
>>> On Sun, Mar 09, 2025 at 09:28:01AM +0000, Aditya Garg wrote:
>>>>
>>>>
>>>>>> On 9 Mar 2025, at 2:46 PM, gregkh@...uxfoundation.org wrote:
>>>>>
>>>>> On Sun, Mar 09, 2025 at 09:03:29AM +0000, Aditya Garg wrote:
>>>>>>
>>>>>>
>>>>>>>> On 9 Mar 2025, at 2:24 PM, gregkh@...uxfoundation.org wrote:
>>>>>>>
>>>>>>> On Sun, Mar 09, 2025 at 08:40:31AM +0000, Aditya Garg wrote:
>>>>>>>> From: Paul Pawlowski <paul@...rm.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?
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists