| Message ID | 20151114175915.GA20429@amd (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > with device that does not have dev_name initialized. OK, that'll be the problem then - we're not mapping the supply into the individual child device but rather system wide, probably because that mapping is being done too early, before we've actually created the device. > regulator_bulk_register_supply_alias() results in "Adding alias" > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > another "MICVDD". That's fine because all supplies should be namespaced with a device. The goal is to say "Supply X on device Y" (we do support exceptions for the few cases where there are not yet any devices involved but this clearly isn't one of them). > And now we have > sound/soc/codecs/wm5102.c, around line 1093: > @@ -1092,7 +1094,6 @@ SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", > ARIZONA_OUTPUT_ASYNC_CLOCK, > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), > SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), > -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS), > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0), > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0), > That is the regulator<->alsa interface I'm talking about. But as you So if you look at this just templates out some boilerplate regulator API client code which calls regulator_get() like any other client and then hooks that regulator into the audio power management. > may recall, I have 2 arizona chips here, so two wm5102.c instances, > and I believe this means that "MICVDD" is not suitable here, and we > want something like "MICVDD,spi32766.2" here. > But a) code does not seem to be quite ready for that, and b) you said > you disliked that approach. Please go and look at how regulator clients request their supplies and how those get resolved into actual supplies - it's exactly the same struct device based namespacing that we use for clocks, PWMs and other resources. It's not that I dislike this approach, it's that this approach does not make sense in the model we use for requesting supplies and is not supported in any way by the code. I'm not sure how I can be any clearer that supply names are namespaced by client device and that as a result fiddling around with the supply name is not going to help anything. > > to be on something like the same page here, at the very least I need you > > to talk about what code you're looking at and what you don't understand > > so I can try to help you follow it but right now I'm just not sure where > > to start, it feels like you're trying to treat a lot of the code as a > > black box without following the abstractions it provides which makes > > things very hard. > Well, the code is pretty close to the black box for me :-(. How far have you got in trying to follow the code, what specific areas are confusing you? > Ok, good. I don't understand how the things are expected to fit > together. See above. I believe SND_SOC_ macros should have another > argument "device", or maybe regulator names should have "device" name > embedded in them. Regulator names *do* have a device. This is the whole point with namespacing by client device.
HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > with device that does not have dev_name initialized. > > OK, that'll be the problem then - we're not mapping the supply into the > individual child device but rather system wide, probably because that > mapping is being done too early, before we've actually created the > device. Take a look at mfd_add_device(). Yes, we do regulator_bulk_register_supply_alias() before doing platform_device_add(). > > regulator_bulk_register_supply_alias() results in "Adding alias" > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > another "MICVDD". > > That's fine because all supplies should be namespaced with a device. > The goal is to say "Supply X on device Y" (we do support exceptions for > the few cases where there are not yet any devices involved but this > clearly isn't one of them). Well, clearly someone should tell that to wm5102 maintainers. Hmm. It looks like driver is marked supported but there are no names attached? WOLFSON MICROELECTRONICS DRIVERS L: patches@opensource.wolfsonmicro.com T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus W: http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ s S: Supported I guess Charles Keepax should be listed there? > > And now we have > > > sound/soc/codecs/wm5102.c, around line 1093: > > > @@ -1092,7 +1094,6 @@ SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", > > ARIZONA_OUTPUT_ASYNC_CLOCK, > > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), > > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), > > SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), > > -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS), > > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0), > > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0), > > > That is the regulator<->alsa interface I'm talking about. But as you > > So if you look at this just templates out some boilerplate regulator API > client code which calls regulator_get() like any other client and then > hooks that regulator into the audio power management. Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have two regulators, right? Is there similar macro I can use? Do you have an example (filename, linenumber) of sound driver that gets this right? > > may recall, I have 2 arizona chips here, so two wm5102.c instances, > > and I believe this means that "MICVDD" is not suitable here, and we > > want something like "MICVDD,spi32766.2" here. > > > But a) code does not seem to be quite ready for that, and b) you said > > you disliked that approach. > > Please go and look at how regulator clients request their supplies and > how those get resolved into actual supplies - it's exactly the same > struct device based namespacing that we use for clocks, PWMs and other > resources. It's not that I dislike this approach, it's that this > approach does not make sense in the model we use for requesting supplies > and is not supported in any way by the code. > > I'm not sure how I can be any clearer that supply names are namespaced > by client device and that as a result fiddling around with the supply > name is not going to help anything. Well, you are saying that pretty clearly, but sound driver I seen assumes names are global, and /sys interface assumed the names are global. Give me an example I can look at and I should be able to figure it out... You are clear, but the kernel code seems to disagree with you. Best regards, Pavel
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > with device that does not have dev_name initialized. > > OK, that'll be the problem then - we're not mapping the supply into the > > individual child device but rather system wide, probably because that > > mapping is being done too early, before we've actually created the > > device. > Take a look at mfd_add_device(). Yes, we do > regulator_bulk_register_supply_alias() before doing > platform_device_add(). Looking at this I suspect we need to re-add the code for matching regulators on the actual struct device and do that since this is going to be very error prone. > I guess Charles Keepax should be listed there? Possibly, up to them. > > So if you look at this just templates out some boilerplate regulator API > > client code which calls regulator_get() like any other client and then > > hooks that regulator into the audio power management. > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have > two regulators, right? Is there similar macro I can use? No? What would make you say that? > Do you have an example (filename, linenumber) of sound driver that > gets this right? I'm not aware of any drivers that get this wrong. > > I'm not sure how I can be any clearer that supply names are namespaced > > by client device and that as a result fiddling around with the supply > > name is not going to help anything. > Well, you are saying that pretty clearly, but sound driver I seen > assumes names are global, and /sys interface assumed the names are > global. Give me an example I can look at and I should be able to > figure it out... You are clear, but the kernel code seems to disagree > with you. Every single sound driver gets this right, none of them assume the name is global. What makes you say that they assume names are global?
Hi! > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > > with device that does not have dev_name initialized. > > > > OK, that'll be the problem then - we're not mapping the supply into the > > > individual child device but rather system wide, probably because that > > > mapping is being done too early, before we've actually created the > > > device. > > > Take a look at mfd_add_device(). Yes, we do > > regulator_bulk_register_supply_alias() before doing > > platform_device_add(). > > Looking at this I suspect we need to re-add the code for matching > regulators on the actual struct device and do that since this is going > to be very error prone. Well, I guess I can test the patches :-). > > > So if you look at this just templates out some boilerplate regulator API > > > client code which calls regulator_get() like any other client and then > > > hooks that regulator into the audio power management. > > > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have > > two regulators, right? Is there similar macro I can use? > > No? What would make you say that? Well.. the fact that in my setup regulators are global (by mistake as you say?) and it still picks them up without warning? Plus, I'd expect to see some kind of "struct device" argument to SND_SOC_DAPM_REGULATOR_SUPPLY(). I'm selecting supply name, but I'm not selecting on which device... > Every single sound driver gets this right, none of them assume the name > is global. What makes you say that they assume names are global? Ok, so you are saying that if I fix mfd initialization, sound will automagically switch from global regulators to device-specific regulators and things will start working? Thanks, Pavel
On Mon, Nov 16, 2015 at 08:45:34AM +0100, Pavel Machek wrote: > > > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have > > > two regulators, right? Is there similar macro I can use? > > No? What would make you say that? > Plus, I'd expect to see some kind of "struct device" argument to > SND_SOC_DAPM_REGULATOR_SUPPLY(). I'm selecting supply name, but I'm > not selecting on which device... I've already pointed you at the implementation at least once and hopefully the regulator API interfaces are quite clear here too that it's not possible to request a regulator without providing a device. > > Every single sound driver gets this right, none of them assume the name > > is global. What makes you say that they assume names are global? > Ok, so you are saying that if I fix mfd initialization, sound will > automagically switch from global regulators to device-specific > regulators and things will start working? Yes.
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > Hi! > > > If you're asking about the regulator API or embedded ALSA both of those > > are me but there are other things in here - the driver you're working > > with and the MFD core at least. At the minute I'm not convinced that > > the problem here isn't just that the MFD and/or MFD core hasn't set up > > the mappings to the child devices properly. > > Ok, good. I don't understand how the things are expected to fit > together. See above. I believe SND_SOC_ macros should have another > argument "device", or maybe regulator names should have "device" name > embedded in them. Effectively the device is passed it is just implicit. If you look where the regulator is actually registered in soc-dapm.c case snd_soc_dapm_regulator_supply: w->regulator = devm_regulator_get(dapm->dev, w->name); if (IS_ERR(w->regulator)) { You see we are requesting the regulator with the dapm device, which will correspond to the CODEC. Thanks, Charles
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > with device that does not have dev_name initialized. > > > > OK, that'll be the problem then - we're not mapping the supply into the > > individual child device but rather system wide, probably because that > > mapping is being done too early, before we've actually created the > > device. > > Take a look at mfd_add_device(). Yes, we do > regulator_bulk_register_supply_alias() before doing > platform_device_add(). > > > > regulator_bulk_register_supply_alias() results in "Adding alias" > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > > another "MICVDD". > > > > That's fine because all supplies should be namespaced with a device. > > The goal is to say "Supply X on device Y" (we do support exceptions for > > the few cases where there are not yet any devices involved but this > > clearly isn't one of them). Indeed that should be the case. > > Well, clearly someone should tell that to wm5102 > maintainers. Hmm. It looks like driver is marked supported but there > are no names attached? > > WOLFSON MICROELECTRONICS DRIVERS > L: patches@opensource.wolfsonmicro.com > T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc > T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus > W: > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ > s > S: Supported > > I guess Charles Keepax should be listed there? The patches mailing list functions as maintainer here. That way anyone who works on upstream Linux stuff here will see the email so you have more chance of someone replying. Also convient for when people leave the company etc. makes for an easy transition. I am afraid though that as in this case you are not always going to get a reply over the weekend. Thanks, Charles
On Mon 2015-11-16 14:11:42, Charles Keepax wrote: > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > > with device that does not have dev_name initialized. > > > > > > OK, that'll be the problem then - we're not mapping the supply into the > > > individual child device but rather system wide, probably because that > > > mapping is being done too early, before we've actually created the > > > device. > > > > Take a look at mfd_add_device(). Yes, we do > > regulator_bulk_register_supply_alias() before doing > > platform_device_add(). > > > > > > regulator_bulk_register_supply_alias() results in "Adding alias" > > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > > > another "MICVDD". > > > > > > That's fine because all supplies should be namespaced with a device. > > > The goal is to say "Supply X on device Y" (we do support exceptions for > > > the few cases where there are not yet any devices involved but this > > > clearly isn't one of them). > > Indeed that should be the case. > > > > > Well, clearly someone should tell that to wm5102 > > maintainers. Hmm. It looks like driver is marked supported but there > > are no names attached? > > > > WOLFSON MICROELECTRONICS DRIVERS > > L: patches@opensource.wolfsonmicro.com > > T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc > > T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus > > W: > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ > > s > > S: Supported > > > > I guess Charles Keepax should be listed there? > > The patches mailing list functions as maintainer here. That way > anyone who works on upstream Linux stuff here will see the email > so you have more chance of someone replying. Also convient for > when people leave the company etc. makes for an easy transition. > I am afraid though that as in this case you are not always going > to get a reply over the weekend. Well.. maintainer is a responsible person. Yes, you can list a mailing list in maintainers file.. but mailing list is not going to be responsible for that. Having a real name of person helps; if your name was listed there, I'd know you (are supposed to be) authoritative person for this. I see it will need to be updated from time to time, but having name really helps. Thanks, Pavel
On Sun, 22 Nov 2015, Pavel Machek wrote: > On Mon 2015-11-16 14:11:42, Charles Keepax wrote: > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > > > > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > > > with device that does not have dev_name initialized. > > > > > > > > OK, that'll be the problem then - we're not mapping the supply into the > > > > individual child device but rather system wide, probably because that > > > > mapping is being done too early, before we've actually created the > > > > device. > > > > > > Take a look at mfd_add_device(). Yes, we do > > > regulator_bulk_register_supply_alias() before doing > > > platform_device_add(). > > > > > > > > regulator_bulk_register_supply_alias() results in "Adding alias" > > > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > > > > another "MICVDD". > > > > > > > > That's fine because all supplies should be namespaced with a device. > > > > The goal is to say "Supply X on device Y" (we do support exceptions for > > > > the few cases where there are not yet any devices involved but this > > > > clearly isn't one of them). > > > > Indeed that should be the case. > > > > > > > > Well, clearly someone should tell that to wm5102 > > > maintainers. Hmm. It looks like driver is marked supported but there > > > are no names attached? > > > > > > WOLFSON MICROELECTRONICS DRIVERS > > > L: patches@opensource.wolfsonmicro.com > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus > > > W: > > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ > > > s > > > S: Supported > > > > > > I guess Charles Keepax should be listed there? > > > > The patches mailing list functions as maintainer here. That way > > anyone who works on upstream Linux stuff here will see the email > > so you have more chance of someone replying. Also convient for > > when people leave the company etc. makes for an easy transition. > > I am afraid though that as in this case you are not always going > > to get a reply over the weekend. > > Well.. maintainer is a responsible person. Yes, you can list a mailing > list in maintainers file.. but mailing list is not going to be > responsible for that. > > Having a real name of person helps; if your name was listed there, I'd > know you (are supposed to be) authoritative person for this. > > I see it will need to be updated from time to time, but having name > really helps. A Mailing List is perfectly adequate for drivers which reside in a maintained subsystem. No requirement to submit names, particularly if there are lots of authorities personnel or if the personalities change regularly.
On Mon 2015-11-23 08:18:57, Lee Jones wrote: > On Sun, 22 Nov 2015, Pavel Machek wrote: > > > On Mon 2015-11-16 14:11:42, Charles Keepax wrote: > > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > > > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > > > > > > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > > > > with device that does not have dev_name initialized. > > > > > > > > > > OK, that'll be the problem then - we're not mapping the supply into the > > > > > individual child device but rather system wide, probably because that > > > > > mapping is being done too early, before we've actually created the > > > > > device. > > > > > > > > Take a look at mfd_add_device(). Yes, we do > > > > regulator_bulk_register_supply_alias() before doing > > > > platform_device_add(). > > > > > > > > > > regulator_bulk_register_supply_alias() results in "Adding alias" > > > > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > > > > > another "MICVDD". > > > > > > > > > > That's fine because all supplies should be namespaced with a device. > > > > > The goal is to say "Supply X on device Y" (we do support exceptions for > > > > > the few cases where there are not yet any devices involved but this > > > > > clearly isn't one of them). > > > > > > Indeed that should be the case. > > > > > > > > > > > Well, clearly someone should tell that to wm5102 > > > > maintainers. Hmm. It looks like driver is marked supported but there > > > > are no names attached? > > > > > > > > WOLFSON MICROELECTRONICS DRIVERS > > > > L: patches@opensource.wolfsonmicro.com > > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc > > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus > > > > W: > > > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ > > > > s > > > > S: Supported > > > > > > > > I guess Charles Keepax should be listed there? > > > > > > The patches mailing list functions as maintainer here. That way > > > anyone who works on upstream Linux stuff here will see the email > > > so you have more chance of someone replying. Also convient for > > > when people leave the company etc. makes for an easy transition. > > > I am afraid though that as in this case you are not always going > > > to get a reply over the weekend. > > > > Well.. maintainer is a responsible person. Yes, you can list a mailing > > list in maintainers file.. but mailing list is not going to be > > responsible for that. > > > > Having a real name of person helps; if your name was listed there, I'd > > know you (are supposed to be) authoritative person for this. > > > > I see it will need to be updated from time to time, but having name > > really helps. > > A Mailing List is perfectly adequate for drivers which reside in a > maintained subsystem. No requirement to submit names, particularly if > there are lots of authorities personnel or if the personalities change > regularly. That's what I'm saying. It is good to know who is the person of authority, as you can't tell from the From: address. Pavel
On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote: > On Mon 2015-11-23 08:18:57, Lee Jones wrote: > > On Sun, 22 Nov 2015, Pavel Machek wrote: > > > > > On Mon 2015-11-16 14:11:42, Charles Keepax wrote: > > > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote: > > > > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote: > > > > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote: > > > > > > > > > > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias() > > > > > > > with device that does not have dev_name initialized. > > > > > > > > > > > > OK, that'll be the problem then - we're not mapping the supply into the > > > > > > individual child device but rather system wide, probably because that > > > > > > mapping is being done too early, before we've actually created the > > > > > > device. > > > > > > > > > > Take a look at mfd_add_device(). Yes, we do > > > > > regulator_bulk_register_supply_alias() before doing > > > > > platform_device_add(). > > > > > > > > > > > > regulator_bulk_register_supply_alias() results in "Adding alias" > > > > > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register > > > > > > > another "MICVDD". > > > > > > > > > > > > That's fine because all supplies should be namespaced with a device. > > > > > > The goal is to say "Supply X on device Y" (we do support exceptions for > > > > > > the few cases where there are not yet any devices involved but this > > > > > > clearly isn't one of them). > > > > > > > > Indeed that should be the case. > > > > > > > > > > > > > > Well, clearly someone should tell that to wm5102 > > > > > maintainers. Hmm. It looks like driver is marked supported but there > > > > > are no names attached? > > > > > > > > > > WOLFSON MICROELECTRONICS DRIVERS > > > > > L: patches@opensource.wolfsonmicro.com > > > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc > > > > > T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus > > > > > W: > > > > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\ > > > > > s > > > > > S: Supported > > > > > > > > > > I guess Charles Keepax should be listed there? > > > > > > > > The patches mailing list functions as maintainer here. That way > > > > anyone who works on upstream Linux stuff here will see the email > > > > so you have more chance of someone replying. Also convient for > > > > when people leave the company etc. makes for an easy transition. > > > > I am afraid though that as in this case you are not always going > > > > to get a reply over the weekend. > > > > > > Well.. maintainer is a responsible person. Yes, you can list a mailing > > > list in maintainers file.. but mailing list is not going to be > > > responsible for that. > > > > > > Having a real name of person helps; if your name was listed there, I'd > > > know you (are supposed to be) authoritative person for this. > > > > > > I see it will need to be updated from time to time, but having name > > > really helps. > > > > A Mailing List is perfectly adequate for drivers which reside in a > > maintained subsystem. No requirement to submit names, particularly if > > there are lots of authorities personnel or if the personalities change > > regularly. > > That's what I'm saying. It is good to know who is the person of > authority, as you can't tell from the From: address. > Pavel It's unreasonable to expect that one member of the Cirrus software team has the time to answer every inquiry about our drivers and never goes on vacation, or that there's only one person who is an authority about the drivers. There's a mailing list for a reason.
On Mon, Nov 23, 2015 at 10:25:22AM +0000, Richard Fitzgerald wrote: > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote: > > That's what I'm saying. It is good to know who is the person of > > authority, as you can't tell from the From: address. > It's unreasonable to expect that one member of the Cirrus software team > has the time to answer every inquiry about our drivers and never goes on > vacation, or that there's only one person who is an authority about the > drivers. There's a mailing list for a reason. It's perfectly OK to list multiple people - look at how other companies handle this, there's usually two or three people listed.
On Mon, Nov 23, 2015 at 11:30:41AM +0000, Mark Brown wrote: > On Mon, Nov 23, 2015 at 10:25:22AM +0000, Richard Fitzgerald wrote: > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote: > > > > That's what I'm saying. It is good to know who is the person of > > > authority, as you can't tell from the From: address. > > > It's unreasonable to expect that one member of the Cirrus software team > > has the time to answer every inquiry about our drivers and never goes on > > vacation, or that there's only one person who is an authority about the > > drivers. There's a mailing list for a reason. > > It's perfectly OK to list multiple people - look at how other companies > handle this, there's usually two or three people listed. I don't really object to sticking a few people in here if the general feeling is that would be better, but personally I didn't see any problem with the current setup. Shall I do a patch to add a few of us in here? Thanks, Charles
On Mon, 23 Nov 2015, Charles Keepax wrote: > On Mon, Nov 23, 2015 at 11:30:41AM +0000, Mark Brown wrote: > > On Mon, Nov 23, 2015 at 10:25:22AM +0000, Richard Fitzgerald wrote: > > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote: > > > > > > That's what I'm saying. It is good to know who is the person of > > > > authority, as you can't tell from the From: address. > > > > > It's unreasonable to expect that one member of the Cirrus software team > > > has the time to answer every inquiry about our drivers and never goes on > > > vacation, or that there's only one person who is an authority about the > > > drivers. There's a mailing list for a reason. > > > > It's perfectly OK to list multiple people - look at how other companies > > handle this, there's usually two or three people listed. > > I don't really object to sticking a few people in here if the > general feeling is that would be better, but personally I didn't > see any problem with the current setup. Me either. > Shall I do a patch to add a few of us in here? Up to you. Happy either way.
On Mon 2015-11-23 11:46:37, Charles Keepax wrote: > On Mon, Nov 23, 2015 at 11:30:41AM +0000, Mark Brown wrote: > > On Mon, Nov 23, 2015 at 10:25:22AM +0000, Richard Fitzgerald wrote: > > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote: > > > > > > That's what I'm saying. It is good to know who is the person of > > > > authority, as you can't tell from the From: address. > > > > > It's unreasonable to expect that one member of the Cirrus software team > > > has the time to answer every inquiry about our drivers and never goes on > > > vacation, or that there's only one person who is an authority about the > > > drivers. There's a mailing list for a reason. > > > > It's perfectly OK to list multiple people - look at how other companies > > handle this, there's usually two or three people listed. > > I don't really object to sticking a few people in here if the > general feeling is that would be better, but personally I didn't > see any problem with the current setup. > > Shall I do a patch to add a few of us in here? Yes, please. Pavel
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c index 14fd5cb..c05feb4 100644 --- a/drivers/mfd/mfd-core.c +++ b/drivers/mfd/mfd-core.c @@ -147,6 +147,18 @@ static int mfd_add_device(struct device *parent, int id, pdev->dev.dma_parms = parent->dma_parms; pdev->dev.coherent_dma_mask = parent->coherent_dma_mask; + + printk("mfd_add_device ... %s, %s, %s\n", cell->name, dev_name(&pdev->dev), pdev->name); + { + char buf[128]; + sprintf(buf, "%s-%s", dev_name(parent), cell->name); + pdev->dev.kobj.name = kstrdup(buf, GFP_KERNEL); + } + + + printk("mfd_add_device ... %s, %s, %s\n", cell->name, dev_name(&pdev->dev), pdev->name); + /* &pdev->dev is not initialized correctly? */ + ret = regulator_bulk_register_supply_alias( &pdev->dev, cell->parent_supplies, parent, cell->parent_supplies, diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 34f3856..0bdf435 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1670,6 +1670,8 @@ int regulator_register_supply_alias(struct device *dev, const char *id, pr_info("Adding alias for supply %s,%s -> %s,%s\n", id, dev_name(dev), alias_id, dev_name(alias_dev)); + WARN_ON(!dev); + return 0; } EXPORT_SYMBOL_GPL(regulator_register_supply_alias);