another error path used only between successfully
enabling the core clock, and successfully enabling the div clock.
That would ensure that core clock is disabled only if it was enabled before.
Signed-off-by: Michał Zegan
---
changes since v1:
cherry picked on top of mmc next branch
drivers/mmc
The mmc host was added in meson_mmc_probe, but never removed in
meson_mmc_remove.
Fix that by removing the host before deallocating other resources.
Signed-off-by: Michał Zegan
Tested-by: Michał Zegan
---
changes since v1:
rebased on top of patchset at
https://patchwork.kernel.org/patch/9581057
another error path used only between successfully
enabling the core clock, and successfully enabling the div clock.
That would ensure that core clock is disabled only if it was enabled before.
Signed-off-by: Michał Zegan
---
applies on top of Heiner's patchset v3
https://patchwork.kernel.org/
W dniu 17.02.2017 o 20:47, Kevin Hilman pisze:
> Michał Zegan writes:
>
>> The mmc host was added in meson_mmc_probe, but never removed in
>> meson_mmc_remove.
>> Fix that by removing the host before deallocating other resources.
>>
>> Signed-off-by: Micha
W dniu 17.02.2017 o 20:44, Kevin Hilman pisze:
> Michał Zegan writes:
>
>> At the end of function meson_mmc_clk_init, the cfg_div clock was
>> prepared, enabled and configured, but then immediately disabled due to bogus
>> if statements.
>> That made later
This patch series fixes mmc driver unloading.
Previously, unloading meson-gx-mmc module would trigger kernel warnings.
Michał Zegan (2):
mmc: meson-gx: prevent cfg_div_clk from being disabled on init
mmc: meson-gx: remove mmc host on device removal
drivers/mmc/host/meson-gx-mmc.c | 9
Sorry, did not send the whole patch series and have to resend.
W dniu 16.02.2017 o 15:39, Michał Zegan pisze:
> This patch series fixes mmc driver unloading.
> Previously, unloading meson-gx-mmc module would trigger kernel warnings.
>
> Michał Zegan (2):
> mmc: meson-gx: prev
The mmc host was added in meson_mmc_probe, but never removed in
meson_mmc_remove.
Fix that by removing the host before deallocating other resources.
Signed-off-by: Michał Zegan
---
drivers/mmc/host/meson-gx-mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/meson-gx
to disable clock only when it failed to be
configured.
Signed-off-by: Michał Zegan
---
drivers/mmc/host/meson-gx-mmc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 09739352834c..d444b6bfa02b
This patch contains fixes for the meson-gx-mmc driver, that allow the module to
be unloaded correctly.
Before trying to unload the module caused kernel warnings.
Michał Zegan (2):
mmc: meson-gx: prevent cfg_div_clk from being disabled on init
mmc: meson-gx: remove mmc host on device removal
Of course.
W dniu 09.01.2017 o 10:58, Sudeep Holla pisze:
>
>
> On 07/01/17 00:44, Michał Zegan wrote:
>> seems the patch works as intended.
>>
>
> So, can we take this as
> Tested-by: Michał Zegan ?
>
>> W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
&
probe and
> also when the CPUs are hot-plugged back in.
>
> This patch fixes the issue by adding the virtual cpufreq device only if
> the SCPI DVFS clock provider is available and registered.
>
> Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device&quo
Yes, I meant what you think I meant. :) thanks
W dniu 06.01.2017 o 12:54, Sudeep Holla pisze:
> Hi Michał,
>
> On 05/01/17 19:04, Michał Zegan wrote:
>> Hello.
>>
>> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
>> it actually works, bu
Hello.
The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
it actually works, but...
Loading the module causes few errors because of not found frequencies or
something, then it is all okay. However after loading scpi-cpufreq you
cannot actually power the cpu off and on. You wi
I have one question: what uids are written in the filesystem inodes?
those that the kernel sees, or those mapped by user namespaces? and so,
is it true that the filesystem will still require shifting uids,
directly or indirectly, to be usable from inside user namespace? can't
uids be mapped dynamic
Hello. I wanted to unsubscribe from this list, sent a line "subscribe
linux-kernel" to majord...@vger.kernel.org, but it does not reply at
all. what is/may be the problem?
I wanted to switch to more specific lists to track things I am
specifically interested in
As I sent a reply in a ... wrong way, I do it again. my question was:
Why isn't it done at the vfs layer when you mount the fs in different
userns, instead of using a separate filesystem for it? I believe it
could be useful to be able to mount all filesystems in userns with
autoshifted uids, althou
sorry, resending to list
I admit I am a newbie and not even a kernel developer, but for
curiosity: couldn't that uid shifting be done at the vfs layer when we
are mounting the fs in a different user ns?
W dniu 01.06.2016 o 02:29, James Bottomley pisze:
> [This patch is updated for the new VFS APIs
18 matches
Mail list logo
