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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Mar 09, 2025 at 09:52:43AM +0000, Aditya Garg wrote:
> 
> 
> > On 9 Mar 2025, at 3:21 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> > 
> > On Sun, Mar 09, 2025 at 09:41:29AM +0000, Aditya Garg wrote:
> >> 
> >> 
> >>>> 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!
> > 
> > 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.




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux