From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.enpas.org (lighthouse.enpas.org [46.38.232.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F132E33D4FB; Thu, 28 May 2026 07:50:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.38.232.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779954624; cv=none; b=pbu3VeCIL21hvqaTFugt6oimAxTDnBvEac6EisN3fVTvfnomrpXtF6P8kTgFEgfdzuUKphx0H3lkS9MjpxW8smY93Z6fc0tDdQ67z4CU/YPkv3f4ViPA6jvzpcIdNJAQ26ZnJdtc20hLoWBbQhIzQc/1E5NtxppqH/yfoDfTXYo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779954624; c=relaxed/simple; bh=emc4zUX6NmJU4RwB16CYry5ahUhaV/+whFqF1fX3UvE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BmxZlhx9FZ8fRAKPDcFgpft8TV+OSWTgcREohsD8GBQSpdc+sQxef4VEMKu0A/sFVfKqDoeZFZA6tJMh6idc3ZEFMJDzVtAv0uoH+NQB450hxjtUaohnbQ24meF4khqlvbaMIY3kq7ABNTwgrEDWoJ+JyZCRcwYJmudlYnZfbUo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=enpas.org; spf=pass smtp.mailfrom=enpas.org; arc=none smtp.client-ip=46.38.232.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=enpas.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enpas.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.enpas.org (Postfix) with ESMTPSA id DB0D71035A4; Thu, 28 May 2026 07:50:13 +0000 (UTC) Message-ID: <0efedf54-9afb-483e-b830-4f69a3220108@enpas.org> Date: Thu, 28 May 2026 16:50:11 +0900 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 6/8] zorro: Simplify storing pointers in device id struct To: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= , Geert Uytterhoeven , Damien Le Moal , Niklas Cassel , "James E.J. Bottomley" , "Martin K. Petersen" , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Thomas Gleixner , Ingo Molnar , Andi Shyti , Helge Deller Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, "Christian A. Ehrhardt" , "Christian A. Ehrhardt" , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, netdev@vger.kernel.org, linux-i2c@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org References: <49576a7501128c93ef318566ed7faefce163f1fd.1779803053.git.u.kleine-koenig@baylibre.com> Content-Language: en-US From: Max Staudt In-Reply-To: <49576a7501128c93ef318566ed7faefce163f1fd.1779803053.git.u.kleine-koenig@baylibre.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/26/26 11:17 PM, Uwe Kleine-König (The Capable Hub) wrote: > Technically it is fine (on all current Linux architectures) to store a > pointer in an unsigned long variable. However this needs explicit > casting which is an easy source for type mismatches. > > By replacing the plain unsigned long .driver_data in struct > zorro_device_id by an anonymous union, most of the casting can be > dropped. There is still some implicit casting involved (between a void * > and a driver specific pointer type), but that's better than the approach > to store a pointer in an unsigned long variable as this doesn't lose the > information that the data being pointed to is const. > > All users of struct zorro_device_id are initialized in a way that is > compatible with the new definition, so no adaptions are needed there. > > Signed-off-by: Uwe Kleine-König (The Capable Hub) Thanks Uwe! Reviewed-by: Max Staudt