Message ID | 20221014220540.55570-1-eajames@linux.ibm.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp395721wrs; Fri, 14 Oct 2022 15:08:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4EIdUtYZkH8fMGnaG+A2fJJ0tyY4ccbTIroenQg65mGFQwiwOD08y1YGY+oijE4Cw5sLLV X-Received: by 2002:a05:6402:4411:b0:437:b723:72 with SMTP id y17-20020a056402441100b00437b7230072mr6114875eda.38.1665785280023; Fri, 14 Oct 2022 15:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665785280; cv=none; d=google.com; s=arc-20160816; b=wh3vifJyFzi9wLGL8QwdQ3KYAhAWbrKIurJmKZ0nfpIdusKWjtKhWfunvwhqJ2emNu SW/tprOrPFrB00tKs+4BdpbU4t5yoBpytL4j9e0KH0JviOsSTjLv2Yd/hWIkwcAjBTMK O5+JX9oroYq4oGB7q0eDBGnx+iQry4gRk0d0jpqoY4OD58q5D0dWYcfCp4eN6EL7t7eS OOyDQg6C5t4NzafyhrpEWRQhR1DXiq4zHtQnFnD2NSps5ErO/JDa4l8AjsZSfar8bvRk fisQQRLEbeMjq/csgv9J3m8O30eLtaMe/09CS1dU3uBP9Nwwc9WrvgqgJHN+Xn9Igk3g LoaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=hCZmNvrm+2RvitSHC59+iYpRNn2YCg0MUUQOP1GA5bY=; b=GAT4WDYgn6aKKiEGICW451lwC6/643A3jkU/htmxPfX8BC1JrHxMVU/mnQhJ90js9X RtCnH928X0RXmY+V541ICtvkuoScBuEL5M8p2IdCfHh6fiMMwGPgSV21d4cIpJc4b0U0 UAVwTxNBsp10Nd03P7gpynfhD4brnVv8DXRBIh1LDTnFbHix9gH9JjxHdQaFx/zCpZW2 Tr1dkUUIN4WMdPPI3eKHujB7g69IcWaa5RL+dWkH2clFaozjIPGYWth7H8LZU5zISTEl XekE09gn4zKcKDamDeT0M7ou7GiTfFLTaO3fOhGl1Nd8Uf4tplpyXLolc1ikRpwqWK+a Qi+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=PRr7me7+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b2-20020a1709064d4200b00773db392e1esi2979226ejv.997.2022.10.14.15.07.35; Fri, 14 Oct 2022 15:08:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=PRr7me7+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229663AbiJNWGS (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Fri, 14 Oct 2022 18:06:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229704AbiJNWGH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Oct 2022 18:06:07 -0400 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7BD913ECE1 for <linux-kernel@vger.kernel.org>; Fri, 14 Oct 2022 15:06:05 -0700 (PDT) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29ELAMdp002456; Fri, 14 Oct 2022 22:05:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=pp1; bh=hCZmNvrm+2RvitSHC59+iYpRNn2YCg0MUUQOP1GA5bY=; b=PRr7me7+7ozcUbSOqocD8AJ8DcT5fPYcjH5DrdDKWUn85Q5uHzsWp/ch7/bQXbbMvXGZ TfWaki6N5Ts4pWWdouPif0HPTL1oweiGjxTX0pWady6YCfaXpJslMY+XFmylEi56GvJl HI3eU3P016SsgtKcHDkJGnTwT6SH7kJV3rOiJEUVaj3fC6XWlMIrq+7J3IFN2crACRR7 75nCCiwyK/Cge7HJ3nAQT+p+CqgTYb/Sfc2zYToYJgo/nLal4zsOnkbp/g4WVyCOy15n KD3hT1pAL335ldFdaAZNYm1YfndJvZaZp9wnciZwooqRMvYSlvaI17ggDiAX21lYJALn yA== Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3k7dhemqy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Oct 2022 22:05:44 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 29EM5CRJ011304; Fri, 14 Oct 2022 22:05:43 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma04dal.us.ibm.com with ESMTP id 3k30uawk94-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Oct 2022 22:05:43 +0000 Received: from smtpav06.wdc07v.mail.ibm.com ([9.208.128.115]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 29EM5gcs2622194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Oct 2022 22:05:42 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 28C1058073; Fri, 14 Oct 2022 22:05:42 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0D97558054; Fri, 14 Oct 2022 22:05:41 +0000 (GMT) Received: from slate16.aus.stglabs.ibm.com (unknown [9.160.52.204]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 14 Oct 2022 22:05:40 +0000 (GMT) From: Eddie James <eajames@linux.ibm.com> To: joel@jms.id.au Cc: broonie@kernel.org, jk@ozlabs.org, alistair@popple.id.au, linux-kernel@vger.kernel.org, linux-fsi@lists.ozlabs.org, eajames@linux.ibm.com Subject: [PATCH 0/5] fsi: Add regmap and refactor sbefifo Date: Fri, 14 Oct 2022 17:05:35 -0500 Message-Id: <20221014220540.55570-1-eajames@linux.ibm.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Krf6LuWJA0A5jxKswohYji9OPercKeo0 X-Proofpoint-ORIG-GUID: Krf6LuWJA0A5jxKswohYji9OPercKeo0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-14_11,2022-10-14_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxscore=0 spamscore=0 clxscore=1011 mlxlogscore=390 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210140121 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746702466253996245?= X-GMAIL-MSGID: =?utf-8?q?1746702466253996245?= |
Series | fsi: Add regmap and refactor sbefifo | |
Message
Eddie James
Oct. 14, 2022, 10:05 p.m. UTC
The SBEFIFO hardware can now be attached over a new I2C endpoint interface called the I2C Responder (I2CR). In order to use the existing SBEFIFO driver, add regmap drivers for both FSI busses and the I2CR. Then, refactor the SBEFIFO and OCC drivers to clean up and use the new regmap drivers. Eddie James (5): regmap: Add FSI bus support regmap: Add IBM I2CR support drivers: fsi: Rename sbefifo and occ sources drivers: fsi: separate char device code for occ and sbefifo drivers: fsi: occ and sbefifo refactor drivers/base/regmap/Kconfig | 10 +- drivers/base/regmap/Makefile | 2 + drivers/base/regmap/regmap-fsi.c | 231 +++++ drivers/base/regmap/regmap-ibm-i2cr.c | 159 ++++ drivers/fsi/Kconfig | 23 +- drivers/fsi/Makefile | 8 +- drivers/fsi/fsi-occ.c | 766 ----------------- drivers/fsi/fsi-sbefifo.c | 1144 ------------------------- drivers/fsi/occ-cdev.c | 157 ++++ drivers/fsi/occ.c | 534 ++++++++++++ drivers/fsi/occ.h | 75 ++ drivers/fsi/sbefifo-cdev.c | 218 +++++ drivers/fsi/sbefifo-fsi.c | 68 ++ drivers/fsi/sbefifo-i2c.c | 72 ++ drivers/fsi/sbefifo.c | 797 +++++++++++++++++ drivers/fsi/sbefifo.h | 50 ++ include/linux/regmap.h | 72 ++ 17 files changed, 2468 insertions(+), 1918 deletions(-) create mode 100644 drivers/base/regmap/regmap-fsi.c create mode 100644 drivers/base/regmap/regmap-ibm-i2cr.c delete mode 100644 drivers/fsi/fsi-occ.c delete mode 100644 drivers/fsi/fsi-sbefifo.c create mode 100644 drivers/fsi/occ-cdev.c create mode 100644 drivers/fsi/occ.c create mode 100644 drivers/fsi/occ.h create mode 100644 drivers/fsi/sbefifo-cdev.c create mode 100644 drivers/fsi/sbefifo-fsi.c create mode 100644 drivers/fsi/sbefifo-i2c.c create mode 100644 drivers/fsi/sbefifo.c create mode 100644 drivers/fsi/sbefifo.h
Comments
On Fri, Oct 14, 2022 at 05:05:35PM -0500, Eddie James wrote: > The SBEFIFO hardware can now be attached over a new I2C endpoint > interface called the I2C Responder (I2CR). In order to use the > existing SBEFIFO driver, add regmap drivers for both FSI busses > and the I2CR. Then, refactor the SBEFIFO and OCC drivers to clean > up and use the new regmap drivers. Is there any great reason to provide support in the regmap core for this rather than just implementing in drivers/fsi? AFAICT this is just ending up as an implementation detail of shared code in drivers/fsi and won't have any external users?
On 10/17/22 12:37, Mark Brown wrote: > On Fri, Oct 14, 2022 at 05:05:35PM -0500, Eddie James wrote: >> The SBEFIFO hardware can now be attached over a new I2C endpoint >> interface called the I2C Responder (I2CR). In order to use the >> existing SBEFIFO driver, add regmap drivers for both FSI busses >> and the I2CR. Then, refactor the SBEFIFO and OCC drivers to clean >> up and use the new regmap drivers. > Is there any great reason to provide support in the regmap core for this > rather than just implementing in drivers/fsi? AFAICT this is just > ending up as an implementation detail of shared code in drivers/fsi and > won't have any external users? One reason is to have a common interface with the new FSI regmap. That way abstracting out the bus transfer is trivial in the new SBEFIFO driver, assuming the SBEFIFO driver should switch to use the FSI regmap. But you are correct, I doubt anyone else will use this. I suppose SBEFIFO may as well not use the regmap and just use some callbacks for whichever bus transfer... Thanks, Eddie
On Tue, Oct 18, 2022 at 09:02:33AM -0500, Eddie James wrote: > On 10/17/22 12:37, Mark Brown wrote: > > Is there any great reason to provide support in the regmap core for this > > rather than just implementing in drivers/fsi? AFAICT this is just > > ending up as an implementation detail of shared code in drivers/fsi and > > won't have any external users? > One reason is to have a common interface with the new FSI regmap. That way > abstracting out the bus transfer is trivial in the new SBEFIFO driver, > assuming the SBEFIFO driver should switch to use the FSI regmap. > But you are correct, I doubt anyone else will use this. I suppose SBEFIFO > may as well not use the regmap and just use some callbacks for whichever bus > transfer... I'm not saying don't use regmap, I'm saying why not just do this in the driver - you can just as easily set the reg_read() and reg_write() callbacks in an individual driver without needing to create a new regmap bus type for just that one driver to use.
On Wed, 19 Oct 2022, at 04:30, Mark Brown wrote: > On Tue, Oct 18, 2022 at 09:02:33AM -0500, Eddie James wrote: >> On 10/17/22 12:37, Mark Brown wrote: > >> > Is there any great reason to provide support in the regmap core for this >> > rather than just implementing in drivers/fsi? AFAICT this is just >> > ending up as an implementation detail of shared code in drivers/fsi and >> > won't have any external users? > >> One reason is to have a common interface with the new FSI regmap. That way >> abstracting out the bus transfer is trivial in the new SBEFIFO driver, >> assuming the SBEFIFO driver should switch to use the FSI regmap. > >> But you are correct, I doubt anyone else will use this. I suppose SBEFIFO >> may as well not use the regmap and just use some callbacks for whichever bus >> transfer... > > I'm not saying don't use regmap, I'm saying why not just do this in the > driver - you can just as easily set the reg_read() and reg_write() > callbacks in an individual driver without needing to create a new regmap > bus type for just that one driver to use. +1
On 10/18/22 13:00, Mark Brown wrote: > On Tue, Oct 18, 2022 at 09:02:33AM -0500, Eddie James wrote: >> On 10/17/22 12:37, Mark Brown wrote: >>> Is there any great reason to provide support in the regmap core for this >>> rather than just implementing in drivers/fsi? AFAICT this is just >>> ending up as an implementation detail of shared code in drivers/fsi and >>> won't have any external users? >> One reason is to have a common interface with the new FSI regmap. That way >> abstracting out the bus transfer is trivial in the new SBEFIFO driver, >> assuming the SBEFIFO driver should switch to use the FSI regmap. >> But you are correct, I doubt anyone else will use this. I suppose SBEFIFO >> may as well not use the regmap and just use some callbacks for whichever bus >> transfer... > I'm not saying don't use regmap, I'm saying why not just do this in the > driver - you can just as easily set the reg_read() and reg_write() > callbacks in an individual driver without needing to create a new regmap > bus type for just that one driver to use. I understand. That sounds like a good approach then, I'll work on that for v2. Thanks, Eddie