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 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

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 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. T

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 beca

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 beca

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 ther

[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.

[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

[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 --- drivers/phy/phy-spear1340-miphy.c | 13 + 1 file changed,

[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 --- drivers/phy/phy-bcm-kona-usb2.c | 1 - drivers/phy/phy-berlin-sata.c | 1

[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

[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 --- drivers/phy/phy-spear1310-miphy.c | 13 + 1 file changed, 1

[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

[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

[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

[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 --- drivers/phy/phy-mvebu-sata.c | 2 ++ 1 file changed, 2 insertions(+)

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

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 wrote: > Hello Tim, > > On 08/15/2014 07:36 AM, Tim Kryger wrote: >> On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: >> >>> Right, there's two things going on here. One is that as you describe we >>> shouldn't be putting constraints i

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On 15 August 2014 11:55, 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 >> vary voltage. The regulat

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 a

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

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'