From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B7C9C47088 for ; Wed, 23 Nov 2022 23:24:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229922AbiKWXYo (ORCPT ); Wed, 23 Nov 2022 18:24:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229928AbiKWXYk (ORCPT ); Wed, 23 Nov 2022 18:24:40 -0500 Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FA3D1121C8; Wed, 23 Nov 2022 15:24:39 -0800 (PST) Date: Wed, 23 Nov 2022 23:24:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1669245874; x=1669505074; bh=4D7H7t9cQFG+vEXPzrmjxP0kBkCA637MqCW+lh8xlvo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hPbJVkIuL1M0qEmL0bT4PuPpgSPCUAu33Y+Qb7tdeEgjcQqAn2P9/FpfK16HEA2EM 7vjsfHf0eS2PmoRXdPNGezpmX314hJ02XB0zpjgzVkJDzPqhEL7AMChGfIwFpiPwIA NF7ZZEj1iGDIHy5p8DLkWQw2m5Qldpno4e6/JtLA16r0ZaA4hkUD/VeqWm5hbTdlnb BxWDFCkr77h+K0/o8YNYsqjLGq0ZWGeFJce25BsYm5wcKn9VpmO0zKAO32OE9aTevx yfP5UsPCKW2I3bqPQKJL7FqD0bhsWsXV2qxdqiRQ7WsVWh4oHNK9TFNBq0m4+w4lGn bmQFT/VhhjM8A== To: Greg Kroah-Hartman From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: Jason Gunthorpe , Matthew Wilcox , Maximilian Luz , Andy Shevchenko , linux-kernel@vger.kernel.org, Jens Axboe , "Rafael J. Wysocki" , Len Brown , Stefan Richter , Wolfram Sang , Alexandre Belloni , Dmitry Torokhov , Sean Young , Mauro Carvalho Chehab , Rob Herring , Frank Rowand , Hans de Goede , Mark Gross , Vinod Koul , Bard Liao , Pierre-Louis Bossart , Sanyog Kale , Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , Jiri Slaby , Heikki Krogerus , "Martin K. Petersen" , Chaitanya Kulkarni , Ming Lei , Jilin Yuan , Alan Stern , Sakari Ailus , Thomas Gleixner , Ira Weiny , Dan Williams , Won Chung , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-block@vger.kernel.org, linux-i2c@vger.kernel.org, linux-i3c@lists.infradead.org, linux-input@vger.kernel.org, linux-media@vger.kernel.org, linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, linux1394-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const * Message-ID: In-Reply-To: References: Feedback-ID: 20568564:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Hi 2022. november 23., szerda 20:06 keltez=C3=A9ssel, Greg Kroah-Hartman = =C3=ADrta: > On Wed, Nov 23, 2022 at 02:25:59PM -0400, Jason Gunthorpe wrote: >=20 > > On Wed, Nov 23, 2022 at 07:10:49PM +0100, Greg Kroah-Hartman wrote: > >=20 > > > On Wed, Nov 23, 2022 at 05:49:36PM +0000, Matthew Wilcox wrote: > > >=20 > > > > On Wed, Nov 23, 2022 at 01:29:56PM -0400, Jason Gunthorpe wrote: > > > >=20 > > > > > #define generic_container_of(in_type, in, out_type, out_member) \ > > > > > _Generic(in, \ > > > > > const in_type *: ((const out_type *)container_of(in, out_type, ou= t_member)), \ > > > > > in_type *: ((out_type *)container_of(in, out_type, out_member)) \ > > > > > ) > > > >=20 > > > > There's a neat trick I found in seqlock.h: > > > >=20 > > > > #define generic_container_of(in_t, in, out_t, m) \ > > > > _Generic(*(in), \ > > > > const in_t: ((const out_t *)container_of(in, out_t, m)), \ > > > > in_t: ((out_t *)container_of(in, out_type, m)) \ > > > > ) > > > >=20 > > > > and now it fits in 80 columns ;-) > > >=20 > > > Nice trick! Dropping the inline functions is a bit different, let me > > > see if that still gives a sane error if we pass an incorrect type or > > > mess with the const * the wrong way. I'll run some tests tomorrow > > > afternoon... > >=20 > > The errors in some cases are very verbose, but it is somewhat > > understandable - the worst is when _Generic fails to match anything, > > but also at least clang partially expanded container_of and it throws > > other assertions too. > >=20 > > I also wonder if this could just be rolled into the normal > > container_of. >=20 >=20 > I think we might be able to now, my previous attempts with inline > functions prevented that. I'll beat on that tomorrow... >=20 > > in_type would have to be derived like: > >=20 > > in_type =3D typeof((out_type *)NULL)->out_member) > >=20 > > But I don't know if you can use typeof in a generic type matching expre= ssion.. >=20 >=20 > Maybe that is what threw me before, I can't remember. I do know we > tried a number of different attempts, can't recall the failed ones... >=20 I am sorry I haven't followed the previous discussion, but has something like the following been considered? #define container_of2(ptr, type, member) \ =09_Generic((ptr), \ =09=09typeof_member(const type, member) *: container_of((ptr), const type= , member), \ =09=09const void *: container_of((ptr), const type, member), \ =09=09default: container_of((ptr), type, member) \ =09) This is not perfect by any means, but I believe it is a reasonable improvement. It only really works reliably if the member type and the specified `type` in the arguments are unqualified, but I believe that should cover the majority of cases. I have tried to build an x86-64 defconfig with this and there are numerous const violations, but I haven't seen any false positives. > [...] Regards, Barnab=C3=A1s P=C5=91cze From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C90FEC6370A for ; Fri, 25 Nov 2022 21:21:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:From:To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ut8wxhNzFOwAyXtzMcmRJVVnyBRaAsMd7itFa/Ue5ZM=; b=pFGEEepAF7XVuE 6XipWPFrRy2c0UkghW+GohLIgDYTTGsNYqdJt2D2gOV5QZmTbAYl1g3l75HzmI+9b42yw2VFjU0HB QL5BDQMYkFdobWIj+DdgbI1ahDZzWD29Xft4EA54PCx6bn1/5P2rV7fw+oc0SrdLZ38QPAzqDvwVi TwZNzW2Cf/TcP6k1Wp7XlbJi55uhuILTPDR5q/86IUzIKSowRq7An7Iva7wAcsB/y6XRD4HCA96Le QJak7BFlCpMx0TCG/ZrpLCsofoslr6nHEASEhV9Gooz7Ej0yRkZ6ea/2t2k/SNxMBZZDGXyHNFI5k nMAnnpICSrElg2c4n41Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oyg8K-002E6h-6y; Fri, 25 Nov 2022 21:21:16 +0000 Received: from mail-4322.protonmail.ch ([185.70.43.22]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxz6e-002s2Y-OO for linux-i3c@lists.infradead.org; Wed, 23 Nov 2022 23:24:42 +0000 Date: Wed, 23 Nov 2022 23:24:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1669245874; x=1669505074; bh=4D7H7t9cQFG+vEXPzrmjxP0kBkCA637MqCW+lh8xlvo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hPbJVkIuL1M0qEmL0bT4PuPpgSPCUAu33Y+Qb7tdeEgjcQqAn2P9/FpfK16HEA2EM 7vjsfHf0eS2PmoRXdPNGezpmX314hJ02XB0zpjgzVkJDzPqhEL7AMChGfIwFpiPwIA NF7ZZEj1iGDIHy5p8DLkWQw2m5Qldpno4e6/JtLA16r0ZaA4hkUD/VeqWm5hbTdlnb BxWDFCkr77h+K0/o8YNYsqjLGq0ZWGeFJce25BsYm5wcKn9VpmO0zKAO32OE9aTevx yfP5UsPCKW2I3bqPQKJL7FqD0bhsWsXV2qxdqiRQ7WsVWh4oHNK9TFNBq0m4+w4lGn bmQFT/VhhjM8A== To: Greg Kroah-Hartman From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: Jason Gunthorpe , Matthew Wilcox , Maximilian Luz , Andy Shevchenko , linux-kernel@vger.kernel.org, Jens Axboe , "Rafael J. Wysocki" , Len Brown , Stefan Richter , Wolfram Sang , Alexandre Belloni , Dmitry Torokhov , Sean Young , Mauro Carvalho Chehab , Rob Herring , Frank Rowand , Hans de Goede , Mark Gross , Vinod Koul , Bard Liao , Pierre-Louis Bossart , Sanyog Kale , Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , Jiri Slaby , Heikki Krogerus , "Martin K. Petersen" , Chaitanya Kulkarni , Ming Lei , Jilin Yuan , Alan Stern , Sakari Ailus , Thomas Gleixner , Ira Weiny , Dan Williams , Won Chung , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-block@vger.kernel.org, linux-i2c@vger.kernel.org, linux-i3c@lists.infradead.org, linux-input@vger.kernel.org, linux-media@vger.kernel.org, linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, linux1394-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const * Message-ID: In-Reply-To: References: Feedback-ID: 20568564:user:proton MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221123_152440_984493_40C2FC5F X-CRM114-Status: GOOD ( 26.85 ) X-Mailman-Approved-At: Fri, 25 Nov 2022 13:21:10 -0800 X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org CkhpCgoKMjAyMi4gbm92ZW1iZXIgMjMuLCBzemVyZGEgMjA6MDYga2VsdGV6w6lzc2VsLCBHcmVn IEtyb2FoLUhhcnRtYW4gw61ydGE6CgoKPiBPbiBXZWQsIE5vdiAyMywgMjAyMiBhdCAwMjoyNTo1 OVBNIC0wNDAwLCBKYXNvbiBHdW50aG9ycGUgd3JvdGU6Cj4gCj4gPiBPbiBXZWQsIE5vdiAyMywg MjAyMiBhdCAwNzoxMDo0OVBNICswMTAwLCBHcmVnIEtyb2FoLUhhcnRtYW4gd3JvdGU6Cj4gPiAK PiA+ID4gT24gV2VkLCBOb3YgMjMsIDIwMjIgYXQgMDU6NDk6MzZQTSArMDAwMCwgTWF0dGhldyBX aWxjb3ggd3JvdGU6Cj4gPiA+IAo+ID4gPiA+IE9uIFdlZCwgTm92IDIzLCAyMDIyIGF0IDAxOjI5 OjU2UE0gLTA0MDAsIEphc29uIEd1bnRob3JwZSB3cm90ZToKPiA+ID4gPiAKPiA+ID4gPiA+ICNk ZWZpbmUgZ2VuZXJpY19jb250YWluZXJfb2YoaW5fdHlwZSwgaW4sIG91dF90eXBlLCBvdXRfbWVt YmVyKSBcCj4gPiA+ID4gPiBfR2VuZXJpYyhpbiwgXAo+ID4gPiA+ID4gY29uc3QgaW5fdHlwZSAq OiAoKGNvbnN0IG91dF90eXBlICopY29udGFpbmVyX29mKGluLCBvdXRfdHlwZSwgb3V0X21lbWJl cikpLCBcCj4gPiA+ID4gPiBpbl90eXBlICo6ICgob3V0X3R5cGUgKiljb250YWluZXJfb2YoaW4s IG91dF90eXBlLCBvdXRfbWVtYmVyKSkgXAo+ID4gPiA+ID4gKQo+ID4gPiA+IAo+ID4gPiA+IFRo ZXJlJ3MgYSBuZWF0IHRyaWNrIEkgZm91bmQgaW4gc2VxbG9jay5oOgo+ID4gPiA+IAo+ID4gPiA+ ICNkZWZpbmUgZ2VuZXJpY19jb250YWluZXJfb2YoaW5fdCwgaW4sIG91dF90LCBtKSBcCj4gPiA+ ID4gX0dlbmVyaWMoKihpbiksIFwKPiA+ID4gPiBjb25zdCBpbl90OiAoKGNvbnN0IG91dF90ICop Y29udGFpbmVyX29mKGluLCBvdXRfdCwgbSkpLCBcCj4gPiA+ID4gaW5fdDogKChvdXRfdCAqKWNv bnRhaW5lcl9vZihpbiwgb3V0X3R5cGUsIG0pKSBcCj4gPiA+ID4gKQo+ID4gPiA+IAo+ID4gPiA+ IGFuZCBub3cgaXQgZml0cyBpbiA4MCBjb2x1bW5zIDstKQo+ID4gPiAKPiA+ID4gTmljZSB0cmlj ayEgRHJvcHBpbmcgdGhlIGlubGluZSBmdW5jdGlvbnMgaXMgYSBiaXQgZGlmZmVyZW50LCBsZXQg bWUKPiA+ID4gc2VlIGlmIHRoYXQgc3RpbGwgZ2l2ZXMgYSBzYW5lIGVycm9yIGlmIHdlIHBhc3Mg YW4gaW5jb3JyZWN0IHR5cGUgb3IKPiA+ID4gbWVzcyB3aXRoIHRoZSBjb25zdCAqIHRoZSB3cm9u ZyB3YXkuIEknbGwgcnVuIHNvbWUgdGVzdHMgdG9tb3Jyb3cKPiA+ID4gYWZ0ZXJub29uLi4uCj4g PiAKPiA+IFRoZSBlcnJvcnMgaW4gc29tZSBjYXNlcyBhcmUgdmVyeSB2ZXJib3NlLCBidXQgaXQg aXMgc29tZXdoYXQKPiA+IHVuZGVyc3RhbmRhYmxlIC0gdGhlIHdvcnN0IGlzIHdoZW4gX0dlbmVy aWMgZmFpbHMgdG8gbWF0Y2ggYW55dGhpbmcsCj4gPiBidXQgYWxzbyBhdCBsZWFzdCBjbGFuZyBw YXJ0aWFsbHkgZXhwYW5kZWQgY29udGFpbmVyX29mIGFuZCBpdCB0aHJvd3MKPiA+IG90aGVyIGFz c2VydGlvbnMgdG9vLgo+ID4gCj4gPiBJIGFsc28gd29uZGVyIGlmIHRoaXMgY291bGQganVzdCBi ZSByb2xsZWQgaW50byB0aGUgbm9ybWFsCj4gPiBjb250YWluZXJfb2YuCj4gCj4gCj4gSSB0aGlu ayB3ZSBtaWdodCBiZSBhYmxlIHRvIG5vdywgbXkgcHJldmlvdXMgYXR0ZW1wdHMgd2l0aCBpbmxp bmUKPiBmdW5jdGlvbnMgcHJldmVudGVkIHRoYXQuIEknbGwgYmVhdCBvbiB0aGF0IHRvbW9ycm93 Li4uCj4gCj4gPiBpbl90eXBlIHdvdWxkIGhhdmUgdG8gYmUgZGVyaXZlZCBsaWtlOgo+ID4gCj4g PiBpbl90eXBlID0gdHlwZW9mKChvdXRfdHlwZSAqKU5VTEwpLT5vdXRfbWVtYmVyKQo+ID4gCj4g PiBCdXQgSSBkb24ndCBrbm93IGlmIHlvdSBjYW4gdXNlIHR5cGVvZiBpbiBhIGdlbmVyaWMgdHlw ZSBtYXRjaGluZyBleHByZXNzaW9uLi4KPiAKPiAKPiBNYXliZSB0aGF0IGlzIHdoYXQgdGhyZXcg bWUgYmVmb3JlLCBJIGNhbid0IHJlbWVtYmVyLiBJIGRvIGtub3cgd2UKPiB0cmllZCBhIG51bWJl ciBvZiBkaWZmZXJlbnQgYXR0ZW1wdHMsIGNhbid0IHJlY2FsbCB0aGUgZmFpbGVkIG9uZXMuLi4K PiAKCkkgYW0gc29ycnkgSSBoYXZlbid0IGZvbGxvd2VkIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9u LApidXQgaGFzIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgYmVlbiBjb25zaWRlcmVkPwoK ICAjZGVmaW5lIGNvbnRhaW5lcl9vZjIocHRyLCB0eXBlLCBtZW1iZXIpIFwKICAJX0dlbmVyaWMo KHB0ciksIFwKICAJCXR5cGVvZl9tZW1iZXIoY29uc3QgdHlwZSwgbWVtYmVyKSAqOiBjb250YWlu ZXJfb2YoKHB0ciksIGNvbnN0IHR5cGUsIG1lbWJlciksIFwKICAJCWNvbnN0IHZvaWQgKjogY29u dGFpbmVyX29mKChwdHIpLCBjb25zdCB0eXBlLCBtZW1iZXIpLCBcCiAgCQlkZWZhdWx0OiBjb250 YWluZXJfb2YoKHB0ciksIHR5cGUsIG1lbWJlcikgXAogIAkpCgpUaGlzIGlzIG5vdCBwZXJmZWN0 IGJ5IGFueSBtZWFucywgYnV0IEkgYmVsaWV2ZSBpdCBpcyBhIHJlYXNvbmFibGUKaW1wcm92ZW1l bnQuIEl0IG9ubHkgcmVhbGx5IHdvcmtzIHJlbGlhYmx5IGlmIHRoZSBtZW1iZXIgdHlwZSBhbmQK dGhlIHNwZWNpZmllZCBgdHlwZWAgaW4gdGhlIGFyZ3VtZW50cyBhcmUgdW5xdWFsaWZpZWQsCmJ1 dCBJIGJlbGlldmUgdGhhdCBzaG91bGQgY292ZXIgdGhlIG1ham9yaXR5IG9mIGNhc2VzLgoKSSBo YXZlIHRyaWVkIHRvIGJ1aWxkIGFuIHg4Ni02NCBkZWZjb25maWcgd2l0aCB0aGlzIGFuZCB0aGVy ZSBhcmUKbnVtZXJvdXMgY29uc3QgdmlvbGF0aW9ucywgYnV0IEkgaGF2ZW4ndCBzZWVuIGFueSBm YWxzZSBwb3NpdGl2ZXMuCgoKPiBbLi4uXQoKClJlZ2FyZHMsCkJhcm5hYsOhcyBQxZFjemUKCi0t IApsaW51eC1pM2MgbWFpbGluZyBsaXN0CmxpbnV4LWkzY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0 dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtaTNjCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29633C4332F for ; Sat, 26 Nov 2022 08:14:59 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 0A46E18D5; Sat, 26 Nov 2022 09:14:07 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 0A46E18D5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1669450497; bh=aY6fpFlBsrseLUokyVITOdHrAVLXpcebwFFMAgJ+/es=; h=Date:To:From:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=hZnIM68CwqUdkpdiU/F2u+i+MVro2DC2bHf1Xhsf8N9iOVPIXagdoZa6OjB4YsJRh CYc4Dm6wvpeYJBCTv0jm76eFsgEUgppm1VN9CW0ncktYKGZcG2Wggdd/HaOPdiQXNA 1UnBQVfqVIvOwomdKMyAPtVorL8yfzmxkNmpF5FY= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 57851F80720; Sat, 26 Nov 2022 08:59:32 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id C5081F8025D; Thu, 24 Nov 2022 00:24:38 +0100 (CET) Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 65111F80149 for ; Thu, 24 Nov 2022 00:24:35 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 65111F80149 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="hPbJVkIu" Date: Wed, 23 Nov 2022 23:24:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1669245874; x=1669505074; bh=4D7H7t9cQFG+vEXPzrmjxP0kBkCA637MqCW+lh8xlvo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hPbJVkIuL1M0qEmL0bT4PuPpgSPCUAu33Y+Qb7tdeEgjcQqAn2P9/FpfK16HEA2EM 7vjsfHf0eS2PmoRXdPNGezpmX314hJ02XB0zpjgzVkJDzPqhEL7AMChGfIwFpiPwIA NF7ZZEj1iGDIHy5p8DLkWQw2m5Qldpno4e6/JtLA16r0ZaA4hkUD/VeqWm5hbTdlnb BxWDFCkr77h+K0/o8YNYsqjLGq0ZWGeFJce25BsYm5wcKn9VpmO0zKAO32OE9aTevx yfP5UsPCKW2I3bqPQKJL7FqD0bhsWsXV2qxdqiRQ7WsVWh4oHNK9TFNBq0m4+w4lGn bmQFT/VhhjM8A== To: Greg Kroah-Hartman From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const * Message-ID: In-Reply-To: References: Feedback-ID: 20568564:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 26 Nov 2022 08:58:52 +0100 Cc: Alexandre Belloni , Heikki Krogerus , Sean Young , "Rafael J. Wysocki" , alsa-devel@alsa-project.org, platform-driver-x86@vger.kernel.org, linux-i2c@vger.kernel.org, Andreas Noever , linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, Frank Rowand , Dan Williams , Andy Shevchenko , linux-acpi@vger.kernel.org, Bard Liao , Pierre-Louis Bossart , Matthew Wilcox , Jason Gunthorpe , Alan Stern , linux-serial@vger.kernel.org, linux-input@vger.kernel.org, Won Chung , Len Brown , devicetree@vger.kernel.org, Chaitanya Kulkarni , Ira Weiny , Michael Jamet , Ming Lei , Mark Gross , Hans de Goede , Rob Herring , Jiri Slaby , Thomas Gleixner , Mauro Carvalho Chehab , Mika Westerberg , Jens Axboe , linux-block@vger.kernel.org, Jilin Yuan , "Martin K. Petersen" , Dmitry Torokhov , linux-kernel@vger.kernel.org, Wolfram Sang , Vinod Koul , Stefan Richter , Sakari Ailus , Yehezkel Bernat , Sanyog Kale , linux-media@vger.kernel.org, Maximilian Luz , linux-usb@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi 2022. november 23., szerda 20:06 keltez=C3=A9ssel, Greg Kroah-Hartman = =C3=ADrta: > On Wed, Nov 23, 2022 at 02:25:59PM -0400, Jason Gunthorpe wrote: >=20 > > On Wed, Nov 23, 2022 at 07:10:49PM +0100, Greg Kroah-Hartman wrote: > >=20 > > > On Wed, Nov 23, 2022 at 05:49:36PM +0000, Matthew Wilcox wrote: > > >=20 > > > > On Wed, Nov 23, 2022 at 01:29:56PM -0400, Jason Gunthorpe wrote: > > > >=20 > > > > > #define generic_container_of(in_type, in, out_type, out_member) \ > > > > > _Generic(in, \ > > > > > const in_type *: ((const out_type *)container_of(in, out_type, ou= t_member)), \ > > > > > in_type *: ((out_type *)container_of(in, out_type, out_member)) \ > > > > > ) > > > >=20 > > > > There's a neat trick I found in seqlock.h: > > > >=20 > > > > #define generic_container_of(in_t, in, out_t, m) \ > > > > _Generic(*(in), \ > > > > const in_t: ((const out_t *)container_of(in, out_t, m)), \ > > > > in_t: ((out_t *)container_of(in, out_type, m)) \ > > > > ) > > > >=20 > > > > and now it fits in 80 columns ;-) > > >=20 > > > Nice trick! Dropping the inline functions is a bit different, let me > > > see if that still gives a sane error if we pass an incorrect type or > > > mess with the const * the wrong way. I'll run some tests tomorrow > > > afternoon... > >=20 > > The errors in some cases are very verbose, but it is somewhat > > understandable - the worst is when _Generic fails to match anything, > > but also at least clang partially expanded container_of and it throws > > other assertions too. > >=20 > > I also wonder if this could just be rolled into the normal > > container_of. >=20 >=20 > I think we might be able to now, my previous attempts with inline > functions prevented that. I'll beat on that tomorrow... >=20 > > in_type would have to be derived like: > >=20 > > in_type =3D typeof((out_type *)NULL)->out_member) > >=20 > > But I don't know if you can use typeof in a generic type matching expre= ssion.. >=20 >=20 > Maybe that is what threw me before, I can't remember. I do know we > tried a number of different attempts, can't recall the failed ones... >=20 I am sorry I haven't followed the previous discussion, but has something like the following been considered? #define container_of2(ptr, type, member) \ =09_Generic((ptr), \ =09=09typeof_member(const type, member) *: container_of((ptr), const type= , member), \ =09=09const void *: container_of((ptr), const type, member), \ =09=09default: container_of((ptr), type, member) \ =09) This is not perfect by any means, but I believe it is a reasonable improvement. It only really works reliably if the member type and the specified `type` in the arguments are unqualified, but I believe that should cover the majority of cases. I have tried to build an x86-64 defconfig with this and there are numerous const violations, but I haven't seen any false positives. > [...] Regards, Barnab=C3=A1s P=C5=91cze