diff mbox series

wifi: cfg80211: wext: Correct spelling in iw_handler.h

Message ID 20240829-wifi-spell-v1-1-e0a8855482a9@kernel.org (mailing list archive)
State Changes Requested
Delegated to: Johannes Berg
Headers show
Series wifi: cfg80211: wext: Correct spelling in iw_handler.h | expand

Commit Message

Simon Horman Aug. 29, 2024, 4:03 p.m. UTC
Correct spelling in iw_handler.h.
As reported by codespell.

Signed-off-by: Simon Horman <horms@kernel.org>
---
 include/net/iw_handler.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Comments

Johannes Berg Aug. 29, 2024, 4:07 p.m. UTC | #1
On Thu, 2024-08-29 at 17:03 +0100, Simon Horman wrote:
> Correct spelling in iw_handler.h.
> As reported by codespell.
> 
> Signed-off-by: Simon Horman <horms@kernel.org>
> ---
>  include/net/iw_handler.h | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
> index b2cf243ebe44..f7f4c2a79b9e 100644
> --- a/include/net/iw_handler.h
> +++ b/include/net/iw_handler.h
> @@ -23,7 +23,7 @@
>   * to handle wireless statistics.
>   *
>   * The initial APIs served us well and has proven a reasonably good design.
> - * However, there is a few shortcommings :
> + * However, there is a few shortcomings :

If we're going to touch it, maybe that should also say "there are a few
shortcomings"? :)

But is it worth it at all? This stuff is totally on the way out, so all
the thing about "proven a reasonably good design", well, didn't really
pan out in practice...

johannes
Simon Horman Sept. 2, 2024, 9:01 a.m. UTC | #2
On Thu, Aug 29, 2024 at 06:07:00PM +0200, Johannes Berg wrote:
> On Thu, 2024-08-29 at 17:03 +0100, Simon Horman wrote:
> > Correct spelling in iw_handler.h.
> > As reported by codespell.
> > 
> > Signed-off-by: Simon Horman <horms@kernel.org>
> > ---
> >  include/net/iw_handler.h | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
> > index b2cf243ebe44..f7f4c2a79b9e 100644
> > --- a/include/net/iw_handler.h
> > +++ b/include/net/iw_handler.h
> > @@ -23,7 +23,7 @@
> >   * to handle wireless statistics.
> >   *
> >   * The initial APIs served us well and has proven a reasonably good design.
> > - * However, there is a few shortcommings :
> > + * However, there is a few shortcomings :
> 
> If we're going to touch it, maybe that should also say "there are a few
> shortcomings"? :)

Yes, indeed :)

> But is it worth it at all? This stuff is totally on the way out, so all
> the thing about "proven a reasonably good design", well, didn't really
> pan out in practice...

I think if the text is there it may as well be correct.
But if you prefer to leave it as is, then we can drop this topic.
Johannes Berg Sept. 2, 2024, 9:11 a.m. UTC | #3
On Mon, 2024-09-02 at 10:01 +0100, Simon Horman wrote:
> > But is it worth it at all? This stuff is totally on the way out, so all
> > the thing about "proven a reasonably good design", well, didn't really
> > pan out in practice...
> 
> I think if the text is there it may as well be correct.
> But if you prefer to leave it as is, then we can drop this topic.

Sure, that's fair, I'm happy to apply patches updating the
grammar/spelling by itself. No need to go into full rewrite and/or
historic debates about the design :)

johannes
Simon Horman Sept. 3, 2024, 8:25 a.m. UTC | #4
On Mon, Sep 02, 2024 at 11:11:11AM +0200, Johannes Berg wrote:
> On Mon, 2024-09-02 at 10:01 +0100, Simon Horman wrote:
> > > But is it worth it at all? This stuff is totally on the way out, so all
> > > the thing about "proven a reasonably good design", well, didn't really
> > > pan out in practice...
> > 
> > I think if the text is there it may as well be correct.
> > But if you prefer to leave it as is, then we can drop this topic.
> 
> Sure, that's fair, I'm happy to apply patches updating the
> grammar/spelling by itself. No need to go into full rewrite and/or
> historic debates about the design :)

Thanks, I agree.

I have sent a v2, which addresses the grammar issue that you flagged.

https://lore.kernel.org/linux-wireless/20240903-wifi-spell-v2-1-bfcf7062face@kernel.org/

I did look for other grammar issues on other lines that are already
updated by that patch: you can get a laugh when you find something obvious.

I didn't check any further, because this seems to be enough for now.
But I can if you like.
diff mbox series

Patch

diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index b2cf243ebe44..f7f4c2a79b9e 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -23,7 +23,7 @@ 
  * to handle wireless statistics.
  *
  * The initial APIs served us well and has proven a reasonably good design.
- * However, there is a few shortcommings :
+ * However, there is a few shortcomings :
  *	o No events, everything is a request to the driver.
  *	o Large ioctl function in driver with gigantic switch statement
  *	  (i.e. spaghetti code).
@@ -38,13 +38,13 @@ 
  * -------------------------------
  * The new driver API is just a bunch of standard functions (handlers),
  * each handling a specific Wireless Extension. The driver just export
- * the list of handler it supports, and those will be called apropriately.
+ * the list of handler it supports, and those will be called appropriately.
  *
  * I tried to keep the main advantage of the previous API (simplicity,
  * efficiency and light weight), and also I provide a good dose of backward
  * compatibility (most structures are the same, driver can use both API
  * simultaneously, ...).
- * Hopefully, I've also addressed the shortcomming of the initial API.
+ * Hopefully, I've also addressed the shortcoming of the initial API.
  *
  * The advantage of the new API are :
  *	o Handling of Extensions in driver broken in small contained functions
@@ -84,7 +84,7 @@ 
 
 /* ---------------------- THE IMPLEMENTATION ---------------------- */
 /*
- * Some of the choice I've made are pretty controversials. Defining an
+ * Some of the choice I've made are pretty controversial. Defining an
  * API is very much weighting compromises. This goes into some of the
  * details and the thinking behind the implementation.
  *
@@ -140,7 +140,7 @@ 
  * example to distinguish setting max rate and basic rate), I would
  * break the prototype. Using iwreq_data is more flexible.
  * 3) Also, the above form is not generic (see above).
- * 4) I don't expect driver developper using the wrong field of the
+ * 4) I don't expect driver developer using the wrong field of the
  * union (Doh !), so static typechecking doesn't add much value.
  * 5) Lastly, you can skip the union by doing :
  *	static int mydriver_ioctl_setrate(struct net_device *dev,
@@ -459,7 +459,7 @@  int iw_handler_get_thrspy(struct net_device *dev, struct iw_request_info *info,
 void wireless_spy_update(struct net_device *dev, unsigned char *address,
 			 struct iw_quality *wstats);
 
-/************************* INLINE FUNTIONS *************************/
+/************************* INLINE FUNCTIONS *************************/
 /*
  * Function that are so simple that it's more efficient inlining them
  */