From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55E1DD65C6C for ; Thu, 14 Nov 2024 10:36:43 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1tBXDM-000000004j8-0QzF for kernelnewbies@archiver.kernel.org; Thu, 14 Nov 2024 05:36:40 -0500 Received: from mail-pg1-f173.google.com ([209.85.215.173]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1tBXCf-0000000036s-0Zko for kernelnewbies@kernelnewbies.org; Thu, 14 Nov 2024 05:35:57 -0500 Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-7ea7e2ff5ceso297702a12.2 for ; Thu, 14 Nov 2024 02:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731580492; x=1732185292; darn=kernelnewbies.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lvrsUFfzMNWDyTCFGXiE6/PyP9BOuohXvlgvaI5T4/U=; b=bII6O6knr1Ck3xpCmKzAsum5ZTqgR+4xm50zVpBDGLJEhrgminDA4P+urqPbEwvQQH bIA8Zyoprw4QX9Fz9Zg6Fqoy+tQs2gM8JLR0jMPvlqXzzcgsTRxEiDwV//DeEXzr6Z70 KIMQ6/HP2YgyZKd1es3oBn1Sf2srvaOeIW1oftYLQJdmcfzP7X6he9uZ8nLdwPigEVHc KRTLGNYwES6XR+KO1ZkuIBhUDTVC4rKLrACaV7IjXMaHWzELuJLEeTej7baj2ar7kVuw uQ0mCoRvM2m5KpxDP6n5oY9q+M1pXiajAJNwJsUjGpejmN5RkIR6eF+NlFFAizLQu+Nf aYpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731580492; x=1732185292; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lvrsUFfzMNWDyTCFGXiE6/PyP9BOuohXvlgvaI5T4/U=; b=TdcjuI9dMKVawnd38FVOBgxkg+TEIaIzner/A6rGL3uQonFANIJNO78HD18MdWdYl/ JVLKlH35jnaZQvCVc7SqZaoXrYY3LPgkByq6CBkqpfIowJoJZv2QWnbfC43gn0U38QVf bCWDksl8WLV3nJxZ67jDrTf8/JdbUGpDHrSBU21dlAgNQtCpxVEKyL9WEC4FSP3QiCxb So8ESdWjfcaLL6qSJH02IFgGP7lSk/OpNo/d2Cp2u8DYchfdY1FfjP60Pk8aIT5/0An9 E3I2jmTg2vrTtl3pbJz+5NEyy8hEdEZ5P9u0hxISKfhye7z2Xf86gkqP+SlJhEJnpTPn ZaHA== X-Gm-Message-State: AOJu0YyM0hjjkc0FZe2b8lGTXUxnYbc4oEdtPGMAYNFrp/smSe+B8hBY Jlin3AnfTGX7eAuP3Bi/HO6N3fzAuJ2/4DQb1dUjznQmDwEssbF2ST2A3HPDUK7vwQjKdW9F+LY 8hk+9DCi8KJQRyouITNAHrW6Ub/8SoQ== X-Google-Smtp-Source: AGHT+IEWjNvUsAYV5Q4DHUK5/NDdLe4I4b1HYbRrYCkN610d+QQriD4xxbK25MmBSlCeXtBu4f/vOodXvciS1Wb5ptA= X-Received: by 2002:a05:6a20:4309:b0:1da:4dea:3a41 with SMTP id adf61e73a8af0-1dc5f8ce2a7mr13795983637.5.1731580491954; Thu, 14 Nov 2024 02:34:51 -0800 (PST) MIME-Version: 1.0 From: Patryk Date: Thu, 14 Nov 2024 11:34:41 +0100 Message-ID: Subject: Replacing reset gpio with reset controller To: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces+kernelnewbies=archiver.kernel.org@kernelnewbies.org Hi, First of all, I'm not sure what would be the best mailing list to ask this question, so if you have an idea what would be a better choice then I would be grateful if you could direct me to the right place. In the board that I've been working on, apart from the main CPU we also have an Intel MAX10 FPGA which acts as a system controller. It has a lot of signals connected over the board that it supervises. Eg. We have a few i2c devices and most of them expose a reset pin. All these reset pins from these devices are connected to the FPGA which is responsible for triggering resets. Apart from that, we thought about implementing a reset controller driver in the kernel that would communicate with this FPGA and allow to trigger a reset on any device (that has its reset pin connected to FPGA of course). I've browsed through the drivers that I'll need to enable on our board, and most of them expect some kind of reset api that they use e.g. during probe. Most of them however expects the reset_gpio which in our case is not what we want, as all resets are managed by FPGA and all reset requests should go through it. I'm wondering - would it be possible (and what is even more important, would it make sense?) to implement a reset controller driver (perhaps there is already something similiar?), that for the consumer drivers (like some sensors and so on that currently use gpiod* calls) would still remain as gpio-like reset (so they would still use gpiod* calls), whereas under the hood the calls would be forwarded to FPGA? If not, the other option I see is to extend the functionality of the drives that we are going to use reset_controller consumer api). I would be grateful for some advice. Best regards Patryk _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies