The type of this function is unsigned long, and it is expected
to return proper fout value or zero if something is wrong.
So this patch fixes wrong return value for error cases.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |
This patch corrects improper logs within the code initializing hardware.
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platfor
Hello Stephen,
On 08/13/2014 06:16 PM, Stephen Warren wrote:
>
> I'm worried that this file represents the limits of the PMIC itself,
> whereas the DT should be representing the limits of the circuits that
> the various PMIC regulators are attached to on the board.
>
> For example:
>
>> diff
Hello Mark,
On 08/13/2014 05:51 PM, Mark Brown wrote:
> On Wed, Aug 13, 2014 at 03:34:12PM +0200, Javier Martinez Canillas wrote:
>
>> Indeed. I'll change mmc_regulator_get_ocrmask() in MMC core then to use
>> regulator_can_change_voltage() to detect if the regulator is a fixed one
>> and call re
On 08/12/2014 10:44 AM, Javier Martinez Canillas wrote:
The tps65090 PMU data manual [0] has a table that list the
"Recommended operating conditions" for each regulator. Add
the information about the FET constraints to its dtsi file.
[0]: http://www.ti.com/lit/ds/symlink/tps65090.pdf
I'm worri
On 08/12/2014 10:44 AM, Javier Martinez Canillas wrote:
The tps65090 is a Power Management Unit (PMU) used in several
boards so the same information is described on different DTS.
It is better to create a .dtsi fragment that can be included.
To be honest, I'm not sure that this file is useful.
On Wed, Aug 13, 2014 at 03:34:12PM +0200, Javier Martinez Canillas wrote:
> Indeed. I'll change mmc_regulator_get_ocrmask() in MMC core then to use
> regulator_can_change_voltage() to detect if the regulator is a fixed one
> and call regulator_get_voltage() instead of list_voltage() in that case.
If we happened to get a data error at just the wrong time the dw_mmc
driver could get into a state where it would never complete its
request. That would leave the caller just hanging there.
We fix this two ways and both of the two fixes on their own appear to
fix the problems we've seen:
1. Fix
On 13 August 2014 15:38, Doug Anderson wrote:
> Hi,
>
> On Wed, May 21, 2014 at 2:08 AM, Seungwon Jeon wrote:
>> On Wed, May 21, 2014, Doug Anderson wrote:
>>> If we happened to get a data error at just the wrong time the dw_mmc
>>> driver could get into a state where it would never complete its
On 08/13/2014 10:38 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, May 21, 2014 at 2:08 AM, Seungwon Jeon wrote:
>> On Wed, May 21, 2014, Doug Anderson wrote:
>>> If we happened to get a data error at just the wrong time the dw_mmc
>>> driver could get into a state where it would never complete its
>
Hi,
On Wed, May 21, 2014 at 2:08 AM, Seungwon Jeon wrote:
> On Wed, May 21, 2014, Doug Anderson wrote:
>> If we happened to get a data error at just the wrong time the dw_mmc
>> driver could get into a state where it would never complete its
>> request. That would leave the caller just hanging t
On 08/13/2014 02:29 PM, Mark Brown wrote:
>
> Please fix your mailer to word wrap at less than 80 columns, it makes
> your mails very hard to read when replying.
>
Sorry I had my wrap length configured to 80 but just changed to 74 now.
>> On 08/12/2014 11:27 PM, Mark Brown wrote:
>
> No, that
On Wed, Aug 13, 2014 at 01:31:44PM +0200, Javier Martinez Canillas wrote:
Please fix your mailer to word wrap at less than 80 columns, it makes
your mails very hard to read when replying.
> On 08/12/2014 11:27 PM, Mark Brown wrote:
> > Well, I think the question is if you understand where those
Hello Mark,
On 08/12/2014 11:27 PM, Mark Brown wrote:
> On Tue, Aug 12, 2014 at 08:49:29PM +0200, Javier Martinez Canillas wrote:
>
>> So, is adding these voltages ranges (the design limits) in the Peach Pit DTS
>> file directly an acceptable solution? Basically what my previous patch [0]
>> did
On 24 June 2014 17:52, Tomasz Figa wrote:
> Hi Daniel,
>
> [adding Ulf, Chris and Mike to the discussion]
>
> On 24.06.2014 11:48, Daniel Drake wrote:
>> sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts
>> disabled, and this calls into sdhci_s3c_consider_clock().
>>
>> The patch
15 matches
Mail list logo