From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752429AbcDZH0c (ORCPT ); Tue, 26 Apr 2016 03:26:32 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:32971 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751433AbcDZH0a (ORCPT ); Tue, 26 Apr 2016 03:26:30 -0400 Date: Tue, 26 Apr 2016 09:26:29 +0200 From: Johan Hovold To: Konstantin Shkolnyy Cc: Johan Hovold , Konstantin Shkolnyy , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code. Message-ID: <20160426072629.GD22229@localhost> References: <1461517761-6240-1-git-send-email-konstantin.shkolnyy@gmail.com> <20160425101635.GI18866@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 25, 2016 at 06:09:01PM +0000, Konstantin Shkolnyy wrote: > I was planning to define all these bits in a separate future patch. > Would you rather prefer the magic numbers defined before fixing the bugs? Fixing the RTS bug (patch 1), which is the only "real" bug, should be done before adding defines, and fixing and cleaning up the rest. > I guess I can do that. Is something like this acceptable? > > /* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */ > struct cp210x_flow_ctl { > u8 SERIAL_DTR_MASK : 2; /* byte 0 */ > u8 : 1; > u8 SERIAL_CTS_HANDSHAKE : 1; > u8 SERIAL_DSR_HANDSHAKE : 1; > u8 SERIAL_DCD_HANDSHAKE : 1; > u8 SERIAL_DSR_SENSITIVITY : 1; > u8 : 1; > u8; /* byte 1 */ > u8; /* byte 2 */ > u8; /* byte 3 */ > u8 SERIAL_AUTO_TRANSMIT : 1; /* byte 4 */ > u8 SERIAL_AUTO_RECEIVE : 1; > u8 SERIAL_ERROR_CHAR : 1; > u8 SERIAL_NULL_STRIPPING : 1; > u8 SERIAL_BREAK_CHAR : 1; > u8 : 1; > u8 SERIAL_RTS_MASK : 2; > u8; /* byte 5 */ > u8; /* byte 6 */ > u8 : 7; /* byte 7 */ > u8 SERIAL_XOFF_CONTINUE : 1; > __le32 ulXonLimit; > __le32 ulXoffLimit; > } __packed; No, shouldn't rely on the layout of bitfields. Define masks and shifts as needed and the message structure as struct cp210x_flow_ctl { __le32 ulControlHandshake; __le32 ulFlowReplace; __le32 ulXonLimit; __le32 ulXoffLimit; }; that is, as per AN571. Thanks, Johan