 Hello everyone, so Today, I'm gonna talk about I3C First a few words about me. So I'm working at Bootlid, which some of you knew as predictorans We had to change our name because of legal issues, but We're really the same team of engineers working in the same company. Nothing has changed except the name so A few things about me in the community and the maintainer of the of the MTD subsystem and I worked a lot on ARM SSC support, so developing drivers or supporting platforms and so on Yeah, what we are really interested here is That I submitted RFC for the I3C subsystem So let's see what this is exactly So for the new I2C, I2C means Inter-integrated secret Actually the new I Which is what we are looking after means improved. So if it's improved, it's obviously better and Yeah, I think I'm done Okay, you don't seem You don't seem to be convinced Luckily, I had a few backup slides So let's have a look at what I 3c is exactly So I square C and SPI have been there for quite a long time it's been created invented in the 80s and They were fine. I mean we are using them all every day but still there are a Bit limited. So let's have a look at what they provide. So they both are relatively simple to implement. They both require limiting the amount of pins to connect a few devices That I square C is really slow and SPI is not that slow. Actually, you can have devices which support I Don't remember, but it's around 250 megahertz clocks but the downside of SPI is that for each new device you want to connect on bus you have to add a new chip select pin So it's not that cheap in terms of the number of pins you need to connect devices on and spy bus Both need extra pins to signal interrupts They don't support a plug. They don't support automatic discovery of devices on the bus so On I square C you can at least know if there is something on the bus, but you can't define what? Have I ever let this address and On I square C bus You have the address collision problem So if you have two devices two different devices you want to connect on the same bus You have to make sure that they have different addresses. Otherwise, there is a collision and the transaction won't work So what if we could overcome this limitation with a new protocol? And this is what I3C is here for so I Couldn't decide it Me pee the fact that the I3C standards is pushed and developed by me pee was a good thing or the bad thing So I left it here I let you decide But the good things about the protocol of that it addresses most of the problems we had with I square C and spy First thing you still need only two pins like I square C But now the protocol Supports what they call in band interrupts, which means if you want to signal interrupts You don't need you don't need to add an extra pin per device to do that It's already everything goes through the bus directly It provides higher throughput It's still not what would achieve with a spy bus, but Obviously better than what you have with I square C It's better in term of power management than I square C. Oh, that's Not that easy to determine, but it's the calculation based the calculation done by the me my BPL ions Was based on the per bit basis So it might happen that if you have a nice QC device Connected on my square space C bus it Will probably consume less than if it was connected to a nice and I3C bus That's it. It's a good thing And it supports all plug natively You can discover devices on the bus which is Much easier to support than having to declare all devices to keep statically in your firmware It support dynamic address and assignment, which means the devices no longer have their address assigned statically and One important thing in my opinion is that you have backward compatibility with I square C Which means on the I3C bus you can connect your old I square C devices Or most of them will see a bit later. That is not always the case and I'm not sure about the last one, but I guess this is what the plan to do in the ice I3C group I think the the plan to standardize the device profiles pretty much like what you have with USB classes So you say that you have such kind of device and then there is a command interface to control this device And you don't have to implement a driver for each new device Created by a new vendor So the downside with I3C is that it will Likely be harder to implement in your hardware than I square C was or SPI was So let's have a look at the protocol in more details The first thing you have to keep in mind is that I3C has been developed with backward compatibility in mind Why simply because all the I square C devices won't go away And we want to be able to support them And to support them we have two solutions either we have two buses one for the I square C devices one for the I3C devices Or we make sure that I3C buses are back work compatible with I square C devices And that that's what they decided to do simply because you want you You don't want to add two more pins to expose devices But backward compatibility goes the other way you want to I mean If you are a nice 3C device vendor, you want your device to work Indifferently on an I square C bus on or an I3C bus and that's why you Will like the Backward compatibility with I square C So that's also supported in the protocol. So let's have a look at the physical near or now as I said, it's really Similar to the I square C protocol and we have two lines the clock line the data line The data line is most of the time in open drain Mod with a pull up You have the same a star 3P to start stop act next sequence So these kind of things didn't change Still we have a few few things that have changed and one of them is that we no longer use we no longer Drive the clock in open drain. So let's see why if you have an a clock running at say 400 kHz and You have a line driven with open drain with a pull up You'll have a signal which looks like like that and the same signal driven in push pull So you see that the open drain one takes a bit more time to rise and to go over the logical I level So that's fine because the clock period is large enough to be able to detect when the level goes I and when it goes low But net then takes the same signal and put it at 12 MHz and you'd see that with the open drain with a pull up approach your signal will actually never rise fast enough to Go over the I level Logical I level and that's a problem because we want to be able to transmit things faster on the bus so we have to move to push pull in order to increase the clock frequency But when doing that we break a bit of the backward compatibility For example devices which are doing clock stretching So clock stretching is about retaining the clock law so that the master can't send the next bit of data because the slave is Too slow to handle more data Then that's no longer supported with I should see Also SDA is still most of the time in open drain except when you want to do high speed transfers In this case for the very much reason you have to switch in push pull because you want your signal to raise To rise fast enough to to be able to detect the change And then the last thing that changes that they added new modes of transmission So you what they call either rate mods and then you have several submods So you can use either DDR which means you are transmitting things on both clocks on both edges of the clock or you can turn a bit turn a base mod where you Encode things using the two signals So each transition is in is encoded using SDA and SCL not only SDA So I said that we want to use push pull to be able to achieve higher throughput But that's not simple. I mean I square C has been designed to use open drain with a probe and There are several reasons for that The first one is that it's simpler to implement The second one is that It helps when several devices on the bus have to take control of the bus If you use an open drain with pull-up approach, that means that the default state is High level and when someone wants to drive the line low Then it drives the line low bet if two devices There there is never two devices which drive one devices drive the line low and the other one Divide the other one drive the line high which would then be a problem So We still have to support those devices which want to To use open drain sometime So for us the clock line that means that of course we can do clock stretching and also we can't have multi-buster so That means that For the SDA line There are some phases where You'll want the slave device to control the data line Which means in this case you have to switch from push-pull to open drain and actually the I3C master controller is doing that Dynamically so depending on where it is in this state machine It will decide to drive the line in push-pull or switch to open drain to let the slave device control the line That's all you can make sure I squished devices still work fine on I3C basis So what about performances When you run the clock at 12 megahertz You are about You are at about 1.4 megabyte per second But then you have another problem. I mean I squished devices have not been Developed to support such high-speed clock. They usually run or some of them might support that but at least it's not always the case So we have to make sure that Devices on the I3C devices on the bus still work correctly The first solution is to slow down everything. So slow the clock down Or we can find a solution to make the I squished devices think that the clock signal stays low and that's what the I3C I3C protocol is doing so instead of having a symmetric clock signal Where the low period is equal to the high period you have? clock signal which is a symmetric with the High period which is below 15 nanosecond and the high period which the low period which can be extended and Because some devices embed Spike filters so they detect that the signal was not maintained more than 50 nanosecond Then what they see on the bus is just a low level and nothing more And thanks to that You can achieve better performance than if you drive the wall clock signal at the lower rates So of course you're not you're not achieving the full performance because you're not running the clock at 12.5 megahertz, but it's still better than Slowing the wall bus at the slowest device rate So let's sum up a nice 3C bus can be in three different Configuration you can have the pure bus Configuration which in which case you only have I3C devices connected on it the clock signal runs at 12.5 megahertz you can support all high data rate modes and Of course, this is what you'll want to use But sometimes you have to put I2C devices on the bus and in this case you have two sub cases the fast bus mode mixed fast bus mode, which means all the devices on all the I2C devices on the bus contains and Spike filter and then you can use the trick we've just seen or Some of the devices on the bus don't contain the spike filter and in this case you have to run the clock at the lowest rates Supported by the I2C devices So obviously the last case is you don't want to end up in this case because in this case I3C is pretty much useless So let's switch to addressing scheme We've seen the physical layer now. How can we address devices in I3C? well, it's all It's also pretty similar to I2C. You have seven bit addresses Devices are expected to hack or knock the transaction and Still there are a few differences. The first one is that Devices are no longer statically assigned their addresses. So the master decide Which address will be assigned to the device and then that means you don't have any collision That's that's a good thing. The second thing is that there is a broadcast broadcast address And with this broadcast address, we will be able to address all the devices on the bus at the same time So that's also a new thing And of course this address has been picked in the reserve range of the I2C protocol So that you're sure that no I2C device should have this exact address So let's sum up what we've found about I2C backward compatibility Obviously the fire and Mac layer have been designed to be backward compatible with I2C But still that's not enough For example, you won't be able to connect slaves Which are doing clock stretching because that's completely forbidden in I3C If you have I2C devices, you might be able to connect them to the bus But remember that if you if they don't have spike filters, then the performance will be really low and obviously, you don't you don't want that and Also, you have to remember that some of the IDAT rate modes are not usable when Some devices some I2C devices are present on the bus So it's backward compatible but still has some drawbacks So we've seen the addressing and physical layer now let's see The functional differences between I3C and I2C which is what most developers software developers are interested in So what are the I2C and I3C physical and addressing layer were pretty similar From a functional point of view I2C and I3C are really different for example As I said several times Addresses are not statically assigned, but now they are dynamically assigned by the master But one of the most interesting point here is that all devices on the bus can be discovered and you'll no longer Have to describe them statically in your device tree or or a new bot file or or whatever Also devices are self-descriptive that means that when you discover something on the bus you will know exactly which device this is and You will be able to easily attach the device to a specific driver and Linux Some masters and slaves can support outplug so that's not mandatory, but I guess most of them will support that and of course because of the Functional differences that means that this management is likely to be more Complicated than with I2C. So we'll see a bit later how to control the bus how to assign addresses But of course, it's it's a bit more complicated in the than what you have with I2C And the last thing is that you have different transactions so the first type of transaction will look at is the CCC transaction which is meaning common common codes so these are all the Stand our comments. We will use to manage the bus So thanks to that you will be able to discover all devices on the bus You will be able to query information about the device each device And you will be able to keep the bus in a consistent state And they also plan to use those generic commands to do generic operation That means operation which are not tied to a specific kind of device Let's have a look at what this kind of frame looks like. You will have an 8-bit opcode the most significant bit in this opcode will encode the whether this is broadcast or unicast command and The seven bits will Encode the actual action that will be sent to the device You can have a payroll attached to a command CCC So the payroll in case this is the unicast command the first byte of the payroll will contain the device address and Then after that you have Real data that are passed to the command So just a few examples of commands that you will be able to send the first one is Start the DAA also DAA is for stands for a dynamic address assignment. And this is basically the auto discovery procedure You have enter activity state X So X is just a number and this is about and Managing for a management so asking a device to enter a lower state for example Then you have all Comments which are used to retrieve information about the device so get PID Get VCR get DCR. So PID is the unique Identifier of the device a boost characteristic is about what the device supports in terms of transfer types and at which speed and Then the device characteristic is about Classifying the devices So let's have a look at one of these comments Which is in my opinion the most important one and this is the one you will use when you Initialize the best to discover everything that is connecting other than the best. So this command is called MdAA for enter DAA which stands for dynamic address assignment And To do that the master will actually send a command and then emit emit directly after that repeated start and Then after after each repeated start all devices all I3C devices on the bus will emit the their PID VCR and DCR Information While they do that while all slaves do that they have to monitor the state of the SDA line and Every time the state of the SDA line is not what they Intend to emit that means they lost the arbitration and that means they have to stop emitting things on the bus and The last device that is remaining emitting something on the bus That means it wins the arbitration and the master will then Assign it an address. So if we Just look at Standard and the a procedure the master starts emitting and the a which Forces all devices on the bus to enter a specific state then it emits a repeated start We have two devices on this bus they both emit their PID DCR and VCR at the same time except that only slave one wins arbitration Then slave two are has to be has to stay silent until the next repeated start the I3C master assign an address to slave one Which is now able to communicate on the bus and then emit a new repeated start then same thing with slave two Which now is able to receive a new address and you add up with a repeated start Which is followed by no one hacking the transaction, which means the discovery procedure is done and the bus is Operational so that's it. So let's have a look at those information which are transmitted during DAA the PID is what we will use when trying to Determine which driver which will be connected to the device When the PID you will find the manufacturer ID the part ID An instance ID in case you want to put several devices of the same type on the same bus So usually this instance ID is controlled with external switches or directly using the pins of the of the device And you have extreme permission which I actually don't know what they are Used for but this is something that vendors can put specific data in to differentiate the devices You also have BCR, which is incurring what the devices capable of So is the devices is the device capable of sending interrupts is a device capable of supporting ID rate modes What is the maximum? transfer speed and and so on And the last thing is that is the DCR, which is encoding the device type. So Ideas here are supposed to be standardized by the MIPI Alliance and they are But yet I don't see what they're meaningful for because there is still no Common interface for each type which means you know what kind of device this is but you don't know how to interact with it You don't know what to query information and so on So right now, it's just Informational and you can't use that to to implement a generic driver, which is able to handle all kind of devices of this Another kind of transaction is as You are transfers or private transfers So there are meant to replace ice-query C transfers Except that this time they are using the full speed mode so clock running at hopefully 1212 megahertz And there is no standard to say which kind of information or send to the device So it's completely free and devices are able to implement what they want and and all they like So it's basically what we see with ice-query C already Then we have HDR transfers which are used to Achieve even higher data rates So we have three different modes The DDR mode is obviously one where you will transmit data on both edges of the clock And then you have determined turn any modes which are used to encode data using the two The clock and the data signals But it's a bit complicated to see how to encode data with both SEL and SDA, but that that works and You have two of them actually because depending on whether they are ice-query C devices on the bus or not You may have to ensure that the low the high period is lower than 15 nanoseconds because of the spike filtering and all the stuff we've seen before The data you transmit using HDR Transfers are a bit more standardized than the SDR SDR transfers So you have to first emit a 16-bit word which contains a command code and then again There is a range with their for generic command code So hopefully it was we should see soon some generic commands which will be used by the ice-query C specification and some vendor specific commands, which will be useful for vendor specific drivers Last thing we want to talk about here is invent interrupts So how to avoid having to add a new a new signal to signal interrupts So what does that work? Basically all devices on the bus all ice-query C devices on the bus are able to Take control of the bus temporarily to just send the IBI and The master which is in control of the bus Well, either act or knack the IBI, but once he has knack the ABI the IBI This will have to Retrieve the payload and to determine which device wins when an IBI is generated generated There is the address arbitration Which means the lowest the lower the device address the higher the priority so that means You have to carefully choose the dynamic address assigned to each device because this encodes the priority of the Interim generation on the bus odd join it's Basically what we call odd plug for other protocols It's pretty much the same as IBI when a device is connected on the bus and it will it has It still has no dynamic address It's able to send an interrupt saying that it wants to Join the bus and then the master will be able to act or knack this request And if the master and acts the request then they asked you assign a dynamic address And as we've seen before assigning a dynamic address is about entering DAA. So Yeah, that's all a joint work and the last thing we'll see here is multimaster capabilities so I3C is supporting multimaster natively That means that you'll be able to have so masters on the same bus Unlike What we had with I2C where all masters were able to take control of the bus at the same time It's a negotiation between the masters to know to know which one of them is controlling the bus So you have two type of I3C masters the main master which is responsible for initializing the bus and the secondary master which is Acting as slave at first and then when it needs to emit Frame on the bus then it will have to negotiate with the current master to gain ownership of the bus So that's a bit more complicated than what we had with I2C And of course bus on F ship can be requested by an inactive master which wants to take control of the bus Or it can also be requested by the active master when he wants to Go sleep for example, and he wants someone else to end all the bus. That's that's a two-way thing So these are just Introduction these are just a piece of him information about I3C and obviously I omitted a lot of things So if you want to know more you can go check the I3C specification which is for once Open but that's not usual for me P stuff, but that's a good thing actually And yeah You can go check it So let's see how we plan to support that in Linux. So that's basically what has been proposed in in the RFC So if you go back a bit, you remember that I3C is a bit tricky to categorize because It's back one compatible with I2C device still it's a lot different functionally from And link I3C devices is a lot different from handling I2C device So we have to keep the existing I2C ecosystem working without changing anything But we want to add support for new I3C function like this And to do that we add two options. The first one is extending the I2C framework to add I3C features the second one is to Add a new framework and then connect it to the I2C framework. So we went for option two And that's basically what we have So on the bottom of the diagram you see the hardware stuff And you see two buses one I3C bus one I2C bus Those buses are exposed to Linux through their controller which are then connected to the I2C or I3C framework and if you if you go look at the devices which are connected on both bus You'll see that they are Then connected to their appropriate driver. So if you go look at the yellow device The I3C device in yellow You'll see that it's directly connected to the driver that was registered to the I3C framework You can also have I2C devices connected to the I3C bus So this is the purple one and in this case it will be connected to the I2C framework Going through the I3C framework. So we are basically using the same infrastructure Which means if you add an I2C driver It will work the same way it used to work even if the device is connected on an I3C bus That's that's supported Now we have More complicated case cases. For example, we said that some devices are Compatible with both I2C and I3C and in this case You want the device to be discovered when it's connected on the I2C bus and you want it to be Discovered when it's connected on an I3C bus and you want the same device to be connected to Those the bus device both devices to be connected to the same driver. So you had to add a way to register single driver to both framework and that's what we did. We have a new macro which has evolved to Register a device a driver in both subsystems so that you have a single driver Which has evolved to handle the device which is operating in I2C mode and the same device Which is operating in I3C mode. So a few more words about the design choices First thing is that we separated the API for device driver and master controller drivers that's mainly to ease Implementation of both kind of drivers So people don't have to guess How is this an API for the controller part or is this an API for the device driver part? Everything is separated in two places in two different places. So that's that's good One other important thing is that Even though we have a single bus, which is the I3C bus When you look in CcFS you'll see Two buses represented the I2C one and the I3C one and this is Mainly because we didn't want to break the I2C Ecosystem so we have to keep everything working as before But still those buses are the same thing and they are usually connected through the parenting of So the bus is declared By a specific controller and when you look at the controller, you will be able to connect the I2C bus to the I3C bus And then how do we bind devices to specific drivers We are basically using the DCR and PID values so PID is encoding the manufacturer and Part ID and DCR is encoding the class of the device So we use that to connect a specific device to a driver and the last thing that is to That is important to note is that IBIs are not exposed as regular IAQs simply because most of the time They do not look like regular IAQs. You have payloads which are added to the interrupt and You also want to send messages on the bus after that and we'll see that it's not really possible in an atomic context So we decided to just simplify things and and treat them as not regular IAQs So let's have a look at the device driver API first It's exposed in Linux I3C device.h and you'll be able to declare a driver register it You'll be able to send SDR-HDR transfers and you'll be able you'll you're not be able you're not able to To send CC commands yet because as I said, it's mainly here to manage the bus And I don't think it's needed for device drivers But if it appears it appears to be needed at some point and we will probably change that And you will of course be able to register IBI on LERS and activate the IBIs So let's have a look at the device driver declaration That's pretty much the same thing you have for any kind of driver. You have a pro function and remove function a table of device ID which are used to bind devices to drivers and That's all then you call you declare your driver structure And you call module I3C driver and it registers the driver to the I3C framework So nothing new here The same thing goes for the SDR transfers. So It's pretty simple It looks like the things you've you've been using with I3C So you declare a table of transfers whether these are reads or writes and Then you send the transfers to the device And pretty much the same for HDR transfers except that now you'll have to specify a specific Upcode and the mod you want to send The one the mod you want to use to send this transfer Nothing really complicated IBI is a bit more complicated So you'll have to first declare an IBI handler and This IBI handler is called from a non-atomic context. So you can Send a new message in this IBI handler and when you request an IBI an IBI you will have to specify the max payload size So normally this is defined in the data sheet of the device And then you have to define the maximum number of slots allocated to this IBI This is mainly useful because since you you're not only that in interrupt in Atomic context and the interrupt context That means that you may have several IBIs queued In the device before the device before the walk you actually call the IBI handler So if you're not using If you're not reserving enough slots you might lose some IBI Maybe that's not such a good idea to do that But that's what we come we came up with to to address the problem and Then once you have requested the IBI is that means all resources needed for these IBI have been allocated You can enable the IBI and in your removal layer you can disable the IBI and free the IBI resources Now the master controller API so it's The interface which you're supposed to implement when you want to support to to declare a new master is Not that big and it leaves a lot of freedom to the controller driver and I did that because actually the I only worked on one of them and I'm not sure exactly where Which part are really common to everyone and which parts are specific to the one I worked on So instead of adding a lot of logic in the in the core right now I decided to put a lot of logic in in the controller driver Basically what the controller drivers will have to do is initialize the bus and initializing the bus is quite vague So It will have to declare all the devices which are statically defined. That means all I square C devices You also have some I 3c devices which can be statically defined So again, you will have to declare them in the controller and then once this is done You will start a DAA to discover all the devices on the bus And you will then declare all the devices you've discovered on the bus to the framework So that's basically what you'll have to do when you initial is initializing the bus Then you will also have to provide some methods to send all kind of transfers So you have one for private transfers HDR comments and CCC comments and also one for I square C transfers For CCC command you can you have a support CCC command which which is Used to check that the CCC command is supported because not all CCC commands are mandatory So your controller may support or are not a specific command and the important thing is here is that all Those hooks are working in a synchronous manner. That means when you call this function you and this function returns that means that the the transaction on the bus is done and You don't have to wait for a call back to be called or or things like that. Everything is synchronous IBI's So pretty much the same function you add in the API in device driver API except that here you have to implement them So request API IBI fee IBI enable IBI disable IBI. So that's pretty obvious There is one more which is here to recycle a slot that was used to store a payload of an ABI and Yes, again, one of the important designs choice we made was to Execute IBI alerts in non atomic context so in the work you can text and Because the other Transfers are done in a synchronous manner. That means that from the IBI and learn you are able to send a new something new on the bus Still if you can't avoid it You should avoid it because there is one more if you pair controller That means that if you send something on the bus you block every other IBI and learn So maybe we'll have to rework that a bit to to make it a bit scalable a bit more scalable And yeah, the IBI slot have been allocated ahead of time That means that if the IBI device driver is not dequeuing the IBI fast enough it will lose some of the IBI's Adjoin again not a lot of facility in the framework because I'm not sure how other controllers will handle that so It's basically an interrupt to you will receive from the controller And you will have to when you receive that you will have to trigger a new DAA so Really nothing else we can expose here So that's basically all we've done The status is that we have submitted two versions of the RFC Everything that I just described in the slides have been tested and implemented The only problem right now or the the problem we had before was that we didn't have any real device So we were using a dummy slave device, which we were more or less controlling that then that that was a problem and The next version should have a real device driver for a GPIO expander, so should be able to use All of the API I've been exposing in the device.h file That's it Not much time for questions Let's let's go. Okay. So the question is what if we all and it what if we have in an identical parts connected on the same bus, right? Yeah, so there is an instance ID here Well, there is an instance ID. So so you can By controlling some some of the pins of the device we can assign a specific instance ID Which will provide a different PID which then means that you will be assigned a different address Dynamic address. So that that works that support it. Yeah So it will likely have to be configured a bit differently in our rare Whether it's with switches or by connecting pins to different levels So how much sure is the hot plug support because that looks very handy for making smart peripherals? How much sorry how much sure is a heart plug hot plug support? How much sure is that like is there other devices I can get out there for example and embedded I think the The specification does not Say anything about how to plug devices physically on the bus that's not defined at all now for the So how to generate an interrupt you signal and odd join event. This is really I think it's it's mature enough But how would you actually plug a device and not disturb all those devices on the bus is not Deal to is and in the spec unfortunately So about that So the MIPI group is defining the spec right it is totally free of licensing and stuff like that Okay, so then my question comes who is Assigning and defending VIDs and PIDs because like that's part of the reason you pay in the USB Is so that those are defined and no one else clobbers over your Actually, I don't have the answer, but I guess this is MIPI will we will assign Manufacturer IDs at least okay, and then so finally on that about the hot plug question So that's not to find what triggers that at all so Like in the case of an I squared C you have it's very common to have I squared C muxes And so I'm wondering like in a mux case. How do you say okay? I've switched to the other branch of the mux I need to go hot plug these new devices in again. It's not specified in the specification. So so it's up to the device manufacturer to decide how to Trigger the odd joint event. Yeah How this compares to USB because I'm thinking about you know to data lines you have Hotplug you have device recognition. It's much slower than USB for for sure and it's also It has better energy efficiency than USB it's ready for small embedded devices And it's it's about energy saving. So it's Couldn't be replaced by It's just a sort of a follow-up on that are you expecting sort of a common device driver for peripherals to start coming out I mean it seems like right now with this concept drivers You're gonna need redundant drivers being implemented for all peripherals to maintain backwards compatibility and some of that could be alleviated if there are Common drivers, I mean like CDC that you find yeah Actually until they define a common interface for a specific kind of device It's not possible. So So we need to wait for them to standardize things And I can't tell if it will even happen. It's it's not yet decided. I think So another hot plug question one of the things that's caused a lot of hassle for Some of the other mippy buses with their hot plug support is what happens if you Have a device you want to put into very low power mode by physically removing its power It then rematerializes on the bus re-numerates yeah, and the The bus core has then got a workout that actually this was this is a device already know about yeah It's not supported yet at least in not in the v2 of the RFC, but I'm working on that So I'm working on trying to figure out. Oh, this is a new device. Okay. I assigned a new address But actually a new device So I shouldn't create a new one a newest instance in Linux and I should instead update the address instead of creating a new device So that's things. I'm I'm working on Hopefully it should be supported Correctly thanks Yeah, so the question is when do I expect to see actual devices I really don't know Okay, thanks. Thanks a lot