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 9876DECAAD2 for ; Mon, 29 Aug 2022 12:27:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231424AbiH2M1L (ORCPT ); Mon, 29 Aug 2022 08:27:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229726AbiH2M0m (ORCPT ); Mon, 29 Aug 2022 08:26:42 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F3B191D1A; Mon, 29 Aug 2022 05:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661775027; x=1693311027; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=oxQnpIC7Es3fbk5Y7KL1o+zPbw4eWKeljrhF6pZeVsU=; b=c9n04zJXK+ylVyxhfduX1T3vms3s2gxOxI0408bWObExuazE+SAa2Jg3 FFwzXdnNAlhynWoe7iGgJQ12tMKPG3+h4zCdiV+6u9HPR9nlofpBSEDge /kvUtoVRPLSn4QrAePZMy4IKsfuuTuF+Z4yMSZDiFrhGAumz8FT8IChR8 PFDAZphQrY7wBjQEzDxjHt7mOtp3ZMXlteIqRDCCBZBiuEY9BcArQ553I ImrvBevAP+JL5HNgWY2FoG9RQkQaZk8iI9nJYjfvkswQh5v+RQ5YMl04x rJLwI0aBos8nIyNiCNkItqNTLTZ2F1/Qj6C2mhhOSCTOEMuk8iefO3ENA A==; X-IronPort-AV: E=McAfee;i="6500,9779,10454"; a="294886252" X-IronPort-AV: E=Sophos;i="5.93,272,1654585200"; d="scan'208";a="294886252" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2022 05:09:15 -0700 X-IronPort-AV: E=Sophos;i="5.93,272,1654585200"; d="scan'208";a="588142891" Received: from kvehmane-mobl1.ger.corp.intel.com ([10.251.220.41]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2022 05:09:08 -0700 Date: Mon, 29 Aug 2022 15:09:09 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Andy Shevchenko cc: Greg Kroah-Hartman , Jiri Slaby , "open list:SERIAL DRIVERS" , Jonathan Corbet , Andy Shevchenko , Vladimir Zapolskiy , Russell King , Richard Genoud , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Maxime Coquelin , Alexandre Torgue , Linux Documentation List , Linux Kernel Mailing List , linux-arm Mailing List , linux-stm32@st-md-mailman.stormreply.com, Lino Sanfilippo Subject: Re: [PATCH 3/3] serial: Add kserial_rs485 to avoid wasted space due to .padding In-Reply-To: Message-ID: <1712a4c5-638-4e63-af29-32bdcbaab443@linux.intel.com> References: <20220826144629.11507-1-ilpo.jarvinen@linux.intel.com> <20220826144629.11507-4-ilpo.jarvinen@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-174262208-1661774957=:1928" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-174262208-1661774957=:1928 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 26 Aug 2022, Andy Shevchenko wrote: > On Fri, Aug 26, 2022 at 5:51 PM Ilpo Järvinen > wrote: > > > -static int user_rs485_to_kernel_serial_rs485(struct serial_rs485 *rs485, > > +static int user_rs485_to_kernel_serial_rs485(struct kserial_rs485 *rs485, > > const struct serial_rs485 __user *rs485_user) > > { > > - if (copy_from_user(rs485, rs485_user, sizeof(*rs485))) > > + struct serial_rs485 rs485_uapi; > > + > > + if (copy_from_user(&rs485_uapi, rs485_user, sizeof(*rs485))) > > return -EFAULT; > > > + *rs485 = *((struct kserial_rs485 *)&rs485_uapi); > > So with all assets we have we can be sure that on BE64 / BE32 machines > this will be flawless. Is this assumption correct? I think so. At worst it could trigger a build fail assuming the kernel would do some really odd struct layout reordering (which, according to the build bot, doesn't occur for any currently tested arch). Now that you highlighted this line though, I started to wonder if it would be just better to use memcpy() instead as it would avoid those casts. > > + * padding. > > + */ > > +struct kserial_rs485 { > > + __u32 flags; /* RS485 feature flags */ > > + __u32 delay_rts_before_send; /* Delay before send (milliseconds) */ > > + __u32 delay_rts_after_send; /* Delay after send (milliseconds) */ > > + struct { > > + __u8 addr_recv; > > + __u8 addr_dest; > > + }; > > Btw, can't we convert them to kernel doc? Yes, why not. -- i. --8323329-174262208-1661774957=:1928--