Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
Hello Tim, On 08/15/2014 07:36 AM, Tim Kryger wrote: On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote: Right, there's two things going on here. One is that as you describe we shouldn't be putting constraints in .dtsi files if we don't know they're OK for a given board. The other thing is that on this particular board it turns out that there's no support for varying the voltages at all so it doesn't make sense to have to specify a range, there's only one value anyway so the software really should be able to figure out that fixed value all by itself. If constraints are truly irrelevant when the voltage supplied to consumers is fixed, why doesn't regulator_list_voltage honor this exemption and skip the voltage filtering that uses (potentially unspecified) constraints when output is entirely determined by a parent (or grandparent) supply that can't change its voltage? I had a similar thought before and proposed the patch: [RFC 3/5] regulator: core: Only apply constraints if available on list voltage [0]. But then Mark explained to me that this is wrong since in that case regulator_list_voltage() will list voltages that can't really be set [1]. But now I wonder why regulator_list_voltage() even list the voltage for fixed regulators (desc-fixed_uV) since they don't have the ability to vary voltage. The regulator_list_voltage() documentation says: Returns a voltage that can be passed to @regulator_set_voltage(), zero if this selector code can't be used on this system, or a negative errno. But in the case of fixed regulators, it is actually listing a voltage that can't be selected. Although regulator_set_voltage() checks if the desired voltage is equal to the regulator min_uV and max_uV and just exits in that case, it feels wrong to list the voltage for a fixed regulators. regulator_list_voltage() only works because of the way we define the generic fixed voltage regulators and that is assuming that regulator-min-microvolt and regulator-max-microvolt DT properties being the same means that the regulator is fixed. This is kind of unfortunate, maybe it would had been better to define it explicitly using a regulator-fixed-microvolt or something. If we had such a DT property, then constraints wouldn't had been set for fixed regulators and regulator_list_voltage() wouldn't list its voltage neither. It seems odd to make callers be the ones to handle this subtlety. If regulator_list_voltage() didn't list the voltage for fixed regulators, then this subtlety should had been handled by callers before but they didn't because they rely on regulator_list_voltage() to always return a voltage even for fixed regulators. Thanks, Tim Kryger Best regards, Javier [0]: https://lkml.org/lkml/2014/7/29/418 [1]: https://lkml.org/lkml/2014/7/29/453 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
On Thu, Aug 14, 2014 at 10:36:18PM -0700, Tim Kryger wrote: On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote: Right, there's two things going on here. One is that as you describe we shouldn't be putting constraints in .dtsi files if we don't know they're OK for a given board. The other thing is that on this particular board it turns out that there's no support for varying the voltages at all so it doesn't make sense to have to specify a range, there's only one value anyway so the software really should be able to figure out that fixed value all by itself. If constraints are truly irrelevant when the voltage supplied to consumers is fixed, why doesn't regulator_list_voltage honor this exemption and skip the voltage filtering that uses (potentially unspecified) constraints when output is entirely determined by a parent (or grandparent) supply that can't change its voltage? It seems odd to make callers be the ones to handle this subtlety. regulator_list_voltage() tells the consumer what voltages could be set, regulator_get_voltage() tells the consumer what the voltage currently is. These aren't quite the same thing. signature.asc Description: Digital signature
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: But now I wonder why regulator_list_voltage() even list the voltage for fixed regulators (desc-fixed_uV) since they don't have the ability to vary voltage. The regulator_list_voltage() documentation says: That's because it's very cheap to do and there is a comprehensible thing we can return - if we have to read the voltage that means potentially asking the hardware in an I2C transaction which is not cheap. It seems odd to make callers be the ones to handle this subtlety. If regulator_list_voltage() didn't list the voltage for fixed regulators, then this subtlety should had been handled by callers before but they didn't because they rely on regulator_list_voltage() to always return a voltage even for fixed regulators. There's plenty of potentially variable regulators used in these situations, I expect it's more likely that people were just ignoring the warning since it has no practical effect. signature.asc Description: Digital signature
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
Hello Mark, On 08/15/2014 11:55 AM, Mark Brown wrote: On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: But now I wonder why regulator_list_voltage() even list the voltage for fixed regulators (desc-fixed_uV) since they don't have the ability to That's because it's very cheap to do and there is a comprehensible thing we can return - if we have to read the voltage that means potentially asking the hardware in an I2C transaction which is not cheap. Thanks a lot for the explanation, that does make a lot of sense. There's plenty of potentially variable regulators used in these situations, I expect it's more likely that people were just ignoring the warning since it has no practical effect. Indeed. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example
Hello Nick, On 08/08/2014 04:52 PM, Javier Martinez Canillas wrote: On 08/07/2014 02:38 PM, Nick Dyer wrote: I'm afraid you have misunderstood the impact of this change to the way that the GPIOs coming in to the touch controller are mapped to key codes. Look Unfortunately there are no boards in mainline using this linux,gpio-keymap property so I tried to figure out what the expected values were by reading the driver. So is more than possible that I got them wrong. By passing all these keycodes the touchpad worked as expected for me and the driver did the same than the Chrome OS driver that has these keycodes hardcoded when is_tp is true. at the protocol guide for T19. I don't have access to proper documentation and I wouldn't expect people to have access to non-public docs in order to use a Device Tree binding. That's why I wanted to document an example, so using this property could be easier for others and they shouldn't have to look at the driver in order to figure it out (and getting it wrong as you said :) ) So it would be great if you could provide an example on how this is supposed to be used. Any comments on this? I would really appreciate if you can expand on how this DT property is supposed to be used so I can re-spin the atmel support patch for Peach boards. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] phy: various misc cleanups to phy drivers
Hi, This series some a few misc cleanups to the PHY drivers: - 1) Use module_platform_driver to register spear PHY drivers. This gets rid of a lof of boiler plate code. 2) Remove .owner field from drivers using module_platform_driver, as this gets overridden anyway in __platform_driver_register. 3) Remove OOM site specific failure messages. These are unecessary and make the kernel bigger. 4) Add missing kzalloc error check, which could avoid NULL ptr dereference. regards, Peter. Peter Griffin (9): phy: phy-omap-control: Remove unncessary site specific OOM messages phy: phy-mvebu-sata: Add missing error check for devm_kzalloc phy: phy-omap-usb2: Remove unncessary site specific OOM messages phy: phy-ti-pipe3: Remove unncessary site specific OOM messages phy: phy-spear1310-miphy: Remove unncessary site specific OOM messages phy: phy-spear1340-miphy: Remove unncessary site specific OOM messages phy: remove .owner field for drivers using module_platform_driver phy: phy-spear1310-miphy: Use module_platform_driver to register driver. phy: phy-spear1340-miphy: Use module_platform_driver to register driver. drivers/phy/phy-bcm-kona-usb2.c | 1 - drivers/phy/phy-berlin-sata.c | 1 - drivers/phy/phy-exynos-dp-video.c | 1 - drivers/phy/phy-exynos-mipi-video.c | 1 - drivers/phy/phy-exynos5-usbdrd.c| 1 - drivers/phy/phy-exynos5250-sata.c | 1 - drivers/phy/phy-hix5hd2-sata.c | 1 - drivers/phy/phy-miphy365x.c | 1 - drivers/phy/phy-mvebu-sata.c| 3 ++- drivers/phy/phy-omap-control.c | 5 + drivers/phy/phy-omap-usb2.c | 9 ++--- drivers/phy/phy-qcom-apq8064-sata.c | 1 - drivers/phy/phy-qcom-ipq806x-sata.c | 1 - drivers/phy/phy-samsung-usb2.c | 1 - drivers/phy/phy-spear1310-miphy.c | 17 ++--- drivers/phy/phy-spear1340-miphy.c | 17 ++--- drivers/phy/phy-sun4i-usb.c | 1 - drivers/phy/phy-ti-pipe3.c | 6 ++ drivers/phy/phy-twl4030-usb.c | 1 - drivers/phy/phy-xgene.c | 1 - 20 files changed, 11 insertions(+), 60 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] phy: phy-omap-control: Remove unncessary site specific OOM messages
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().
Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-omap-control.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 9487bf1..cb2f4d1 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -295,10 +295,8 @@ static int omap_control_phy_probe(struct platform_device
*pdev)
control_phy = devm_kzalloc(pdev-dev, sizeof(*control_phy),
GFP_KERNEL);
- if (!control_phy) {
- dev_err(pdev-dev, unable to alloc memory for control phy\n);
+ if (!control_phy)
return -ENOMEM;
- }
control_phy-dev = pdev-dev;
control_phy-type = *(enum omap_control_phy_type *)of_id-data;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] phy: phy-spear1340-miphy: Use module_platform_driver to register driver.
Using the module_platform_driver macro to register the driver as this gets
rid of a lot of the boilerplate code.
Also remove .owner field as this gets overridden in __platform_driver_register.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-spear1340-miphy.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/phy/phy-spear1340-miphy.c
b/drivers/phy/phy-spear1340-miphy.c
index ee4d66f..1ecd094 100644
--- a/drivers/phy/phy-spear1340-miphy.c
+++ b/drivers/phy/phy-spear1340-miphy.c
@@ -282,23 +282,12 @@ static struct platform_driver spear1340_miphy_driver = {
.probe = spear1340_miphy_probe,
.driver = {
.name = spear1340-miphy,
- .owner = THIS_MODULE,
.pm = spear1340_miphy_pm_ops,
.of_match_table = of_match_ptr(spear1340_miphy_of_match),
},
};
-static int __init spear1340_miphy_phy_init(void)
-{
- return platform_driver_register(spear1340_miphy_driver);
-}
-module_init(spear1340_miphy_phy_init);
-
-static void __exit spear1340_miphy_phy_exit(void)
-{
- platform_driver_unregister(spear1340_miphy_driver);
-}
-module_exit(spear1340_miphy_phy_exit);
+module_platform_driver(spear1340_miphy_driver);
MODULE_DESCRIPTION(ST SPEAR1340-MIPHY driver);
MODULE_AUTHOR(Pratyush Anand pratyush.an...@st.com);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver
This patch removes the superflous .owner field for drivers which
use the module_platform_driver or platform_driver_register api,
as this is overriden in __platform_driver_register.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-bcm-kona-usb2.c | 1 -
drivers/phy/phy-berlin-sata.c | 1 -
drivers/phy/phy-exynos-dp-video.c | 1 -
drivers/phy/phy-exynos-mipi-video.c | 1 -
drivers/phy/phy-exynos5-usbdrd.c| 1 -
drivers/phy/phy-exynos5250-sata.c | 1 -
drivers/phy/phy-hix5hd2-sata.c | 1 -
drivers/phy/phy-miphy365x.c | 1 -
drivers/phy/phy-mvebu-sata.c| 1 -
drivers/phy/phy-omap-control.c | 1 -
drivers/phy/phy-omap-usb2.c | 1 -
drivers/phy/phy-qcom-apq8064-sata.c | 1 -
drivers/phy/phy-qcom-ipq806x-sata.c | 1 -
drivers/phy/phy-samsung-usb2.c | 1 -
drivers/phy/phy-sun4i-usb.c | 1 -
drivers/phy/phy-ti-pipe3.c | 1 -
drivers/phy/phy-twl4030-usb.c | 1 -
drivers/phy/phy-xgene.c | 1 -
18 files changed, 18 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index 894fe74..c1e0ca3 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -143,7 +143,6 @@ static struct platform_driver bcm_kona_usb2_driver = {
.probe = bcm_kona_usb2_probe,
.driver = {
.name = bcm-kona-usb2,
- .owner = THIS_MODULE,
.of_match_table = bcm_kona_usb2_dt_ids,
},
};
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index 5c3a042..69ced52 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -273,7 +273,6 @@ static struct platform_driver phy_berlin_sata_driver = {
.probe = phy_berlin_sata_probe,
.driver = {
.name = phy-berlin-sata,
- .owner = THIS_MODULE,
.of_match_table = phy_berlin_sata_of_match,
},
};
diff --git a/drivers/phy/phy-exynos-dp-video.c
b/drivers/phy/phy-exynos-dp-video.c
index 8b3026e..5c6e513 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -99,7 +99,6 @@ static struct platform_driver exynos_dp_video_phy_driver = {
.probe = exynos_dp_video_phy_probe,
.driver = {
.name = exynos-dp-video-phy,
- .owner = THIS_MODULE,
.of_match_table = exynos_dp_video_phy_of_match,
}
};
diff --git a/drivers/phy/phy-exynos-mipi-video.c
b/drivers/phy/phy-exynos-mipi-video.c
index b55a92e..6a9bef1 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -165,7 +165,6 @@ static struct platform_driver exynos_mipi_video_phy_driver
= {
.driver = {
.of_match_table = exynos_mipi_video_phy_of_match,
.name = exynos-mipi-video-phy,
- .owner = THIS_MODULE,
}
};
module_platform_driver(exynos_mipi_video_phy_driver);
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b05302b..929c7d0 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -666,7 +666,6 @@ static struct platform_driver exynos5_usb3drd_phy = {
.driver = {
.of_match_table = exynos5_usbdrd_phy_of_match,
.name = exynos5_usb3drd_phy,
- .owner = THIS_MODULE,
}
};
diff --git a/drivers/phy/phy-exynos5250-sata.c
b/drivers/phy/phy-exynos5250-sata.c
index 19a679a..54cf4ae 100644
--- a/drivers/phy/phy-exynos5250-sata.c
+++ b/drivers/phy/phy-exynos5250-sata.c
@@ -240,7 +240,6 @@ static struct platform_driver exynos_sata_phy_driver = {
.driver = {
.of_match_table = exynos_sata_phy_of_match,
.name = samsung,sata-phy,
- .owner = THIS_MODULE,
}
};
module_platform_driver(exynos_sata_phy_driver);
diff --git a/drivers/phy/phy-hix5hd2-sata.c b/drivers/phy/phy-hix5hd2-sata.c
index 6a08fa5..d5d9780 100644
--- a/drivers/phy/phy-hix5hd2-sata.c
+++ b/drivers/phy/phy-hix5hd2-sata.c
@@ -180,7 +180,6 @@ static struct platform_driver hix5hd2_sata_phy_driver = {
.probe = hix5hd2_sata_phy_probe,
.driver = {
.name = hix5hd2-sata-phy,
- .owner = THIS_MODULE,
.of_match_table = hix5hd2_sata_phy_of_match,
}
};
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index e111baf..a010bf4 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -625,7 +625,6 @@ static struct platform_driver miphy365x_driver = {
.probe = miphy365x_probe,
.driver = {
.name = miphy365x-phy,
- .owner = THIS_MODULE,
.of_match_table = miphy365x_of_match,
}
};
diff --git a/drivers/phy/phy-mvebu-sata.c
[PATCH 4/9] phy: phy-ti-pipe3: Remove unncessary site specific OOM messages
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().
Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-ti-pipe3.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index b964aa9..9280ef8 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -299,10 +299,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct clk *clk;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
- if (!phy) {
- dev_err(pdev-dev, unable to alloc mem for TI PIPE3 PHY\n);
+ if (!phy)
return -ENOMEM;
- }
+
phy-dev= pdev-dev;
if (!of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] phy: phy-spear1310-miphy: Use module_platform_driver to register driver.
Use the module_platform_driver macro to register the driver as this gets
rid of a lot of the boilerplate code.
Also remove .owner field as this gets overridden in __platform_driver_register.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-spear1310-miphy.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/phy/phy-spear1310-miphy.c
b/drivers/phy/phy-spear1310-miphy.c
index 911d25b..5f4c586 100644
--- a/drivers/phy/phy-spear1310-miphy.c
+++ b/drivers/phy/phy-spear1310-miphy.c
@@ -250,22 +250,11 @@ static struct platform_driver spear1310_miphy_driver = {
.probe = spear1310_miphy_probe,
.driver = {
.name = spear1310-miphy,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(spear1310_miphy_of_match),
},
};
-static int __init spear1310_miphy_phy_init(void)
-{
- return platform_driver_register(spear1310_miphy_driver);
-}
-module_init(spear1310_miphy_phy_init);
-
-static void __exit spear1310_miphy_phy_exit(void)
-{
- platform_driver_unregister(spear1310_miphy_driver);
-}
-module_exit(spear1310_miphy_phy_exit);
+module_platform_driver(spear1310_miphy_driver);
MODULE_DESCRIPTION(ST SPEAR1310-MIPHY driver);
MODULE_AUTHOR(Pratyush Anand pratyush.an...@st.com);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] phy: phy-spear1310-miphy: Remove unncessary site specific OOM messages
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().
Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-spear1310-miphy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/phy/phy-spear1310-miphy.c
b/drivers/phy/phy-spear1310-miphy.c
index 6dcbfcd..911d25b 100644
--- a/drivers/phy/phy-spear1310-miphy.c
+++ b/drivers/phy/phy-spear1310-miphy.c
@@ -212,10 +212,8 @@ static int spear1310_miphy_probe(struct platform_device
*pdev)
struct phy_provider *phy_provider;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(dev, can't alloc spear1310_miphy private date
memory\n);
+ if (!priv)
return -ENOMEM;
- }
priv-misc =
syscon_regmap_lookup_by_phandle(dev-of_node, misc);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] phy: phy-omap-usb2: Remove unncessary site specific OOM messages
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().
Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-omap-usb2.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 93d7835..51c6f92 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -212,16 +212,12 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy_data = (struct usb_phy_data *)of_id-data;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
- if (!phy) {
- dev_err(pdev-dev, unable to allocate memory for USB2 PHY\n);
+ if (!phy)
return -ENOMEM;
- }
otg = devm_kzalloc(pdev-dev, sizeof(*otg), GFP_KERNEL);
- if (!otg) {
- dev_err(pdev-dev, unable to allocate memory for USB OTG\n);
+ if (!otg)
return -ENOMEM;
- }
phy-dev= pdev-dev;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] phy: phy-spear1340-miphy: Remove unncessary site specific OOM messages
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().
Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/phy/phy-spear1340-miphy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/phy/phy-spear1340-miphy.c
b/drivers/phy/phy-spear1340-miphy.c
index 7135ba2..ee4d66f 100644
--- a/drivers/phy/phy-spear1340-miphy.c
+++ b/drivers/phy/phy-spear1340-miphy.c
@@ -249,10 +249,8 @@ static int spear1340_miphy_probe(struct platform_device
*pdev)
struct phy_provider *phy_provider;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(dev, can't alloc spear1340_miphy private date
memory\n);
+ if (!priv)
return -ENOMEM;
- }
priv-misc =
syscon_regmap_lookup_by_phandle(dev-of_node, misc);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] phy: phy-mvebu-sata: Add missing error check for devm_kzalloc
Currently this driver is missing a check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. This patch adds the aformentioned missing check. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- drivers/phy/phy-mvebu-sata.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/phy-mvebu-sata.c b/drivers/phy/phy-mvebu-sata.c index cc3c0e1..10bb8e5 100644 --- a/drivers/phy/phy-mvebu-sata.c +++ b/drivers/phy/phy-mvebu-sata.c @@ -89,6 +89,8 @@ static int phy_mvebu_sata_probe(struct platform_device *pdev) struct phy *phy; priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); priv-base = devm_ioremap_resource(pdev-dev, res); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] phy: phy-mvebu-sata: Add missing error check for devm_kzalloc
On Fri, Aug 15, 2014 at 01:40:09PM +0100, Peter Griffin wrote: Currently this driver is missing a check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. This patch adds the aformentioned missing check. Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Andrew Lunn and...@lunn.ch Thanks Andrew --- drivers/phy/phy-mvebu-sata.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/phy-mvebu-sata.c b/drivers/phy/phy-mvebu-sata.c index cc3c0e1..10bb8e5 100644 --- a/drivers/phy/phy-mvebu-sata.c +++ b/drivers/phy/phy-mvebu-sata.c @@ -89,6 +89,8 @@ static int phy_mvebu_sata_probe(struct platform_device *pdev) struct phy *phy; priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); priv-base = devm_ioremap_resource(pdev-dev, res); -- 1.9.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
On Fri, Aug 15, 2014 at 12:48 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Tim, On 08/15/2014 07:36 AM, Tim Kryger wrote: On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote: Right, there's two things going on here. One is that as you describe we shouldn't be putting constraints in .dtsi files if we don't know they're OK for a given board. The other thing is that on this particular board it turns out that there's no support for varying the voltages at all so it doesn't make sense to have to specify a range, there's only one value anyway so the software really should be able to figure out that fixed value all by itself. If constraints are truly irrelevant when the voltage supplied to consumers is fixed, why doesn't regulator_list_voltage honor this exemption and skip the voltage filtering that uses (potentially unspecified) constraints when output is entirely determined by a parent (or grandparent) supply that can't change its voltage? I had a similar thought before and proposed the patch: [RFC 3/5] regulator: core: Only apply constraints if available on list voltage [0]. [0]: https://lkml.org/lkml/2014/7/29/418 You proposed constraints only be applied when they are defined. That is a little different from my suggestion where the constraints check is skipped when the regulator output is fixed. It effectively does this now when the regulator itself provides the fixed voltage. However, the checks aren't skipped when that fixed voltage is coming from an ancestor. Why the difference? -Tim -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
On 15 August 2014 11:55, Mark Brown broo...@kernel.org wrote: On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: But now I wonder why regulator_list_voltage() even list the voltage for fixed regulators (desc-fixed_uV) since they don't have the ability to vary voltage. The regulator_list_voltage() documentation says: That's because it's very cheap to do and there is a comprehensible thing we can return - if we have to read the voltage that means potentially asking the hardware in an I2C transaction which is not cheap. It seems odd to make callers be the ones to handle this subtlety. If regulator_list_voltage() didn't list the voltage for fixed regulators, then this subtlety should had been handled by callers before but they didn't because they rely on regulator_list_voltage() to always return a voltage even for fixed regulators. There's plenty of potentially variable regulators used in these situations, I expect it's more likely that people were just ignoring the warning since it has no practical effect. Just wanted to add some input regarding the errors in the mmc case. These are of high importance. In principle if you get, Failed getting OCR mask: -22, likely you will be using a wrong OCR mask while negotiating the voltage level with the card. So, somehow we need to address this issue. Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example
On 15/08/14 13:01, Javier Martinez Canillas wrote:
By passing all these keycodes the touchpad worked as expected for me and the
driver did the same than the Chrome OS driver that has these keycodes
hardcoded
when is_tp is true.
at the protocol guide for T19.
I don't have access to proper documentation and I wouldn't expect people to
have
access to non-public docs in order to use a Device Tree binding.
That's why I wanted to document an example, so using this property could be
easier for others and they shouldn't have to look at the driver in order to
figure it out (and getting it wrong as you said :) )
So it would be great if you could provide an example on how this is supposed
to
be used.
Any comments on this? I would really appreciate if you can expand on how
this DT property is supposed to be used so I can re-spin the atmel support
patch for Peach boards.
The below patch improves the documentation for the gpio-property. Stephen
Warren has a good example here:
https://github.com/swarren/linux-tegra/commit/09789801
trackpad@4b {
compatible = atmel,maxtouch;
reg = 0x4b;
interrupt-parent = gpio;
interrupts = TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW;
linux,gpio-keymap = 0 0 0 BTN_LEFT;
};
This maps BTN_LEFT to the 4th bit of the T19 message. I haven't looked up
what GPIO number that corresponds to on the mXT224SL that he has, it varies
with the particular maXTouch device you have.
Hope this helps.
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index baef432..1852906 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -11,10 +11,17 @@ Required properties:
Optional properties for main touchpad device:
-- linux,gpio-keymap: An array of up to 4 entries indicating the Linux
-keycode generated by each GPIO. Linux keycodes are defined in
+- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
+on GPIO bit changes. An array of up to 8 entries can be provided
+indicating the Linux keycode mapped to each bit of the status byte,
+starting at the LSB. Linux keycodes are defined in
dt-bindings/input/input.h.
+Note: the numbering of the GPIOs and the bit they start at varies between
+maXTouch devices. You must either refer to the documentation, or
+experiment to determine which bit corresponds to which input. Use
+KEY_RESERVED for unused padding values.
+
Example:
touch@4b {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example
On 08/15/2014 10:08 AM, Nick Dyer wrote:
On 15/08/14 13:01, Javier Martinez Canillas wrote:
By passing all these keycodes the touchpad worked as expected for me and the
driver did the same than the Chrome OS driver that has these keycodes hardcoded
when is_tp is true.
at the protocol guide for T19.
I don't have access to proper documentation and I wouldn't expect people to have
access to non-public docs in order to use a Device Tree binding.
That's why I wanted to document an example, so using this property could be
easier for others and they shouldn't have to look at the driver in order to
figure it out (and getting it wrong as you said :) )
So it would be great if you could provide an example on how this is supposed to
be used.
Any comments on this? I would really appreciate if you can expand on how
this DT property is supposed to be used so I can re-spin the atmel support
patch for Peach boards.
The below patch improves the documentation for the gpio-property.
That patch makes sense, and is a nice description,
Acked-by: Stephen Warren swar...@nvidia.com
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
Example:
touch@4b {
Perhaps it makes sense to add a linux,gpio-keymap property into the
example too though; IIRC there was an earlier patch to the docs that did
this?
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote: That is a little different from my suggestion where the constraints check is skipped when the regulator output is fixed. It effectively does this now when the regulator itself provides the fixed voltage. However, the checks aren't skipped when that fixed voltage is coming from an ancestor. Why the difference? Nobody has written suitable code, and please bear in mind that even if the code is written there will probably be cases where it's too expensive for whatever reason so Javier's change is going to be needed. signature.asc Description: Digital signature
