Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4640833imm; Mon, 14 May 2018 10:23:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp7b6JwHJeuudg9ycdelN3nEII8Aq9Y0j+OnzDM1dbe+rvO5UTorWIsM3ePCKE/tqlbPfOM X-Received: by 2002:a65:4484:: with SMTP id l4-v6mr8465772pgq.103.1526318606139; Mon, 14 May 2018 10:23:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526318606; cv=none; d=google.com; s=arc-20160816; b=tuErIkVC9hA/jKy7uRQBlo4OtUMI8yVpAE3fYbTjQVnlNYb9B7PAVq1V6PXbCYoQHs w2v4MFqJOhTx8/7cFVGBmT2gYH0us+BKkR6wE0PL/dWkjkPBFPeMJZrAmy0nyvs9Q5ME QMTNXhbNd05jNbVYV3a9Zy4uMKdaY6zFTmS/J+nLxY9EO94bUTa5vrxc5I8ZTBHe84Tv 9ktEs9FLe3VARs/qXBQ3TuVx0w6F47KD8aqqppT2+ushcKzEoSFdXciY9WQj77rtl5lV iqkF99seL9akbxu6zgXvwKrnqI/Ls7D0ag7AzY5T+aBQCKBvHVwBj9kjjiSFnNgPVoEU U2qw== 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 :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=QNINd99N/Q7idCDvfIWD18xtabzo4U7OLbdzfX3M+9k=; b=UCT7FFcLapPmFQx92aFlOrd/v7If0ofLHU1dh5feq3xDSdiUSxfRarFs0CPElV9+Zc 4jSsGmMzrjPacObp+PQfc7BZbbkGrc62DkJ3T6Q53XxeQfvf9Fo/Oiyme4Xvqw/gnpar PfsRUw5030K6knYFZ4M9KgoMVjKdOY845udhu8BOa13hheqTqAPRigShB0LnCSbDcVX0 ujKQBWumZzDPqvw5GRyY5YXiGp9E7MgKMoqX1cy5NincKCJilVgXgG91is0NMjzp+tkS NWFkRIH4kooJjHRgW+Y/4SXTCrSo4cBsACGmT4WZBEGRhvqaHnKKNxVv/vd+B2Uq+grD fPrg== 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 v24-v6si10424240pfj.292.2018.05.14.10.23.11; Mon, 14 May 2018 10:23:26 -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 S932365AbeENQNa (ORCPT + 99 others); Mon, 14 May 2018 12:13:30 -0400 Received: from mga18.intel.com ([134.134.136.126]:46802 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753582AbeENQN2 (ORCPT ); Mon, 14 May 2018 12:13:28 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 09:13:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,400,1520924400"; d="scan'208";a="55783844" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga001.jf.intel.com with ESMTP; 14 May 2018 09:13:25 -0700 Message-ID: Subject: Re: [PATCH v2] device property: Get rid of union aliasing From: Andy Shevchenko To: Lukas Wunner Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-efi@vger.kernel.org, Sakari Ailus , Mika Westerberg , "Rafael J . Wysocki" , ACPI Devel Maling List Date: Mon, 14 May 2018 19:13:24 +0300 In-Reply-To: <20180514154017.GA6734@wunner.de> References: <20180508131547.44366-1-andriy.shevchenko@linux.intel.com> <20180514121817.GA27869@wunner.de> <20180514154017.GA6734@wunner.de> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1-2 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 Mon, 2018-05-14 at 17:40 +0200, Lukas Wunner wrote: > On Mon, May 14, 2018 at 03:48:09PM +0300, Andy Shevchenko wrote: > > On Mon, 2018-05-14 at 14:18 +0200, Lukas Wunner wrote: > > > On Tue, May 08, 2018 at 04:15:47PM +0300, Andy Shevchenko wrote: > > > > --- a/drivers/firmware/efi/apple-properties.c > > > > +++ b/drivers/firmware/efi/apple-properties.c > > > > @@ -13,6 +13,9 @@ > > > > + * FIXME: The approach is still based on union aliasing and > > > > should be > > > > + * replaced by a proper resource provider. > > > > > > Why? All Apple EFI properties are either boolean or u8 arrays. > > > You've correctly changed this file to always supply u8 arrays, > > > so I don't see where union aliasing is happening here? > > > > Okay, for now I can see only Thunderbolt user of these properties > > (is it > > correct?) in upstream which uses u8 arrays indeed. > > That is correct, thunderbolt.ko is so far the only user. > > > > Though the implementation is quite fragile in this sense, because it > > doesn't discourage people to use device_property_read_string() in > > case > > when it's indeed a string (I saw these kind of properties in the > > very > > dump you posted on your GH page). > > Well if that is your concern then you need to prevent functions which > retrieve properties to use the wrong type. > > E.g. to prevent retrieval of the u8 array as string, you'd have to > amend drivers/base/property.c:pset_prop_read_string_array() to > check the type of the property found and return -EINVAL if it's not > string. I think it's doable. I will hack a new version later this week. But it still not a (best) solution for Apple properties. B/c as I told already I saw in _your_ dump the _string_ properties. Someone might have got an idea to use them as _strings_. -- Andy Shevchenko Intel Finland Oy