| Message ID | E1bXZjd-0000YR-7n@debutante (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 10 Aug 2016, Mark Brown wrote: > The patch > > mfd: tps65218: add version check to the PMIC probe Why did you take this patch? I now have a merge conflict. Did you provide a pull-request that I can use to resolve? > has been applied to the regulator tree at > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > > All being well this means that it will be integrated into the linux-next > tree (usually sometime in the next 24 hours) and sent to Linus during > the next merge window (or sooner if it is a bug fix), however if > problems are discovered then the patch may be dropped or reverted. > > You may get further e-mails resulting from automated or manual testing > and review of the tree, please engage with people reporting problems and > send followup patches addressing any issues that are reported if needed. > > If any updates are required or you are submitting further changes they > should be sent as incremental updates against current git, existing > patches will not be replaced. > > Please add any relevant lists and maintainers to the CCs when replying > to this mail. > > Thanks, > Mark > > From f11fa1796a4b4f8c6d4ced37e8824276ec57057d Mon Sep 17 00:00:00 2001 > From: Tero Kristo <t-kristo@ti.com> > Date: Wed, 10 Aug 2016 17:53:54 +0530 > Subject: [PATCH] mfd: tps65218: add version check to the PMIC probe > > Version information will be needed to handle some error cases under the > regulator driver, so store the information once during MFD probe. > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > Signed-off-by: Keerthy <j-keerthy@ti.com> > Acked-by: Lee Jones <lee.jones@linaro.org> > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > drivers/mfd/tps65218.c | 9 +++++++++ > include/linux/mfd/tps65218.h | 1 + > 2 files changed, 10 insertions(+) > > diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c > index 80b9dc363cd8..ba610adbdbff 100644 > --- a/drivers/mfd/tps65218.c > +++ b/drivers/mfd/tps65218.c > @@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client, > struct tps65218 *tps; > const struct of_device_id *match; > int ret; > + unsigned int chipid; > > match = of_match_device(of_tps65218_match_table, &client->dev); > if (!match) { > @@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client, > if (ret < 0) > return ret; > > + ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid); > + if (ret) { > + dev_err(tps->dev, "Failed to read chipid: %d\n", ret); > + return ret; > + } > + > + tps->rev = chipid & TPS65218_CHIPID_REV_MASK; > + > ret = of_platform_populate(client->dev.of_node, NULL, NULL, > &client->dev); > if (ret < 0) > diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h > index 7fdf5326f34e..85e464e32c43 100644 > --- a/include/linux/mfd/tps65218.h > +++ b/include/linux/mfd/tps65218.h > @@ -267,6 +267,7 @@ struct tps_info { > struct tps65218 { > struct device *dev; > unsigned int id; > + u8 rev; > > struct mutex tps_lock; /* lock guarding the data structure */ > /* IRQ Data */
On Wed, 31 Aug 2016, Mark Brown wrote: > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > The patch > > > > mfd: tps65218: add version check to the PMIC probe > > > Why did you take this patch? > > You acked it, that's saying that you're OK with the patch and are > expecting someone else to apply it. No it doesn't, you made that up. :) I know when you and some others Ack a patch, that's what you mean, but you've been working with me for long enough to know that's not what I mean when I Ack a patch. I do it as an indication that I've reviewed the patch and I'm happy with it. Most MFD patches that have dependencies tend to come through the MFD tree. If that's not the case, my Ack is usually backed up with a "I expect this patch to go through the X tree". > > I now have a merge conflict. > > > Did you provide a pull-request that I can use to resolve? > > The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Thanks. > Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/tps65218-ver-check > > for you to fetch changes up to f11fa1796a4b4f8c6d4ced37e8824276ec57057d: > > mfd: tps65218: add version check to the PMIC probe (2016-08-10 18:21:55 +0100) > > ---------------------------------------------------------------- > mfd: tps65218: Add hardware version check > > This will be used for quirks by some function drivers. > > ---------------------------------------------------------------- > Tero Kristo (1): > mfd: tps65218: add version check to the PMIC probe > > drivers/mfd/tps65218.c | 9 +++++++++ > include/linux/mfd/tps65218.h | 1 + > 2 files changed, 10 insertions(+)
On Wed, Aug 31, 2016 at 03:50:18PM +0100, Lee Jones wrote: > On Wed, 31 Aug 2016, Mark Brown wrote: > > You acked it, that's saying that you're OK with the patch and are > > expecting someone else to apply it. > No it doesn't, you made that up. :) > I know when you and some others Ack a patch, that's what you mean, but That's the standard meaning I'm afraid, you're going to confuse people if you do that. I'd suggest using a different tag if you want to do this, probably make one up. > you've been working with me for long enough to know that's not what I > mean when I Ack a patch. I do it as an indication that I've reviewed > the patch and I'm happy with it. Most MFD patches that have Sorry but I'm not actually reading most of these threads, I've not seen this behaviour. Mostly I just look at the relevant patches, especially on the resends where presumably this has been happening. Not sure why I even saw the ack here, perhaps I had some question about the versioning API.
On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > On Wed, 10 Aug 2016, Mark Brown wrote: > > > The patch > > > > mfd: tps65218: add version check to the PMIC probe > > Why did you take this patch? I think folk need to start to understand the purpose of the To: and Cc: lines in emails. To: means you're sending the message _to_ the recipient, expecting them to be the _primary_ receiver of the message, and to _process_ the message in some way. In the case of a patch, that may be applying the change. Cc: means you're providing the recipient with a copy of the message, "for their information" and you're not expecting them to take action. If you think that there's no difference between To: and Cc: then ask yourself this question: what's the point of having the two headers, why not list all recipients under one single header. Mark was in the To: line, therefore it is perfectly reasonable for him to apply the patch when it gets acked, since the original author sent it _TO_ Mark implicitly asking him to apply it. If you have a problem with that, then you need to say something in reply to the patch, or you need to instruct folk who send patches for bits of your subsystem not to place others in the To: field who may pick up the patch. However, there is a tendency with some people's mailers (including yours) which keeps the recipients of the To: and Cc: from the message being replied to, and copies them to the reply as-is. That totally screws up the meaning of the To: and Cc: headers, and is really really really really annoying for people who are in the To: field but who aren't being asked to do anything in the replies. (Fix your bloody mailer not to do this please!)
On Wed, 31 Aug 2016, Russell King - ARM Linux wrote: > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > > The patch > > > > > > mfd: tps65218: add version check to the PMIC probe > > > > Why did you take this patch? > > I think folk need to start to understand the purpose of the To: and Cc: > lines in emails. > > To: means you're sending the message _to_ the recipient, expecting them > to be the _primary_ receiver of the message, and to _process_ the message > in some way. In the case of a patch, that may be applying the change. > > Cc: means you're providing the recipient with a copy of the message, "for > their information" and you're not expecting them to take action. > > If you think that there's no difference between To: and Cc: then ask > yourself this question: what's the point of having the two headers, > why not list all recipients under one single header. > > Mark was in the To: line, therefore it is perfectly reasonable for him > to apply the patch when it gets acked, since the original author sent > it _TO_ Mark implicitly asking him to apply it. > > If you have a problem with that, then you need to say something in > reply to the patch, or you need to instruct folk who send patches for > bits of your subsystem not to place others in the To: field who may > pick up the patch. It's not up to submitters which repo patches get applied to. They are free to make a verbal (written) request and if it's justified then we can choose to agree to it or not. For instance, a submitter is more likely to know if a dependency was recently taken in via a particular tree than a Maintainer, since it's almost impossible to keep track each and every patch and all it's possible dependants. I personally review/accept patches based solely on the subsystem(s) touched and the actions of particular Maintainers, knowing firstly how they operate. Actioning patches based on whether a contributor uses the To: or Cc: lines seems very fragile and prone to unnecessary complications. > However, there is a tendency with some people's mailers (including > yours) which keeps the recipients of the To: and Cc: from the message > being replied to, and copies them to the reply as-is. That totally > screws up the meaning of the To: and Cc: headers, and is really > really really really annoying for people who are in the To: field > but who aren't being asked to do anything in the replies. (Fix your > bloody mailer not to do this please!) I use the Mutt's default configuration for 'reply-to-all' in all cases. I really don't have time to manually reorganise something as trivial as To: and Cc: lines. I find them irrelevant in this setting. Any time spent on trivial activities such as these adds further delay to patch-reviews. Some of us have day jobs too you know. ;)
On Wed, 31 Aug 2016, Mark Brown wrote: > On Wed, Aug 31, 2016 at 03:50:18PM +0100, Lee Jones wrote: > > On Wed, 31 Aug 2016, Mark Brown wrote: > > > > You acked it, that's saying that you're OK with the patch and are > > > expecting someone else to apply it. > > > No it doesn't, you made that up. :) > > > I know when you and some others Ack a patch, that's what you mean, but > > That's the standard meaning I'm afraid, you're going to confuse people > if you do that. I'd suggest using a different tag if you want to do > this, probably make one up. Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me> :) Temporary-Acked-by-[to go through MFD tree]: <me> Suggestions? > > you've been working with me for long enough to know that's not what I > > mean when I Ack a patch. I do it as an indication that I've reviewed > > the patch and I'm happy with it. Most MFD patches that have > > Sorry but I'm not actually reading most of these threads, I've not seen > this behaviour. Mostly I just look at the relevant patches, especially > on the resends where presumably this has been happening. Not sure why I > even saw the ack here, perhaps I had some question about the versioning > API.
On Thu, Sep 01, 2016 at 09:23:08AM +0100, Lee Jones wrote: > On Wed, 31 Aug 2016, Mark Brown wrote: > > That's the standard meaning I'm afraid, you're going to confuse people > > if you do that. I'd suggest using a different tag if you want to do > > this, probably make one up. > Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me> > :) > Temporary-Acked-by-[to go through MFD tree]: <me> > Suggestions? Reviwed-for-MFD-by: ?
On Thu, 01 Sep 2016, Mark Brown wrote: > On Thu, Sep 01, 2016 at 09:23:08AM +0100, Lee Jones wrote: > > On Wed, 31 Aug 2016, Mark Brown wrote: > > > > That's the standard meaning I'm afraid, you're going to confuse people > > > if you do that. I'd suggest using a different tag if you want to do > > > this, probably make one up. > > > Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me> > > > :) > > > Temporary-Acked-by-[to go through MFD tree]: <me> > > > Suggestions? > > Reviwed-for-MFD-by: ? Okay, done. Thanks for your suggestion.
On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote: > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote: > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > > > > The patch > > > > > > > > mfd: tps65218: add version check to the PMIC probe > > > > > > Why did you take this patch? > > > > I think folk need to start to understand the purpose of the To: and Cc: > > lines in emails. > > > > To: means you're sending the message _to_ the recipient, expecting them > > to be the _primary_ receiver of the message, and to _process_ the message > > in some way. In the case of a patch, that may be applying the change. > > > > Cc: means you're providing the recipient with a copy of the message, "for > > their information" and you're not expecting them to take action. > > > > If you think that there's no difference between To: and Cc: then ask > > yourself this question: what's the point of having the two headers, > > why not list all recipients under one single header. > > > > Mark was in the To: line, therefore it is perfectly reasonable for him > > to apply the patch when it gets acked, since the original author sent > > it _TO_ Mark implicitly asking him to apply it. > > > > If you have a problem with that, then you need to say something in > > reply to the patch, or you need to instruct folk who send patches for > > bits of your subsystem not to place others in the To: field who may > > pick up the patch. > > It's not up to submitters which repo patches get applied to. They are > free to make a verbal (written) request and if it's justified then we > can choose to agree to it or not. Wrong. It's up to submitters to send TO the person who they want to apply the patch - that's how it's always worked. What's become broken is this idea of "I absolutely own this area of the kernel, all patches _must_ come through me." That's never been the case. There may be a good reason why the submitter doesn't want the normal maintainer of an area of the kernel to take the patch, in which case the submitter has every right to decide who should take their patch. The wrong maintainer taking the patch can screw up the submitters workflow, cause additional conflicts, or break dependencies. The submitter is the best person to decide who should apply their change. > I use the Mutt's default configuration for 'reply-to-all' in all > cases. I really don't have time to manually reorganise something as > trivial as To: and Cc: lines. I find them irrelevant in this > setting. Any time spent on trivial activities such as these adds > further delay to patch-reviews. Some of us have day jobs too you > know. ;) Exactly - some of us don't have a lot of time, and some of us don't read messages that aren't sent either To or Cc'd to us. Some of us also place messages that are Cc'd at a _much_ lower priority than those which are sent To them. If people want me to take some action with their message, they had better put me in the To: line and _not_ the Cc, otherwise they're risking me ignoring them for a long time.
On Thu, 01 Sep 2016, Russell King - ARM Linux wrote: > On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote: > > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote: > > > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > > > > > > The patch > > > > > > > > > > mfd: tps65218: add version check to the PMIC probe > > > > > > > > Why did you take this patch? > > > > > > I think folk need to start to understand the purpose of the To: and Cc: > > > lines in emails. > > > > > > To: means you're sending the message _to_ the recipient, expecting them > > > to be the _primary_ receiver of the message, and to _process_ the message > > > in some way. In the case of a patch, that may be applying the change. > > > > > > Cc: means you're providing the recipient with a copy of the message, "for > > > their information" and you're not expecting them to take action. > > > > > > If you think that there's no difference between To: and Cc: then ask > > > yourself this question: what's the point of having the two headers, > > > why not list all recipients under one single header. > > > > > > Mark was in the To: line, therefore it is perfectly reasonable for him > > > to apply the patch when it gets acked, since the original author sent > > > it _TO_ Mark implicitly asking him to apply it. > > > > > > If you have a problem with that, then you need to say something in > > > reply to the patch, or you need to instruct folk who send patches for > > > bits of your subsystem not to place others in the To: field who may > > > pick up the patch. > > > > It's not up to submitters which repo patches get applied to. They are > > free to make a verbal (written) request and if it's justified then we > > can choose to agree to it or not. > > Wrong. It's up to submitters to send TO the person who they want to > apply the patch - that's how it's always worked. > > What's become broken is this idea of "I absolutely own this area of the > kernel, all patches _must_ come through me." That's never been the case. > > There may be a good reason why the submitter doesn't want the normal > maintainer of an area of the kernel to take the patch, in which case > the submitter has every right to decide who should take their patch. > The wrong maintainer taking the patch can screw up the submitters > workflow, cause additional conflicts, or break dependencies. The > submitter is the best person to decide who should apply their change. I agree that the submitter is the best person to provide a compelling case to re-route a patch's normal submission path. I disagree that they have the final say. I've had a bunch of requests asking if a patch can go in via a different repository due to convenience i.e. their feature will magically start working once the set lands. Myself and the all of the Maintainers I regularly work with vehemently push back on that, and insist the only 2 cases which will be considered are a) to prevent merge-conflicts and b) in the case of a *build* dependency. If neither of those boxes are ticked, then we separate the set and apply the patches pertaining to the subsystems we each look maintain. In the acceptable cases above, if I am the *lucky* person to route the patches to Mainline (which 9 out of 10 times I am), I religiously send pull-requests to the other Maintainers, so they can continue to avoid merge conflicts, both in their own trees and in Linus' during the merge-window. If patches go through another tree, I usually insist on an immutable branch to pull from, for the same reasons stated. > > I use the Mutt's default configuration for 'reply-to-all' in all > > cases. I really don't have time to manually reorganise something as > > trivial as To: and Cc: lines. I find them irrelevant in this > > setting. Any time spent on trivial activities such as these adds > > further delay to patch-reviews. Some of us have day jobs too you > > know. ;) > > Exactly - some of us don't have a lot of time, and some of us don't > read messages that aren't sent either To or Cc'd to us. Some of us > also place messages that are Cc'd at a _much_ lower priority than > those which are sent To them. I can live with that. So far I have not been inhibited by this, AFAIK. > If people want me to take some action with their message, they had > better put me in the To: line and _not_ the Cc, otherwise they're > risking me ignoring them for a long time. I'm not sure many people work like that, sending or receiving. In my case I deal with every mail I receive, firstly by brain grepping -- skimming over the subject headers for mails I consider urgent. Everything else gets marked as 'important' and is dealt with chronologically. No where in my workflow to do filter by, or consider To: and Cc: fields. That just sounds like too much effort. Again, sorry if that messes with your workflow, truly, but I have more important things to focus on.
On Thu, Sep 01, 2016 at 12:19:18PM +0100, Lee Jones wrote: > On Thu, 01 Sep 2016, Russell King - ARM Linux wrote: > > > On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote: > > > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote: > > > > > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > > > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > > > > > > > > The patch > > > > > > > > > > > > mfd: tps65218: add version check to the PMIC probe > > > > > > > > > > Why did you take this patch? > > > > > > > > I think folk need to start to understand the purpose of the To: and Cc: > > > > lines in emails. > > > > > > > > To: means you're sending the message _to_ the recipient, expecting them > > > > to be the _primary_ receiver of the message, and to _process_ the message > > > > in some way. In the case of a patch, that may be applying the change. > > > > > > > > Cc: means you're providing the recipient with a copy of the message, "for > > > > their information" and you're not expecting them to take action. > > > > > > > > If you think that there's no difference between To: and Cc: then ask > > > > yourself this question: what's the point of having the two headers, > > > > why not list all recipients under one single header. > > > > > > > > Mark was in the To: line, therefore it is perfectly reasonable for him > > > > to apply the patch when it gets acked, since the original author sent > > > > it _TO_ Mark implicitly asking him to apply it. > > > > > > > > If you have a problem with that, then you need to say something in > > > > reply to the patch, or you need to instruct folk who send patches for > > > > bits of your subsystem not to place others in the To: field who may > > > > pick up the patch. > > > > > > It's not up to submitters which repo patches get applied to. They are > > > free to make a verbal (written) request and if it's justified then we > > > can choose to agree to it or not. > > > > Wrong. It's up to submitters to send TO the person who they want to > > apply the patch - that's how it's always worked. > > > > What's become broken is this idea of "I absolutely own this area of the > > kernel, all patches _must_ come through me." That's never been the case. > > > > There may be a good reason why the submitter doesn't want the normal > > maintainer of an area of the kernel to take the patch, in which case > > the submitter has every right to decide who should take their patch. > > The wrong maintainer taking the patch can screw up the submitters > > workflow, cause additional conflicts, or break dependencies. The > > submitter is the best person to decide who should apply their change. > > I agree that the submitter is the best person to provide a compelling > case to re-route a patch's normal submission path. I disagree that > they have the final say. I'm *not* saying that they have the final say - that's completely _your_ invention. They are making the request, and people can still ignore, refuse, or reply saying that they don't want to take it - all of those are valid actions of someone listed in the To: header. However, you should not be surprised if a person listed in the To: header does action the merge if they think that's the reasonable thing for them to do. > > If people want me to take some action with their message, they had > > better put me in the To: line and _not_ the Cc, otherwise they're > > risking me ignoring them for a long time. > > I'm not sure many people work like that, sending or receiving. In my > case I deal with every mail I receive, firstly by brain grepping -- > skimming over the subject headers for mails I consider urgent. > Everything else gets marked as 'important' and is dealt with > chronologically. No where in my workflow to do filter by, or consider > To: and Cc: fields. That just sounds like too much effort. My mutt is normally set with "~p | ~P" so I don't even see any message that I'm not expicitly listed in the To or Cc anymore - that's because if I don't do that, due to the number of emails I get, I can't track _anything_. That was highlighted by a security bug that came up earlier this year that got totally buried in my mailbox and completely forgotten. Since then, I've decided that it's just impossible for me to do anything but filter away every mail that I'm not explicitly in those headers. I asked Linus how he deals with his mail, and he's the same: he may be subscribed to several mailing lists, but he doesn't _read_ any email that he's not listed in the To or Cc fields, and even then he tries to get rid of it as quickly as possible. So, I'm doing kind of what Linus does to cope with his mail stream: if you want me to read your message, you have to put me in the headers, otherwise be prepared for me to ignore your message for a very long time (possibly never read it.) And as I've said, wanting me to do something needs me in the To: header because I'll look at those with a higher priority. Mutt makes that nice and easy, giving a T (for To), C (for Cc), and a + for personal messages in the index. But... my point still stands. This is how To and Cc have worked universally, even before email. There's plenty of articles on the net describing the correct use of To, Cc, and Bcc, most of which back up my point. It's a basic English writing skill and it was important when sending memos around a company to get it right. Thankfully, memos didn't need to be threaded unlike emails today. However, the same point _does_ still exist. It's down to pure laziness that this is not followed as it should be, and it's not surprising that things go wrong as a result. So, keep making unreasonable expectations of others and writing poor emails if you like, just don't expect the outcome you wish every time, as illustrated by what happened earlier in this thread!
On Thu, 01 Sep 2016, Russell King - ARM Linux wrote: > On Thu, Sep 01, 2016 at 12:19:18PM +0100, Lee Jones wrote: > > On Thu, 01 Sep 2016, Russell King - ARM Linux wrote: > > > > > On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote: > > > > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote: > > > > > > > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote: > > > > > > On Wed, 10 Aug 2016, Mark Brown wrote: > > > > > > > > > > > > > The patch > > > > > > > > > > > > > > mfd: tps65218: add version check to the PMIC probe > > > > > > > > > > > > Why did you take this patch? > > > > > > > > > > I think folk need to start to understand the purpose of the To: and Cc: > > > > > lines in emails. > > > > > > > > > > To: means you're sending the message _to_ the recipient, expecting them > > > > > to be the _primary_ receiver of the message, and to _process_ the message > > > > > in some way. In the case of a patch, that may be applying the change. > > > > > > > > > > Cc: means you're providing the recipient with a copy of the message, "for > > > > > their information" and you're not expecting them to take action. > > > > > > > > > > If you think that there's no difference between To: and Cc: then ask > > > > > yourself this question: what's the point of having the two headers, > > > > > why not list all recipients under one single header. > > > > > > > > > > Mark was in the To: line, therefore it is perfectly reasonable for him > > > > > to apply the patch when it gets acked, since the original author sent > > > > > it _TO_ Mark implicitly asking him to apply it. > > > > > > > > > > If you have a problem with that, then you need to say something in > > > > > reply to the patch, or you need to instruct folk who send patches for > > > > > bits of your subsystem not to place others in the To: field who may > > > > > pick up the patch. > > > > > > > > It's not up to submitters which repo patches get applied to. They are > > > > free to make a verbal (written) request and if it's justified then we > > > > can choose to agree to it or not. > > > > > > Wrong. It's up to submitters to send TO the person who they want to > > > apply the patch - that's how it's always worked. > > > > > > What's become broken is this idea of "I absolutely own this area of the > > > kernel, all patches _must_ come through me." That's never been the case. > > > > > > There may be a good reason why the submitter doesn't want the normal > > > maintainer of an area of the kernel to take the patch, in which case > > > the submitter has every right to decide who should take their patch. > > > The wrong maintainer taking the patch can screw up the submitters > > > workflow, cause additional conflicts, or break dependencies. The > > > submitter is the best person to decide who should apply their change. > > > > I agree that the submitter is the best person to provide a compelling > > case to re-route a patch's normal submission path. I disagree that > > they have the final say. > > I'm *not* saying that they have the final say - that's completely _your_ > invention. They are making the request, and people can still ignore, > refuse, or reply saying that they don't want to take it - all of those > are valid actions of someone listed in the To: header. Okay, we are in agreement then. :) > However, you > should not be surprised if a person listed in the To: header does action > the merge if they think that's the reasonable thing for them to do. I would never take a patch from another subsystem without permission from its Maintainer. And I would/do get pretty shirty when others do the same to me. It's not a terrestrial thing. If we transcended into a free-for-all, or to a lesser extent, patches touching the same file are routed into multiple repos, then we run the risk of conflict at merge time. Hence why I go to all that effort to provide pull- requests to immutable branches when I do so. > > > If people want me to take some action with their message, they had > > > better put me in the To: line and _not_ the Cc, otherwise they're > > > risking me ignoring them for a long time. > > > > I'm not sure many people work like that, sending or receiving. In my > > case I deal with every mail I receive, firstly by brain grepping -- > > skimming over the subject headers for mails I consider urgent. > > Everything else gets marked as 'important' and is dealt with > > chronologically. No where in my workflow to do filter by, or consider > > To: and Cc: fields. That just sounds like too much effort. > > My mutt is normally set with "~p | ~P" so I don't even see any message > that I'm not expicitly listed in the To or Cc anymore - that's because > if I don't do that, due to the number of emails I get, I can't track > _anything_. That was highlighted by a security bug that came up earlier > this year that got totally buried in my mailbox and completely forgotten. > Since then, I've decided that it's just impossible for me to do anything > but filter away every mail that I'm not explicitly in those headers. Apologies for misleading you a little. I too do that. I have lots of filters which only place *relevant* mails in my 'Personal' folder, which is the only mail folder I operate on. All filters are duplicated though -- again I do not differentiate between To: and Cc: headers. > I asked Linus how he deals with his mail, and he's the same: he may be > subscribed to several mailing lists, but he doesn't _read_ any email > that he's not listed in the To or Cc fields, and even then he tries to > get rid of it as quickly as possible. Yeah, likewise. > So, I'm doing kind of what Linus does to cope with his mail stream: if > you want me to read your message, you have to put me in the headers, > otherwise be prepared for me to ignore your message for a very long > time (possibly never read it.) And as I've said, wanting me to do > something needs me in the To: header because I'll look at those with > a higher priority. Mutt makes that nice and easy, giving a T (for > To), C (for Cc), and a + for personal messages in the index. I didn't know know about those bindings, but as I say, I probably wouldn't use them anyway. Do you seriously/actually use them? Even knowing full well that contributors do not use them as you expect? > But... my point still stands. This is how To and Cc have worked > universally, even before email. There's plenty of articles on the net > describing the correct use of To, Cc, and Bcc, most of which back up my > point. It's a basic English writing skill and it was important when > sending memos around a company to get it right. Thankfully, memos > didn't need to be threaded unlike emails today. However, the same > point _does_ still exist. It's down to pure laziness that this is not > followed as it should be, and it's not surprising that things go wrong > as a result. I think there is certainly a place for To: and Cc:, but it is my *personal* (I'm not trying to preach to anyone) that they are a) not used as perhaps they should be and b) due to (a) not much use, thus I ignore them. And yes, I agree, it's due to laziness/lack of time/the fact that they are pretty pointless in an ML setting that the difference between To: and Cc: are not seen as important enough to be handled differently. > So, keep making unreasonable expectations of others and writing poor > emails if you like, just don't expect the outcome you wish every time, > as illustrated by what happened earlier in this thread! Not quite sure how we arrived at this point, but it is my belief that this misunderstanding didn't have anything to do with mail headers. Mark and I resolved the real issue in another part of the thread.
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c index 80b9dc363cd8..ba610adbdbff 100644 --- a/drivers/mfd/tps65218.c +++ b/drivers/mfd/tps65218.c @@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client, struct tps65218 *tps; const struct of_device_id *match; int ret; + unsigned int chipid; match = of_match_device(of_tps65218_match_table, &client->dev); if (!match) { @@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client, if (ret < 0) return ret; + ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid); + if (ret) { + dev_err(tps->dev, "Failed to read chipid: %d\n", ret); + return ret; + } + + tps->rev = chipid & TPS65218_CHIPID_REV_MASK; + ret = of_platform_populate(client->dev.of_node, NULL, NULL, &client->dev); if (ret < 0) diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h index 7fdf5326f34e..85e464e32c43 100644 --- a/include/linux/mfd/tps65218.h +++ b/include/linux/mfd/tps65218.h @@ -267,6 +267,7 @@ struct tps_info { struct tps65218 { struct device *dev; unsigned int id; + u8 rev; struct mutex tps_lock; /* lock guarding the data structure */ /* IRQ Data */