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 3E63FC433F5 for ; Thu, 5 May 2022 18:02:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382941AbiEESFv (ORCPT ); Thu, 5 May 2022 14:05:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230386AbiEESFk (ORCPT ); Thu, 5 May 2022 14:05:40 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DAED4BFFC; Thu, 5 May 2022 11:02:00 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id be20so6073782edb.12; Thu, 05 May 2022 11:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9t4LNeKMgDm4bsG6VjPLo2oZxRoaM8DUvvm+HYE+R1M=; b=iJoOmgsIjvyuFihyonY0t0eMJ1r4WRq2au65ubOWz4svZ7uNke1xkh5TMl5Uk1C4ar UIY/BEIb559kc/8GA6AN2jZbtK3HJUgDyFcf8WYibLMc4HUxfjX6QN0xwUZxTH3bch5f TpiHeFKPDqdrDDweoPDKVkKe0H69aGPfNEBD0lxurv4GAGtssFoph6Z3LIYL2wxFRX8W l3guDXZ+n306XJnPKwzETB0ujHwqeVXGp3xpkZe1ZSLKJGvydMrE5OiDGzIL3LGVfVNK m9QhBxtqSxYy18lmWGr2EAHMM9HquaSsC1yXL1dJ2GxYlyf3YhgL6KBvi44ez6Sum4DJ JZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9t4LNeKMgDm4bsG6VjPLo2oZxRoaM8DUvvm+HYE+R1M=; b=wQgah8rVFW4z64LJm6bBhPN3qY1qM3VtVv095jFvGPIcvZXmScdWzXyHIZgW0B/Ou+ NFN9DzdYoEpXf+O8gPn3ePaLYEW4oxc/TLOqz4ZtQvvLdQ3nk4M6h+sb+ubb2LO59oM6 m6lNsoBN6ZZam0pII34pso21Ro5pM6mWuS2J1795gG3YnOD/pOm6utahn239IT+/46V0 O81rNKg0bBiPWfhu933RI93UCf0pzVVNzWRpxyKaef91/WfzOnoRa5HS6vevJ0jsCnRa kCclYCb6HXxqJJ27FwE7BwPxlqWhmhtIVtgIEj/uCCGOVGrFDQJ8wy23XUTqAsWAIXvh N/uw== X-Gm-Message-State: AOAM531ky5YN6yM6NKCIxFxLP4u5mJgj51dSVx5WXww+1h9mHl9i/BT/ vSbeireKuqg6uloUKKv89N9twhJjx8ot1QX3eo0= X-Google-Smtp-Source: ABdhPJwS8lSH9jpq6E2YTDJsT+UUIAttq51sN8ZOaVxn+s/4vminCmuIhkjtgAfiFHBrFFujkBJeOKFSZV9VWi3/Zok= X-Received: by 2002:aa7:d350:0:b0:425:e029:da56 with SMTP id m16-20020aa7d350000000b00425e029da56mr31711234edr.296.1651773718814; Thu, 05 May 2022 11:01:58 -0700 (PDT) MIME-Version: 1.0 References: <20220504133612.604304-1-Qing-wu.Li@leica-geosystems.com.cn> <20220504133612.604304-4-Qing-wu.Li@leica-geosystems.com.cn> In-Reply-To: From: Andy Shevchenko Date: Thu, 5 May 2022 20:01:22 +0200 Message-ID: Subject: Re: [PATCH V3 3/5] iio: accel: sca3300: modified to support multi chips To: LI Qingwu Cc: Jonathan Cameron , Lars-Peter Clausen , Rob Herring , Tomas Melin , devicetree , Linux Kernel Mailing List , linux-iio , Rob Herring Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 5, 2022 at 4:12 PM LI Qingwu wrote: > > -----Original Message----- > > From: Andy Shevchenko > > Sent: Wednesday, May 4, 2022 10:39 PM > > On Wed, May 4, 2022 at 4:35 PM LI Qingwu > > wrote: > > > > From: Andy Shevchenko > > > > Sent: Wednesday, May 4, 2022 10:20 PM On Wed, May 4, 2022 at 3:36 P= M > > > > LI Qingwu wrote: ... > > > > > +struct sca3300_chip_info { > > > > > + const struct iio_chan_spec *channels; > > > > > + const int (*accel_scale_table)[2]; > > > > > + const int *accel_scale_modes_map; > > > > > + const unsigned long *scan_masks; > > > > > + const int *avail_modes_table; > > > > > + const int *freq_modes_map; > > > > > + const int *freq_table; > > > > > + const u8 num_accel_scales; > > > > > + const u8 num_avail_modes; > > > > > + const u8 num_channels; > > > > > + const u8 num_freqs; > > > > > + const u8 chip_id; > > > > > > > > Why do you have const qualifier on all members? The last one is > > > > understandable, but the rest, esp. pointers should be justified. > > > Because I thought it was static and has fix value for each chip, unac= ceptable > > for you? > > > > But why const qualifier? What is the point of it for example for u8 mem= bers if > > the entire object is qualified as const below in the same patch? > > > > On top of that, please explain what in your opinion the "const ... > > *foo" gives us, and what we will lose if we remove the "const" part out= of them. > > Ah, you are right, those const are unnecessary for nonpointer members. > for the pointers, the contexts that the pointer points to are still writa= ble. > what about if I remove all the const from nonpointer and keep it for the = pointers? > Like=EF=BC=9A > const struct iio_chan_spec *channels; > const int (*accel_scale_table)[2]; > const int (*incli_scale_table)[2]; > const int *accel_scale_modes_map; > const int *incli_scale_modes_map; > const unsigned long *scan_masks; > const int *avail_modes_table; > const int *freq_modes_map; > const int *freq_table; > const char *name; > u8 num_accel_scales; > u8 num_incli_scales; > u8 num_avail_modes; > u8 num_channels; > u8 num_freqs; > u8 chip_id; > bool angle; It's better, but you still need to justify the rest with explanation in the commit message. And I leave this to maintainers to say if the const:s are needed or not. > > > > > + const char *name; > > > > > +}; --=20 With Best Regards, Andy Shevchenko