Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4819579imm; Mon, 14 May 2018 13:45:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZov758JZ/3JxqeIpde9eLI9MhDbEq4G3Sok007tg6ff0TeZPnUgabToNN966Td30xSprLZU X-Received: by 2002:a62:e30f:: with SMTP id g15-v6mr12013234pfh.68.1526330758303; Mon, 14 May 2018 13:45:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526330758; cv=none; d=google.com; s=arc-20160816; b=Ju0due4k2Nv2doJJ+dLlmbZK/x805nI9csw4jRzlE/l9FIuoB2QIa5XU89piwTW/or wqRxGxRRRKiCQ479BXSS1IA997hRvf1nIj2r2muk3TXFPSznczucns22ef3ovaclkugP xpZmprAoC9G/uOCRF54sLRGBN8sQ4VCxcif9F+rvWDkXK+J1aRwjsjoIqgR3lKXp9YzZ bf6h9KAdnb0McEbLXPiAShqx+VmGWaGF2Vhg7BPfwq/NuPKPzjMMipzdI/oTIb7KX/wH 9XYUhAfF54TVlq7yhKja9IWGteB/SE92jNZpi8wxcWF0ewz82yIsaWAqZ1vkevcIBdqj 9BKw== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=p8YADD0D2zfk82S+ydxjyo7dDsyzV1gwZ6EX+niLndo=; b=iWB0UkJJ/8Qdt5pec0/bhBZGxvqoTRKm+JseHhWABk835OSNvkuXNMBxxQiacR/02E P4/E77qlOF50Kgaluf9SDqskI0XYgfumC4xe/8+QFodaBMvcgbBphngEQ3/ulnWhX5U2 tABb1wdd/r3bMU3s2vcR819YzjHxETvZzjWBZUBN3su+ndHUKX6d5PdoYqqMYRHF8oKF wlnbdMMBCyZVqtsTs1jQBlQ2pUKKwdM7hOMJ5LzKKtm0DvfiuK8AwJdWO9IT7CKhYL7P YXXlQ3I6yAxjtj1b4sk9UG1N93w2Z3FXjEVX4f9aOW1v2pYScQDOY2a0Q0Wp6rvWwqa5 R9Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Tvqm3Wu/; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h62-v6si8241108pgc.548.2018.05.14.13.45.43; Mon, 14 May 2018 13:45:58 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Tvqm3Wu/; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752089AbeENUoz (ORCPT + 99 others); Mon, 14 May 2018 16:44:55 -0400 Received: from mail-ot0-f196.google.com ([74.125.82.196]:44472 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865AbeENUox (ORCPT ); Mon, 14 May 2018 16:44:53 -0400 Received: by mail-ot0-f196.google.com with SMTP id g7-v6so15902038otj.11; Mon, 14 May 2018 13:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=p8YADD0D2zfk82S+ydxjyo7dDsyzV1gwZ6EX+niLndo=; b=Tvqm3Wu/rpasLRE9tPkHD8CaUdm7Al8XiRJh0PumSB9NVZG4kZ5wieaVXgauJ/MD6W 5O4uVDaNLhz7i1FTVDxh2rjjEJVWk5hSzdPpF0A4J3lvwRcxXgWT0Bjn2bszMGU3L51Z qQSxi8tof5hywIkbRcdM3Ol8FtlbJCSp+S2EVk4VVJDzBDK8NZIzjxS9PkMK8c9vSfdu MsB2uKTr2C+Ix7GRFuGBDmfaUdgdp1Nof+3auxUBtxitNUIOJohTaLCqyKzeCj3vkWmi E+jR9KMB/eUstmzJX0Eb8fRcb7lEmlQs5R8sn6yZwr85/rVmAMJwERlqPc7Bb8Z0B1j1 Gl9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=p8YADD0D2zfk82S+ydxjyo7dDsyzV1gwZ6EX+niLndo=; b=teNXF+77OnNciG+0lm6uACiiBNwpDtTIo0nOWbocueaAzp1ys0TGg/VPjnEIj5p3N2 STJJ3pzwKuZVg/NUPgdIkcRoz+pmKX5oO8Z+5D5EA2zdK1HLBIbFEcd91a7/nqhj/XFO tQfPexmBhx2q5ByNyKFdYe8FEZvOoLGYPx3A0OQYL1Ggfft4ihNAWJq6Bw83mOewQKzv e06NzKOPwqDdT2RObG/bw7r/TNJ3+V4e2sim/D+6X3/+oJpaKwI7QXMl7A0qA3OJ85GF nkREKNkC3OOmtdRedIXNZr2TlAMV1Ag3URQ5OpykmI1CUcG0SQmoVHrBRa7eAD/JwSaR D5QQ== X-Gm-Message-State: ALKqPwfFi39Bq7quwJbHGqjH6IQvhjMxHA+jjFQ6+M9Nu8NRxyJ5aeYq VuJRSaa3xZfk7LucgPpZ0ZNBgkql4TGFyoOn7dc= X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr8710346otb.271.1526330692567; Mon, 14 May 2018 13:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Mon, 14 May 2018 13:44:52 -0700 (PDT) In-Reply-To: References: <20180508131547.44366-1-andriy.shevchenko@linux.intel.com> <20180514121817.GA27869@wunner.de> <20180514154017.GA6734@wunner.de> From: "Rafael J. Wysocki" Date: Mon, 14 May 2018 22:44:52 +0200 X-Google-Sender-Auth: 0S0kM7oi2YWFcXuEYkM5qOrn2ZI Message-ID: Subject: Re: [PATCH v2] device property: Get rid of union aliasing To: Andy Shevchenko Cc: Lukas Wunner , Greg Kroah-Hartman , Linux Kernel Mailing List , Ard Biesheuvel , linux-efi@vger.kernel.org, Sakari Ailus , Mika Westerberg , "Rafael J . Wysocki" , ACPI Devel Maling List 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 Mon, May 14, 2018 at 6:13 PM, Andy Shevchenko wrote: > 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. So I'm assuming that I should disregard this patch and wait for an update, right? Thanks, Rafael