From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FAEF70 for ; Fri, 9 Jul 2021 07:24:29 +0000 (UTC) Received: by mail-vk1-f175.google.com with SMTP id x20so1973317vkd.5 for ; Fri, 09 Jul 2021 00:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tCqEXFc24XvKiFkOa/fiWYH4DXDnsx7wiFTJWpA4rKI=; b=H8cuodBlZ2FXS4YssEWaz4u93myVh6hKFlvtMFuc6iWxFYsdZR7HFuVi4Stc5G4x3H 5nX1PklUlf16zcR0Eyk7HEPjVK2ZCUzxGxR2uk6m+sGBZL4M1m41CogKSx78gwCcqwPt ndMaQDoYcmcrzKL9v5ce1uH0kA12/85oNO+bLSkc2Nd0FETddlxwus8wxxT3mEZq4fOi QnbfmH5IZjVeGpfYmWb/9cd836HZ70PmmoF7IY1u0brGljkTCgmQlODFpbZb6+fOKDWZ ceGwyhPIG8yZxUNuvY+2f1dQECBIh6gThgkTaa5B/m3QkqovLCuRmtQnujVsqgphFA9A lQLQ== X-Gm-Message-State: AOAM5319S9FOdFUT9j9Jdsa+gqyw8nDt7AaP8Ai/HTLQn9xmX1gN0w+4 whKwiR5qJMr/pL2r2O/5aTYKYFIWHs/rFntsvVE= X-Google-Smtp-Source: ABdhPJzaU3neZsjAhS7cWSCC1o70unv3wmChdBVMX3/5A9qT8J51Jrwi7Kv5qaEnjJut5BNeb//U+yH5eyrgGtV9a04= X-Received: by 2002:a1f:1a41:: with SMTP id a62mr30561501vka.5.1625815468163; Fri, 09 Jul 2021 00:24:28 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <1f2a62c19845e4602817c2130d47bbea02d04d1d.camel@HansenPartnership.com> <20210707203827.GI18396@quack2.suse.cz> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 9 Jul 2021 09:24:16 +0200 Message-ID: Subject: Re: [TECH TOPIC] Rust for Linux To: Linus Walleij Cc: Miguel Ojeda , Greg KH , Bartosz Golaszewski , Kees Cook , Wedson Almeida Filho , Jan Kara , James Bottomley , Julia Lawall , Laurent Pinchart , Roland Dreier , ksummit@lists.linux.dev, Viresh Kumar Content-Type: text/plain; charset="UTF-8" Hi Linus, On Fri, Jul 9, 2021 at 12:13 AM Linus Walleij wrote: > On Thu, Jul 8, 2021 at 10:34 PM Miguel Ojeda > wrote: > > On Thu, Jul 8, 2021 at 9:49 PM Linus Walleij wrote: > > > With my GPIO maintainer hat on I'd say a GPIO driver would be quite > > > interesting to look at. We are two GPIO maintainers and Bartosz is > > > doing the heavy lifting for the moment so I'm connecting Bartosz to this > > > discussion. (Now he has to read through the whole backlog, > > > sorry Bart!) > > > > > > This is not to say I promise we will merge it or so, but I just generically > > > like new approaches to old problems so I like this whole thing > > > overall, despite being critical to some details. > > > > > > I am also trying to learn Rust. Baby steps. > > > > Thanks a lot for this offer Linus. > > > > Do you have a particular one in mind? Ideally, it would be one that > > has QEMU support or a test suite of some kind, or at least one that > > you can easily test for us etc. > > I don't use QEMU for GPIO development, we are so close to the > real hardware that it's often not appropriate. We have a testing > module but that is not a real world driver and would not meet the > expectations set here of creating real hardware drivers. > > I have seen that QEMU has a piece of code for the Arm PrimeCell > PL061 GPIO block which corresponds to drivers/gpio/gpio-pl061.c > Note that this hardware apart from being used in all Arm reference > designs is used on ARMv4T systems that are not supported by > LLVM but only GCC, which might complicate things. Still, the PL061 emulation may be incomplete. It also doesn't do that much yet, i.e. you cannot use it to blink a virtual LED. > I am a bit oldschool in that I think real hardware is awesome to test > on. GPIO drivers exist in many shapes and sizes, some are directly > memory-mapped to hardware registers, some are I2C or SPI. > Most Raspberry Pis and Beagle Boards have them, albeit the > on-chip GPIOs are often also pin controllers which complicates > things. Expanders on I2C and SPI will be simpler. Maybe look > for an I2C or SPI expander that has no existing kernel support and > implement it in Rust? That still requires an I2C or SPI bus, which may not be that easy to find for people who don't have embedded boards on their desk... Do you know of any unsupported expanders that connect to USB? Something like an MCP2210 dev board[1], but that one is mainly intended for SPI, although some pins can be used as GPIOs. There is no upstream driver yet, but there is an out-of-tree driver and a FOSDEM presentation. [1] E.g. https://www.digikey.be/product-detail/en/microchip-technology/ADM00419/ADM00419-ND/3046570 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds