Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8087205imu; Thu, 15 Nov 2018 06:27:47 -0800 (PST) X-Google-Smtp-Source: AJdET5eTYHIejtWIhpCptcTYH1u/bVUTQGh9bVuxggw6qRaF4UIwBYyaOGUEgFL0o2kwHJV7FMQl X-Received: by 2002:a17:902:f20e:: with SMTP id gn14mr6280299plb.11.1542292067043; Thu, 15 Nov 2018 06:27:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542292067; cv=none; d=google.com; s=arc-20160816; b=XXZ8Y5UACyqW2F+9VSyNoCu6CAFPQAfD7KsLZL18MjFrrbDM3JZDcPDbaXBnLCoijD zQgaK3jKfKMiHGNzwjqIKUwTQq2QVzpbA7VMZRFlYc+X3s2sAmhnwJsHpR2f3Ch5MZUm 2UsqAalyFIa51E/9UBE5xURFzq/7kAuFjYniyFpcijwhU0AlmPxxEgN1E/ff2aZSO53k /VU4GcbkJd05wKfCxTC2J/AUABdR4CDOzqJNU/H2ycfGI6vgrzfpXzR+Ag3IbOc1J2vv 1AyzAIZGLP/7tAt6AZ3IIiOuZenHgfSje7KHc18SLUav+WosQJPaT7A6VaYWZzSdJxFn GUhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=YKOzLffA+GFpkGJNymqpj3HUqw5QIb3tyHuzTzucqtk=; b=J+RHZC+MMv3Wzw7YEI+Zl8Drn4WCIqVw2YXYsx1SNBvS2bJ+Y9l8XAecHjdzLWN9Jb zIVhyT6WJprub/ML4/qPQOCCc1JAHs8ROKGXBJto3lpF5zky3lQYIg6V7ZrgGB7oO41a J1RxKd6surlAzsMvt2nvG5p8uTGx1pn8PZ/PBRigVghQ6n2gd/qghfyOToLfvmHtDVeJ krDn3EZiK5CQxE1R3keuBFZTVhro232vvd95j9p6ZHMpmNO/5e3+sHFalfIC5AX2P9+P gIMpBptbzLw92Dv3TYAiK5T0VOyJ71kinbVFU6h6mxyxDKuDtQUrrRbj1pHNhEs1izcj uAiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h7si7214651pls.326.2018.11.15.06.27.31; Thu, 15 Nov 2018 06:27:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388404AbeKPAeT (ORCPT + 99 others); Thu, 15 Nov 2018 19:34:19 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:39300 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388042AbeKPAeS (ORCPT ); Thu, 15 Nov 2018 19:34:18 -0500 Received: by mail-qk1-f194.google.com with SMTP id q70so14476011qkh.6; Thu, 15 Nov 2018 06:26:15 -0800 (PST) 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=YKOzLffA+GFpkGJNymqpj3HUqw5QIb3tyHuzTzucqtk=; b=YMGKpxLCem1M9yWRmzhjFxYeeXDIfs+z6oR7CeqX72HiqGFC9Vsz9Xl6KMrB8AAAp3 Oy/13Mm0b5RMFd46N9Jbl0ajg2TkbSd5Ju/LmQqmJ8GZI6NORFDbhCtfSAK30XFtyy6b WLFrq+xLZGe2ZPZRNL9PzQQKiIcyHp3j03QXTv+kvo5b3MQNTTXqgvRVKMiqlCROTjdi YuZP2VSy/raxd11w+v9EtUGTbf9ozd+aeTPd8d4Z+XP6BylfZCY5vbY7ZMAOQIzWc1We aWB/YkFo8nd9OjkQWza0BlBJay3RcgD4bIStJlx8WvC5BeKuh5HNpOsuF4R/mhnfjjfc 8ndw== X-Gm-Message-State: AGRZ1gIVnqaw6nhjEAGJO1sjSBdccDoS0d7sQQ+5/q/yJPExuZOLjmbp W02GdQ8L/kVemP3feAjVG3Od6pRj/9Ai8kq0e1I= X-Received: by 2002:ac8:7451:: with SMTP id h17mr5954341qtr.319.1542291974414; Thu, 15 Nov 2018 06:26:14 -0800 (PST) MIME-Version: 1.0 References: <20181026144333.12276-1-boris.brezillon@bootlin.com> <76b1d15d-232c-d8ba-5eba-8394e71be725@synopsys.com> <20181115135731.25f60990@bbrezillon> In-Reply-To: <20181115135731.25f60990@bbrezillon> From: Arnd Bergmann Date: Thu, 15 Nov 2018 06:25:54 -0800 Message-ID: Subject: Re: [PATCH v10 0/9] Add the I3C subsystem To: Boris Brezillon Cc: Vitor Soares , Wolfram Sang , Linux I2C , Jonathan Corbet , "open list:DOCUMENTATION" , gregkh , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Cyprian Wronka , Suresh Punnoose , Rafal Ciepiela , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , DTML , Linux Kernel Mailing List , Geert Uytterhoeven , Linus Walleij , Xiang Lin , "open list:GPIO SUBSYSTEM" , Sekhar Nori , Przemyslaw Gaj , Peter Rosin , Mike Shettel , Stephen Boyd , Mark Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 4:58 AM Boris Brezillon wrote: > +Mark Brown for the question about /dev/spidev > On Thu, 15 Nov 2018 12:14:37 +0000 > vitor wrote: > > My initial thoughts are to do the same think as for i2c, expose the > > buses or the i3c_devices and use ioctl for private transfers. > > Exposing the bus is dangerous IMO, because an I3C bus is not like an > I2C bus: > > * I3C device needs to be discovered through DAA > * I2C devices need to be declared ahead of time, and LVR is used to > determine the limitations on the bus at runtime > > So you'd anyway be able to interact only with devices that have > previously been discovered. > > Note that the virtual I2C bus is already exposed, but any command > targeting an address that is not attached to a registered I2C dev will > get a -ENOENT error. > > What we could do though, is expose I3C devices that do not have a > driver in kernel space, like spidev does. > > > Some > > direct CCC commands can be sent through the /sys as you plan for SETNEWDA . > > Yes, CCC commands that need to be exposed to userspace should be > exposed through sysfs, or, if we decide to create a /dev/i3cX device > per bus, through ioctls. > > > > > What do you think about this? > > I think this request is perfectly valid, we just need to decide how it > should be done, and before we take this decision, I'd like to get > inputs from other maintainers. > > Mark, Wolfram, Arnd, Greg, any opinion? I think for a new user space interface, it makes sense to explore a number of different options before making the final decision. I agree about better not exposing the bus as a /dev/i3c* node, and that we probably do need to expose individual devices in some form to allow writing complete user space drivers that can do everything a kernel driver can do. Can you describe what a low-level interface to the device looks like in the kernel? Can this be abstracted as simply pread()/pwrite() plus an interrupt mechanism, or do we need a set of ioctl() operations as well? If it can be purely based on a regmap abstraction, a sysfs inteface might be sufficient, though that has some downsides with permission management compared to a /dev/* node. Another option might be the use of a socket interface, which also has some issues in terms of permission management, but might be a good fit if we could abstract bus transactions as packets that can be queued. Arnd