Hello everyone,
About 3 months have silently passed, without anything visibly changing.
I can't help but ask myself if Linaro has abandoned the 96borad effort
in its original form and resolved to make it a mostly Linaro internal
project. Don't get me wrong, I wouldn't mind, even in such a form it
would ultimately benefit the broader audience in terms of better
upstream support of ARMv7 and AArch64.
I do think though, that "the community" deserves to know if they are
still part of the target audience and can count on any form of support.
Personally I have a bit of a "Pandaboard past OMAPgeddon" feeling at the
moment
Thomas
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
V2: Fix compile error for error commit
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..279063c 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
The Arduino toolchain needs some help to know which UART to use when
running on a 96Board. This file adds two environmental variables to
configure both the IDE and command line Arduino tools.
JAVA_TOOL_OPTIONS adds the correct UART to the GUI IDE
MONITOR_PORT sets the correct UART for the Arduino.mk Makefile tools
Signed-off-by: Grant Likely <grant.likely(a)linaro.org>
---
This works on my platform, but it is only part of a patch. The debian
package needs to be updated to install this file as a configuration
file.
Slightly off topic, I think that we need to move to this approach for
selecting the correct serial port and get rid of the /etc/udev/rules.d
rule. The udev rule approach is fragile, and a shell script can make
intelligent decisions about how the UART is mapped to the 96Boards LS
connector.
96boards-sensors.sh | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 96boards-sensors.sh
diff --git a/96boards-sensors.sh b/96boards-sensors.sh
new file mode 100644
index 000000000000..efb1c4a8c1e8
--- /dev/null
+++ b/96boards-sensors.sh
@@ -0,0 +1,5 @@
+# Environmental variables for working with the 96Boards Sensors adapter
+#
+# Copy this file into /etc/profile.d to set up the correct environment by default
+export JAVA_TOOL_OPTIONS="-Dgnu.io.rxtx.SerialPorts=/dev/tty96B0"
+export MONITOR_PORT=/dev/tty96B0
--
2.5.0
I just build vanilla v4.4 with arm64 defconfig and it doesn't boot on
hikey. What patch set and config do I need?
I need a minimal set of patches to add to an existing project.
-Geoff
The patch sets add support for Hi6220 PMIC Hi655x MFD core and its
regulator driver.
Current testing and support board is Hikey which is one of 96boards.
It is an arm64 open source board. For more information about this board,
please access https://www.96boards.org.
This is hardware layout for access PMIC Hi655x from AP SoC Hi6220.
Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
We can use memory-mapped I/O to communicate.
+----------------+ +-------------+
| | | |
| Hi6220 | SSI bus | Hi655x |
| |-------------| |
| |(REGMAP_MMIO)| |
+----------------+ +-------------+
V2: Code refactoring of regulator.
V3: Drop mtcmos from this patch and use regmap-irq.
V4: Move the vset-table to driver code and donot open code for it.
V6: Use regulators_node and of_match, donot open code fot it.
Chen Feng (5):
doc: bindings: Add document for mfd hi665x PMIC
doc: bindings: Document for hi655x regulator driver
mfd: hi655x: Add hi665x pmic driver
regulator: add regulator driver of hi655x pmic
hisilicon/dts: Add hi655x pmic dts node
.../devicetree/bindings/mfd/hisilicon,hi655x.txt | 28 +++
.../regulator/hisilicon,hi655x-regulator.txt | 28 +++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 87 ++++++++
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/hi655x-pmic.c | 170 +++++++++++++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/hi655x-regulator.c | 227 +++++++++++++++++++++
include/linux/mfd/hi655x-pmic.h | 56 +++++
11 files changed, 621 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
create mode 100644 Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
create mode 100644 drivers/mfd/hi655x-pmic.c
create mode 100644 drivers/regulator/hi655x-regulator.c
create mode 100644 include/linux/mfd/hi655x-pmic.h
--
1.9.1
Hi,
I'm trying to flash HiKey board using standard procedure but I'm not
getting any signs of life on the host laptop after connecting the USB
cable. I checked both recovery mode and fastboot.efi. I tested with 2
cables and different USB sockets on my laptop and USB hub. Has anyone
seen the failure like this? The board is flashed with alip image and
can boot just fine.
Cheers,
milosz
hello there,
A new kernel branch for the HiKey is now available: hikey-mainline-rebase,
which is now v4.4-rc3 based. That's a start (meaning there are issues), but
topics and patches are keep coming. Goal here is to make HiKey finally land
linus' tree.
What’s new in this release?
* Based on Linux kernel v4.4-rc3
* Debian Jessie developer image, with HDMI console.
* patches are upstreaming targeted, and
* managed by topic branches, for easy rebase to latest kernel
* topics include:
hikey-tracking-dts
hikey-tracking-gpio
hikey-tracking-pmic
hikey-tracking-mmc
hikey-tracking-wifi
hikey-tracking-usb
hikey-tracking-adv7511
hikey-tracking-drm
hikey-tracking-pm
What to expect in soon future?
* topic on iommu, bt
* new builds: Debian Jessie ALIP image
* new builds: AOSP (Android M)
* patches be accepted by mainline.
Resources:
For kernel source code, ref:
https://github.com/96boards/linux/tree/hikey-mainline-rebase
For download of Debian developer image, ref:
https://builds.96boards.org/snapshots/hikey/community/hikey-mainline-rebase…
For UEFI to use with this snapshots build, ref:
https://builds.96boards.org/releases/hikey/linaro/binaries/15.11/
For documentation about everything of HiKey, please ref:
https://github.com/96boards/documentation/wiki/HiKey
Support & Bug Report:
For general question or support request, please go to 96boards Community
forum:
https://www.96boards.org/forums/forum/products/hikey/
<https://www.96boards.org/dragonboard410c/forum>
For any bug related to this release, please submit issues to the
96Boards Bug tracking system:
https://bugs.96boards.org/enter_bug.cgi?product=HiKey
Finally, to get in touch with us, you can also use IRC:
#96boards on irc.freenode.net
On behalf of the Linaro HiSilicon Landing team,
cheers,
Guodong
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..279063c 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->tsk->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..3a74c5d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->tsk->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
The page is already alloc at ion_alloc function,
ion_mmap map the alloced pages to user-space.
The default prot can be PTE_RDONLY. Take a look at
here:
set_pte_at()
arch/arm64/include/asm:
if (pte_dirty(pte) && pte_write(pte))
pte_val(pte) &= ~PTE_RDONLY;
else
pte_val(pte) |= PTE_RDONLY;
So with the dirty bit,it can improve the efficiency
and donnot need to handle memory fault when use access.
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/staging/android/ion/ion.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index e237e9f..dba5942 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1026,6 +1026,9 @@ static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ /*Default writeable*/
+ vma->vm_page_prot = pte_mkdirty(vma->vm_page_prot);
+
mutex_lock(&buffer->lock);
/* now map it to userspace */
ret = buffer->heap->ops->map_user(buffer->heap, buffer, vma);
--
1.9.1
