Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2427400imm; Sat, 16 Jun 2018 18:23:05 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIpbYa4PB3ajHxQcYpi6kdiAc2LoWwp287LW/EhxLlpSaDkqsicHKmRsNuGswJRITYti734 X-Received: by 2002:a17:902:9f84:: with SMTP id g4-v6mr8382742plq.339.1529198585243; Sat, 16 Jun 2018 18:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529198585; cv=none; d=google.com; s=arc-20160816; b=H02ZGlD9X6xkM7wWUT8xKQRyHq0LJ3RQR8SgMv7YB8SrUzkXloRKnYgmxLZ3wDr+T/ 6DdHIjIlLsUrL16zE416nXUtdzCmwP4ryvJidF05FgSBCtWHyRJCPqHKQBrF44CoDd/E CM6ObwJlMNrmRKflJwNwIR7QV5TYkaigR1mxgeT1j7wl6qVHQp223mXGxethzTrUEKv2 FdiFrstNMYkGM6sD8dcSqKSbuQO/yQhyTKGr6hriLG6mvctyl6yfJKsNGuacrJ80YRmA nWmoFCgCz7Sltu3cEhfpNpxf9n0txv/SLSpqqDv7myvOJHZingLVOUilEt2jqCeIJsKu 8t9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=LzmFhg1JaOT/mPFeDptKTr+Ak4QGktqdvquILy4YWYs=; b=EY2upXn/+wxUqj3waB7LRp0DDrvIlnSp7sRkWa2Qe/H1G8XBX//m4VRRwwKS8nu/b3 Ked1XT92EEWsaSHL7KJILJMHZfiChkW1F31YoOjVG0B66l2qBmze4QOKf88EN+wVn6cj N015fpq6BMfqk6B56mIxFkuLLAGF4F4cv6Z6myPEr1lBId48lXca/LbisEvaj1oRr3/s 3bYV9F61FtF45WSOo18d9ADJbBiPo9iyzcj1CjHgJ/+HqqhfrFJ4RSyhV7WqjWgbLLAI 2+fhzWPzucsEHadATiMJIl8k9N9OyAwIb2Bh+Gdh9NUSh1f2/NEzysYz8GqxIHAqQHUQ jDaA== 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 c7-v6si9820963pgt.220.2018.06.16.18.22.50; Sat, 16 Jun 2018 18:23:05 -0700 (PDT) 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 S1757023AbeFQBW1 (ORCPT + 99 others); Sat, 16 Jun 2018 21:22:27 -0400 Received: from gate.crashing.org ([63.228.1.57]:33373 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756946AbeFQBW0 (ORCPT ); Sat, 16 Jun 2018 21:22:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w5H1MCDi016000; Sat, 16 Jun 2018 20:22:13 -0500 Message-ID: Subject: Re: [RFC PATCH 5/5] fsi/scom: Major overhaul From: Benjamin Herrenschmidt To: Joel Stanley Cc: OpenBMC Maillist , Linux Kernel Mailing List , Andrew Jeffery , Greg Kroah-Hartman Date: Sun, 17 Jun 2018 11:22:11 +1000 In-Reply-To: References: <20180612051911.20690-1-benh@kernel.crashing.org> <20180612051911.20690-6-benh@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 (3.28.1-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote: > > We have everything that cronus needs and more than pdbg needs afaik :-) > > That said, cronus does a bunch of other stupid things that I'm still > trying to figure out how to fix. > > We might need to create a /dev/cfam rather than going through that > magic sysfs "raw" file, and I wouldn't mind using a single IDA so that > all the devices below a given FSI slace (cfam itself, sbefifo, occ, > ...) have the same "number". Also while we're at reworking how all this is exposed to our broken userspace, I wouldn't mind putting all these dev entries under a directory, if I can figure out how to do that (I haven't really looked yet). /dev/fsi/{cfamN,sbefifoN,occN, ...} and possibly similar by-id and by- path that other subsystems use, so we have something more deterministic than the "random number" crap we do now. We can always keep hacks to do symlinks in our kernel tree until we have converted all our userspace users. We currently control the only userspace users of this, so now is a good time to cleanup how we expose things. This won't always be the case. Cheers, Ben.