drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
Fixed spelling errors in error message and comments that
were reported by codespell as follows:
unexpect --> unexpected
workaound --> workaround
Also, fixed codestyle error and replaced a hardcoded function
name in a pr_err statement with __func__.
Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
---
drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c b/drivers/usb/gadget/udc/m66592-udc.c
index bfaa5291e6c8..e0b261ff0828 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -110,7 +110,7 @@ static inline u16 control_reg_get_pid(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
pid = m66592_read(m66592, offset) & M66592_PID;
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
return pid;
}
@@ -126,7 +126,7 @@ static inline void control_reg_set_pid(struct m66592 *m66592, u16 pipenum,
offset = get_pipectr_addr(pipenum);
m66592_mdfy(m66592, pid, M66592_PID, offset);
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
}
static inline void pipe_start(struct m66592 *m66592, u16 pipenum)
@@ -155,7 +155,7 @@ static inline u16 control_reg_get(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
ret = m66592_read(m66592, offset);
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
return ret;
}
@@ -172,7 +172,7 @@ static inline void control_reg_sqclr(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
m66592_bset(m66592, M66592_SQCLR, offset);
} else
- pr_err("unexpect pipe num(%d)\n", pipenum);
+ pr_err("unexpected pipe num(%d)\n", pipenum);
}
static inline int get_buffer_size(struct m66592 *m66592, u16 pipenum)
@@ -293,7 +293,7 @@ static void pipe_buffer_release(struct m66592 *m66592,
if (info->type == M66592_BULK)
m66592->bulk--;
} else
- pr_err("ep_release: unexpect pipenum (%d)\n",
+ pr_err("ep_release: unexpected pipenum (%d)\n",
info->pipe);
}
@@ -428,7 +428,7 @@ static int alloc_pipe_config(struct m66592_ep *ep,
counter = &m66592->isochronous;
break;
default:
- pr_err("unexpect xfer type\n");
+ pr_err("unexpected xfer type\n");
return -EINVAL;
}
ep->type = info.type;
@@ -579,7 +579,7 @@ static void start_ep0(struct m66592_ep *ep, struct m66592_request *req)
control_end(ep->m66592, 0);
break;
default:
- pr_err("start_ep0: unexpect ctsq(%x)\n", ctsq);
+ pr_err("%s: unexpected ctsq(%x)\n", __func__, ctsq);
break;
}
}
@@ -599,7 +599,7 @@ static void init_controller(struct m66592 *m66592)
m66592_bclr(m66592, M66592_DPRPU, M66592_SYSCFG);
m66592_bset(m66592, M66592_USBE, M66592_SYSCFG);
- /* This is a workaound for SH7722 2nd cut */
+ /* This is a workaround for SH7722 2nd cut */
m66592_bset(m66592, 0x8000, M66592_DVSTCTR);
m66592_bset(m66592, 0x1000, M66592_TESTMODE);
m66592_bclr(m66592, 0x8000, M66592_DVSTCTR);
@@ -1186,7 +1186,7 @@ __acquires(m66592->lock)
control_end(m66592, 0);
break;
default:
- pr_err("ctrl_stage: unexpect ctsq(%x)\n", ctsq);
+ pr_err("ctrl_stage: unexpected ctsq(%x)\n", ctsq);
break;
}
}
--
2.43.0On Sun, Sep 15, 2024 at 07:45:07PM -0600, Everest K.C. wrote: > Fixed spelling errors in error message and comments that > were reported by codespell as follows: > unexpect --> unexpected > workaound --> workaround > Also, fixed codestyle error and replaced a hardcoded function > name in a pr_err statement with __func__. > > Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> > --- > drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Fixed spelling errors in error message and comments that
were reported by codespell as follows:
unexpect --> unexpected
workaound --> workaround
Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
---
v1 --> v2: Removed the coding style fix. This patch now only
fixes spelling errors. The coding style will be fixed
in a separate patch.
drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c b/drivers/usb/gadget/udc/m66592-udc.c
index bfaa5291e6c8..c5e68caaac8d 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -110,7 +110,7 @@ static inline u16 control_reg_get_pid(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
pid = m66592_read(m66592, offset) & M66592_PID;
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
return pid;
}
@@ -126,7 +126,7 @@ static inline void control_reg_set_pid(struct m66592 *m66592, u16 pipenum,
offset = get_pipectr_addr(pipenum);
m66592_mdfy(m66592, pid, M66592_PID, offset);
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
}
static inline void pipe_start(struct m66592 *m66592, u16 pipenum)
@@ -155,7 +155,7 @@ static inline u16 control_reg_get(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
ret = m66592_read(m66592, offset);
} else
- pr_err("unexpect pipe num (%d)\n", pipenum);
+ pr_err("unexpected pipe num (%d)\n", pipenum);
return ret;
}
@@ -172,7 +172,7 @@ static inline void control_reg_sqclr(struct m66592 *m66592, u16 pipenum)
offset = get_pipectr_addr(pipenum);
m66592_bset(m66592, M66592_SQCLR, offset);
} else
- pr_err("unexpect pipe num(%d)\n", pipenum);
+ pr_err("unexpected pipe num(%d)\n", pipenum);
}
static inline int get_buffer_size(struct m66592 *m66592, u16 pipenum)
@@ -293,7 +293,7 @@ static void pipe_buffer_release(struct m66592 *m66592,
if (info->type == M66592_BULK)
m66592->bulk--;
} else
- pr_err("ep_release: unexpect pipenum (%d)\n",
+ pr_err("ep_release: unexpected pipenum (%d)\n",
info->pipe);
}
@@ -428,7 +428,7 @@ static int alloc_pipe_config(struct m66592_ep *ep,
counter = &m66592->isochronous;
break;
default:
- pr_err("unexpect xfer type\n");
+ pr_err("unexpected xfer type\n");
return -EINVAL;
}
ep->type = info.type;
@@ -579,7 +579,7 @@ static void start_ep0(struct m66592_ep *ep, struct m66592_request *req)
control_end(ep->m66592, 0);
break;
default:
- pr_err("start_ep0: unexpect ctsq(%x)\n", ctsq);
+ pr_err("start_ep0: unexpected ctsq(%x)\n", ctsq);
break;
}
}
@@ -599,7 +599,7 @@ static void init_controller(struct m66592 *m66592)
m66592_bclr(m66592, M66592_DPRPU, M66592_SYSCFG);
m66592_bset(m66592, M66592_USBE, M66592_SYSCFG);
- /* This is a workaound for SH7722 2nd cut */
+ /* This is a workaround for SH7722 2nd cut */
m66592_bset(m66592, 0x8000, M66592_DVSTCTR);
m66592_bset(m66592, 0x1000, M66592_TESTMODE);
m66592_bclr(m66592, 0x8000, M66592_DVSTCTR);
@@ -1186,7 +1186,7 @@ __acquires(m66592->lock)
control_end(m66592, 0);
break;
default:
- pr_err("ctrl_stage: unexpect ctsq(%x)\n", ctsq);
+ pr_err("ctrl_stage: unexpected ctsq(%x)\n", ctsq);
break;
}
}
--
2.43.0On Sun, Sep 15, 2024 at 11:23:56PM -0600, Everest K.C. wrote: > Fixed spelling errors in error message and comments that > were reported by codespell as follows: > unexpect --> unexpected > workaound --> workaround > > Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> > --- > v1 --> v2: Removed the coding style fix. This patch now only > fixes spelling errors. The coding style will be fixed > in a separate patch. > > drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++--------- If you do: git log --oneline drivers/usb/gadget/udc/m66592-udc.c you will see the format for how to properly write the Subject: line here. As this is your first kernel contributions, I recommend working in an area that is designed for new developers to help work through these types of issues, drivers/staging/ Get some experience there before moving out into other areas of the kernel. Also note that many subsystems do not care about things like spelling fixes, so be careful. thanks, greg k-h
On Mon, Sep 16, 2024 at 12:52 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Sun, Sep 15, 2024 at 11:23:56PM -0600, Everest K.C. wrote: > > Fixed spelling errors in error message and comments that > > were reported by codespell as follows: > > unexpect --> unexpected > > workaound --> workaround > > > > Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> > > --- > > v1 --> v2: Removed the coding style fix. This patch now only > > fixes spelling errors. The coding style will be fixed > > in a separate patch. > > > > drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++--------- > > If you do: > git log --oneline drivers/usb/gadget/udc/m66592-udc.c > you will see the format for how to properly write the Subject: line > here. > > As this is your first kernel contributions, I recommend working in an > area that is designed for new developers to help work through these > types of issues, drivers/staging/ Get some experience there before > moving out into other areas of the kernel. Also note that many > subsystems do not care about things like spelling fixes, so be careful. > > thanks, > > greg k-h Hi Greg, Thank you for pointing out my mistake with the subject line. I have noted and will keep that in mind when I submit my next patch. Also, do you mean the fixes like this need to be done in gregkh/staging.git repo? Do you recommend that I resubmit this patch with corrections or discard it ? / Everest K.C.
On Mon, Sep 16, 2024 at 01:35:19AM -0600, Everest K.C. wrote: > On Mon, Sep 16, 2024 at 12:52 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Sun, Sep 15, 2024 at 11:23:56PM -0600, Everest K.C. wrote: > > > Fixed spelling errors in error message and comments that > > > were reported by codespell as follows: > > > unexpect --> unexpected > > > workaound --> workaround > > > > > > Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> > > > --- > > > v1 --> v2: Removed the coding style fix. This patch now only > > > fixes spelling errors. The coding style will be fixed > > > in a separate patch. > > > > > > drivers/usb/gadget/udc/m66592-udc.c | 18 +++++++++--------- > > > > If you do: > > git log --oneline drivers/usb/gadget/udc/m66592-udc.c > > you will see the format for how to properly write the Subject: line > > here. > > > > As this is your first kernel contributions, I recommend working in an > > area that is designed for new developers to help work through these > > types of issues, drivers/staging/ Get some experience there before > > moving out into other areas of the kernel. Also note that many > > subsystems do not care about things like spelling fixes, so be careful. > > > > thanks, > > > > greg k-h > > Hi Greg, > Thank you for pointing out my mistake with the subject line. I have noted > and will keep that in mind when I submit my next patch. > Also, do you mean the fixes like this need to be done in gregkh/staging.git > repo? Do you recommend that I resubmit this patch with corrections or > discard it ? I mean start working in drivers/staging/ on issues there, not in drivers/usb/, until you get the process working well for you, then worry about moving to other portions of the kernel. good luck! greg k-h
© 2016 - 2024 Red Hat, Inc.