Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
Hi, On 03-01-18 00:40, Darren Hart wrote: On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote: Add touchscreen platform data for the Teclast X98 Plus II tablet. Signed-off-by: Paul Cercueil Acked-by: Hans de Goede --- drivers/platform/x86/silead_dmi.c | 24 1 file changed, 24 insertions(+) v2: Rebased on top of http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy Generally "testing" is the branch you want to base on if linus/master doesn't work as the review-* branches *will* rebase frequently. Exceptions exist of course, and this patch is just fine - just for future reference. This is my "fault", I asked Paul to rebase on top of review-andy as that had 1 new silead_dmi patches missing from testing, so otherwise we would end up with a conflict when merging review branches. Same reason why I've been basing my silead_dmi patches on top of review-andy even though that is an unusual base to use. Regards, Hans
Re: [PATCH 05/12] pinctrl: armada-37xx: account for const type of of_device_id.data
On Tue, Jan 2, 2018 at 2:28 PM, Julia Lawall wrote: > The data field of an of_device_id structure has type const void *, so > there is no need for a const-discarding cast when putting const values > into such a structure. > > Done using Coccinelle. > > Signed-off-by: Julia Lawall Patch applied with Gregory's ACK. Yours, Linus Walleij
Re: [PATCH] ethernet: mlx4: Delete an error message for a failed memory allocation in five functions
On Wed, 3 Jan 2018, Tariq Toukan wrote: > > > On 01/01/2018 10:46 PM, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Mon, 1 Jan 2018 21:42:27 +0100 > > > > Omit an extra message for a memory allocation failure in these functions. > > > > This issue was detected by using the Coccinelle software. > > > > Signed-off-by: Markus Elfring > > --- > > Is this an issue? Why? What is your motivation? > These are error messages, very informative, appear only upon errors, and in > control flow. Strings take up space. Since there is a backtrace on an out of memory problem, if the string does not provide any more information than the position of the call, then there is not much added value. I don't know what was the string in this case. If it provides some additional information, then it would be reasonable to keep it. julia > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop user
friendly graphic user interface.
ofcap 7 general features:
CPU NXP Freescale i.MX6Q rev1.5 at 792 MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC, 512MB
LVDS Display TFT 7" industrial, 800x480 resolution
Touchscreen EP0700M06 EDT Polytouch capacitive touch screen
Backlight LED backlight, brightness 300 Cd/m2
Power supply 15 to 30 Vdc
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore-ofcap7.dts | 100 +++
2 files changed, 101 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0bb8db3..11d0544 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -451,6 +451,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
+ imx6q-icore-ofcap7.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-mccmon6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
new file mode 100644
index 000..f0be682
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 7 Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ ep0700m06: touchscreen@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_edt_ft5x06>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <30 IRQ_TYPE_NONE>;
+ reset-gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ reg = <0>;
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_edt_ft5x06: edt-ft5x06grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30 0x1b0b0 /*interrupt*/
+ MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00 0x1b0b0 /*reset edt*/
+ >;
+ };
+};
--
2.7.4
Re: [PATCH] pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
On Tue, Jan 2, 2018 at 5:40 PM, Stefan Agner wrote:
> From: Bai Ping
>
> On i.MX 6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL registers
> are available in a separate IOMUXC_SNVS module. Add support for the
> IOMUXC_SNVS module to the i.MX 6UL pinctrl driver.
>
> Signed-off-by: Bai Ping
> Signed-off-by: Stefan Agner
So 6 unsigned long 32 bit is succeeded by 6 unsigned long long, 64 bit?
Someone is having fun naming these platforms I see.
> Required properties:
> -- compatible: "fsl,imx6ul-iomuxc"
> +- compatible: "fsl,imx6ul-iomuxc" for main IOMUX controller or
> + "fsl,imx6ull-iomuxc-snvs" for i.MX 6ULL's SNVS IOMUX controller.
Pretty uncontroversial change but still nice to give the DT people a chance
to ACK it.
> static int imx6ul_pinctrl_probe(struct platform_device *pdev)
> {
> - return imx_pinctrl_probe(pdev, &imx6ul_pinctrl_info);
> + const struct of_device_id *match;
> + struct imx_pinctrl_soc_info *pinctrl_info;
> +
> + match = of_match_device(imx6ul_pinctrl_of_match, &pdev->dev);
> +
> + if (!match)
> + return -ENODEV;
> +
> + pinctrl_info = (struct imx_pinctrl_soc_info *) match->data;
1. Do not use a cast on void * pointers.
2. Use this function:
extern const void *of_device_get_match_data(const struct device *dev);
>From
Yours,
Linus Walleij
Re: [PATCH 1/4] extcon: axp288: Remove unused extcon_nb struct member
Hi,
On 03-01-18 02:17, Chanwoo Choi wrote:
Hi Hans,
On 2017년 12월 22일 21:36, Hans de Goede wrote:
Remove the unused extcon_nb struct member.
Signed-off-by: Hans de Goede
---
drivers/extcon/extcon-axp288.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 981fba56bc18..ba185e9ebb82 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -107,7 +107,6 @@ struct axp288_extcon_info {
struct gpio_desc *gpio_mux_cntl;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
- struct notifier_block extcon_nb;
unsigned int previous_cable;
};
Applied them(patch1/2/3/4). Thanks.
Great, thank you.
Regards,
Hans
Re: About the try to remove cross-release feature entirely by Ingo
On 1/3/2018 4:05 PM, Theodore Ts'o wrote:
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
The point I was trying to drive home is that "all we have to do is
just classify everything well or just invalidate the right lock
Just to be sure, we don't have to invalidate lock objects at all but
a problematic waiter only.
So essentially you are proposing that we have to play "whack-a-mole"
as we find false positives, and where we may have to put in ad-hoc
plumbing to only invalidate "a problematic waiter" when it's
problematic --- or to entirely suppress the problematic waiter
If we have too many problematic completions(waiters) to handle it,
then I agree with you. But so far, only one exits and it seems able
to be handled even in the future on my own.
Or if you believe that we have a lot of those kind of completions
making trouble so we cannot handle it, the (4) by Amir would work,
no? I'm asking because I'm really curious about your opinion..
altogether. And in that case, a file system developer might be forced
to invalidate a lock/"waiter"/"completion" in another subsystem.
As I said, with regard to the invalidation, we don't have to
consider locks at all. It's enough to invalidate the waiter only.
I will also remind you that doing this will trigger a checkpatch.pl
*error*:
This is what we decided. And I think the decision is reasonable for
original lockdep. But I wonder if we should apply the same decision
on waiters. I don't insist but just wonder.
ERROR("LOCKDEP", "lockdep_no_validate class is reserved for device->mutex.\n" .
$herecurr);
- Ted
--
Thanks,
Byungchul
Happy New Year
I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more details on this email id: shengl...@hotmail.com Thanks Mr Sheng Li Hung
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Hi All, On Wed, Jan 3, 2018 at 6:49 PM, Geert Uytterhoeven wrote: > Hi Michael, > > On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman wrote: >> Geert Uytterhoeven writes: >> >>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman >>> wrote: Christoph Hellwig writes: > We want to use the dma_direct_ namespace for a generic implementation, > so rename powerpc to the second best choice: dma_nommu_. I'm not a fan of "nommu". Some of the users of direct ops *are* using an IOMMU, they're just setting up a 1:1 mapping once at init time, rather than mapping dynamically. Though I don't have a good idea for a better name, maybe "1to1", "linear", "premapped" ? >>> >>> "identity"? >> >> I think that would be wrong, but thanks for trying to help :) >> >> The address on the device side is sometimes (often?) offset from the CPU >> address. So eg. the device can DMA to RAM address 0x0 using address >> 0x800. >> >> Identity would imply 0 == 0 etc. >> >> I think "bijective" is the correct term, but that's probably a bit >> esoteric. > > OK, didn't know about the offset. > Then "linear" is what we tend to use, right? If this is indeed a linear mapping, can we just remove this and replace it with the new "generic" mapping being introduced by this patchset? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
Re: About the try to remove cross-release feature entirely by Ingo
On 1/3/2018 5:10 PM, Byungchul Park wrote:
On 1/3/2018 4:05 PM, Theodore Ts'o wrote:
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
The point I was trying to drive home is that "all we have to do is
just classify everything well or just invalidate the right lock
Just to be sure, we don't have to invalidate lock objects at all but
a problematic waiter only.
So essentially you are proposing that we have to play "whack-a-mole"
as we find false positives, and where we may have to put in ad-hoc
plumbing to only invalidate "a problematic waiter" when it's
problematic --- or to entirely suppress the problematic waiter
If we have too many problematic completions(waiters) to handle it,
then I agree with you. But so far, only one exits and it seems able
to be handled even in the future on my own.
Or if you believe that we have a lot of those kind of completions
making trouble so we cannot handle it, the (4) by Amir would work,
no? I'm asking because I'm really curious about your opinion..
altogether. And in that case, a file system developer might be forced
to invalidate a lock/"waiter"/"completion" in another subsystem.
As I said, with regard to the invalidation, we don't have to
consider locks at all. It's enough to invalidate the waiter only.
I will also remind you that doing this will trigger a checkpatch.pl
*error*:
This is what we decided. And I think the decision is reasonable for
original lockdep. But I wonder if we should apply the same decision
on waiters. I don't insist but just wonder.
What if we adopt the (4) in which waiters are validated one by one
and no explicit invalidation is involved?
ERROR("LOCKDEP", "lockdep_no_validate class is reserved for
device->mutex.\n" . $herecurr);
- Ted
--
Thanks,
Byungchul
[PATCH 0/3] unclutter thp migration
Hi, I have posted this work as an RFC [1] and there were no fundamental objections to the approach so I am resending for inclusion. It is quite late in the release cycle and I definitely do not want to rush this into the next release cycle but having it in linux-next for longer should be only better to show potential fallouts. Motivation: THP migration is hacked into the generic migration with rather surprising semantic. The migration allocation callback is supposed to check whether the THP can be migrated at once and if that is not the case then it allocates a simple page to migrate. unmap_and_move then fixes that up by splitting the THP into small pages while moving the head page to the newly allocated order-0 page. Remaining pages are moved to the LRU list by split_huge_page. The same happens if the THP allocation fails. This is really ugly and error prone [2]. I also believe that split_huge_page to the LRU lists is inherently wrong because all tail pages are not migrated. Some callers will just work around that by retrying (e.g. memory hotplug). There are other pfn walkers which are simply broken though. e.g. madvise_inject_error will migrate head and then advances next pfn by the huge page size. do_move_page_to_node_array, queue_pages_range (migrate_pages, mbind), will simply split the THP before migration if the THP migration is not supported then falls back to single page migration but it doesn't handle tail pages if the THP migration path is not able to allocate a fresh THP so we end up with ENOMEM and fail the whole migration which is a questionable behavior. Page compaction doesn't try to migrate large pages so it should be immune. The first patch reworks do_pages_move which relies on a very ugly calling semantic when the return status is pushed to the migration path via private pointer. It uses pre allocated fixed size batching to achieve that. We simply cannot do the same if a THP is to be split during the migration path which is done in the patch 3. Patch 2 is follow up cleanup which removes the mentioned return status calling convention ugliness. On a side note: There are some semantic issues I have encountered on the way when working on patch 1 but I am not addressing them here. E.g. trying to move THP tail pages will result in either success or EBUSY (the later one more likely once we isolate head from the LRU list). Hugetlb reports EACCESS on tail pages. Some errors are reported via status parameter but migration failures are not even though the original `reason' argument suggests there was an intention to do so. From a quick look into git history this never worked. I have tried to keep the semantic unchanged. Then there is a relatively minor thing that the page isolation might fail because of pages not being on the LRU - e.g. because they are sitting on the per-cpu LRU caches. Easily fixable. Shortlog Michal Hocko (3): mm, numa: rework do_pages_move mm, migrate: remove reason argument from new_page_t mm: unclutter THP migration Diffstat include/linux/migrate.h| 7 +- include/linux/page-isolation.h | 3 +- mm/compaction.c| 3 +- mm/huge_memory.c | 6 + mm/internal.h | 1 + mm/memory_hotplug.c| 5 +- mm/mempolicy.c | 40 + mm/migrate.c | 354 ++--- mm/page_isolation.c| 3 +- 9 files changed, 181 insertions(+), 241 deletions(-) [1] http://lkml.kernel.org/r/20171208161559.27313-1-mho...@kernel.org [2] http://lkml.kernel.org/r/20171121021855.50525-1-zi@sent.com
[PATCH 3/3] mm: unclutter THP migration
From: Michal Hocko
THP migration is hacked into the generic migration with rather
surprising semantic. The migration allocation callback is supposed to
check whether the THP can be migrated at once and if that is not the
case then it allocates a simple page to migrate. unmap_and_move then
fixes that up by spliting the THP into small pages while moving the
head page to the newly allocated order-0 page. Remaning pages are moved
to the LRU list by split_huge_page. The same happens if the THP
allocation fails. This is really ugly and error prone [1].
I also believe that split_huge_page to the LRU lists is inherently
wrong because all tail pages are not migrated. Some callers will just
work around that by retrying (e.g. memory hotplug). There are other
pfn walkers which are simply broken though. e.g. madvise_inject_error
will migrate head and then advances next pfn by the huge page size.
do_move_page_to_node_array, queue_pages_range (migrate_pages, mbind),
will simply split the THP before migration if the THP migration is not
supported then falls back to single page migration but it doesn't handle
tail pages if the THP migration path is not able to allocate a fresh
THP so we end up with ENOMEM and fail the whole migration which is
a questionable behavior. Page compaction doesn't try to migrate large
pages so it should be immune.
This patch tries to unclutter the situation by moving the special THP
handling up to the migrate_pages layer where it actually belongs. We
simply split the THP page into the existing list if unmap_and_move fails
with ENOMEM and retry. So we will _always_ migrate all THP subpages and
specific migrate_pages users do not have to deal with this case in a
special way.
[1] http://lkml.kernel.org/r/20171121021855.50525-1-zi@sent.com
- document changed ordering of split THP page in migrate_pages as per
Zi Yan
Acked-by: Kirill A. Shutemov
Reviewed-by: Zi Yan
Signed-off-by: Michal Hocko
---
include/linux/migrate.h | 4 ++--
mm/huge_memory.c| 6 ++
mm/memory_hotplug.c | 2 +-
mm/mempolicy.c | 31 +++
mm/migrate.c| 34 --
5 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index e5d99ade2319..0c6fe904bc97 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -42,9 +42,9 @@ static inline struct page *new_page_nodemask(struct page
*page,
return
alloc_huge_page_nodemask(page_hstate(compound_head(page)),
preferred_nid, nodemask);
- if (thp_migration_supported() && PageTransHuge(page)) {
- order = HPAGE_PMD_ORDER;
+ if (PageTransHuge(page)) {
gfp_mask |= GFP_TRANSHUGE;
+ order = HPAGE_PMD_ORDER;
}
if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 93d729fc94a4..8c296f19ff6e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2417,6 +2417,12 @@ static void __split_huge_page_tail(struct page *head,
int tail,
page_tail->index = head->index + tail;
page_cpupid_xchg_last(page_tail, page_cpupid_last(head));
+
+ /*
+* always add to the tail because some iterators expect new
+* pages to show after the currently processed elements - e.g.
+* migrate_pages
+*/
lru_add_page_tail(head, page_tail, lruvec, list);
}
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 9a2381469172..25060b0184e9 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1387,7 +1387,7 @@ do_migrate_range(unsigned long start_pfn, unsigned long
end_pfn)
if (isolate_huge_page(page, &source))
move_pages -= 1 << compound_order(head);
continue;
- } else if (thp_migration_supported() && PageTransHuge(page))
+ } else if (PageTransHuge(page))
pfn = page_to_pfn(compound_head(page))
+ hpage_nr_pages(page) - 1;
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4d849d3098e5..b6f4fcf9df64 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -446,15 +446,6 @@ static int queue_pages_pmd(pmd_t *pmd, spinlock_t *ptl,
unsigned long addr,
__split_huge_pmd(walk->vma, pmd, addr, false, NULL);
goto out;
}
- if (!thp_migration_supported()) {
- get_page(page);
- spin_unlock(ptl);
- lock_page(page);
- ret = split_huge_page(page);
- unlock_page(page);
- put_page(page);
- goto out;
- }
if (!queue_pages_required(page, qp)) {
ret = 1;
goto unlock;
@@ -495,7 +486,7 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long
addr,
i
[PATCH 2/3] mm, migrate: remove reason argument from new_page_t
From: Michal Hocko
No allocation callback is using this argument anymore. new_page_node
used to use this parameter to convey node_id resp. migration error
up to move_pages code (do_move_page_to_node_array). The error status
never made it into the final status field and we have a better way
to communicate node id to the status field now. All other allocation
callbacks simply ignored the argument so we can drop it finally.
Reviewed-by: Zi Yan
Signed-off-by: Michal Hocko
---
include/linux/migrate.h| 3 +--
include/linux/page-isolation.h | 3 +--
mm/compaction.c| 3 +--
mm/internal.h | 2 +-
mm/memory_hotplug.c| 3 +--
mm/mempolicy.c | 6 +++---
mm/migrate.c | 18 ++
mm/page_isolation.c| 3 +--
8 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index a2246cf670ba..e5d99ade2319 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -7,8 +7,7 @@
#include
#include
-typedef struct page *new_page_t(struct page *page, unsigned long private,
- int **reason);
+typedef struct page *new_page_t(struct page *page, unsigned long private);
typedef void free_page_t(struct page *page, unsigned long private);
/*
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index cdad58bbfd8b..4ae347cbc36d 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -63,7 +63,6 @@ undo_isolate_page_range(unsigned long start_pfn, unsigned
long end_pfn,
int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
bool skip_hwpoisoned_pages);
-struct page *alloc_migrate_target(struct page *page, unsigned long private,
- int **resultp);
+struct page *alloc_migrate_target(struct page *page, unsigned long private);
#endif
diff --git a/mm/compaction.c b/mm/compaction.c
index b8c23882c8ae..4589830b5959 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1165,8 +1165,7 @@ static void isolate_freepages(struct compact_control *cc)
* from the isolated freelists in the block we are migrating to.
*/
static struct page *compaction_alloc(struct page *migratepage,
- unsigned long data,
- int **result)
+ unsigned long data)
{
struct compact_control *cc = (struct compact_control *)data;
struct page *freepage;
diff --git a/mm/internal.h b/mm/internal.h
index 745e247aca9c..62d8c34e63d5 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -540,5 +540,5 @@ static inline bool is_migrate_highatomic_page(struct page
*page)
}
void setup_zone_pageset(struct zone *zone);
-extern struct page *alloc_new_node_page(struct page *page, unsigned long node,
int **x);
+extern struct page *alloc_new_node_page(struct page *page, unsigned long node);
#endif /* __MM_INTERNAL_H */
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 262bfd26baf9..9a2381469172 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1344,8 +1344,7 @@ static unsigned long scan_movable_pages(unsigned long
start, unsigned long end)
return 0;
}
-static struct page *new_node_page(struct page *page, unsigned long private,
- int **result)
+static struct page *new_node_page(struct page *page, unsigned long private)
{
int nid = page_to_nid(page);
nodemask_t nmask = node_states[N_MEMORY];
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 66c9c79b21be..4d849d3098e5 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -943,7 +943,7 @@ static void migrate_page_add(struct page *page, struct
list_head *pagelist,
}
/* page allocation callback for NUMA node migration */
-struct page *alloc_new_node_page(struct page *page, unsigned long node, int
**x)
+struct page *alloc_new_node_page(struct page *page, unsigned long node)
{
if (PageHuge(page))
return alloc_huge_page_node(page_hstate(compound_head(page)),
@@ -1108,7 +1108,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
* list of pages handed to migrate_pages()--which is how we get here--
* is in virtual address order.
*/
-static struct page *new_page(struct page *page, unsigned long start, int **x)
+static struct page *new_page(struct page *page, unsigned long start)
{
struct vm_area_struct *vma;
unsigned long uninitialized_var(address);
@@ -1153,7 +1153,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
return -ENOSYS;
}
-static struct page *new_page(struct page *page, unsigned long start, int **x)
+static struct page *new_page(struct page *page, unsigned long start)
{
return NULL;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index 8fb90bcd44a7..aba3759a2e27 100644
--- a/mm/migrate.c
+++ b/
[PATCH 1/3] mm, numa: rework do_pages_move
From: Michal Hocko
do_pages_move is supposed to move user defined memory (an array of
addresses) to the user defined numa nodes (an array of nodes one for
each address). The user provided status array then contains resulting
numa node for each address or an error. The semantic of this function is
little bit confusing because only some errors are reported back. Notably
migrate_pages error is only reported via the return value. This patch
doesn't try to address these semantic nuances but rather change the
underlying implementation.
Currently we are processing user input (which can be really large)
in batches which are stored to a temporarily allocated page. Each
address is resolved to its struct page and stored to page_to_node
structure along with the requested target numa node. The array of these
structures is then conveyed down the page migration path via private
argument. new_page_node then finds the corresponding structure and
allocates the proper target page.
What is the problem with the current implementation and why to change
it? Apart from being quite ugly it also doesn't cope with unexpected
pages showing up on the migration list inside migrate_pages path.
That doesn't happen currently but the follow up patch would like to
make the thp migration code more clear and that would need to split a
THP into the list for some cases.
How does the new implementation work? Well, instead of batching into a
fixed size array we simply batch all pages that should be migrated to
the same node and isolate all of them into a linked list which doesn't
require any additional storage. This should work reasonably well because
page migration usually migrates larger ranges of memory to a specific
node. So the common case should work equally well as the current
implementation. Even if somebody constructs an input where the target
numa nodes would be interleaved we shouldn't see a large performance
impact because page migration alone doesn't really benefit from
batching. mmap_sem batching for the lookup is quite questionable and
isolate_lru_page which would benefit from batching is not using it even
in the current implementation.
Acked-by: Kirill A. Shutemov
Signed-off-by: Michal Hocko
---
mm/internal.h | 1 +
mm/mempolicy.c | 5 +-
mm/migrate.c | 306 +
3 files changed, 138 insertions(+), 174 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 3e5dc95dc259..745e247aca9c 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -540,4 +540,5 @@ static inline bool is_migrate_highatomic_page(struct page
*page)
}
void setup_zone_pageset(struct zone *zone);
+extern struct page *alloc_new_node_page(struct page *page, unsigned long node,
int **x);
#endif /* __MM_INTERNAL_H */
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index f604b22ebb65..66c9c79b21be 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -942,7 +942,8 @@ static void migrate_page_add(struct page *page, struct
list_head *pagelist,
}
}
-static struct page *new_node_page(struct page *page, unsigned long node, int
**x)
+/* page allocation callback for NUMA node migration */
+struct page *alloc_new_node_page(struct page *page, unsigned long node, int
**x)
{
if (PageHuge(page))
return alloc_huge_page_node(page_hstate(compound_head(page)),
@@ -986,7 +987,7 @@ static int migrate_to_node(struct mm_struct *mm, int
source, int dest,
flags | MPOL_MF_DISCONTIG_OK, &pagelist);
if (!list_empty(&pagelist)) {
- err = migrate_pages(&pagelist, new_node_page, NULL, dest,
+ err = migrate_pages(&pagelist, alloc_new_node_page, NULL, dest,
MIGRATE_SYNC, MR_SYSCALL);
if (err)
putback_movable_pages(&pagelist);
diff --git a/mm/migrate.c b/mm/migrate.c
index 4d0be47a322a..8fb90bcd44a7 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1444,141 +1444,103 @@ int migrate_pages(struct list_head *from, new_page_t
get_new_page,
}
#ifdef CONFIG_NUMA
-/*
- * Move a list of individual pages
- */
-struct page_to_node {
- unsigned long addr;
- struct page *page;
- int node;
- int status;
-};
-static struct page *new_page_node(struct page *p, unsigned long private,
- int **result)
+static int store_status(int __user *status, int start, int value, int nr)
{
- struct page_to_node *pm = (struct page_to_node *)private;
-
- while (pm->node != MAX_NUMNODES && pm->page != p)
- pm++;
+ while (nr-- > 0) {
+ if (put_user(value, status + start))
+ return -EFAULT;
+ start++;
+ }
- if (pm->node == MAX_NUMNODES)
- return NULL;
+ return 0;
+}
- *result = &pm->status;
+static int do_move_pages_to_node(struct mm_struct *mm,
+ struct list_head *pagelist, int node)
+{
+ int err;
Re: [PATCH V6] mmc:host:sdhci-pci:Addition of Arasan PCI Controller with integrated phy.
On 03/01/18 02:11, Atul Garg wrote: > The Arasan Controller is based on a FPGA platform and has integrated phy > with specific registers used during initialization and > management of different modes. The phy and the controller are integrated > and registers are very specific to Arasan. > > Arasan being an IP provider, licenses these IPs to various companies for > integration of IP in custom SOCs. The custom SOCs define own register > map depending on how bits are tied inside the SOC for phy registers, > depending on SOC memory plan and hence will require own platform drivers. > > If more details on phy registers are required, an interface document is > hosted at https: //arasandotcom/NF/eMMC5.1 PHY Programming in Linux.pdf. > > Signed-off-by: Atul Garg Thanks for making the changes. Still a couple of tiny things below. > --- > V6 - Parameters are enclosed in parantheses in macros. Adjusted tab space. > Removed ret variable in arasan_phy_addr_poll. > V5 - Separated arasan_phy_poll function into arasan_phy_addr_poll and > arasan_phy_sts_poll Tabspace corrected. Checked return values of poll > functions. > Removed static declaration of sdhci_pci_enable_dma and defined in > sdhci-pci.h as suggested by Adrian Hunter . > V4 - Created arasan_phy_poll function to have common timeout call. > .Restructured arasan_set_phy to arasan_select_phy_clock and > .arasan_phy_set to have single set of registers to be programmed for > different modes. > .Applied code style suggestions from Adrian Hunter . > V3 - Removed sdhci-pci-arasan.h. Code and interface document mentioned > above are made relevant..Applied code style suggestions from > Sekhar Nori and .Adrian Hunter . > V2 - Removed code from sdhci-pci-core.c and created sdhci-pci-arasan.c and > .sdhci-pci-arasan.h. > V1 - Initial Patch coded in sdhci-pci-core.c. > > drivers/mmc/host/Makefile | 2 +- > drivers/mmc/host/sdhci-pci-arasan.c | 338 > > drivers/mmc/host/sdhci-pci-core.c | 4 +- > drivers/mmc/host/sdhci-pci.h| 7 +- > 4 files changed, 347 insertions(+), 4 deletions(-) > create mode 100644 drivers/mmc/host/sdhci-pci-arasan.c > > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile > index 191a040..84cd138 100644 > --- a/drivers/mmc/host/Makefile > +++ b/drivers/mmc/host/Makefile > @@ -11,7 +11,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o > obj-$(CONFIG_MMC_MXS)+= mxs-mmc.o > obj-$(CONFIG_MMC_SDHCI) += sdhci.o > obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o > -sdhci-pci-y += sdhci-pci-core.o sdhci-pci-o2micro.o > +sdhci-pci-y += sdhci-pci-core.o sdhci-pci-o2micro.o > sdhci-pci-arasan.o > obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI)) += sdhci-pci-data.o > obj-$(CONFIG_MMC_SDHCI_ACPI) += sdhci-acpi.o > obj-$(CONFIG_MMC_SDHCI_PXAV3)+= sdhci-pxav3.o > diff --git a/drivers/mmc/host/sdhci-pci-arasan.c > b/drivers/mmc/host/sdhci-pci-arasan.c > new file mode 100644 > index 000..79d1f74 > --- /dev/null > +++ b/drivers/mmc/host/sdhci-pci-arasan.c > @@ -0,0 +1,338 @@ > +/* > + * Copyright (C) 2017 Arasan Chip Systems Inc. > + * > + * Author: Atul Garg > + * > + * This software is licensed under the terms of the GNU General Public > + * License version 2, as published by the Free Software Foundation, and > + * may be copied, distributed, and modified under those terms. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. Please consider using SPDX license identifiers: https://marc.info/?l=linux-kernel&m=151447555910302&w=2 > + * > + */ > + > +#include > +#include > + > +#include "sdhci.h" > +#include "sdhci-pci.h" > + > +/* Extra registers for Arasan SD Host Controller for eMMC5.1 PHY */ > +#define PHY_ADDR_REG 0x300 > +#define PHY_DAT_REG 0x304 > + > +#define PHY_WRITEBIT(8) > +#define PHY_BUSY BIT(9) > +#define DATA_MASK0xFF > + > +/* eMMC5.1 PHY Specific Registers */ > +#define DLL_STATUS 0x00 > +#define IPAD_CTRL1 0x01 > +#define IPAD_CTRL2 0x02 > +#define IPAD_STS 0x03 > +#define IOREN_CTRL1 0x06 > +#define IOREN_CTRL2 0x07 > +#define IOPU_CTRL1 0x08 > +#define IOPU_CTRL2 0x09 > +#define ITAP_DELAY 0x0C > +#define OTAP_DELAY 0x0D > +#define STRB_SEL 0x0E > +#define CLKBUF_SEL 0x0F > +#define MODE_CTRL0x11 > +#define DLL_TRIM 0x12 > +#define CMD_CTRL 0x20 > +#define DATA_CTRL0x21 > +#define STRB_CTRL0x22 > +#define CLK_CTRL 0x23 > +#define PHY_CTRL 0x24 > + > +#define DLL_ENBL BIT(3) > +#define RTRIM_EN BIT(1) > +#define PDB_ENBL BIT(1) > +#define RETB_ENBLBIT(6) > +#define ODEN_CMD BIT(1) > +#define ODEN_DAT 0xFF > +#define REN_STRB BIT(0) > +#define REN_CMND BIT(1) > +#defi
Re: [GIT PULL] phy: for 4.16
Hi Greg, On Tuesday 02 January 2018 03:25 PM, Greg KH wrote: > On Tue, Jan 02, 2018 at 01:46:54PM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> Please find the pull request for 4.16 merge window below. >> >> It includes a fix in exynos5-usbdrd to enumerate SuperSpeed devices on >> Odroid XU3 and includes fixes/cleanups in Broadcom and Mediatek PHYs. >> Please see the tag message for the complete list of changes. > > Are you wanting these "fixes" to be in 4.15-final, or is 4.16-rc1 ok? 4.16-rc1 is okay for these fixes. Thanks Kishon
Re: [PATCH][crypto-next] crypto: inside-secure - make function safexcel_try_push_requests static
Hi Colin, On Tue, Jan 02, 2018 at 02:34:10PM +, Colin King wrote: > > /* Called with ring's lock taken */ > -int safexcel_try_push_requests(struct safexcel_crypto_priv *priv, int ring, > -int reqs) > +static int safexcel_try_push_requests(struct safexcel_crypto_priv *priv, > + int ring, int reqs) Alignment should match open parenthesis, one space is missing. Otherwise, looks good to me. Thanks! Antoine -- Antoine Ténart, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 1/6] phy: sun4i-usb: add support for R40 USB PHY
Hi, On Saturday 30 December 2017 05:08 PM, Icenowy Zheng wrote: > 在 2017年10月18日星期三 CST 下午7:46:08，Kishon Vijay Abraham I 写道： >> On Wednesday 18 October 2017 05:12 PM, Maxime Ripard wrote: >>> On Wed, Oct 18, 2017 at 05:09:00PM +0530, Kishon Vijay Abraham I wrote: Hi, On Tuesday 10 October 2017 02:28 AM, Maxime Ripard wrote: > On Sun, Oct 08, 2017 at 04:29:01AM +, Icenowy Zheng wrote: >> Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs. >> >> Add support for it. >> >> Signed-off-by: Icenowy Zheng > > Acked-by: Maxime Ripard Is this patch good to be merged? I see you have pending comments on the other patch in the series. >>> >>> Yeah, but I guess you can merge this one, it's pretty harmless, and it >>> will reduce the amount of patches to review / merge later on. >> >> Thank you for the quick reply. >> >> merged with Maxime's and Rob's Ack. > > Sorry, but I didn't see the patch appears in linux-next for such long time. > > Is it lost? yeah, looks like it. Can you post it again? sorry about that :-/ Thanks Kishon
Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations
> I understand it can be frustrating to encounter different policies > across kernel maintainers. The change acceptance is varying for special transformation patterns. > You'll even run in to this with maintainers of the same subsystem > from time to time. Interesting, isn't it? > I'm supportive of cleaning up old code in general, Nice. > and we routinely apply such patches as these developed with cocci. Good to know … > 1. This is init code )so any space savings is short lived) Would you dare to achieve another small improvement there? > So it isn't that we place a low value on coding style guidelines, > but rather we place higher value on not perturbing code I can follow this view in principle. > we can't fully test without a demonstrable functional reasons to do so. How do you think about to get a bit nicer run time characteristics? Regards, Markus
Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move
On 12/08/2017 09:45 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> do_pages_move is supposed to move user defined memory (an array of
> addresses) to the user defined numa nodes (an array of nodes one for
> each address). The user provided status array then contains resulting
> numa node for each address or an error. The semantic of this function is
> little bit confusing because only some errors are reported back. Notably
> migrate_pages error is only reported via the return value. This patch
> doesn't try to address these semantic nuances but rather change the
> underlying implementation.
>
> Currently we are processing user input (which can be really large)
> in batches which are stored to a temporarily allocated page. Each
> address is resolved to its struct page and stored to page_to_node
> structure along with the requested target numa node. The array of these
> structures is then conveyed down the page migration path via private
> argument. new_page_node then finds the corresponding structure and
> allocates the proper target page.
>
> What is the problem with the current implementation and why to change
> it? Apart from being quite ugly it also doesn't cope with unexpected
> pages showing up on the migration list inside migrate_pages path.
> That doesn't happen currently but the follow up patch would like to
> make the thp migration code more clear and that would need to split a
> THP into the list for some cases.
>
> How does the new implementation work? Well, instead of batching into a
> fixed size array we simply batch all pages that should be migrated to
> the same node and isolate all of them into a linked list which doesn't
> require any additional storage. This should work reasonably well because
> page migration usually migrates larger ranges of memory to a specific
> node. So the common case should work equally well as the current
> implementation. Even if somebody constructs an input where the target
> numa nodes would be interleaved we shouldn't see a large performance
> impact because page migration alone doesn't really benefit from
> batching. mmap_sem batching for the lookup is quite questionable and
> isolate_lru_page which would benefit from batching is not using it even
> in the current implementation.
>
> Signed-off-by: Michal Hocko
> ---
> mm/internal.h | 1 +
> mm/mempolicy.c | 5 +-
> mm/migrate.c | 306
> +
> 3 files changed, 139 insertions(+), 173 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index e6bd35182dae..1a1bb5d59c15 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -538,4 +538,5 @@ static inline bool is_migrate_highatomic_page(struct page
> *page)
> }
>
> void setup_zone_pageset(struct zone *zone);
> +extern struct page *alloc_new_node_page(struct page *page, unsigned long
> node, int **x);
> #endif /* __MM_INTERNAL_H */
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index f604b22ebb65..66c9c79b21be 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -942,7 +942,8 @@ static void migrate_page_add(struct page *page, struct
> list_head *pagelist,
> }
> }
>
> -static struct page *new_node_page(struct page *page, unsigned long node, int
> **x)
> +/* page allocation callback for NUMA node migration */
> +struct page *alloc_new_node_page(struct page *page, unsigned long node, int
> **x)
> {
> if (PageHuge(page))
> return alloc_huge_page_node(page_hstate(compound_head(page)),
> @@ -986,7 +987,7 @@ static int migrate_to_node(struct mm_struct *mm, int
> source, int dest,
> flags | MPOL_MF_DISCONTIG_OK, &pagelist);
>
> if (!list_empty(&pagelist)) {
> - err = migrate_pages(&pagelist, new_node_page, NULL, dest,
> + err = migrate_pages(&pagelist, alloc_new_node_page, NULL, dest,
> MIGRATE_SYNC, MR_SYSCALL);
> if (err)
> putback_movable_pages(&pagelist);
This reuses the existing page allocation helper from migrate_pages() system
call. But all these allocator helper names for migrate_pages() function are
really confusing. Even in this case alloc_new_node_page and the original
new_node_page() which is still getting used in do_migrate_range() sounds
similar even if their implementation is quite different. IMHO either all of
them should be moved to the header file with proper differentiating names
or let them be there in their respective files with these generic names and
clean them up later.
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 4d0be47a322a..9d7252ea2acd 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1444,141 +1444,104 @@ int migrate_pages(struct list_head *from,
> new_page_t get_new_page,
> }
>
> #ifdef CONFIG_NUMA
> -/*
> - * Move a list of individual pages
> - */
> -struct page_to_node {
> - unsigned long addr;
> - struct page *page;
> - int node;
> - int status;
Re: [PATCH 3/5] arch: Remove clkdev.h asm-generic from Kbuild
On Wed, Jan 3, 2018 at 2:35 AM, Stephen Boyd wrote:
> Now that every architecture is using the generic clkdev.h file
> and we no longer include asm/clkdev.h anywhere in the tree, we
> can remove it.
>
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc:
> Signed-off-by: Stephen Boyd
For m68k part:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()
>> Omit an extra message for a memory allocation failure in this function. >> >> This issue was detected by using the Coccinelle software. >> > What is the issue with this message? * Is it redundant? * Would a Linux allocation failure report be already sufficient here? Regards, Markus
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
> When an interrupt is moved across node collections on ThunderX2
node collections?
> multi Socket platform, an interrupt stops routed to new collection
> and results in loss of interrupts.
>
> Adding workaround to issue INV after MOVI for cross-node collection
> move to flush out the cached entry.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++
> drivers/irqchip/irq-gic-v3-its.c | 24
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index fc1c884..fb27cb5 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,6 +63,7 @@ stable kernels.
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
> |
> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115
> |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A
> |
> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
> |
> | Cavium | ThunderX2 SMMUv3| #74 | N/A
> |
> | Cavium | ThunderX2 SMMUv3| #126| N/A
> |
> || | |
> |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c9a7e9e..71a7e30 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_174
> + bool "Cavium ThunderX2 erratum 174"
> + depends on NUMA
Why? This system will be affected no matter whether NUMA is selected or not.
> + default y
> + help
> + LPI stops routed to redistributors after inter node collection
> + move in ITS. Enable workaround to invalidate ITS entry after
> + inter-node collection move.
That's a very terse description. Nobody knows what an LPI, a
redistributor or a collection is. Please explain what the erratum is in
layman's terms (Cavium ThunderX2 systems may loose interrupts on
affinity change) so that people understand whether or not they are affected.
> +
> + If unsure, say Y.
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025f..d8b9c96 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -46,6 +46,7 @@
> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>
> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>
> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const
> struct cpumask *mask_val,
> if (cpu != its_dev->event_map.col_map[id]) {
> target_col = &its_dev->its->collections[cpu];
> its_send_movi(its_dev, target_col, id);
> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
> + /* Issue INV for cross node collection move. */
> + if (cpu_to_node(cpu) !=
> + cpu_to_node(its_dev->event_map.col_map[id]))
> + its_send_inv(its_dev, id);
> + }
What happens if an interrupt happens after the MOV, but before the INV?
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
> @@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
> }
> }
>
> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
> +{
> + struct its_node *its = data;
> +
> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
> +
> + return true;
> +}
> +
> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
> {
> struct its_node *its = data;
> @@ -3031,6 +3047,14 @@ static const struct gic_quirk its_quirks[] = {
> .init = its_enable_quirk_hip07_161600802,
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_174
> + {
> + .desc = "ITS: Cavium ThunderX2 erratum 174",
> + .iidr = 0x13f,/* ThunderX2 pass A1/A2/B0 */
Do all 3 revisions have the same IIDR?
> + .mask = 0x,
> + .init = its_enable_quirk_cavium_174,
> + },
> +#endif
> {
> }
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
RE: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
Hi Jeremy,
Sorry, I don't have your previous patch emails to reply on right patch
context.
So commenting on top of this patch.
AFAIU, the PPTT v5 patches still rely on CLIDR_EL1 register to know the type
of
Caches enabled/available on the platform. With PPTT, it should not rely on
architecture
registers. There can be platforms which can report cache availability in
PPTT but not in
architecture registers.
The following code snippet shows usage of CLIDR_EL1
In arch/arm64/kernel/cacheinfo.c
static inline enum cache_type get_cache_type(int level)
{
u64 clidr;
if (level > MAX_CACHE_LEVEL)
return CACHE_TYPE_NOCACHE;
clidr = read_sysreg(clidr_el1);
return CLIDR_CTYPE(clidr, level);
}
static int __populate_cache_leaves(unsigned int cpu)
{
unsigned int level, idx;
enum cache_type type;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
idx < this_cpu_ci->num_leaves; idx++, level++) {
type = get_cache_type(level);
if (type == CACHE_TYPE_SEPARATE) {
ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
} else {
ci_leaf_init(this_leaf++, type, level);
}
}
return 0;
}
In populate_cache_leaves() the cache type is read from CLIDR_EL1 register.
If CLIDR_EL1 reports CACHE_TYPE_NOCACHE for a particular level then sysfs
entry
/sys/devices/system/cpu/cpu0/index/type is not created and hence
userspace tools
like lstopo will not report this cache level.
Regards
Vijay
> -Original Message-
> From: linux-arm-kernel
[mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Rafael J. Wysocki
> Sent: Thursday, December 14, 2017 4:40 AM
> To: Jeremy Linton
> Cc: Mark Rutland ; jonathan.zh...@cavium.com;
> jayachandran.n...@cavium.com; Lorenzo Pieralisi
> ; Catalin Marinas ;
> Rafael J. Wysocki ; jh...@codeaurora.org; Will Deacon
> ; Linux PM ; Rafael J.
> Wysocki ; Greg Kroah-Hartman
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; ACPI Devel Maling List
;
> Viresh Kumar ; Hanjun Guo
> ; Al Stone ; Sudeep Holla
> ; austi...@codeaurora.org;
> wangxiongfe...@huawei.com; linux-arm-ker...@lists.infradead.org; Len
> Brown
> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
>
> On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton
> wrote:
> > Hi,
> >
> >
> > On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
> >>
> >> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
> >> wrote:
> >>>
> >>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
>
> Hi,
>
> First, thanks for taking a look at this.
>
> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
> >
> > On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> >>
> >> The PPTT can be used to determine the groupings of CPU's at given
> >> levels in the system. Lets add a few routines to the PPTT parsing
> >> code to return a unique id for each unique level in the processor
> >> hierarchy. This can then be matched to build
> >> thread/core/cluster/die/package/etc mappings for each processing
> >> element in the system.
> >>
> >> Signed-off-by: Jeremy Linton
> >
> >
> > Why can't this be folded into patch [2/9]?
>
>
> It can, and I will be happy squash it.
>
> It was requested that the topology portion of the parser be split
> out back in v3.
>
> https://www.spinics.net/lists/linux-acpi/msg78487.html
> >>>
> >>>
> >>> I asked to split cache/topology since I am not familiar with cache
> >>> code and Sudeep - who looks after the cache code - won't be able to
> >>> review this series in time for v4.16.
> >>
> >>
> >> OK, so why do we need it in 4.16?
> >
> >
> > I think its more case of as soon as possible. That is because there
> > are machines where the topology is completely incorrect due to
> > assumptions the kernel makes based on registers that aren't defined
> > for that purpose (say describing which cores are in a physical socket,
> > or LLC's attached to interconnects or memory controllers).
> >
> > This incorrect topology information is reported to things like the
> > kernel scheduler, which then makes poor scheduling decisions resulting
> > in sub-optimal system performance.
> >
> > This patchset (and ACPI 6.2) clears up a lot of those problems.
>
> As long as the ACPI tables are as expected that is, I suppose?
>
> Anyway, fair enough, but I don't want to rush it in.
>
> Thanks,
> Rafael
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infrade
Re: [PATCH v2 1/9] dt-bindings: media: Add Renesas CEU bindings
Hi Laurent,
On Tue, Jan 02, 2018 at 01:45:30PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 28 December 2017 16:01:13 EET Jacopo Mondi wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../devicetree/bindings/media/renesas,ceu.txt | 85 +++
> > 1 file changed, 85 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > b/Documentation/devicetree/bindings/media/renesas,ceu.txt new file mode
> > 100644
> > index 000..f45628e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > @@ -0,0 +1,85 @@
> > +Renesas Capture Engine Unit (CEU)
> > +--
> > +
> > +The Capture Engine Unit is the image capture interface found on Renesas
> > +RZ chip series and on SH Mobile ones.
>
> "ones" sound a bit weird. How about "... found in the Renesas SH Mobil and RZ
> SoCs." ?
>
> > +The interface supports a single parallel input with data bus width up to
> > +8/16 bits.
>
> What do you mean by "up to 8/16 bits" ?
The input bus width can be 8 or 16 bit.
On a general note: I always assumed DT bindings should describe the
hardware capabilities. In this case the hardware supports 8 or 16 bits
as input width, but the driver only cares about the 8 bits case. Which
one should I describe here?
I will fix all of yours and Geert's remarks in V3.
Thanks
j
>
> > +Required properties:
> > +- compatible
> > + Must be one of:
> > + - "renesas,ceu"
> > + - "renesas,r7s72100-ceu"
>
> This is unclear, as Geert pointed out renesas,ceu sounds like a fallback. I
> think this could be clarified if you explained how you plan to support other
> SoCs (in particular the SH Mobile series, when/if it will receive DT support).
>
> > +- reg
> > + Physical address base and size.
>
> The standard practice, if I'm not mistaken, is to document properties with the
> description starting on the same line as the property name.
>
> - reg: Physical address base and size.
>
> And nitpicking again, I'd write "register" instead of "physical" to clarify
> what the properties contains (even if its name should make it clear).
>
> > +- interrupts
> > + The interrupt specifier.
> > +- pinctrl-names, pinctrl-0
> > + phandle of pin controller sub-node configuring pins for CEU operations.
>
> pinctrl-names isn't a phandle. If you want to document those properties (not
> all DT bindings do, I'm not sure what is best) you should document them both,
> possibly on two separate lines. There are plenty of examples in the upstream
> DT bindings.
>
> > +- remote-endpoint
> > + phandle to an 'endpoint' subnode of a remote device node.
>
> As Geert pointed out this isn't a top-level property. I wouldn't document it
> as such, but instead reference Documentation/devicetree/bindings/media/video-
> interfaces.txt (see Documentation/devicetree/bindings/display/renesas,du.txt
> or Documentation/devicetree/bindings/media/renesas,drif.txt for examples).
>
> > +CEU supports a single parallel input and should contain a single 'port'
>
> s/CEU/The CEU/
>
> > subnode
> > +with a single 'endpoint'. Optional endpoint properties applicable to
> > parallel
> > +input bus described in "video-interfaces.txt" supported by this driver are:
> > +
> > +- hsync-active
> > + active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
> > +- vsync-active
> > + active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
> > +
> > +Example:
> > +
> > +The example describes the connection between the Capture Engine Unit and an
> > +OV7670 image sensor sitting on bus i2c1.
>
> Maybe s/sitting on/connected to/ ?
>
> > +ceu: ceu@e821 {
> > + reg = <0xe821 0x209c>;
> > + compatible = "renesas,ceu";
> > + interrupts = ;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + status = "okay";
> > +
> > + port {
> > + ceu_in: endpoint {
> > + remote-endpoint = <&ov7670_out>;
> > +
> > + hsync-active = <1>;
> > + vsync-active = <0>;
> > + };
> > + };
> > +};
> > +
> > +i2c1: i2c@fcfee400 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1_pins>;
> > +
> > + status = "okay";
> > +
> > + clock-frequency = <10>;
> > +
> > + ov7670: camera@21 {
> > + compatible = "ovti,ov7670";
> > + reg = <0x21>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> > + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + ov7670_out: endpoint {
> > + remote-endpoint = <&ceu_in>;
> > +
> > + hsync
[PATCH RESEND] phy: sun4i-usb: add support for R40 USB PHY
Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
Add support for it.
Signed-off-by: Icenowy Zheng
Acked-by: Maxime Ripard
Acked-by: Rob Herring
---
When resending, the ACK's by Maxime and Rob are added.
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
drivers/phy/allwinner/phy-sun4i-usb.c | 12
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index c1ce5a0a652e..07ca4ec4a745 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -11,6 +11,7 @@ Required properties:
* allwinner,sun8i-a33-usb-phy
* allwinner,sun8i-a83t-usb-phy
* allwinner,sun8i-h3-usb-phy
+ * allwinner,sun8i-r40-usb-phy
* allwinner,sun8i-v3s-usb-phy
* allwinner,sun50i-a64-usb-phy
- reg : a list of offset + length pairs
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index aa857be692cf..bee798892b21 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -112,6 +112,7 @@ enum sun4i_usb_phy_type {
sun8i_a33_phy,
sun8i_a83t_phy,
sun8i_h3_phy,
+ sun8i_r40_phy,
sun8i_v3s_phy,
sun50i_a64_phy,
};
@@ -919,6 +920,16 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.phy0_dual_route = true,
};
+static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
+ .num_phys = 3,
+ .type = sun8i_r40_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .enable_pmu_unk1 = true,
+ .phy0_dual_route = true,
+};
+
static const struct sun4i_usb_phy_cfg sun8i_v3s_cfg = {
.num_phys = 1,
.type = sun8i_v3s_phy,
@@ -948,6 +959,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] =
{
{ .compatible = "allwinner,sun8i-a33-usb-phy", .data = &sun8i_a33_cfg },
{ .compatible = "allwinner,sun8i-a83t-usb-phy", .data = &sun8i_a83t_cfg
},
{ .compatible = "allwinner,sun8i-h3-usb-phy", .data = &sun8i_h3_cfg },
+ { .compatible = "allwinner,sun8i-r40-usb-phy", .data = &sun8i_r40_cfg },
{ .compatible = "allwinner,sun8i-v3s-usb-phy", .data = &sun8i_v3s_cfg },
{ .compatible = "allwinner,sun50i-a64-usb-phy",
.data = &sun50i_a64_cfg},
--
2.14.2
Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations
On 01/02/2018 10:09 PM, Matthew Wilcox wrote:
On Fri, Dec 22, 2017 at 04:49:11PM +0800, Wei Wang wrote:
Thanks for the improvement. I also found a small bug in xb_zero. With the
following changes, it has passed the current test cases and tested with the
virtio-balloon usage without any issue.
Thanks; I applied the change. Can you supply a test-case for testing
xb_zero please?
Sure. Please check below the test cases. Do you plan to send out the new
version of xbitmap yourself? If so, I will wait for that to send out the
virtio-balloon patches.
static void xbitmap_check_zero_bits(void)
{
assert(xb_empty(&xb1));
/* Zero an empty xbitmap should work though no real work to do */
xb_zero(&xb1, 0, ULONG_MAX);
assert(xb_empty(&xb1));
xb_preload(GFP_KERNEL);
assert(xb_set_bit(&xb1, 0) == 0);
xb_preload_end();
/* Overflow test */
xb_zero(&xb1, ULONG_MAX - 10, ULONG_MAX);
assert(xb_test_bit(&xb1, 0));
xb_preload(GFP_KERNEL);
assert(xb_set_bit(&xb1, ULONG_MAX) == 0);
xb_preload_end();
xb_zero(&xb1, 0, ULONG_MAX);
assert(xb_empty(&xb1));
}
/*
* In the following tests, preload is called once when all the bits to set
* locate in the same ida bitmap. Otherwise, it is recommended to call
* preload for each xb_set_bit.
*/
static void xbitmap_check_bit_range(void)
{
unsigned long nbit = 0;
/* Regular test1: node = NULL */
xb_preload(GFP_KERNEL);
xb_set_bit(&xb1, 700);
xb_preload_end();
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true);
assert(nbit == 700);
nbit++;
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == false);
assert(nbit == 701);
xb_zero(&xb1, 0, 1023);
/*
* Regular test2
* set bit 2000, 2001, 2040
* Next 1 in [0, 2048] --> 2000
* Next 1 in [2000, 2002] --> 2000
* Next 1 in [2002, 2040] --> 2040
* Next 1 in [2002, 2039] --> none
* Next 0 in [2000, 2048] --> 2002
* Next 0 in [2048, 2060] --> 2048
*/
xb_preload(GFP_KERNEL);
assert(!xb_set_bit(&xb1, 2000));
assert(!xb_set_bit(&xb1, 2001));
assert(!xb_set_bit(&xb1, 2040));
nbit = 0;
assert(xb_find_set(&xb1, 2048, &nbit) == true);
assert(nbit == 2000);
assert(xb_find_set(&xb1, 2002, &nbit) == true);
assert(nbit == 2000);
nbit = 2002;
assert(xb_find_set(&xb1, 2040, &nbit) == true);
assert(nbit == 2040);
nbit = 2002;
assert(xb_find_set(&xb1, 2039, &nbit) == false);
assert(nbit == 2002);
nbit = 2000;
assert(xb_find_zero(&xb1, 2048, &nbit) == true);
assert(nbit == 2002);
nbit = 2048;
assert(xb_find_zero(&xb1, 2060, &nbit) == true);
assert(nbit == 2048);
xb_zero(&xb1, 0, 2048);
nbit = 0;
assert(xb_find_set(&xb1, 2048, &nbit) == false);
assert(nbit == 0);
xb_preload_end();
/*
* Overflow tests:
* Set bit 1 and ULONG_MAX - 4
* Next 1 in [0, ULONG_MAX] --> 1
* Next 1 in [1, ULONG_MAX] --> 1
* Next 1 in [2, ULONG_MAX] --> ULONG_MAX - 4
* Next 1 in [ULONG_MAX - 3, 2] --> none
* Next 0 in [ULONG_MAX - 4, ULONG_MAX] --> ULONG_MAX - 3
* Zero [ULONG_MAX - 4, ULONG_MAX]
* Next 1 in [ULONG_MAX - 10, ULONG_MAX]--> none
* Next 1 in [ULONG_MAX - 1, 2] --> none
* Zero [0, 1]
* Next 1 in [0, 2] --> none
*/
xb_preload(GFP_KERNEL);
assert(!xb_set_bit(&xb1, 1));
xb_preload_end();
xb_preload(GFP_KERNEL);
assert(!xb_set_bit(&xb1, ULONG_MAX - 4));
nbit = 0;
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true);
assert(nbit == 1);
nbit = 1;
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true);
assert(nbit == 1);
nbit = 2;
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true);
assert(nbit == ULONG_MAX - 4);
nbit++;
assert(xb_find_set(&xb1, 2, &nbit) == false);
assert(nbit == ULONG_MAX - 3);
nbit--;
assert(xb_find_zero(&xb1, ULONG_MAX, &nbit) == true);
assert(nbit == ULONG_MAX - 3);
xb_zero(&xb1, ULONG_MAX - 4, ULONG_MAX);
nbit = ULONG_MAX - 10;
assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == false);
assert(nbit == ULONG_MAX - 10);
nbit = ULONG_MAX - 1;
assert(xb_find_set(&xb1, 2, &nbit) == false);
xb_zero(&xb1, 0, 1);
nbit = 0;
assert(xb_find_set(&xb1, 2, &nbit) == false);
assert(nbit == 0);
xb_preload_end();
assert(xb_empty(&xb1));
}
Be
Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
On 01/03/2018 10:29 AM, Tetsuo Handa wrote: Matthew Wilcox wrote: The radix tree convention is objectively awful, which is why I'm working to change it. Specifying the GFP flags at radix tree initialisation time rather than allocation time leads to all kinds of confusion. The preload API is a pretty awful workaround, and it will go away once the XArray is working correctly. That said, there's no alternative to it without making XBitmap depend on XArray, and I don't want to hold you up there. So there's an xb_preload for the moment. I'm ready to propose cvbmp shown below as an alternative to xbitmap (but specialized for virtio-balloon case). Wei, can you do some benchmarking between xbitmap and cvbmp? cvbmp: clustered values bitmap I don't think we need to replace xbitmap, at least at this stage. The new implementation doesn't look simpler at all, and virtio-balloon has worked well with xbitmap. I would suggest you to send out the new implementation for discussion after this series ends, and justify with better performance results if you could get. Best, Wei
Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move
On Wed 03-01-18 14:12:17, Anshuman Khandual wrote:
> On 12/08/2017 09:45 PM, Michal Hocko wrote:
[...]
> > @@ -986,7 +987,7 @@ static int migrate_to_node(struct mm_struct *mm, int
> > source, int dest,
> > flags | MPOL_MF_DISCONTIG_OK, &pagelist);
> >
> > if (!list_empty(&pagelist)) {
> > - err = migrate_pages(&pagelist, new_node_page, NULL, dest,
> > + err = migrate_pages(&pagelist, alloc_new_node_page, NULL, dest,
> > MIGRATE_SYNC, MR_SYSCALL);
> > if (err)
> > putback_movable_pages(&pagelist);
>
> This reuses the existing page allocation helper from migrate_pages() system
> call. But all these allocator helper names for migrate_pages() function are
> really confusing. Even in this case alloc_new_node_page and the original
> new_node_page() which is still getting used in do_migrate_range() sounds
> similar even if their implementation is quite different. IMHO either all of
> them should be moved to the header file with proper differentiating names
> or let them be there in their respective files with these generic names and
> clean them up later.
I believe I've tried that but I couldn't make them into a single header
file easily because of header file dependencies. I agree that their
names are quite confusing. Feel free to send a patch to clean this up.
>
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 4d0be47a322a..9d7252ea2acd 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -1444,141 +1444,104 @@ int migrate_pages(struct list_head *from,
> > new_page_t get_new_page,
> > }
> >
> > #ifdef CONFIG_NUMA
> > -/*
> > - * Move a list of individual pages
> > - */
> > -struct page_to_node {
> > - unsigned long addr;
> > - struct page *page;
> > - int node;
> > - int status;
> > -};
> >
> > -static struct page *new_page_node(struct page *p, unsigned long private,
> > - int **result)
> > +static int store_status(int __user *status, int start, int value, int nr)
> > {
> > - struct page_to_node *pm = (struct page_to_node *)private;
> > -
> > - while (pm->node != MAX_NUMNODES && pm->page != p)
> > - pm++;
> > + while (nr-- > 0) {
> > + if (put_user(value, status + start))
> > + return -EFAULT;
> > + start++;
> > + }
> >
> > - if (pm->node == MAX_NUMNODES)
> > - return NULL;
> > + return 0;
> > +}
>
>
> Just a nit. new_page_node() and store_status() seems different. Then why
> the git diff looks so clumsy.
Kirill was suggesting to use --patience to general the diff which leads
to a slightly better output. It has been posted as a separate email [1].
Maybe you will find that one easier to review.
[1] http://lkml.kernel.org/r/20171213143948.gm25...@dhcp22.suse.cz
> >
> > - *result = &pm->status;
> > +static int do_move_pages_to_node(struct mm_struct *mm,
> > + struct list_head *pagelist, int node)
> > +{
> > + int err;
> >
> > - if (PageHuge(p))
> > - return alloc_huge_page_node(page_hstate(compound_head(p)),
> > - pm->node);
> > - else if (thp_migration_supported() && PageTransHuge(p)) {
> > - struct page *thp;
> > + if (list_empty(pagelist))
> > + return 0;
> >
> > - thp = alloc_pages_node(pm->node,
> > - (GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
> > - HPAGE_PMD_ORDER);
> > - if (!thp)
> > - return NULL;
> > - prep_transhuge_page(thp);
> > - return thp;
> > - } else
> > - return __alloc_pages_node(pm->node,
> > - GFP_HIGHUSER_MOVABLE | __GFP_THISNODE, 0);
> > + err = migrate_pages(pagelist, alloc_new_node_page, NULL, node,
> > + MIGRATE_SYNC, MR_SYSCALL);
> > + if (err)
> > + putback_movable_pages(pagelist);
> > + return err;
> > }
>
> Even this one. IIUC, do_move_pages_to_node() migrate a chunk of pages
> at a time which belong to the same target node. Perhaps the name should
> suggest so. All these helper page migration helper functions sound so
> similar.
What do you suggest? I find do_move_pages_to_node quite explicit on its
purpose.
> > /*
> > - * Move a set of pages as indicated in the pm array. The addr
> > - * field must be set to the virtual address of the page to be moved
> > - * and the node number must contain a valid target node.
> > - * The pm array ends with node = MAX_NUMNODES.
> > + * Resolves the given address to a struct page, isolates it from the LRU
> > and
> > + * puts it to the given pagelist.
> > + * Returns -errno if the page cannot be found/isolated or 0 when it has
> > been
> > + * queued or the page doesn't need to be migrated because it is already on
> > + * the target node
> > */
> > -static int do_move_page_to_node_array(struct mm_struct *mm,
> > - str
[v2 PATCH 1/6] usb: mtu3: fix error code for getting extcon device
When failing to get extcon device, extcon_get_edev_by_phandle()
may return different error codes, but not only -EPROBE_DEFER,
so can't always return -EPROBE_DEFER, and fix it.
Signed-off-by: Chunfeng Yun
---
drivers/usb/mtu3/mtu3_plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 3650fd1..5b2110b 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -308,7 +308,7 @@ static int get_ssusb_rscs(struct platform_device *pdev,
struct ssusb_mtk *ssusb)
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
- return -EPROBE_DEFER;
+ return PTR_ERR(otg_sx->edev);
}
}
--
1.9.1
[v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties
Add two arguments in "mediatek,syscon-wakeup" to support multi
wakeup glue layer between SSUSB and SPM, and use standard property
"wakeup-source" to replace the private "mediatek,enable-wakeup"
Signed-off-by: Chunfeng Yun
---
Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index b2271d8..d589a1e 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -42,9 +42,14 @@ Optional properties:
- enable-manual-drd : supports manual dual-role switch via debugfs; usually
used when receptacle is TYPE-A and also wants to support dual-role
mode.
- - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,enable-wakeup".
+ - wakeup-source: enable USB remote wakeup of host mode.
+ - mediatek,syscon-wakeup : phandle to syscon used to access the register
+ of the USB wakeup glue layer between SSUSB and SPM; it depends on
+ "wakeup-source", and has two arguments:
+ - the first one : register base address of the glue layer in syscon;
+ - the second one : hardware version of the glue layer
+ - 1 : used by mt8173 etc
+ - 2 : used by mt2712 etc
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
@@ -71,8 +76,8 @@ ssusb: usb@11271000 {
vbus-supply = <&usb_p0_vbus>;
extcon = <&extcon_usb>;
dr_mode = "otg";
- mediatek,enable-wakeup;
- mediatek,syscon-wakeup = <&pericfg>;
+ wakeup-source;
+ mediatek,syscon-wakeup = <&pericfg 0x400 1>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
1.9.1
[v2 PATCH 6/6] arm64: dts: mt8173: update properties about USB wakeup
Use new binding about USB wakeup which now supports multi USB wakeup glue layer between SSUSB and SPM. Meanwhile remove dummy clocks of USB wakeup. Signed-off-by: Chunfeng Yun --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 2 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12 +++- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index 1c3634f..0acba1f 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -505,7 +505,7 @@ vbus-supply = <&usb_p0_vbus>; extcon = <&extcon_usb>; dr_mode = "otg"; - mediatek,enable-wakeup; + wakeup-source; pinctrl-names = "default", "id_float", "id_ground"; pinctrl-0 = <&usb_id_pins_float>; pinctrl-1 = <&usb_id_pins_float>; diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index 26396ef..9263d9f 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi @@ -731,15 +731,9 @@ <&u3port0 PHY_TYPE_USB3>, <&u2port1 PHY_TYPE_USB2>; power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>; - clocks = <&topckgen CLK_TOP_USB30_SEL>, -<&clk26m>, -<&pericfg CLK_PERI_USB0>, -<&pericfg CLK_PERI_USB1>; - clock-names = "sys_ck", - "ref_ck", - "wakeup_deb_p0", - "wakeup_deb_p1"; - mediatek,syscon-wakeup = <&pericfg>; + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; + clock-names = "sys_ck", "ref_ck"; + mediatek,syscon-wakeup = <&pericfg 0x400 1>; #address-cells = <2>; #size-cells = <2>; ranges; -- 1.9.1
[v2 PATCH 2/6] usb: mtu3: supports remote wakeup for mt2712 with two SSUSB IPs
The old way of usb wakeup only supports platform with single SSUSB IP,
such as mt8173, but mt2712 has two SSUSB IPs, so rebuild its flow and
also supports the new glue layer of usb wakeup on mt2712 which is
different from mt8173.
Signed-off-by: Chunfeng Yun
---
drivers/usb/mtu3/mtu3.h | 11 +++--
drivers/usb/mtu3/mtu3_dr.h | 3 +-
drivers/usb/mtu3/mtu3_host.c | 115 +--
drivers/usb/mtu3/mtu3_plat.c | 8 +--
4 files changed, 70 insertions(+), 67 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 3c888d9..2cd00a2 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -229,7 +229,10 @@ struct otg_switch_mtk {
* @u3p_dis_msk: mask of disabling usb3 ports, for example, bit0==1 to
* disable u3port0, bit1==1 to disable u3port1,... etc
* @dbgfs_root: only used when supports manual dual-role switch via debugfs
- * @wakeup_en: it's true when supports remote wakeup in host mode
+ * @uwk_en: it's true when supports remote wakeup in host mode
+ * @uwk: syscon including usb wakeup glue layer between SSUSB IP and SPM
+ * @uwk_reg_base: the base address of the wakeup glue layer in @uwk
+ * @uwk_vers: the version of the wakeup glue layer
*/
struct ssusb_mtk {
struct device *dev;
@@ -253,8 +256,10 @@ struct ssusb_mtk {
int u3p_dis_msk;
struct dentry *dbgfs_root;
/* usb wakeup for host mode */
- bool wakeup_en;
- struct regmap *pericfg;
+ bool uwk_en;
+ struct regmap *uwk;
+ u32 uwk_reg_base;
+ u32 uwk_vers;
};
/**
diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
index c179192..ae1598d 100644
--- a/drivers/usb/mtu3/mtu3_dr.h
+++ b/drivers/usb/mtu3/mtu3_dr.h
@@ -18,8 +18,7 @@ int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn);
int ssusb_host_enable(struct ssusb_mtk *ssusb);
int ssusb_host_disable(struct ssusb_mtk *ssusb, bool suspend);
-int ssusb_wakeup_enable(struct ssusb_mtk *ssusb);
-void ssusb_wakeup_disable(struct ssusb_mtk *ssusb);
+void ssusb_wakeup_set(struct ssusb_mtk *ssusb, bool enable);
#else
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index d237d7e..259beef 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -18,66 +18,77 @@
#include "mtu3.h"
#include "mtu3_dr.h"
-#define PERI_WK_CTRL1 0x404
-#define UWK_CTL1_IS_C(x) (((x) & 0xf) << 26)
-#define UWK_CTL1_IS_E BIT(25)
-#define UWK_CTL1_IDDIG_C(x)(((x) & 0xf) << 11) /* cycle debounce */
-#define UWK_CTL1_IDDIG_E BIT(10) /* enable debounce */
-#define UWK_CTL1_IDDIG_P BIT(9) /* polarity */
-#define UWK_CTL1_IS_P BIT(6) /* polarity for ip sleep */
+/* mt8173 etc */
+#define PERI_WK_CTRL1 0x4
+#define WC1_IS_C(x)(((x) & 0xf) << 26) /* cycle debounce */
+#define WC1_IS_EN BIT(25)
+#define WC1_IS_P BIT(6) /* polarity for ip sleep */
+
+/* mt2712 etc */
+#define PERI_SSUSB_SPM_CTRL0x0
+#define SSC_IP_SLEEP_ENBIT(4)
+#define SSC_SPM_INT_EN BIT(1)
+
+enum ssusb_uwk_vers {
+ SSUSB_UWK_V1 = 1,
+ SSUSB_UWK_V2,
+};
/*
* ip-sleep wakeup mode:
* all clocks can be turn off, but power domain should be kept on
*/
-static void ssusb_wakeup_ip_sleep_en(struct ssusb_mtk *ssusb)
+static void ssusb_wakeup_ip_sleep_set(struct ssusb_mtk *ssusb, bool enable)
{
- u32 tmp;
- struct regmap *pericfg = ssusb->pericfg;
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_P;
- tmp &= ~(UWK_CTL1_IS_C(0xf));
- tmp |= UWK_CTL1_IS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_IS_E);
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- dev_dbg(ssusb->dev, "%s(): WK_CTRL1[P6,E25,C26:29]=%#x\n",
- __func__, tmp);
-}
-
-static void ssusb_wakeup_ip_sleep_dis(struct ssusb_mtk *ssusb)
-{
- u32 tmp;
-
- regmap_read(ssusb->pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_E;
- regmap_write(ssusb->pericfg, PERI_WK_CTRL1, tmp);
+ u32 reg, msk, val;
+
+ switch (ssusb->uwk_vers) {
+ case SSUSB_UWK_V1:
+ reg = ssusb->uwk_reg_base + PERI_WK_CTRL1;
+ msk = WC1_IS_EN | WC1_IS_C(0xf) | WC1_IS_P;
+ val = enable ? (WC1_IS_EN | WC1_IS_C(0x8)) : 0;
+ break;
+ case SSUSB_UWK_V2:
+ reg = ssusb->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
+ default:
+ return;
+ };
+ regmap_update_bits(ssusb->uwk, reg, msk, val);
}
int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn)
{
- struct device *dev = ssusb->
[v2 PATCH 4/6] usb: xhci-mtk: supports remote wakeup for mt2712 with two xHCI IPs
The old way of usb wakeup only supports platform with single xHCI IP,
such as mt8173, but mt2712 has two xHCI IPs, so rebuild its flow and
supports the new glue layer of usb wakeup on mt2712 which is different
from mt8173.
Due to there is a hardware bug with the LINE STATE wakeup mode on
mt8173 which causes wakeup failure by low speed devices, and also
because IP SLEEP mode can cover all functions of LINE STATE mode,
it is unused in fact, and will not support it later, so remove it at
the same time.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 177 +++-
drivers/usb/host/xhci-mtk.h | 6 +-
2 files changed, 65 insertions(+), 118 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b62a1d2..53187ff 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -57,26 +57,21 @@
/* u2_phy_pll register */
#define CTRL_U2_FORCE_PLL_STB BIT(28)
-#define PERI_WK_CTRL0 0x400
-#define UWK_CTR0_0P_LS_PE BIT(8) /* posedge */
-#define UWK_CTR0_0P_LS_NE BIT(7) /* negedge for 0p linestate*/
-#define UWK_CTL1_1P_LS_C(x)(((x) & 0xf) << 1)
-#define UWK_CTL1_1P_LS_E BIT(0)
-
-#define PERI_WK_CTRL1 0x404
-#define UWK_CTL1_IS_C(x) (((x) & 0xf) << 26)
-#define UWK_CTL1_IS_E BIT(25)
-#define UWK_CTL1_0P_LS_C(x)(((x) & 0xf) << 21)
-#define UWK_CTL1_0P_LS_E BIT(20)
-#define UWK_CTL1_IDDIG_C(x)(((x) & 0xf) << 11) /* cycle debounce */
-#define UWK_CTL1_IDDIG_E BIT(10) /* enable debounce */
-#define UWK_CTL1_IDDIG_P BIT(9) /* polarity */
-#define UWK_CTL1_0P_LS_P BIT(7)
-#define UWK_CTL1_IS_P BIT(6) /* polarity for ip sleep */
-
-enum ssusb_wakeup_src {
- SSUSB_WK_IP_SLEEP = 1,
- SSUSB_WK_LINE_STATE = 2,
+/* usb remote wakeup registers in syscon */
+/* mt8173 etc */
+#define PERI_WK_CTRL1 0x4
+#define WC1_IS_C(x)(((x) & 0xf) << 26) /* cycle debounce */
+#define WC1_IS_EN BIT(25)
+#define WC1_IS_P BIT(6) /* polarity for ip sleep */
+
+/* mt2712 etc */
+#define PERI_SSUSB_SPM_CTRL0x0
+#define SSC_IP_SLEEP_ENBIT(4)
+#define SSC_SPM_INT_EN BIT(1)
+
+enum ssusb_uwk_vers {
+ SSUSB_UWK_V1 = 1,
+ SSUSB_UWK_V2,
};
static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
@@ -296,112 +291,58 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk
*mtk)
}
/* only clocks can be turn off for ip-sleep wakeup mode */
-static void usb_wakeup_ip_sleep_en(struct xhci_hcd_mtk *mtk)
+static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk *mtk, bool enable)
{
- u32 tmp;
- struct regmap *pericfg = mtk->pericfg;
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_P;
- tmp &= ~(UWK_CTL1_IS_C(0xf));
- tmp |= UWK_CTL1_IS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_IS_E);
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- dev_dbg(mtk->dev, "%s(): WK_CTRL1[P6,E25,C26:29]=%#x\n",
- __func__, tmp);
+ u32 reg, msk, val;
+
+ switch (mtk->uwk_vers) {
+ case SSUSB_UWK_V1:
+ reg = mtk->uwk_reg_base + PERI_WK_CTRL1;
+ msk = WC1_IS_EN | WC1_IS_C(0xf) | WC1_IS_P;
+ val = enable ? (WC1_IS_EN | WC1_IS_C(0x8)) : 0;
+ break;
+ case SSUSB_UWK_V2:
+ reg = mtk->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
+ default:
+ return;
+ };
+ regmap_update_bits(mtk->uwk, reg, msk, val);
}
-static void usb_wakeup_ip_sleep_dis(struct xhci_hcd_mtk *mtk)
+static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
+ struct device_node *dn)
{
- u32 tmp;
+ struct of_phandle_args args;
+ int ret;
- regmap_read(mtk->pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_E;
- regmap_write(mtk->pericfg, PERI_WK_CTRL1, tmp);
-}
+ /* Wakeup function is optional */
+ mtk->uwk_en = of_property_read_bool(dn, "wakeup-source");
+ if (!mtk->uwk_en)
+ return 0;
-/*
-* for line-state wakeup mode, phy's power should not power-down
-* and only support cable plug in/out
-*/
-static void usb_wakeup_line_state_en(struct xhci_hcd_mtk *mtk)
-{
- u32 tmp;
- struct regmap *pericfg = mtk->pericfg;
-
- /* line-state of u2-port0 */
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_0P_LS_P;
- tmp &= ~(UWK_CTL1_0P_LS_C(0xf));
- tmp |= UWK_CTL1_0P_LS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_0P_LS_E);
-
- /* line-state of u2-port1 */
- regmap_read(pericfg
Re: [PATCH v2 2/9] include: media: Add Renesas CEU driver interface
Hi Laurent,
On Tue, Jan 02, 2018 at 01:50:07PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 28 December 2017 16:01:14 EET Jacopo Mondi wrote:
> > Add renesas-ceu header file.
> >
> > Do not remove the existing sh_mobile_ceu.h one as long as the original
> > driver does not go away.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > include/media/drv-intf/renesas-ceu.h | 20
> > 1 file changed, 20 insertions(+)
> > create mode 100644 include/media/drv-intf/renesas-ceu.h
> >
> > diff --git a/include/media/drv-intf/renesas-ceu.h
> > b/include/media/drv-intf/renesas-ceu.h new file mode 100644
> > index 000..7470c3f
> > --- /dev/null
> > +++ b/include/media/drv-intf/renesas-ceu.h
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0+
>
> Just out of curiosity, any reason you have picked GPL-2.0+ and not GPL-2.0 ?
Good question. I would mention lazyness in copying the SPDX identifier
from somewhere else and overlooking the license version reported
there. I don't have any personal preference on GPLv3 I was trying to
squeeze in :)
I'll switch it back to GPL-2.0 only
>
> You might want to add a copyright header to state copyright ownership
>
> /**
> * renesas-ceu.h - Renesas CEU driver interface
> *
> * Copyright 2017-2018 Jacopo Mondi
> */
>
> That's up to you.
>
> > +#ifndef __ASM_RENESAS_CEU_H__
>
> Maybe __MEDIA_DRV_INTF_RENESAS_CEU_H__ ?
>
> > +#define __ASM_RENESAS_CEU_H__
> > +
> > +#define CEU_MAX_SUBDEVS2
> > +
> > +struct ceu_async_subdev {
> > + unsigned long flags;
> > + unsigned char bus_width;
> > + unsigned char bus_shift;
> > + unsigned int i2c_adapter_id;
> > + unsigned int i2c_address;
> > +};
> > +
> > +struct ceu_info {
>
> This is really platform data, how about calling it ceu_platform_data ?
>
> > + unsigned int num_subdevs;
> > + struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
> > +};
> > +
> > +#endif /* __ASM_RENESAS_CEU_H__ */
>
> Don't forget to update the comment here too.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
Thanks
j
>
> --
> Regards,
>
> Laurent Pinchart
>
[v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties
Add two arguments in "mediatek,syscon-wakeup" to support multi
wakeup glue layer between SSUSB and SPM, and use standard property
"wakeup-source" to replace the private "mediatek,wakeup-src"
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/usb/mediatek,mtk-xhci.txt| 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 3059596..5842868 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -35,10 +35,14 @@ Required properties:
- phys : a list of phandle + phy specifier pairs
Optional properties:
- - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
- mode;
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,wakeup-src".
+ - wakeup-source : enable USB remote wakeup;
+ - mediatek,syscon-wakeup : phandle to syscon used to access the register
+ of the USB wakeup glue layer between xHCI and SPM; it depends on
+ "wakeup-source", and has two arguments:
+ - the first one : register base address of the glue layer in syscon;
+ - the second one : hardware version of the glue layer
+ - 1 : used by mt8173 etc
+ - 2 : used by mt2712 etc
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
- vbus-supply : reference to the VBUS regulator;
@@ -64,8 +68,8 @@ usb30: usb@1127 {
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p1_vbus>;
usb3-lpm-capable;
- mediatek,syscon-wakeup = <&pericfg>;
- mediatek,wakeup-src = <1>;
+ mediatek,syscon-wakeup = <&pericfg 0x400 1>;
+ wakeup-source;
};
2nd: dual-role mode with xHCI driver
--
1.9.1
RE: [LINUX PATCH 3/4] dmaengine: xilinx_dma: Fix compilation warning
Hi, >>> >BTW whats with LINUX tag in patches, pls drop them >>> >>> Ok will mention the Linux tag info in the cover letter patch from the >>> next patch series on wards... >> >>Please wrap your replies within 80chars. It is very hard to read! I have >>reflown >for >>readability > >Sure will take care of it next time onwards... > >> >>Can you explain what you mean by that info, what are you trying to convey? > >What I mean here is will mention the Linux kernel tag >Information in the cover letter patch... Oops sorry I misunderstood your comment... In my company we have internally different projects To differentiate b/w them we usually use LINUX prefix By mistake I have added the LINUX prefix in this patch series I have removed it in the v2 series... Regards, Kedar. > >Regards, >Kedar. > >> >>-- >>~Vinod
Re: [PATCH 2/3] mm, migrate: remove reason argument from new_page_t
Ups, this one is missing so it should be foleded in.
---
>From a6f412a700a20ffee3ff3839eae8a0f891332f8a Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 3 Jan 2018 10:00:16 +0100
Subject: [PATCH] fold me "mm, migrate: remove reason argument from new_page_t"
- fix new_iommu_non_cma_page leftover
---
arch/powerpc/mm/mmu_context_iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_iommu.c
b/arch/powerpc/mm/mmu_context_iommu.c
index e0a2d8e806ed..91ee2231c527 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -75,8 +75,7 @@ EXPORT_SYMBOL_GPL(mm_iommu_preregistered);
/*
* Taken from alloc_migrate_target with changes to remove CMA allocations
*/
-struct page *new_iommu_non_cma_page(struct page *page, unsigned long private,
- int **resultp)
+struct page *new_iommu_non_cma_page(struct page *page, unsigned long private)
{
gfp_t gfp_mask = GFP_USER;
struct page *new_page;
--
2.15.1
--
Michal Hocko
SUSE Labs
Re: [PATCH] vhost: remove unused lock check flag in vhost_dev_cleanup()
On 2017年12月25日 00:08, 夷则(Caspar) wrote:
In commit ea5d404655ba ("vhost: fix release path lockdep checks"),
Michael added a flag to check whether we should hold a lock in
vhost_dev_cleanup(), however, in commit 47283bef7ed3 ("vhost: move
memory pointer to VQs"), RCU operations have been replaced by
mutex, we can remove the no-longer-used `locked' parameter now.
Signed-off-by: Caspar Zhang
---
drivers/vhost/net.c | 2 +-
drivers/vhost/scsi.c | 2 +-
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 5 ++---
drivers/vhost/vhost.h | 2 +-
drivers/vhost/vsock.c | 2 +-
6 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index c7bdeb655646..a354d8d731e3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -996,7 +996,7 @@ static int vhost_net_release(struct inode *inode, struct
file *f)
vhost_net_stop(n, &tx_sock, &rx_sock);
vhost_net_flush(n);
vhost_dev_stop(&n->dev);
- vhost_dev_cleanup(&n->dev, false);
+ vhost_dev_cleanup(&n->dev);
vhost_net_vq_reset(n);
if (tx_sock)
sockfd_put(tx_sock);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 71517b3c5558..797d08916553 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1420,7 +1420,7 @@ static int vhost_scsi_release(struct inode *inode, struct
file *f)
mutex_unlock(&vs->dev.mutex);
vhost_scsi_clear_endpoint(vs, &t);
vhost_dev_stop(&vs->dev);
- vhost_dev_cleanup(&vs->dev, false);
+ vhost_dev_cleanup(&vs->dev);
/* Jobs can re-queue themselves in evt kick handler. Do extra flush. */
vhost_scsi_flush(vs);
kfree(vs->dev.vqs);
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 3cc98c07dcd3..906b8f0f19f7 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -157,7 +157,7 @@ static int vhost_test_release(struct inode *inode, struct
file *f)
vhost_test_stop(n, &private);
vhost_test_flush(n);
- vhost_dev_cleanup(&n->dev, false);
+ vhost_dev_cleanup(&n->dev);
/* We do an extra flush before freeing memory,
* since jobs can re-queue themselves. */
vhost_test_flush(n);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 33ac2b186b85..014675c3d569 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -544,7 +544,7 @@ void vhost_dev_reset_owner(struct vhost_dev *dev, struct
vhost_umem *umem)
{
int i;
- vhost_dev_cleanup(dev, true);
+ vhost_dev_cleanup(dev);
/* Restore memory to default empty mapping. */
INIT_LIST_HEAD(&umem->umem_list);
@@ -611,8 +611,7 @@ static void vhost_clear_msg(struct vhost_dev *dev)
spin_unlock(&dev->iotlb_lock);
}
-/* Caller should have device mutex if and only if locked is set */
-void vhost_dev_cleanup(struct vhost_dev *dev, bool locked)
+void vhost_dev_cleanup(struct vhost_dev *dev)
{
int i;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 79c6e7a60a5e..ff4d918e3e0a 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -181,7 +181,7 @@ bool vhost_dev_has_owner(struct vhost_dev *dev);
long vhost_dev_check_owner(struct vhost_dev *);
struct vhost_umem *vhost_dev_reset_owner_prepare(void);
void vhost_dev_reset_owner(struct vhost_dev *, struct vhost_umem *);
-void vhost_dev_cleanup(struct vhost_dev *, bool locked);
+void vhost_dev_cleanup(struct vhost_dev *);
void vhost_dev_stop(struct vhost_dev *);
long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, void __user
*argp);
long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp);
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 5a5e981bd8e4..0d14e2ff19f1 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -599,7 +599,7 @@ static int vhost_vsock_dev_release(struct inode *inode,
struct file *file)
}
spin_unlock_bh(&vsock->send_pkt_list_lock);
- vhost_dev_cleanup(&vsock->dev, false);
+ vhost_dev_cleanup(&vsock->dev);
kfree(vsock->dev.vqs);
vhost_vsock_free(vsock);
return 0;
Acked-by: Jason Wang
Re: [PATCH v2 0/9] PCI: Add support to the Cadence PCIe controller
Hi, On Saturday 30 December 2017 02:23 AM, Cyrille Pitchen wrote: > Hi Kishon, > > Le 28/12/2017 à 14:00, Kishon Vijay Abraham I a écrit : >> Hi Cyrille, >> >> On Monday 18 December 2017 11:46 PM, Cyrille Pitchen wrote: >>> Hi all, >>> >>> this series of patches adds support to the Cadence PCIe controller. >>> It was tested on a ARM64 platform emulated by a Palladium running the >>> pci-next kernel. >>> >>> The host mode was tested with some PCIe devices connected to the Palladium >>> through a speed-bridge. Some of those devices were a USB host controller >>> and a SATA controller. The PCIe host controller was also tested with a >>> second controller configured in endpoint mode and connected back to back >>> to the first controller. >>> >>> The EndPoint Controller (EPC) driver of this series was tested with the >>> pci-epf-test.c EndPoint Function (EPF) driver and the pcitest userspace >>> program. >> >> Did you get to test multi function EP? >> > > No I didn't: I tested only with a single function to check for regression > but currently I'm not able to test with multiple functions. > > With devmem, I've tried to read then write the Physical Function Configuration > Register (offset 0x2c0 in the Local Management registers) to enable > functions other than function 0. > > This is the CDNS_PCIE_LM_EP_FUNC_CFG register that the pcie-cadence_ep.c > driver updates in cdns_pcie_ep_write_header() since v2 of the series. > > As written in the datasheet, BIT(0) is actually hard-wired to 1, hence > function 0 can't be disabled: that makes sense. However other function > enable bits were read as 0 whereas the datasheet claims they should be set > at power up. Besides, I can't set any of them with devmem. > > Actually, I have 2 slightly different datasheets, in the first one I should > have 4 functions but only 2 based on the second datasheet. > > Then I guess it's a design parameter used when synthesizing the controller. > > So I've asked Cadence whether I've missed or misunderstood something in the > datasheets or whether the IP they provided me with has a single function > for now. I'm waiting for their answers. hmm.. It would be nice to have multi function tested since it would both validate multi function support of PCI EP core and the cadence multi-function itself. Thanks Kishon
Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK
Hi Peter, On 22 December 2017 at 21:42, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 07:56:29PM +0100, Peter Zijlstra wrote: >> Right; but I figured we'd try and do it 'right' and see how horrible it >> is before we try and do funny things. > > So now it should have a 32ms tick for up to .5s when the system goes > completely idle. > > No idea how bad that is.. I have tested your branch but the timer doesn't seem to fire correctly because i can still see blocked load in the use case i have run. I haven't found the reason yet
Re: 4.15-rc6 PTI regression: L1 TLB mismatch MCE on Athlon64
> > > [ 316.384669] mce: [Hardware Error]: Machine check events logged > > > [ 316.384698] [Hardware Error]: Corrected error, no action required. > > > [ 316.384719] [Hardware Error]: CPU:0 (f:2f:2) > > > MC1_STATUS[-|CE|-|-|AddrV]: 0x94010011 > > > [ 316.384742] [Hardware Error]: Error Addr: 0x81e000e0 > > > > That's the [47:12] slice of the virtual address which it tried to execute. > > > > According to our map in mm.txt: > > > > 8000 - 87ff (=43 bits) guard hole, reserved for > > hypervisor > > > > vs > > > > 81e000e0... > > > > which makes me think: WTF now?! > > > > I don't see any hypervisor happening in dmesg... > > Meelis, can you please enable CONFIG_X86_PTDUMP. If you select M then > please load the resulting module 'debug_pagetables'. > > Then please do the following from a shell: > > # cat /sys/kernel/debug/page_tables/* >t.txt > > and provide the output. Here it is from 4.15.0-rc5-00184-ga9746e4089d6 (rc5 was OK). ---[ User Space ]--- 0x-0x5500 85T pgd 0x5500-0x555b4000 365G pud 0x555b4000-0x555b5180 280M pmd 0x555b5180-0x555b519810001540K pte 0x555b51981000-0x555b51989000 32K USR ro x pte 0x555b51989000-0x555b51b880002044K pte 0x555b51b88000-0x555b51b89000 4K USR ro NX pte 0x555b51b89000-0x555b51b8a000 4K USR RW NX pte 0x555b51b8a000-0x555b51c0 472K pte 0x555b51c0-0x555b53a0 30M pmd 0x555b53a0-0x555b53b21152K pte 0x555b53b2-0x555b53b22000 8K USR RW NX pte 0x555b53b22000-0x555b53c0 888K pte 0x555b53c0-0x555b8000 708M pmd 0x555b8000-0x5580 146G pud 0x5580-0x7f80 42T pgd 0x7f80-0x7fbb4000 237G pud 0x7fbb4000-0x7fbb5040 260M pmd 0x7fbb5040-0x7fbb5059d0001652K pte 0x7fbb5059d000-0x7fbb505e 268K USR ro x pte 0x7fbb505e-0x7fbb5061 192K pte 0x7fbb5061-0x7fbb50632000 136K USR ro x pte 0x7fbb50632000-0x7fbb50633000 4K pte 0x7fbb50633000-0x7fbb5066 180K USR ro x pte 0x7fbb5066-0x7fbb5067 64K pte 0x7fbb5067-0x7fbb5069 128K USR ro x pte 0x7fbb5069-0x7fbb506c 192K pte 0x7fbb506c-0x7fbb506cb000 44K USR ro x pte 0x7fbb506cb000-0x7fbb506cc000 4K pte 0x7fbb506cc000-0x7fbb506d 16K USR ro x pte 0x7fbb506d-0x7fbb506e 64K pte 0x7fbb506e-0x7fbb5071 192K USR ro x pte 0x7fbb5071-0x7fbb509360002200K pte 0x7fbb50936000-0x7fbb5093a000 16K USR ro NX pte 0x7fbb5093a000-0x7fbb5093d000 12K USR RW NX pte 0x7fbb5093d000-0x7fbb5093f000 8K pte 0x7fbb5093f000-0x7fbb5094 4K USR RW NX pte 0x7fbb5094-0x7fbb50963000 140K USR ro x pte 0x7fbb50963000-0x7fbb5099d000 232K pte 0x7fbb5099d000-0x7fbb5099e000 4K USR RW NX pte 0x7fbb5099e000-0x7fbb509bf000 132K pte 0x7fbb509bf000-0x7fbb509cf000 64K USR ro NX pte 0x7fbb509cf000-0x7fbb509d 4K pte 0x7fbb509d-0x7fbb509d7000 28K USR ro NX pte 0x7fbb509d7000-0x7fbb509d8000 4K pte 0x7fbb509d8000-0x7fbb509ea000 72K USR ro NX pte 0x7fbb509ea000
[PATCH][next] usbip: vhci: fix spelling mistake: "synchronuously" -> "synchronously"
From: Colin Ian King Trivial fix to spelling mistake in dev_dbg debug message. Signed-off-by: Colin Ian King --- drivers/usb/usbip/vhci_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c index 112ebb90d8c9..44cd64518925 100644 --- a/drivers/usb/usbip/vhci_rx.c +++ b/drivers/usb/usbip/vhci_rx.c @@ -30,7 +30,7 @@ struct urb *pickup_urb_and_free_priv(struct vhci_device *vdev, __u32 seqnum) /* fall through */ case -ECONNRESET: dev_dbg(&urb->dev->dev, -"urb seq# %u was unlinked %ssynchronuously\n", +"urb seq# %u was unlinked %ssynchronously\n", seqnum, status == -ENOENT ? "" : "a"); break; case -EINPROGRESS: -- 2.14.1
Re: "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs
On Wed, Jan 03, 2018 at 12:46:00AM -0800, Benjamin Gilbert wrote: > [resending with less web] (adding lkml and x86 developers) > Hi all, > > In our regression tests on kernel 4.14.11, we're occasionally seeing a run > of "bad pmd" messages during boot, followed by a "BUG: unable to handle > kernel paging request". This happens on no more than a couple percent of > boots, but we've seen it on AWS HVM, GCE, Oracle Cloud VMs, and local QEMU > instances. It always happens immediately after "Loading compiled-in X.509 > certificates". I can't reproduce it on 4.14.10, nor, so far, on 4.14.11 > with pti=off. Here's a sample backtrace: > > [4.762964] Loading compiled-in X.509 certificates > [4.765620] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee000(80007d6000e3) > [4.769099] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee008(80007d8000e3) > [4.772479] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee010(80007da000e3) > [4.775919] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee018(80007dc000e3) > [4.779251] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee020(80007de000e3) > [4.782558] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee028(80007ee3) > [4.794160] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee030(80007e2000e3) > [4.797525] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee038(80007e4000e3) > [4.800776] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee040(80007e6000e3) > [4.804100] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee048(80007e8000e3) > [4.807437] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee050(80007ea000e3) > [4.810729] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee058(80007ec000e3) > [4.813989] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee060(80007ee000e3) > [4.817294] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee068(80007fe3) > [4.820713] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee070(80007f2000e3) > [4.823943] ../source/mm/pgtable-generic.c:40: bad pmd > 8b39bf7ee078(80007f4000e3) > [4.827311] BUG: unable to handle kernel paging request at fe27c1fdfba0 > [4.830109] IP: free_page_and_swap_cache+0x6/0xa0 > [4.831999] PGD 7f7ef067 P4D 7f7ef067 PUD 0 > [4.833779] Oops: [#1] SMP PTI > [4.835197] Modules linked in: > [4.836450] CPU: 0 PID: 45 Comm: modprobe Not tainted 4.14.11-coreos #1 > [4.839009] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 > [4.841551] task: 8b39b5a71e40 task.stack: b92580558000 > [4.844062] RIP: 0010:free_page_and_swap_cache+0x6/0xa0 > [4.846238] RSP: 0018:b9258055bc98 EFLAGS: 00010297 > [4.848300] RAX: RBX: fe27c0001000 RCX: > 8b39bf7ef4f8 > [4.851184] RDX: 0007f7ee RSI: fe27c1fdfb80 RDI: > fe27c1fdfb80 > [4.854090] RBP: 8b39bf7ee000 R08: R09: > 0162 > [4.856946] R10: ff90 R11: 0161 R12: > fe27ffe0 > [4.859777] R13: 8b39bf7ef000 R14: fe28 R15: > b9258055bd60 > [4.862602] FS: () GS:8b39bd20() > knlGS: > [4.865860] CS: 0010 DS: ES: CR0: 80050033 > [4.868175] CR2: fe27c1fdfba0 CR3: 2d00a001 CR4: > 001606f0 > [4.871162] Call Trace: > [4.872188] free_pgd_range+0x3a5/0x5b0 > [4.873781] free_ldt_pgtables.part.2+0x60/0xa0 > [4.875679] ? arch_tlb_finish_mmu+0x42/0x70 > [4.877476] ? tlb_finish_mmu+0x1f/0x30 > [4.878999] exit_mmap+0x5b/0x1a0 > [4.880327] ? dput+0xb8/0x1e0 > [4.881575] ? hrtimer_try_to_cancel+0x25/0x110 > [4.883388] mmput+0x52/0x110 > [4.884620] do_exit+0x330/0xb10 > [4.886044] ? task_work_run+0x6b/0xa0 > [4.887544] do_group_exit+0x3c/0xa0 > [4.889012] SyS_exit_group+0x10/0x10 > [4.890473] entry_SYSCALL_64_fastpath+0x1a/0x7d > [4.892364] RIP: 0033:0x7f4a41d4ded9 > [4.893812] RSP: 002b:7ffe25d85708 EFLAGS: 0246 ORIG_RAX: > 00e7 > [4.896974] RAX: ffda RBX: 5601b3c9e2e0 RCX: > 7f4a41d4ded9 > [4.899830] RDX: RSI: 0001 RDI: > 0001 > [4.902647] RBP: 5601b3c9d0e8 R08: 003c R09: > 00e7 > [4.905743] R10: ff90 R11: 0246 R12: > 5601b3c9d090 > [4.908659] R13: 0004 R14: 0001 R15: > 7ffe25d85828 > [4.911495] Code: e0 01 48 83 f8 01 19 c0 25 01 fe ff ff 05 00 02 00 00 3e > 29 43 1c 5b 5d 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 <48> > 8b 57 20 48 89 fb 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 48 > [4.919014] RIP: free_page_and_swap_cache+0x6/0xa0
Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
On Wednesday, January 3, 2018 8:14:47 AM CET Jani Nikula wrote:
> On Tue, 02 Jan 2018, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2018-01-02 19:12:18)
> >
> >> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> >> > + edid = drm_get_edid(connector, i2c);
> >> > +
> >> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> >> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using
> >> > GPIO bit-banging\n"); + intel_gmbus_force_bit(i2c, true);
> >> > + edid = drm_get_edid(connector, i2c);
> >> > + intel_gmbus_force_bit(i2c, false);
> >> > + }
> >>
> >> Approach seems fine for this case.
> >> I just wonder what would be the risks of forcing this bit and edid read
> >> when nothing is present on the other end?>
> > Should be no more risky than using GMBUS as the bit-banging is the
> > underlying HW protocol; it should just be adding an extra delay to
> > the disconnected probe. Offset against the chance that it fixes
> > detection of borderline devices.
> >
> > I would say that given the explanation above, the question is why not
> > apply it universally? (Bonus points for including the explanation as
> > comments.)
>
> I'm wondering, is gmbus too fast for the adapters, does gmbus generally
> have different timing for the ack/nak as described in the commit message
> than bit banging, or are the adapters just plain buggy? Do we have any
> control over gmbus timings (don't have the time to peruse the bpsec just
> now)?
I have seen two different behaviours, one on the ~2009 GM965, the other on the
~2013 Haswell. The Haswell provides a 250..500ns hold time, the other does
not.
There is a flag in the GMBUS0 register, GMBUS_HOLD_EXT, "300ns hold time, rsvd
on Pineview". The driver does not set this flag. Possibly it is always set/
implied on the Haswell (which is post-Pineview), and should be set for
anything older than Pineview.
There is another odd fact with the GM965, according to the register setting it
should run at 100 kBit/s, but it only runs at 30 kBit/s. The Haswell runs at
100 kBit/s, as specified. As there are also idle periods ever 8 bytes, the
EDID read takes 270ms before it fails.
The bitbanging code, running at 45 kBit/s (2 * 20us per clock cycle plus
overhead) on the other hand just needs 58 ms, but keeps one core busy
(udelay).
Unfortunately I currently have no older system than the Haswell available, so
I can not check if the GMBUS_HOLD_EXT flag has any effect.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
[PATCH] thermal: Use power efficient workqueue
Thermal core framework uses the system_freezable_wq workqueue as its
workqueue for polling temperature. Using system_freezable_wq workqueue
prevents the scheduler to make smart decision about the best place to
schedule the work.
This commit replaces system_freezable_wq with
system_freezable_power_efficient_wq. With kernel configuration
CONFIG_WQ_POWER_EFFICIENT is enabled, the work can be scheduled on the
best CPU from a power or a performance point of view.
This commit is inspired by Vincent Guittot patch "netfilter: conntrack:
use power efficient workqueue" and verified on 96boards Hikey960.
Cc: Eduardo Valentin
Cc: Zhang Rui
Cc: Daniel Lezcano
Cc: Vincent Guittot
Signed-off-by: Leo Yan
---
drivers/thermal/thermal_core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 2b1b0ba..ba90f71 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -293,11 +293,12 @@ static void thermal_zone_device_set_polling(struct
thermal_zone_device *tz,
int delay)
{
if (delay > 1000)
- mod_delayed_work(system_freezable_wq, &tz->poll_queue,
+ mod_delayed_work(system_freezable_power_efficient_wq,
+&tz->poll_queue,
round_jiffies(msecs_to_jiffies(delay)));
else if (delay)
- mod_delayed_work(system_freezable_wq, &tz->poll_queue,
-msecs_to_jiffies(delay));
+ mod_delayed_work(system_freezable_power_efficient_wq,
+&tz->poll_queue, msecs_to_jiffies(delay));
else
cancel_delayed_work(&tz->poll_queue);
}
--
2.7.4
[PATCH] staging: ccree: mark debug_regs[] as static
The global array clashes with an existing symbol of the same name:
drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of
`debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
We should fix both, this one addresses the ccree driver by removing
the symbol from the global namespace.
Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and
hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs
interface")
Signed-off-by: Arnd Bergmann
---
drivers/staging/ccree/cc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/cc_debugfs.c
b/drivers/staging/ccree/cc_debugfs.c
index 7cd33957fdc6..662fa07af832 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -37,7 +37,7 @@ struct cc_debugfs_ctx {
*/
static struct dentry *cc_debugfs_dir;
-struct debugfs_reg32 debug_regs[] = {
+static struct debugfs_reg32 debug_regs[] = {
CC_DEBUG_REG(HOST_SIGNATURE),
CC_DEBUG_REG(HOST_IRR),
CC_DEBUG_REG(HOST_POWER_DOWN_EN),
--
2.9.0
[PATCH] media: intel-ipu3: cio2: mark PM functions as __maybe_unused
When CONFIG_PM is disabled, we get harmless warnings about the
suspend/resume callbacks being unused:
drivers/media/pci/intel/ipu3/ipu3-cio2.c:1993:12: error: 'cio2_resume' defined
but not used [-Werror=unused-function]
drivers/media/pci/intel/ipu3/ipu3-cio2.c:1967:12: error: 'cio2_suspend' defined
but not used [-Werror=unused-function]
This marks them as __maybe_unused to shut up the warnings.
Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Arnd Bergmann
---
drivers/media/pci/intel/ipu3/ipu3-cio2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index 941caa987dab..c2f1447eec0b 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -1964,7 +1964,7 @@ static void cio2_fbpt_rearrange(struct cio2_device *cio2,
struct cio2_queue *q)
cio2_fbpt_entry_enable(cio2, q->fbpt + i * CIO2_MAX_LOPS);
}
-static int cio2_suspend(struct device *dev)
+static int __maybe_unused cio2_suspend(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
struct cio2_device *cio2 = pci_get_drvdata(pci_dev);
@@ -1990,7 +1990,7 @@ static int cio2_suspend(struct device *dev)
return 0;
}
-static int cio2_resume(struct device *dev)
+static int __maybe_unused cio2_resume(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
struct cio2_device *cio2 = pci_get_drvdata(pci_dev);
--
2.9.0
[PATCH] s3mci: mark debug_regs[] as static
The global array clashes with a newly added symbol of the same name:
drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of
`debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
We should fix both, this one addresses the s3cmci driver by removing
the symbol from the global namespace.
Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and
hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs
interface")
Signed-off-by: Arnd Bergmann
---
drivers/mmc/host/s3cmci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 36daee1e6588..24b27e0957e7 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -1421,7 +1421,7 @@ static const struct file_operations s3cmci_fops_state = {
#define DBG_REG(_r) { .addr = S3C2410_SDI##_r, .name = #_r }
-struct s3cmci_reg {
+static struct s3cmci_reg {
unsigned short addr;
unsigned char *name;
} debug_regs[] = {
--
2.9.0
Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
Hi Stefano, Stefano Brivio writes: > On Tue, 2 Jan 2018 17:30:20 +0100 > Nicolai Stange wrote: > >> [...] >> >> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c >> index 5b9bd5c33d9d..e84290c28c0c 100644 >> --- a/net/ipv4/raw.c >> +++ b/net/ipv4/raw.c >> @@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct msghdr >> *msg, size_t len) >> int err; >> struct ip_options_data opt_copy; >> struct raw_frag_vec rfv; >> -int hdrincl; >> +int hdrincl, __hdrincl; >> >> err = -EMSGSIZE; >> if (len > 0x) >> goto out; >> >> /* hdrincl should be READ_ONCE(inet->hdrincl) >> - * but READ_ONCE() doesn't work with bit fields >> + * but READ_ONCE() doesn't work with bit fields. >> + * Emulate it by doing the READ_ONCE() from an intermediate int. >> */ >> -hdrincl = inet->hdrincl; >> +__hdrincl = inet->hdrincl; >> +hdrincl = READ_ONCE(__hdrincl); > > I guess you don't actually need to use a third variable. What about > doing READ_ONCE() on hdrincl itself after the first assignment? > > Perhaps something like the patch below -- applies to net.git, yields > same binary output as your version with gcc 6, looks IMHO more > straightforward: > > diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c > index 125c1eab3eaa..8c2f783a95fc 100644 > --- a/net/ipv4/raw.c > +++ b/net/ipv4/raw.c > @@ -519,10 +519,12 @@ static int raw_sendmsg(struct sock *sk, struct msghdr > *msg, size_t len) > if (len > 0x) > goto out; > > - /* hdrincl should be READ_ONCE(inet->hdrincl) > - * but READ_ONCE() doesn't work with bit fields > + /* hdrincl should be READ_ONCE(inet->hdrincl) but READ_ONCE() doesn't > + * work with bit fields. Emulate it by adding a further sequence point. >*/ > hdrincl = inet->hdrincl; > + hdrincl = READ_ONCE(hdrincl); > + Yes, this does also work. In fact, after having been lowered into SSA form, it should be equivalent to what I posted. So, it's a matter of preference/style and I'd leave the decision on this to the maintainers -- for me, either way is fine. I don't like the "sequence point" wording in the comment above though: AFAICS, if taken in the meaning of C99, it's not any sequence point but the volatile access in READ_ONCE() which ensures that there won't be any reloads from ->hdrincl. If you don't mind, I'll adjust that comment if asked to resend with your solution. Thanks, Nicolai
Re: [PATCH V6] mmc:host:sdhci-pci:Addition of Arasan PCI Controller with integrated phy.
On Wednesday 03 January 2018 05:41 AM, Atul Garg wrote: > The Arasan Controller is based on a FPGA platform and has integrated phy > with specific registers used during initialization and > management of different modes. The phy and the controller are integrated > and registers are very specific to Arasan. > > Arasan being an IP provider, licenses these IPs to various companies for > integration of IP in custom SOCs. The custom SOCs define own register > map depending on how bits are tied inside the SOC for phy registers, > depending on SOC memory plan and hence will require own platform drivers. > > If more details on phy registers are required, an interface document is > hosted at https: //arasandotcom/NF/eMMC5.1 PHY Programming in Linux.pdf. Please fix this link (no space after : and arasan.com instead of arasandotcom etc). > > Signed-off-by: Atul Garg Apart from the comments given by Adrian, looks good to me. Reviewed-by: Sekhar Nori Regards, Sekhar
[PATCH] clk: imx: imx7d: correct video pll clock tree
There is a test divider and post divider in video PLL,
test divider is placed before post divider, all clocks
that can select parent from video PLL should be from
post divider, NOT from pll_video_main, below are
clock tree dump before and after this patch:
Before:
pll_video_main
pll_video_main_bypass
pll_video_main_clk
lcdif_pixel_src
lcdif_pixel_cg
lcdif_pixel_pre_div
lcdif_pixel_post_div
lcdif_pixel_root_clk
After:
pll_video_main
pll_video_main_bypass
pll_video_main_clk
pll_video_test_div
pll_video_post_div
lcdif_pixel_src
lcdif_pixel_cg
lcdif_pixel_pre_div
lcdif_pixel_post_div
lcdif_pixel_root_clk
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 84 -
1 file changed, 44 insertions(+), 40 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..992938b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -51,20 +51,20 @@
static const char *arm_m4_sel[] = { "osc", "pll_sys_main_240m_clk",
"pll_enet_250m_clk", "pll_sys_pfd2_270m_clk",
- "pll_dram_533m_clk", "pll_audio_post_div", "pll_video_main_clk",
+ "pll_dram_533m_clk", "pll_audio_post_div", "pll_video_post_div",
"pll_usb_main_clk", };
static const char *axi_sel[] = { "osc", "pll_sys_pfd1_332m_clk",
"pll_dram_533m_clk", "pll_enet_250m_clk", "pll_sys_pfd5_clk",
- "pll_audio_post_div", "pll_video_main_clk", "pll_sys_pfd7_clk", };
+ "pll_audio_post_div", "pll_video_post_div", "pll_sys_pfd7_clk", };
static const char *disp_axi_sel[] = { "osc", "pll_sys_pfd1_332m_clk",
"pll_dram_533m_clk", "pll_enet_250m_clk", "pll_sys_pfd6_clk",
- "pll_sys_pfd7_clk", "pll_audio_post_div", "pll_video_main_clk", };
+ "pll_sys_pfd7_clk", "pll_audio_post_div", "pll_video_post_div", };
static const char *enet_axi_sel[] = { "osc", "pll_sys_pfd2_270m_clk",
"pll_dram_533m_clk", "pll_enet_250m_clk",
- "pll_sys_main_240m_clk", "pll_audio_post_div", "pll_video_main_clk",
+ "pll_sys_main_240m_clk", "pll_audio_post_div", "pll_video_post_div",
"pll_sys_pfd4_clk", };
static const char *nand_usdhc_bus_sel[] = { "osc", "pll_sys_pfd2_270m_clk",
@@ -75,7 +75,7 @@
static const char *ahb_channel_sel[] = { "osc", "pll_sys_pfd2_270m_clk",
"pll_dram_533m_clk", "pll_sys_pfd0_392m_clk",
"pll_enet_125m_clk", "pll_usb_main_clk", "pll_audio_post_div",
- "pll_video_main_clk", };
+ "pll_video_post_div", };
static const char *dram_phym_sel[] = { "pll_dram_main_clk",
"dram_phym_alt_clk", };
@@ -86,7 +86,7 @@
static const char *dram_phym_alt_sel[] = { "osc", "pll_dram_533m_clk",
"pll_sys_main_clk", "pll_enet_500m_clk",
"pll_usb_main_clk", "pll_sys_pfd7_clk", "pll_audio_post_div",
- "pll_video_main_clk", };
+ "pll_video_post_div", };
static const char *dram_alt_sel[] = { "osc", "pll_dram_533m_clk",
"pll_sys_main_clk", "pll_enet_500m_clk",
@@ -108,62 +108,62 @@
static const char *epdc_pixel_sel[] = { "osc", "pll_sys_pfd1_332m_clk",
"pll_dram_533m_clk", "pll_sys_main_clk", "pll_sys_pfd5_clk",
- "pll_sys_pfd6_clk", "pll_sys_pfd7_clk", "pll_video_main_clk", };
+ "pll_sys_pfd6_clk", "pll_sys_pfd7_clk", "pll_video_post_div", };
static const char *lcdif_pixel_sel[] = { "osc", "pll_sys_pfd5_clk",
"pll_dram_533m_clk", "ext_clk_3", "pll_sys_pfd4_clk",
- "pll_sys_pfd2_270m_clk", "pll_video_main_clk",
+ "pll_sys_pfd2_270m_clk", "pll_video_post_div",
"pll_usb_main_clk", };
static const char *mipi_dsi_sel[] = { "osc", "pll_sys_pfd5_clk",
"pll_sys_pfd3_clk", "pll_sys_main_clk", "pll_sys_pfd0_196m_clk",
- "pll_dram_533m_clk", "pll_video_main_clk", "pll_audio_post_div", };
+ "pll_dram_533m_clk", "pll_video_post_div", "pll_audio_post_div", };
static const char *mipi_csi_sel[] = { "osc", "pll_sys_pfd4_clk",
"pll_sys_pfd3_clk", "pll_sys_main_clk", "pll_sys_pfd0_196m_clk",
- "pll_dram_533m_clk", "pll_video_main_clk", "pll_audio_post_div", };
+ "pll_dram_533m_clk", "pll_video_post_div", "pll_audio_post_div", };
static const char *mipi_dphy_sel[] = { "osc", "pll_sys_main_120m_clk",
"pll_dram_533m_clk", "pll_sys_pfd5_clk", "ref_1m_clk", "ext_clk_2",
- "pll_video_main_clk", "ext_clk_3", };
+ "pll_video_post_div", "ext_clk_3", };
static const char *sai1_sel[] = { "osc", "pll_sys_pfd2_135m_clk",
- "pll_audio_post_div", "pll_dram_533m_clk", "pll_video_main_clk",
+ "pll_audio_post_div", "pll_dram_533m_clk", "pll_video_post_div",
"pll_sys_pfd4_clk", "pll_enet_125m_clk", "ext_clk_2", };
static const char *sai2_sel[] = { "osc", "pll_sys_pfd2_135m_clk",
- "pll_
Re: [RFC PATCH] input: Add disable sysfs entry for every input device
On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote: > On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote: > > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote: > > > I don't doubt that the use cases should be catered for, I > > > essentially > > > did that same work without kernel changes for GNOME. What I doubt > > > is > > > the fuzzy semantics, the fact that the device is kept opened but no > > > data is sent (that's not power saving), that whether users are > > > revoked > > > or should be revoked isn't clear, and that the goal is basically to > > > work around stupid input handling when at the console. When running > > > a > > > display manager, this is all avoided. > > > > > > If this were to go through, then the semantics and behaviour needs > > > to > > > be better explained, power saving actually made possible, and make > > > sure > > > that libinput can proxy that state to the users on the console. Or > > > an > > > ioctl added to the evdev device to disable them. > > > > So, do you mean to implement this "disable" action as ioctl for > > particular /dev/input/event* device (instead of sysfs entry)? > > Yes, so the device can be powered down without the device node being > closed and made unavailable. I don't know whether that's something > that's already possible for all cases, but there's already > opportunistic in a lot of drivers and subsystems. > > This opens up a whole new wave of potential problems, but it's a more > generally useful mechanism, I would think. Ok. How should API for this ioctl looks like? And do you have an idea for name of that ioctl? Dmitry, what do you think about it? It is acceptable for you? -- Pali Rohár pali.ro...@gmail.com
[PATCH] f2fs: continue to do direct IO if we only preallocate partial blocks
While doing direct IO, if we run out-of-space when we preallocate blocks,
we should not return ENOSPC error directly, instead, we should continue
to do following direct IO, which will keep directIO of f2fs acting like
other filesystems.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 4ba9aa268632..557d6d1e65f7 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -831,10 +831,12 @@ int f2fs_preallocate_blocks(struct kiocb *iocb, struct
iov_iter *from)
{
struct inode *inode = file_inode(iocb->ki_filp);
struct f2fs_map_blocks map;
+ int flag;
int err = 0;
+ bool direct_io = iocb->ki_flags & IOCB_DIRECT;
/* convert inline data for Direct I/O*/
- if (iocb->ki_flags & IOCB_DIRECT) {
+ if (direct_io) {
err = f2fs_convert_inline_inode(inode);
if (err)
return err;
@@ -853,25 +855,29 @@ int f2fs_preallocate_blocks(struct kiocb *iocb, struct
iov_iter *from)
map.m_next_pgofs = NULL;
map.m_seg_type = NO_CHECK_TYPE;
- if (iocb->ki_flags & IOCB_DIRECT) {
+ if (direct_io) {
map.m_seg_type = rw_hint_to_seg_type(iocb->ki_hint);
- return f2fs_map_blocks(inode, &map, 1,
- __force_buffered_io(inode, WRITE) ?
- F2FS_GET_BLOCK_PRE_AIO :
- F2FS_GET_BLOCK_PRE_DIO);
+ flag = __force_buffered_io(inode, WRITE) ?
+ F2FS_GET_BLOCK_PRE_AIO :
+ F2FS_GET_BLOCK_PRE_DIO;
+ goto map_blocks;
}
if (iocb->ki_pos + iov_iter_count(from) > MAX_INLINE_DATA(inode)) {
err = f2fs_convert_inline_inode(inode);
if (err)
return err;
}
- if (!f2fs_has_inline_data(inode)) {
- err = f2fs_map_blocks(inode, &map, 1, F2FS_GET_BLOCK_PRE_AIO);
- if (map.m_len > 0 && err == -ENOSPC) {
- set_inode_flag(inode, FI_NO_PREALLOC);
- err = 0;
- }
+ if (f2fs_has_inline_data(inode))
return err;
+
+ flag = F2FS_GET_BLOCK_PRE_AIO;
+
+map_blocks:
+ err = f2fs_map_blocks(inode, &map, 1, flag);
+ if (map.m_len > 0 && err == -ENOSPC) {
+ if (!direct_io)
+ set_inode_flag(inode, FI_NO_PREALLOC);
+ err = 0;
}
return err;
}
--
2.15.0.55.gc2ece9dc4de6
[PATCH 4/6] mm, hugetlb: get rid of surplus page accounting tricks
From: Michal Hocko
alloc_surplus_huge_page increases the pool size and the number of
surplus pages opportunistically to prevent from races with the pool size
change. See d1c3fb1f8f29 ("hugetlb: introduce nr_overcommit_hugepages
sysctl") for more details.
The resulting code is unnecessarily hairy, cause code duplication and
doesn't allow to share the allocation paths. Moreover pool size changes
tend to be very seldom so optimizing for them is not really reasonable.
Simplify the code and allow to allocate a fresh surplus page as long as
we are under the overcommit limit and then recheck the condition after
the allocation and drop the new page if the situation has changed. This
should provide a reasonable guarantee that an abrupt allocation requests
will not go way off the limit.
If we consider races with the pool shrinking and enlarging then we
should be reasonably safe as well. In the first case we are off by one
in the worst case and the second case should work OK because the page is
not yet visible. We can waste CPU cycles for the allocation but that
should be acceptable for a relatively rare condition.
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
mm/hugetlb.c | 62 ++--
1 file changed, 23 insertions(+), 39 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f260ffa26363..7dc80cbe8e89 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1540,62 +1540,46 @@ int dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn)
static struct page *__alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nmask)
{
- struct page *page;
- unsigned int r_nid;
+ struct page *page = NULL;
if (hstate_is_gigantic(h))
return NULL;
- /*
-* Assume we will successfully allocate the surplus page to
-* prevent racing processes from causing the surplus to exceed
-* overcommit
-*
-* This however introduces a different race, where a process B
-* tries to grow the static hugepage pool while alloc_pages() is
-* called by process A. B will only examine the per-node
-* counters in determining if surplus huge pages can be
-* converted to normal huge pages in adjust_pool_surplus(). A
-* won't be able to increment the per-node counter, until the
-* lock is dropped by B, but B doesn't drop hugetlb_lock until
-* no more huge pages can be converted from surplus to normal
-* state (and doesn't try to convert again). Thus, we have a
-* case where a surplus huge page exists, the pool is grown, and
-* the surplus huge page still exists after, even though it
-* should just have been converted to a normal huge page. This
-* does not leak memory, though, as the hugepage will be freed
-* once it is out of use. It also does not allow the counters to
-* go out of whack in adjust_pool_surplus() as we don't modify
-* the node values until we've gotten the hugepage and only the
-* per-node value is checked there.
-*/
spin_lock(&hugetlb_lock);
- if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
- spin_unlock(&hugetlb_lock);
- return NULL;
- } else {
- h->nr_huge_pages++;
- h->surplus_huge_pages++;
- }
+ if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages)
+ goto out_unlock;
spin_unlock(&hugetlb_lock);
page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask, nid, nmask);
+ if (!page)
+ goto out_unlock;
spin_lock(&hugetlb_lock);
- if (page) {
+ /*
+* We could have raced with the pool size change.
+* Double check that and simply deallocate the new page
+* if we would end up overcommiting the surpluses. Abuse
+* temporary page to workaround the nasty free_huge_page
+* codeflow
+*/
+ if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
+ SetPageHugeTemporary(page);
+ put_page(page);
+ page = NULL;
+ } else {
+ int r_nid;
+
+ h->surplus_huge_pages++;
+ h->nr_huge_pages++;
INIT_LIST_HEAD(&page->lru);
r_nid = page_to_nid(page);
set_compound_page_dtor(page, HUGETLB_PAGE_DTOR);
set_hugetlb_cgroup(page, NULL);
- /*
-* We incremented the global counters already
-*/
h->nr_huge_pages_node[r_nid]++;
h->surplus_huge_pages_node[r_nid]++;
- } else {
- h->nr_huge_pages--;
- h->surplus_huge_pages--;
}
+
+out_unlock:
spin_unlock(&hugetlb_lock);
return page;
--
2.15.1
[PATCH 2/6] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path
From: Michal Hocko
Gigantic hugetlb pages were ingrown to the hugetlb code as an alien
specie with a lot of special casing. The allocation path is not an
exception. Unnecessarily so to be honest. It is true that the underlying
allocator is different but that is an implementation detail.
This patch unifies the hugetlb allocation path that a prepares fresh
pool pages. alloc_fresh_gigantic_page basically copies alloc_fresh_huge_page
logic so we can move everything there. This will simplify set_max_huge_pages
which doesn't have to care about what kind of huge page we allocate.
Changes since RFC
- compile fix for !CONFIG_ARCH_HAS_GIGANTIC_PAGE
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
mm/hugetlb.c | 55 ++-
1 file changed, 14 insertions(+), 41 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a8959667f539..360765156c7c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1106,7 +1106,8 @@ static bool zone_spans_last_pfn(const struct zone *zone,
return zone_spans_pfn(zone, last_pfn);
}
-static struct page *alloc_gigantic_page(int nid, struct hstate *h)
+static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
+ int nid, nodemask_t *nodemask)
{
unsigned int order = huge_page_order(h);
unsigned long nr_pages = 1 << order;
@@ -1114,11 +1115,9 @@ static struct page *alloc_gigantic_page(int nid, struct
hstate *h)
struct zonelist *zonelist;
struct zone *zone;
struct zoneref *z;
- gfp_t gfp_mask;
- gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
zonelist = node_zonelist(nid, gfp_mask);
- for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(gfp_mask),
NULL) {
+ for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(gfp_mask),
nodemask) {
spin_lock_irqsave(&zone->lock, flags);
pfn = ALIGN(zone->zone_start_pfn, nr_pages);
@@ -1149,42 +1148,13 @@ static struct page *alloc_gigantic_page(int nid, struct
hstate *h)
static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
static void prep_compound_gigantic_page(struct page *page, unsigned int order);
-static struct page *alloc_fresh_gigantic_page_node(struct hstate *h, int nid)
-{
- struct page *page;
-
- page = alloc_gigantic_page(nid, h);
- if (page) {
- prep_compound_gigantic_page(page, huge_page_order(h));
- prep_new_huge_page(h, page, nid);
- put_page(page); /* free it into the hugepage allocator */
- }
-
- return page;
-}
-
-static int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed)
-{
- struct page *page = NULL;
- int nr_nodes, node;
-
- for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = alloc_fresh_gigantic_page_node(h, node);
- if (page)
- return 1;
- }
-
- return 0;
-}
-
#else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE */
static inline bool gigantic_page_supported(void) { return false; }
+static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
+ int nid, nodemask_t *nodemask) { return NULL; }
static inline void free_gigantic_page(struct page *page, unsigned int order) {
}
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
-static inline int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed) { return 0; }
#endif
static void update_and_free_page(struct hstate *h, struct page *page)
@@ -1410,8 +1380,12 @@ static int alloc_fresh_huge_page(struct hstate *h,
nodemask_t *nodes_allowed)
gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask,
- node, nodes_allowed);
+ if (hstate_is_gigantic(h))
+ page = alloc_gigantic_page(h, gfp_mask,
+ node, nodes_allowed);
+ else
+ page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask,
+ node, nodes_allowed);
if (page)
break;
@@ -1420,6 +1394,8 @@ static int alloc_fresh_huge_page(struct hstate *h,
nodemask_t *nodes_allowed)
if (!page)
return 0;
+ if (hstate_is_gigantic(h))
+ prep_compound_gigantic_page(page, huge_page_order(h));
prep_new_huge_page(h, page, page_to_nid(page));
put_page(page); /* free it into the hugepage allocator */
@@ -2307,10 +2283,7 @@ static unsigned long set_max_huge_pages(struct hstate
*h, u
[PATCH 0/6] mm, hugetlb: allocation API and migration improvements
Hi, I've posted this as an RFC [1] and both Mike and Naoya seem to be OK both with patches and the approach. I have rebased this on top of [2] because there is a small conflict in mm/mempolicy.c. I know it is late in the release cycle but similarly to [2] I would really like to see this in linux-next for a longer time for a wider testing exposure. Motivation: this is a follow up for [3] for the allocation API and [4] for the hugetlb migration. It wasn't really easy to split those into two separate patch series as they share some code. My primary motivation to touch this code is to make the gigantic pages migration working. The giga pages allocation code is just too fragile and hacked into the hugetlb code now. This series tries to move giga pages closer to the first class citizen. We are not there yet but having 5 patches is quite a lot already and it will already make the code much easier to follow. I will come with other changes on top after this sees some review. The first two patches should be trivial to review. The third patch changes the way how we migrate huge pages. Newly allocated pages are a subject of the overcommit check and they participate surplus accounting which is quite unfortunate as the changelog explains. This patch doesn't change anything wrt. giga pages. Patch #4 removes the surplus accounting hack from __alloc_surplus_huge_page. I hope I didn't miss anything there and a deeper review is really due there. Patch #5 finally unifies allocation paths and giga pages shouldn't be any special anymore. There is also some renaming going on as well. Shortlog Michal Hocko (6): mm, hugetlb: unify core page allocation accounting and initialization mm, hugetlb: integrate giga hugetlb more naturally to the allocation path mm, hugetlb: do not rely on overcommit limit during migration mm, hugetlb: get rid of surplus page accounting tricks mm, hugetlb: further simplify hugetlb allocation API hugetlb, mempolicy: fix the mbind hugetlb migration Diffstat: include/linux/hugetlb.h | 8 +- mm/hugetlb.c| 338 +++- mm/mempolicy.c | 3 +- mm/migrate.c| 3 +- 4 files changed, 198 insertions(+), 154 deletions(-) [1] http://lkml.kernel.org/r/20171204140117.7191-1-mho...@kernel.org [2] http://lkml.kernel.org/r/20180103082555.14592-1-mho...@kernel.org [3] http://lkml.kernel.org/r/20170622193034.28972-1-mho...@kernel.org [4] http://lkml.kernel.org/r/20171122152832.iayefrlxbugph...@dhcp22.suse.cz
[PATCH 6/6] hugetlb, mempolicy: fix the mbind hugetlb migration
From: Michal Hocko
do_mbind migration code relies on alloc_huge_page_noerr for hugetlb
pages. alloc_huge_page_noerr uses alloc_huge_page which is a highlevel
allocation function which has to take care of reserves, overcommit or
hugetlb cgroup accounting. None of that is really required for the page
migration because the new page is only temporal and either will replace
the original page or it will be dropped. This is essentially as for
other migration call paths and there shouldn't be any reason to handle
mbind in a special way.
The current implementation is even suboptimal because the migration
might fail just because the hugetlb cgroup limit is reached, or the
overcommit is saturated.
Fix this by making mbind like other hugetlb migration paths. Add
a new migration helper alloc_huge_page_vma as a wrapper around
alloc_huge_page_nodemask with additional mempolicy handling.
alloc_huge_page_noerr has no more users and it can go.
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
include/linux/hugetlb.h | 5 ++---
mm/hugetlb.c| 33 +++--
mm/mempolicy.c | 3 +--
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 66992348531e..612a29b7f6c6 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -356,10 +356,9 @@ struct huge_bootmem_page {
struct page *alloc_huge_page(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve);
struct page *alloc_huge_page_node(struct hstate *h, int nid);
-struct page *alloc_huge_page_noerr(struct vm_area_struct *vma,
- unsigned long addr, int avoid_reserve);
struct page *alloc_huge_page_nodemask(struct hstate *h, int preferred_nid,
nodemask_t *nmask);
+struct page *alloc_huge_page_vma(struct vm_area_struct *vma, unsigned long
address);
int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
pgoff_t idx);
@@ -537,7 +536,7 @@ struct hstate {};
#define alloc_huge_page(v, a, r) NULL
#define alloc_huge_page_node(h, nid) NULL
#define alloc_huge_page_nodemask(h, preferred_nid, nmask) NULL
-#define alloc_huge_page_noerr(v, a, r) NULL
+#define alloc_huge_page_vma(vma, address) NULL
#define alloc_bootmem_huge_page(h) NULL
#define hstate_file(f) NULL
#define hstate_sizelog(s) NULL
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 60acd3e93a95..ffcae114ceed 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1674,6 +1674,25 @@ struct page *alloc_huge_page_nodemask(struct hstate *h,
int preferred_nid,
return alloc_migrate_huge_page(h, gfp_mask, preferred_nid, nmask);
}
+/* mempolicy aware migration callback */
+struct page *alloc_huge_page_vma(struct vm_area_struct *vma, unsigned long
address)
+{
+ struct mempolicy *mpol;
+ nodemask_t *nodemask;
+ struct page *page;
+ struct hstate *h;
+ gfp_t gfp_mask;
+ int node;
+
+ h = hstate_vma(vma);
+ gfp_mask = htlb_alloc_mask(h);
+ node = huge_node(vma, address, gfp_mask, &mpol, &nodemask);
+ page = alloc_huge_page_nodemask(h, node, nodemask);
+ mpol_cond_put(mpol);
+
+ return page;
+}
+
/*
* Increase the hugetlb pool such that it can accommodate a reservation
* of size 'delta'.
@@ -2079,20 +2098,6 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
return ERR_PTR(-ENOSPC);
}
-/*
- * alloc_huge_page()'s wrapper which simply returns the page if allocation
- * succeeds, otherwise NULL. This function is called from new_vma_page(),
- * where no ERR_VALUE is expected to be returned.
- */
-struct page *alloc_huge_page_noerr(struct vm_area_struct *vma,
- unsigned long addr, int avoid_reserve)
-{
- struct page *page = alloc_huge_page(vma, addr, avoid_reserve);
- if (IS_ERR(page))
- page = NULL;
- return page;
-}
-
int alloc_bootmem_huge_page(struct hstate *h)
__attribute__ ((weak, alias("__alloc_bootmem_huge_page")));
int __alloc_bootmem_huge_page(struct hstate *h)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index b6f4fcf9df64..30e68da64873 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1097,8 +1097,7 @@ static struct page *new_page(struct page *page, unsigned
long start)
}
if (PageHuge(page)) {
- BUG_ON(!vma);
- return alloc_huge_page_noerr(vma, address, 1);
+ return alloc_huge_page_vma(vma, address);
} else if (PageTransHuge(page)) {
struct page *thp;
--
2.15.1
[PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API
From: Michal Hocko
Hugetlb allocator has several layer of allocation functions depending
and the purpose of the allocation. There are two allocators depending
on whether the page can be allocated from the page allocator or we need
a contiguous allocator. This is currently opencoded in alloc_fresh_huge_page
which is the only path that might allocate giga pages which require the
later allocator. Create alloc_fresh_huge_page which hides this
implementation detail and use it in all callers which hardcoded the
buddy allocator path (__hugetlb_alloc_buddy_huge_page). This shouldn't
introduce any funtional change because both migration and surplus
allocators exlude giga pages explicitly.
While we are at it let's do some renaming. The current scheme is not
consistent and overly painfull to read and understand. Get rid of prefix
underscores from most functions. There is no real reason to make names
longer.
* alloc_fresh_huge_page is the new layer to abstract underlying
allocator
* __hugetlb_alloc_buddy_huge_page becomes shorter and neater
alloc_buddy_huge_page.
* Former alloc_fresh_huge_page becomes alloc_pool_huge_page because we put
the new page directly to the pool
* alloc_surplus_huge_page can drop the opencoded prep_new_huge_page code
as it uses alloc_fresh_huge_page now
* others lose their excessive prefix underscores to make names shorter
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
mm/hugetlb.c | 78
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7dc80cbe8e89..60acd3e93a95 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1378,7 +1378,7 @@ pgoff_t __basepage_index(struct page *page)
return (index << compound_order(page_head)) + compound_idx;
}
-static struct page *__hugetlb_alloc_buddy_huge_page(struct hstate *h,
+static struct page *alloc_buddy_huge_page(struct hstate *h,
gfp_t gfp_mask, int nid, nodemask_t *nmask)
{
int order = huge_page_order(h);
@@ -1396,34 +1396,49 @@ static struct page
*__hugetlb_alloc_buddy_huge_page(struct hstate *h,
return page;
}
+/*
+ * Common helper to allocate a fresh hugetlb page. All specific allocators
+ * should use this function to get new hugetlb pages
+ */
+static struct page *alloc_fresh_huge_page(struct hstate *h,
+ gfp_t gfp_mask, int nid, nodemask_t *nmask)
+{
+ struct page *page;
+
+ if (hstate_is_gigantic(h))
+ page = alloc_gigantic_page(h, gfp_mask, nid, nmask);
+ else
+ page = alloc_buddy_huge_page(h, gfp_mask,
+ nid, nmask);
+ if (!page)
+ return NULL;
+
+ if (hstate_is_gigantic(h))
+ prep_compound_gigantic_page(page, huge_page_order(h));
+ prep_new_huge_page(h, page, page_to_nid(page));
+
+ return page;
+}
+
/*
* Allocates a fresh page to the hugetlb allocator pool in the node interleaved
* manner.
*/
-static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
+static int alloc_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
{
struct page *page;
int nr_nodes, node;
gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- if (hstate_is_gigantic(h))
- page = alloc_gigantic_page(h, gfp_mask,
- node, nodes_allowed);
- else
- page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask,
- node, nodes_allowed);
+ page = alloc_fresh_huge_page(h, gfp_mask, node, nodes_allowed);
if (page)
break;
-
}
if (!page)
return 0;
- if (hstate_is_gigantic(h))
- prep_compound_gigantic_page(page, huge_page_order(h));
- prep_new_huge_page(h, page, page_to_nid(page));
put_page(page); /* free it into the hugepage allocator */
return 1;
@@ -1537,7 +1552,7 @@ int dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn)
/*
* Allocates a fresh surplus page from the page allocator.
*/
-static struct page *__alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
+static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nmask)
{
struct page *page = NULL;
@@ -1550,7 +1565,7 @@ static struct page *__alloc_surplus_huge_page(struct
hstate *h, gfp_t gfp_mask,
goto out_unlock;
spin_unlock(&hugetlb_lock);
- page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask, nid, nmask);
+ page = alloc_fresh_huge_page(h, gfp_mask, nid, nmask);
if (!page)
goto out_unlock;
@@ -1567,16 +1582,8 @@ static struct pag
[PATCH 3/6] mm, hugetlb: do not rely on overcommit limit during migration
From: Michal Hocko
hugepage migration relies on __alloc_buddy_huge_page to get a new page.
This has 2 main disadvantages.
1) it doesn't allow to migrate any huge page if the pool is used
completely which is not an exceptional case as the pool is static and
unused memory is just wasted.
2) it leads to a weird semantic when migration between two numa nodes
might increase the pool size of the destination NUMA node while the page
is in use. The issue is caused by per NUMA node surplus pages tracking
(see free_huge_page).
Address both issues by changing the way how we allocate and account
pages allocated for migration. Those should temporal by definition.
So we mark them that way (we will abuse page flags in the 3rd page)
and update free_huge_page to free such pages to the page allocator.
Page migration path then just transfers the temporal status from the
new page to the old one which will be freed on the last reference.
The global surplus count will never change during this path but we still
have to be careful when migrating a per-node suprlus page. This is now
handled in move_hugetlb_state which is called from the migration path
and it copies the hugetlb specific page state and fixes up the
accounting when needed
Rename __alloc_buddy_huge_page to __alloc_surplus_huge_page to better
reflect its purpose. The new allocation routine for the migration path
is __alloc_migrate_huge_page.
The user visible effect of this patch is that migrated pages are really
temporal and they travel between NUMA nodes as per the migration
request:
Before migration
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:0
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
After
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:1
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
with the previous implementation, both nodes would have nr_hugepages:1
until the page is freed.
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
include/linux/hugetlb.h | 3 ++
mm/hugetlb.c| 111 +---
mm/migrate.c| 3 +-
3 files changed, 99 insertions(+), 18 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 944e6e8bd572..66992348531e 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -119,6 +119,7 @@ long hugetlb_unreserve_pages(struct inode *inode, long
start, long end,
long freed);
bool isolate_huge_page(struct page *page, struct list_head *list);
void putback_active_hugepage(struct page *page);
+void move_hugetlb_state(struct page *oldpage, struct page *newpage, int
reason);
void free_huge_page(struct page *page);
void hugetlb_fix_reserve_counts(struct inode *inode);
extern struct mutex *hugetlb_fault_mutex_table;
@@ -157,6 +158,7 @@ unsigned long hugetlb_change_protection(struct
vm_area_struct *vma,
unsigned long address, unsigned long end, pgprot_t newprot);
bool is_hugetlb_entry_migration(pte_t pte);
+
#else /* !CONFIG_HUGETLB_PAGE */
static inline void reset_vma_resv_huge_pages(struct vm_area_struct *vma)
@@ -197,6 +199,7 @@ static inline bool isolate_huge_page(struct page *page,
struct list_head *list)
return false;
}
#define putback_active_hugepage(p) do {} while (0)
+#define move_hugetlb_state(old, new, reason) do {} while (0)
static inline unsigned long hugetlb_change_protection(struct vm_area_struct
*vma,
unsigned long address, unsigned long end, pgprot_t newprot)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 360765156c7c..f260ffa26363 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "internal.h"
int hugetlb_max_hstate __read_mostly;
@@ -1219,6 +1220,28 @@ static void clear_page_huge_active(struct page *page)
ClearPagePrivate(&page[1]);
}
+/*
+ * Internal hugetlb specific page flag. Do not use outside of the hugetlb
+ * code
+ */
+static inline bool PageHugeTemporary(struct page *page)
+{
+ if (!PageHuge(page))
+ return false;
+
+ return (unsigned long)page[2].mapping == -1U;
+}
+
+static inline void SetPageHugeTemporary(struct page *page)
+{
+ page[2].mapping = (void *
[PATCH] slimbus: qcom: add HAS_IOMEM dependency
From: Srinivas Kandagatla Below build failure was reported on UML, ERROR: "devm_ioremap_resource" [drivers/slimbus/slim-qcom-ctrl.ko] undefined! ERROR: "__ioread32_copy" [drivers/slimbus/slim-qcom-ctrl.ko] undefined! ERROR: "__iowrite32_copy" [drivers/slimbus/slim-qcom-ctrl.ko] undefined! ERROR: "devm_ioremap" [drivers/slimbus/slim-qcom-ctrl.ko] undefined! This patch fixes it by making qcom slimbus depend on HAS_IOMEM, as these are only defined when HAS_IOMEM is selected. Reported-by: Thomas Meyer Signed-off-by: Srinivas Kandagatla --- drivers/slimbus/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig index 78bdd4808282..1a632fad597e 100644 --- a/drivers/slimbus/Kconfig +++ b/drivers/slimbus/Kconfig @@ -16,6 +16,7 @@ if SLIMBUS config SLIM_QCOM_CTRL tristate "Qualcomm SLIMbus Manager Component" depends on SLIMBUS + depends on HAS_IOMEM help Select driver if Qualcomm's SLIMbus Manager Component is programmed using Linux kernel. -- 2.15.0
[PATCH 2/2] f2fs: clean up unneeded declaration
Commit 6afc662e68b5 ("f2fs: support flexible inline xattr size")
declared f2fs_sb_has_flexible_inline_xattr in f2fs.h for latter being
used in get_inline_xattr_addrs, but in latter version, related code
has been changed, leave f2fs_sb_has_flexible_inline_xattr w/o any
users. Let's remove it for cleanup.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ad19d29688ae..c082ae905f08 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2449,7 +2449,6 @@ static inline int get_extra_isize(struct inode *inode)
return F2FS_I(inode)->i_extra_isize / sizeof(__le32);
}
-static inline int f2fs_sb_has_flexible_inline_xattr(struct super_block *sb);
static inline int get_inline_xattr_addrs(struct inode *inode)
{
return F2FS_I(inode)->i_inline_xattr_size;
--
2.15.0.55.gc2ece9dc4de6
[PATCH 1/2] f2fs: use flexible array for f2fs_checkpoint::sit_nat_version_bitmap
If we need an array with variable size in the end of structure, we
can utilize flexible array feature which is supported in C99, so
let's change sit_nat_version_bitmap[] to flexible array in struct
f2fs_checkpoint for readability.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 4 ++--
include/linux/f2fs_fs.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 83d1f697388b..ad19d29688ae 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1719,13 +1719,13 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info
*sbi, int flag)
if (__cp_payload(sbi) > 0) {
if (flag == NAT_BITMAP)
- return &ckpt->sit_nat_version_bitmap;
+ return ckpt->sit_nat_version_bitmap;
else
return (unsigned char *)ckpt + F2FS_BLKSIZE;
} else {
offset = (flag == NAT_BITMAP) ?
le32_to_cpu(ckpt->sit_ver_bitmap_bytesize) : 0;
- return &ckpt->sit_nat_version_bitmap + offset;
+ return ckpt->sit_nat_version_bitmap + offset;
}
}
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index 43e98d30d2df..564f65fc192f 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -157,7 +157,7 @@ struct f2fs_checkpoint {
unsigned char alloc_type[MAX_ACTIVE_LOGS];
/* SIT and NAT version bitmap */
- unsigned char sit_nat_version_bitmap[1];
+ unsigned char sit_nat_version_bitmap[];
} __packed;
/*
--
2.15.0.55.gc2ece9dc4de6
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
Hi Marc,
On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier wrote:
> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>> When an interrupt is moved across node collections on ThunderX2
>
> node collections?
ok, i will rephrase it.
i was intended to say cross NUMA node collection/cpu affinity change.
>
>> multi Socket platform, an interrupt stops routed to new collection
>> and results in loss of interrupts.
>>
>> Adding workaround to issue INV after MOVI for cross-node collection
>> move to flush out the cached entry.
>>
>> Signed-off-by: Ganapatrao Kulkarni
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 11 +++
>> drivers/irqchip/irq-gic-v3-its.c | 24
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/arm64/silicon-errata.txt
>> b/Documentation/arm64/silicon-errata.txt
>> index fc1c884..fb27cb5 100644
>> --- a/Documentation/arm64/silicon-errata.txt
>> +++ b/Documentation/arm64/silicon-errata.txt
>> @@ -63,6 +63,7 @@ stable kernels.
>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
>>|
>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115
>>|
>> | Cavium | ThunderX SMMUv2 | #27704 | N/A
>>|
>> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
>>|
>> | Cavium | ThunderX2 SMMUv3| #74 | N/A
>>|
>> | Cavium | ThunderX2 SMMUv3| #126| N/A
>>|
>> || | |
>>|
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c9a7e9e..71a7e30 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>
>> If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_174
>> + bool "Cavium ThunderX2 erratum 174"
>> + depends on NUMA
>
> Why? This system will be affected no matter whether NUMA is selected or not.
it does not makes sense to enable on non-NUMA/single socket platforms.
By default NUMA is enabled on ThunderX2 dual socket platforms.
>
>> + default y
>> + help
>> + LPI stops routed to redistributors after inter node collection
>> + move in ITS. Enable workaround to invalidate ITS entry after
>> + inter-node collection move.
>
> That's a very terse description. Nobody knows what an LPI, a
> redistributor or a collection is. Please explain what the erratum is in
> layman's terms (Cavium ThunderX2 systems may loose interrupts on
> affinity change) so that people understand whether or not they are affected.
ok, i will rephrase it in next version.
>
>> +
>> + If unsure, say Y.
>> +
>> config CAVIUM_ERRATUM_22375
>> bool "Cavium erratum 22375, 24313"
>> default y
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d8b9c96 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -46,6 +46,7 @@
>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>
>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>
>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const
>> struct cpumask *mask_val,
>> if (cpu != its_dev->event_map.col_map[id]) {
>> target_col = &its_dev->its->collections[cpu];
>> its_send_movi(its_dev, target_col, id);
>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>> + /* Issue INV for cross node collection move. */
>> + if (cpu_to_node(cpu) !=
>> + cpu_to_node(its_dev->event_map.col_map[id]))
>> + its_send_inv(its_dev, id);
>> + }
>
> What happens if an interrupt happens after the MOV, but before the INV?
there can be drop, if interrupt happens before INV, however, it is
highly unlikely that we will hit the issue since MOVI and INV are
executed back to back. this workaround fixed issue seen on couple of
IOs.
>
>> its_dev->event_map.col_map[id] = cpu;
>> irq_data_update_effective_affinity(d, cpumask_of(cpu));
>> }
>> @@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
>> }
>> }
>>
>> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
>> +{
>> + struct its_node *its = data;
>> +
>> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
>> +
>> + return true;
>> +}
>> +
>> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
>> {
>> struct its_node *its = data;
>> @@ -3031,
[PATCH] doc: memory-barriers: reStructure Text
Let PDF & HTML's be created out of memory-barriers Text by
reStructuring.
reStructuring done were,
1. Section headers modification, lower header case except start
2. Removal of manual index(contents section), since it now gets created
automatically for html/pdf
3. Internal cross reference for easy navigation
4. Alignment adjustments
5. Strong emphasis made wherever there was emphasis earlier (through
other ways), strong was chosen as normal emphasis showed in italics,
which was felt to be not enough & strong showed it in bold
6. ASCII text & code snippets in literal blocks
7. Backquotes for inline instances in the paragraph's where they are
expressed not in English, but in C, pseudo-code, file path etc.
8. Notes section created out of the earlier notes
9. Manual numbering replaced by auto-numbering
10.Bibliography (References section) made such that it can be
cross-linked
Signed-off-by: afzal mohammed
---
Hi,
With this change, pdf & html could be generated. There certainly are
improvements to be made, but thought of first knowing whether migrating
memory-barriers from txt to rst is welcome.
The location chosen is "Documentation/kernel-hacking", i was unsure
where this should reside & there was no .rst file in top-level directory
"Documentation", so put it into one of the existing folder that seemed
to me as not that unsuitable.
Other files refer to memory-barrier.txt, those also needs to be
adjusted based on where .rst can reside.
afzal
Documentation/kernel-hacking/index.rst |1 +
.../memory-barriers.rst} | 1707 ++--
2 files changed, 837 insertions(+), 871 deletions(-)
rename Documentation/{memory-barriers.txt =>
kernel-hacking/memory-barriers.rst} (63%)
diff --git a/Documentation/kernel-hacking/index.rst
b/Documentation/kernel-hacking/index.rst
index fcb0eda3cca3..20eb56d02ea5 100644
--- a/Documentation/kernel-hacking/index.rst
+++ b/Documentation/kernel-hacking/index.rst
@@ -7,3 +7,4 @@ Kernel Hacking Guides
hacking
locking
+ memory-barriers
diff --git a/Documentation/memory-barriers.txt
b/Documentation/kernel-hacking/memory-barriers.rst
similarity index 63%
rename from Documentation/memory-barriers.txt
rename to Documentation/kernel-hacking/memory-barriers.rst
index 479ecec80593..60b6a8be8a09 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/kernel-hacking/memory-barriers.rst
@@ -1,14 +1,13 @@
-
-LINUX KERNEL MEMORY BARRIERS
-
+
+Linux kernel memory barriers
+
-By: David Howells
-Paul E. McKenney
-Will Deacon
-Peter Zijlstra
+:Authors: David Howells ,
+ Paul E. McKenney ,
+ Will Deacon ,
+ Peter Zijlstra
-==
-DISCLAIMER
+Disclaimer
==
This document is not a specification; it is intentionally (for the sake of
@@ -21,10 +20,9 @@ hardware.
The purpose of this document is twofold:
- (1) to specify the minimum functionality that one can rely on for any
- particular barrier, and
-
- (2) to provide a guide as to how to use the barriers that are available.
+* to specify the minimum functionality that one can rely on for any
+ particular barrier
+* to provide a guide as to how to use the barriers that are available
Note that an architecture can provide more than the minimum requirement
for any particular barrier, but if the architecture provides less than
@@ -35,78 +33,10 @@ architecture because the way that arch works renders an
explicit barrier
unnecessary in that case.
-
-CONTENTS
-
-
- (*) Abstract memory access model.
-
- - Device operations.
- - Guarantees.
-
- (*) What are memory barriers?
-
- - Varieties of memory barrier.
- - What may not be assumed about memory barriers?
- - Data dependency barriers.
- - Control dependencies.
- - SMP barrier pairing.
- - Examples of memory barrier sequences.
- - Read memory barriers vs load speculation.
- - Multicopy atomicity.
-
- (*) Explicit kernel barriers.
-
- - Compiler barrier.
- - CPU memory barriers.
- - MMIO write barrier.
-
- (*) Implicit kernel memory barriers.
-
- - Lock acquisition functions.
- - Interrupt disabling functions.
- - Sleep and wake-up functions.
- - Miscellaneous functions.
-
- (*) Inter-CPU acquiring barrier effects.
-
- - Acquires vs memory accesses.
- - Acquires vs I/O accesses.
-
- (*) Where are memory barriers needed?
-
- - Interprocessor interaction.
- - Atomic operations.
- - Accessing devices.
- - Interrupts.
-
- (*) Kernel I/O barrier effects.
-
- (*) Assumed minimum execution ordering model.
-
- (*) The effects of the cpu cache.
-
- - Cache coherency.
- - Cache coherency vs DMA.
- - Cache coherency vs MMIO.
-
- (*) The things CPUs
[PATCH 1/6] mm, hugetlb: unify core page allocation accounting and initialization
From: Michal Hocko
hugetlb allocator has two entry points to the page allocator
- alloc_fresh_huge_page_node
- __hugetlb_alloc_buddy_huge_page
The two differ very subtly in two aspects. The first one doesn't care
about HTLB_BUDDY_* stats and it doesn't initialize the huge page.
prep_new_huge_page is not used because it not only initializes hugetlb
specific stuff but because it also put_page and releases the page to
the hugetlb pool which is not what is required in some contexts. This
makes things more complicated than necessary.
Simplify things by a) removing the page allocator entry point duplicity
and only keep __hugetlb_alloc_buddy_huge_page and b) make
prep_new_huge_page more reusable by removing the put_page which moves
the page to the allocator pool. All current callers are updated to call
put_page explicitly. Later patches will add new callers which won't
need it.
This patch shouldn't introduce any functional change.
Reviewed-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Signed-off-by: Michal Hocko
---
mm/hugetlb.c | 61 +---
1 file changed, 29 insertions(+), 32 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4137fb67cd79..a8959667f539 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1157,6 +1157,7 @@ static struct page *alloc_fresh_gigantic_page_node(struct
hstate *h, int nid)
if (page) {
prep_compound_gigantic_page(page, huge_page_order(h));
prep_new_huge_page(h, page, nid);
+ put_page(page); /* free it into the hugepage allocator */
}
return page;
@@ -1304,7 +1305,6 @@ static void prep_new_huge_page(struct hstate *h, struct
page *page, int nid)
h->nr_huge_pages++;
h->nr_huge_pages_node[nid]++;
spin_unlock(&hugetlb_lock);
- put_page(page); /* free it into the hugepage allocator */
}
static void prep_compound_gigantic_page(struct page *page, unsigned int order)
@@ -1381,41 +1381,49 @@ pgoff_t __basepage_index(struct page *page)
return (index << compound_order(page_head)) + compound_idx;
}
-static struct page *alloc_fresh_huge_page_node(struct hstate *h, int nid)
+static struct page *__hugetlb_alloc_buddy_huge_page(struct hstate *h,
+ gfp_t gfp_mask, int nid, nodemask_t *nmask)
{
+ int order = huge_page_order(h);
struct page *page;
- page = __alloc_pages_node(nid,
- htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
-
__GFP_RETRY_MAYFAIL|__GFP_NOWARN,
- huge_page_order(h));
- if (page) {
- prep_new_huge_page(h, page, nid);
- }
+ gfp_mask |= __GFP_COMP|__GFP_RETRY_MAYFAIL|__GFP_NOWARN;
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+ page = __alloc_pages_nodemask(gfp_mask, order, nid, nmask);
+ if (page)
+ __count_vm_event(HTLB_BUDDY_PGALLOC);
+ else
+ __count_vm_event(HTLB_BUDDY_PGALLOC_FAIL);
return page;
}
+/*
+ * Allocates a fresh page to the hugetlb allocator pool in the node interleaved
+ * manner.
+ */
static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
{
struct page *page;
int nr_nodes, node;
- int ret = 0;
+ gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = alloc_fresh_huge_page_node(h, node);
- if (page) {
- ret = 1;
+ page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask,
+ node, nodes_allowed);
+ if (page)
break;
- }
+
}
- if (ret)
- count_vm_event(HTLB_BUDDY_PGALLOC);
- else
- count_vm_event(HTLB_BUDDY_PGALLOC_FAIL);
+ if (!page)
+ return 0;
- return ret;
+ prep_new_huge_page(h, page, page_to_nid(page));
+ put_page(page); /* free it into the hugepage allocator */
+
+ return 1;
}
/*
@@ -1523,17 +1531,6 @@ int dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn)
return rc;
}
-static struct page *__hugetlb_alloc_buddy_huge_page(struct hstate *h,
- gfp_t gfp_mask, int nid, nodemask_t *nmask)
-{
- int order = huge_page_order(h);
-
- gfp_mask |= __GFP_COMP|__GFP_RETRY_MAYFAIL|__GFP_NOWARN;
- if (nid == NUMA_NO_NODE)
- nid = numa_mem_id();
- return __alloc_pages_nodemask(gfp_mask, order, nid, nmask);
-}
-
static struct page *__alloc_buddy_huge_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nmask)
{
@@ -1589,11 +1586,9 @@ static struct page *__alloc_buddy_huge_page(struct
hstate *h, gfp_t gfp_mask,
*/
h->nr_huge_pages_node[r_nid]++;
h->surplus_
Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move
On 01/03/2018 02:28 PM, Michal Hocko wrote:
> On Wed 03-01-18 14:12:17, Anshuman Khandual wrote:
>> On 12/08/2017 09:45 PM, Michal Hocko wrote:
> [...]
[...]
>>
>> This reuses the existing page allocation helper from migrate_pages() system
>> call. But all these allocator helper names for migrate_pages() function are
>> really confusing. Even in this case alloc_new_node_page and the original
>> new_node_page() which is still getting used in do_migrate_range() sounds
>> similar even if their implementation is quite different. IMHO either all of
>> them should be moved to the header file with proper differentiating names
>> or let them be there in their respective files with these generic names and
>> clean them up later.
>
> I believe I've tried that but I couldn't make them into a single header
> file easily because of header file dependencies. I agree that their
> names are quite confusing. Feel free to send a patch to clean this up.
Sure. Will try once this one gets into mmotm.
[...]
>>
>>
>> Just a nit. new_page_node() and store_status() seems different. Then why
>> the git diff looks so clumsy.
>
> Kirill was suggesting to use --patience to general the diff which leads
> to a slightly better output. It has been posted as a separate email [1].
> Maybe you will find that one easier to review.
>
> [1] http://lkml.kernel.org/r/20171213143948.gm25...@dhcp22.suse.cz
Yeah it does look better.
[...]
>>> - return thp;
>>> - } else
>>> - return __alloc_pages_node(pm->node,
>>> - GFP_HIGHUSER_MOVABLE | __GFP_THISNODE, 0);
>>> + err = migrate_pages(pagelist, alloc_new_node_page, NULL, node,
>>> + MIGRATE_SYNC, MR_SYSCALL);
>>> + if (err)
>>> + putback_movable_pages(pagelist);
>>> + return err;
>>> }
>>
>> Even this one. IIUC, do_move_pages_to_node() migrate a chunk of pages
>> at a time which belong to the same target node. Perhaps the name should
>> suggest so. All these helper page migration helper functions sound so
>> similar.
>
> What do you suggest? I find do_move_pages_to_node quite explicit on its
> purpose.
Sure. Not a big deal.
[...]
>>> {
>>> + struct vm_area_struct *vma;
>>> + struct page *page;
>>> + unsigned int follflags;
>>> int err;
>>> - struct page_to_node *pp;
>>> - LIST_HEAD(pagelist);
>>>
>>> down_read(&mm->mmap_sem);
>>
>> Holding mmap_sem for individual pages makes sense. Current
>> implementation is holding it for an entire batch.
>
> I didn't bother to optimize this path to be honest. It is true that lock
> batching can lead to improvements but that would complicate the code
> (how many patches to batch?) so I've left that for later if somebody
> actually sees any problem.
>
>>> + err = -EFAULT;
>>> + vma = find_vma(mm, addr);
>>> + if (!vma || addr < vma->vm_start || !vma_migratable(vma))
>>
>> While here, should not we add 'addr > vma->vm_end' into this condition ?
>
> No. See what find_vma does.
>
Right.
> [...]
>
> Please cut out the quoted reply to minimum
Sure will do.
>
>>> @@ -1593,79 +1556,80 @@ static int do_pages_move(struct mm_struct *mm,
>>> nodemask_t task_nodes,
>>> const int __user *nodes,
>>> int __user *status, int flags)
>>> {
>>> - struct page_to_node *pm;
>>> - unsigned long chunk_nr_pages;
>>> - unsigned long chunk_start;
>>> - int err;
>>> -
>>> - err = -ENOMEM;
>>> - pm = (struct page_to_node *)__get_free_page(GFP_KERNEL);
>>> - if (!pm)
>>> - goto out;
>>> + int chunk_node = NUMA_NO_NODE;
>>> + LIST_HEAD(pagelist);
>>> + int chunk_start, i;
>>> + int err = 0, err1;
>>
>> err init might not be required, its getting assigned to -EFAULT right away.
>
> No, nr_pages might be 0 AFAICS.
Right but there is another err = 0 after the for loop.
>
> [...]
>>> + if (chunk_node == NUMA_NO_NODE) {
>>> + chunk_node = node;
>>> + chunk_start = i;
>>> + } else if (node != chunk_node) {
>>> + err = do_move_pages_to_node(mm, &pagelist, chunk_node);
>>> + if (err)
>>> + goto out;
>>> + err = store_status(status, chunk_start, chunk_node, i -
>>> chunk_start);
>>> + if (err)
>>> + goto out;
>>> + chunk_start = i;
>>> + chunk_node = node;
>>> }
[...]
>>> + err = do_move_pages_to_node(mm, &pagelist, chunk_node);
>>> + if (err)
>>> + goto out;
>>> + if (i > chunk_start) {
>>> + err = store_status(status, chunk_start, chunk_node, i -
>>> chunk_start);
>>> + if (err)
>>> + goto out;
>>> + }
>>> + chunk_node = NUMA_NO_NODE;
>>
>> This block of code is bit confusing.
>
> I believe this is easier to grasp when looking at the r
Re: [PATCH 2/4] extcon: axp288: Remove unused platform data
On Wed, 03 Jan 2018, Chanwoo Choi wrote: > Dear Lee, > > On 2018년 01월 02일 18:16, Lee Jones wrote: > > On Tue, 02 Jan 2018, Chanwoo Choi wrote: > > > >> + MFD Maintainer (Lee Jones ) > >> > >> Hi Hans, > >> > >> You better to use the scripts/get_maintainer.pl for the mailing list. > >> I added the MFD maintainer. > >> > >> This patch looks good to me. > >> Reviewed-by: Chanwoo Choi > >> > >> > >> Best Regards, > >> Chanwoo Choi > >> > >> On 2017년 12월 22일 21:36, Hans de Goede wrote: > >>> This is not used / set anywhere in the tree. > >>> > >>> Signed-off-by: Hans de Goede > >>> --- > >>> drivers/extcon/extcon-axp288.c | 35 +-- > >>> include/linux/mfd/axp20x.h | 5 - > > > > Acked-by: Lee Jones > > > > I already made the immutable branch[1] for both mfd and extcon. > [1] https://lkml.org/lkml/2017/12/15/133 > > I added the additional patch for 'include/linux/mfd/axp20x.h' > If you want to need to apply it on mfd tree, please apply them of immutable > branch. > > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > ib-extcon-mfd-4.16 How is this possible? ib-extcon-mfd-4.16 is already immutable. I believe you should have created a new tag: ib-extcon-mfd-4.16-1 ... based on ib-extcon-mfd-4.16. > for you to fetch changes up to 9bf317e900a19a857eb9921c9441a92e89f40415: > > extcon: axp288: Remove unused platform data (2018-01-03 10:11:02 +0900) > > > Arvind Yadav (1): > extcon: axp288:: Handle return value of platform_get_irq > > Benson Leung (1): > extcon: usbc-cros-ec: add support to notify USB type cables. > > Hans de Goede (2): > extcon: axp288: Remove unused extcon_nb struct member > extcon: axp288: Remove unused platform data > > drivers/extcon/extcon-axp288.c | 39 +- > drivers/extcon/extcon-usbc-cros-ec.c | 142 > ++- > include/linux/mfd/axp20x.h | 5 -- > include/linux/mfd/cros_ec_commands.h | 17 + > 4 files changed, 159 insertions(+), 44 deletions(-) > -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] nvme: check ctrl.tagset before start ns scan
Hi Jianchao, ctrl.tagset maybe NULL due to failure of io queue setup or blk-mq tagset allocation in nvme_reset_work. Then panic would come up. To fix this, just add ctrl.tagset check in nvme_scan_work. This came up before (and forgotten...) I think we should not have state indicators other than ctrl->state. How about instead we add a new state NVME_CTRL_ADMIN_LIVE when we have no I/O queues.
[PATCH] Staging: greybus: audio_codec.h: Change uint32_t to u32
This patch fixes the following checkpatch.pl issues:
CHECK: Prefer kernel type 'u32' over 'uint32_t'
+ uint32_t format, rate;
CHECK: Prefer kernel type 'u32' over 'uint32_t'
+ uint32_t *rate, u8 *channels,
CHECK: Prefer kernel type 'u32' over 'uint32_t'
+ uint32_t rate, u8 channels,
Signed-off-by: Sumit Pundir
---
drivers/staging/greybus/audio_codec.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.h
b/drivers/staging/greybus/audio_codec.h
index 161b37c..fd7b893 100644
--- a/drivers/staging/greybus/audio_codec.h
+++ b/drivers/staging/greybus/audio_codec.h
@@ -53,7 +53,7 @@ enum gbaudio_codec_state {
struct gbaudio_stream_params {
int state;
u8 sig_bits, channels;
- uint32_t format, rate;
+ u32 format, rate;
};
struct gbaudio_codec_dai {
@@ -183,12 +183,12 @@ extern int gb_audio_gb_enable_widget(struct gb_connection
*connection,
extern int gb_audio_gb_disable_widget(struct gb_connection *connection,
u8 widget_id);
extern int gb_audio_gb_get_pcm(struct gb_connection *connection,
- u16 data_cport, uint32_t *format,
- uint32_t *rate, u8 *channels,
+ u16 data_cport, u32 *format,
+ u32 *rate, u8 *channels,
u8 *sig_bits);
extern int gb_audio_gb_set_pcm(struct gb_connection *connection,
- u16 data_cport, uint32_t format,
- uint32_t rate, u8 channels,
+ u16 data_cport, u32 format,
+ u32 rate, u8 channels,
u8 sig_bits);
extern int gb_audio_gb_set_tx_data_size(struct gb_connection *connection,
u16 data_cport, u16 size);
--
2.7.4
Re: [PATCH] Fix read buffer overflow in delta-ipc
Hi Andi, Thanks for the patch but I would suggest to use strlcpy instead, this will guard msg.name overwriting and add the NULL termination in case of truncation: - memcpy(msg.name, name, sizeof(msg.name)); - msg.name[sizeof(msg.name) - 1] = 0; + strlcpy(msg.name, name, sizeof(msg.name)); Best regards, Hugues. On 12/22/2017 01:12 AM, Andi Kleen wrote: > From: Andi Kleen > > The single caller passes a string to delta_ipc_open, which copies with a > fixed size larger than the string. So it copies some random data after > the original string the ro segment. > > If the string was at the end of a page it may fault. > > Just copy the string with a normal strcpy after clearing the field. > > Found by a LTO build (which errors out) > because the compiler inlines the functions and can resolve > the string sizes and triggers the compile time checks in memcpy. > > In function ‘memcpy’, > inlined from ‘delta_ipc_open.constprop’ at > linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0, > inlined from ‘delta_mjpeg_ipc_open’ at > linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0, > inlined from ‘delta_mjpeg_decode’ at > linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0: > /home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to > ‘__read_overflow2’ declared with attribute error: detected read beyond size > of object passed as 2nd parameter > __read_overflow2(); > > Cc: hugues.fruc...@st.com > Cc: mche...@s-opensource.com > Signed-off-by: Andi Kleen > --- > drivers/media/platform/sti/delta/delta-ipc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/sti/delta/delta-ipc.c > b/drivers/media/platform/sti/delta/delta-ipc.c > index 41e4a4c259b3..b6c256e3ceb6 100644 > --- a/drivers/media/platform/sti/delta/delta-ipc.c > +++ b/drivers/media/platform/sti/delta/delta-ipc.c > @@ -175,8 +175,8 @@ int delta_ipc_open(struct delta_ctx *pctx, const char > *name, > msg.ipc_buf_size = ipc_buf_size; > msg.ipc_buf_paddr = ctx->ipc_buf->paddr; > > - memcpy(msg.name, name, sizeof(msg.name)); > - msg.name[sizeof(msg.name) - 1] = 0; > + memset(msg.name, 0, sizeof(msg.name)); > + strcpy(msg.name, name); > > msg.param_size = param->size; > memcpy(ctx->ipc_buf->vaddr, param->data, msg.param_size); >
[PATCH] Staging: greybus: audio_codec.c: Change uint32_t to u32
This patch fixes the following checkpatch.pl issue at multiple lines:
CHECK: Prefer kernel type 'u32' over 'uint32_t'
+ uint32_t format, rate;
Signed-off-by: Sumit Pundir
---
drivers/staging/greybus/audio_codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index fdb9e83..d81cdc9 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -47,7 +47,7 @@ static int gbaudio_module_enable_tx(struct gbaudio_codec_info
*codec,
int module_state, ret = 0;
u16 data_cport, i2s_port, cportid;
u8 sig_bits, channels;
- uint32_t format, rate;
+ u32 format, rate;
struct gbaudio_data_connection *data;
struct gbaudio_stream_params *params;
@@ -182,7 +182,7 @@ static int gbaudio_module_enable_rx(struct
gbaudio_codec_info *codec,
int module_state, ret = 0;
u16 data_cport, i2s_port, cportid;
u8 sig_bits, channels;
- uint32_t format, rate;
+ u32 format, rate;
struct gbaudio_data_connection *data;
struct gbaudio_stream_params *params;
@@ -412,7 +412,7 @@ static int gbcodec_hw_params(struct snd_pcm_substream
*substream,
{
int ret;
u8 sig_bits, channels;
- uint32_t format, rate;
+ u32 format, rate;
struct gbaudio_module_info *module;
struct gbaudio_data_connection *data;
struct gb_bundle *bundle;
--
2.7.4
[PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks as maintainers for the EFI test driver and efivarfs file system. Signed-off-by: Matt Fleming --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Ard, if you want to add yourself as co-maintainer of the EFI test driver or efivarfs, please go ahead. I'm sure no one would object. diff --git a/MAINTAINERS b/MAINTAINERS index d4fdcb12616c..9a41aa072e6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5150,15 +5150,13 @@ F: sound/usb/misc/ua101.c EFI TEST DRIVER L: linux-...@vger.kernel.org M: Ivan Hu -M: Matt Fleming S: Maintained F: drivers/firmware/efi/test/ EFI VARIABLE FILESYSTEM M: Matthew Garrett M: Jeremy Kerr -M: Matt Fleming -T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git L: linux-...@vger.kernel.org S: Maintained F: fs/efivarfs/ @@ -5319,7 +5317,6 @@ S:Supported F: security/integrity/evm/ EXTENSIBLE FIRMWARE INTERFACE (EFI) -M: Matt Fleming M: Ard Biesheuvel L: linux-...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git -- 2.14.2
Re: [PATCH] thermal: Use power efficient workqueue
On 3 January 2018 at 10:24, Leo Yan wrote:
> Thermal core framework uses the system_freezable_wq workqueue as its
> workqueue for polling temperature. Using system_freezable_wq workqueue
> prevents the scheduler to make smart decision about the best place to
> schedule the work.
>
> This commit replaces system_freezable_wq with
> system_freezable_power_efficient_wq. With kernel configuration
> CONFIG_WQ_POWER_EFFICIENT is enabled, the work can be scheduled on the
> best CPU from a power or a performance point of view.
>
> This commit is inspired by Vincent Guittot patch "netfilter: conntrack:
> use power efficient workqueue" and verified on 96boards Hikey960.
>
> Cc: Eduardo Valentin
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Vincent Guittot
> Signed-off-by: Leo Yan
Acked-by: Vincent Guittot
> ---
> drivers/thermal/thermal_core.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 2b1b0ba..ba90f71 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -293,11 +293,12 @@ static void thermal_zone_device_set_polling(struct
> thermal_zone_device *tz,
> int delay)
> {
> if (delay > 1000)
> - mod_delayed_work(system_freezable_wq, &tz->poll_queue,
> + mod_delayed_work(system_freezable_power_efficient_wq,
> +&tz->poll_queue,
> round_jiffies(msecs_to_jiffies(delay)));
> else if (delay)
> - mod_delayed_work(system_freezable_wq, &tz->poll_queue,
> -msecs_to_jiffies(delay));
> + mod_delayed_work(system_freezable_power_efficient_wq,
> +&tz->poll_queue, msecs_to_jiffies(delay));
> else
> cancel_delayed_work(&tz->poll_queue);
> }
> --
> 2.7.4
>
Re: [PATCH v17 0/5] ZII RAVE platform driver
Well I guess we better at least include them in the conversation. Stephen and Andrew added. On Tue, 02 Jan 2018, Andrey Smirnov wrote: > On Tue, Jan 2, 2018 at 7:17 AM, Lee Jones wrote: > > On Wed, 20 Dec 2017, Andrey Smirnov wrote: > > > >> Everyone: > >> > >> This patch series is v17 of the driver for supervisory processor found > >> on RAVE series of devices from ZII. Supervisory processor is a PIC > >> microcontroller connected to various electrical subsystems on RAVE > >> devices whose firmware implements protocol to command/qery them. > >> > >> NOTE: > >> > >> * This driver dependends on crc_ccitt_false(), added by > >>2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch > >>was pulled in by Andrew Morton and is currently avaiting users, so > >>this series might have to go in through Andrew's tree > > > > Hmm... well that's annoying! I just attempted to merge this set, but > > early build tests fail due to a dependency already merged into -next. > > > > ../drivers/mfd/rave-sp.c:227:25: error: > > implicit declaration of function ‘crc_ccitt_false’ > > [-Werror=implicit-function-declaration] > > > > We need to figure out if either of the following are true: > > > > - Patch [0] can be dropped from Andrew's tree > >- ... and I can take it via the MFD tree instead > FWIW, it seems to me that the path above should be doable (and might > be simpler?). Let me know if any action needs to be taken on my part. > > Thanks, > Andrey Smirnov > > - Patch [0] is on an immutable branch I can pull in to my PR > > > > If not, it will have to wait until the next cycle. > > > > [0]: > > > > Author: Andrey Vostrikov > > Date: Mon Dec 25 22:39:57 2017 +1100 > > > > lib/crc-ccitt: add CCITT-FALSE CRC16 variant > > > > In support of a soon to be published MFD driver using serdev to talk to > > a supervisory processor that uses the CCITT-FALSE CRC16 variant in it's > > protocol, this patch was tested successfully on an i.MX6 ARM platform. > > > > Link: > > http://lkml.kernel.org/r/20170413142932.27287-1-andrew.smir...@gmail.com > > Signed-off-by: Andrey Vostrikov > > Signed-off-by: Andrey Smirnov > > Tested-by: Chris Healy > > Signed-off-by: Andrew Morton > > Signed-off-by: Stephen Rothwell -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all
No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: add "default y" to avoid breaking existing configs Signed-off-by: Vincent Legoll --- drivers/virtio/Kconfig | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index cff773f15b7e..290a1875e1d3 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -5,7 +5,11 @@ config VIRTIO bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG or CONFIG_S390_GUEST. -menu "Virtio drivers" +menuconfig VIRTIO_MENU + bool "Virtio drivers" + default y + +if VIRTIO_MENU config VIRTIO_PCI tristate "PCI driver for virtio devices" @@ -79,4 +83,4 @@ config VIRTIO_MMIO_CMDLINE_DEVICES If unsure, say 'N'. -endmenu +endif # VIRTIO_MENU -- 2.11.0
Re: [PATCH v6 00/11] Intel SGX Driver
Hi!
> Good evening Pavel et.al., I hope the New Year has started well for
> everyone.
:-). Stuff proceeds as usual. Too bad it is raining outside, instead
of snowing.
> > > > Would you list guarantees provided by SGX?
> > >
> > > Obviously, confidentiality and integrity. SGX was designed to address
> > > an Iago threat model, a very difficult challenge to address in
> > > reality.
>
> > Do you have link on "Iago threat model"?
>
> https://cseweb.ucsd.edu/~hovav/dist/iago.pdf
>
> > > I don't have the citation immediately available, but a bit-flip attack
> > > has also been described on enclaves. Due to the nature of the
> > > architecture, they tend to crash the enclave so they are more in the
> > > category of a denial-of-service attack, rather then a functional
> > > confidentiality or integrity compromise.
>
> > So ... even with SGX, host can generate bitflips in the enclave,
> > right?
>
> Correct.
...
I'd say that you can't generate bitflips because if you do hardware
will kill the enclave. This seems to be significant difference from
AMD "secure" memory encryption...
> > People usually assume that bitflip will lead "only" to
> > denial-of-service, but rowhammer work shows that even "random" bit
> > flips easily lead to priviledge escalation on javascript virtual
> > machines, and in similar way you can get root if you have user and
> > bit flips happen.
> >
> > So... I believe we should assume compromise is possible, not just
> > denial-of-service.
>
> Prudence always dictates that one assumes the worst. In this case
> however, the bitflip attacks against SGX enclaves are very definitely
> in the denial-of-service category. The attack is designed to trigger
> a hardware self-protection feature on the processor.
>
> Each page of memory which is initialized into an enclave has a
> metadata block associated with it which contains the integrity state
> of that page of memory. The MM{E,U} hardware on an SGX capable
> platform checks this integrity data on each page fetch request arising
> from addresses/pages inside of an enclave.
>
> Forcing a bitflip in enclave memory causes the next page fetch
> containing the bitflipped location to fail its integrity check. Since
> this technically shouldn't be possible, this situation was classified
> as a hardware failure which is handled by the processor locking its
> execution state, thus taking the machine down.
So you can't really do bitflips on the SGX protected memory, because
MM{E,U} hardware will catch that and kill machine if you try?
So SGX protected memory is not swappable?
> It would seem to be a misfeature for the self-protection mechanism to
> not generate some type of trappable fault rather then generating a
> processor lockup but hindsight is always 20/20. Philosophically this
> is a good example of security risk managment. Locking a machine is
> obviously problematic in a cloud service environment, but it has to be
> taken in the perspective of whether or not it would be preferable to
> have a successful privilege escalation attack which could result in
> exfiltration of sensitive data.
Ok, right, it should fault. They can fix it in new version?
> > Well, yes :-). And I believe someone is going to have fun with SGX
> > ;-).
>
> Arguably not as much fun as what appears to be pending, given what
> appears to be the difficulty of some Intel processors to deal with
> page faults induced by speculative memory references... :-)
Do you have more info on that? Will they actually leak information, or
is it just good for rowhammering the kernel memory?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[PATCH, v2] virtio: make VIRTIO a menuconfig to ease disabling it
No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: Added "default y" to avoid breaking existing configs Signed-off-by: Vincent Legoll
Re: [PATCH] alpha: fix crash if pthread_create races with signal delivery
On Tue, Jan 02, 2018 at 02:01:34PM -0500, Mikulas Patocka wrote: > On alpha, a process will crash if it attempts to start a thread and a > signal is delivered at the same time. The crash can be reproduced with > this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html > > The reason for the crash is this: > * we call the clone syscall > * we go to the function copy_process > * copy process calls copy_thread_tls, it is a wrapper around copy_thread > * copy_thread sets the tls pointer: childti->pcb.unique = regs->r20 > * copy_thread sets regs->r20 to zero > * we go back to copy_process > * copy process checks "if (signal_pending(current))" and returns > -ERESTARTNOINTR > * the clone syscall is restarted, but this time, regs->r20 is zero, so > the new thread is created with zero tls pointer > * the new thread crashes in start_thread when attempting to access tls > > The comment in the code says that setting the register r20 is some > compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so > we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug > by zeroing regs->r20 only if CLONE_SETTLS is not set. This bug was identified some three years ago; it triggers a failure in the glibc nptl/tst-eintr3 test. See: https://marc.info/?l=linux-alpha&m=140610647213217&w=2 and a fix was proposed by RTH, namely: https://marc.info/?l=linux-alpha&m=140675667715872&w=2 but was never included in the kernel because someone objected to breaking the ability to run OSF/1 executables. That patch also deleted the line to set childregs->r20 to 1 which I mark below. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org > > --- > arch/alpha/kernel/process.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux-stable/arch/alpha/kernel/process.c > === > --- linux-stable.orig/arch/alpha/kernel/process.c 2017-12-31 > 17:42:12.0 +0100 > +++ linux-stable/arch/alpha/kernel/process.c 2018-01-02 18:06:24.0 > +0100 > @@ -265,12 +265,13 @@ copy_thread(unsigned long clone_flags, u > application calling fork. */ > if (clone_flags & CLONE_SETTLS) > childti->pcb.unique = regs->r20; > + else > + regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */ > childti->pcb.usp = usp ?: rdusp(); > *childregs = *regs; > childregs->r0 = 0; > childregs->r19 = 0; > childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */ This line. Is it not also problematic? Cheers Michael. > - regs->r20 = 0; > stack = ((struct switch_stack *) regs) - 1; > *childstack = *stack; > childstack->r26 = (unsigned long) ret_from_fork; > -- > To unsubscribe from this list: send the line "unsubscribe linux-alpha" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] backlight: tdo24m: add the reset line gpio
On Sun, Dec 24, 2017 at 12:55:55PM +0100, Robert Jarzmik wrote: > Robert Jarzmik writes: > > > Daniel Thompson writes: > > > >> On Fri, Oct 13, 2017 at 09:42:48PM +0200, Robert Jarzmik wrote: > >> Also, this adds a new optional property, doesn't the devicetree binding > >> docs need to be update to match this? > > Ah yes, that too. I'll add it for v3. > Actually I won't ... because there is no description for tdo24m I could find. > > If that's a problem for you, I'll drop that patch as well. I think I'm ok to drop this, if only because based on current upstream state I think this code will never be given a reset line anyway (or is there a partner patch for mach-pxa that hasn't been posted yet). Daniel.
Re: linux-next: manual merge of the kvm-arm tree with Linus' tree
Thanks Stephen,
On Wed, Jan 3, 2018 at 3:38 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
> virt/kvm/arm/arch_timer.c
>
> between commit:
>
> 36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after
> vtimer_save_state")
>
> from Linus' tree and commit:
>
> 70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level")
>
> from the kvm-arm tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
The resolution looks correct to me.
cc'ing the KVM maintainers in case they want to merge kvm/master into
kvm/next to avoid the conflict going up to Linus.
Thanks,
-Christoffer
>
> diff --cc virt/kvm/arm/arch_timer.c
> index cc29a8148328,cfcd0323deab..
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@@ -92,27 -92,19 +92,26 @@@ static irqreturn_t kvm_arch_timer_handl
> {
> struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> struct arch_timer_context *vtimer;
> + u32 cnt_ctl;
>
> - if (!vcpu) {
> - pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> - return IRQ_NONE;
> - }
> - vtimer = vcpu_vtimer(vcpu);
> + /*
> + * We may see a timer interrupt after vcpu_put() has been called which
> + * sets the CPU's vcpu pointer to NULL, because even though the timer
> + * has been disabled in vtimer_save_state(), the hardware interrupt
> + * signal may not have been retired from the interrupt controller yet.
> + */
> + if (!vcpu)
> + return IRQ_HANDLED;
>
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> + vtimer = vcpu_vtimer(vcpu);
> - if (!vtimer->irq.level) {
> - cnt_ctl = read_sysreg_el0(cntv_ctl);
> - cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> - ARCH_TIMER_CTRL_IT_MASK;
> - if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE |
> ARCH_TIMER_CTRL_IT_STAT))
> - kvm_timer_update_irq(vcpu, true, vtimer);
> - }
> -
> - if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> ++ cnt_ctl = read_sysreg_el0(cntv_ctl);
> ++ cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> ++ ARCH_TIMER_CTRL_IT_MASK;
> ++ if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
> + kvm_timer_update_irq(vcpu, true, vtimer);
> +
> + if (static_branch_unlikely(&userspace_irqchip_in_use) &&
> + unlikely(!irqchip_in_kernel(vcpu->kvm)))
> kvm_vtimer_update_mask_user(vcpu);
>
> return IRQ_HANDLED;
Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move
On Wed 03-01-18 15:06:49, Anshuman Khandual wrote:
> On 01/03/2018 02:28 PM, Michal Hocko wrote:
> > On Wed 03-01-18 14:12:17, Anshuman Khandual wrote:
> >> On 12/08/2017 09:45 PM, Michal Hocko wrote:
[...]
> >>> @@ -1593,79 +1556,80 @@ static int do_pages_move(struct mm_struct *mm,
> >>> nodemask_t task_nodes,
> >>>const int __user *nodes,
> >>>int __user *status, int flags)
> >>> {
> >>> - struct page_to_node *pm;
> >>> - unsigned long chunk_nr_pages;
> >>> - unsigned long chunk_start;
> >>> - int err;
> >>> -
> >>> - err = -ENOMEM;
> >>> - pm = (struct page_to_node *)__get_free_page(GFP_KERNEL);
> >>> - if (!pm)
> >>> - goto out;
> >>> + int chunk_node = NUMA_NO_NODE;
> >>> + LIST_HEAD(pagelist);
> >>> + int chunk_start, i;
> >>> + int err = 0, err1;
> >>
> >> err init might not be required, its getting assigned to -EFAULT right away.
> >
> > No, nr_pages might be 0 AFAICS.
>
> Right but there is another err = 0 after the for loop.
No we have
out_flush:
/* Make sure we do not overwrite the existing error */
err1 = do_move_pages_to_node(mm, &pagelist, current_node);
if (!err1)
err1 = store_status(status, start, current_node, i - start);
if (!err)
err = err1;
This is obviously not an act of beauty and probably a subject to a
cleanup but I just wanted this thing to be working first. Further
cleanups can go on top.
> > [...]
> >>> + if (chunk_node == NUMA_NO_NODE) {
> >>> + chunk_node = node;
> >>> + chunk_start = i;
> >>> + } else if (node != chunk_node) {
> >>> + err = do_move_pages_to_node(mm, &pagelist, chunk_node);
> >>> + if (err)
> >>> + goto out;
> >>> + err = store_status(status, chunk_start, chunk_node, i -
> >>> chunk_start);
> >>> + if (err)
> >>> + goto out;
> >>> + chunk_start = i;
> >>> + chunk_node = node;
> >>> }
>
> [...]
>
> >>> + err = do_move_pages_to_node(mm, &pagelist, chunk_node);
> >>> + if (err)
> >>> + goto out;
> >>> + if (i > chunk_start) {
> >>> + err = store_status(status, chunk_start, chunk_node, i -
> >>> chunk_start);
> >>> + if (err)
> >>> + goto out;
> >>> + }
> >>> + chunk_node = NUMA_NO_NODE;
> >>
> >> This block of code is bit confusing.
> >
> > I believe this is easier to grasp when looking at the resulting code.
> >>
> >> 1) Why attempt to migrate when just one page could not be isolated ?
> >> 2) 'i' is always greater than chunk_start except the starting page
> >> 3) Why reset chunk_node as NUMA_NO_NODE ?
> >
> > This is all about flushing the pending state on an error and
> > distinguising a fresh batch.
>
> Okay. Will test it out on a multi node system once I get hold of one.
Thanks. I have been testing this specific code path with the following
simple test program and numactl -m0. The code is rather crude so I've
always modified it manually to test different scenarios (this one keeps
every 1k page on the node node to test batching.
---
#include
#include
#include
#include
#include
#include
#include
int main()
{
unsigned long nr_pages = 1;
size_t length = nr_pages << 12, i;
unsigned char *addr = mmap(NULL, length, PROT_READ | PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
void *addrs[nr_pages];
int nodes[nr_pages];
int status[nr_pages];
char cmd[128];
char ch;
if (addr == MAP_FAILED)
return 1;
madvise(addr, length, MADV_NOHUGEPAGE);
for (i = 0; i < length; i += 4096)
addr[i] = 1;
for (i = 0; i < nr_pages; i++)
{
addrs[i] = &addr[i * 4096];
if (i%1024)
nodes[i] = 1;
else
nodes[i] = 0;
status[i] = 0;
}
snprintf(cmd, sizeof(cmd)-1, "grep %lx /proc/%d/numa_maps", addr,
getpid());
system(cmd);
snprintf(cmd, sizeof(cmd)-1, "grep %lx -A20 /proc/%d/smaps", addr,
getpid());
system(cmd);
read(0, &ch, 1);
if (move_pages(0, nr_pages, addrs, nodes, status, MPOL_MF_MOVE)) {
printf("move_pages: err:%d\n", errno);
}
snprintf(cmd, sizeof(cmd)-1, "grep %lx /proc/%d/numa_maps", addr,
getpid());
system(cmd);
snprintf(cmd, sizeof(cmd)-1, "grep %lx -A20 /proc/%d/smaps", addr,
getpid());
system(cmd);
return 0;
}
---
--
Michal Hocko
SUSE Labs
Re: [PATCH 2/4] extcon: axp288: Remove unused platform data
On 2018년 01월 03일 18:37, Lee Jones wrote: > On Wed, 03 Jan 2018, Chanwoo Choi wrote: > >> Dear Lee, >> >> On 2018년 01월 02일 18:16, Lee Jones wrote: >>> On Tue, 02 Jan 2018, Chanwoo Choi wrote: >>> + MFD Maintainer (Lee Jones ) Hi Hans, You better to use the scripts/get_maintainer.pl for the mailing list. I added the MFD maintainer. This patch looks good to me. Reviewed-by: Chanwoo Choi Best Regards, Chanwoo Choi On 2017년 12월 22일 21:36, Hans de Goede wrote: > This is not used / set anywhere in the tree. > > Signed-off-by: Hans de Goede > --- > drivers/extcon/extcon-axp288.c | 35 +-- > include/linux/mfd/axp20x.h | 5 - >>> >>> Acked-by: Lee Jones >>> >> >> I already made the immutable branch[1] for both mfd and extcon. >> [1] https://lkml.org/lkml/2017/12/15/133 >> >> I added the additional patch for 'include/linux/mfd/axp20x.h' >> If you want to need to apply it on mfd tree, please apply them of immutable >> branch. >> >> >> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: >> >> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git >> ib-extcon-mfd-4.16 > > How is this possible? ib-extcon-mfd-4.16 is already immutable. > > I believe you should have created a new tag: > > ib-extcon-mfd-4.16-1 > > ... based on ib-extcon-mfd-4.16. You're right. I make the new immutable branch (ib-extcon-mfd-4.16-1) as following: The following changes since commit c7eb47f9e45226571be31212f6efd4b307d3b59d: extcon: usbc-cros-ec: add support to notify USB type cables. (2017-12-15 17:21:49 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/ib-extcon-mfd-4.16-1 for you to fetch changes up to 9bf317e900a19a857eb9921c9441a92e89f40415: extcon: axp288: Remove unused platform data (2018-01-03 10:11:02 +0900) Immutable branch for both MFD and EXTCON tree. Arvind Yadav (1): extcon: axp288:: Handle return value of platform_get_irq Hans de Goede (2): extcon: axp288: Remove unused extcon_nb struct member extcon: axp288: Remove unused platform data drivers/extcon/extcon-axp288.c | 39 --- include/linux/mfd/axp20x.h | 5 - 2 files changed, 4 insertions(+), 40 deletions(-) > >> for you to fetch changes up to 9bf317e900a19a857eb9921c9441a92e89f40415: >> >> extcon: axp288: Remove unused platform data (2018-01-03 10:11:02 +0900) >> >> >> Arvind Yadav (1): >> extcon: axp288:: Handle return value of platform_get_irq >> >> Benson Leung (1): >> extcon: usbc-cros-ec: add support to notify USB type cables. >> >> Hans de Goede (2): >> extcon: axp288: Remove unused extcon_nb struct member >> extcon: axp288: Remove unused platform data >> >> drivers/extcon/extcon-axp288.c | 39 +- >> drivers/extcon/extcon-usbc-cros-ec.c | 142 >> ++- >> include/linux/mfd/axp20x.h | 5 -- >> include/linux/mfd/cros_ec_commands.h | 17 + >> 4 files changed, 159 insertions(+), 44 deletions(-) >> > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: v3.18.86 build: 0 failures 1 warnings (v3.18.86)
On Wed, Jan 03, 2018 at 12:24:12AM +0100, Arnd Bergmann wrote:
> On Wed, Dec 6, 2017 at 1:18 AM, Build bot for Mark Brown
> wrote:
>
> > ---
> > x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
> >
> > Warnings:
> > ../include/linux/ftrace.h:632:36: warning: calling
> > '__builtin_return_address' with a nonzero argument is unsafe
> > [-Wframe-address]
> > ../include/linux/ftrace.h:632:36: warning: calling
> > '__builtin_return_address' with a nonzero argument is unsafe
> > [-Wframe-address]
> > ---
>
> This warning keeps coming up in 3.18 and 4.1 builds, which lack a backport of
>
> ef6000b4c670 ("Disable the __builtin_return_address() warning globally
> after all")
>
> The other build bots use different gcc versions that don't report the
> warning here,
> so only Mark's bot triggers it. The warning in this file is harmless,
> and the patch
> only turns off the warning flag.
Ah, I tried to figure this one out in the past, thanks for this, I'll
queue it up soon. Hm, this isn't in 4.4.y, why is it not showing up
there? Due to a different backport of this type of thing?
odd,
greg k-h
Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations
On Wed, Jan 03, 2018 at 08:42:15AM +0800, Huang, Ying wrote: > Mel Gorman writes: > > > On Tue, Jan 02, 2018 at 12:29:55PM +0100, Jan Kara wrote: > >> On Tue 02-01-18 10:21:03, Mel Gorman wrote: > >> > On Sat, Dec 23, 2017 at 10:36:53AM +0900, Minchan Kim wrote: > >> > > > code path. It appears that similar situation is possible for them > >> > > > too. > >> > > > > >> > > > The file cache pages will be delete from file cache address_space > >> > > > before > >> > > > address_space (embedded in inode) is freed. But they will be deleted > >> > > > from LRU list only when its refcount dropped to zero, please take a > >> > > > look > >> > > > at put_page() and release_pages(). While address_space will be freed > >> > > > after putting reference to all file cache pages. If someone holds a > >> > > > reference to a file cache page for quite long time, it is possible > >> > > > for a > >> > > > file cache page to be in LRU list after the inode/address_space is > >> > > > freed. > >> > > > > >> > > > And I found inode/address_space is freed witch call_rcu(). I don't > >> > > > know > >> > > > whether this is related to page_mapping(). > >> > > > > >> > > > This is just my understanding. > >> > > > >> > > Hmm, it smells like a bug of __isolate_lru_page. > >> > > > >> > > Ccing Mel: > >> > > > >> > > What locks protects address_space destroying when race happens between > >> > > inode trauncation and __isolate_lru_page? > >> > > > >> > > >> > I'm just back online and have a lot of catching up to do so this is a > >> > rushed > >> > answer and I didn't read the background of this. However the question is > >> > somewhat ambiguous and the scope is broad as I'm not sure which race you > >> > refer to. For file cache pages, I wouldnt' expect the address_space to be > >> > destroyed specifically as long as the inode exists which is the structure > >> > containing the address_space in this case. A page on the LRU being > >> > isolated > >> > in __isolate_lru_page will have an elevated reference count which will > >> > pin the inode until remove_mapping is called which holds the page lock > >> > while inode truncation looking at a page for truncation also only checks > >> > page_mapping under the page lock. Very broadly speaking, pages avoid > >> > being > >> > added back to an inode being freed by checking the I_FREEING state. > >> > >> So I'm wondering what prevents the following: > >> > >> CPU1 CPU2 > >> > >> truncate(inode)__isolate_lru_page() > >> ... > >> truncate_inode_page(mapping, page); > >> delete_from_page_cache(page) > >> spin_lock_irqsave(&mapping->tree_lock, flags); > >> __delete_from_page_cache(page, NULL) > >> page_cache_tree_delete(..) > >> ... mapping = > >> page_mapping(page); > >> page->mapping = NULL; > >> ... > >> spin_unlock_irqrestore(&mapping->tree_lock, flags); > >> page_cache_free_page(mapping, page) > >> put_page(page) > >> if (put_page_testzero(page)) -> false > >> - inode now has no pages and can be freed including embedded address_space > >> > >> if (mapping && > >> !mapping->a_ops->migratepage) > >> - we've dereferenced mapping which is potentially already free. > >> > > > > Hmm, possible if unlikely. > > > > Before delete_from_page_cache, we called truncate_cleanup_page so the > > page is likely to be !PageDirty or PageWriteback which gets skipped by > > the only caller that checks the mappping in __isolate_lru_page. The race > > is tiny but it does exist. One way of closing it is to check the mapping > > under the page lock which will prevent races with truncation. The > > overhead is minimal as the calling context (compaction) is quite a heavy > > operation anyway. > > > > I think another possible fix is to use call_rcu_sched() to free inode > (and address_space). Because __isolate_lru_page() will be called with > LRU spinlock held and IRQ disabled, call_rcu_sched() will wait > LRU spin_unlock and IRQ enabled. > Maybe, but in this particular case, I would prefer to go with something more conventional unless there is strong evidence that it's an improvement (which I doubt in this case given the cost of migration overall and the corner case of migrating a dirty page). -- Mel Gorman SUSE Labs
Re: v3.18.86 build: 0 failures 1 warnings (v3.18.86)
On Wed, Jan 03, 2018 at 10:54:16AM +0100, Greg KH wrote:
> On Wed, Jan 03, 2018 at 12:24:12AM +0100, Arnd Bergmann wrote:
> > On Wed, Dec 6, 2017 at 1:18 AM, Build bot for Mark Brown
> > wrote:
> >
> > > ---
> > > x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
> > >
> > > Warnings:
> > > ../include/linux/ftrace.h:632:36: warning: calling
> > > '__builtin_return_address' with a nonzero argument is unsafe
> > > [-Wframe-address]
> > > ../include/linux/ftrace.h:632:36: warning: calling
> > > '__builtin_return_address' with a nonzero argument is unsafe
> > > [-Wframe-address]
> > > ---
> >
> > This warning keeps coming up in 3.18 and 4.1 builds, which lack a backport
> > of
> >
> > ef6000b4c670 ("Disable the __builtin_return_address() warning globally
> > after all")
> >
> > The other build bots use different gcc versions that don't report the
> > warning here,
> > so only Mark's bot triggers it. The warning in this file is harmless,
> > and the patch
> > only turns off the warning flag.
>
> Ah, I tried to figure this one out in the past, thanks for this, I'll
> queue it up soon. Hm, this isn't in 4.4.y, why is it not showing up
> there? Due to a different backport of this type of thing?
Nope, doesn't apply to 3.18 at all, as the main part of this patch is
already in there. I don't really understand it, it seems that the
cc-disable-warning option isn't working for me for 3.18 at all in my
local builds. I spent a few hours on it last week, but gave up in the
end :(
thanks,
greg k-h
[PATCH] include/uapi/linux/swab: Fix potentially missing __always_inline
Commit bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining
of some byteswap operations") added __always_inline to swab functions
and commit 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to
userspace headers") added a definition of __always_inline for use in
exported headers when the kernel's compiler.h is not available.
However, since swab.h does not include stddef.h, if the header soup does
not indirectly include it, the definition of __always_inline is missing,
resulting in a compilation failure, which was observed compiling the
perf tool using exported headers containing this commit:
In file included from /usr/include/linux/byteorder/little_endian.h:12:0,
from /usr/include/asm/byteorder.h:14,
from tools/include/uapi/linux/perf_event.h:20,
from perf.h:8,
from builtin-bench.c:18:
/usr/include/linux/swab.h:160:8: error: unknown type name ‘__always_inline’
static __always_inline __u16 __swab16p(const __u16 *p)
Fix this by replacing the inclusion of linux/compiler.h with
linux/stddef.h to ensure that we pick up that definition if required,
without relying on it's indirect inclusion. compiler.h is then included
indirectly, via stddef.h.
Fixes: 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to userspace
headers")
Signed-off-by: Matt Redfearn
---
include/uapi/linux/swab.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index 23cd84868cc3..f6a8cf737abf 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -3,7 +3,7 @@
#define _UAPI_LINUX_SWAB_H
#include
-#include
+#include
#include
/*
--
2.7.4
Re: [PATCH 4.14 000/146] 4.14.11-stable review
On Tue, Jan 02, 2018 at 03:34:38PM -0700, Shuah Khan wrote: > On 01/01/2018 07:36 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.11 release. > > There are 146 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 3 14:00:12 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.11-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH v3 01/34] clk_ops: change round_rate() to return unsigned long
Em Mon, 1 Jan 2018 19:42:40 + Bryan O'Donoghue escreveu: > Right now it is not possible to return a value larger than LONG_MAX on 32 > bit systems. You can pass a rate of ULONG_MAX but can't return anything > past LONG_MAX due to the fact both the rounded_rate and negative error > codes are represented in the return value of round_rate(). > > Most implementations either return zero on error or don't return error > codes at all. A minority of implementations do return a negative number - > typically -EINVAL or -ENODEV. > > At the higher level then callers of round_rate() typically and rightly > check for a value of <= 0. > > It is possible then to convert round_rate() to an unsigned long return > value and change error code indication for the minority from -ERRORCODE to > a simple 0. > > This patch is the first step in making it possible to scale round_rate past > LONG_MAX, later patches will change the previously mentioned minority of > round_rate() implementations to return zero only on error if those > implementations currently return a negative error number. Implementations > that do not return an error code of < 0 will be left as-is. > > drivers/media/platform/omap3isp/isp.c | 4 ++-- Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2
Am 02.01.2018 um 21:51 schrieb Konrad Rzeszutek Wilk: On Tue, Jan 02, 2018 at 01:13:58PM +0100, Christian König wrote: [SNIP] + +phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, + dma_addr_t tbl_dma_addr, + phys_addr_t orig_addr, size_t size, + enum dma_data_direction dir, + unsigned long attrs) Hm, could be my editor, but are the parameters on the same line as 'struct device *hwdev'? Looks like just an issue in your editor. I've fixed all other suggestions and going to send out v3 of the patch in a minute. Thanks, Christian.
[PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v3
TTM tries to allocate coherent memory in chunks of 2MB first to improve
TLB efficiency and falls back to allocating 4K pages if that fails.
Suppress the warning when the 2MB allocations fails since there is a
valid fall back path.
v2: suppress warnings from swiotlb_tbl_map_single as well
v3: coding style fixes as suggested by Konrad
Signed-off-by: Christian König
Reported-by: Mike Galbraith
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
CC: sta...@vger.kernel.org
---
lib/swiotlb.c | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index cea19aaf303c..9890cc2e416f 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -490,11 +490,11 @@ static void swiotlb_bounce(phys_addr_t orig_addr,
phys_addr_t tlb_addr,
}
}
-phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
- dma_addr_t tbl_dma_addr,
- phys_addr_t orig_addr, size_t size,
- enum dma_data_direction dir,
- unsigned long attrs)
+phys_addr_t tbl_map_single(struct device *hwdev,
+ dma_addr_t tbl_dma_addr,
+ phys_addr_t orig_addr, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs, bool warn)
{
unsigned long flags;
phys_addr_t tlb_addr;
@@ -586,7 +586,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
not_found:
spin_unlock_irqrestore(&io_tlb_lock, flags);
- if (printk_ratelimit())
+ if (warn && printk_ratelimit())
dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n",
size);
return SWIOTLB_MAP_ERROR;
found:
@@ -605,6 +605,16 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
return tlb_addr;
}
+
+phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
+ dma_addr_t tbl_dma_addr,
+ phys_addr_t orig_addr, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return tbl_map_single(hwdev, tbl_dma_addr, orig_addr,
+ size, dir, attrs, true);
+}
EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
/*
@@ -613,7 +623,7 @@ EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
static phys_addr_t
map_single(struct device *hwdev, phys_addr_t phys, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
+ enum dma_data_direction dir, unsigned long attrs, bool warn)
{
dma_addr_t start_dma_addr;
@@ -624,8 +634,8 @@ map_single(struct device *hwdev, phys_addr_t phys, size_t
size,
}
start_dma_addr = swiotlb_phys_to_dma(hwdev, io_tlb_start);
- return swiotlb_tbl_map_single(hwdev, start_dma_addr, phys, size,
- dir, attrs);
+ return tbl_map_single(hwdev, start_dma_addr, phys, size,
+ dir, attrs, warn);
}
/*
@@ -713,6 +723,7 @@ void *
swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags)
{
+ bool warn = !(flags & __GFP_NOWARN);
dma_addr_t dev_addr;
void *ret;
int order = get_order(size);
@@ -739,7 +750,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
* will grab memory from the lowest available address range.
*/
phys_addr_t paddr = map_single(hwdev, 0, size,
- DMA_FROM_DEVICE, 0);
+ DMA_FROM_DEVICE, 0, warn);
if (paddr == SWIOTLB_MAP_ERROR)
goto err_warn;
@@ -769,9 +780,11 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
return ret;
err_warn:
- pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n",
- dev_name(hwdev), size);
- dump_stack();
+ if (warn && printk_ratelimit()) {
+ pr_warn("swiotlb: coherent allocation failed for device %s
size=%zu\n",
+ dev_name(hwdev), size);
+ dump_stack();
+ }
return NULL;
}
@@ -851,7 +864,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page
*page,
trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force);
/* Oh well, have to allocate and map a bounce buffer. */
- map = map_single(dev, phys, size, dir, attrs);
+ map = map_single(dev, phys, size, dir, attrs, true);
if (map == SWIOTLB_MAP_ERROR) {
swiotlb_full(dev, size, dir, 1);
return swiotlb_phys_to_dma(dev, io_tlb_overflow_buffer);
@@ -989,7 +1002,8 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct
scatterlist *sgl, int ne
Re: [PATCH] staging: ccree: mark debug_regs[] as static
Hi
On Wed, Jan 3, 2018 at 11:26 AM, Arnd Bergmann wrote:
> The global array clashes with an existing symbol of the same name:
>
> drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of
> `debug_regs'
> drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
>
> We should fix both, this one addresses the ccree driver by removing
> the symbol from the global namespace.
>
> Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and
> hardware state")
> Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by
> debugfs interface")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/ccree/cc_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/cc_debugfs.c
> b/drivers/staging/ccree/cc_debugfs.c
> index 7cd33957fdc6..662fa07af832 100644
> --- a/drivers/staging/ccree/cc_debugfs.c
> +++ b/drivers/staging/ccree/cc_debugfs.c
> @@ -37,7 +37,7 @@ struct cc_debugfs_ctx {
> */
> static struct dentry *cc_debugfs_dir;
>
> -struct debugfs_reg32 debug_regs[] = {
> +static struct debugfs_reg32 debug_regs[] = {
> CC_DEBUG_REG(HOST_SIGNATURE),
> CC_DEBUG_REG(HOST_IRR),
> CC_DEBUG_REG(HOST_POWER_DOWN_EN),
> --
> 2.9.0
>
Thank you Arnd.
I ran into this issue myself via a sparse check (I did not have s3cmci
compiled in) and was sure I sent a fix for it but now I see I did not.
Acked-by: Gilad Ben-Yossef
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH] v4l2: i2c: ov7670: Implement OF mbus configuration
Hi Jacopo,
Please see my comments below.
On Tue, Jan 02, 2018 at 04:03:53PM +0100, Jacopo Mondi wrote:
> ov7670 driver supports two optional properties supplied through platform
> data, but currently does not support any standard video interface
> property.
>
> Add support through OF parsing for 2 generic properties (vsync and hsync
> polarities) and for two custom properties already supported by platform
> data.
>
> Signed-off-by: Jacopo Mondi
> ---
>
> I have made sure signal polarities gets properly changed using a scope and
> capturing images with negative polarities using CEU capture interface.
> Also verified with a scope that pixel clock gets suppressed on horizontal
> blankings as well when "ov7670,pclk-hb-disable" property is specified.
>
> Thanks
>j
> ---
>
> .../devicetree/bindings/media/i2c/ov7670.txt | 12 +++
> drivers/media/i2c/ov7670.c | 101
> +++--
> 2 files changed, 106 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> index 826b656..c005453 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> @@ -9,11 +9,20 @@ Required Properties:
> - clocks: reference to the xclk input clock.
> - clock-names: should be "xclk".
>
> +The following properties, as defined by "video-interfaces.txt", are
> supported:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> respectively.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> respectively.
> +
> +Default is high active state for both vsync and hsync signals.
> +
> Optional Properties:
> - reset-gpios: reference to the GPIO connected to the resetb pin, if any.
>Active is low.
> - powerdown-gpios: reference to the GPIO connected to the pwdn pin, if any.
>Active is high.
> +- ov7670,pll-bypass: set to 1 to bypass PLL for pixel clock generation.
Is this something that should be specified using a device specific
property?
It looks like a rather crude way to configure the sensor's internal clock
tree. Is this something that could be deduced from the external clock
frequency? The check for the clock frequency seems very coarse and more or
less satisfies the device's input clock frequency limits (between 10 and 48
MHz).
> +- ov7670,pclk-hb-disable: set to 1 to suppress pixel clock output signal
> during
> + horizontal blankings.
Please separate the DT bindings from driver changes, and cc the devicetree
list.
>
> The device node must contain one 'port' child node for its digital output
> video port, in accordance with the video interface bindings defined in
> @@ -34,6 +43,9 @@ Example:
> assigned-clocks = <&pck0>;
> assigned-clock-rates = <2500>;
>
> + vsync-active = <0>;
> + pclk-sample = <1>;
> +
> port {
> ov7670_0: endpoint {
> remote-endpoint = <&isi_0>;
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index 950a0ac..a42bee7 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -11,6 +11,7 @@
> * Public License, version 2.
> */
> #include
> +#include
media/v4l2-fwnode.h includes linux/fwnode.h.
> #include
> #include
> #include
> @@ -21,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -237,6 +239,7 @@ struct ov7670_info {
> struct clk *clk;
> struct gpio_desc *resetb_gpio;
> struct gpio_desc *pwdn_gpio;
> + unsigned int mbus_config; /* Media bus configuration flags */
> int min_width; /* Filter out smaller sizes */
> int min_height; /* Filter out smaller sizes */
> int clock_speed;/* External clock speed (MHz) */
> @@ -995,7 +998,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> #ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
> struct v4l2_mbus_framefmt *mbus_fmt;
> #endif
> - unsigned char com7;
> + unsigned char com7, com10 = 0;
> int ret;
>
> if (format->pad)
> @@ -1027,6 +1030,18 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> com7 = ovfmt->regs[0].value;
> com7 |= wsize->com7_bit;
> ov7670_write(sd, REG_COM7, com7);
> +
> + /*
> + * Configure the media bus through COM10 register
> + */
> + if (info->mbus_config & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> + com10 |= COM10_VS_NEG;
> + if (info->mbus_config & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> + com10 |= COM10_HREF_REV;
> + if (info->pclk_hb_disable)
> + com10 |= COM10_PCLK_HB;
> + ov7670_write(sd, REG_COM10, com10);
How about checking the return value here?
> +
> /*
>* Now write th
Re: [PATCH] Staging: greybus: audio_codec.h: Change uint32_t to u32
On Wed, Jan 03, 2018 at 03:07:33PM +0530, Sumit Pundir wrote: > This patch fixes the following checkpatch.pl issues: > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > + uint32_t format, rate; > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > + uint32_t *rate, u8 *channels, > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > + uint32_t rate, u8 channels, > > Signed-off-by: Sumit Pundir > --- > drivers/staging/greybus/audio_codec.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Please fold this in with the changes to audio_codec.c and submit a single patch for it all. Thanks, Johan
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier wrote:
>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved across node collections on ThunderX2
>>
>> node collections?
>
> ok, i will rephrase it.
> i was intended to say cross NUMA node collection/cpu affinity change.
>
>>
>>> multi Socket platform, an interrupt stops routed to new collection
>>> and results in loss of interrupts.
>>>
>>> Adding workaround to issue INV after MOVI for cross-node collection
>>> move to flush out the cached entry.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni
>>> ---
>>> Documentation/arm64/silicon-errata.txt | 1 +
>>> arch/arm64/Kconfig | 11 +++
>>> drivers/irqchip/irq-gic-v3-its.c | 24
>>> 3 files changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.txt
>>> b/Documentation/arm64/silicon-errata.txt
>>> index fc1c884..fb27cb5 100644
>>> --- a/Documentation/arm64/silicon-errata.txt
>>> +++ b/Documentation/arm64/silicon-errata.txt
>>> @@ -63,6 +63,7 @@ stable kernels.
>>> | Cavium | ThunderX Core | #27456 |
>>> CAVIUM_ERRATUM_27456|
>>> | Cavium | ThunderX Core | #30115 |
>>> CAVIUM_ERRATUM_30115|
>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A
>>> |
>>> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
>>> |
>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A
>>> |
>>> | Cavium | ThunderX2 SMMUv3| #126| N/A
>>> |
>>> || | |
>>> |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index c9a7e9e..71a7e30 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>
>>> If unsure, say Y.
>>>
>>> +config CAVIUM_ERRATUM_174
>>> + bool "Cavium ThunderX2 erratum 174"
>>> + depends on NUMA
>>
>> Why? This system will be affected no matter whether NUMA is selected or not.
>
> it does not makes sense to enable on non-NUMA/single socket platforms.
> By default NUMA is enabled on ThunderX2 dual socket platforms.
config ARCH_THUNDER2
bool "Cavium ThunderX2 Server Processors"
select GPIOLIB
help
This enables support for Cavium's ThunderX2 CN99XX family of
server processors.
Do you see any NUMA here? I can perfectly compile a kernel with both
sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
>
>>
>>> + default y
>>> + help
>>> + LPI stops routed to redistributors after inter node collection
>>> + move in ITS. Enable workaround to invalidate ITS entry after
>>> + inter-node collection move.
>>
>> That's a very terse description. Nobody knows what an LPI, a
>> redistributor or a collection is. Please explain what the erratum is in
>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>> affinity change) so that people understand whether or not they are affected.
>
> ok, i will rephrase it in next version.
>>
>>> +
>>> + If unsure, say Y.
>>> +
>>> config CAVIUM_ERRATUM_22375
>>> bool "Cavium erratum 22375, 24313"
>>> default y
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>>> b/drivers/irqchip/irq-gic-v3-its.c
>>> index 06f025f..d8b9c96 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -46,6 +46,7 @@
>>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>>
>>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>>
>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d,
>>> const struct cpumask *mask_val,
>>> if (cpu != its_dev->event_map.col_map[id]) {
>>> target_col = &its_dev->its->collections[cpu];
>>> its_send_movi(its_dev, target_col, id);
>>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>>> + /* Issue INV for cross node collection move. */
>>> + if (cpu_to_node(cpu) !=
>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>> + its_send_inv(its_dev, id);
>>> + }
>>
>> What happens if an interrupt happens after the MOV, but before the INV?
>
> there can be drop, if interrupt happens before INV, however, it is
> highly unlikely that we will hit the issue since MOVI and INV are
> executed back to back. this workaround fixed issue seen on couple of
> IOs.
Really? So this doesn't fix anything, and the
Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
On 3 January 2018 at 09:44, Matt Fleming wrote: > Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks > as maintainers for the EFI test driver and efivarfs file system. > > Signed-off-by: Matt Fleming Acked-by: Ard Biesheuvel Thanks Matt > --- > MAINTAINERS | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > Ard, if you want to add yourself as co-maintainer of the EFI test > driver or efivarfs, please go ahead. I'm sure no one would object. > I guess that makes sense. Should we just fold that in? > diff --git a/MAINTAINERS b/MAINTAINERS > index d4fdcb12616c..9a41aa072e6a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5150,15 +5150,13 @@ F: sound/usb/misc/ua101.c > EFI TEST DRIVER > L: linux-...@vger.kernel.org > M: Ivan Hu > -M: Matt Fleming > S: Maintained > F: drivers/firmware/efi/test/ > > EFI VARIABLE FILESYSTEM > M: Matthew Garrett > M: Jeremy Kerr > -M: Matt Fleming > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git > L: linux-...@vger.kernel.org > S: Maintained > F: fs/efivarfs/ > @@ -5319,7 +5317,6 @@ S:Supported > F: security/integrity/evm/ > > EXTENSIBLE FIRMWARE INTERFACE (EFI) > -M: Matt Fleming > M: Ard Biesheuvel > L: linux-...@vger.kernel.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git > -- > 2.14.2 >
Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
Wei Wang wrote: > On 01/03/2018 10:29 AM, Tetsuo Handa wrote: > > Matthew Wilcox wrote: > >> The radix tree convention is objectively awful, which is why I'm working > >> to change it. Specifying the GFP flags at radix tree initialisation time > >> rather than allocation time leads to all kinds of confusion. The preload > >> API is a pretty awful workaround, and it will go away once the XArray > >> is working correctly. That said, there's no alternative to it without > >> making XBitmap depend on XArray, and I don't want to hold you up there. > >> So there's an xb_preload for the moment. > > I'm ready to propose cvbmp shown below as an alternative to xbitmap (but > > specialized for virtio-balloon case). Wei, can you do some benchmarking > > between xbitmap and cvbmp? > > > > cvbmp: clustered values bitmap > > I don't think we need to replace xbitmap, at least at this stage. The > new implementation doesn't look simpler at all, and virtio-balloon has > worked well with xbitmap. > > I would suggest you to send out the new implementation for discussion > after this series ends, and justify with better performance results if > you could get. I'm VMware Workstation Player user, and I don't have environment for doing performance test using virtio-balloon. Thus, I need to ask you. Also, please look at http://lkml.kernel.org/r/1514904621-39186-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp .
Re: [PATCH] Staging: greybus: audio_codec.c: Change uint32_t to u32
On Wed, Jan 3, 2018 at 3:09 PM, Sumit Pundir wrote: > This patch fixes the following checkpatch.pl issue at multiple lines: > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > + uint32_t format, rate; > > Signed-off-by: Sumit Pundir > --- Hi Sumit, Similar patches are already submitted by Kamal. Kindly go thru the driverdev mailing list to get more details and share another series if you find anything missing. -- thanks, ./va
Re: [PATCH] media: don't drop front-end reference count for ->detach
Em Tue, 2 Jan 2018 10:48:54 +0100
Arnd Bergmann escreveu:
> A bugfix introduce a link failure in configurations without CONFIG_MODULES:
>
> In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0:
> drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
> drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of
> 'stb0899_attach' being applied to a already existing, static definition
>
> The problem is that the !IS_REACHABLE() declaration of stb0899_attach()
> is a 'static inline' definition that clashes with the weak definition.
>
> I further observed that the bugfix was only done for one of the five users
> of stb0899_attach(), the other four still have the problem. This reverts
> the bugfix and instead addresses the problem by not dropping the reference
> count when calling '->detach()', instead we call this function directly
> in dvb_frontend_put() before dropping the kref on the front-end.
>
> Cc: Max Kellermann
> Cc: Wolfgang Rohdewald
> Fixes: f686c14364ad ("[media] stb0899: move code to "detach" callback")
> Fixes: 6cdeaed3b142 ("media: dvb_usb_pctv452e: module refcount changes were
> unbalanced")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/dvb-core/dvb_frontend.c | 4 +++-
> drivers/media/usb/dvb-usb/pctv452e.c | 8
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c
> index 87fc1bcae5ae..fe10b6f4d3e0 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -164,6 +164,9 @@ static void dvb_frontend_free(struct kref *ref)
>
> static void dvb_frontend_put(struct dvb_frontend *fe)
> {
> + /* call detach before dropping the reference count */
> + if (fe->ops.detach)
> + fe->ops.detach(fe);
> /*
>* Check if the frontend was registered, as otherwise
>* kref was not initialized yet.
> @@ -2965,7 +2968,6 @@ void dvb_frontend_detach(struct dvb_frontend* fe)
> dvb_frontend_invoke_release(fe, fe->ops.release_sec);
> dvb_frontend_invoke_release(fe, fe->ops.tuner_ops.release);
> dvb_frontend_invoke_release(fe, fe->ops.analog_ops.release);
> - dvb_frontend_invoke_release(fe, fe->ops.detach);
> dvb_frontend_put(fe);
Hmm... stb0899 is not the only driver using detach:
drivers/media/dvb-frontends/stb0899_drv.c: .detach
= stb0899_detach,
drivers/media/pci/saa7146/hexium_gemini.c: .detach = hexium_detach,
drivers/media/pci/saa7146/hexium_orion.c: .detach = hexium_detach,
drivers/media/pci/saa7146/mxb.c:.detach = mxb_detach,
drivers/media/pci/ttpci/av7110.c: .detach = av7110_detach,
drivers/media/pci/ttpci/budget-av.c:.detach = budget_av_detach,
drivers/media/pci/ttpci/budget-ci.c:.detach = budget_ci_detach,
drivers/media/pci/ttpci/budget-patch.c: .detach = budget_patch_detach,
drivers/media/pci/ttpci/budget.c: .detach = budget_detach,
Unfortunately, I don't have any device that would be affected by
this change, but it sounds risky to not call this code anymore:
#ifdef CONFIG_MEDIA_ATTACH
dvb_detach(release);
#endif
for .detach ops, as it has the potential of preventing unbind on
those drivers.
> }
> EXPORT_SYMBOL(dvb_frontend_detach);
> diff --git a/drivers/media/usb/dvb-usb/pctv452e.c
> b/drivers/media/usb/dvb-usb/pctv452e.c
> index 0af74383083d..ae793dac4964 100644
> --- a/drivers/media/usb/dvb-usb/pctv452e.c
> +++ b/drivers/media/usb/dvb-usb/pctv452e.c
> @@ -913,14 +913,6 @@ static int pctv452e_frontend_attach(struct
> dvb_usb_adapter *a)
> &a->dev->i2c_adap);
> if (!a->fe_adap[0].fe)
> return -ENODEV;
> -
> - /*
> - * dvb_frontend will call dvb_detach for both stb0899_detach
> - * and stb0899_release but we only do dvb_attach(stb0899_attach).
> - * Increment the module refcount instead.
> - */
> - symbol_get(stb0899_attach);
IMHO, the safest fix would be, instead, to do:
#ifdef CONFIG_MEDIA_ATTACH
symbol_get(stb0899_attach);
#endif
Btw, we have some code similar to that on other drivers
with either symbol_get() or symbol_put().
Yeah, I agree that this sucks. The right fix here is to use i2c high level
interfaces, binding it via i2c bus, instead of using the symbol_get()
based dvb_attach() macro.
We're (very) slowing doing such changes along the media subsystem.
Thanks,
Mauro
Re: [PATCH] nokia N9: Add support for magnetometer and touchscreen
On Tue 2018-01-02 18:27:20, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jan 02, 2018 at 02:17:22PM +0100, Pavel Machek wrote:
> > This adds dts support for magnetometer and touchscreen on Nokia N9.
>
> I think it makes sense to have this splitted.
Creating more work for everyone for little gain? Meh.
> > diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> > index 39e35f8..57a6679 100644
> > --- a/arch/arm/boot/dts/omap3-n9.dts
> > +++ b/arch/arm/boot/dts/omap3-n9.dts
> > @@ -36,6 +57,22 @@
> > };
> > };
> > };
> > +
> > + touch@4b {
>
> touchscreen@
Ok.
> > + compatible = "atmel,maxtouch";
> > + reg = <0x4b>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <29 2>; /* gpio_61, IRQF_TRIGGER_FALLING*/
>
> reset-gpios = <&gpio3 17 GPIO_ACTIVE_SOMETHING>;
>
> > + vdd-supply = <&vio>;
> > + avdd-supply = <&vaux1>;
>
> Those two are not mentioned in the binding and not supported by the
> driver as far as I can see?
Driver will need to be fixed, AFAICT :-(.
> Touchscreen with the same settings is required for n950, so it
> should be in the shared n950 + n9 file.
In future, settings will be different for n9/n950: calibration matrix
is different as panel is rotated in different way. Still it probably
makes sense to share. Ok.
> > +&i2c3 {
> > + ak8975@0f {
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0f>;
> > + };
> > };
>
> Looking at the N9 board file this is missing a rotation matrix. This
> is supported by the binding:
>
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
Do you have an idea how the rotation matrix should look like? I don't
currently have an userland software that could calibrate and test the
sensor, so I'd prefer to merge basic binding now and do calibration
later.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
