This patch series adds Qualcomm SD Card Controller support in pl180 mmci
driver. QCom SDCC is basically a pl180, but bit more customized, some of the
register layouts and offsets are different to the ones mentioned in pl180
datasheet. The plan is to totally remove the standalone SDCC driver
drivers/mmc/host/msm_sdcc.* and start using generic mmci driver for all
Qualcomm parts, as we get chance to test on other Qcom boards.
To start using the existing mmci driver, a fake amba id for Qualcomm is added
in patches:
ARM: amba: Add Qualcomm vendor ID.
mmc: mmci: Add Qualcomm Id to amba id table.
Second change is, adding a 3 clock cycle delay for register writes on QCOM SDCC
registers, which is done in patches:
mmc: mmci: Add register read/write wrappers.
mmc: mmci: Add write delay to variant structure.
mmc: mmci: Qcomm: Add 3 clock cycle delay after each register write
Third change was to accommodate DATCTRL and MMCICLK register layout changes in
Qcom SDCC. Which is done in patches:
mmc: mmci: Add Qcom datactrl register variant
mmc: mmci: Add Qcom variations to MCICommand register.
mmc: mmci: Qcom fix MCICLK register settings.
mmc: mmci: Add clock support for Qualcomm.
Fourth major change was to add qcom specfic pio read function, the need for
this is because the way MCIFIFOCNT register behaved in QCOM SDCC is very
different to the one in pl180. This change is done in patch:
mmc: mmci: Add Qcom specific pio_read function.
Last some Qcom unrelated changes to support Qcom are done in patches:
mmc: mmci: use NSEC_PER_SEC macro
mmc: mmci: move ST specific register extensions access under condition.
This patches are tested in PIO mode on IFC8064 board with both eMMC and
external SD card. I would appreciate any feedback/suggestions on the overall
approach.
Thanks,
srini
Srinivas Kandagatla (12):
ARM: amba: Add Qualcomm vendor ID.
mmc: mmci: Add Qualcomm Id to amba id table
mmc: mmci: Add Qcom datactrl register variant
mmc: mmci: Add register read/write wrappers.
mmc: mmci: use NSEC_PER_SEC macro
mmc: mmci: Add write delay to variant structure.
mmc: mmci: Qcomm: Add 3 clock cycle delay after each register write
mmc: mmci: move ST specific register extensions access under condition.
mmc: mmci: Qcom fix MCICLK register settings.
mmc: mmci: Add clock support for Qualcomm.
mmc: mmci: Add Qcom variations to MCICommand register.
mmc: mmci: Add Qcom specific pio_read function.
drivers/mmc/host/mmci.c | 239 +++++++++++++++++++++++++++++++++-------------
drivers/mmc/host/mmci.h | 28 ++++++
include/linux/amba/bus.h | 1 +
3 files changed, 202 insertions(+), 66 deletions(-)
--
1.7.9.5
Hi Guys,
Here is my understanding of Dave's and Russell's suggestion on [1]
to use direct write of xol slot instructions to user space. Now
posting patch through 'git send-email' since, as it was noted, my
mailer corrupts patches otherwise.
Note default case with __copy_to_user is NOT tested. It addresses
David's remark.
Personally, I am very concerned about this patch because it creates
writable and executable page in traced process. The way how uprobes
is implemented such page will stay in process even if all uprobes
are detached from process. IMHO it may create possible attack hole.
I would prefer to see any executable memory read-only all the time.
On top of that, at least in ARM case xol page address is not even
randomized, which was perfectly fine with current nowrite/noread,
just execute permissions.
Patch follows this cover letter.
Thanks,
Victor
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/247763.html
Victor Kamensky (1):
ARM: uprobes xol write directly to userspace
arch/arm/kernel/uprobes.c | 8 ++++++++
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 28 +++++++++++++++++++---------
3 files changed, 30 insertions(+), 9 deletions(-)
--
1.8.1.4
This is LSK CMA backporting for armv8. I add some kernel config for CMA
enabling. With these config, kernel will be booted with following message:
cma: CMA: reserved 16 MiB at xxxxxxxx
Linaro Stable Kernel git tree:
git://git.linaro.org/kernel/linux-linaro-stable.git
Marek,
I saw you had mentioned testing this feature with cma-regions compatibility
layer and videobuf2-cma memory allocator module. But I didn't get it by google.
Could you give a link for them?
And I will more appreciate if you'd like to take a glance for review.
Thanks!
Alex
[PATCH 1/6] mm/cma: Move dma contiguous changes into a seperate
[PATCH 2/6] drivers: dma-contiguous: clean source code and prepare
[PATCH 3/6] arm64: Enable CMA
[PATCH 4/6] arm64: add CMA support for armv8
[PATCH 5/6] arm64: fix build error if DMA_CMA is enabled
[PATCH 6/6] arm64: Align CMA sizes to PAGE_SIZE
Patch to avoid calling kernel_power_off when pm_power_off is null.
When pm_power_off is null, the platform will not power off in
kernel_power_off. Currently, hibernate will call kernel_power_off and
then move on to kernel_halt. However, this calls the notifier chain
twice with a different parameter. In kernel/reboot.c, this is avoided
by checking if pm_power_off is NULL and bypassing kernel_power_off.
Mostly, this is a check if anyone is dependent on having the reboot
notifier called 2x if pm_power_off is null. There are some panics if
it's called this way in some drivers.
Tested this on omap beaglebone black, but have not tried on other
hardware. Please let me know if you can test this on another platform
and the results.
Thanks,
Sebastian