* [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting
From: Alexander Duyck @ 2019-09-07 17:26 UTC (permalink / raw)
To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
linux-kernel, willy, mhocko, linux-mm, akpm, will,
linux-arm-kernel, osalvador
Cc: yang.zhang.wz, pagupta, riel, konrad.wilk, ying.huang,
lcapitulino, wei.w.wang, aarcange, nitesh, pbonzini,
dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov
In-Reply-To: <20190907172225.10910.34302.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Currently the page poisoning setting wasn't being enabled unless free page
hinting was enabled. However we will need the page poisoning tracking logic
as well for unused page reporting. As such pull it out and make it a
separate bit of config in the probe function.
In addition we can actually wrap the code in a check for NO_SANITY. If we
don't care what is actually in the page we can just default to 0 and leave
it there.
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
drivers/virtio/virtio_balloon.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..d2547df7de93 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
static int virtballoon_probe(struct virtio_device *vdev)
{
struct virtio_balloon *vb;
- __u32 poison_val;
int err;
if (!vdev->config->get) {
@@ -909,11 +908,18 @@ static int virtballoon_probe(struct virtio_device *vdev)
VIRTIO_BALLOON_CMD_ID_STOP);
spin_lock_init(&vb->free_page_list_lock);
INIT_LIST_HEAD(&vb->free_page_list);
- if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
- memset(&poison_val, PAGE_POISON, sizeof(poison_val));
- virtio_cwrite(vb->vdev, struct virtio_balloon_config,
- poison_val, &poison_val);
- }
+ }
+ if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+ __u32 poison_val;
+
+ /*
+ * Let hypervisor know that we are expecting a specific
+ * value to be written back in unused pages.
+ */
+ memset(&poison_val, PAGE_POISON, sizeof(poison_val));
+
+ virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+ poison_val, &poison_val);
}
/*
* We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
@@ -1014,7 +1020,9 @@ static int virtballoon_restore(struct virtio_device *vdev)
static int virtballoon_validate(struct virtio_device *vdev)
{
- if (!page_poisoning_enabled())
+ /* Notify host if we care about poison value */
+ if (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY) ||
+ !page_poisoning_enabled())
__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host
From: Alexander Duyck @ 2019-09-07 17:26 UTC (permalink / raw)
To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
linux-kernel, willy, mhocko, linux-mm, akpm, will,
linux-arm-kernel, osalvador
Cc: yang.zhang.wz, pagupta, riel, konrad.wilk, ying.huang,
lcapitulino, wei.w.wang, aarcange, nitesh, pbonzini,
dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov
In-Reply-To: <20190907172225.10910.34302.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Add support for the page reporting feature provided by virtio-balloon.
Reporting differs from the regular balloon functionality in that is is
much less durable than a standard memory balloon. Instead of creating a
list of pages that cannot be accessed the pages are only inaccessible
while they are being indicated to the virtio interface. Once the
interface has acknowledged them they are placed back into their respective
free lists and are once again accessible by the guest system.
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
drivers/virtio/Kconfig | 1 +
drivers/virtio/virtio_balloon.c | 65 +++++++++++++++++++++++++++++++++++
include/uapi/linux/virtio_balloon.h | 1 +
3 files changed, 67 insertions(+)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..4b2dd8259ff5 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -58,6 +58,7 @@ config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
select MEMORY_BALLOON
+ select PAGE_REPORTING
---help---
This driver supports increasing and decreasing the amount
of memory within a KVM guest.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index d2547df7de93..62bdb0afd022 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
#include <linux/mount.h>
#include <linux/magic.h>
#include <linux/pseudo_fs.h>
+#include <linux/page_reporting.h>
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -37,6 +38,9 @@
#define VIRTIO_BALLOON_FREE_PAGE_SIZE \
(1 << (VIRTIO_BALLOON_FREE_PAGE_ORDER + PAGE_SHIFT))
+/* limit on the number of pages that can be on the reporting vq */
+#define VIRTIO_BALLOON_VRING_HINTS_MAX 16
+
#ifdef CONFIG_BALLOON_COMPACTION
static struct vfsmount *balloon_mnt;
#endif
@@ -46,6 +50,7 @@ enum virtio_balloon_vq {
VIRTIO_BALLOON_VQ_DEFLATE,
VIRTIO_BALLOON_VQ_STATS,
VIRTIO_BALLOON_VQ_FREE_PAGE,
+ VIRTIO_BALLOON_VQ_REPORTING,
VIRTIO_BALLOON_VQ_MAX
};
@@ -113,6 +118,10 @@ struct virtio_balloon {
/* To register a shrinker to shrink memory upon memory pressure */
struct shrinker shrinker;
+
+ /* Unused page reporting device */
+ struct virtqueue *reporting_vq;
+ struct page_reporting_dev_info ph_dev_info;
};
static struct virtio_device_id id_table[] = {
@@ -152,6 +161,32 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
}
+void virtballoon_unused_page_report(struct page_reporting_dev_info *ph_dev_info,
+ unsigned int nents)
+{
+ struct virtio_balloon *vb =
+ container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
+ struct virtqueue *vq = vb->reporting_vq;
+ unsigned int unused, err;
+
+ /* We should always be able to add these buffers to an empty queue. */
+ err = virtqueue_add_inbuf(vq, ph_dev_info->sg, nents, vb,
+ GFP_NOWAIT | __GFP_NOWARN);
+
+ /*
+ * In the extremely unlikely case that something has changed and we
+ * are able to trigger an error we will simply display a warning
+ * and exit without actually processing the pages.
+ */
+ if (WARN_ON(err))
+ return;
+
+ virtqueue_kick(vq);
+
+ /* When host has read buffer, this completes via balloon_ack */
+ wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
+}
+
static void set_page_pfns(struct virtio_balloon *vb,
__virtio32 pfns[], struct page *page)
{
@@ -476,6 +511,7 @@ static int init_vqs(struct virtio_balloon *vb)
names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
names[VIRTIO_BALLOON_VQ_STATS] = NULL;
names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
+ names[VIRTIO_BALLOON_VQ_REPORTING] = NULL;
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
names[VIRTIO_BALLOON_VQ_STATS] = "stats";
@@ -487,11 +523,19 @@ static int init_vqs(struct virtio_balloon *vb)
callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
}
+ if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
+ names[VIRTIO_BALLOON_VQ_REPORTING] = "reporting_vq";
+ callbacks[VIRTIO_BALLOON_VQ_REPORTING] = balloon_ack;
+ }
+
err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
vqs, callbacks, names, NULL, NULL);
if (err)
return err;
+ if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
+ vb->reporting_vq = vqs[VIRTIO_BALLOON_VQ_REPORTING];
+
vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
@@ -930,12 +974,30 @@ static int virtballoon_probe(struct virtio_device *vdev)
if (err)
goto out_del_balloon_wq;
}
+
+ vb->ph_dev_info.report = virtballoon_unused_page_report;
+ if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
+ unsigned int capacity;
+
+ capacity = min_t(unsigned int,
+ virtqueue_get_vring_size(vb->reporting_vq),
+ VIRTIO_BALLOON_VRING_HINTS_MAX);
+ vb->ph_dev_info.capacity = capacity;
+
+ err = page_reporting_startup(&vb->ph_dev_info);
+ if (err)
+ goto out_unregister_shrinker;
+ }
+
virtio_device_ready(vdev);
if (towards_target(vb))
virtballoon_changed(vdev);
return 0;
+out_unregister_shrinker:
+ if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
+ virtio_balloon_unregister_shrinker(vb);
out_del_balloon_wq:
if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
destroy_workqueue(vb->balloon_wq);
@@ -964,6 +1026,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
{
struct virtio_balloon *vb = vdev->priv;
+ if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
+ page_reporting_shutdown(&vb->ph_dev_info);
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
virtio_balloon_unregister_shrinker(vb);
spin_lock_irq(&vb->stop_update_lock);
@@ -1035,6 +1099,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
VIRTIO_BALLOON_F_FREE_PAGE_HINT,
VIRTIO_BALLOON_F_PAGE_POISON,
+ VIRTIO_BALLOON_F_REPORTING,
};
static struct virtio_driver virtio_balloon_driver = {
diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index a1966cd7b677..19974392d324 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -36,6 +36,7 @@
#define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
#define VIRTIO_BALLOON_F_FREE_PAGE_HINT 3 /* VQ to report free pages */
#define VIRTIO_BALLOON_F_PAGE_POISON 4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_REPORTING 5 /* Page reporting virtqueue */
/* Size of a PFN in the balloon interface. */
#define VIRTIO_BALLOON_PFN_SHIFT 12
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting
From: Alexander Duyck @ 2019-09-07 17:34 UTC (permalink / raw)
To: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox,
Michal Hocko, linux-mm, Andrew Morton, will, linux-arm-kernel,
Oscar Salvador
Cc: Yang Zhang, Pankaj Gupta, Rik van Riel, Konrad Rzeszutek Wilk,
ying.huang, lcapitulino, Wang, Wei W, Andrea Arcangeli,
Nitesh Narayan Lal, Paolo Bonzini, Dan Williams, Fengguang Wu,
Alexander Duyck, Kirill A. Shutemov
In-Reply-To: <20190907172225.10910.34302.stgit@localhost.localdomain>
Sorry about that. Looks like I fat fingered things and copied the
command line into the cover page. I corrected the subject here, and
pulled the command line out of the message below.
- Alex
On Sat, Sep 7, 2019 at 10:25 AM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> This series provides an asynchronous means of reporting to a hypervisor
> that a guest page is no longer in use and can have the data associated
> with it dropped. To do this I have implemented functionality that allows
> for what I am referring to as unused page reporting
>
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported pages in a given free area.
> When the number of free pages exceeds this value plus a high water value,
> currently 32, it will begin performing page reporting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page reporting device and it will perform
> the required action to make the pages "reported", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list, and an additional bit is added if they are not
> merged indicating that they are a reported buddy page instead of a
> standard buddy page. The cycle then repeats with additional non-reported
> pages being pulled until the free areas all consist of reported pages.
>
> I am leaving a number of things hard-coded such as limiting the lowest
> order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
> determine what the limit is on how many pages it wants to allocate to
> process the hints. The upper limit for this is based on the size of the
> queue used to store the scattergather list.
>
> My primary testing has just been to verify the memory is being freed after
> allocation by running memhog 40g on a 40g guest and watching the total
> free memory via /proc/meminfo on the host. With this I have verified most
> of the memory is freed after each iteration. As far as performance I have
> been mainly focusing on the will-it-scale/page_fault1 test running with
> 16 vcpus. I have modified it to use Transparent Huge Pages. With this I
> see almost no difference, -0.08%, with the patches applied and the feature
> disabled. I see a regression of -0.86% with the feature enabled, but the
> madvise disabled in the hypervisor due to a device being assigned. With
> the feature fully enabled I see a regression of -3.27% versus the baseline
> without these patches applied. In my testing I found that most of the
> overhead was due to the page zeroing that comes as a result of the pages
> having to be faulted back into the guest.
>
> One side effect of these patches is that the guest becomes much more
> resilient in terms of NUMA locality. With the pages being freed and then
> reallocated when used it allows for the pages to be much closer to the
> active thread, and as a result there can be situations where this patch
> set will out-perform the stock kernel when the guest memory is not local
> to the guest vCPUs. To avoid that in my testing I set the affinity of all
> the vCPUs and QEMU instance to the same node.
>
> I have not included the QEMU patches with this set as they haven't really
> changed in the last several revisions. If needed they can be located with
> the v8 patchset.
>
> Changes from the RFC:
> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> Moved aeration requested flag out of aerator and into zone->flags.
> Moved boundary out of free_area and into local variables for aeration.
> Moved aeration cycle out of interrupt and into workqueue.
> Left nr_free as total pages instead of splitting it between raw and aerated.
> Combined size and physical address values in virtio ring into one 64b value.
>
> Changes from v1:
> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> Dropped "waste page treatment" in favor of "page hinting"
> Renamed files and functions from "aeration" to "page_hinting"
> Moved from page->lru list to scatterlist
> Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> Virtio now uses scatterlist directly instead of intermediate array
> Moved stats out of free_area, now in separate area and pointed to from zone
> Merged patch 5 into patch 4 to improve review-ability
> Updated various code comments throughout
>
> Changes from v2:
> https://lore.kernel.org/lkml/20190724165158.6685.87228.stgit@localhost.localdomain/
> Dropped "page hinting" in favor of "page reporting"
> Renamed files from "hinting" to "reporting"
> Replaced "Hinted" page type with "Reported" page flag
> Added support for page poisoning while hinting is active
> Add QEMU patch that implements PAGE_POISON feature
>
> Changes from v3:
> https://lore.kernel.org/lkml/20190801222158.22190.96964.stgit@localhost.localdomain/
> Added mutex lock around page reporting startup and shutdown
> Fixed reference to "page aeration" in patch 2
> Split page reporting function bit out into separate QEMU patch
> Limited capacity of scatterlist to vq size - 1 instead of vq size
> Added exception handling for case of virtio descriptor allocation failure
>
> Changes from v4:
> https://lore.kernel.org/lkml/20190807224037.6891.53512.stgit@localhost.localdomain/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle()
> Dropped if/continue for ternary operator in page_reporting_process()
> Added checks for isolate and cma types to for_each_reporting_migratetype_order
> Added virtio-dev, Michal Hocko, and Oscar Salvador to to:/cc:
> Rebased on latest linux-next and QEMU git trees
>
> Changes from v5:
> https://lore.kernel.org/lkml/20190812213158.22097.30576.stgit@localhost.localdomain/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_startup()
> Updated shuffle code to use "shuffle_pick_tail" and updated patch description
> Dropped storage of order and migratettype while page is being reported
> Used get_pfnblock_migratetype to determine migratetype of page
> Renamed put_reported_page to free_reported_page, added order as argument
> Dropped check for CMA type as I believe we should be reporting those
> Added code to allow moving of reported pages into and out of isolation
> Defined page reporting order as minimum of Huge Page size vs MAX_ORDER - 1
> Cleaned up use of static branch usage for page_reporting_notify_enabled
>
> Changes from v6:
> https://lore.kernel.org/lkml/20190821145806.20926.22448.stgit@localhost.localdomain/
> Rebased on linux-next for 20190903
> Added jump label to __page_reporting_request so we release RCU read lock
> Removed "- 1" from capacity limit based on virtio ring
> Added code to verify capacity is non-zero or return error on startup
>
> Changes from v7:
> https://lore.kernel.org/lkml/20190904150920.13848.32271.stgit@localhost.localdomain/
> Updated poison fixes to clear flag if "nosanity" is enabled in kernel config
> Split shuffle per-cpu optimization into separate patch
> Moved check for !phdev->capacity into reporting patch where it belongs
> Added Reviewed-by tags received for v7
>
> Changes from v8:
> https://lore.kernel.org/lkml/20190906145213.32552.30160.stgit@localhost.localdomain/
> Added patch that moves HPAGE_SIZE definition for ARM64 to match other archs
> Switch back to using pageblock_order instead of HUGETLB_ORDER and MAX_ORDER - 1
> Boundary allocation now dynamic to support HUGETLB_PAGE_SIZE_VARIABLE option
> Made use of existing code/functions to reduce size of move_to_boundary function
> Dropped unused zone pointer from add_to/del_from_boundary functions
> Added additional possible mm and arm64 people as reviewers to Cc
> Added Reviewed-by tags received for v8
> Fixed missing parameter in kerneldoc
>
> ---
>
> Alexander Duyck (8):
> mm: Add per-cpu logic to page shuffling
> mm: Adjust shuffle code to allow for future coalescing
> mm: Move set/get_pcppage_migratetype to mmzone.h
> mm: Use zone and order instead of free area in free_list manipulators
> arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
> mm: Introduce Reported pages
> virtio-balloon: Pull page poisoning config out of free page hinting
> virtio-balloon: Add support for providing unused page reports to host
>
>
> arch/arm64/include/asm/page-def.h | 9 +
> arch/arm64/include/asm/pgtable.h | 9 -
> drivers/virtio/Kconfig | 1
> drivers/virtio/virtio_balloon.c | 87 ++++++++-
> include/linux/mmzone.h | 124 ++++++++----
> include/linux/page-flags.h | 11 +
> include/linux/page_reporting.h | 178 +++++++++++++++++
> include/uapi/linux/virtio_balloon.h | 1
> mm/Kconfig | 5
> mm/Makefile | 1
> mm/internal.h | 18 ++
> mm/memory_hotplug.c | 1
> mm/page_alloc.c | 217 +++++++++++++++------
> mm/page_reporting.c | 358 +++++++++++++++++++++++++++++++++++
> mm/shuffle.c | 40 ++--
> mm/shuffle.h | 12 +
> 16 files changed, 931 insertions(+), 141 deletions(-)
> create mode 100644 include/linux/page_reporting.h
> create mode 100644 mm/page_reporting.c
>
> --
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 11/12] open: openat2(2) syscall
From: Andy Lutomirski @ 2019-09-07 17:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=whZx97Nm-gUK0ppofj2RA2LLz2vmaDUTKSSV-+yYB9q_Q@mail.gmail.com>
> On Sep 7, 2019, at 9:58 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Sat, Sep 7, 2019 at 5:40 AM Jeff Layton <jlayton@kernel.org> wrote:
>>
>> After thinking about this a bit, I wonder if we might be better served
>> with a new set of OA2_* flags instead of repurposing the O_* flags?
>
> I'd hate to have yet _another_ set of translation functions, and
> another chance of people just getting it wrong either in user space or
> the kernel.
>
> So no. Let's not make another set of flags that has no sane way to
> have type-safety to avoid more confusion.
>
> The new flags that _only_ work with openat2() might be named with a
> prefix/suffix to mark that, but I'm not sure it's a huge deal.
>
>
I agree with the philosophy, but I think it doesn’t apply in this case. Here are the flags:
O_RDONLY, O_WRONLY, O_RDWR: not even a proper bitmask. The kernel already has the FMODE_ bits to make this make sense. How about we make the openat2 permission bits consistent with the internal representation and let the O_ permission bits remain as an awful translation. The kernel already translates like this, and it already sucks.
O_CREAT, O_TMPFILE, O_NOCTTY, O_TRUNC: not modes on the fd at all. These affect the meaning of open(). Heck, for openat2, NOCTTY should be this default.
O_EXCL: hopelessly overloaded.
O_APPEND, O_DIRECT, O_SYNC, O_DSYNC, O_LARGEFILE, O_NOATIME, O_PATH, O_NONBLOCK: genuine mode bits
O_CLOEXEC: special because it affects the fd, not the struct file.
Linus, you rejected resolveat() because you wanted a *nice* API that people would use and that might even be adopted by other OSes. Let’s please not make openat2() be a giant pile of crap in the name of consistency with open(). open(), frankly, is horrible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ASoC: rockchip: ignore 0Hz sysclk
From: Katsuhiro Suzuki @ 2019-09-07 17:43 UTC (permalink / raw)
To: Mark Brown
Cc: Katsuhiro Suzuki, alsa-devel, Heiko Stuebner, linux-arm-kernel,
linux-kernel
This patch ignores sysclk setting if it is 0Hz.
Some codecs treat 0Hz sysclk as signal of applying no constraints.
This driver does not have such feature but current implementation
outputs 'Failed to set mclk' error message if machine driver sets
0Hz sysclk to this driver.
Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
---
sound/soc/rockchip/rockchip_i2s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 88ebaf6e1880..af2d5a6124c8 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -419,6 +419,9 @@ static int rockchip_i2s_set_sysclk(struct snd_soc_dai *cpu_dai, int clk_id,
struct rk_i2s_dev *i2s = to_info(cpu_dai);
int ret;
+ if (freq == 0)
+ return 0;
+
ret = clk_set_rate(i2s->mclk, freq);
if (ret)
dev_err(i2s->dev, "Fail to set mclk %d\n", ret);
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v12 11/12] open: openat2(2) syscall
From: Linus Torvalds @ 2019-09-07 17:45 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <C81D6D29-F6BF-48E6-A15E-3ABCB2C992E5@amacapital.net>
On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> Linus, you rejected resolveat() because you wanted a *nice* API
No. I rejected resoveat() because it was a completely broken garbage
API that couldn't do even basic stuff right (like O_CREAT).
We have a ton of flag space in the new openat2() model, we might as
well leave the old flags alone that people are (a) used to and (b) we
have code to support _anyway_.
Making up a new flag namespace is only going to cause us - and users -
more work, and more confusion. For no actual advantage. It's not going
to be "cleaner". It's just going to be worse.
Linus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
From: H. Nikolaus Schaller @ 2019-09-07 17:46 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
Changes V2:
* fix ti-cpufreq to properly describe what compatible string is legacy
* add some reviewed-by and acked-by Tony Lindgren <tony@atomide.com>
PATCH V1 2019-09-07 08:56:19:
* fix typo in omap3-ldp.dts
(reported by Tony Lindgren <tony@atomide.com>)
* extend commit message to describe the bit patterns needed
for opp-supported-hw
* add error check to ioremap()
(suggested by Christ van Willegen <cvwillegen@gmail.com>)
* update Documentation/devicetree/bindings/arm/omap/omap.txt
* change bulk update to use "ti,omap3430" and "ti,omap3630"
* update OPP4 of omap3430 to 1275 mV since it was not a valid
voltage for the twl4030 driver (reported by Tony Lindgren
<tony@atomide.com>)
RFC V2 2019-09-04 10:53:43:
* merge separate patch to remove opp-v1 table from n950-n9 into
the general omap3xxx.dtsi patch
(suggested by Viresh Kumar <viresh.kumar@linaro.org>)
* add legacy compatibility to ti,omap3430 and ti,omap3630 for
the ti-cpufreq driver
* make driver and omap3xxx.dtsi patches pass checkpatch
* add bulk patch to explicitly define compatibility to ti,omap3430
and ti,omap36xx in addition to ti,omap3 of all in-tree boards
where it was missing
RFC V1 2019-09-02 12:55:55:
This patch set converts the omap3 opp tables to opp-v2 format
and extends the ti-cpufreq to support omap3.
It adds 720 MHz (omap34xx) and 1 GHz (omap36xx) OPPs but
tells the ti-cpufreq driver to disable them if the speed
binned / 720MHz grade eFuse bits indicate that the chip
is not rated for that speed.
It has been tested (for chip variant detection, not reliability
of the high speed OPPs) on:
* BeagleBoard C2 (omap3530 600MHz)
* BeagleBoard XM B (dm3730 800MHz)
* GTA04A4 (dm3730 800MHz)
* GTA04A5 (dm3730 1GHz)
H. Nikolaus Schaller (4):
cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx
ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430
or ti,omap3630 or ti,am3517
DTS: bindings: omap: update bindings documentation
.../devicetree/bindings/arm/omap/omap.txt | 30 +++---
arch/arm/boot/dts/am3517_mt_ventoux.dts | 2 +-
.../boot/dts/logicpd-som-lv-35xx-devkit.dts | 2 +-
.../boot/dts/logicpd-torpedo-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000.dts | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-ha-lcd.dts | 2 +-
arch/arm/boot/dts/omap3-ha.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
arch/arm/boot/dts/omap3-ldp.dts | 2 +-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 2 +-
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 --
arch/arm/boot/dts/omap3-n950.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-alto35.dts | 2 +-
.../boot/dts/omap3-overo-storm-chestnut43.dts | 2 +-
.../boot/dts/omap3-overo-storm-gallop43.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-palo35.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-palo43.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-summit.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 2 +-
.../boot/dts/omap3-overo-storm-tobiduo.dts | 2 +-
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-sniper.dts | 2 +-
arch/arm/boot/dts/omap3-thunder.dts | 2 +-
arch/arm/boot/dts/omap3-zoom3.dts | 2 +-
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
arch/arm/boot/dts/omap34xx.dtsi | 65 +++++++++++--
arch/arm/boot/dts/omap36xx.dtsi | 53 +++++++++--
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
drivers/cpufreq/ti-cpufreq.c | 91 ++++++++++++++++++-
43 files changed, 245 insertions(+), 77 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx
From: H. Nikolaus Schaller @ 2019-09-07 17:46 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567878413.git.hns@goldelico.com>
In addition, move omap3 from whitelist to blacklist in cpufreq-dt-platdev
in the same patch, because doing either first breaks operation and
may make trouble in bisect.
We also can remove opp-v1 table for omap3-n950-n9 since it is now
automatically detected.
We also fix a wrong OPP4 voltage for omap3430 which must be
0.6V + 54*12.5mV = 1275mV. Otherwise the twl4030 driver will reject
this OPP.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 ---
arch/arm/boot/dts/omap34xx.dtsi | 65 ++++++++++++++++++++++++----
arch/arm/boot/dts/omap36xx.dtsi | 53 +++++++++++++++++++----
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
4 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 5441e9ffdbb4..e98b0c615f19 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -11,13 +11,6 @@
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
- operating-points = <
- /* kHz uV */
- 300000 1012500
- 600000 1200000
- 800000 1325000
- 1000000 1375000
- >;
};
};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index f572a477f74c..91154829f86a 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -16,19 +16,66 @@
/ {
cpus {
cpu: cpu@0 {
- /* OMAP343x/OMAP35xx variants OPP1-5 */
- operating-points = <
- /* kHz uV */
- 125000 975000
- 250000 1075000
- 500000 1200000
- 550000 1270000
- 600000 1350000
- >;
+ /* OMAP343x/OMAP35xx variants OPP1-6 */
+ operating-points-v2 = <&cpu0_opp_table>;
+
clock-latency = <300000>; /* From legacy driver */
};
};
+ /* see Documentation/devicetree/bindings/opp/opp.txt */
+ cpu0_opp_table: opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp1-125000000 {
+ opp-hz = /bits/ 64 <125000000>;
+ /*
+ * we currently only select the max voltage from table
+ * Table 3-3 of the omap3530 Data sheet (SPRS507F).
+ * Format is: <target min max>
+ */
+ opp-microvolt = <975000 975000 975000>;
+ /*
+ * first value is silicon revision bit mask
+ * second one 720MHz Device Identification bit mask
+ */
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp2-250000000 {
+ opp-hz = /bits/ 64 <250000000>;
+ opp-microvolt = <1075000 1075000 1075000>;
+ opp-supported-hw = <0xffffffff 3>;
+ opp-suspend;
+ };
+
+ opp3-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1200000 1200000 1200000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp4-550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ opp-microvolt = <1275000 1275000 1275000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp5-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1350000 1350000 1350000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp6-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1350000 1350000 1350000>;
+ /* only high-speed grade omap3530 devices */
+ opp-supported-hw = <0xffffffff 2>;
+ };
+ };
+
ocp@68000000 {
omap3_pmx_core2: pinmux@480025d8 {
compatible = "ti,omap3-padconf", "pinctrl-single";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 6fb23ada1f64..44f25b0eb45b 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -19,15 +19,52 @@
};
cpus {
- /* OMAP3630/OMAP37xx 'standard device' variants OPP50 to OPP130 */
+ /* OMAP3630/OMAP37xx variants OPP50 to OPP130 and OPP1G */
cpu: cpu@0 {
- operating-points = <
- /* kHz uV */
- 300000 1012500
- 600000 1200000
- 800000 1325000
- >;
- clock-latency = <300000>; /* From legacy driver */
+ operating-points-v2 = <&cpu0_opp_table>;
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+ };
+ };
+
+ /* see Documentation/devicetree/bindings/opp/opp.txt */
+ cpu0_opp_table: opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp50-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ /*
+ * we currently only select the max voltage from table
+ * Table 4-19 of the DM3730 Data sheet (SPRS685B)
+ * Format is: <target min max>
+ */
+ opp-microvolt = <1012500 1012500 1012500>;
+ /*
+ * first value is silicon revision bit mask
+ * second one is "speed binned" bit mask
+ */
+ opp-supported-hw = <0xffffffff 3>;
+ opp-suspend;
+ };
+
+ opp100-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1200000 1200000 1200000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp130-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1325000 1325000 1325000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp1g-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1375000 1375000 1375000>;
+ /* only on am/dm37x with speed-binned bit set */
+ opp-supported-hw = <0xffffffff 2>;
};
};
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 03dc4244ab00..68b7fc4225f8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -86,7 +86,6 @@ static const struct of_device_id whitelist[] __initconst = {
{ .compatible = "st-ericsson,u9540", },
{ .compatible = "ti,omap2", },
- { .compatible = "ti,omap3", },
{ .compatible = "ti,omap4", },
{ .compatible = "ti,omap5", },
@@ -132,6 +131,7 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "ti,am33xx", },
{ .compatible = "ti,am43", },
{ .compatible = "ti,dra7", },
+ { .compatible = "ti,omap3", },
{ }
};
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
From: H. Nikolaus Schaller @ 2019-09-07 17:46 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567878413.git.hns@goldelico.com>
This adds code and tables to read the silicon revision and
eFuse (speed binned / 720 MHz grade) bits for selecting
opp-v2 table entries.
Since these bits are not always part of the syscon register
range (like for am33xx, am43, dra7), we add code to directly
read the register values using ioremap() if syscon access fails.
The format of the opp-supported-hw entries is that it has
two 32 bit bitfields. E.g.:
opp-supported-hw = <0xffffffff 3>
The first value is matched against the bit position of the
silicon revision which is (see TRM)
omap34xx:
BIT(0) ES1.0
BIT(1) ES2.0
BIT(2) ES2.1
BIT(3) ES3.0
BIT(4) ES3.1
BIT(7) ES3.1.2
omap36xx:
BIT(0) ES1.0
BIT(1) ES1.1
BIT(2) ES1.2
The second value is matched against the speed grade eFuse:
BIT(0) no high speed OPP
BIT(1) high speed OPP
This means for the example above that it is always enabled
while e.g.
opp-supported-hw = <0x1 2>
enables the OPP only for ES1.0 BIT(0) and if the high speed
eFuse is set BIT(1).
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
---
drivers/cpufreq/ti-cpufreq.c | 91 +++++++++++++++++++++++++++++++++++-
1 file changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 2ad1ae17932d..f2f58d689320 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -31,6 +31,11 @@
#define DRA7_EFUSE_OD_MPU_OPP BIT(1)
#define DRA7_EFUSE_HIGH_MPU_OPP BIT(2)
+#define OMAP3_CONTROL_DEVICE_STATUS 0x4800244C
+#define OMAP3_CONTROL_IDCODE 0x4830A204
+#define OMAP34xx_ProdID_SKUID 0x4830A20C
+#define OMAP3_SYSCON_BASE (0x48000000 + 0x2000 + 0x270)
+
#define VERSION_COUNT 2
struct ti_cpufreq_data;
@@ -84,6 +89,13 @@ static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data *opp_data,
return calculated_efuse;
}
+static unsigned long omap3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ /* OPP enable bit ("Speed Binned") */
+ return BIT(efuse);
+}
+
static struct ti_cpufreq_soc_data am3x_soc_data = {
.efuse_xlate = amx3_efuse_xlate,
.efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,
@@ -111,6 +123,56 @@ static struct ti_cpufreq_soc_data dra7_soc_data = {
.multi_regulator = true,
};
+/*
+ * OMAP35x TRM (SPRUF98K):
+ * CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ * Control OMAP Status Register 15:0 (Address 0x4800 244C)
+ * to separate between omap3503, omap3515, omap3525, omap3530
+ * and feature presence.
+ * There are encodings for versions limited to 400/266MHz
+ * but we ignore.
+ * Not clear if this also holds for omap34xx.
+ * some eFuse values e.g. CONTROL_FUSE_OPP1_VDD1
+ * are stored in the SYSCON register range
+ * Register 0x4830A20C [ProdID.SKUID] [0:3]
+ * 0x0 for normal 600/430MHz device.
+ * 0x8 for 720/520MHz device.
+ * Not clear what omap34xx value is.
+ */
+
+static struct ti_cpufreq_soc_data omap34xx_soc_data = {
+ .efuse_xlate = omap3_efuse_xlate,
+ .efuse_offset = OMAP34xx_ProdID_SKUID - OMAP3_SYSCON_BASE,
+ .efuse_shift = 3,
+ .efuse_mask = BIT(3),
+ .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+ .multi_regulator = false,
+};
+
+/*
+ * AM/DM37x TRM (SPRUGN4M)
+ * CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ * Control Device Status Register 15:0 (Address 0x4800 244C)
+ * to separate between am3703, am3715, dm3725, dm3730
+ * and feature presence.
+ * Speed Binned = Bit 9
+ * 0 800/600 MHz
+ * 1 1000/800 MHz
+ * some eFuse values e.g. CONTROL_FUSE_OPP 1G_VDD1
+ * are stored in the SYSCON register range.
+ * There is no 0x4830A20C [ProdID.SKUID] register (exists but
+ * seems to always read as 0).
+ */
+
+static struct ti_cpufreq_soc_data omap36xx_soc_data = {
+ .efuse_xlate = omap3_efuse_xlate,
+ .efuse_offset = OMAP3_CONTROL_DEVICE_STATUS - OMAP3_SYSCON_BASE,
+ .efuse_shift = 9,
+ .efuse_mask = BIT(9),
+ .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+ .multi_regulator = false,
+};
+
/**
* ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
* @opp_data: pointer to ti_cpufreq_data context
@@ -127,7 +189,17 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
&efuse);
- if (ret) {
+ if (ret == -EIO) {
+ /* not a syscon register! */
+ void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
+ opp_data->soc_data->efuse_offset, 4);
+
+ if (!regs)
+ return -ENOMEM;
+ efuse = readl(regs);
+ iounmap(regs);
+ }
+ else if (ret) {
dev_err(dev,
"Failed to read the efuse value from syscon: %d\n",
ret);
@@ -158,7 +230,17 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
&revision);
- if (ret) {
+ if (ret == -EIO) {
+ /* not a syscon register! */
+ void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
+ opp_data->soc_data->rev_offset, 4);
+
+ if (!regs)
+ return -ENOMEM;
+ revision = readl(regs);
+ iounmap(regs);
+ }
+ else if (ret) {
dev_err(dev,
"Failed to read the revision number from syscon: %d\n",
ret);
@@ -190,6 +272,11 @@ static const struct of_device_id ti_cpufreq_of_match[] = {
{ .compatible = "ti,am33xx", .data = &am3x_soc_data, },
{ .compatible = "ti,am43", .data = &am4x_soc_data, },
{ .compatible = "ti,dra7", .data = &dra7_soc_data },
+ { .compatible = "ti,omap34xx", .data = &omap34xx_soc_data, },
+ { .compatible = "ti,omap36xx", .data = &omap36xx_soc_data, },
+ /* legacy */
+ { .compatible = "ti,omap3430", .data = &omap34xx_soc_data, },
+ { .compatible = "ti,omap3630", .data = &omap36xx_soc_data, },
{},
};
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] DTS: bindings: omap: update bindings documentation
From: H. Nikolaus Schaller @ 2019-09-07 17:46 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567878413.git.hns@goldelico.com>
* clarify that we now need either "ti,omap3430" or "ti,omap3630" or "ti,am3517" for omap3 chips
* clarify that "ti,omap3" has no default
* clarify that AM33x is not an "ti,omap3"
* clarify that the list of boards is incomplete
* remove some "ti,am33xx", "ti,omap3"
* add some missing "ti,omap4"
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
.../devicetree/bindings/arm/omap/omap.txt | 30 +++++++++++--------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index b301f753ed2c..e77635c5422c 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -43,7 +43,7 @@ SoC Families:
- OMAP2 generic - defaults to OMAP2420
compatible = "ti,omap2"
-- OMAP3 generic - defaults to OMAP3430
+- OMAP3 generic
compatible = "ti,omap3"
- OMAP4 generic - defaults to OMAP4430
compatible = "ti,omap4"
@@ -51,6 +51,8 @@ SoC Families:
compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
+- AM33x generic
+ compatible = "ti,am33xx"
- AM43x generic - defaults to AM4372
compatible = "ti,am43"
@@ -63,12 +65,14 @@ SoCs:
- OMAP3430
compatible = "ti,omap3430", "ti,omap3"
+ legacy: "ti,omap34xx" - please do not use any more
- AM3517
compatible = "ti,am3517", "ti,omap3"
- OMAP3630
- compatible = "ti,omap36xx", "ti,omap3"
-- AM33xx
- compatible = "ti,am33xx", "ti,omap3"
+ compatible = "ti,omap3630", "ti,omap3"
+ legacy: "ti,omap36xx" - please do not use any more
+- AM335x
+ compatible = "ti,am33xx"
- OMAP4430
compatible = "ti,omap4430", "ti,omap4"
@@ -110,19 +114,19 @@ SoCs:
- AM4372
compatible = "ti,am4372", "ti,am43"
-Boards:
+Boards (incomplete list of examples):
- OMAP3 BeagleBoard : Low cost community board
- compatible = "ti,omap3-beagle", "ti,omap3"
+ compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
- compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
+ compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
- OMAP4 SDP : Software Development Board
- compatible = "ti,omap4-sdp", "ti,omap4430"
+ compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4"
- OMAP4 PandaBoard : Low cost community board
- compatible = "ti,omap4-panda", "ti,omap4430"
+ compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4"
- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
@@ -134,16 +138,16 @@ Boards:
compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
- compatible = "ti,omap3-evm", "ti,omap3"
+ compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3"
- AM335X EVM : Software Development Board for AM335x
- compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am335x-evm", "ti,am33xx"
- AM335X Bone : Low cost community board
- compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am335x-bone", "ti,am33xx"
- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
- compatible = "ti,am3359-icev2", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am3359-icev2", "ti,am33xx"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti, omap3430 or ti, omap3630 or ti, am3517
From: H. Nikolaus Schaller @ 2019-09-07 17:46 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567878413.git.hns@goldelico.com>
For the ti-cpufreq driver we need a clear separation between omap34 and omap36 families
since they have different silicon revisions and efuses.
So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while omap34 has no
required entry.
Therefore we can not match omap34 boards properly.
This needs to add ti,omap3430 and ti,omap3630 where it is missing.
We also clean up some instances of missing ti,am3517 so that we can rely on
seeing either one of:
ti,am3517
ti,omap3430
ti,omap3630
in addition to ti,omap3.
We leave ti,omap34xx and ti,omap36xx untouched for compatibility.
The script to do the conversion is:
manually fix am3517_mt_ventoux.dts
find arch/arm/boot/dts -name '*.dts*' -exec fgrep -q '"ti,omap34xx"' {} \; ! -exec fgrep -q '"ti,omap3430"' {} \; -exec sed -i '' 's/"ti,omap34xx"/"ti,omap3430", "ti,omap34xx"/' {} \;
find arch/arm/boot/dts -name '*.dts*' -exec fgrep -q '"ti,omap36xx"' {} \; ! -exec fgrep -q '"ti,omap3630"' {} \; -exec sed -i '' 's/"ti,omap36xx"/"ti,omap3630", "ti,omap36xx"/' {} \;
find arch/arm/boot/dts \( -name 'omap*.dts*' -o -name 'logic*.dts*' \) -exec fgrep -q '"ti,omap3"' {} \; ! -exec fgrep -q '"ti,omap3630"' {} \; ! -exec fgrep -q '"ti,omap36xx"' {} \; ! -exec fgrep -q '"ti,am3517"' {} \; ! -exec fgrep -q '"ti,omap34xx"' {} \; ! -exec fgrep -q '"ti,omap3430"' {} \; -exec sed -i '' 's/"ti,omap3"/"ti,omap3430", "ti,omap3"/' {} \;
So if your out-of-tree omap3 board does not show any OPPs, please check
the compatibility entry and update if needed.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am3517_mt_ventoux.dts | 2 +-
arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000.dts | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-ha-lcd.dts | 2 +-
arch/arm/boot/dts/omap3-ha.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
arch/arm/boot/dts/omap3-ldp.dts | 2 +-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 2 +-
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n950.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-alto35.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-gallop43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-palo35.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-palo43.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-summit.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts | 2 +-
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-sniper.dts | 2 +-
arch/arm/boot/dts/omap3-thunder.dts | 2 +-
arch/arm/boot/dts/omap3-zoom3.dts | 2 +-
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
37 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/am3517_mt_ventoux.dts b/arch/arm/boot/dts/am3517_mt_ventoux.dts
index e507e4ae0d88..e7d7124a34ba 100644
--- a/arch/arm/boot/dts/am3517_mt_ventoux.dts
+++ b/arch/arm/boot/dts/am3517_mt_ventoux.dts
@@ -8,7 +8,7 @@
/ {
model = "TeeJet Mt.Ventoux";
- compatible = "teejet,mt_ventoux", "ti,omap3";
+ compatible = "teejet,mt_ventoux", "ti,am3517", "ti,omap3";
memory@80000000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts b/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
index f7a841a28865..2a0a98fe67f0 100644
--- a/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-som-lv-35xx-devkit.dts
@@ -9,5 +9,5 @@
/ {
model = "LogicPD Zoom OMAP35xx SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3";
+ compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3430", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts b/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts
index 7675bc3fa868..57bae2aa910e 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-35xx-devkit.dts
@@ -9,5 +9,5 @@
/ {
model = "LogicPD Zoom OMAP35xx Torpedo Development Kit";
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3";
+ compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3430", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 1aa99fc1487a..125ed933ca75 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
+ compatible = "ti,omap3-beagle-xm", "ti,omap3630", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index e3df3c166902..4ed3f93f5841 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3 BeagleBoard";
- compatible = "ti,omap3-beagle", "ti,omap3";
+ compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts b/arch/arm/boot/dts/omap3-cm-t3530.dts
index 76e52c78cbb4..32dbaeaed147 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -9,7 +9,7 @@
/ {
model = "CompuLab CM-T3530";
- compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
+ compatible = "compulab,omap3-cm-t3530", "ti,omap3430", "ti,omap34xx", "ti,omap3";
/* Regulator to trigger the reset signal of the Wifi module */
mmc2_sdio_reset: regulator-mmc2-sdio-reset {
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts b/arch/arm/boot/dts/omap3-cm-t3730.dts
index 6e944dfa0f3d..683819bf0915 100644
--- a/arch/arm/boot/dts/omap3-cm-t3730.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -9,7 +9,7 @@
/ {
model = "CompuLab CM-T3730";
- compatible = "compulab,omap3-cm-t3730", "ti,omap36xx", "ti,omap3";
+ compatible = "compulab,omap3-cm-t3730", "ti,omap3630", "ti,omap36xx", "ti,omap3";
wl12xx_vmmc2: wl12xx_vmmc2 {
compatible = "regulator-fixed";
diff --git a/arch/arm/boot/dts/omap3-devkit8000-lcd43.dts b/arch/arm/boot/dts/omap3-devkit8000-lcd43.dts
index a80fc60bc773..afed85078ad8 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-lcd43.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000-lcd43.dts
@@ -11,7 +11,7 @@
#include "omap3-devkit8000-lcd-common.dtsi"
/ {
model = "TimLL OMAP3 Devkit8000 with 4.3'' LCD panel";
- compatible = "timll,omap3-devkit8000", "ti,omap3";
+ compatible = "timll,omap3-devkit8000", "ti,omap3430", "ti,omap3";
lcd0: display {
panel-timing {
diff --git a/arch/arm/boot/dts/omap3-devkit8000-lcd70.dts b/arch/arm/boot/dts/omap3-devkit8000-lcd70.dts
index 0753776071f8..07c51a105c0d 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-lcd70.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000-lcd70.dts
@@ -11,7 +11,7 @@
#include "omap3-devkit8000-lcd-common.dtsi"
/ {
model = "TimLL OMAP3 Devkit8000 with 7.0'' LCD panel";
- compatible = "timll,omap3-devkit8000", "ti,omap3";
+ compatible = "timll,omap3-devkit8000", "ti,omap3430", "ti,omap3";
lcd0: display {
panel-timing {
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
index faafc48d8f61..162d0726b008 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -7,7 +7,7 @@
#include "omap3-devkit8000-common.dtsi"
/ {
model = "TimLL OMAP3 Devkit8000";
- compatible = "timll,omap3-devkit8000", "ti,omap3";
+ compatible = "timll,omap3-devkit8000", "ti,omap3430", "ti,omap3";
aliases {
display1 = &dvi0;
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b295f6fad2a5..25b6ed9203e1 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -11,7 +11,7 @@
/ {
model = "OMAP3 GTA04";
- compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
+ compatible = "ti,omap3-gta04", "ti,omap3630", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3-ha-lcd.dts b/arch/arm/boot/dts/omap3-ha-lcd.dts
index badb9b3c8897..c9ecbc45c8e2 100644
--- a/arch/arm/boot/dts/omap3-ha-lcd.dts
+++ b/arch/arm/boot/dts/omap3-ha-lcd.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3 HEAD acoustics LCD-baseboard with TAO3530 SOM";
- compatible = "headacoustics,omap3-ha-lcd", "technexion,omap3-tao3530", "ti,omap34xx", "ti,omap3";
+ compatible = "headacoustics,omap3-ha-lcd", "technexion,omap3-tao3530", "ti,omap3430", "ti,omap34xx", "ti,omap3";
};
&omap3_pmx_core {
diff --git a/arch/arm/boot/dts/omap3-ha.dts b/arch/arm/boot/dts/omap3-ha.dts
index a5365252bfbe..35c4e15abeb7 100644
--- a/arch/arm/boot/dts/omap3-ha.dts
+++ b/arch/arm/boot/dts/omap3-ha.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3 HEAD acoustics baseboard with TAO3530 SOM";
- compatible = "headacoustics,omap3-ha", "technexion,omap3-tao3530", "ti,omap34xx", "ti,omap3";
+ compatible = "headacoustics,omap3-ha", "technexion,omap3-tao3530", "ti,omap3430", "ti,omap34xx", "ti,omap3";
};
&omap3_pmx_core {
diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index 03dcd05fb8a0..d134ce1cffc0 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -10,7 +10,7 @@
/ {
model = "IGEPv2 Rev. F (TI OMAP AM/DM37x)";
- compatible = "isee,omap3-igep0020-rev-f", "ti,omap36xx", "ti,omap3";
+ compatible = "isee,omap3-igep0020-rev-f", "ti,omap3630", "ti,omap36xx", "ti,omap3";
/* Regulator to trigger the WL_EN signal of the Wifi module */
lbep5clwmc_wlen: regulator-lbep5clwmc-wlen {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index 6d0519e3dfd0..e341535a7162 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -10,7 +10,7 @@
/ {
model = "IGEPv2 Rev. C (TI OMAP AM/DM37x)";
- compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
+ compatible = "isee,omap3-igep0020", "ti,omap3630", "ti,omap36xx", "ti,omap3";
vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 060acd1e803a..9ca1d0f61964 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -10,7 +10,7 @@
/ {
model = "IGEP COM MODULE Rev. G (TI OMAP AM/DM37x)";
- compatible = "isee,omap3-igep0030-rev-g", "ti,omap36xx", "ti,omap3";
+ compatible = "isee,omap3-igep0030-rev-g", "ti,omap3630", "ti,omap36xx", "ti,omap3";
/* Regulator to trigger the WL_EN signal of the Wifi module */
lbep5clwmc_wlen: regulator-lbep5clwmc-wlen {
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 25170bd3c573..32f31035daa2 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -10,7 +10,7 @@
/ {
model = "IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)";
- compatible = "isee,omap3-igep0030", "ti,omap36xx", "ti,omap3";
+ compatible = "isee,omap3-igep0030", "ti,omap3630", "ti,omap36xx", "ti,omap3";
vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 9a5fde2d9bce..ec9ba04ef43b 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -10,7 +10,7 @@
/ {
model = "TI OMAP3430 LDP (Zoom1 Labrador)";
- compatible = "ti,omap3-ldp", "ti,omap3";
+ compatible = "ti,omap3-ldp", "ti,omap3430", "ti,omap3";
memory@80000000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index c22833d4e568..73d477898ec2 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -7,7 +7,7 @@
/ {
model = "INCOstartec LILLY-A83X module (DM3730)";
- compatible = "incostartec,omap3-lilly-a83x", "ti,omap36xx", "ti,omap3";
+ compatible = "incostartec,omap3-lilly-a83x", "ti,omap3630", "ti,omap36xx", "ti,omap3";
chosen {
bootargs = "console=ttyO0,115200n8 vt.global_cursor_default=0 consoleblank=0";
diff --git a/arch/arm/boot/dts/omap3-lilly-dbb056.dts b/arch/arm/boot/dts/omap3-lilly-dbb056.dts
index fec335400074..ecb4ef738e07 100644
--- a/arch/arm/boot/dts/omap3-lilly-dbb056.dts
+++ b/arch/arm/boot/dts/omap3-lilly-dbb056.dts
@@ -8,7 +8,7 @@
/ {
model = "INCOstartec LILLY-DBB056 (DM3730)";
- compatible = "incostartec,omap3-lilly-dbb056", "incostartec,omap3-lilly-a83x", "ti,omap36xx", "ti,omap3";
+ compatible = "incostartec,omap3-lilly-dbb056", "incostartec,omap3-lilly-a83x", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&twl {
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 74c0ff2350d3..2495a696cec6 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -12,7 +12,7 @@
/ {
model = "Nokia N9";
- compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
+ compatible = "nokia,omap3-n9", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&i2c2 {
diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 9886bf8b90ab..31d47a1fad84 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -12,7 +12,7 @@
/ {
model = "Nokia N950";
- compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
+ compatible = "nokia,omap3-n950", "ti,omap3630", "ti,omap36xx", "ti,omap3";
keys {
compatible = "gpio-keys";
diff --git a/arch/arm/boot/dts/omap3-overo-storm-alto35.dts b/arch/arm/boot/dts/omap3-overo-storm-alto35.dts
index 18338576c41d..7f04dfad8203 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-alto35.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-alto35.dts
@@ -14,5 +14,5 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Alto35";
- compatible = "gumstix,omap3-overo-alto35", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-alto35", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts b/arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts
index f204c8af8281..bc5a04e03336 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts
@@ -14,7 +14,7 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Chestnut43";
- compatible = "gumstix,omap3-overo-chestnut43", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-chestnut43", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts b/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
index c633f7cee68e..065c31cbf0e2 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
@@ -14,7 +14,7 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Gallop43";
- compatible = "gumstix,omap3-overo-gallop43", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-gallop43", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-overo-storm-palo35.dts b/arch/arm/boot/dts/omap3-overo-storm-palo35.dts
index fb88ebc9858c..e38c1c51392c 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-palo35.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-palo35.dts
@@ -14,7 +14,7 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Palo35";
- compatible = "gumstix,omap3-overo-palo35", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-palo35", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-overo-storm-palo43.dts b/arch/arm/boot/dts/omap3-overo-storm-palo43.dts
index 76cca00d97b6..e6dc23159c4d 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-palo43.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-palo43.dts
@@ -14,7 +14,7 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Palo43";
- compatible = "gumstix,omap3-overo-palo43", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-palo43", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-overo-storm-summit.dts b/arch/arm/boot/dts/omap3-overo-storm-summit.dts
index cc081a9e4c1e..587c08ce282d 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-summit.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-summit.dts
@@ -14,7 +14,7 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Summit";
- compatible = "gumstix,omap3-overo-summit", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-summit", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
index 1de41c0826e0..f57de6010994 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
@@ -14,6 +14,6 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Tobi";
- compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts b/arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts
index 9ed13118ed8e..281af6c113be 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts
@@ -14,5 +14,5 @@
/ {
model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on TobiDuo";
- compatible = "gumstix,omap3-overo-tobiduo", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
+ compatible = "gumstix,omap3-overo-tobiduo", "gumstix,omap3-overo", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
index 81b957f33c9f..ea509956d7ac 100644
--- a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
@@ -16,7 +16,7 @@
/ {
model = "Pandora Handheld Console 1GHz";
- compatible = "openpandora,omap3-pandora-1ghz", "ti,omap36xx", "ti,omap3";
+ compatible = "openpandora,omap3-pandora-1ghz", "ti,omap3630", "ti,omap36xx", "ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-sbc-t3530.dts b/arch/arm/boot/dts/omap3-sbc-t3530.dts
index ae96002abb3b..24bf3fd86641 100644
--- a/arch/arm/boot/dts/omap3-sbc-t3530.dts
+++ b/arch/arm/boot/dts/omap3-sbc-t3530.dts
@@ -8,7 +8,7 @@
/ {
model = "CompuLab SBC-T3530 with CM-T3530";
- compatible = "compulab,omap3-sbc-t3530", "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
+ compatible = "compulab,omap3-sbc-t3530", "compulab,omap3-cm-t3530", "ti,omap3430", "ti,omap34xx", "ti,omap3";
aliases {
display0 = &dvi0;
diff --git a/arch/arm/boot/dts/omap3-sbc-t3730.dts b/arch/arm/boot/dts/omap3-sbc-t3730.dts
index 7de6df16fc17..eb3893b9535e 100644
--- a/arch/arm/boot/dts/omap3-sbc-t3730.dts
+++ b/arch/arm/boot/dts/omap3-sbc-t3730.dts
@@ -8,7 +8,7 @@
/ {
model = "CompuLab SBC-T3730 with CM-T3730";
- compatible = "compulab,omap3-sbc-t3730", "compulab,omap3-cm-t3730", "ti,omap36xx", "ti,omap3";
+ compatible = "compulab,omap3-sbc-t3730", "compulab,omap3-cm-t3730", "ti,omap3630", "ti,omap36xx", "ti,omap3";
aliases {
display0 = &dvi0;
diff --git a/arch/arm/boot/dts/omap3-sniper.dts b/arch/arm/boot/dts/omap3-sniper.dts
index 40a87330e8c3..b6879cdc5c13 100644
--- a/arch/arm/boot/dts/omap3-sniper.dts
+++ b/arch/arm/boot/dts/omap3-sniper.dts
@@ -9,7 +9,7 @@
/ {
model = "LG Optimus Black";
- compatible = "lg,omap3-sniper", "ti,omap36xx", "ti,omap3";
+ compatible = "lg,omap3-sniper", "ti,omap3630", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3-thunder.dts b/arch/arm/boot/dts/omap3-thunder.dts
index 6276e7079b36..64221e3b3477 100644
--- a/arch/arm/boot/dts/omap3-thunder.dts
+++ b/arch/arm/boot/dts/omap3-thunder.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3 Thunder baseboard with TAO3530 SOM";
- compatible = "technexion,omap3-thunder", "technexion,omap3-tao3530", "ti,omap34xx", "ti,omap3";
+ compatible = "technexion,omap3-thunder", "technexion,omap3-tao3530", "ti,omap3430", "ti,omap34xx", "ti,omap3";
};
&omap3_pmx_core {
diff --git a/arch/arm/boot/dts/omap3-zoom3.dts b/arch/arm/boot/dts/omap3-zoom3.dts
index db3a2fe84e99..d240e39f2151 100644
--- a/arch/arm/boot/dts/omap3-zoom3.dts
+++ b/arch/arm/boot/dts/omap3-zoom3.dts
@@ -9,7 +9,7 @@
/ {
model = "TI Zoom3";
- compatible = "ti,omap3-zoom3", "ti,omap36xx", "ti,omap3";
+ compatible = "ti,omap3-zoom3", "ti,omap3630", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index 0abd61108a53..7bfde8aac7ae 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -8,7 +8,7 @@
/ {
model = "TI OMAP3430 SDP";
- compatible = "ti,omap3430-sdp", "ti,omap3";
+ compatible = "ti,omap3430-sdp", "ti,omap3430", "ti,omap3";
memory@80000000 {
device_type = "memory";
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: dts: rockchip: add analog audio nodes on rk3399-rockpro64
From: Katsuhiro Suzuki @ 2019-09-07 17:48 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Katsuhiro Suzuki, linux-rockchip, linux-kernel, linux-arm-kernel
This patch adds audio codec (Everest ES8316) and I2S audio nodes for
RK3399 RockPro64.
Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
---
.../boot/dts/rockchip/rk3399-rockpro64.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 0401d4ec1f45..8b1e6382b140 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -81,6 +81,12 @@
reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
};
+ sound {
+ compatible = "audio-graph-card";
+ label = "rockchip,rk3399";
+ dais = <&i2s1_p0>;
+ };
+
vcc12v_dcin: vcc12v-dcin {
compatible = "regulator-fixed";
regulator-name = "vcc12v_dcin";
@@ -470,6 +476,20 @@
i2c-scl-rising-time-ns = <300>;
i2c-scl-falling-time-ns = <15>;
status = "okay";
+
+ es8316: codec@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = <&cru SCLK_I2S_8CH_OUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ es8316_p0_0: endpoint {
+ remote-endpoint = <&i2s1_p0_0>;
+ };
+ };
+ };
};
&i2c3 {
@@ -505,6 +525,14 @@
rockchip,playback-channels = <2>;
rockchip,capture-channels = <2>;
status = "okay";
+
+ i2s1_p0: port {
+ i2s1_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <&es8316_p0_0>;
+ };
+ };
};
&i2s2 {
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] iommu/arm-smmu: fix "hang" when games exit
From: Rob Clark @ 2019-09-07 17:50 UTC (permalink / raw)
To: iommu
Cc: Rob Clark, Will Deacon, linux-arm-msm, Joerg Roedel, Robin Murphy,
open list, freedreno, moderated list:ARM SMMU DRIVERS
From: Rob Clark <robdclark@chromium.org>
When games, browser, or anything using a lot of GPU buffers exits, there
can be many hundreds or thousands of buffers to unmap and free. If the
GPU is otherwise suspended, this can cause arm-smmu to resume/suspend
for each buffer, resulting 5-10 seconds worth of reprogramming the
context bank (arm_smmu_write_context_bank()/arm_smmu_write_s2cr()/etc).
To the user it would appear that the system is locked up.
A simple solution is to use pm_runtime_put_autosuspend() instead, so we
don't immediately suspend the SMMU device.
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
Note: I've tied the autosuspend enable/delay to the consumer device,
based on the reasoning that if the consumer device benefits from using
an autosuspend delay, then it's corresponding SMMU probably does too.
Maybe that is overkill and we should just unconditionally enable
autosuspend.
drivers/iommu/arm-smmu.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c2733b447d9c..73a0dd53c8a3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -289,7 +289,7 @@ static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
{
if (pm_runtime_enabled(smmu->dev))
- pm_runtime_put(smmu->dev);
+ pm_runtime_put_autosuspend(smmu->dev);
}
static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
@@ -1445,6 +1445,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
/* Looks ok, so add the device to the domain */
ret = arm_smmu_domain_add_master(smmu_domain, fwspec);
+#ifdef CONFIG_PM
+ /* TODO maybe device_link_add() should do this for us? */
+ if (dev->power.use_autosuspend) {
+ pm_runtime_set_autosuspend_delay(smmu->dev,
+ dev->power.autosuspend_delay);
+ pm_runtime_use_autosuspend(smmu->dev);
+ }
+#endif
+
rpm_put:
arm_smmu_rpm_put(smmu);
return ret;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/9] crypto: Add allwinner subdirectory
From: Corentin Labbe @ 2019-09-07 17:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190907035453.urfqmdg3kg4kbtgc@flea>
On Sat, Sep 07, 2019 at 06:54:53AM +0300, Maxime Ripard wrote:
> On Fri, Sep 06, 2019 at 08:45:43PM +0200, Corentin Labbe wrote:
> > Since a second Allwinner crypto driver will be added, it is better to
> > create a dedicated subdirectory.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > MAINTAINERS | 6 ++++++
> > drivers/crypto/Kconfig | 2 ++
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/allwinner/Kconfig | 6 ++++++
>
> I guess it would make sense to move the sun4i driver there too?
>
Yes it is planned.
I will add this move patch in the next iteration.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/9] ARM: dts: sun8i: r40: add crypto engine node
From: Corentin Labbe @ 2019-09-07 17:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190907040217.kzvq7gfxz67pluhz@flea>
On Sat, Sep 07, 2019 at 07:02:17AM +0300, Maxime Ripard wrote:
> On Fri, Sep 06, 2019 at 08:45:46PM +0200, Corentin Labbe wrote:
> > The Crypto Engine is a hardware cryptographic offloader that supports
> > many algorithms.
> > It could be found on most Allwinner SoCs.
> >
> > This patch enables the Crypto Engine on the Allwinner R40 SoC Device-tree.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-r40.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
> > index bde068111b85..7eb649cea163 100644
> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > @@ -266,6 +266,17 @@
> > #phy-cells = <1>;
> > };
> >
> > + crypto: crypto-engine@1c15000 {
> > + compatible = "allwinner,sun8i-r40-crypto";
> > + reg = <0x01c15000 0x1000>;
> > + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_CE>;
> > + reset-names = "ahb";
> > + status = "okay";
>
> The driver will probe if status is not declared, so if you want it
> always enabled you should simply remove status
>
Fixed, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] ARM64: dts: allwinner: sun50i: Add Crypto Engine node on A64
From: Corentin Labbe @ 2019-09-07 17:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190907040254.5ecohywqbekokwfx@flea>
On Sat, Sep 07, 2019 at 07:02:54AM +0300, Maxime Ripard wrote:
> On Fri, Sep 06, 2019 at 08:45:48PM +0200, Corentin Labbe wrote:
> > The Crypto Engine is a hardware cryptographic accelerator that supports
> > many algorithms.
> > It could be found on most Allwinner SoCs.
> >
> > This patch enables the Crypto Engine on the Allwinner A64 SoC Device-tree.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 69128a6dfc46..c9e30d462ab1 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -487,6 +487,17 @@
> > reg = <0x1c14000 0x400>;
> > };
> >
> > + crypto: crypto@1c15000 {
> > + compatible = "allwinner,sun50i-a64-crypto";
> > + reg = <0x01c15000 0x1000>;
> > + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "ce_ns";
>
> You didn't document that property
>
It is unnecessary, I forgot to remove it.
Fixed, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 9/9] sunxi_defconfig: add new crypto options
From: Corentin Labbe @ 2019-09-07 17:55 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190907040353.hrz7gmqgzpfpo4xj@flea>
On Sat, Sep 07, 2019 at 07:03:53AM +0300, Maxime Ripard wrote:
> On Fri, Sep 06, 2019 at 08:45:51PM +0200, Corentin Labbe wrote:
> > This patch adds the new allwinner crypto configs to sunxi_defconfig
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/configs/sunxi_defconfig | 2 ++
> > 1 file changed, 2 insertions(+)
>
> Can you also enable it in arm64's defconfig as a module?
>
Will do.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 11/12] open: openat2(2) syscall
From: Andy Lutomirski @ 2019-09-07 18:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=whe90Ec_RRrMRLE0=bJOHNS9YmVwcytVxmrfK3oCuZF6A@mail.gmail.com>
> On Sep 7, 2019, at 10:45 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> Linus, you rejected resolveat() because you wanted a *nice* API
>
> No. I rejected resoveat() because it was a completely broken garbage
> API that couldn't do even basic stuff right (like O_CREAT).
>
> We have a ton of flag space in the new openat2() model, we might as
> well leave the old flags alone that people are (a) used to and (b) we
> have code to support _anyway_.
>
> Making up a new flag namespace is only going to cause us - and users -
> more work, and more confusion. For no actual advantage. It's not going
> to be "cleaner". It's just going to be worse.
>
>
If we keep all the flag bits in the same mask with the same values, then we’re stuck with O_RDONLY=0 and everything that implies. We’ll have UPGRADE_READ that works differently from the missing plain-old-READ bit, and we can’t express execute-only-no-read-or-write. This sucks.
Can we at least split the permission bits into their own mask and make bits 0 and 1 illegal in the main set of flags in openat2?
There’s another thread going on right now about adding a bit along the lines of “MAYEXEC”, and one of the conclusions was that it should wait for openat2 so that it can have same semantics. If we’re stuck with O_RDONLY and friends, then MAYEXEC is doomed to being at least a bit nonsensical.
As an analogy, AMD64 introduced bigger PTEs but kept the same nonsense encoding of read and write permission. And then we got NX, and now we’re getting little holes in the encoding stolen by CET to mean new silly things. I don’t know if you’ve been following the various rounds of patches, but it is truly horrible. The mapping from meaning to the actual bits is *shit*, and AMD64 should have made a clean break instead.
open()’s permission bits are basically the same situation. And the kernel *already* has a non-type-safe translation layer. Please, please let openat2() at least get rid of the turd in open()’s bits 0 and 1.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/9] crypto: Add Allwinner sun8i-ce Crypto Engine
From: Corentin Labbe @ 2019-09-07 19:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190907081951.v2huvhm44jfprfop@flea>
On Sat, Sep 07, 2019 at 11:19:51AM +0300, Maxime Ripard wrote:
> Hi,
>
> I can't really comment on the crypto side, so my review is going to be
> pretty boring.
>
> On Fri, Sep 06, 2019 at 08:45:44PM +0200, Corentin Labbe wrote:
> > +static const struct ce_variant ce_h3_variant = {
> > + .alg_cipher = { CE_ID_NOTSUPP, CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
> > + CE_ID_NOTSUPP,
> > + },
>
> As far as I can see, it's always the same value, so I'm not sure why
> it's a parameter.
>
No it is not the same value.
If by same value you mean "the list is the same accross variant", it will be different when I will add CTS/CTR/XTS.
Note that .alg_cipher was already different on h6, since I forgot to remove the RAES.
So it will be the same on PATChv2, but again il will be different after.
> > + .op_mode = { CE_ID_NOTSUPP, CE_OP_ECB, CE_OP_CBC
> > + },
>
> Ditto
>
> > + .intreg = CE_ISR,
>
> Ditto
>
> > + .maxflow = 4,
>
> Ditto
>
Both .intreg and .maxflow are remains of sun8i-ss support.
I will remove them.
> > + .ce_clks = {
> > + { "ahb", 200000000 },
>
> This is the default IIRC, and the clock driver will ignore any clock
> rate change on it anyway, so the clock rate is pretty much useless
> there.
>
> > + { "mod", 48000000 },
>
> 48MHz seems pretty slow, especially compared to the other rates you
> have listed there. Is that on purpose?
On H3, the value used on others SoC bring to random fail.
I will add a comment.
>
> Also, I'm not sure what is the point of having the clocks names be
> parameters there as well. It's constant across all the compatibles,
> the only thing that isn't is the number of clocks and the module clock
> rate. It's what you should have in there.
>
Since the datasheet give some max frequency, I think I will add a max_freq and add a check to verify if the clock is in the right range
> > + }
> > +};
> > +
> > +static const struct ce_variant ce_h5_variant = {
> > + .alg_cipher = { CE_ID_NOTSUPP, CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
> > + CE_ID_NOTSUPP,
> > + },
> > + .op_mode = { CE_ID_NOTSUPP, CE_OP_ECB, CE_OP_CBC
> > + },
> > + .intreg = CE_ISR,
> > + .maxflow = 4,
> > + .ce_clks = {
> > + { "ahb", 200000000 },
> > + { "mod", 300000000 },
> > + }
> > +};
> > +
> > +static const struct ce_variant ce_h6_variant = {
> > + .alg_cipher = { CE_ID_NOTSUPP, CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
> > + CE_ALG_RAES,
> > + },
> > + .op_mode = { CE_ID_NOTSUPP, CE_OP_ECB, CE_OP_CBC
> > + },
> > + .model = CE_v2,
>
> Can't that be derived from the version register and / or the
> compatible? This seems to be redundant with each.
>
I could use the compatible, but I want to avoid a string comparison on each request.
> > + .intreg = CE_ISR,
> > + .maxflow = 4,
> > + .ce_clks = {
> > + { "ahb", 200000000 },
> > + { "mod", 300000000 },
> > + { "mbus", 400000000 },
>
> That rate is going to be ignored as well.
>
> > + }
> > +};
> > +
> > +static const struct ce_variant ce_a64_variant = {
> > + .alg_cipher = { CE_ID_NOTSUPP, CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
> > + CE_ID_NOTSUPP,
> > + },
> > + .op_mode = { CE_ID_NOTSUPP, CE_OP_ECB, CE_OP_CBC
> > + },
> > + .intreg = CE_ISR,
> > + .maxflow = 4,
> > + .ce_clks = {
> > + { "ahb", 200000000 },
> > + { "mod", 300000000 },
> > + }
> > +};
>
> You should order your variants by alphabetical order.
>
Will do.
> > +static const struct ce_variant ce_r40_variant = {
> > + .alg_cipher = { CE_ID_NOTSUPP, CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
> > + CE_ID_NOTSUPP,
> > + },
> > + .op_mode = { CE_ID_NOTSUPP, CE_OP_ECB, CE_OP_CBC
> > + },
> > + .intreg = CE_ISR,
> > + .maxflow = 4,
> > + .ce_clks = {
> > + { "ahb", 200000000 },
> > + { "mod", 300000000 },
> > + }
> > +};
> > +
>
> ...
>
> > +int sun8i_ce_get_engine_number(struct sun8i_ce_dev *ce)
> > +{
> > + return atomic_inc_return(&ce->flow) % ce->variant->maxflow;
> > +}
>
> I'm not sure what this is supposed to be doing, but that mod there
> seems pretty dangerous.
>
> ...
>
This mod do a round robin on each channel.
I dont see why it is dangerous.
> > +static int sun8i_ce_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + u32 v;
> > + int err, i, ce_method, id, irq;
> > + unsigned long cr;
> > + struct sun8i_ce_dev *ce;
> > +
> > + if (!pdev->dev.of_node)
> > + return -ENODEV;
>
> This is pretty much guaranteed already
>
Ok, removed
> > + ce = devm_kzalloc(&pdev->dev, sizeof(*ce), GFP_KERNEL);
> > + if (!ce)
> > + return -ENOMEM;
> > +
> > + ce->variant = of_device_get_match_data(&pdev->dev);
> > + if (!ce->variant) {
> > + dev_err(&pdev->dev, "Missing Crypto Engine variant\n");
> > + return -EINVAL;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + ce->base = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(ce->base)) {
> > + err = PTR_ERR(ce->base);
> > + dev_err(&pdev->dev, "Cannot request MMIO err=%d\n", err);
> > + return err;
>
> ioremap_resource already prints an error message on failure, so this
> is redundant.
>
Will remove.
> > + }
> > +
> > + for (i = 0; i < CE_MAX_CLOCKS; i++) {
> > + if (!ce->variant->ce_clks[i].name)
> > + continue;
> > + dev_info(&pdev->dev, "Get %s clock\n", ce->variant->ce_clks[i].name);
>
> There's no reason to print this at the info level
>
Will remove.
> > + ce->ceclks[i] = devm_clk_get(&pdev->dev, ce->variant->ce_clks[i].name);
> > + if (IS_ERR(ce->ceclks[i])) {
> > + err = PTR_ERR(ce->ceclks[i]);
> > + dev_err(&pdev->dev, "Cannot get %s CE clock err=%d\n",
> > + ce->variant->ce_clks[i].name, err);
> > + }
> > + cr = clk_get_rate(ce->ceclks[i]);
>
> So on error you'd call clk_get_rate on the clock still? That seems
> pretty fragile, you should return there, it's a hard error.
>
I will add the missing "return err"
> > + if (ce->variant->ce_clks[i].freq) {
> > + dev_info(&pdev->dev, "Set %s clock to %lu (%lu Mhz) from %lu (%lu Mhz)\n",
> > + ce->variant->ce_clks[i].name,
> > + ce->variant->ce_clks[i].freq,
> > + ce->variant->ce_clks[i].freq / 1000000,
> > + cr,
> > + cr / 1000000);
>
> Same remark about that message than the previous one.
>
> > + err = clk_set_rate(ce->ceclks[i], ce->variant->ce_clks[i].freq);
> > + if (err)
> > + dev_err(&pdev->dev, "Fail to set %s clk speed to %lu\n",
> > + ce->variant->ce_clks[i].name,
> > + ce->variant->ce_clks[i].freq);
> > + } else {
> > + dev_info(&pdev->dev, "%s run at %lu\n",
> > + ce->variant->ce_clks[i].name, cr);
>
> Ditto.
>
> > + }
> > + err = clk_prepare_enable(ce->ceclks[i]);
>
> Do you really need this right now though?
>
Not sure to understand, why I shouldnt do it now ?
Does it is related to your pm_runtime remark below ?
My feeling was to submit the driver without PM and convert it after.
> > + if (err) {
> > + dev_err(&pdev->dev, "Cannot prepare_enable %s\n",
> > + ce->variant->ce_clks[i].name);
> > + return err;
> > + }
> > + }
> > +
> > + /* Get Non Secure IRQ */
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(ce->dev, "Cannot get NS IRQ\n");
> > + return irq;
> > + }
> > +
> > + err = devm_request_irq(&pdev->dev, irq, ce_irq_handler, 0,
> > + "sun8i-ce-ns", ce);
> > + if (err < 0) {
> > + dev_err(ce->dev, "Cannot request NS IRQ\n");
> > + return err;
> > + }
> > +
> > + ce->reset = devm_reset_control_get_optional(&pdev->dev, "ahb");
> > + if (IS_ERR(ce->reset)) {
> > + if (PTR_ERR(ce->reset) == -EPROBE_DEFER)
> > + return PTR_ERR(ce->reset);
> > + dev_info(&pdev->dev, "No reset control found\n");
>
> It's not optional though.
>
I dont understand why.
> > + ce->reset = NULL;
> > + }
> > +
> > + err = reset_control_deassert(ce->reset);
> > + if (err) {
> > + dev_err(&pdev->dev, "Cannot deassert reset control\n");
> > + goto error_clk;
> > + }
>
> Again, you don't really need this at this moment. Using runtime_pm
> would make more sense.
>
> > + v = readl(ce->base + CE_CTR);
> > + v >>= 16;
> > + v &= 0x07;
>
> This should be in a define
>
Will fix.
> > + dev_info(&pdev->dev, "CE_NS Die ID %x\n", v);
>
> And if that really makes sense to print it, the error message should
> be made less cryptic.
>
Will fix.
> > +
> > + ce->dev = &pdev->dev;
> > + platform_set_drvdata(pdev, ce);
> > +
> > + mutex_init(&ce->mlock);
> > +
> > + ce->chanlist = devm_kcalloc(ce->dev, ce->variant->maxflow,
> > + sizeof(struct sun8i_ce_flow), GFP_KERNEL);
> > + if (!ce->chanlist) {
> > + err = -ENOMEM;
> > + goto error_flow;
> > + }
> > +
> > + for (i = 0; i < ce->variant->maxflow; i++) {
> > + init_completion(&ce->chanlist[i].complete);
> > + mutex_init(&ce->chanlist[i].lock);
> > +
> > + ce->chanlist[i].engine = crypto_engine_alloc_init(ce->dev, true);
> > + if (!ce->chanlist[i].engine) {
> > + dev_err(ce->dev, "Cannot allocate engine\n");
> > + i--;
> > + goto error_engine;
> > + }
> > + err = crypto_engine_start(ce->chanlist[i].engine);
> > + if (err) {
> > + dev_err(ce->dev, "Cannot start engine\n");
> > + goto error_engine;
> > + }
> > + ce->chanlist[i].tl = dma_alloc_coherent(ce->dev,
> > + sizeof(struct ce_task),
> > + &ce->chanlist[i].t_phy,
> > + GFP_KERNEL);
> > + if (!ce->chanlist[i].tl) {
> > + dev_err(ce->dev, "Cannot get DMA memory for task %d\n",
> > + i);
> > + err = -ENOMEM;
> > + goto error_engine;
> > + }
> > + }
>
> All this initialization should be done before calling
> request_irq. You're using some of those fields in your handler.
>
No interrupt could fire, since algorithms are still not registred.
> > +
> > +#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
> > + ce->dbgfs_dir = debugfs_create_dir("sun8i-ce", NULL);
> > + if (IS_ERR_OR_NULL(ce->dbgfs_dir)) {
> > + dev_err(ce->dev, "Fail to create debugfs dir");
> > + err = -ENOMEM;
> > + goto error_engine;
> > + }
> > + ce->dbgfs_stats = debugfs_create_file("stats", 0444,
> > + ce->dbgfs_dir, ce,
> > + &sun8i_ce_debugfs_fops);
> > + if (IS_ERR_OR_NULL(ce->dbgfs_stats)) {
> > + dev_err(ce->dev, "Fail to create debugfs stat");
> > + err = -ENOMEM;
> > + goto error_debugfs;
> > + }
> > +#endif
> > + for (i = 0; i < ARRAY_SIZE(ce_algs); i++) {
> > + ce_algs[i].ce = ce;
> > + switch (ce_algs[i].type) {
> > + case CRYPTO_ALG_TYPE_SKCIPHER:
> > + id = ce_algs[i].ce_algo_id;
> > + ce_method = ce->variant->alg_cipher[id];
> > + if (ce_method == CE_ID_NOTSUPP) {
> > + dev_info(ce->dev,
> > + "DEBUG: Algo of %s not supported\n",
> > + ce_algs[i].alg.skcipher.base.cra_name);
> > + ce_algs[i].ce = NULL;
> > + break;
> > + }
> > + id = ce_algs[i].ce_blockmode;
> > + ce_method = ce->variant->op_mode[id];
> > + if (ce_method == CE_ID_NOTSUPP) {
> > + dev_info(ce->dev, "DEBUG: Blockmode of %s not supported\n",
> > + ce_algs[i].alg.skcipher.base.cra_name);
> > + ce_algs[i].ce = NULL;
> > + break;
> > + }
> > + dev_info(ce->dev, "DEBUG: Register %s\n",
> > + ce_algs[i].alg.skcipher.base.cra_name);
> > + err = crypto_register_skcipher(&ce_algs[i].alg.skcipher);
> > + if (err) {
> > + dev_err(ce->dev, "Fail to register %s\n",
> > + ce_algs[i].alg.skcipher.base.cra_name);
> > + ce_algs[i].ce = NULL;
> > + goto error_alg;
> > + }
> > + break;
> > + default:
> > + dev_err(ce->dev, "ERROR: tryed to register an unknown algo\n");
> > + }
> > + }
> > +
> > + return 0;
> > +error_alg:
> > + i--;
> > + for (; i >= 0; i--) {
> > + switch (ce_algs[i].type) {
> > + case CRYPTO_ALG_TYPE_SKCIPHER:
> > + if (ce_algs[i].ce)
> > + crypto_unregister_skcipher(&ce_algs[i].alg.skcipher);
> > + break;
> > + }
> > + }
> > +#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
> > +error_debugfs:
> > + debugfs_remove_recursive(ce->dbgfs_dir);
> > +#endif
> > + i = ce->variant->maxflow;
> > +error_engine:
> > + while (i >= 0) {
> > + crypto_engine_exit(ce->chanlist[i].engine);
> > + if (ce->chanlist[i].tl)
> > + dma_free_coherent(ce->dev, sizeof(struct ce_task),
> > + ce->chanlist[i].tl,
> > + ce->chanlist[i].t_phy);
> > + i--;
> > + }
> > +error_flow:
> > + reset_control_assert(ce->reset);
> > +error_clk:
> > + for (i = 0; i < CE_MAX_CLOCKS; i++)
> > + clk_disable_unprepare(ce->ceclks[i]);
> > + return err;
> > +}
>
> So that function takes around 200-250 LoC, this is definitely too
> much and should be split into multiple functions.
>
Will do.
Thanks for your review.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
From: Pavel Machek @ 2019-09-07 19:40 UTC (permalink / raw)
To: Lubomir Rintel, arnd
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20190828072629.285760-1-lkundrak@v3.sk>
[-- Attachment #1.1: Type: text/plain, Size: 458 bytes --]
> Here's a couple of updates for the MMP2 SoC devicetree files.
> I'm wondering if they could be applied to the armsoc tree?
>
> Compared to previous submission, the only change is the addition of
> Acks from Pavel.
Any news here? Having up-to-date dts is kind-of useful....
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
From: Arnd Bergmann @ 2019-09-07 19:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Mark Rutland, DTML, linux-kernel@vger.kernel.org, Lubomir Rintel,
Rob Herring, Olof Johansson, Linux ARM
In-Reply-To: <20190907194040.GB25459@amd>
On Sat, Sep 7, 2019 at 9:40 PM Pavel Machek <pavel@ucw.cz> wrote:
>
>
> > Here's a couple of updates for the MMP2 SoC devicetree files.
> > I'm wondering if they could be applied to the armsoc tree?
> >
> > Compared to previous submission, the only change is the addition of
> > Acks from Pavel.
>
> Any news here? Having up-to-date dts is kind-of useful....
Thanks for adding me to Cc on your reply. I'm doing the merged for 5.4
and had not noticed this series earlier (I found the mmp3 series by
accident, but that one looked like it was not meant as a submission
for inclusion yet).
I've added the six patches to the arm/late branch in the soc tree
now, they will be in 5.4.
Lubomir, please send all future submissions to soc@kernel.org
(with Cc: to the interested parties) when you want them to be
included in the soc tree. That way they show up in patchwork
and won't get lost.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] ARM: dts: mmp2: devicetree updates
From: Pavel Machek @ 2019-09-07 20:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, DTML, linux-kernel@vger.kernel.org, Lubomir Rintel,
Rob Herring, Olof Johansson, Linux ARM
In-Reply-To: <CAK8P3a0nNEoy31oxFL11Y2VHw-O=m8e8JuuQk+FjiPh94GikoA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 978 bytes --]
On Sat 2019-09-07 21:57:42, Arnd Bergmann wrote:
> On Sat, Sep 7, 2019 at 9:40 PM Pavel Machek <pavel@ucw.cz> wrote:
> >
> >
> > > Here's a couple of updates for the MMP2 SoC devicetree files.
> > > I'm wondering if they could be applied to the armsoc tree?
> > >
> > > Compared to previous submission, the only change is the addition of
> > > Acks from Pavel.
> >
> > Any news here? Having up-to-date dts is kind-of useful....
>
> Thanks for adding me to Cc on your reply. I'm doing the merged for 5.4
> and had not noticed this series earlier (I found the mmp3 series by
> accident, but that one looked like it was not meant as a submission
> for inclusion yet).
>
> I've added the six patches to the arm/late branch in the soc tree
> now, they will be in 5.4.
That was quick, thank you!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 2/2] media: i2c: Add DW9768 VCM driver
From: kbuild test robot @ 2019-09-07 22:12 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, sam.hung, shengnan.wang, dongchun.zhu, tfiga,
sj.huang, robh+dt, linux-mediatek, kbuild-all, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190905072142.14606-3-dongchun.zhu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[cannot apply to v5.3-rc7 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/dongchun-zhu-mediatek-com/media-i2c-dw9768-Add-DT-support-and-MAINTAINERS-entry/20190908-044622
base: git://linuxtv.org/media_tree.git master
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/media/i2c/dw9768.c: In function 'dw9768_write_smbus':
>> drivers/media/i2c/dw9768.c:82:9: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ret;
^~~
vim +/ret +82 drivers/media/i2c/dw9768.c
70
71 static int dw9768_write_smbus(struct dw9768 *dw9768, unsigned char reg,
72 unsigned char value)
73 {
74 struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
75 int ret;
76
77 if (reg == DW9768_CMD_DELAY && value == DW9768_CMD_DELAY)
78 usleep_range(DW9768_CTRL_DELAY_US,
79 DW9768_CTRL_DELAY_US + 100);
80 else
81 ret = i2c_smbus_write_byte_data(client, reg, value);
> 82 return ret;
83 }
84
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51779 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Andi Shyti @ 2019-09-07 23:38 UTC (permalink / raw)
To: Yuehaibing
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, linux-samsung-soc@vger.kernel.org, f.fainelli,
benjaminfair, shc_work, khilman, openbmc, michal.simek,
Krzysztof Kozlowski, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard, broonie, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <3595bac1-e426-b4f9-4e24-01e104fdfe5d@huawei.com>
Hi Yuehaibing,
> >> Use devm_platform_ioremap_resource() to simplify the code a bit.
> >> This is detected by coccinelle.
> >>
> >> Reported-by: Hulk Robot <hulkci@huawei.com>
> >
> > This tag does not look real... First of all where is the report?
>
> It is our internal CI robot, which is unavailable to external temporarily.
Hulk Robot is not a person and not accountable for his report.
If it is your internal CI, please write a sentence stating that
the fix has been made using Huawei internal tools.
Credit must be given to tools as well, but not accounts that will
never answer an e-mail.
Otherwise, the patch would look fine.
Andi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
From: Guo Ren @ 2019-09-07 23:52 UTC (permalink / raw)
To: Will Deacon
Cc: julien.thierry, Catalin Marinas, Palmer Dabbelt, Will Deacon,
christoffer.dall, Atish Patra, Julien Grall, gary, linux-riscv,
kvmarm, Mike Rapoport, Christoph Hellwig, aou, Arnd Bergmann,
suzuki.poulose, Marc Zyngier, Paul Walmsley, linux-arm-kernel,
Anup Patel, Linux Kernel Mailing List, iommu, james.morse
In-Reply-To: <20190624104006.lvm32nahemaqklxc@willie-the-truck>
Thx Will,
On Mon, Jun 24, 2019 at 6:40 PM Will Deacon <will@kernel.org> wrote:
> > I'll keep my system use the same ASID for SMP + IOMMU :P
>
> You will want a separate allocator for that:
>
> https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.brucker@arm.com
Yes, it is hard to maintain ASID between IOMMU and CPUMMU or different
system, because it's difficult to synchronize the IO_ASID when the CPU
ASID is rollover.
But we could still use hardware broadcast TLB invalidation instruction
to uniformly manage the ASID and IO_ASID, or OTHER_ASID in our IOMMU.
Welcome to join our disscusion:
"Introduce an implementation of IOMMU in linux-riscv"
9 Sep 2019, 10:45 Jade-room-I&II (Corinthia Hotel Lisbon) RISC-V MC
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox