From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aVsjF-00057u-FH for mharc-grub-devel@gnu.org; Tue, 16 Feb 2016 22:24:37 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVsjD-00056s-Bf for grub-devel@gnu.org; Tue, 16 Feb 2016 22:24:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVsj9-0002J4-6u for grub-devel@gnu.org; Tue, 16 Feb 2016 22:24:35 -0500 Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:33834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVsj8-0002Ir-QW for grub-devel@gnu.org; Tue, 16 Feb 2016 22:24:31 -0500 Received: by mail-lb0-x22c.google.com with SMTP id of3so2036013lbc.1 for ; Tue, 16 Feb 2016 19:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/0RkUAFk2aVKmyu6slLdn3/fO71E8eK6X02rtLK93UU=; b=NpstWgLHrAmQjgLCRt2Fz8QNx6hZJS/SHoRgMfv+PlrR9tk/h0snbW8yd9Y7bkdcg7 eWRcS4MXQ9M7VMtlS5EZeiZE45E6s3OrGwnnrY47Arec6NiNUfesY1bRUq31ADU1pJCl ZGOSiByWos3la4pA4/po8MsUUp3Ge7YTq6HOkPZJw2ifCzIbVGm+RAF5pxEG1/vH97DB gK/o1mctwtlX95WwN/AY7O7g9xBftpTMLTNoF7OIXta8dEoaqqluNePKZrOa8C5zj111 YW0viEDmhrJQ5IQ1bGwjQy0h9dgM3EUSuZ9H7+ynaSS0Itd99419+OMsr6xNd2f/CuBx lMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=/0RkUAFk2aVKmyu6slLdn3/fO71E8eK6X02rtLK93UU=; b=nM4Xz/6uKSAKRoqcA0+SwfkX6rswc79XJGzx1mgOCQjM9/aqMrx9a6Uc+v1rgrV8Xe jXoq/pORX91WE7BbXiMKbeBH0a6N4IT7OwQh8Q5/5iZUgtJ2zPX22I564CPrlT5kUE5a wLJpTml9C+PlEYq8ppsjqMx9X8vWtaHAtAQGFk85e6GcPfBiK2rH0HdlIO6cjfl8AnHs Yu41uWAwZYzc/vQm3YUccrL7/1+1AhGoJJHxlY4/7zPoHbVRTtLdeusvVAJFgrDv5Rrm HgxgebhKPYZqV4Xbtt/QQHMs9d/ICZEx77md3sKVOVfq9KWo7oA6RCXaMP9pr8hMgmnZ FkGQ== X-Gm-Message-State: AG10YOSbU+7NefJNAi7QJkWfQSqiOCgylW4Yvq0T/rdvp96CVjEp7Jy3S+AufHHtP/jRlA== X-Received: by 10.112.135.230 with SMTP id pv6mr11081248lbb.68.1455679470031; Tue, 16 Feb 2016 19:24:30 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id t5sm4604531lbg.15.2016.02.16.19.24.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 19:24:29 -0800 (PST) Subject: Re: [PATCH] sparc64: fix OF path names for sun4v systems To: The development of GNU GRUB References: <1455563481-87543-1-git-send-email-eric.snowberg@oracle.com> From: Andrei Borzenkov Message-ID: <56C3E7EB.7080606@gmail.com> Date: Wed, 17 Feb 2016 06:24:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22c Cc: Daniel Kiper X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 03:24:36 -0000 17.02.2016 05:02, Eric Snowberg пишет: > >> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov wrote: >> >> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg >> wrote: >>> Fix the open firmware path property for sun4v SPARC systems. These >>> platforms do not have a /sas/ within their path. Over time >>> different OF addressing schemes have been supported. There >>> is no generic addressing scheme that works across every HBA. >>> >>> Signed-off-by: Eric Snowberg >>> --- >>> grub-core/osdep/linux/ofpath.c | 192 +++++++++++++++++++++++++++++++++++++++- >>> 1 files changed, 190 insertions(+), 2 deletions(-) >>> >>> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c >>> index a79682a..de51c57 100644 >>> --- a/grub-core/osdep/linux/ofpath.c >>> +++ b/grub-core/osdep/linux/ofpath.c >> ... >>> @@ -444,6 +525,111 @@ of_path_of_scsi(const char *sys_devname __attribute__((unused)), const char *dev >>> } >>> else >>> { >>> +#ifdef __sparc__ >>> + int vendor = 0, device_id = 0; >>> + check_hba_identifiers(sysfs_path, &vendor, &device_id); >>> + >>> + if (vendor == 0x1000) /* LSI Logic Vendor ID */ >>> + { >>> + /* Over time different OF addressing schemes have been supported */ >>> + /* There is no generic addressing scheme that works across */ >>> + /* every HBA */ >>> + switch (device_id) >>> + { >>> + case 0x30: /* Rhea, Jasper 320, LSI53C1020/1030 */ >>> + case 0x50: /* SAS-1068E */ >>> + case 0x56: /* SAS-1064E */ >>> + case 0x58: /* Pandora SAS-1068E */ >>> + case 0x5d: /* Aspen, Invader, LSI SAS-3108 */ >>> + case 0x79: /* Niwot, SAS 2108 */ >> >> That really does not scale. Can we enumerate device aliases and take >> diskN and cdromN? So that we do not need to duplicate OBP logic? >> > > Do you have an idea in mind on how to do this differently to make it scale better? This patch will default to the old disk@N for unknown HBAs. I agree it doesn’t scale that well, but new HBAs for SPARC with OF support don't come out that often. > > Before this patch, there isn’t a single SAS HBA that is enumerated correctly on SPARC. I went back 10 years and believe I have added every HBA with OF support. This isn’t duplicating OBP logic. The final part of the device path is vendor specific. OBP does not control that part of the path, it just uses it. Unfortunately there isn’t a standard. This code only gets run during setup/install (not boot) to return the path for OBP to use. > > You mentioned cdroms being enumerated with cdromN. I believe that type of enumeration stopped with IDE drives. A USB cdrom would be enumerated something like this: > > /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0 > > So the function that runs during boot: check_string_removable does not identify the cdrom properly. > > I’m open to making any changes to this patch if you have some ideas in mind. I tried to base it off of what was already in ofpath.c and I have some follow on patches coming the rely on this path being correct. > I mean to read device aliases created by OBP (those displayed by devalias OBP command). disk0 /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0 ...