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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4BBD5E6FE31 for ; Fri, 6 Sep 2024 16:52:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=h4Zf0qBJVKBAX2oTkkO2ilQEf9MRXPCVUknF15ax8Qw=; b=F3m70FoDu1JcvvyHMGJvQLI89s SruYuefZR/OIgXc0MqJmpa2SbKSArP/fgM3hLTcf6BKY6bjPiJOKvGMCaGi/ve32SqQDGkrJgGkaW uNzQzCFWqms5N13u47Gx0Rl3f1jZgSeShQQo9k9OWOLr6xHtah5W70wLPZbGdvFDldTLwjynWWCRh 6clmdLaW++EA91rIOwsy3rOyDhJzJOKIvygL/mTvpBhW61JxZPyWu2R7NEoXR2Q83japRfIlt+lc6 8UAs0l8irIqPRKk4i4m69FPkyY8wuxylPxjV7ZfXXOcapxhcBwyxCnS6R6QistDgA5h4x+T3VP3cS rb6WOMMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1smcCM-0000000D2CZ-1rFt; Fri, 06 Sep 2024 16:52:38 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1smcBM-0000000D23s-0vwN for linux-arm-kernel@lists.infradead.org; Fri, 06 Sep 2024 16:51:37 +0000 Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-7148912a1ebso1458414b3a.0 for ; Fri, 06 Sep 2024 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725641495; x=1726246295; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=h4Zf0qBJVKBAX2oTkkO2ilQEf9MRXPCVUknF15ax8Qw=; b=h0bWL7GhpSAF5iTTAfYWstB1E7hq2gby2bFZnE2qfHK9CWrVTmRvaEmewcACnUUpsB jBFaCbxLmLvSB4MI7txJetDQPMuBjf5ZGasbJR7M9IWUBOfmafVyCZ8dL5B9SMY4RAOl sLlCrN0yr8kwh6wENZcq70cRqx9FE2Jd6tY/nPq1hSavpBe4nzypj6xyZ1kS7pPVryuR r9Sew4VD6VmmCbr4BJRRz0tnnoBYBWiu+l8WU+hk/FxMClOha7EOTNoXyTUhtGT0rypG 8GcKcfQcpd+zq3FsKfj15L3kotXNw+Ik4BRFVuS7B6TkZzIazsjQiT46gYbyMcn9yCGt SJqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725641495; x=1726246295; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h4Zf0qBJVKBAX2oTkkO2ilQEf9MRXPCVUknF15ax8Qw=; b=nmicC/o4sYL7h5/b/4VntDGxN+CljzXo2V2aXI9yL6Mfz16gy8abj9wCegPoip9SRs ZGX5V46JsejGUh4R1AKTUd8E9czr+U5KC+ZDKmdof7cUEMwv4imionnZcAAubCMsbg0e poaBw7hEP4nEvFWrxXRAepAHV9k5ywcocEdNvIjjK6F61mvvS271OOig5beb03akBue1 6XSxzrHasL9gL1pF8n5PmwbNSokWofAz3RFze34Kwl1ng2E2gJMcyW5tvMlLv/BgV0i+ UgMfNWOmIpmvdYGKmy9PiVuGMbl5UiqB1MOBfrCChsu0n714VTlOolG2Rcbg8FN/mQuo f/+g== X-Forwarded-Encrypted: i=1; AJvYcCVJfc6dtwkF2n+iexoSuembr2/HI0VBc93VKfiE//EKdt+BrSUo5SRE1+2xPsaPNM8Wr89P+UITO5LazFCuDDrs@lists.infradead.org X-Gm-Message-State: AOJu0YzSZM+o4fDVniiLy1Dftx7yOypOwnZFbT5y5tYB+Uzm7D4Zd5Cz Ingd69L/d3g1Ntovt8CgAP25zjZL8rM2Uh9WSMQbfdxg6kcHjLGP X-Google-Smtp-Source: AGHT+IFelxxdKcd3hHoXb+4xNySiblzNeAKpXJIt60X2PrLPJ1PnpFDoBGQmt95PhQgRwy0Caz4XXA== X-Received: by 2002:a05:6a00:4651:b0:70d:3354:a190 with SMTP id d2e1a72fcca58-718d5f1f833mr3579486b3a.27.1725641494419; Fri, 06 Sep 2024 09:51:34 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:4846:f267:7877:9a14]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-718d9ffa501sm1247390b3a.138.2024.09.06.09.51.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Sep 2024 09:51:34 -0700 (PDT) Date: Fri, 6 Sep 2024 09:51:31 -0700 From: Dmitry Torokhov To: Nuno =?iso-8859-1?Q?S=E1?= Cc: Arnd Bergmann , Michael Hennerich , Linus Walleij , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Lee Jones , linux-arm-kernel@lists.infradead.org, Utsav Agarwal Subject: Re: [PATCH] Input: keypad-nomadik-ske - remove the driver Message-ID: References: <1bc01e00-7b70-4e90-8060-f3de3ec7afa3@app.fastmail.com> <9db96c99c805e615ba40ca7fd3632174d1e8d11f.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9db96c99c805e615ba40ca7fd3632174d1e8d11f.camel@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240906_095136_283950_E7E6985F X-CRM114-Status: GOOD ( 23.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Nuno, On Fri, Sep 06, 2024 at 10:38:35AM +0200, Nuno Sá wrote: > > Hi Dmitry, > > This is not forgotten and I plan to start working on this early next week. > > One thing I noticed and I might as well just ask before starting the work, is that > the platform data allows, in theory, for you to have holes in your keymap [1]. Like > enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of > the box as we just define the number of rows/cols and then without any other property > we assume (I think) that the map is contiguous.  > > This is just early thinking but one way to support the current behavior would be 2 > custom DT properties that would be 2 u32 arrays specifying the enabled columns and > rows. Out of it, we could build row and col masks and get the total number of cols > and rows that we could pass to matrix_keypad_build_keymap(). I'd ask DT maintainers but in my opinion we could add 2 u32 scalar properties to specify row and col masks (either enabled or disabled, whatever is more convenient) and then indeed we could figure out the resulting size of key matrix and use matrix_keypad_build_keymap() to load it. > > The question is... is it worth it? I'm aware that if we just assume a contiguous > keymap we could break some old users. But I guess it would be only out of tree ones > as we don't have any in kernel user of the platform data. On top of it, I guess it's > sane to assume that one just wants a contiguous keymap... > > [1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630 I think in practice it's just a few extra lines of code, so shoudl be fairly easy to keep supporting this. But we can actually split the binding and the driver implementation, with binding defining all capabilities of the hardware and driver implementing just a subset of it (i.e. complain if row and column mask properties are specified and abort probe). Thanks. -- Dmitry