From: Arnd Bergmann <arnd@arndb.de> To: Alex Elder <elder@linaro.org> Cc: David Miller <davem@davemloft.net>, Bjorn Andersson <bjorn.andersson@linaro.org>, Ilias Apalodimas <ilias.apalodimas@linaro.org>, Networking <netdev@vger.kernel.org>, DTML <devicetree@vger.kernel.org>, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, syadagir@codeaurora.org, mjavid@codeaurora.org, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com> Subject: Re: [RFC PATCH 12/12] soc: qcom: ipa: build and "ipa_i.h" Date: Wed, 7 Nov 2018 13:34:56 +0100 [thread overview] Message-ID: <CAK8P3a2X1zstSWP89uDxyf+rvyzzDY98_cvE4fzc-ZGbyVz23w@mail.gmail.com> (raw) In-Reply-To: <20181107003250.5832-13-elder@linaro.org> On Wed, Nov 7, 2018 at 1:33 AM Alex Elder <elder@linaro.org> wrote: > +config IPA_ASSERT > + bool "Enable IPA assertions" > + depends on IPA > + default y > + help > + Incorporate IPA assertion verification in the build. This > + cause various design assumptions to be checked at runtime, > + generating a report (and a crash) if any assumed condition > + does not hold. You may wish to disable this to avoid the > + overhead of checking. Maybe remove this from the submission. > +#define ipa_debug(fmt, args...) dev_dbg(ipa_ctx->dev, fmt, ## args) > +#define ipa_err(fmt, args...) dev_err(ipa_ctx->dev, fmt, ## args) These macros refer to variables in the caller that are not passed as arguments, which is generally a bad idea. They also trivially wrap a standard kernel interface, so better just that directly. > +#define ipa_bug() \ > + do { \ > + ipa_err("an unrecoverable error has occurred\n"); \ > + BUG(); \ > + } while (0) > + > +#define ipa_bug_on(condition) \ > + do { \ > + if (condition) { \ > + ipa_err("ipa_bug_on(%s) failed!\n", #condition); \ > + ipa_bug(); \ > + } \ > + } while (0) According to a discussion at the kernel summit, we should generally try to avoid BUG() as it rarely does anything useful: it crashes the current task, but in a network driver that usually means killing the entire kernel since you are not in process context. Try questioning each one to see if it can possibly happen, or if the code can be rewritten in a way to guarantee that it cannot. If continuing after the bug was detected does not cause a security hole or permanent data corruption, you can also use WARN_ON() or WARN_ONCE() (without a wrapper). > +int ipa_wwan_init(void); > +void ipa_wwan_cleanup(void); > + > +int ipa_stop_gsi_channel(u32 ep_id); > + > +void ipa_cfg_ep(u32 ep_id); > + > +int ipa_tx_dp(enum ipa_client_type dst, struct sk_buff *skb); > + > +bool ipa_endp_aggr_support(u32 ep_id); > +enum ipa_seq_type ipa_endp_seq_type(u32 ep_id); > + > +void ipa_endp_init_hdr_cons(u32 ep_id, u32 header_size, > + u32 metadata_offset, u32 length_offset); > +void ipa_endp_init_hdr_prod(u32 ep_id, u32 header_size, > + u32 metadata_offset, u32 length_offset); I'm surprised to see many functions that don't take a pointer to an instance as the first argument, which often indicates that you have global state variables and the driver won't work with multiple hardware instances. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 12/12] soc: qcom: ipa: build and "ipa_i.h" Date: Wed, 7 Nov 2018 13:34:56 +0100 [thread overview] Message-ID: <CAK8P3a2X1zstSWP89uDxyf+rvyzzDY98_cvE4fzc-ZGbyVz23w@mail.gmail.com> (raw) In-Reply-To: <20181107003250.5832-13-elder@linaro.org> On Wed, Nov 7, 2018 at 1:33 AM Alex Elder <elder@linaro.org> wrote: > +config IPA_ASSERT > + bool "Enable IPA assertions" > + depends on IPA > + default y > + help > + Incorporate IPA assertion verification in the build. This > + cause various design assumptions to be checked at runtime, > + generating a report (and a crash) if any assumed condition > + does not hold. You may wish to disable this to avoid the > + overhead of checking. Maybe remove this from the submission. > +#define ipa_debug(fmt, args...) dev_dbg(ipa_ctx->dev, fmt, ## args) > +#define ipa_err(fmt, args...) dev_err(ipa_ctx->dev, fmt, ## args) These macros refer to variables in the caller that are not passed as arguments, which is generally a bad idea. They also trivially wrap a standard kernel interface, so better just that directly. > +#define ipa_bug() \ > + do { \ > + ipa_err("an unrecoverable error has occurred\n"); \ > + BUG(); \ > + } while (0) > + > +#define ipa_bug_on(condition) \ > + do { \ > + if (condition) { \ > + ipa_err("ipa_bug_on(%s) failed!\n", #condition); \ > + ipa_bug(); \ > + } \ > + } while (0) According to a discussion at the kernel summit, we should generally try to avoid BUG() as it rarely does anything useful: it crashes the current task, but in a network driver that usually means killing the entire kernel since you are not in process context. Try questioning each one to see if it can possibly happen, or if the code can be rewritten in a way to guarantee that it cannot. If continuing after the bug was detected does not cause a security hole or permanent data corruption, you can also use WARN_ON() or WARN_ONCE() (without a wrapper). > +int ipa_wwan_init(void); > +void ipa_wwan_cleanup(void); > + > +int ipa_stop_gsi_channel(u32 ep_id); > + > +void ipa_cfg_ep(u32 ep_id); > + > +int ipa_tx_dp(enum ipa_client_type dst, struct sk_buff *skb); > + > +bool ipa_endp_aggr_support(u32 ep_id); > +enum ipa_seq_type ipa_endp_seq_type(u32 ep_id); > + > +void ipa_endp_init_hdr_cons(u32 ep_id, u32 header_size, > + u32 metadata_offset, u32 length_offset); > +void ipa_endp_init_hdr_prod(u32 ep_id, u32 header_size, > + u32 metadata_offset, u32 length_offset); I'm surprised to see many functions that don't take a pointer to an instance as the first argument, which often indicates that you have global state variables and the driver won't work with multiple hardware instances. Arnd
next prev parent reply other threads:[~2018-11-07 12:34 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-07 0:32 [RFC PATCH 00/12] net: introduce Qualcomm IPA driver Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 01/12] dt-bindings: soc: qcom: add IPA bindings Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 11:50 ` Arnd Bergmann 2018-11-07 11:50 ` Arnd Bergmann 2018-11-09 22:38 ` Alex Elder 2018-11-09 22:38 ` Alex Elder 2018-11-07 14:59 ` Rob Herring 2018-11-07 14:59 ` Rob Herring 2018-11-09 22:38 ` Alex Elder 2018-11-09 22:38 ` Alex Elder 2018-11-11 1:40 ` Rob Herring 2018-11-11 1:40 ` Rob Herring 2018-11-11 1:40 ` Rob Herring 2018-11-13 16:28 ` Alex Elder 2018-11-13 16:28 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 02/12] soc: qcom: ipa: DMA helpers Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 12:17 ` Arnd Bergmann 2018-11-07 12:17 ` Arnd Bergmann 2018-11-13 16:33 ` Alex Elder 2018-11-13 16:33 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 03/12] soc: qcom: ipa: generic software interface Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 04/12] soc: qcom: ipa: immediate commands Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 14:36 ` Arnd Bergmann 2018-11-07 14:36 ` Arnd Bergmann 2018-11-13 16:58 ` Alex Elder 2018-11-13 16:58 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 05/12] soc: qcom: ipa: IPA interrupts and the microcontroller Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 06/12] soc: qcom: ipa: QMI modem communication Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 07/12] soc: qcom: ipa: IPA register abstraction Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 15:00 ` Arnd Bergmann 2018-11-07 15:00 ` Arnd Bergmann 2018-11-15 2:48 ` Alex Elder 2018-11-15 2:48 ` Alex Elder 2018-11-15 14:42 ` Arnd Bergmann 2018-11-15 14:42 ` Arnd Bergmann 2018-11-07 0:32 ` [RFC PATCH 08/12] soc: qcom: ipa: utility functions Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 09/12] soc: qcom: ipa: main IPA source file Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 14:08 ` Arnd Bergmann 2018-11-07 14:08 ` Arnd Bergmann 2018-11-15 3:11 ` Alex Elder 2018-11-15 3:11 ` Alex Elder 2018-11-07 0:32 ` [RFC PATCH 10/12] soc: qcom: ipa: data path Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 14:55 ` Arnd Bergmann 2018-11-07 14:55 ` Arnd Bergmann 2018-11-15 3:31 ` Alex Elder 2018-11-15 3:31 ` Alex Elder 2018-11-15 14:48 ` Arnd Bergmann 2018-11-15 14:48 ` Arnd Bergmann 2018-11-07 0:32 ` [RFC PATCH 11/12] soc: qcom: ipa: IPA rmnet interface Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 13:30 ` Arnd Bergmann 2018-11-07 13:30 ` Arnd Bergmann 2018-11-07 15:26 ` Dan Williams 2018-11-07 15:26 ` Dan Williams 2018-11-07 0:32 ` [RFC PATCH 12/12] soc: qcom: ipa: build and "ipa_i.h" Alex Elder 2018-11-07 0:32 ` Alex Elder 2018-11-07 0:40 ` Randy Dunlap 2018-11-07 0:40 ` Randy Dunlap 2018-11-07 0:40 ` Randy Dunlap 2018-11-08 16:22 ` Alex Elder 2018-11-08 16:22 ` Alex Elder 2018-11-07 12:34 ` Arnd Bergmann [this message] 2018-11-07 12:34 ` Arnd Bergmann 2018-11-07 15:46 ` [RFC PATCH 00/12] net: introduce Qualcomm IPA driver Arnd Bergmann 2018-11-07 15:46 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK8P3a2X1zstSWP89uDxyf+rvyzzDY98_cvE4fzc-ZGbyVz23w@mail.gmail.com \ --to=arnd@arndb.de \ --cc=bjorn.andersson@linaro.org \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=elder@linaro.org \ --cc=ilias.apalodimas@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-soc@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mjavid@codeaurora.org \ --cc=netdev@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=syadagir@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.