WEBVTT 00:00.000 --> 00:17.000 Okay. Hello, my name is Bartos Gileshevsky. I'm based in France. I'm originally from Poland, 00:17.000 --> 00:23.000 and I have been working in the embedded Linux space for 16 years, actually, in 15. I maintain 00:23.000 --> 00:29.000 the GPIO subsystem and Linux kernel, and the new power sequencing subsystem, and also the counterpart 00:29.000 --> 00:36.000 in user space for the GPIO subsystem, which is LiPGPAD. I also contribute to many other open source projects, 00:36.000 --> 00:43.000 and I have a weird hobby of jumping out of perfectly good airplane for fun. I'm here on behalf of Flenaro. 00:43.000 --> 00:52.000 Check us out. We make Linux, I'm running well on ARM. I'm personally in the Qualcomm landing team, 00:52.000 --> 00:58.000 and this has been what I've been doing professionally for the last couple of years. 00:58.000 --> 01:06.000 And today, I'm going to be talking about GPIO and the system class. 01:06.000 --> 01:18.000 So over the course of the last years, I've given several talks about LiPGPAD, and about how I would prefer to remove 01:18.000 --> 01:23.000 the old legacy SSFS class from the kernel, and why the collector device is better. 01:23.000 --> 01:31.000 And I've been asked several times why we want to remove SSFS, like what's wrong, it's been around for so many years. 01:31.000 --> 01:43.000 It's useful. Why do you hate it? And the answer to this is I don't only hate SSFS, there is a deeper problem to it. 01:43.000 --> 01:51.000 It is a bad interface, and it cannot really be improved now, that has been covered in stone for many years. 01:51.000 --> 02:01.000 But the problem is just much more complex. So GPIO lib, the kernel subsystem for GPIO, has been around for a very long time, 02:01.000 --> 02:09.000 and it has a problem with craft. It has accumulated a lot of unnecessary things. 02:09.000 --> 02:16.000 And I've talked about it in detail during my talk last year, or was it years ago not sure. 02:16.000 --> 02:23.000 So what's the problem? We, GPIO lib, has been around for two decades. 02:23.000 --> 02:29.000 That means that it has been created way before we even had a driver model in the kernel. 02:29.000 --> 02:37.000 And it has been modified and improved by many people, had several maintainers. 02:37.000 --> 02:44.000 And the main users for a long time for GPIO lib were ARM and MIPS in the dark times of board files. 02:44.000 --> 02:52.000 This is when the entire driver model, it wasn't even there, was very fragmented. 02:52.000 --> 02:57.000 The drivers would be implemented at Hawke in other arch in board files. 02:57.000 --> 03:01.000 This has caused a lot of things being implemented. 03:01.000 --> 03:05.000 It just caused a lot of bad engineering but program. 03:05.000 --> 03:14.000 And what we ended up with now is, we have two interfaces in the kernel for using GPIOs. 03:14.000 --> 03:21.000 We have the modern one, which is descriptors, opaque structures, which you get assigned in femur and dtore, 03:21.000 --> 03:27.000 a CPI, and then relevant drivers can retrieve their GPIOs and use them. 03:27.000 --> 03:36.000 And legacy numbers, space, base system, where you basically have magic numbers and you request GPIO 42 for no reason. 03:36.000 --> 03:41.000 There's nothing to do with hardware offsets of controllers. 03:42.000 --> 03:46.000 So, yeah, as I said, many people have tried to improve it. 03:46.000 --> 03:51.000 We have made a lot of advancements recently. 03:51.000 --> 03:57.000 We now support, for instance, hot pluggable USB chips, which wasn't the case before. 03:57.000 --> 04:01.000 But still, we are stuck with these two interfaces. 04:01.000 --> 04:06.000 So, why actually would I want to remove the global number space that legacy interface from the kernel? 04:06.000 --> 04:11.000 So, first of all, having two interfaces for doing the same thing is just bad programming. 04:11.000 --> 04:15.000 So, that alone would lead to a lot of code and duplication. 04:15.000 --> 04:19.000 But also, the legacy interface is just that. 04:19.000 --> 04:25.000 So, first of all, magic numbers, it allows basically any driver to fetch any GPIO that it wants, 04:25.000 --> 04:30.000 even if, you know, nobody said that it's allowed to. 04:31.000 --> 04:37.000 There are many drivers still in the kernel, which use a hard code that base GPIO number. 04:37.000 --> 04:43.000 Because if you have several controllers and they come up different times, the probe ordering can change, 04:43.000 --> 04:46.000 and then the numbers will not be the same. 04:46.000 --> 04:48.000 They will not be what you expect. 04:48.000 --> 04:53.000 So, this is what led to people to just hard code the base number in their GPIO drivers. 04:53.000 --> 04:56.000 And again, that's not unnecessary. 04:56.000 --> 05:01.000 If you use a proper descriptor-based interface. 05:01.000 --> 05:11.000 And finally, since I do maintain that subsystem, I have a personal interest in reducing the maintainer, maintainer ship burden. 05:11.000 --> 05:20.000 What do I? First of all, in the kernel, in the kernel, we still have drivers that use the old interface. 05:20.000 --> 05:24.000 Because that is not a hard problem. 05:24.000 --> 05:30.000 Basically, it's about converting drivers using old interface to using the new one. 05:30.000 --> 05:34.000 We don't have to care about out of three drivers. 05:34.000 --> 05:38.000 That's a them problem and not our problem. 05:38.000 --> 05:44.000 So, if we convert every internal user to the new interface, we can drop the old interface. 05:45.000 --> 05:47.000 It's just that it's very tedious. 05:47.000 --> 05:53.000 It's a task that is not simple enough for kernel janitors to tackle, 05:53.000 --> 05:59.000 but it's not very interesting for advanced developers who want to do something fun. 05:59.000 --> 06:03.000 But as I said, this is not a hard problem. The hard problem is just past GPIO. 06:03.000 --> 06:09.000 So, it's a major user of the legacy interface, but not in the way you think, 06:09.000 --> 06:13.000 it actually uses the new descriptor based interface. 06:13.000 --> 06:17.000 But the user space refers to GPIOs using the global number space. 06:17.000 --> 06:22.000 So, we have to translate the numbers that we get from users' space to the descriptors, 06:22.000 --> 06:25.000 and this is how we do it in the kernel. 06:25.000 --> 06:30.000 This is a hard problem because we advertise the kernel, 06:30.000 --> 06:33.000 UAPI, as indefinitely stable. 06:33.000 --> 06:38.000 So, we cannot, as far as long as users want to keep using this interface, we are stuck with it. 06:38.000 --> 06:42.000 And CISPAS GPIO also has issues. 06:42.000 --> 06:47.000 First of all, just the same problem as for the legacy kernel interface. 06:47.000 --> 06:53.000 It's very brittle if you have shell scripts that refer to some random magic numbers, 06:53.000 --> 06:58.000 like 120, for a given GPIO, and then you have drivers that will come up, 06:58.000 --> 07:03.000 get probed in a different order and the numbers don't mean anything anymore. 07:03.000 --> 07:09.000 You can, of course, scan the labels and then calculate the offset from the base number 07:09.000 --> 07:17.000 and the offset of the GPIO, but that's rather unnecessary calculation in your script. 07:17.000 --> 07:21.000 It's quite feature poor compared to the character device, 07:21.000 --> 07:23.000 which I will focus in a second. 07:23.000 --> 07:25.000 It doesn't admit many, many things. 07:25.000 --> 07:31.000 And the polling for interrupts is quite unreliable, 07:31.000 --> 07:35.000 because it's not a buffer, you just get an notification about an event 07:35.000 --> 07:40.000 and then you have to read it very fast, but if you get enough events in a given time span, 07:40.000 --> 07:43.000 you will not be able to read all of them so you can lose them. 07:43.000 --> 07:48.000 And yeah, so there has been an API in consistency in CISPAS, 07:48.000 --> 07:51.000 that nobody noticed and I just recently realized. 07:51.000 --> 07:56.000 So back in the days of the board files, if you exported a named GPIO, 07:56.000 --> 07:59.000 the link to it in CISPAS would appear as its name, 07:59.000 --> 08:02.000 but for DT-based system, device-driven based system, 08:02.000 --> 08:04.000 that's no longer the case. That was a big change, 08:04.000 --> 08:06.000 and nobody ever noticed. 08:06.000 --> 08:09.000 I just realized when I was working on it on the thing recently, 08:09.000 --> 08:11.000 and that got fixed. 08:11.000 --> 08:15.000 I will give credit where it's due though, 08:15.000 --> 08:20.000 and using the virtual file system actually is quite useful 08:20.000 --> 08:23.000 for fine-grained permission control. 08:23.000 --> 08:28.000 If that's what you are about, give a user permission to access 08:28.000 --> 08:32.000 just this one GPIO line, and that's what you can easily 08:32.000 --> 08:35.000 achieve using the file system. 08:35.000 --> 08:40.000 And also, the CISPAS GPIO works kind of like a centralized authority 08:40.000 --> 08:45.000 for all GPIOs just that it's implemented in the kernel. 08:45.000 --> 08:54.000 So as a maintainer, my long-term goal is to remove CISPAS GPIO from the kernel entirely, 08:55.000 --> 09:01.000 but, unfortunately, I have to first get everyone to stop using it. 09:01.000 --> 09:08.000 And so a quick note on kernel interfaces. 09:08.000 --> 09:11.000 It wouldn't be the first time that the kernel interface gets removed. 09:11.000 --> 09:13.000 So it is true that we're saying, 09:13.000 --> 09:16.000 okay, once it's carved in stone, it's ABI, 09:16.000 --> 09:18.000 we will support it indefinitely, 09:18.000 --> 09:23.000 but history knows at least a couple instances of removing existing kernel interfaces. 09:23.000 --> 09:26.000 So there was a CISP control system call, 09:26.000 --> 09:29.000 which was buggy, had problems with buffer overflows, 09:29.000 --> 09:30.000 and eventually it was removed. 09:30.000 --> 09:32.000 There was a safe death team, 09:32.000 --> 09:36.000 which was a special device providing access to kernel memory. 09:36.000 --> 09:39.000 It also got removed, there was dev raw. 09:39.000 --> 09:41.000 Also, some CISPAS classes. 09:41.000 --> 09:44.000 So there was an RTC class under class MISC. 09:44.000 --> 09:48.000 That was moved to class RTC and reward. 09:48.000 --> 09:51.000 So it wouldn't be the first time that an interface 09:52.000 --> 09:55.000 from CISPAS would be dropped. 09:55.000 --> 09:58.000 But the truth is that if user space objects 09:58.000 --> 10:00.000 to any such backwards incompatible changes, 10:00.000 --> 10:03.000 then we must not remove them. 10:03.000 --> 10:06.000 And unless the interface is harmful, buggy, 10:06.000 --> 10:08.000 but this is not the case here. 10:12.000 --> 10:14.000 Yeah, so where are we at? 10:14.000 --> 10:17.000 Unfortunately, we are not close yet. 10:17.000 --> 10:19.000 And the problem is that I cannot really 10:19.000 --> 10:21.000 don't trump my way out of it, 10:21.000 --> 10:23.000 and impose tariffs on CISPAS. 10:23.000 --> 10:27.000 So I have to go the good way. 10:27.000 --> 10:31.000 And just propose a set of alternatives. 10:31.000 --> 10:35.000 So the most of this one is the character device, 10:35.000 --> 10:38.000 which has been around for almost a year now. 10:38.000 --> 10:41.000 And unfortunately, if you tell users that they have 10:41.000 --> 10:45.000 to drop their neat shell scripts that just write to files 10:45.000 --> 10:49.000 and use custom C code that calls 10:49.000 --> 10:51.000 include CUAPI, kernel headers, 10:51.000 --> 10:54.000 and calls various system calls. 10:54.000 --> 10:58.000 I octose, then the reaction will be quite predictable. 10:58.000 --> 11:04.000 But, well, users want something that works simply simply. 11:04.000 --> 11:06.000 This is why we provide it. 11:06.000 --> 11:09.000 Logically at the set of command line GPIO tools. 11:09.000 --> 11:13.000 So Logically, it is a C library that wraps the kernel interface 11:13.000 --> 11:16.000 better in a better higher level API. 11:16.000 --> 11:19.000 We have bindings to Python, Rust, C++, 11:19.000 --> 11:21.000 G object bindings as well. 11:21.000 --> 11:24.000 And of course, command line tools. 11:24.000 --> 11:28.000 However, the character device inherently works with 11:28.000 --> 11:32.000 file descriptors and file descriptors in unique systems. 11:32.000 --> 11:36.000 When the last process that holds a reference 11:36.000 --> 11:38.000 to a given file descriptor exits, 11:38.000 --> 11:41.000 all the file descriptor file is closed. 11:41.000 --> 11:44.000 And that has caused a lot of confusion for people that 11:44.000 --> 11:49.000 were used to CFS because they realize very fast that 11:49.000 --> 11:53.000 the state of a GPIO is not guaranteed when GPIO set 11:53.000 --> 11:58.000 the program that sets a GPIO value exits. 11:58.000 --> 12:01.000 Because anyone can grab it or even the driver can implement 12:01.000 --> 12:03.000 some default state to which the line reverts. 12:03.000 --> 12:08.000 And people naturally instinctively assume that 12:08.000 --> 12:12.000 GPIO set this GPIO to act if we will make it 12:12.000 --> 12:17.000 state that way, but that's not the case. 12:17.000 --> 12:20.000 So I realize at some point that users do really 12:20.000 --> 12:24.000 want this state persistence exactly what CFS does. 12:24.000 --> 12:27.000 And I really like a fraction layers, 12:27.000 --> 12:29.000 because there is no such problem that cannot be fixed with 12:29.000 --> 12:31.000 another fraction layer. 12:31.000 --> 12:34.000 And I created this thing called GPIO manager. 12:34.000 --> 12:37.000 This is a demon that runs in the background and exposes 12:37.000 --> 12:41.000 the class interface with which you can interact using either 12:41.000 --> 12:46.000 the provided GPIO client or whatever library for 12:46.000 --> 12:47.000 DBS that you want to use. 12:47.000 --> 12:51.000 I presented it in detail during a talk last year. 12:51.000 --> 12:56.000 And what it allows you now is to simply do GPIO 12:56.000 --> 12:59.000 CLI request a line. 12:59.000 --> 13:02.000 And then I'm actually, this slide is wrong. 13:02.000 --> 13:05.000 This should be GPIO CLI set GPIO CLI get, 13:05.000 --> 13:07.000 but sorry for that. 13:07.000 --> 13:10.000 Basically, you request it and the line stays requested 13:10.000 --> 13:14.000 because it's the demon that is responsible for holding it. 13:14.000 --> 13:15.000 And then you can set it stay. 13:15.000 --> 13:17.000 The demon retains it. 13:17.000 --> 13:22.000 And then you can free it when you see it. 13:22.000 --> 13:25.000 The problem is that people still, well, it has seen 13:25.000 --> 13:26.000 some adoption. 13:26.000 --> 13:28.000 I've integrated it in meta-open embedded. 13:28.000 --> 13:30.000 I've had people report back to me. 13:30.000 --> 13:32.000 I think someone started packaging it. 13:32.000 --> 13:34.000 I'm not sure. 13:34.000 --> 13:36.000 But there was some package maintenance 13:36.000 --> 13:39.000 that reached out to me with questions. 13:39.000 --> 13:41.000 But immediately, like, for instance, 13:41.000 --> 13:44.000 after presenting GPIO manager last year, 13:44.000 --> 13:46.000 I was approached by some people and saying, 13:46.000 --> 13:47.000 you know, it's neat and all, 13:47.000 --> 13:50.000 but I don't really want to change my programs. 13:50.000 --> 13:52.000 Because I had my programs for a long time, 13:52.000 --> 13:55.000 and I want to keep them. 13:55.000 --> 13:59.000 So I thought that if you really cannot 13:59.000 --> 14:02.000 be convinced to change, you really want to keep using 14:02.000 --> 14:06.000 Cisco's GPIO, do you really care whether the code for that 14:06.000 --> 14:08.000 runs in the kernel? 14:08.000 --> 14:13.000 Or would you be okay if it run in user space? 14:13.000 --> 14:16.000 So that idea occurred to me when I was looking 14:16.000 --> 14:20.000 for a project to learn Rust and I figured that I need 14:20.000 --> 14:23.000 something that will be useful that will keep me motivated 14:23.000 --> 14:25.000 to actually do a good job. 14:25.000 --> 14:29.000 I figured that I will write an abstraction layer 14:29.000 --> 14:32.000 for CSS in Rust in user space. 14:32.000 --> 14:33.000 And then I started looking at Rust, 14:33.000 --> 14:35.000 because this was my first experience with it. 14:35.000 --> 14:39.000 And I figured that, yeah, Python is good enough, right? 14:39.000 --> 14:46.000 So now there is a thing called GPIO. 14:46.000 --> 14:48.000 These CSS proxy. 14:48.000 --> 14:50.000 This is exactly that. 14:50.000 --> 14:54.000 This is an abstraction layer based on fuse. 14:54.000 --> 14:58.000 And using live GPIO to control GPIOs, 14:58.000 --> 15:00.000 implemented in user space. 15:00.000 --> 15:02.000 So you can get it from GitHub. 15:02.000 --> 15:04.000 You can get it from Python. 15:04.000 --> 15:06.000 And there are some things. 15:06.000 --> 15:09.000 So I would say that it's 99% compatible with CSS. 15:09.000 --> 15:11.000 There is a problem with limitations with fuse. 15:11.000 --> 15:15.000 So you cannot have multiple Polars of a single file in fuse. 15:15.000 --> 15:20.000 And there is also no static GPIO based for chips. 15:20.000 --> 15:21.000 I'm working on it. 15:21.000 --> 15:23.000 I don't want to add it in some way, 15:23.000 --> 15:26.000 but I am sort of consulting people who may have 15:26.000 --> 15:28.000 interested in that on how to approach it. 15:28.000 --> 15:31.000 So configuration file, listing labels of GPIO chips, 15:31.000 --> 15:34.000 and they're predefined basis or something. 15:34.000 --> 15:35.000 That sounds really it. 15:35.000 --> 15:36.000 I will figure that. 15:36.000 --> 15:39.000 I've written a comprehensive set of compatibility tests. 15:39.000 --> 15:41.000 And this script passes them. 15:41.000 --> 15:44.000 So I think it's rather compatible. 15:44.000 --> 15:47.000 You can get it from, you can install from PIP. 15:47.000 --> 15:50.000 And just mount it on the directory of your choice, 15:50.000 --> 15:53.000 which typically would be CIS class GPIO. 15:53.000 --> 15:54.000 But then you'll say, okay, 15:54.000 --> 15:58.000 but I disabled CIS class GPIO in my kernel config. 15:58.000 --> 16:00.000 I don't have that directory, 16:00.000 --> 16:03.000 and I cannot empty the GPIO in CIS class. 16:03.000 --> 16:04.000 So what do I do? 16:04.000 --> 16:08.000 Well, you can use overlay FS. 16:08.000 --> 16:12.000 And I actually sent a patch to Greg KH, 16:12.000 --> 16:16.000 adding a predefined mount point for CIS class GPIO 16:16.000 --> 16:18.000 if this class is disabled. 16:19.000 --> 16:21.000 Just like what you have for debug FS or config FS. 16:21.000 --> 16:22.000 He said that it's disgusting. 16:22.000 --> 16:26.000 He was very, very unhappy with it. 16:26.000 --> 16:30.000 And then I played with overlay FS and figured that I can simply overlay 16:30.000 --> 16:32.000 this directory on top of CIS class. 16:32.000 --> 16:34.000 And I sent the response to him saying, 16:34.000 --> 16:35.000 I no longer need that patch. 16:35.000 --> 16:36.000 I can do it in user space. 16:36.000 --> 16:37.000 And he never responded. 16:37.000 --> 16:41.000 And I can imagine that he's faced with something like this. 16:41.000 --> 16:44.000 So what's next for that? 16:44.000 --> 16:47.000 I want to support static predefined 16:47.000 --> 16:49.000 to hardcore the GPIO base numbers. 16:49.000 --> 16:51.000 I want to get some traction for it. 16:51.000 --> 16:53.000 So please check it out. 16:53.000 --> 16:55.000 I still want to learn Rust. 16:55.000 --> 16:57.000 And I figured that maybe there is. 16:57.000 --> 17:00.000 There would be interest in having a proper. 17:00.000 --> 17:04.000 A better file system based interface for GPIOs. 17:04.000 --> 17:06.000 This is something that Linux Valesh, 17:06.000 --> 17:09.000 the commentator for GPIO float at some time ago. 17:09.000 --> 17:11.000 Like, oh, I would, you know, I don't, 17:11.000 --> 17:15.000 I'm not against having a user file system based interface. 17:15.000 --> 17:18.000 Maybe you should work on a new one that would live in debug effects. 17:18.000 --> 17:20.000 But I'm like, OK, let's not add anything to the kernel. 17:20.000 --> 17:22.000 Let's do it in user space. 17:22.000 --> 17:27.000 And I, my, my, my, my to do this is running over, 17:27.000 --> 17:30.000 but I, I intend to get to it at some point. 17:30.000 --> 17:35.000 And finally, oh, this is the last GPIO will stay there for a while. 17:35.000 --> 17:38.000 We can remove it as long as it has users. 17:38.000 --> 17:41.000 We have alternatives in the form of live GPIOD. 17:41.000 --> 17:46.000 We have, I'll turn on a compatible alternative in the form of the system's proxy. 17:46.000 --> 17:51.000 And well, the work continues on converting the kernel drivers, 17:51.000 --> 17:54.000 the legacy kernel drivers to using the new API. 17:54.000 --> 17:58.000 And once we get that done, that will make a much more strong, 17:58.000 --> 18:04.000 stronger case for removing the old interface and subsequently the GPIO class. 18:04.000 --> 18:07.000 And yeah, right on time, that's it. 18:07.000 --> 18:08.000 Thank you very much. 18:08.000 --> 18:10.000 And I'm open to question. 18:16.000 --> 18:18.000 Question. 18:23.000 --> 18:27.000 For other alternatives from a minimal user space, 18:27.000 --> 18:34.000 like when you're most the only one to use things like busy box. 18:35.000 --> 18:41.000 So if you only want to use busy box, 18:41.000 --> 18:48.000 plan some scripts, but not even fully in it. 18:48.000 --> 18:51.000 For other alternatives, 18:51.000 --> 18:55.000 send this out, having to start a bunch of demons. 18:59.000 --> 19:00.000 I think the question is. 19:00.000 --> 19:03.000 Yeah, I, I, I, I, I'm trying to, I'm thinking about the answer. 19:04.000 --> 19:10.000 If you really just want busy box and not run anything other than busy box, 19:10.000 --> 19:13.000 then, all the closest thing is running GPIO tools. 19:13.000 --> 19:14.000 They are very tiny. 19:14.000 --> 19:15.000 These are very tiny programs. 19:15.000 --> 19:18.000 And I guess you're not running only this box. 19:18.000 --> 19:20.000 You typically will have something else. 19:20.000 --> 19:21.000 Something on top of it. 19:21.000 --> 19:25.000 So the closest will be just just running the GPIO tools. 19:26.000 --> 19:30.000 I mean, yeah. 19:32.000 --> 19:34.000 Oh, I'm not gonna. 19:34.000 --> 19:35.000 That's enough. 19:35.000 --> 19:37.000 Not yourself out. 19:42.000 --> 19:45.000 So the broad come GPIO drivers, 19:45.000 --> 19:48.000 that's used as Raspberry Pi's, has a kernel module parameter 19:48.000 --> 19:51.000 to enable GPIO persistence. 19:51.000 --> 19:53.000 So even if you release a release line, 19:54.000 --> 19:56.000 it returns to the old value. 19:56.000 --> 19:57.000 And it's upstream. 19:57.000 --> 20:00.000 Why can't we have that for all GPIO controllers? 20:00.000 --> 20:03.000 And just use GPIO set without having to use demons. 20:03.000 --> 20:06.000 Why only this one driver is allowed to have it, 20:06.000 --> 20:08.000 and the others, not couldn't we add like a flag? 20:08.000 --> 20:11.000 And request, please, I want to have GPIO persistence, 20:11.000 --> 20:13.000 and the drivers just do the correcting. 20:13.000 --> 20:15.000 Do you have three hours? 20:15.000 --> 20:17.000 So, uh, I, okay, but surely, 20:17.000 --> 20:20.000 register that for the embedded dinners. 20:21.000 --> 20:22.000 We sit next to each other. 20:22.000 --> 20:23.000 I'm sure you know. 20:23.000 --> 20:24.000 I'm sure you know. 20:24.000 --> 20:26.000 The idea of like, 20:26.000 --> 20:29.000 safe state property in device three for GPIOs 20:29.000 --> 20:31.000 has been around for a while. 20:31.000 --> 20:34.000 We just couldn't get any traction of for it with 20:34.000 --> 20:35.000 DT maintainers. 20:35.000 --> 20:38.000 And yeah, there is this idea that, 20:38.000 --> 20:42.000 oh, we should actually limit the available states of GPIOs 20:42.000 --> 20:45.000 because some of them may be regulators that may damage hardware 20:45.000 --> 20:47.000 if they enter a certain state. 20:48.000 --> 20:51.000 Yes, that, that, that, that is an idea, 20:51.000 --> 20:54.000 but I'm, I'm not sure if it's going to go anywhere 20:54.000 --> 20:56.000 in, in, in the new future, 20:56.000 --> 20:58.000 but we can talk about it doing the dinners. 20:58.000 --> 21:00.000 Okay, but for respite, it went somewhere. 21:00.000 --> 21:01.000 So why not? 21:01.000 --> 21:03.000 I, I am not sure if it, 21:03.000 --> 21:06.000 ever, so it's, is it a kernel module? 21:08.000 --> 21:09.000 Is it a kernel parameter? 21:09.000 --> 21:12.000 Or is it a device three property? 21:12.000 --> 21:13.000 Okay. 21:14.000 --> 21:17.000 I'll just follow up on this gentleman over there. 21:17.000 --> 21:20.000 What happens if you have, in a drum of us, 21:20.000 --> 21:22.000 with just visible. 21:24.000 --> 21:27.000 Basically, at that point, you do not have python 21:27.000 --> 21:28.000 to run the proxy. 21:28.000 --> 21:31.000 You don't have potential GPIO tools 21:31.000 --> 21:33.000 because you are limited in size. 21:33.000 --> 21:38.000 What now, you are left with the system of a interface anyway. 21:38.000 --> 21:41.000 And actually, this is of a interface for this stuff, 21:41.000 --> 21:43.000 and it's nice because you can just echo stuff 21:43.000 --> 21:46.000 and this is of us attributes. 21:46.000 --> 21:50.000 I do agree, yes, that's another, another problem to think about. 21:50.000 --> 21:54.000 And maybe adding some limited subset of GPIO tools, 21:54.000 --> 21:57.000 functionality to your busy box is the way. 21:57.000 --> 22:00.000 I had a use case like that back in the day with, 22:00.000 --> 22:01.000 I, I, I, to see, 22:01.000 --> 22:04.000 and I actually added, I, to see tools to busy box 22:04.000 --> 22:06.000 because I, I required it in, in front of us. 22:06.000 --> 22:08.000 So, that may be the way. 22:09.000 --> 22:11.000 Or maybe the debug of us interface. 22:11.000 --> 22:14.000 And you won a viable one. 22:17.000 --> 22:20.000 That's, um, basically, I don't have enough to write now. 22:20.000 --> 22:22.000 I will, I will think about it however. 22:22.000 --> 22:24.000 That may be material for another, 22:24.000 --> 22:27.000 another talk and another conference. 22:27.000 --> 22:30.000 You can always use configFS. 22:31.000 --> 22:34.000 We already have gadgets in configFS, right? 22:34.000 --> 22:37.000 So, if we add another interface for GPIO, 22:37.000 --> 22:40.000 that is configurable for configFS. 22:43.000 --> 22:45.000 Okay, that does the end. 22:45.000 --> 22:46.000 Thank you.