| Message ID | 20200519065749.4624-1-jonathan.albrieux@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: magnetometer: ak8975: Add gpio reset support | expand |
On Tue, May 19, 2020 at 08:57:40AM +0200, Jonathan Albrieux wrote: > Convert documentation from txt format to yaml. Add documentation about > reset-gpio. Trailing white space (though it doesn't matter here, in cover letter). > Deassert reset on ak8975_power_on, assert reset on ak8975_power_off. > > Without reset's deassertion during ak8975_power_on, driver's probe fails > on ak8975_who_i_am while checking for device identity for AK09911 chip > > AK09911 has an active low reset gpio to handle register's reset. > AK09911 datasheed says that, if not used, reset pin should be connected > to VID. This patch emulates this situation I dunno if it's your first submission to Linux kernel project or other OSS, but here you missed a changelog. Rule of thumb is to provide a summary of the changes done in the history of the evolution of a patch series.
On Tue, May 19, 2020 at 12:22:12PM +0300, Andy Shevchenko wrote: > On Tue, May 19, 2020 at 08:57:40AM +0200, Jonathan Albrieux wrote: > > Convert documentation from txt format to yaml. Add documentation about > > reset-gpio. > > Trailing white space (though it doesn't matter here, in cover letter). > Ok will fix it! > > Deassert reset on ak8975_power_on, assert reset on ak8975_power_off. > > > > Without reset's deassertion during ak8975_power_on, driver's probe fails > > on ak8975_who_i_am while checking for device identity for AK09911 chip > > > > AK09911 has an active low reset gpio to handle register's reset. > > AK09911 datasheed says that, if not used, reset pin should be connected > > to VID. This patch emulates this situation > > I dunno if it's your first submission to Linux kernel project or other OSS, > but here you missed a changelog. Rule of thumb is to provide a summary of > the changes done in the history of the evolution of a patch series. > Oh thank you and sorry for not having included it. Does the changelog needs to be added to all patch files or just on the ones subject of the changes? > -- > With Best Regards, > Andy Shevchenko > > Best regards, Jonathan Albrieux
On Tue, May 19, 2020 at 11:48:35AM +0200, Jonathan Albrieux wrote: > On Tue, May 19, 2020 at 12:22:12PM +0300, Andy Shevchenko wrote: > > On Tue, May 19, 2020 at 08:57:40AM +0200, Jonathan Albrieux wrote: ... > > I dunno if it's your first submission to Linux kernel project or other OSS, > > but here you missed a changelog. Rule of thumb is to provide a summary of > > the changes done in the history of the evolution of a patch series. > > > > Oh thank you and sorry for not having included it. > > Does the changelog needs to be added to all patch files or just on the ones > subject of the changes? Up to you and maintainer of the corresponding subsystem. My common sense tells me that 1) if there is a cover letter, just put a joined changelog there 2) otherwise, put changelog in each patch. I saw in practice all possible variants, i.e. a) cover letter w/o changelog + changelog per patch; b) cover letter w/ changelog + changelog per patch; c) cover letter w/ changelog. I think any of it is fine in general.
On Tue, May 19, 2020 at 01:08:15PM +0300, Andy Shevchenko wrote: > On Tue, May 19, 2020 at 11:48:35AM +0200, Jonathan Albrieux wrote: > > On Tue, May 19, 2020 at 12:22:12PM +0300, Andy Shevchenko wrote: > > > On Tue, May 19, 2020 at 08:57:40AM +0200, Jonathan Albrieux wrote: > > ... > > > > I dunno if it's your first submission to Linux kernel project or other OSS, > > > but here you missed a changelog. Rule of thumb is to provide a summary of > > > the changes done in the history of the evolution of a patch series. > > > > > > > Oh thank you and sorry for not having included it. > > > > Does the changelog needs to be added to all patch files or just on the ones > > subject of the changes? > > Up to you and maintainer of the corresponding subsystem. > > My common sense tells me that > 1) if there is a cover letter, just put a joined changelog there > 2) otherwise, put changelog in each patch. > > I saw in practice all possible variants, i.e. > a) cover letter w/o changelog + changelog per patch; > b) cover letter w/ changelog + changelog per patch; > c) cover letter w/ changelog. > > I think any of it is fine in general. > > -- > With Best Regards, > Andy Shevchenko > > Thank you for the tips, will work on it! Best regards, Jonathan Albrieux