These sentences are not proper English due to the typos. I had initially caught
one of them while trying to understand the regmap feature, and then I just ran
the vim spell checker, and went through all the items that would need to be
fixed for this header file.
Signed-off-by: Laszlo Papp <[email protected]>
---
include/linux/regmap.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index e559078..6305657 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -122,9 +122,9 @@ typedef void (*regmap_unlock)(void *);
* volatile_table (see below) is not, the check is performed on
* such table (a register is volatile if it belongs to one of
* the ranges specified by volatile_table).
- * @precious_reg: Optional callback returning true if the rgister
+ * @precious_reg: Optional callback returning true if the register
* should not be read outside of a call from the driver
- * (eg, a clear on read interrupt status register). If this
+ * (e.g. a clear on read interrupt status register). If this
* field is NULL but precious_table (see below) is not, the
* check is performed on such table (a register is precious if
* it belongs to one of the ranges specified by precious_table).
@@ -136,9 +136,9 @@ typedef void (*regmap_unlock)(void *);
* are not overridden).
* @reg_read: Optional callback that if filled will be used to perform
* all the reads from the registers. Should only be provided for
- * devices whos read operation cannot be represented as a simple read
- * operation on a bus such as SPI, I2C, etc. Most of the devices do
- * not need this.
+ * devices whose read operation cannot be represented as a simple
+ * read operation on a bus such as SPI, I2C, etc. Most of the
+ * devices do not need this.
* @reg_write: Same as above for writing.
* @fast_io: Register IO is fast. Use a spinlock instead of a mutex
* to perform locking. This field is ignored if custom lock/unlock
--
1.8.5.1
On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
> - * (eg, a clear on read interrupt status register). If this
> + * (e.g. a clear on read interrupt status register). If this
This is somewhat outdated orthorgraphy...
On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown <[email protected]> wrote:
> On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>
>> - * (eg, a clear on read interrupt status register). If this
>> + * (e.g. a clear on read interrupt status register). If this
>
> This is somewhat outdated orthorgraphy...
Pardon ?
On 01/08/2014 10:07 AM, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>
>> - * (eg, a clear on read interrupt status register). If this
>> + * (e.g. a clear on read interrupt status register). If this
>
> This is somewhat outdated orthorgraphy...
orthography
Anyway, I would merge such a patch if I were a maintainer.
--
~Randy
On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown <[email protected]> wrote:
> > On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
> >> - * (eg, a clear on read interrupt status register). If this
> >> + * (e.g. a clear on read interrupt status register). If this
> > This is somewhat outdated orthorgraphy...
> Pardon ?
It's not that common to write it as an abbreviation (even though it is
one) and for some random reason you've decided to drop the comma which
is standard.
On Wed, Jan 8, 2014 at 7:07 PM, Mark Brown <[email protected]> wrote:
> On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown <[email protected]> wrote:
>> > On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>
>> >> - * (eg, a clear on read interrupt status register). If this
>> >> + * (e.g. a clear on read interrupt status register). If this
>
>> > This is somewhat outdated orthorgraphy...
>
>> Pardon ?
>
> It's not that common to write it as an abbreviation (even though it is
> one) and for some random reason you've decided to drop the comma which
> is standard.
Cannot agree. I see this effectively almost anywhere, and I even asked
this on IRC from native English speaker in #English @ freenode who
were in an agreement with me as far as I can tell.
That being said, I will not have time, nor the motivation to argue
over such a nuance, so feel free to reject the change.
On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp <[email protected]> wrote:
> On Wed, Jan 8, 2014 at 7:07 PM, Mark Brown <[email protected]> wrote:
>> On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
>>> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown <[email protected]> wrote:
>>> > On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>>
>>> >> - * (eg, a clear on read interrupt status register). If this
>>> >> + * (e.g. a clear on read interrupt status register). If this
>>
>>> > This is somewhat outdated orthorgraphy...
>>
>>> Pardon ?
>>
>> It's not that common to write it as an abbreviation (even though it is
>> one) and for some random reason you've decided to drop the comma which
>> is standard.
>
> Cannot agree. I see this effectively almost anywhere, and I even asked
> this on IRC from native English speaker in #English @ freenode who
> were in an agreement with me as far as I can tell.
>
> That being said, I will not have time, nor the motivation to argue
> over such a nuance, so feel free to reject the change.
Of course, this is just on top of the vim spell checker error as I
wrote in the commit message...
Oh yes, and one more factual data in here:
lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l
3447
lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l
18
On Wed, Jan 08, 2014 at 09:08:44PM +0000, Laszlo Papp wrote:
> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp <[email protected]> wrote:
> > That being said, I will not have time, nor the motivation to argue
> > over such a nuance, so feel free to reject the change.
> Of course, this is just on top of the vim spell checker error as I
> wrote in the commit message...
> Oh yes, and one more factual data in here:
> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l
> 3447
> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l
> 18
That's not the issue - it's dropping the comma. It's either "e.g." or
"eg", the comma is a separate thing providing a break between clauses.
Strictly it should have the periods since it is an abbreviation but
their use is more vauge in fixed point text since they look ugly, the
thing that made me complain was that you dropped the comma as well as
substituting in the expanded version.
On 01/08/14 11:07, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown <[email protected]> wrote:
>>> On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>
>>>> - * (eg, a clear on read interrupt status register). If this
>>>> + * (e.g. a clear on read interrupt status register). If this
>
>>> This is somewhat outdated orthorgraphy...
>
>> Pardon ?
>
> It's not that common to write it as an abbreviation (even though it is
> one) and for some random reason you've decided to drop the comma which
> is standard.
Good catch. I somehow overlooked that change (dropped comma) in the patch.
e.g.,
--
~Randy
On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown <[email protected]> wrote:
> On Wed, Jan 08, 2014 at 09:08:44PM +0000, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp <[email protected]> wrote:
>
>> > That being said, I will not have time, nor the motivation to argue
>> > over such a nuance, so feel free to reject the change.
>
>> Of course, this is just on top of the vim spell checker error as I
>> wrote in the commit message...
>
>> Oh yes, and one more factual data in here:
>
>> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l
>> 3447
>
>> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l
>> 18
>
> That's not the issue - it's dropping the comma. It's either "e.g." or
> "eg", the comma is a separate thing providing a break between clauses.
> Strictly it should have the periods since it is an abbreviation but
> their use is more vauge in fixed point text since they look ugly, the
> thing that made me complain was that you dropped the comma as well as
> substituting in the expanded version.
I still do not get what point you are trying to make. Could you please
provide evidence? Because really, this is the usage I have seen in
projects out there all around, including the majority of the linux
kernel.
Here is some more data:
grep -rn "e\.g\. " . | wc -l
2553
lpapp ~/Projects/linux-staging $ grep -rn "e\.g\.," . | wc -l
573
On 01/08/14 17:46, Laszlo Papp wrote:
> On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown <[email protected]> wrote:
>> On Wed, Jan 08, 2014 at 09:08:44PM +0000, Laszlo Papp wrote:
>>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp <[email protected]> wrote:
>>
>>>> That being said, I will not have time, nor the motivation to argue
>>>> over such a nuance, so feel free to reject the change.
>>
>>> Of course, this is just on top of the vim spell checker error as I
>>> wrote in the commit message...
>>
>>> Oh yes, and one more factual data in here:
>>
>>> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l
>>> 3447
>>
>>> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l
>>> 18
>>
>> That's not the issue - it's dropping the comma. It's either "e.g." or
>> "eg", the comma is a separate thing providing a break between clauses.
>> Strictly it should have the periods since it is an abbreviation but
>> their use is more vauge in fixed point text since they look ugly, the
>> thing that made me complain was that you dropped the comma as well as
>> substituting in the expanded version.
>
> I still do not get what point you are trying to make. Could you please
> provide evidence? Because really, this is the usage I have seen in
> projects out there all around, including the majority of the linux
> kernel.
>
> Here is some more data:
>
> grep -rn "e\.g\. " . | wc -l
> 2553
> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\.," . | wc -l
> 573
> --
Hi,
I am used to seeing e.g. and i.e. always followed by a comma when they are
used to begin a sentence. However, I just checked and some online style
guides say to omit the comma and some say to use it, and we (Linux kernel)
don't really have a writing style guide to look at. I think that makes it
up to the maintainer to decide what is acceptable.
--
~Randy
On Thu, Jan 9, 2014 at 2:43 AM, Randy Dunlap <[email protected]> wrote:
> On 01/08/14 17:46, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown <[email protected]> wrote:
>>> On Wed, Jan 08, 2014 at 09:08:44PM +0000, Laszlo Papp wrote:
>>>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp <[email protected]> wrote:
>>>
>>>>> That being said, I will not have time, nor the motivation to argue
>>>>> over such a nuance, so feel free to reject the change.
>>>
>>>> Of course, this is just on top of the vim spell checker error as I
>>>> wrote in the commit message...
>>>
>>>> Oh yes, and one more factual data in here:
>>>
>>>> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l
>>>> 3447
>>>
>>>> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l
>>>> 18
>>>
>>> That's not the issue - it's dropping the comma. It's either "e.g." or
>>> "eg", the comma is a separate thing providing a break between clauses.
>>> Strictly it should have the periods since it is an abbreviation but
>>> their use is more vauge in fixed point text since they look ugly, the
>>> thing that made me complain was that you dropped the comma as well as
>>> substituting in the expanded version.
>>
>> I still do not get what point you are trying to make. Could you please
>> provide evidence? Because really, this is the usage I have seen in
>> projects out there all around, including the majority of the linux
>> kernel.
>>
>> Here is some more data:
>>
>> grep -rn "e\.g\. " . | wc -l
>> 2553
>> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\.," . | wc -l
>> 573
>> --
>
> Hi,
>
> I am used to seeing e.g. and i.e. always followed by a comma when they are
> used to begin a sentence. However, I just checked and some online style
> guides say to omit the comma and some say to use it, and we (Linux kernel)
> don't really have a writing style guide to look at. I think that makes it
> up to the maintainer to decide what is acceptable.
Who is the maintainer? Is it Mark, or I should wait for someone else?
On Wed, Jan 08, 2014 at 06:43:20PM -0800, Randy Dunlap wrote:
> On 01/08/14 17:46, Laszlo Papp wrote:
> > I still do not get what point you are trying to make. Could you please
> > provide evidence? Because really, this is the usage I have seen in
> > projects out there all around, including the majority of the linux
> > kernel.
> I am used to seeing e.g. and i.e. always followed by a comma when they are
> used to begin a sentence. However, I just checked and some online style
> guides say to omit the comma and some say to use it, and we (Linux kernel)
> don't really have a writing style guide to look at. I think that makes it
> up to the maintainer to decide what is acceptable.
More generally they're just abbreviations for the latin for for example
and that is so (to a reasonable approximation) get used in the same way.
On Thu, Jan 09, 2014 at 10:22:19AM +0000, Laszlo Papp wrote:
> Who is the maintainer? Is it Mark, or I should wait for someone else?
Yes, it's me.