Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote: > On 6/19/19 1:12 AM, Peter Zijlstra wrote: > > I'm assuming you've looked at what x86 currently does and found > > something like that doesn't work for ARC? > > Just looked at x86 code and it seems similar I think you missed a bit. > >>> + WRITE_ONCE(*instr_addr, instr); > >>> + flush_icache_range(entry->code, entry->code + JUMP_LABEL_NOP_SIZE); > > So do you have a 2 byte opcode that traps unconditionally? In that case > > I'm thinking you could do something like x86 does. And it would avoid > > that NOP padding you do to get the alignment. > > Just to be clear there is no trapping going on in the canonical sense of it. > There > are regular instructions for NO-OP and Branch. > We do have 2 byte opcodes for both but as described the branch offset is too > limited so not usable. In particular we do not need the alignment. So what the x86 code does is: - overwrite the first byte of the instruction with a single byte trap instruction - machine wide IPI which synchronizes I$ At this point, any CPU that encounters this instruction will trap; and the trap handler will emulate the 'new' instruction -- typically a jump. - overwrite the tail of the instruction (if there is a tail) - machine wide IPI which syncrhonizes I$ At this point, nobody will execute the tail, because we'll still trap on that first single byte instruction, but if they were to read the instruction stream, the tail must be there. - overwrite the first byte of the instruction to now have a complete instruction. - machine wide IPI which syncrhonizes I$ At this point, any CPU will encounter the new instruction as a whole, irrespective of alignment. So the benefit of this scheme is that is works irrespective of the instruction fetch window size and don't need the 'funny' alignment stuff. Now, I've no idea if something like this is feasible on ARC; for it to work you need that 2 byte trap instruction -- since all instructions are 2 byte aligned, you can always poke that without issue.
Re: [PATCH 7/8] mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs
Acked-by: Suganath Prabu
On Thu, Jun 20, 2019 at 12:34 PM Suganath Prabu Subramani
wrote:
>
> Please consider this as Acked-by: Suganath Prabu
>
>
>
> On Tue, Jun 18, 2019 at 6:16 AM Ming Lei wrote:
> >
> > On Mon, Jun 17, 2019 at 8:21 PM Christoph Hellwig wrote:
> > >
> > > When using a virt_boundary_mask, as done for NVMe devices attached to
> > > mpt3sas controllers we require an unlimited max_segment_size, as the
> > > virt boundary merging code assumes that. But we also need to propagate
> > > that to the DMA mapping layer to make dma-debug happy. The SCSI layer
> > > takes care of that when using the per-host virt_boundary setting, but
> > > given that mpt3sas only wants to set the virt_boundary for actual
> > > NVMe devices we can't rely on that. The DMA layer maximum segment
> > > is global to the HBA however, so we have to set it explicitly. This
> > > patch assumes that mpt3sas does not have a segment size limitation,
> > > which seems true based on the SGL format, but will need to be verified.
> > >
> > > Signed-off-by: Christoph Hellwig
> > > ---
> > > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > index 1ccfbc7eebe0..c719b807f6d8 100644
> > > --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > @@ -10222,6 +10222,7 @@ static struct scsi_host_template
> > > mpt3sas_driver_template = {
> > > .this_id= -1,
> > > .sg_tablesize = MPT3SAS_SG_DEPTH,
> > > .max_sectors= 32767,
> > > + .max_segment_size = 0x,
> >
> > .max_segment_size should be aligned, either setting it here correctly or
> > forcing to make it aligned in scsi-core.
> >
> > Thanks,
> > Ming Lei
Re: [PATCH v2 4/5] mm: introduce MADV_PAGEOUT
On Thu 20-06-19 13:16:20, Minchan Kim wrote:
> On Wed, Jun 19, 2019 at 03:24:50PM +0200, Michal Hocko wrote:
> > On Mon 10-06-19 20:12:51, Minchan Kim wrote:
> > [...]
> > > +static int madvise_pageout_pte_range(pmd_t *pmd, unsigned long addr,
> > > + unsigned long end, struct mm_walk *walk)
> >
> > Again the same question about a potential code reuse...
> > [...]
> > > +regular_page:
> > > + tlb_change_page_size(tlb, PAGE_SIZE);
> > > + orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> > > + flush_tlb_batched_pending(mm);
> > > + arch_enter_lazy_mmu_mode();
> > > + for (; addr < end; pte++, addr += PAGE_SIZE) {
> > > + ptent = *pte;
> > > + if (!pte_present(ptent))
> > > + continue;
> > > +
> > > + page = vm_normal_page(vma, addr, ptent);
> > > + if (!page)
> > > + continue;
> > > +
> > > + if (isolate_lru_page(page))
> > > + continue;
> > > +
> > > + isolated++;
> > > + if (pte_young(ptent)) {
> > > + ptent = ptep_get_and_clear_full(mm, addr, pte,
> > > + tlb->fullmm);
> > > + ptent = pte_mkold(ptent);
> > > + set_pte_at(mm, addr, pte, ptent);
> > > + tlb_remove_tlb_entry(tlb, pte, addr);
> > > + }
> > > + ClearPageReferenced(page);
> > > + test_and_clear_page_young(page);
> > > + list_add(&page->lru, &page_list);
> > > + if (isolated >= SWAP_CLUSTER_MAX) {
> >
> > Why do we need SWAP_CLUSTER_MAX batching? Especially when we need ...
> > [...]
>
> It aims for preventing early OOM kill since we isolate too many LRU
> pages concurrently.
This is a good point. For some reason I thought that we consider
isolated pages in should_reclaim_retry but we do not anymore (since we
move from zone to node LRUs I guess). Please stick a comment there.
> > > +unsigned long reclaim_pages(struct list_head *page_list)
> > > +{
> > > + int nid = -1;
> > > + unsigned long nr_reclaimed = 0;
> > > + LIST_HEAD(node_page_list);
> > > + struct reclaim_stat dummy_stat;
> > > + struct scan_control sc = {
> > > + .gfp_mask = GFP_KERNEL,
> > > + .priority = DEF_PRIORITY,
> > > + .may_writepage = 1,
> > > + .may_unmap = 1,
> > > + .may_swap = 1,
> > > + };
> > > +
> > > + while (!list_empty(page_list)) {
> > > + struct page *page;
> > > +
> > > + page = lru_to_page(page_list);
> > > + if (nid == -1) {
> > > + nid = page_to_nid(page);
> > > + INIT_LIST_HEAD(&node_page_list);
> > > + }
> > > +
> > > + if (nid == page_to_nid(page)) {
> > > + list_move(&page->lru, &node_page_list);
> > > + continue;
> > > + }
> > > +
> > > + nr_reclaimed += shrink_page_list(&node_page_list,
> > > + NODE_DATA(nid),
> > > + &sc, 0,
> > > + &dummy_stat, false);
> >
> > per-node batching in fact. Other than that nothing really jumped at me.
> > Except for the shared page cache side channel timing aspect not being
> > considered AFAICS. To be more specific. Pushing out a shared page cache
> > is possible even now but this interface gives a much easier tool to
> > evict shared state and perform all sorts of timing attacks. Unless I am
> > missing something we should be doing something similar to mincore and
> > ignore shared pages without a writeable access or at least document why
> > we do not care.
>
> I'm not sure IIUC side channel attach. As you mentioned, without this syscall,
> 1. they already can do that simply by memory hogging
This is way much more harder for practical attacks because the reclaim
logic is not fully under the attackers control. Having a direct tool to
reclaim memory directly then just opens doors to measure the other
consumers of that memory and all sorts of side channel.
> 2. If we need fix MADV_PAGEOUT, that means we need to fix MADV_DONTNEED, too?
nope because MADV_DONTNEED doesn't unmap from other processes.
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 1/5] mm: introduce MADV_COLD
On Thu 20-06-19 09:06:51, Minchan Kim wrote: > On Wed, Jun 19, 2019 at 02:56:12PM +0200, Michal Hocko wrote: [...] > > Why cannot we reuse a large part of that code and differ essentially on > > the reclaim target check and action? Have you considered to consolidate > > the code to share as much as possible? Maybe that is easier said than > > done because the devil is always in details... > > Yub, it was not pretty when I tried. Please see last patch in this > patchset. That is bad because this code is quite subtle - especially the THP part of it. I will be staring at the code some more. Maybe some simplification pops out. -- Michal Hocko SUSE Labs
Re: [PATCH v2] mtd: spinand: read return badly if the last page has bitflips
On Thu, 20 Jun 2019 09:00:16 +0800
liaoweixiong wrote:
> In case of the last page containing bitflips (ret > 0),
> spinand_mtd_read() will return that number of bitflips for the last
> page. But to me it looks like it should instead return max_bitflips like
> it does when the last page read returns with 0.
>
> Signed-off-by: liaoweixiong
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/nand/spi/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 556bfdb..6b9388d 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -511,12 +511,12 @@ static int spinand_mtd_read(struct mtd_info *mtd,
> loff_t from,
> if (ret == -EBADMSG) {
> ecc_failed = true;
> mtd->ecc_stats.failed++;
> - ret = 0;
> } else {
> mtd->ecc_stats.corrected += ret;
> max_bitflips = max_t(unsigned int, max_bitflips, ret);
> }
>
> + ret = 0;
> ops->retlen += iter.req.datalen;
> ops->oobretlen += iter.req.ooblen;
> }
Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote: > FWIW I tried to avoid all of this by using the 2 byte NOP_S and B_S variants > which > ensures we can never straddle cache line so the alignment issue goes away. > There's > a nice code size reduction too - see [1] . But I get build link errors in > networking code around DO_ONCE where the unlikely code is too much and offset > can't be encoded in signed 10 bits which B_S is allowed. Yeah, so on x86 we have a 2 byte and a 5 byte relative jump and have the exact same issue. We're currently using 5 byte jumps unconditionally for the same reason. Getting it to use the 2 byte one where possible is a 'fun' project for someone with spare time at some point. It might need a GCC plugin to pull off, I've not put too much tought into it.
[PATCH 1/5] dt-bindings: i2c: at91: add new compatible
From: Eugen Hristev Add compatible for new Microchip SoC, sam9x60 Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index b7cec17..2210f43 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -3,7 +3,8 @@ I2C for Atmel platforms Required properties : - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c" + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or + "microchip,sam9x60-i2c" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. -- 2.7.4
[PATCH 2/5] i2c: at91: add new platform support for sam9x60
From: Eugen Hristev
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 8d55cdd..a663a7a 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = &sama5d2_config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = &sam9x60_config,
+ }, {
/* sentinel */
}
};
--
2.7.4
[PATCH 4/5] i2c: at91: add support for advanced digital filtering
From: Eugen Hristev
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 6 ++
drivers/i2c/busses/i2c-at91.h| 3 +++
3 files changed, 18 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 62610af..3bbe37c 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index 366e90f..b9e601e 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(7) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 3e80811..ccf18ba 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,8 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILTBIT(0)
+#define AT91_TWI_FILTR_THRES(v)((v) << 8)
+#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
#defineAT91_TWI_FMR0x0050 /* FIFO Mode Register */
#defineAT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
@@ -112,6 +114,7 @@ struct at91_twi_pdata {
bool has_alt_cmd;
bool has_hold_field;
bool has_dig_filtr;
+ bool has_adv_dig_filtr;
struct at_dma_slave dma_slave;
};
--
2.7.4
Re: [PATCH] pci/switchtec: fix stream_open.cocci warnings (fwd)
Bjorn Helgaas писал 2019-06-19 23:19:
On Wed, Jun 19, 2019 at 04:27:52PM +, Kirill Smelkov wrote:
Hi Julia, everyone.
On Wed, Jun 19, 2019 at 12:28:47PM +0200, Julia Lawall wrote:
> Hi,
>
> Can you forward this patch to the people below if you think it is
> appropriate?
Yes, this patch is appropriate. It was actually part of
git.kernel.org/linus/c5bf68fe0c86 . It should be safe, (and desirable
as
it removes a chance for deadlock) to apply it.
Sebastian, Kurt, Logan, Bjorn, please consider picking it up.
I don't get it. This appeared in v5.2-rc1 as c5bf68fe0c86 ("*: convert
stream-like files from nonseekable_open -> stream_open"), so it looks
like
this is already done. What would you like me to do with it?
I meant just that it was ok to pick this change into 5.0-RT tree as
kbuild robot was suggesting. Sorry for not being clear.
Kirill
> Could I tell the kbuild people to add you to the CC list for
> this semantic patch?
Yes, sure. Please feel free to add me to CC list for stream_open.cocci
related patches.
Kirill
> thanks,
> julia
>
> -- Forwarded message --
> Date: Wed, 19 Jun 2019 18:23:18 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Subject: [PATCH] pci/switchtec: fix stream_open.cocci warnings
>
> CC: kbuild-...@01.org
> TO: Sebastian Andrzej Siewior
> CC: Kurt Schwemmer
> CC: Logan Gunthorpe
> CC: Bjorn Helgaas
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
>
> From: kbuild test robot
>
> drivers/pci/switch/switchtec.c:395:1-17: ERROR: switchtec_fops: .read() can
deadlock .write(); change nonseekable_open -> stream_open to fix.
>
> Generated by: scripts/coccinelle/api/stream_open.cocci
>
> Fixes: a3a1e895d4fa ("pci/switchtec: Don't use completion's wait queue")
> Signed-off-by: kbuild test robot
> ---
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
linux-5.0.y-rt-rebase
> head: 31cc76d5590f5e60c2f26f029e40bc7d0441d93f
> commit: a3a1e895d4fa0508e11ac9107ace883a5b2a4d3b [171/305] pci/switchtec:
Don't use completion's wait queue
> :: branch date: 6 days ago
> :: commit date: 6 days ago
>
> Please take the patch only if it's a positive warning. Thanks!
>
> switchtec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -392,7 +392,7 @@ static int switchtec_dev_open(struct ino
>return PTR_ERR(stuser);
>
>filp->private_data = stuser;
> - nonseekable_open(inode, filp);
> + stream_open(inode, filp);
>
>dev_dbg(&stdev->dev, "%s: %p\n", __func__, stuser);
>
[PATCH 3/5] i2c: at91: add support for digital filtering
From: Eugen Hristev
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 6 ++
drivers/i2c/busses/i2c-at91.h| 4
3 files changed, 19 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index a663a7a..62610af 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index e87232f..366e90f 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..3e80811 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#defineAT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#defineAT91_TWI_ACR_DIRBIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILTBIT(0)
+
#defineAT91_TWI_FMR0x0050 /* FIFO Mode Register */
#defineAT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#defineAT91_TWI_FMR_TXRDYM_MASK(0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
--
2.7.4
[PATCH 5/5] i2c: at91: add support for analog filtering
From: Eugen Hristev
Add new platform data support for analog filtering for i2c.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 15 +++
drivers/i2c/busses/i2c-at91.h| 3 +++
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 3bbe37c..d2840ba 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index b9e601e..6b591ac 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,19 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(7) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+(AT91_TWI_FILTR_THRES(7) & AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr)
+ filtr |= AT91_TWI_FILTR_PADFEN | AT91_TWI_FILTR_PADFCFG;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index ccf18ba..f009799 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,8 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILTBIT(0)
+#define AT91_TWI_FILTR_PADFEN BIT(1)
+#define AT91_TWI_FILTR_PADFCFG BIT(2)
#define AT91_TWI_FILTR_THRES(v)((v) << 8)
#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
@@ -115,6 +117,7 @@ struct at91_twi_pdata {
bool has_hold_field;
bool has_dig_filtr;
bool has_adv_dig_filtr;
+ bool has_ana_filtr;
struct at_dma_slave dma_slave;
};
--
2.7.4
Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
On 6/19/19 8:19 PM, Yang Shi wrote: This is getting even more muddy TBH. Is there any reason that we have to handle this problem during the isolation phase rather the migration? >>> I think it was already said that if pages can't be isolated, then >>> migration phase won't process them, so they're just ignored. >> >> Yes，exactly. >> >>> However I think the patch is wrong to abort immediately when >>> encountering such page that cannot be isolated (AFAICS). IMHO it should >>> still try to migrate everything it can, and only then return -EIO. >> >> It is fine too. I don't see mbind semantics define how to handle such >> case other than returning -EIO. I think it does. There's: If MPOL_MF_MOVE is specified in flags, then the kernel *will attempt to move all the existing pages* ... If MPOL_MF_STRICT is also specified, then the call fails with the error *EIO if some pages could not be moved* Aborting immediately would be against the attempt to move all. > By looking into the code, it looks not that easy as what I thought. > do_mbind() would check the return value of queue_pages_range(), it just > applies the policy and manipulates vmas as long as the return value is 0 > (success), then migrate pages on the list. We could put the movable > pages on the list by not breaking immediately, but they will be ignored. > If we migrate the pages regardless of the return value, it may break the > policy since the policy will *not* be applied at all. I think we just need to remember if there was at least one page that failed isolation or migration, but keep working, and in the end return EIO if there was such page(s). I don't think it breaks the policy. Once pages are allocated in a mapping, changing the policy is a best effort thing anyway. >> >> >
Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Hi, On Tue, 18 Jun 2019 08:56:33 -0700 Vineet Gupta wrote: > +CC Masami San, Eugeniy > > On 6/13/19 10:57 AM, Vineet Gupta wrote: > > > > On 6/13/19 3:07 AM, Anshuman Khandual wrote: > >> Questions: > >> > >> AFAICT there is no equivalent of erstwhile notify_page_fault() during page > >> fault handling in arc and mips archs which can call this generic function. > >> Please let me know if that is not the case. > > > > For ARC do_page_fault() is entered for MMU exceptions (TLB Miss, access > > violations > > r/w/x etc). kprobes uses a combination of UNIMP_S and TRAP_S instructions > > which > > don't funnel into do_page_fault(). > > > > UINMP_S leads to > > > > instr_service > >do_insterror_or_kprobe > > notify_die(DIE_IERR) > > kprobe_exceptions_notify > > arc_kprobe_handler > > > > > > TRAP_S 2 leads to > > > > EV_Trap > >do_non_swi_trap > > trap_is_kprobe > > notify_die(DIE_TRAP) > > kprobe_exceptions_notify > >arc_post_kprobe_handler > > > > But indeed we are *not* calling into kprobe_fault_handler() - from eithet > > of those > > paths and not sure if the existing arc*_kprobe_handler() combination does > > the > > equivalent in tandem. Interesting, it seems that the kprobe_fault_handler() has never been called. Anyway, it is used for handling a page fault in kprobe's user handler or single stepping. And a page fault in user handler will not hard to fix up. Only a hard case is a page fault in single stepping. If ARC's kprobes using single-stepping on copied buffer, it may crashes kernel, since fixup code can not find correct address without kprobe_fault_handler. Thank you, > > @Eugeniy can you please investigate this - do we have krpobes bit rot in ARC > port. > > -Vineet > > -- Masami Hiramatsu
Re: [PATCH] flow_dissector: Fix vlan header offset in __skb_flow_dissect
Wed, Jun 19, 2019 at 08:39:38PM CEST, s...@fomichev.me wrote:
>On 06/20, YueHaibing wrote:
>> We build vlan on top of bonding interface, which vlan offload
>> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
>> BOND_XMIT_POLICY_ENCAP34.
>>
>> __skb_flow_dissect() fails to get information from protocol headers
>> encapsulated within vlan, because 'nhoff' is points to IP header,
>> so bond hashing is based on layer 2 info, which fails to distribute
>> packets across slaves.
>>
>> Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from
>> skb->vlan_tci")
>> Signed-off-by: YueHaibing
>> ---
>> net/core/flow_dissector.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 415b95f..2a52abb 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -785,6 +785,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> skb && skb_vlan_tag_present(skb)) {
>> proto = skb->protocol;
>> } else {
>> +if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
>> +nhoff -= sizeof(*vlan);
>> +
>Should we instead fix the place where the skb is allocated to properly
>pull vlan (skb_vlan_untag)? I'm not sure this particular place is
Yes.
>supposed to work with an skb. Having an skb with nhoff pointing to
>IP header but missing skb_vlan_tag_present() when with
>proto==ETH_P_8021xx seems weird.
>
>> vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
>> data, hlen, &_vlan);
>> if (!vlan) {
>> --
>> 2.7.0
>>
>>
Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote: > So we ensure a patched instruction never crosses a > cache line - using .balign 4. This causes a slight mis-optimization that all > patched instruction locations are forced to be 4 bytes aligned while ISA > allows > code to be 2 byte aligned. The cost is an extra NOP_S (2 bytes) - no big deal > in > grand scheme of things in IMO. Right, so the scheme x86 uses (which I outlined in an earlier email) allows you to get rid of those extra NOPs. Given jump labels are typically used on fast paths, and NOPs still take up cycles to, at the very least, fetch and decode, some people might care. But if you're OK with having them, then sure, your scheme certainly should work.
Re: [PATCH] replace timeconst bc script with an sh script
Hi Ethan,
Thank you for the patch,
On 20/06/2019 07:22, Ethan Sommer wrote:
> removes the bc build dependency introduced when timeconst.pl was
> replaced by timeconst.bc
Does this introduction of bc cause you problems when building?
Documentation/process/changes.rst states that "You will need bc to build
kernels 3.10 and higher"
Is bc used elsewhere in the kernel?
If this is the only use of BC and it is no longer a dependency - the
process document should be updated.
Though I see uses at:
tools/testing/selftests/net/forwarding/lib.sh
There is a small issue with quotes highlighted below, and the only other
(really minor) comment is performance.
time (echo 1000 | bc -q ./kernel/time/timeconst.bc)
real 0m0.006s
user 0m0.006s
sys 0m0.000s
vs
time /tmp/timeconst.sh 1000
real 0m0.176s
user 0m0.141s
sys 0m0.050s
So that's 176 milliseconds vs 6. (on an i7 gen8 laptop) which probably
isn't going to affect things too much on the scale of building a kernel.
But I measured it so I thought it was worth posting the results.
--
Regards
Kieran
> Signed-off-by: Ethan Sommer
> ---
> Kbuild | 4 +-
> kernel/time/timeconst.bc | 117 --
> kernel/time/timeconst.sh | 118 +++
> 3 files changed, 120 insertions(+), 119 deletions(-)
> delete mode 100644 kernel/time/timeconst.bc
> create mode 100755 kernel/time/timeconst.sh
>
> diff --git a/Kbuild b/Kbuild
> index 8637fd14135f..2b5f2957cf04 100644
> --- a/Kbuild
> +++ b/Kbuild
> @@ -20,9 +20,9 @@ timeconst-file := include/generated/timeconst.h
>
> targets += $(timeconst-file)
>
> -filechk_gentimeconst = echo $(CONFIG_HZ) | bc -q $<
> +filechk_gentimeconst = $(CONFIG_SHELL) $< $(CONFIG_HZ)
>
> -$(timeconst-file): kernel/time/timeconst.bc FORCE
> +$(timeconst-file): kernel/time/timeconst.sh FORCE
> $(call filechk,gentimeconst)
>
> #
> diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc
> deleted file mode 100644
> index 7ed0e0fb5831..
> --- a/kernel/time/timeconst.bc
> +++ /dev/null
> @@ -1,117 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -
> -scale=0
> -
> -define gcd(a,b) {
> - auto t;
> - while (b) {
> - t = b;
> - b = a % b;
> - a = t;
> - }
> - return a;
> -}
> -
> -/* Division by reciprocal multiplication. */
> -define fmul(b,n,d) {
> - return (2^b*n+d-1)/d;
> -}
> -
> -/* Adjustment factor when a ceiling value is used. Use as:
> - (imul * n) + (fmulxx * n + fadjxx) >> xx) */
> -define fadj(b,n,d) {
> - auto v;
> - d = d/gcd(n,d);
> - v = 2^b*(d-1)/d;
> - return v;
> -}
> -
> -/* Compute the appropriate mul/adj values as well as a shift count,
> - which brings the mul value into the range 2^b-1 <= x < 2^b. Such
> - a shift value will be correct in the signed integer range and off
> - by at most one in the upper half of the unsigned range. */
> -define fmuls(b,n,d) {
> - auto s, m;
> - for (s = 0; 1; s++) {
> - m = fmul(s,n,d);
> - if (m >= 2^(b-1))
> - return s;
> - }
> - return 0;
> -}
> -
> -define timeconst(hz) {
> - print "/* Automatically generated by kernel/time/timeconst.bc */\n"
> - print "/* Time conversion constants for HZ == ", hz, " */\n"
> - print "\n"
> -
> - print "#ifndef KERNEL_TIMECONST_H\n"
> - print "#define KERNEL_TIMECONST_H\n\n"
> -
> - print "#include \n"
> - print "#include \n\n"
> -
> - print "#if HZ != ", hz, "\n"
> - print "#error \qinclude/generated/timeconst.h has the wrong HZ
> value!\q\n"
> - print "#endif\n\n"
> -
> - if (hz < 2) {
> - print "#error Totally bogus HZ value!\n"
> - } else {
> - s=fmuls(32,1000,hz)
> - obase=16
> - print "#define HZ_TO_MSEC_MUL32\tU64_C(0x", fmul(s,1000,hz),
> ")\n"
> - print "#define HZ_TO_MSEC_ADJ32\tU64_C(0x", fadj(s,1000,hz),
> ")\n"
> - obase=10
> - print "#define HZ_TO_MSEC_SHR32\t", s, "\n"
> -
> - s=fmuls(32,hz,1000)
> - obase=16
> - print "#define MSEC_TO_HZ_MUL32\tU64_C(0x", fmul(s,hz,1000),
> ")\n"
> - print "#define MSEC_TO_HZ_ADJ32\tU64_C(0x", fadj(s,hz,1000),
> ")\n"
> - obase=10
> - print "#define MSEC_TO_HZ_SHR32\t", s, "\n"
> -
> - obase=10
> - cd=gcd(hz,1000)
> - print "#define HZ_TO_MSEC_NUM\t\t", 1000/cd, "\n"
> - print "#define HZ_TO_MSEC_DEN\t\t", hz/cd, "\n"
> - print "#define MSEC_TO_HZ_NUM\t\t", hz/cd, "\n"
> - print "#define MSEC_TO_HZ_DEN\t\t", 1000/cd, "\n"
> - print "\n"
> -
> - s=fmuls(32,100,hz)
> - obase=16
> - print "#define HZ_TO_USEC_MUL32\tU64_C(0x", fmul(s,100,hz),
> ")\n"
> - print "#define HZ_TO_USEC_ADJ32
Re: [PATCH V10 10/15] dt-bindings: PHY: P2U: Add Tegra194 P2U block
On 12/06/19 3:23 PM, Vidya Sagar wrote:
> Add support for Tegra194 P2U (PIPE to UPHY) module block which is a glue
> module instantiated one for each PCIe lane between Synopsys DesignWare core
> based PCIe IP and Universal PHY block.
>
> Signed-off-by: Vidya Sagar
> Reviewed-by: Rob Herring
> Acked-by: Thierry Reding
Acked-by: Kishon Vijay Abraham I
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * Added Sob
> * Changed node name from "p2u@" to "phy@"
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * Changed node label to reflect new format that includes either 'hsio' or
> 'nvhs' in its name to reflect which UPHY brick they belong to
>
> Changes since [v1]:
> * This is a new patch in v2 series
>
> .../bindings/phy/phy-tegra194-p2u.txt | 28 +++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt
> b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt
> new file mode 100644
> index ..d23ff90baad5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt
> @@ -0,0 +1,28 @@
> +NVIDIA Tegra194 P2U binding
> +
> +Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High
> +Speed) each interfacing with 12 and 8 P2U instances respectively.
> +A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's
> PIPE
> +interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe
> +lane.
> +
> +Required properties:
> +- compatible: For Tegra19x, must contain "nvidia,tegra194-p2u".
> +- reg: Should be the physical address space and length of respective each P2U
> + instance.
> +- reg-names: Must include the entry "ctl".
> +
> +Required properties for PHY port node:
> +- #phy-cells: Defined by generic PHY bindings. Must be 0.
> +
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties.
> +
> +Example:
> +
> +p2u_hsio_0: phy@3e1 {
> + compatible = "nvidia,tegra194-p2u";
> + reg = <0x03e1 0x1>;
> + reg-names = "ctl";
> +
> + #phy-cells = <0>;
> +};
>
Re: [PATCH V10 13/15] phy: tegra: Add PCIe PIPE2UPHY support
On 12/06/19 3:23 PM, Vidya Sagar wrote:
> Synopsys DesignWare core based PCIe controllers in Tegra 194 SoC interface
> with Universal PHY (UPHY) module through a PIPE2UPHY (P2U) module.
> For each PCIe lane of a controller, there is a P2U unit instantiated at
> hardware level. This driver provides support for the programming required
> for each P2U that is going to be used for a PCIe controller.
One minor comment below. With that fixed
Acked-by: Kishon Vijay Abraham I
>
> Signed-off-by: Vidya Sagar
> ---
> Changes since [v9]:
> * Used _relaxed() versions of readl() & writel()
>
> Changes since [v8]:
> * Made it dependent on ARCH_TEGRA_194_SOC directly instead of ARCH_TEGRA
>
> Changes since [v7]:
> * Changed P2U driver file name from pcie-p2u-tegra194.c to phy-tegra194-p2u.c
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * Addressed review comments from Thierry
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * Rebased on top of linux-next top of the tree
>
> Changes since [v2]:
> * Replaced spaces with tabs in Kconfig file
> * Sorted header file inclusion alphabetically
>
> Changes since [v1]:
> * Added COMPILE_TEST in Kconfig
> * Removed empty phy_ops implementations
> * Modified code according to DT documentation file modifications
>
> drivers/phy/tegra/Kconfig| 7 ++
> drivers/phy/tegra/Makefile | 1 +
> drivers/phy/tegra/phy-tegra194-p2u.c | 120 +++
> 3 files changed, 128 insertions(+)
> create mode 100644 drivers/phy/tegra/phy-tegra194-p2u.c
>
> diff --git a/drivers/phy/tegra/Kconfig b/drivers/phy/tegra/Kconfig
> index e516967d695b..f9817c3ae85f 100644
> --- a/drivers/phy/tegra/Kconfig
> +++ b/drivers/phy/tegra/Kconfig
> @@ -7,3 +7,10 @@ config PHY_TEGRA_XUSB
>
> To compile this driver as a module, choose M here: the module will
> be called phy-tegra-xusb.
> +
> +config PHY_TEGRA194_P2U
> + tristate "NVIDIA Tegra194 PIPE2UPHY PHY driver"
> + depends on ARCH_TEGRA_194_SOC || COMPILE_TEST
> + select GENERIC_PHY
> + help
> + Enable this to support the P2U (PIPE to UPHY) that is part of Tegra
> 19x SOCs.
> diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
> index 64ccaeacb631..320dd389f34d 100644
> --- a/drivers/phy/tegra/Makefile
> +++ b/drivers/phy/tegra/Makefile
> @@ -6,3 +6,4 @@ phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
> phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
> phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
> phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_186_SOC) += xusb-tegra186.o
> +obj-$(CONFIG_PHY_TEGRA194_P2U) += phy-tegra194-p2u.o
> diff --git a/drivers/phy/tegra/phy-tegra194-p2u.c
> b/drivers/phy/tegra/phy-tegra194-p2u.c
> new file mode 100644
> index ..df009abd2482
> --- /dev/null
> +++ b/drivers/phy/tegra/phy-tegra194-p2u.c
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * P2U (PIPE to UPHY) driver for Tegra T194 SoC
> + *
> + * Copyright (C) 2019 NVIDIA Corporation.
> + *
> + * Author: Vidya Sagar
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define P2U_PERIODIC_EQ_CTRL_GEN30xc0
> +#define P2U_PERIODIC_EQ_CTRL_GEN3_PERIODIC_EQ_EN BIT(0)
> +#define P2U_PERIODIC_EQ_CTRL_GEN3_INIT_PRESET_EQ_TRAIN_ENBIT(1)
> +#define P2U_PERIODIC_EQ_CTRL_GEN40xc4
> +#define P2U_PERIODIC_EQ_CTRL_GEN4_INIT_PRESET_EQ_TRAIN_ENBIT(1)
> +
> +#define P2U_RX_DEBOUNCE_TIME 0xa4
> +#define P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_MASK 0x
> +#define P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_VAL 160
> +
> +struct tegra_p2u {
> + void __iomem *base;
> +};
> +
> +static inline void p2u_writel(struct tegra_p2u *phy, const u32 value,
> + const u32 reg)
> +{
> + writel_relaxed(value, phy->base + reg);
> +}
> +
> +static inline u32 p2u_readl(struct tegra_p2u *phy, const u32 reg)
> +{
> + return readl_relaxed(phy->base + reg);
> +}
> +
> +static int tegra_p2u_power_on(struct phy *x)
> +{
> + struct tegra_p2u *phy = phy_get_drvdata(x);
> + u32 val;
> +
> + val = p2u_readl(phy, P2U_PERIODIC_EQ_CTRL_GEN3);
> + val &= ~P2U_PERIODIC_EQ_CTRL_GEN3_PERIODIC_EQ_EN;
> + val |= P2U_PERIODIC_EQ_CTRL_GEN3_INIT_PRESET_EQ_TRAIN_EN;
> + p2u_writel(phy, val, P2U_PERIODIC_EQ_CTRL_GEN3);
> +
> + val = p2u_readl(phy, P2U_PERIODIC_EQ_CTRL_GEN4);
> + val |= P2U_PERIODIC_EQ_CTRL_GEN4_INIT_PRESET_EQ_TRAIN_EN;
> + p2u_writel(phy, val, P2U_PERIODIC_EQ_CTRL_GEN4);
> +
> + val = p2u_readl(phy, P2U_RX_DEBOUNCE_TIME);
> + val &= ~P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_MASK;
> + val |= P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_VAL;
> + p2u_writel(phy, val, P2U_RX_DEBOUNCE_TIME);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops ops = {
> + .power_on = tegra_p2u_power_on,
> + .owner = THIS_MODULE,
> +};
> +
> +st
[PATCH v5] media: docs-rst: Document m2m stateless video decoder interface
Documents the protocol that user-space should follow when
communicating with stateless video decoders.
The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
should probably still be considered staging for a short while.
Signed-off-by: Alexandre Courbot
---
Changes since v4:
* Specify that G_FMT must be performed again after S_FMT on the CAPTURE queue
to get up-to-date buffer information,
* Add description of multi-slice decoding using the
V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag.
The very last paragraph of this document describes a situation that has not yet
been discussed: draining the queue when a held CAPTURE buffer is still there. I
have written a basic solution for this situation, but feel free to suggest
something better.
Documentation/media/uapi/v4l/dev-mem2mem.rst | 5 +
.../media/uapi/v4l/dev-stateless-decoder.rst | 415 ++
2 files changed, 420 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst
diff --git a/Documentation/media/uapi/v4l/dev-mem2mem.rst
b/Documentation/media/uapi/v4l/dev-mem2mem.rst
index 67a980818dc8..db6f4efc458d 100644
--- a/Documentation/media/uapi/v4l/dev-mem2mem.rst
+++ b/Documentation/media/uapi/v4l/dev-mem2mem.rst
@@ -13,6 +13,11 @@
Video Memory-To-Memory Interface
+.. toctree::
+:maxdepth: 1
+
+dev-stateless-decoder
+
A V4L2 memory-to-memory device can compress, decompress, transform, or
otherwise convert video data from one format into another format, in memory.
Such memory-to-memory devices set the ``V4L2_CAP_VIDEO_M2M`` or
diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
new file mode 100644
index ..186ec39c5ed7
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
@@ -0,0 +1,415 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _stateless_decoder:
+
+**
+Memory-to-memory Stateless Video Decoder Interface
+**
+
+A stateless decoder is a decoder that works without retaining any kind of state
+between processed frames. This means that each frame is decoded independently
+of any previous and future frames, and that the client is responsible for
+maintaining the decoding state and providing it to the decoder with each
+decoding request. This is in contrast to the stateful video decoder interface,
+where the hardware and driver maintain the decoding state and all the client
+has to do is to provide the raw encoded stream and dequeue decoded frames in
+display order.
+
+This section describes how user-space ("the client") is expected to communicate
+with stateless decoders in order to successfully decode an encoded stream.
+Compared to stateful codecs, the decoder/client sequence is simpler, but the
+cost of this simplicity is extra complexity in the client which is responsible
+for maintaining a consistent decoding state.
+
+Stateless decoders make use of the request API. A stateless decoder must expose
+the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its ``OUTPUT`` queue when
+:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are invoked.
+
+Depending on the encoded formats supported by the decoder, a single decoded
+frame may be the result of several decode requests (for instance, H.264 streams
+with multiple slices per frame). Decoders that support such formats must also
+expose the ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` capability on their
+``OUTPUT`` queue.
+
+Querying capabilities
+=
+
+1. To enumerate the set of coded formats supported by the decoder, the client
+ calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
+
+ * The driver must always return the full set of supported ``OUTPUT``
formats,
+ irrespective of the format currently set on the ``CAPTURE`` queue.
+
+ * Simultaneously, the driver must restrain the set of values returned by
+ codec-specific capability controls (such as H.264 profiles) to the set
+ actually supported by the hardware.
+
+2. To enumerate the set of supported raw formats, the client calls
+ :c:func:`VIDIOC_ENUM_FMT` on the ``CAPTURE`` queue.
+
+ * The driver must return only the formats supported for the format currently
+ active on the ``OUTPUT`` queue.
+
+ * Depending on the currently set ``OUTPUT`` format, the set of supported raw
+ formats may depend on the value of some codec-dependent controls. The
+ The client is responsible for making sure that these controls are set
+ before querying the ``CAPTURE`` queue. Failure to do so will result in the
+ default values for these controls being used, and a returned set of
formats
+ that may not be usable for the media the client is trying to decode.
+
+3. The client may use :c:func:`VIDIOC_ENUM_FRAMES
[PATCH V4 4/6] PM / QoS: Add support for MIN/MAX frequency constraints
This patch introduces the min-frequency and max-frequency device
constraints, which will be used by the cpufreq core to begin with.
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/base/power/qos.c | 111 ++-
include/linux/pm_qos.h | 12 +
2 files changed, 109 insertions(+), 14 deletions(-)
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index 2461fed0efa0..6c90fd7e2ff8 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -120,6 +120,14 @@ s32 dev_pm_qos_read_value(struct device *dev, enum
dev_pm_qos_req_type type)
ret = IS_ERR_OR_NULL(qos) ? PM_QOS_RESUME_LATENCY_NO_CONSTRAINT
: pm_qos_read_value(&qos->resume_latency);
break;
+ case DEV_PM_QOS_MIN_FREQUENCY:
+ ret = IS_ERR_OR_NULL(qos) ? PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE
+ : pm_qos_read_value(&qos->min_frequency);
+ break;
+ case DEV_PM_QOS_MAX_FREQUENCY:
+ ret = IS_ERR_OR_NULL(qos) ? PM_QOS_MAX_FREQUENCY_DEFAULT_VALUE
+ : pm_qos_read_value(&qos->max_frequency);
+ break;
default:
WARN_ON(1);
ret = 0;
@@ -161,6 +169,14 @@ static int apply_constraint(struct dev_pm_qos_request *req,
req->dev->power.set_latency_tolerance(req->dev, value);
}
break;
+ case DEV_PM_QOS_MIN_FREQUENCY:
+ ret = pm_qos_update_target(&qos->min_frequency,
+ &req->data.pnode, action, value);
+ break;
+ case DEV_PM_QOS_MAX_FREQUENCY:
+ ret = pm_qos_update_target(&qos->max_frequency,
+ &req->data.pnode, action, value);
+ break;
case DEV_PM_QOS_FLAGS:
ret = pm_qos_update_flags(&qos->flags, &req->data.flr,
action, value);
@@ -189,12 +205,11 @@ static int dev_pm_qos_constraints_allocate(struct device
*dev)
if (!qos)
return -ENOMEM;
- n = kzalloc(sizeof(*n), GFP_KERNEL);
+ n = kzalloc(3 * sizeof(*n), GFP_KERNEL);
if (!n) {
kfree(qos);
return -ENOMEM;
}
- BLOCKING_INIT_NOTIFIER_HEAD(n);
c = &qos->resume_latency;
plist_head_init(&c->list);
@@ -203,6 +218,7 @@ static int dev_pm_qos_constraints_allocate(struct device
*dev)
c->no_constraint_value = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
c->type = PM_QOS_MIN;
c->notifiers = n;
+ BLOCKING_INIT_NOTIFIER_HEAD(n);
c = &qos->latency_tolerance;
plist_head_init(&c->list);
@@ -211,6 +227,24 @@ static int dev_pm_qos_constraints_allocate(struct device
*dev)
c->no_constraint_value = PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT;
c->type = PM_QOS_MIN;
+ c = &qos->min_frequency;
+ plist_head_init(&c->list);
+ c->target_value = PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE;
+ c->default_value = PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE;
+ c->no_constraint_value = PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE;
+ c->type = PM_QOS_MAX;
+ c->notifiers = ++n;
+ BLOCKING_INIT_NOTIFIER_HEAD(n);
+
+ c = &qos->max_frequency;
+ plist_head_init(&c->list);
+ c->target_value = PM_QOS_MAX_FREQUENCY_DEFAULT_VALUE;
+ c->default_value = PM_QOS_MAX_FREQUENCY_DEFAULT_VALUE;
+ c->no_constraint_value = PM_QOS_MAX_FREQUENCY_DEFAULT_VALUE;
+ c->type = PM_QOS_MIN;
+ c->notifiers = ++n;
+ BLOCKING_INIT_NOTIFIER_HEAD(n);
+
INIT_LIST_HEAD(&qos->flags.list);
spin_lock_irq(&dev->power.lock);
@@ -264,11 +298,25 @@ void dev_pm_qos_constraints_destroy(struct device *dev)
apply_constraint(req, PM_QOS_REMOVE_REQ, PM_QOS_DEFAULT_VALUE);
memset(req, 0, sizeof(*req));
}
+
c = &qos->latency_tolerance;
plist_for_each_entry_safe(req, tmp, &c->list, data.pnode) {
apply_constraint(req, PM_QOS_REMOVE_REQ, PM_QOS_DEFAULT_VALUE);
memset(req, 0, sizeof(*req));
}
+
+ c = &qos->min_frequency;
+ plist_for_each_entry_safe(req, tmp, &c->list, data.pnode) {
+ apply_constraint(req, PM_QOS_REMOVE_REQ,
PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE);
+ memset(req, 0, sizeof(*req));
+ }
+
+ c = &qos->max_frequency;
+ plist_for_each_entry_safe(req, tmp, &c->list, data.pnode) {
+ apply_constraint(req, PM_QOS_REMOVE_REQ,
PM_QOS_MAX_FREQUENCY_DEFAULT_VALUE);
+ memset(req, 0, sizeof(*req));
+ }
+
f = &qos->flags;
list_for_each_entry_safe(req, tmp, &f->list, data.flr.node) {
apply_constraint(req, PM_QOS_REMOVE_REQ, PM_QOS_DEFAULT_VALUE);
@@ -380,6 +428,8 @@ static
[PATCH V4 2/6] PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()
dev_pm_qos_read_value() will soon need to support more constraint types
(min/max frequency) and will have another argument to it, i.e. type of
the constraint. While that is fine for the existing users of
dev_pm_qos_read_value(), but not that optimal for the callers of
__dev_pm_qos_read_value() and dev_pm_qos_raw_read_value() as all the
callers of these two routines are only looking for resume latency
constraint.
Lets make these two routines care only about the resume latency
constraint and rename them to __dev_pm_qos_resume_latency() and
dev_pm_qos_raw_resume_latency().
Suggested-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
---
drivers/base/power/domain_governor.c | 2 +-
drivers/base/power/qos.c | 13 +
drivers/base/power/runtime.c | 2 +-
drivers/cpuidle/governor.c | 2 +-
include/linux/pm_qos.h | 8
5 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/domain_governor.c
b/drivers/base/power/domain_governor.c
index 3838045c9277..20e56a5be01f 100644
--- a/drivers/base/power/domain_governor.c
+++ b/drivers/base/power/domain_governor.c
@@ -66,7 +66,7 @@ static bool default_suspend_ok(struct device *dev)
td->constraint_changed = false;
td->cached_suspend_ok = false;
td->effective_constraint_ns = 0;
- constraint_ns = __dev_pm_qos_read_value(dev);
+ constraint_ns = __dev_pm_qos_resume_latency(dev);
spin_unlock_irqrestore(&dev->power.lock, flags);
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index cfd463212513..7a0d197f0809 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -90,16 +90,16 @@ enum pm_qos_flags_status dev_pm_qos_flags(struct device
*dev, s32 mask)
EXPORT_SYMBOL_GPL(dev_pm_qos_flags);
/**
- * __dev_pm_qos_read_value - Get PM QoS constraint for a given device.
+ * __dev_pm_qos_resume_latency - Get resume latency constraint for a given
device.
* @dev: Device to get the PM QoS constraint value for.
*
* This routine must be called with dev->power.lock held.
*/
-s32 __dev_pm_qos_read_value(struct device *dev)
+s32 __dev_pm_qos_resume_latency(struct device *dev)
{
lockdep_assert_held(&dev->power.lock);
- return dev_pm_qos_raw_read_value(dev);
+ return dev_pm_qos_raw_resume_latency(dev);
}
/**
@@ -112,7 +112,12 @@ s32 dev_pm_qos_read_value(struct device *dev)
s32 ret;
spin_lock_irqsave(&dev->power.lock, flags);
- ret = __dev_pm_qos_read_value(dev);
+
+ if (IS_ERR_OR_NULL(dev->power.qos))
+ ret = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
+ else
+ ret = pm_qos_read_value(&dev->power.qos->resume_latency);
+
spin_unlock_irqrestore(&dev->power.lock, flags);
return ret;
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 952a1e7057c7..b75335508d2c 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -275,7 +275,7 @@ static int rpm_check_suspend_allowed(struct device *dev)
|| (dev->power.request_pending
&& dev->power.request == RPM_REQ_RESUME))
retval = -EAGAIN;
- else if (__dev_pm_qos_read_value(dev) == 0)
+ else if (__dev_pm_qos_resume_latency(dev) == 0)
retval = -EPERM;
else if (dev->power.runtime_status == RPM_SUSPENDED)
retval = 1;
diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c
index 9fddf828a76f..2e3e14192bee 100644
--- a/drivers/cpuidle/governor.c
+++ b/drivers/cpuidle/governor.c
@@ -110,7 +110,7 @@ int cpuidle_governor_latency_req(unsigned int cpu)
{
int global_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
struct device *device = get_cpu_device(cpu);
- int device_req = dev_pm_qos_raw_read_value(device);
+ int device_req = dev_pm_qos_raw_resume_latency(device);
return device_req < global_req ? device_req : global_req;
}
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 1f4d456e8fff..06aa88496761 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -139,7 +139,7 @@ s32 pm_qos_read_value(struct pm_qos_constraints *c);
#ifdef CONFIG_PM
enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev, s32 mask);
enum pm_qos_flags_status dev_pm_qos_flags(struct device *dev, s32 mask);
-s32 __dev_pm_qos_read_value(struct device *dev);
+s32 __dev_pm_qos_resume_latency(struct device *dev);
s32 dev_pm_qos_read_value(struct device *dev);
int dev_pm_qos_add_request(struct device *dev, struct dev_pm_qos_request *req,
enum dev_pm_qos_req_type type, s32 value);
@@ -176,7 +176,7 @@ static inline s32 dev_pm_qos_requested_flags(struct device
*dev)
return dev->power.qos->flags_req->data.flr.flags;
}
-static inline s32 dev_pm_qos_raw_read_value(struct device *dev)
+static inline s32 dev_pm_qos_raw_resume_latency(struct devic
[PATCH V4 3/6] PM / QOS: Pass request type to dev_pm_qos_read_value()
In order to allow dev_pm_qos_read_value() to read values for different
QoS requests, pass request type as a parameter to these routines.
For now, it only supports resume-latency request type but will be
extended to frequency limit (min/max) constraints later on.
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
Documentation/power/pm_qos_interface.txt | 2 +-
drivers/base/power/domain_governor.c | 2 +-
drivers/base/power/qos.c | 17 -
include/linux/pm_qos.h | 16 +---
4 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/Documentation/power/pm_qos_interface.txt
b/Documentation/power/pm_qos_interface.txt
index ec7d662d1707..cfcb1df39799 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -123,7 +123,7 @@ Will remove the element. After removal it will update the
aggregate target and
call the notification trees if the target was changed as a result of removing
the request.
-s32 dev_pm_qos_read_value(device):
+s32 dev_pm_qos_read_value(device, type):
Returns the aggregated value for a given device's constraints list.
enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
diff --git a/drivers/base/power/domain_governor.c
b/drivers/base/power/domain_governor.c
index 20e56a5be01f..daa8c7689f7e 100644
--- a/drivers/base/power/domain_governor.c
+++ b/drivers/base/power/domain_governor.c
@@ -33,7 +33,7 @@ static int dev_update_qos_constraint(struct device *dev, void
*data)
* take its current PM QoS constraint (that's the only thing
* known at this point anyway).
*/
- constraint_ns = dev_pm_qos_read_value(dev);
+ constraint_ns = dev_pm_qos_read_value(dev,
DEV_PM_QOS_RESUME_LATENCY);
constraint_ns *= NSEC_PER_USEC;
}
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index 7a0d197f0809..2461fed0efa0 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -105,18 +105,25 @@ s32 __dev_pm_qos_resume_latency(struct device *dev)
/**
* dev_pm_qos_read_value - Get PM QoS constraint for a given device (locked).
* @dev: Device to get the PM QoS constraint value for.
+ * @type: QoS request type.
*/
-s32 dev_pm_qos_read_value(struct device *dev)
+s32 dev_pm_qos_read_value(struct device *dev, enum dev_pm_qos_req_type type)
{
+ struct dev_pm_qos *qos = dev->power.qos;
unsigned long flags;
s32 ret;
spin_lock_irqsave(&dev->power.lock, flags);
- if (IS_ERR_OR_NULL(dev->power.qos))
- ret = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
- else
- ret = pm_qos_read_value(&dev->power.qos->resume_latency);
+ switch (type) {
+ case DEV_PM_QOS_RESUME_LATENCY:
+ ret = IS_ERR_OR_NULL(qos) ? PM_QOS_RESUME_LATENCY_NO_CONSTRAINT
+ : pm_qos_read_value(&qos->resume_latency);
+ break;
+ default:
+ WARN_ON(1);
+ ret = 0;
+ }
spin_unlock_irqrestore(&dev->power.lock, flags);
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 06aa88496761..5ce1c310373e 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -140,7 +140,7 @@ s32 pm_qos_read_value(struct pm_qos_constraints *c);
enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev, s32 mask);
enum pm_qos_flags_status dev_pm_qos_flags(struct device *dev, s32 mask);
s32 __dev_pm_qos_resume_latency(struct device *dev);
-s32 dev_pm_qos_read_value(struct device *dev);
+s32 dev_pm_qos_read_value(struct device *dev, enum dev_pm_qos_req_type type);
int dev_pm_qos_add_request(struct device *dev, struct dev_pm_qos_request *req,
enum dev_pm_qos_req_type type, s32 value);
int dev_pm_qos_update_request(struct dev_pm_qos_request *req, s32 new_value);
@@ -191,8 +191,18 @@ static inline enum pm_qos_flags_status
dev_pm_qos_flags(struct device *dev,
{ return PM_QOS_FLAGS_UNDEFINED; }
static inline s32 __dev_pm_qos_resume_latency(struct device *dev)
{ return PM_QOS_RESUME_LATENCY_NO_CONSTRAINT; }
-static inline s32 dev_pm_qos_read_value(struct device *dev)
- { return PM_QOS_RESUME_LATENCY_NO_CONSTRAINT; }
+static inline s32 dev_pm_qos_read_value(struct device *dev,
+ enum dev_pm_qos_req_type type)
+{
+ switch type {
+ case DEV_PM_QOS_RESUME_LATENCY:
+ return PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+}
+
static inline int dev_pm_qos_add_request(struct device *dev,
struct dev_pm_qos_request *req,
enum dev_pm_qos_req_type type,
--
2.21.0.rc0.269.g1a574e7a288b
[PATCH V4 5/6] cpufreq: Register notifiers with the PM QoS framework
This registers the notifiers for min/max frequency constraints with the
PM QoS framework. The constraints are also taken into consideration in
cpufreq_set_policy().
This also relocates cpufreq_policy_put_kobj() as it is required to be
called from cpufreq_policy_alloc() now.
reeval_frequency_limits() is updated to have proper locking in place and
avoid calling cpufreq_set_policy() for inactive policies.
No constraints are added until now though.
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 135 ++
include/linux/cpufreq.h | 3 +
2 files changed, 109 insertions(+), 29 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0a73de7aae54..b47a6c094171 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -999,7 +1000,7 @@ static void add_cpu_dev_symlink(struct cpufreq_policy
*policy, unsigned int cpu)
{
struct device *dev = get_cpu_device(cpu);
- if (!dev)
+ if (unlikely(!dev))
return;
if (cpumask_test_and_set_cpu(cpu, policy->real_cpus))
@@ -1117,14 +1118,20 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy
*policy, unsigned int cp
static void reeval_frequency_limits(struct cpufreq_policy *policy)
{
- struct cpufreq_policy new_policy = *policy;
+ struct cpufreq_policy new_policy;
- pr_debug("updating policy for CPU %u\n", policy->cpu);
+ down_write(&policy->rwsem);
+
+ if (!policy_is_inactive(policy)) {
+ new_policy = *policy;
+ pr_debug("updating policy for CPU %u\n", policy->cpu);
- new_policy.min = policy->user_policy.min;
- new_policy.max = policy->user_policy.max;
+ new_policy.min = policy->user_policy.min;
+ new_policy.max = policy->user_policy.max;
+ cpufreq_set_policy(policy, &new_policy);
+ }
- cpufreq_set_policy(policy, &new_policy);
+ up_write(&policy->rwsem);
}
static void handle_update(struct work_struct *work)
@@ -1136,11 +1143,55 @@ static void handle_update(struct work_struct *work)
reeval_frequency_limits(policy);
}
+static int cpufreq_notifier_min(struct notifier_block *nb, unsigned long freq,
+ void *data)
+{
+ struct cpufreq_policy *policy = container_of(nb, struct cpufreq_policy,
nb_min);
+
+ schedule_work(&policy->update);
+ return 0;
+}
+
+static int cpufreq_notifier_max(struct notifier_block *nb, unsigned long freq,
+ void *data)
+{
+ struct cpufreq_policy *policy = container_of(nb, struct cpufreq_policy,
nb_max);
+
+ schedule_work(&policy->update);
+ return 0;
+}
+
+static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
+{
+ struct kobject *kobj;
+ struct completion *cmp;
+
+ down_write(&policy->rwsem);
+ cpufreq_stats_free_table(policy);
+ kobj = &policy->kobj;
+ cmp = &policy->kobj_unregister;
+ up_write(&policy->rwsem);
+ kobject_put(kobj);
+
+ /*
+* We need to make sure that the underlying kobj is
+* actually not referenced anymore by anybody before we
+* proceed with unloading.
+*/
+ pr_debug("waiting for dropping of refcount\n");
+ wait_for_completion(cmp);
+ pr_debug("wait complete\n");
+}
+
static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
{
struct cpufreq_policy *policy;
+ struct device *dev = get_cpu_device(cpu);
int ret;
+ if (!dev)
+ return NULL;
+
policy = kzalloc(sizeof(*policy), GFP_KERNEL);
if (!policy)
return NULL;
@@ -1157,7 +1208,7 @@ static struct cpufreq_policy
*cpufreq_policy_alloc(unsigned int cpu)
ret = kobject_init_and_add(&policy->kobj, &ktype_cpufreq,
cpufreq_global_kobject, "policy%u", cpu);
if (ret) {
- pr_err("%s: failed to init policy->kobj: %d\n", __func__, ret);
+ dev_err(dev, "%s: failed to init policy->kobj: %d\n", __func__,
ret);
/*
* The entire policy object will be freed below, but the extra
* memory allocated for the kobject name needs to be freed by
@@ -1167,6 +1218,25 @@ static struct cpufreq_policy
*cpufreq_policy_alloc(unsigned int cpu)
goto err_free_real_cpus;
}
+ policy->nb_min.notifier_call = cpufreq_notifier_min;
+ policy->nb_max.notifier_call = cpufreq_notifier_max;
+
+ ret = dev_pm_qos_add_notifier(dev, &policy->nb_min,
+ DEV_PM_QOS_MIN_FREQUENCY);
+ if (ret) {
+ dev_err(dev, "Failed to register MIN QoS notifier: %d
(%*pbl)\n",
+
[PATCH V4 0/6] cpufreq: Use QoS layer to manage freq-constraints
Hello,
This patchset attempts to manage CPU frequency constraints using the PM
QoS framework. It only does the basic stuff right now and moves the
userspace constraints to use the QoS infrastructure.
This is rebased over pm/linux-next and another cleanup series [1].
Todo:
- Migrate all users to the QoS framework and get rid of cpufreq specific
notifiers.
- Make PM QoS learn about the relation of CPUs in a policy, so a single
list of constraints is managed for all of them instead of per-cpu
constraints.
V3->V4:
- Few commit logs updated as suggested during reviews.
- Separate commit (2/6) to create resume-latency specific routines
- Reused earlier work ("update") for notifiers as well.
- Kept Reviewed-by tags as is as the patches normally got better only.
Please take them back if you find any issues.
V2->V3:
- Add a comment in cpufreq.c as suggested by Qais.
- Rebased on latest pm/linux-next.
V1->V2:
- The previous version introduced a completely new framework, this one
moves to PM QoS instead.
- Lots of changes because of this.
--
viresh
[1] http://lore.kernel.org/lkml/cover.1560999838.git.viresh.ku...@linaro.org
Viresh Kumar (6):
PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()
PM / QOS: Rename __dev_pm_qos_read_value() and
dev_pm_qos_raw_read_value()
PM / QOS: Pass request type to dev_pm_qos_read_value()
PM / QoS: Add support for MIN/MAX frequency constraints
cpufreq: Register notifiers with the PM QoS framework
cpufreq: Add QoS requests for userspace constraints
Documentation/power/pm_qos_interface.txt | 12 +-
drivers/base/power/domain.c | 8 +-
drivers/base/power/domain_governor.c | 4 +-
drivers/base/power/qos.c | 135 ++--
drivers/base/power/runtime.c | 2 +-
drivers/cpufreq/cpufreq.c| 198 ---
drivers/cpuidle/governor.c | 2 +-
include/linux/cpufreq.h | 11 +-
include/linux/pm_qos.h | 48 --
9 files changed, 316 insertions(+), 104 deletions(-)
--
2.21.0.rc0.269.g1a574e7a288b
Re: [PATCH v2.5 2/3] firmware: Add support for loading compressed files
On Thu, 20 Jun 2019 01:26:47 +0200,
Luis Chamberlain wrote:
>
> Sorry for the late review... Ah!
No problem, thanks for review.
> On Tue, Jun 11, 2019 at 02:26:25PM +0200, Takashi Iwai wrote:
> > @@ -354,7 +454,12 @@ module_param_string(path, fw_path_para,
> > sizeof(fw_path_para), 0644);
> > MODULE_PARM_DESC(path, "customized firmware image search path with a
> > higher priority than default path");
> >
> > static int
> > -fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv)
> > +fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
> > + const char *suffix,
> > + int (*decompress)(struct device *dev,
> > +struct fw_priv *fw_priv,
> > +size_t in_size,
> > +const void *in_buffer))
>
> I *think* this could be cleaner, I'll elaborate below.
>
> > @@ -645,7 +768,13 @@ _request_firmware(const struct firmware **firmware_p,
> > const char *name,
> > if (ret <= 0) /* error or already assigned */
> > goto out;
> >
> > - ret = fw_get_filesystem_firmware(device, fw->priv);
> > + ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL);
> > +#ifdef CONFIG_FW_LOADER_COMPRESS
> > + if (ret == -ENOENT)
> > + ret = fw_get_filesystem_firmware(device, fw->priv, ".xz",
> > +fw_decompress_xz);
> > +#endif
>
> Hrm, and let more #ifdef'ery.
>
> And so if someone wants to add bzip, we'd add yet-another if else on the
> return value of this call... and yet more #ifdefs.
>
> We already have a list of paths supported. It seems what we need instead
> is a list of supported suffixes, and a respective structure which then
> has its set of callbacks for posthandling.
>
> This way, this could all be handled inside fw_get_filesystem_firmware()
> neatly, and we can just strive towards avoiding #ifdef'ery.
Yes, I had similar idea. Actually my plan for multiple compression
formats was:
- Move the decompression part into another file, e.g. decompress_xz.c
and change in Makefile:
firmware_class-$(CONFIG_FW_LOADER_COMPRESS_XZ) += decompress_xz.o
- Create a table of the extension and the decompression,
static struct fw_decompression_table fw_decompressions[] = {
{ "", NULL },
#ifdef CONFIG_FW_LOADER_COMPRESS_XZ
{ ".xz", fw_decompress_xz },
#endif
#ifdef CONFIG_FW_LOADER_COMPRESS_BZIP2
{ ".bz2", fw_decompress_bzip2 },
#endif
.
};
and call it
for (i = 0; i < ARRAY_SIZE(fw_decompressions); i++) {
ret = fw_get_filesystem_firmware(device, fw->priv,
fw_decompressions[i].extesnion,
fw_decompressions[i].func);
if (ret != -ENOENT)
break;
}
The patch was submitted in the current form just because it's simpler
for a single compression case. But as you can see in the v2 patchset
change, it has already the decompression function pointer, so that the
code can be cleaned up / extended easily later if multiple formats are
supported like the above.
BTW, I took a look at other compression methods, and found that LZ4 is
a bit tough with the current API. ZSTD should be relatively easy, as
it can get the whole decompressed size at first, so we'll be able to
do vmalloc(). For others, we may need a streaming decompression and
growing buffer per page. But LZ4 decompression API doesn't seem
allowing the partial decompression-and-continue as I used for XZ, so
it'll be tricky.
GZIP and BZIP2 should work in a streaming mode like XZ, I suppose.
thanks,
Takashi
[PATCH V4 1/6] PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()
In order to use the same set of routines to register notifiers for
different request types, update the existing
dev_pm_qos_{add|remove}_notifier() routines with an additional
parameter: request-type.
For now, it only supports resume-latency request type but will be
extended to frequency limit (min/max) constraints later on.
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
Documentation/power/pm_qos_interface.txt | 10 ++
drivers/base/power/domain.c | 8 +---
drivers/base/power/qos.c | 14 --
include/linux/pm_qos.h | 12
4 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/Documentation/power/pm_qos_interface.txt
b/Documentation/power/pm_qos_interface.txt
index 19c5f7b1a7ba..ec7d662d1707 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -164,12 +164,14 @@ directory.
Notification mechanisms:
The per-device PM QoS framework has a per-device notification tree.
-int dev_pm_qos_add_notifier(device, notifier):
-Adds a notification callback function for the device.
+int dev_pm_qos_add_notifier(device, notifier, type):
+Adds a notification callback function for the device for a particular request
+type.
+
The callback is called when the aggregated value of the device constraints list
-is changed (for resume latency device PM QoS only).
+is changed.
-int dev_pm_qos_remove_notifier(device, notifier):
+int dev_pm_qos_remove_notifier(device, notifier, type):
Removes the notification callback function for the device.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 33c30c1e6a30..b063bc41b0a9 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1536,7 +1536,8 @@ static int genpd_add_device(struct generic_pm_domain
*genpd, struct device *dev,
if (ret)
genpd_free_dev_data(dev, gpd_data);
else
- dev_pm_qos_add_notifier(dev, &gpd_data->nb);
+ dev_pm_qos_add_notifier(dev, &gpd_data->nb,
+ DEV_PM_QOS_RESUME_LATENCY);
return ret;
}
@@ -1569,7 +1570,8 @@ static int genpd_remove_device(struct generic_pm_domain
*genpd,
pdd = dev->power.subsys_data->domain_data;
gpd_data = to_gpd_data(pdd);
- dev_pm_qos_remove_notifier(dev, &gpd_data->nb);
+ dev_pm_qos_remove_notifier(dev, &gpd_data->nb,
+ DEV_PM_QOS_RESUME_LATENCY);
genpd_lock(genpd);
@@ -1597,7 +1599,7 @@ static int genpd_remove_device(struct generic_pm_domain
*genpd,
out:
genpd_unlock(genpd);
- dev_pm_qos_add_notifier(dev, &gpd_data->nb);
+ dev_pm_qos_add_notifier(dev, &gpd_data->nb, DEV_PM_QOS_RESUME_LATENCY);
return ret;
}
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index 6c91f8df1d59..cfd463212513 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -467,6 +467,7 @@ EXPORT_SYMBOL_GPL(dev_pm_qos_remove_request);
*
* @dev: target device for the constraint
* @notifier: notifier block managed by caller.
+ * @type: request type.
*
* Will register the notifier into a notification chain that gets called
* upon changes to the target value for the device.
@@ -474,10 +475,14 @@ EXPORT_SYMBOL_GPL(dev_pm_qos_remove_request);
* If the device's constraints object doesn't exist when this routine is
called,
* it will be created (or error code will be returned if that fails).
*/
-int dev_pm_qos_add_notifier(struct device *dev, struct notifier_block
*notifier)
+int dev_pm_qos_add_notifier(struct device *dev, struct notifier_block
*notifier,
+ enum dev_pm_qos_req_type type)
{
int ret = 0;
+ if (WARN_ON(type != DEV_PM_QOS_RESUME_LATENCY))
+ return -EINVAL;
+
mutex_lock(&dev_pm_qos_mtx);
if (IS_ERR(dev->power.qos))
@@ -500,15 +505,20 @@ EXPORT_SYMBOL_GPL(dev_pm_qos_add_notifier);
*
* @dev: target device for the constraint
* @notifier: notifier block to be removed.
+ * @type: request type.
*
* Will remove the notifier from the notification chain that gets called
* upon changes to the target value.
*/
int dev_pm_qos_remove_notifier(struct device *dev,
- struct notifier_block *notifier)
+ struct notifier_block *notifier,
+ enum dev_pm_qos_req_type type)
{
int retval = 0;
+ if (WARN_ON(type != DEV_PM_QOS_RESUME_LATENCY))
+ return -EINVAL;
+
mutex_lock(&dev_pm_qos_mtx);
/* Silently return if the constraints object is not present. */
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 6ea1ae373d77..1f4d456e8fff 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -146,9 +146,11 @@ int dev_pm_qos_add_request(struct d
[PATCH V4 6/6] cpufreq: Add QoS requests for userspace constraints
This implements QoS requests to manage userspace configuration of min
and max frequency.
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 87 ---
include/linux/cpufreq.h | 8 +---
2 files changed, 46 insertions(+), 49 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b47a6c094171..5d050b4a3806 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -718,23 +718,15 @@ static ssize_t show_scaling_cur_freq(struct
cpufreq_policy *policy, char *buf)
static ssize_t store_##file_name \
(struct cpufreq_policy *policy, const char *buf, size_t count) \
{ \
- int ret, temp; \
- struct cpufreq_policy new_policy; \
+ unsigned long val; \
+ int ret;\
\
- memcpy(&new_policy, policy, sizeof(*policy)); \
- new_policy.min = policy->user_policy.min; \
- new_policy.max = policy->user_policy.max; \
- \
- ret = sscanf(buf, "%u", &new_policy.object);\
+ ret = sscanf(buf, "%lu", &val); \
if (ret != 1) \
return -EINVAL; \
\
- temp = new_policy.object; \
- ret = cpufreq_set_policy(policy, &new_policy); \
- if (!ret) \
- policy->user_policy.object = temp; \
- \
- return ret ? ret : count; \
+ ret = dev_pm_qos_update_request(policy->object##_freq_req, val);\
+ return ret >= 0 ? count : ret; \
}
store_one(scaling_min_freq, min);
@@ -1126,8 +1118,6 @@ static void reeval_frequency_limits(struct cpufreq_policy
*policy)
new_policy = *policy;
pr_debug("updating policy for CPU %u\n", policy->cpu);
- new_policy.min = policy->user_policy.min;
- new_policy.max = policy->user_policy.max;
cpufreq_set_policy(policy, &new_policy);
}
@@ -1237,6 +1227,12 @@ static struct cpufreq_policy
*cpufreq_policy_alloc(unsigned int cpu)
goto err_min_qos_notifier;
}
+ policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
+ GFP_KERNEL);
+ if (!policy->min_freq_req)
+ goto err_max_qos_notifier;
+
+ policy->max_freq_req = policy->min_freq_req + 1;
INIT_LIST_HEAD(&policy->policy_list);
init_rwsem(&policy->rwsem);
spin_lock_init(&policy->transition_lock);
@@ -1247,6 +1243,9 @@ static struct cpufreq_policy
*cpufreq_policy_alloc(unsigned int cpu)
policy->cpu = cpu;
return policy;
+err_max_qos_notifier:
+ dev_pm_qos_remove_notifier(dev, &policy->nb_max,
+ DEV_PM_QOS_MAX_FREQUENCY);
err_min_qos_notifier:
dev_pm_qos_remove_notifier(dev, &policy->nb_min,
DEV_PM_QOS_MIN_FREQUENCY);
@@ -1282,6 +1281,9 @@ static void cpufreq_policy_free(struct cpufreq_policy
*policy)
DEV_PM_QOS_MAX_FREQUENCY);
dev_pm_qos_remove_notifier(dev, &policy->nb_min,
DEV_PM_QOS_MIN_FREQUENCY);
+ dev_pm_qos_remove_request(policy->max_freq_req);
+ dev_pm_qos_remove_request(policy->min_freq_req);
+ kfree(policy->min_freq_req);
cpufreq_policy_put_kobj(policy);
free_cpumask_var(policy->real_cpus);
@@ -1360,16 +1362,30 @@ static int cpufreq_online(unsigned int cpu)
cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
if (new_policy) {
- policy->user_policy.min = policy->min;
- policy->user_policy.max = policy->max;
+ struct device *dev = get_cpu_device(cpu);
for_each_cpu(j, policy->related_cpus) {
per_cpu(cpufreq_cpu_data, j) = policy;
add_cpu_dev_symlink(policy, j);
}
- } else {
- policy->min = policy->user_policy.min;
- policy->max = policy->use
[PATCH V4] regulator: da9061/62: Adjust LDO voltage selection minimum value
From: Felix Riemann According to the DA9061 and DA9062 datasheets the LDO voltage selection registers have a lower value of 0x02. This applies to voltage registers VLDO1_A, VLDO2_A, VLDO3_A and VLDO4_A. This linear offset of 0x02 was previously not observed by the driver, causing the LDO output voltage to be systematically lower by two steps (= 0.1V). This patch fixes the minimum linear selector offset by setting it to a value of 2 and increases the n_voltages by the same amount allowing voltages in the range 0x02 -> 0.9V to 0x38 -> 3.6V to be correctly selected. Also fixes an incorrect calculaton for the n_voltages value in the regulator LDO2. These fixes effect all LDO regulators for DA9061 and DA9062. Acked-by: Steve Twiss Tested-by: Steve Twiss Signed-off-by: Felix Riemann Signed-off-by: Steve Twiss --- Patch history v2 - Fix whitespace problems, slight refactor and correct n_voltages calc v3 - Addition of missing signed-off-by tag from sender v4 - Correct order for Signed-off-by tags in commit message Regards, Steve drivers/regulator/da9062-regulator.c | 40 +--- include/linux/mfd/da9062/registers.h | 3 +++ 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c index a02e048..1cadaae 100644 --- a/drivers/regulator/da9062-regulator.c +++ b/drivers/regulator/da9062-regulator.c @@ -493,12 +493,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO1_CONT, .desc.enable_mask = DA9062AA_LDO1_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO1_A, .desc.vsel_mask = DA9062AA_VLDO1_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO1_A, __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -525,12 +526,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (600))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO2_CONT, .desc.enable_mask = DA9062AA_LDO2_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO2_A, .desc.vsel_mask = DA9062AA_VLDO2_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO2_A, __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -557,12 +559,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO3_CONT, .desc.enable_mask = DA9062AA_LDO3_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO3_A, .desc.vsel_mask = DA9062AA_VLDO3_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO3_A, __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -589,12 +592,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO4_CONT, .desc.enable_mask = DA9062AA_LDO4_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO4_A, .desc.vsel_mask = DA9062AA_VLDO4_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO4_A, __builtin_ffs((
Re: [PATCH RFC 0/3] Automatically choose a bigger font for high resolution screens
On Thu, 20 Jun 2019 08:28:21 +0200, Greg Kroah-Hartman wrote: > > On Tue, Jun 18, 2019 at 10:34:22PM +0200, Takashi Iwai wrote: > > Hi, > > > > this is an RFC patch for automatically selecting a bigger font for > > high resolution monitors if available. Although we recently got a > > 16x32 sized font support in the kernel, using it still requires some > > extra kernel option. This patch reduces this and the kernel will pick > > up a bigger font. > > > > The logic is simply checking the text screen size. If it's over a > > threshold, the penalty is given to the function that chooses the > > default font. > > > > The threshold was chosen so that the normal display up to Full HD > > won't be affected. > > > > There are two preliminary patches and they are merely cleanups. They > > can be applied no matter whether to take the last patch or not. > > I applied the first two patches, as they seem sane. Thanks! > I like the idea of the last one, and have no objections to it. I can > apply it too if you want and we can see what happens :) OK, then let's go ahead. We can see what people react if they can read a kernel crash message without glasses :) Takashi
Re: [PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface
On Thu, Jun 20, 2019 at 05:56:32AM +, Parshuram Raju Thombare wrote: > For in band mode, I see two places to config MAC speed > and duplex mode, 1. mac_link_state 2. mac_link_up. In mac_link_up, though > state > read from mac_link_state is passed, it is only used for printing log and > updating > pl->cur_interface, so if configuring MAC speed/duplex mode in mac_link_up is > correct, > these parameters will need to read again from HW. That is incorrect. Again, please read the phylink documentation. There is even an article on how to convert drivers. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE
Hi Nick, On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote: > Generated via: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make savedefconfig > $ mv defconfig arch/arm64/configs/defconfig Hmm, I'm in two minds about whether we want this on by default. On the plus side, it gets us extra testing coverage, although the /vast/ majority of firmware implementations I run into either don't pass a seed or don't provide a working EFI_RNG. Perhaps that's just a chicken-and-egg problem which can be solved if we shout loud enough when we fail to randomize; we'll also eventually be in a better position when CPUs start implementing the v8.5 RNG instructions (but don't hold your breath unless you have an unusually high lung capacity). On the flip side, I worry that it could make debugging more difficult, but I don't know whether that's a genuine concern or not. I'm assuming you've debugged your fair share of crashes from KASLR-enabled kernels; how bad is it? (I'm thinking of the case where somebody mails you part of a panic log and a .config). Irrespective of the above, I know Catalin was running into issues with his automated tests where the kernel would die silently during early boot with some seeds. That's a bit rubbish if it's still the case -- Catalin? Finally, I know that (K)ASLR can be a bit controversial amongst security folks, with some seeing it as purely a smoke-and-mirrors game with no tangible benefits other than making us feel better about ourselves. Is it still the case that it can be trivially bypassed, or do you see it actually preventing some attacks in production? Sorry for the barrage of questions, but I think enabling this one by default is quite a significant thing to do and probably deserves a bit of scrutiny beforehand. Cheers, Will
Re: SPDX conversion under scripts/dtc/ of Linux Kernel
On Wed, Jun 19, 2019 at 09:39:13AM -0600, Rob Herring wrote: > On Wed, Jun 19, 2019 at 6:59 AM Greg Kroah-Hartman > wrote: > > > > On Wed, Jun 19, 2019 at 07:23:19PM +0900, Masahiro Yamada wrote: > > > Hi. > > > > > > In this development cycle of Linux kernel, > > > lots of files were converted to use SPDX > > > instead of the license boilerplate. > > > > > > However. > > > > > > Some files were imported from a different project, > > > and are periodically synchronized with the upstream. > > > Have we discussed what to do about this case? > > > > > > > > > For example, scripts/dtc/ is the case. > > > > > > The files in scripts/dtc/ are synced with the upstream > > > device tree compiler. > > > > > > Rob Herring periodically runs scripts/dtc/update-dtc-source.sh > > > to import outcome from the upstream. > > > > > > > > > The upstream DTC has not adopted SPDX yet. > > > > > > Some files in Linux (e.g. scripts/dtc/dtc.c) > > > have been converted to SPDX. > > > > > > So, they are out of sync now. > > > > > > The license boilerplate will come back > > > when Rob runs scripts/dtc/update-dtc-source.sh > > > next time. > > Already has. It just happened and is in next. The policy is everything > is upstream first and any changes to dtc in the kernel are rejected. > > > > > > > What shall we do? > > > > > > [1] Convert upstream DTC to SPDX > > > > > > This will be a happy solution if it is acceptable in DTC. > > > Since we cannot push the decision of the kernel to a different > > > project, this is totally up to David Gibson. > > > > That's fine with me :) > > I'll do the work if David is okay with it. I have no objection. > > > [2] Change scripts/dtc/update-dtc-source.sh to > > > take care of the license block somehow > > > > That would also be good. > > > > > [3] Go back to license boilerplate, and keep the files > > > synced with the upstream > > > (and scripts/dtc/ should be excluded from the > > > SPDX conversion tool.) > > > > nothing is being excluded from the SPDX conversions, sorry. The goal is > > to do this for every file in the kernel tree. Otherwise it's pointless. > > > > > Or, what else? > > > > Rob remembers to keep those first lines of the files intact when doing > > the next sync? > > Patches to the import script are welcome. The only thing I have to > remember running the script is to add any new files. Otherwise, it's > scripted so I don't have to remember anything. > > Rob > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> >>> +static inline u32 arc_gen_nop(void)
> >>> +{
> >>> + /* 1x 32bit NOP in middle endian */
> > I dare not ask...
>
> :-) The public PRM is being worked on for *real* so this will be remedied in
> a few
> months at best.
>
> Short answer is it specifies how instruction stream is laid out in code
> memory for
> efficient next PC decoding given that ARC can freely intermix 2, 4, 6, 8 byte
> instruction fragments w/o any restrictions.
>
> Consier SWI insn encoding: per PRM is
>
> 31 0
> --
> 00100010011000000011
> --
>
> In regular little endian notation, in memory it would have looked as
>
> 31 0
> 0x220x6F0x000x3F
> b3 b2 b1 b0
>
> However in middle endian format, the 2 short words are flipped
>
> 31 0
> 0x000x3F 0x22 0x6F
> b1 b0 b3 b2
I'm probably missing something here. I understand the I-fetch likes 2
byte chunks, but I'm not sure I understand how you end up with middle
endian.
With everything little endian, everything seems just fine. If you load
the first 2 byte at offset 0, you get the first 2 bytes of the
instruction.
If OTOH your arch big endian, and you were to load the first two bytes
at offset 0, you get the top two.
So this middle endian scheme, only seems to make sense if you're
otherwise big endian. But AFAICT ARC is bi-endian and the jump-label
patch under condsideration is explicitly !CPU_ENDIAN_BE32 -- which
suggests the instruction stream is sensitive to the endian selection.
Anyway, I was just 'surprised' at seeing middle endian mentioned,
curiosity killed the cat and all that :-)
Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor
On 6/20/19 12:29 AM, Ryan Chen wrote: > Hello Tao, > Our recommend about clk divider setting is follow the datasheet clock > setting table for clock divisor. > > Ryan Thanks Ryan for the response. Could you also share some recommendations/hints on how to solve the intermittent i2c transaction failures on Facebook AST2500 BMC platforms? BTW, the patch is not aimed at modifying the existing formula of calculating clock settings in i2c-aspeed driver: people still get the recommended settings by default. The goal of the patch is to allow people to customize clock settings in case the default/recommended one doesn't work. Cheers, Tao
Re: cifs: Fix tracing build error with O=
On Thu, Jun 20, 2019 at 06:54:42AM +, yamada.masah...@socionext.com wrote: > > I cannot reproduce the build error on the latest Linus tree. > > > $ make O=build allmodconfig fs/cifs/ > > perfectly works for me. I was trying to build just the fs/cifs directory with make O=build M=fs/cifs But I see now that this can't possibly work as M= only supports absolute paths. As M= is supposed to replace SUBDIRS=, what are we supposed to do to build just a directory? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
RE: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor
Hello Tao, Our recommend about clk divider setting is follow the datasheet clock setting table for clock divisor. Ryan -Original Message- From: Linux-aspeed [mailto:linux-aspeed-bounces+ryan_chen=aspeedtech@lists.ozlabs.org] On Behalf Of Tao Ren Sent: Thursday, June 20, 2019 6:33 AM To: Brendan Higgins Cc: Mark Rutland ; devicetree ; linux-asp...@lists.ozlabs.org; OpenBMC Maillist ; Linux Kernel Mailing List ; Rob Herring ; Linux ARM ; linux-...@vger.kernel.org Subject: Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor On 6/19/19 2:25 PM, Brendan Higgins wrote: > On Wed, Jun 19, 2019 at 2:00 PM Tao Ren wrote: >> >> Some intermittent I2C transaction failures are observed on Facebook >> CMM and Minipack (ast2500) BMC platforms, because slave devices (such >> as CPLD, BIC and etc.) NACK the address byte sometimes. The issue can >> be resolved by increasing base clock divisor which affects ASPEED I2C >> Controller's base clock and other AC timing parameters. >> >> This patch allows to customize ASPEED I2C Controller's base clock >> divisor in device tree. > > First off, are you sure you actually need this? > > You should be able to achieve an effectively equivalent result by just > lowering the `bus-frequency` property specified in the DT. The > `bus-frequency` property ultimately determines all the register > values, and you should be able to set it to whatever you want by > refering to the Aspeed documentation. > > Nevertheless, the code that determines the correct dividers from the > frequency is based on the tables in the Aspeed documentation. I don't > think the equation makes sense when the base_clk_divisor is fixed; I > mean it will probably just set the other divisor to max or min > depending on the values chosen. I think if someone really wants to > program this parameter manually, they probably want to set the other > parameters manually too. Thank you for the quick response, Brendan. Aspeed I2C bus frequency is defined by 3 parameters (base_clk_divisor, clk_high_width, clk_low_width), and I choose base_clk_divisor because it controls all the Aspeed I2C timings (such as setup time and hold time). Once base_clk_divisor is decided (either by the current logic in i2c-aspeed driver or manually set in device tree), clk_high_width and clk_low_width will be calculated by i2c-aspeed driver to meet the specified I2C bus speed. For example, by setting I2C bus frequency to 100KHz on AST2500 platform, (base_clock_divisor, clk_high_width, clk_low_width) is set to (3, 15, 14) by our driver. But some slave devices (on CMM i2c-8 and Minipack i2c-0) NACK byte transactions with the default timing setting: the issue can be resolved by setting base_clk_divisor to 4, and (clk_high_width, clk_low_width) will be set to (7, 7) by our i2c-aspeed driver to achieve similar I2C bus speed. Not sure if my answer helps to address your concerns, but kindly let me know if you have further questions/suggestions. Thanks, Tao
RE: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor
Hello Tao, Let me more clear. When you set (3, 15, 14) the device sometimes response nack. but when you set (4, 7, 7), the device always ack. Am I right? Ryan -Original Message- From: Tao Ren [mailto:tao...@fb.com] Sent: Thursday, June 20, 2019 3:57 PM To: Ryan Chen ; Brendan Higgins Cc: Mark Rutland ; devicetree ; linux-asp...@lists.ozlabs.org; OpenBMC Maillist ; Linux Kernel Mailing List ; Rob Herring ; Linux ARM ; linux-...@vger.kernel.org Subject: Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor On 6/20/19 12:29 AM, Ryan Chen wrote: > Hello Tao, > Our recommend about clk divider setting is follow the datasheet clock > setting table for clock divisor. > > Ryan Thanks Ryan for the response. Could you also share some recommendations/hints on how to solve the intermittent i2c transaction failures on Facebook AST2500 BMC platforms? BTW, the patch is not aimed at modifying the existing formula of calculating clock settings in i2c-aspeed driver: people still get the recommended settings by default. The goal of the patch is to allow people to customize clock settings in case the default/recommended one doesn't work. Cheers, Tao
Re: [PATCH][V2] x86/apic: fix integer overflow on 10 bit left shift of cpu_khz
On Wed, Jun 19, 2019 at 07:14:46PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The left shift of unsigned int cpu_khz will overflow for large values
> of cpu_khz, so cast it to a long long before shifting it to avoid
> overvlow. For example, this can happen when cpu_khz is 4194305 (just
> less than 4.2 GHz). Also wrap line to avoid checkpatch wide line
> warning.
>
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 8c3ba8d04924 ("x86, apic: ack all pending irqs when crashed/on kexec")
> Signed-off-by: Colin Ian King
> ---
> arch/x86/kernel/apic/apic.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 8956072f677d..31426126e5e0 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1464,7 +1464,8 @@ static void apic_pending_intr_clear(void)
> if (queued) {
> if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
> ntsc = rdtsc();
> - max_loops = (cpu_khz << 10) - (ntsc - tsc);
> + max_loops = ((long long)cpu_khz << 10) -
> + (ntsc - tsc);
> } else {
> max_loops--;
> }
> --
>
> V2: replace right with left in commit subject and message. Doh.
>
Uh, why are you putting the v2 explanation here instead of between the
--- cut off and the diffstat/
regards,
dan carpenter
Re: [PATCH] staging: rtl8723bs: hal: hal_btcoex: Remove variables pHalData and pU1Tmp
Looks good. Reviewed-by: Dan Carpenter regards, dan carpenter
selftests: bpf: test_libbpf.sh failed at file test_l4lb.o
selftests: bpf test_libbpf.sh failed running Linux -next kernel 20190618 and 20190619. Here is the log from x86_64, # selftests bpf test_libbpf.sh bpf: test_libbpf.sh_ # # [0] libbpf BTF is required, but is missing or corrupted. libbpf: BTF_is # # test_libbpf failed at file test_l4lb.o failed: at_file # # selftests test_libbpf [FAILED] test_libbpf: [FAILED]_ # [FAIL] 29 selftests bpf test_libbpf.sh selftests: bpf_test_libbpf.sh [FAIL] Full test log, https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190619/testrun/781777/log Test results comparison, https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_libbpf.sh Good linux -next tag: next-20190617 Bad linux -next tag: next-20190618 git branch master git commit1c6b40509daf5190b1fd2c758649f7df1da4827b git repo https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Best regards Naresh Kamboju
Re: [PATCH v2.5 2/3] firmware: Add support for loading compressed files
On Thu, Jun 20, 2019 at 09:36:03AM +0200, Takashi Iwai wrote:
> On Thu, 20 Jun 2019 01:26:47 +0200,
> Luis Chamberlain wrote:
> >
> > Sorry for the late review... Ah!
>
> No problem, thanks for review.
>
> > On Tue, Jun 11, 2019 at 02:26:25PM +0200, Takashi Iwai wrote:
> > > @@ -354,7 +454,12 @@ module_param_string(path, fw_path_para,
> > > sizeof(fw_path_para), 0644);
> > > MODULE_PARM_DESC(path, "customized firmware image search path with a
> > > higher priority than default path");
> > >
> > > static int
> > > -fw_get_filesystem_firmware(struct device *device, struct fw_priv
> > > *fw_priv)
> > > +fw_get_filesystem_firmware(struct device *device, struct fw_priv
> > > *fw_priv,
> > > +const char *suffix,
> > > +int (*decompress)(struct device *dev,
> > > + struct fw_priv *fw_priv,
> > > + size_t in_size,
> > > + const void *in_buffer))
> >
> > I *think* this could be cleaner, I'll elaborate below.
> >
> > > @@ -645,7 +768,13 @@ _request_firmware(const struct firmware
> > > **firmware_p, const char *name,
> > > if (ret <= 0) /* error or already assigned */
> > > goto out;
> > >
> > > - ret = fw_get_filesystem_firmware(device, fw->priv);
> > > + ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL);
> > > +#ifdef CONFIG_FW_LOADER_COMPRESS
> > > + if (ret == -ENOENT)
> > > + ret = fw_get_filesystem_firmware(device, fw->priv, ".xz",
> > > + fw_decompress_xz);
> > > +#endif
> >
> > Hrm, and let more #ifdef'ery.
> >
> > And so if someone wants to add bzip, we'd add yet-another if else on the
> > return value of this call... and yet more #ifdefs.
> >
> > We already have a list of paths supported. It seems what we need instead
> > is a list of supported suffixes, and a respective structure which then
> > has its set of callbacks for posthandling.
> >
> > This way, this could all be handled inside fw_get_filesystem_firmware()
> > neatly, and we can just strive towards avoiding #ifdef'ery.
>
> Yes, I had similar idea. Actually my plan for multiple compression
> formats was:
>
> - Move the decompression part into another file, e.g. decompress_xz.c
> and change in Makefile:
> firmware_class-$(CONFIG_FW_LOADER_COMPRESS_XZ) += decompress_xz.o
>
> - Create a table of the extension and the decompression,
>
> static struct fw_decompression_table fw_decompressions[] = {
> { "", NULL },
> #ifdef CONFIG_FW_LOADER_COMPRESS_XZ
> { ".xz", fw_decompress_xz },
> #endif
> #ifdef CONFIG_FW_LOADER_COMPRESS_BZIP2
> { ".bz2", fw_decompress_bzip2 },
> #endif
> .
> };
But why? Why not just stick with one for now, we don't need a zillion
different formats to start with. Let's just stick with .xz and that's
it. There is no need to do anything else for the foreseeable future.
thanks,
greg k-h
Re: [PATCH v12 00/31] Speculative page faults
Hi Laurent, I downloaded your script and run it on Intel 2s skylake platform with spf-v12 patch serials. Here attached the output results of this script. The following comparison result is statistics from the script outputs. a). Enable THP SPF_0 change SPF_1 will-it-scale.page_fault2.per_thread_ops2664190.8 -11.7% 2353637.6 will-it-scale.page_fault3.per_thread_ops4480027.2 -14.7% 3819331.9 b). Disable THP SPF_0 change SPF_1 will-it-scale.page_fault2.per_thread_ops2653260.7 -10% 2385165.8 will-it-scale.page_fault3.per_thread_ops4436330.1 -12.4% 3886734.2 Thanks, Haiyan Song On Fri, Jun 14, 2019 at 10:44:47AM +0200, Laurent Dufour wrote: > Le 14/06/2019 à 10:37, Laurent Dufour a écrit : > > Please find attached the script I run to get these numbers. > > This would be nice if you could give it a try on your victim node and share > > the result. > > Sounds that the Intel mail fitering system doesn't like the attached shell > script. > Please find it there: > https://gist.github.com/ldu4/a5cc1a93f293108ea387d43d5d5e7f44 > > Thanks, > Laurent. > THP always SPF 0 average:2628818 average:2732209 average:2728392 average:2550695 average:2689873 average:2691963 average:2627612 average:2558295 average:2707877 average:2726174 SPF 1 average:2426260 average:2145674 average:2117769 average:2292502 average:2350403 average:2483327 average:2467324 average:2335393 average:2437859 average:2479865 THP never SPF 0 average:2712575 average:2711447 average:2672362 average:2701981 average:2668073 average:2579296 average:2662048 average:2637422 average:2579143 average:2608260 SPF 1 average:2348782 average:2203349 average:2312960 average:2402995 average:2318914 average:2543129 average:2390337 average:2490178 average:2416798 average:2424216 THP always SPF 0 average:4370143 average:4245754 average:4678884 average:4665759 average:4665809 average:4639132 average:4210755 average:4330552 average:4290469 average:4703015 SPF 1 average:3810608 average:3918890 average:3758003 average:3965024 average:3578151 average:3822748 average:3687293 average:3998701 average:3915771 average:3738130 THP never SPF 0 average:4505598 average:4672023 average:4701787 average:4355885 average:4338397 average:4446350 average:4360811 average:4653767 average:4016352 average:4312331 SPF 1 average:3685383 average:4029413 average:4051615 average:3747588 average:4058557 average:4042340 average:3971295 average:3752943 average:3750626 average:3777582
[PATCH 1/3] slimbus: fix kerneldoc comments
From: Jonathan Corbet
The kerneldoc comments in drivers/slimbus/stream.c were not properly
formatted, leading to a distinctly unsatisfying "no structured comments
found" warning in the docs build. Sprinkle some asterisks around so that
the comments will be properly recognized.
Signed-off-by: Jonathan Corbet
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/stream.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/slimbus/stream.c b/drivers/slimbus/stream.c
index 2fa05324ed07..75f87b3d8b95 100644
--- a/drivers/slimbus/stream.c
+++ b/drivers/slimbus/stream.c
@@ -84,7 +84,7 @@ static const int slim_presence_rate_table[] = {
512000,
};
-/*
+/**
* slim_stream_allocate() - Allocate a new SLIMbus Stream
* @dev:Slim device to be associated with
* @name: name of the stream
@@ -189,7 +189,7 @@ static int slim_get_prate_code(int rate)
return -EINVAL;
}
-/*
+/**
* slim_stream_prepare() - Prepare a SLIMbus Stream
*
* @rt: instance of slim stream runtime to configure
@@ -336,7 +336,7 @@ static int slim_activate_channel(struct slim_stream_runtime
*stream,
return slim_do_transfer(sdev->ctrl, &txn);
}
-/*
+/**
* slim_stream_enable() - Enable a prepared SLIMbus Stream
*
* @stream: instance of slim stream runtime to enable
@@ -389,7 +389,7 @@ int slim_stream_enable(struct slim_stream_runtime *stream)
}
EXPORT_SYMBOL_GPL(slim_stream_enable);
-/*
+/**
* slim_stream_disable() - Disable a SLIMbus Stream
*
* @stream: instance of slim stream runtime to disable
@@ -423,7 +423,7 @@ int slim_stream_disable(struct slim_stream_runtime *stream)
}
EXPORT_SYMBOL_GPL(slim_stream_disable);
-/*
+/**
* slim_stream_unprepare() - Un-prepare a SLIMbus Stream
*
* @stream: instance of slim stream runtime to unprepare
@@ -449,7 +449,7 @@ int slim_stream_unprepare(struct slim_stream_runtime
*stream)
}
EXPORT_SYMBOL_GPL(slim_stream_unprepare);
-/*
+/**
* slim_stream_free() - Free a SLIMbus Stream
*
* @stream: instance of slim stream runtime to free
--
2.21.0
[PATCH 2/3] slimbus: remove redundant dev_err message
From: Ding Xiang
devm_ioremap_resource already contains error message, so remove
the redundant dev_err message
Signed-off-by: Ding Xiang
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/qcom-ctrl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/slimbus/qcom-ctrl.c b/drivers/slimbus/qcom-ctrl.c
index ad3e2e23f56e..a444badd8df5 100644
--- a/drivers/slimbus/qcom-ctrl.c
+++ b/drivers/slimbus/qcom-ctrl.c
@@ -528,10 +528,8 @@ static int qcom_slim_probe(struct platform_device *pdev)
slim_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ctrl");
ctrl->base = devm_ioremap_resource(ctrl->dev, slim_mem);
- if (IS_ERR(ctrl->base)) {
- dev_err(&pdev->dev, "IOremap failed\n");
+ if (IS_ERR(ctrl->base))
return PTR_ERR(ctrl->base);
- }
sctrl->set_laddr = qcom_set_laddr;
sctrl->xfer_msg = qcom_xfer_msg;
--
2.21.0
Re: [PATCH v2 2/5] nvme: rename "pci" operations to "mmio"
On Thu, Jun 20, 2019 at 2:11 PM Christoph Hellwig wrote: > The Linux NVMe driver will deal with NVMe as specified plus whatever > minor tweaks we'll need for small bugs. Hiding it behind an AHCI > device is completely out of scope and will not be accepted. Do you have any new suggestions for alternative ways we can implement support for this storage configuration? I tried to follow your earlier suggestions regarding faking a PCI bus here: (or let me know if you had something different in mind...) https://marc.info/?l=linux-pci&m=156015271021614&w=2 but it looks like that is not going to fly either :( Daniel
[PATCH 3/3] slimbus: core: generate uevent for non-dt only
Rely on MODULE_ALIAS() for automatic kernel module loading, rather than
basing it on the OF compatible. This ensures that drivers without
of_device_id table, such as wcd9335, will be automatically loaded.
Signed-off-by: Srinivas Kandagatla
[bjorn: Added commit message]
Signed-off-by: Bjorn Andersson
---
drivers/slimbus/core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
index b2f07d2043eb..526e3215d8fe 100644
--- a/drivers/slimbus/core.c
+++ b/drivers/slimbus/core.c
@@ -98,11 +98,6 @@ static int slim_device_remove(struct device *dev)
static int slim_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct slim_device *sbdev = to_slim_device(dev);
- int ret;
-
- ret = of_device_uevent_modalias(dev, env);
- if (ret != -ENODEV)
- return ret;
return add_uevent_var(env, "MODALIAS=slim:%s", dev_name(&sbdev->dev));
}
--
2.21.0
Re: [PATCH 1/5] media: venus: Add codec data table
Hi Stan,
On 2019-06-17 14:07, Stanimir Varbanov wrote:
Hi Aniket,
On 6/11/19 9:05 AM, Aniket Masule wrote:
Add vpp cycles for for different types of codec
It indicates the cycles required by video hardware
to process each macroblock.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/core.c | 13 +
drivers/media/platform/qcom/venus/core.h | 15 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 7393667..43eb446 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -473,9 +473,22 @@ static __maybe_unused int
venus_runtime_resume(struct device *dev)
{ 244800, 1 }, /* 1920x1080@30 */
};
+static struct codec_data sdm845_codec_data[] = {
+ { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_ENC, 675 },
+ { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_ENC, 675 },
+ { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_ENC, 675 },
+ { V4L2_PIX_FMT_MPEG2, VIDC_SESSION_TYPE_DEC, 200 },
+ { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_DEC, 200 },
+ { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_DEC, 200 },
+ { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_DEC, 200 },
+ { V4L2_PIX_FMT_VP9, VIDC_SESSION_TYPE_DEC, 200 },
+};
+
static const struct venus_resources sdm845_res = {
.freq_tbl = sdm845_freq_table,
.freq_tbl_size = ARRAY_SIZE(sdm845_freq_table),
+ .codec_data = sdm845_codec_data,
+ .codec_data_size = ARRAY_SIZE(sdm845_codec_data),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.max_load = 2563200,
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 7a3feb5..b1a9b43 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -35,12 +35,20 @@ struct reg_val {
u32 value;
};
+struct codec_data {
The name is very generic, could you rename the structure to something
like vpp_cycles_data?
I will be adding vsp_cycles with next patch for bitrate based clock
scaling.
So, I could rename it to codec_cycles_data.
+u32 pixfmt;
+u32 session_type;
+int vpp_cycles;
please check your editor, those fields should have a tab to the right.
+};
+
struct venus_resources {
u64 dma_mask;
const struct freq_tbl *freq_tbl;
unsigned int freq_tbl_size;
const struct reg_val *reg_tbl;
unsigned int reg_tbl_size;
+ const struct codec_data *codec_data;
+ unsigned int codec_data_size;
const char * const clks[VIDC_CLKS_NUM_MAX];
unsigned int clks_num;
enum hfi_version hfi_version;
@@ -216,6 +224,12 @@ struct venus_buffer {
struct list_head ref_list;
};
+struct clock_data {
+ u32 core_id;
+ unsigned long freq;
I cannot see how this 'freq' structure field is used? I can see that
you
fill it in 3/5 patch but you don't used nowhere.
Yes Stan, I will remove 'freq' from clock data structure.
+ struct codec_data *codec_data;
+};
Having the fact that freq field seems not needed can we just merge the
fields in venus_inst structure?
I will be adding 'freq' with next patch for bitrate based clock scaling.
So, it would be easier if we maintain separate structure from this
patch.
+
#define to_venus_buffer(ptr) container_of(ptr, struct venus_buffer,
vb)
/**
@@ -275,6 +289,7 @@ struct venus_inst {
struct list_head list;
struct mutex lock;
struct venus_core *core;
+ struct clock_data clk_data;
struct list_head dpbbufs;
struct list_head internalbufs;
struct list_head registeredbufs;
[PATCH 0/3] drivers: slimbus: patches for 5.3
Hi Greg, Here are some slimbus patches that are good to go in 5.3 One of them is doc fix and other one is redundant message and the last one is fix for module autoloading which have dt entry. Thanks, srini Ding Xiang (1): slimbus: remove redundant dev_err message Jonathan Corbet (1): slimbus: fix kerneldoc comments Srinivas Kandagatla (1): slimbus: core: generate uevent for non-dt only drivers/slimbus/core.c | 5 - drivers/slimbus/qcom-ctrl.c | 4 +--- drivers/slimbus/stream.c| 12 ++-- 3 files changed, 7 insertions(+), 14 deletions(-) -- 2.21.0
[PATCH] usb: dwc3: remove unused @lock member of dwc3_ep struct
The member @lock of dwc2_ep struct is only initialized,
and not used elsewhere, so remove it.
Signed-off-by: Chunfeng Yun
---
drivers/usb/dwc3/core.h | 2 --
drivers/usb/dwc3/gadget.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index f19cbeb01087..72d28cb14bdf 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -649,7 +649,6 @@ struct dwc3_event_buffer {
* @cancelled_list: list of cancelled requests for this endpoint
* @pending_list: list of pending requests for this endpoint
* @started_list: list of started requests on this endpoint
- * @lock: spinlock for endpoint request queue traversal
* @regs: pointer to first endpoint register
* @trb_pool: array of transaction buffers
* @trb_pool_dma: dma address of @trb_pool
@@ -677,7 +676,6 @@ struct dwc3_ep {
struct list_headpending_list;
struct list_headstarted_list;
- spinlock_t lock;
void __iomem*regs;
struct dwc3_trb *trb_pool;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d67655384eb2..7f75da30caba 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2251,8 +2251,6 @@ static int dwc3_gadget_init_endpoint(struct dwc3 *dwc, u8
epnum)
dep->endpoint.comp_desc = NULL;
}
- spin_lock_init(&dep->lock);
-
if (num == 0)
ret = dwc3_gadget_init_control_endpoint(dep);
else if (direction)
--
2.21.0
Re: [PATCH RFC 0/3] Automatically choose a bigger font for high resolution screens
On Thu, Jun 20, 2019 at 09:43:21AM +0200, Takashi Iwai wrote: > On Thu, 20 Jun 2019 08:28:21 +0200, > Greg Kroah-Hartman wrote: > > > > On Tue, Jun 18, 2019 at 10:34:22PM +0200, Takashi Iwai wrote: > > > Hi, > > > > > > this is an RFC patch for automatically selecting a bigger font for > > > high resolution monitors if available. Although we recently got a > > > 16x32 sized font support in the kernel, using it still requires some > > > extra kernel option. This patch reduces this and the kernel will pick > > > up a bigger font. > > > > > > The logic is simply checking the text screen size. If it's over a > > > threshold, the penalty is given to the function that chooses the > > > default font. > > > > > > The threshold was chosen so that the normal display up to Full HD > > > won't be affected. > > > > > > There are two preliminary patches and they are merely cleanups. They > > > can be applied no matter whether to take the last patch or not. > > > > I applied the first two patches, as they seem sane. > > Thanks! > > > I like the idea of the last one, and have no objections to it. I can > > apply it too if you want and we can see what happens :) > > OK, then let's go ahead. We can see what people react if they can > read a kernel crash message without glasses :) Now applied, thanks. greg k-h
Re: [PATCH 2/5] media: venus: Initialize codec data
Hi Stan,
On 2019-06-17 14:07, Stanimir Varbanov wrote:
Hi Aniket,
On 6/11/19 9:05 AM, Aniket Masule wrote:
Initialize the codec data with core resources.
Please squash this patch in 1/5 patch.
Yes Stan.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c | 30
+
drivers/media/platform/qcom/venus/helpers.h | 1 +
drivers/media/platform/qcom/venus/vdec.c| 4
drivers/media/platform/qcom/venus/venc.c| 4
4 files changed, 39 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 5cad601..f7f724b 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -715,6 +715,36 @@ int venus_helper_set_core_usage(struct venus_inst
*inst, u32 usage)
}
EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
+int venus_helper_init_codec_data(struct venus_inst *inst)
+{
+ const struct codec_data *codec_data;
+ unsigned int i, codec_data_size;
+ u32 pixfmt;
+ int ret = 0;
+
+ if (!IS_V4(inst->core))
+ return 0;
+
+ codec_data = inst->core->res->codec_data;
+ codec_data_size = inst->core->res->codec_data_size;
+ pixfmt = inst->session_type == VIDC_SESSION_TYPE_DEC ?
+ inst->fmt_out->pixfmt : inst->fmt_cap->pixfmt;
+
+ for (i = 0; i < codec_data_size; i++) {
+ if (codec_data[i].pixfmt == pixfmt &&
+ codec_data[i].session_type == inst->session_type) {
+ inst->clk_data.codec_data = &codec_data[i];
+ break;
+ }
+ }
+
+ if (!inst->clk_data.codec_data)
+ ret = -EINVAL;
just return -EINVAL
+
+ return ret;
return 0 is enough, and that will avoid ret variable.
Sure Stan.
+}
+EXPORT_SYMBOL_GPL(venus_helper_init_codec_data);
+
int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int
input_bufs,
unsigned int output_bufs,
unsigned int output2_bufs)
diff --git a/drivers/media/platform/qcom/venus/helpers.h
b/drivers/media/platform/qcom/venus/helpers.h
index 2475f284..f9360a8 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -41,6 +41,7 @@ int venus_helper_set_output_resolution(struct
venus_inst *inst,
unsigned int width, unsigned int height,
u32 buftype);
int venus_helper_set_work_mode(struct venus_inst *inst, u32 mode);
+int venus_helper_init_codec_data(struct venus_inst *inst);
int venus_helper_set_core_usage(struct venus_inst *inst, u32 usage);
int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int
input_bufs,
unsigned int output_bufs,
diff --git a/drivers/media/platform/qcom/venus/vdec.c
b/drivers/media/platform/qcom/venus/vdec.c
index 282de21..51795fd 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -660,6 +660,10 @@ static int vdec_init_session(struct venus_inst
*inst)
if (ret)
goto deinit;
+ ret = venus_helper_init_codec_data(inst);
+ if (ret)
+ goto deinit;
+
return 0;
deinit:
hfi_session_deinit(inst);
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 32cff29..792cdce 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -847,6 +847,10 @@ static int venc_init_session(struct venus_inst
*inst)
if (ret)
goto deinit;
+ ret = venus_helper_init_codec_data(inst);
+ if (ret)
+ goto deinit;
+
ret = venc_set_properties(inst);
if (ret)
goto deinit;
RE: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
Hi Uffe,
> -Original Message-
> From: Ulf Hansson
> Sent: Wednesday, June 19, 2019 7:09 PM
> To: Manish Narani
> Cc: Michal Simek ; Rob Herring ;
> Mark Rutland ; Adrian Hunter
> ; Rajan Vaja ; Jolly Shah
> ; Nava kishore Manne ; Olof
> Johansson ; linux-...@vger.kernel.org; DTML
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux ARM
> Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP
> Platform Tap Delays Setup
>
> On Wed, 19 Jun 2019 at 10:40, Manish Narani wrote:
> >
> > Hi Uffe,
> >
> >
> > > -Original Message-
> > > From: Ulf Hansson
> > > Sent: Monday, June 17, 2019 5:51 PM
> > [...]
> > >
> > > The "const struct zynqmp_eemi_ops *eemi_ops; should then be moved into
> > > a clock provider specific struct, which is assigned when calling
> > > sdhci_arasan_register_sdclk. I understand that all the clock data is
> > > folded into struct sdhci_arasan_data today, but I think that should be
> > > moved into a "sub-struct" for the clock specifics.
> > >
> > > Moreover, when registering the clock, we should convert from using
> > > devm_clk_register() into devm_clk_hw_register() as the first one is
> > > now deprecated.
> >
> > Just a query here:
> > When we switch to using devm_clk_hw_register() here, it will register the
> clk_hw and return int.
> > Is there a way we can get the clk (related to the clk_hw registered) from
> > the
> > clock framework?
> > I am asking this because we will need that clk pointer while calling
> clk_set_phase() function.
>
> I assume devm_clk_get() should work fine?
This clock does not come through ZynqMP Clock framework. We are initializing it
in this 'sdhci-of-arasan' driver and getting only the clock name from
"clock_output_names" property. So I think devm_clk_get() will not work here for
our case.
I have gone through the clock framework and I found one function which may be
used to create clock from clock hw, that is ' clk_hw_create_clk()' which can be
used from our driver, however this needs change in the clock framework as below
:
---
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index aa51756..4dc69ff 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3420,6 +3420,7 @@ struct clk *clk_hw_create_clk(struct device *dev, struct
clk_hw *hw,
return clk;
}
+EXPORT_SYMBOL_GPL(clk_hw_create_clk);
static int clk_cpy_name(const char **dst_p, const char *src, bool must_exist)
{
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
index d8400d6..2319899 100644
--- a/drivers/clk/clk.h
+++ b/drivers/clk/clk.h
@@ -22,17 +22,9 @@ static inline struct clk_hw *of_clk_get_hw(struct
device_node *np,
struct clk_hw *clk_find_hw(const char *dev_id, const char *con_id);
#ifdef CONFIG_COMMON_CLK
-struct clk *clk_hw_create_clk(struct device *dev, struct clk_hw *hw,
- const char *dev_id, const char *con_id);
void __clk_put(struct clk *clk);
#else
/* All these casts to avoid ifdefs in clkdev... */
-static inline struct clk *
-clk_hw_create_clk(struct device *dev, struct clk_hw *hw, const char *dev_id,
- const char *con_id)
-{
- return (struct clk *)hw;
-}
static struct clk_hw *__clk_get_hw(struct clk *clk)
{
return (struct clk_hw *)clk;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index f689fc5..d3f60fe 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -18,6 +18,7 @@
struct device;
struct clk;
+struct clk_hw;
struct device_node;
struct of_phandle_args;
@@ -934,4 +935,15 @@ static inline struct clk *of_clk_get_from_provider(struct
of_phandle_args *clksp
}
#endif
+#ifdef CONFIG_COMMON_CLK
+struct clk *clk_hw_create_clk(struct device *dev, struct clk_hw *hw,
+ const char *dev_id, const char *con_id);
+#else
+static inline struct clk *
+clk_hw_create_clk(struct device *dev, struct clk_hw *hw, const char *dev_id,
+ const char *con_id)
+{
+ return (struct clk *)hw;
+}
+#endif
#endif
---
This change should help other drivers (outside 'drivers/clk/') as well for
getting the clock created from clk_hw.
Is this fine to do?
Thanks,
Manish
Re: [PATCH 1/2] i2c: aspeed: allow to customize base clock divisor
On 6/20/19 1:01 AM, Ryan Chen wrote: > Hello Tao, > Let me more clear. When you set (3, 15, 14) the device sometimes > response nack. > but when you set (4, 7, 7), the device always ack. Am I right? > Ryan Hello Ryan, It's correct. We have seen the problem on 2 Facebook BMC platforms so far. Given the other ~10 Facebook BMC platforms are still running kernel 4.1 (with (4, 7, 7) settings), I'd assume more platforms will be impacted after upgrading to the latest kernel. Thank you for spending time on this! Cheers, Tao
Re: [PATCH] staging: vt6656: fix indentation on break statement
On Wed, Jun 19, 2019 at 05:54:05PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The break statement is indented one level too deep, fix this.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/vt6656/card.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
> index 08fc03d8740e..56cd77fd9ea0 100644
> --- a/drivers/staging/vt6656/card.c
> +++ b/drivers/staging/vt6656/card.c
> @@ -166,7 +166,7 @@ static void vnt_calculate_ofdm_rate(u16 rate, u8 bb_type,
> *tx_rate = 0x8b;
> *rsv_time = 30;
> }
> - break;
> + break;
> case RATE_9M:
> if (bb_type == BB_TYPE_11A) {
> *tx_rate = 0x9f;
> --
> 2.20.1
>
Reviewed-by: Quentin Deslandes
Regards,
Quentin
Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE
On Thu, 20 Jun 2019 at 09:47, Will Deacon wrote: > > Hi Nick, > > On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote: > > Generated via: > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig > > > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make savedefconfig > > $ mv defconfig arch/arm64/configs/defconfig > > Hmm, I'm in two minds about whether we want this on by default. On the plus > side, it gets us extra testing coverage, although the /vast/ majority of > firmware implementations I run into either don't pass a seed or don't > provide a working EFI_RNG. Perhaps that's just a chicken-and-egg problem > which can be solved if we shout loud enough when we fail to randomize; we'll > also eventually be in a better position when CPUs start implementing the > v8.5 RNG instructions (but don't hold your breath unless you have an > unusually high lung capacity). > For testing coverage purposes, exercising the relocation machinery etc even on no-kaslr boots would be beneficial imo. (The kernel is relocated once for non-kaslr boots and twice for kaslr boots on kaslr capable kernels) > On the flip side, I worry that it could make debugging more difficult, but I > don't know whether that's a genuine concern or not. I'm assuming you've > debugged your fair share of crashes from KASLR-enabled kernels; how bad is > it? (I'm thinking of the case where somebody mails you part of a panic log > and a .config). > When you are debugging using GDB, it can get a bit tedious, since you have to pass the offset when you load the symbols. However, in that case, you can just pass 'nokaslr' unless you are debugging something that is affected by the randomization. For reading backtraces etc, nothing really changes, since we get symbol+nnn/mmm entries (and the full panic log prints the KASLR offset as well, in case it matters) > Irrespective of the above, I know Catalin was running into issues with his > automated tests where the kernel would die silently during early boot with > some seeds. That's a bit rubbish if it's still the case -- Catalin? > Yes, it would be good if we could fix that. In fact, I would argue that having this change in would have increased the likelihood that someone else would have spotted it and fixed it :-) In fact, given how many Android phones are running this code: Nick, can you check if there are any KASLR related kernel fixes that haven't been upstreamed? > Finally, I know that (K)ASLR can be a bit controversial amongst security > folks, with some seeing it as purely a smoke-and-mirrors game with no > tangible benefits other than making us feel better about ourselves. Is it > still the case that it can be trivially bypassed, or do you see it actually > preventing some attacks in production? > > Sorry for the barrage of questions, but I think enabling this one by default > is quite a significant thing to do and probably deserves a bit of scrutiny > beforehand. > I think it is mostly controversial among non-security folks, who think that every mitigation by itself should be bullet proof. Security folks tend to think more about how each layer reduces the attack surface, hopefully resulting in a secure system when all layers are enabled. So KASLR is known to be broken unless you enable KPTI as well, so that is something we could take into account. I.e., mitigations that don't reduce the attack surface at all are just pointless complexity, which should obviously be avoided. Another thing to note is that the runtime cost of KASLR is ~zero, with the exception of the module PLTs. However, the latter could do with some additional coverage as well, so in summary, I think enabling this is a good thing. Otherwise, we could disable full module randomization so that the module PLT code doesn't get used in practice. Acked-by: Ard Biesheuvel
Re: [PATCH] KVM: vmx: Fix the broken usage of vmx_xsaves_supported
On 20/06/19 08:46, Xiaoyao Li wrote: >> >> It depends on whether or not processors support the 1-setting instead >> of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway, > > Yes, whether this field exist or not depends on whether processors > support the 1-setting. > > But if "enable XSAVES/XRSTORS" is clear to 0, XSS_EXIT_BITMAP doesn't > work. I think in this case, there is no need to set this vmcs field? vmx->secondary_exec_control can change; you are making the code more complex by relying on the value of the field at the point of vmx_vcpu_setup. I do _think_ your version is incorrect, because at this point CPUID has not been initialized yet and therefore vmx_compute_secondary_exec_control has not set SECONDARY_EXEC_XSAVES. However I may be wrong because I didn't review the code very closely: the old code is obvious and so there is no point in changing it. Paolo
Re: [PATCH] usb: dwc3: remove unused @lock member of dwc3_ep struct
Hi,
Chunfeng Yun writes:
> The member @lock of dwc2_ep struct is only initialized,
> and not used elsewhere, so remove it.
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/usb/dwc3/core.h | 2 --
> drivers/usb/dwc3/gadget.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index f19cbeb01087..72d28cb14bdf 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -649,7 +649,6 @@ struct dwc3_event_buffer {
> * @cancelled_list: list of cancelled requests for this endpoint
> * @pending_list: list of pending requests for this endpoint
> * @started_list: list of started requests on this endpoint
> - * @lock: spinlock for endpoint request queue traversal
> * @regs: pointer to first endpoint register
> * @trb_pool: array of transaction buffers
> * @trb_pool_dma: dma address of @trb_pool
> @@ -677,7 +676,6 @@ struct dwc3_ep {
> struct list_headpending_list;
> struct list_headstarted_list;
>
> - spinlock_t lock;
> void __iomem*regs;
>
> struct dwc3_trb *trb_pool;
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index d67655384eb2..7f75da30caba 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2251,8 +2251,6 @@ static int dwc3_gadget_init_endpoint(struct dwc3 *dwc,
> u8 epnum)
> dep->endpoint.comp_desc = NULL;
> }
>
> - spin_lock_init(&dep->lock);
heh, thanks. This is left-over from when I playing with further
paralelizing the driver. Turned out that there are not enough gains to
justify that work. I'll apply this patch.
--
balbi
Re: [PATCH v2.5 2/3] firmware: Add support for loading compressed files
On Thu, 20 Jun 2019 10:10:03 +0200,
Greg Kroah-Hartman wrote:
>
> On Thu, Jun 20, 2019 at 09:36:03AM +0200, Takashi Iwai wrote:
> > On Thu, 20 Jun 2019 01:26:47 +0200,
> > Luis Chamberlain wrote:
> > >
> > > Sorry for the late review... Ah!
> >
> > No problem, thanks for review.
> >
> > > On Tue, Jun 11, 2019 at 02:26:25PM +0200, Takashi Iwai wrote:
> > > > @@ -354,7 +454,12 @@ module_param_string(path, fw_path_para,
> > > > sizeof(fw_path_para), 0644);
> > > > MODULE_PARM_DESC(path, "customized firmware image search path with a
> > > > higher priority than default path");
> > > >
> > > > static int
> > > > -fw_get_filesystem_firmware(struct device *device, struct fw_priv
> > > > *fw_priv)
> > > > +fw_get_filesystem_firmware(struct device *device, struct fw_priv
> > > > *fw_priv,
> > > > + const char *suffix,
> > > > + int (*decompress)(struct device *dev,
> > > > +struct fw_priv *fw_priv,
> > > > +size_t in_size,
> > > > +const void *in_buffer))
> > >
> > > I *think* this could be cleaner, I'll elaborate below.
> > >
> > > > @@ -645,7 +768,13 @@ _request_firmware(const struct firmware
> > > > **firmware_p, const char *name,
> > > > if (ret <= 0) /* error or already assigned */
> > > > goto out;
> > > >
> > > > - ret = fw_get_filesystem_firmware(device, fw->priv);
> > > > + ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL);
> > > > +#ifdef CONFIG_FW_LOADER_COMPRESS
> > > > + if (ret == -ENOENT)
> > > > + ret = fw_get_filesystem_firmware(device, fw->priv,
> > > > ".xz",
> > > > +fw_decompress_xz);
> > > > +#endif
> > >
> > > Hrm, and let more #ifdef'ery.
> > >
> > > And so if someone wants to add bzip, we'd add yet-another if else on the
> > > return value of this call... and yet more #ifdefs.
> > >
> > > We already have a list of paths supported. It seems what we need instead
> > > is a list of supported suffixes, and a respective structure which then
> > > has its set of callbacks for posthandling.
> > >
> > > This way, this could all be handled inside fw_get_filesystem_firmware()
> > > neatly, and we can just strive towards avoiding #ifdef'ery.
> >
> > Yes, I had similar idea. Actually my plan for multiple compression
> > formats was:
> >
> > - Move the decompression part into another file, e.g. decompress_xz.c
> > and change in Makefile:
> > firmware_class-$(CONFIG_FW_LOADER_COMPRESS_XZ) += decompress_xz.o
> >
> > - Create a table of the extension and the decompression,
> >
> > static struct fw_decompression_table fw_decompressions[] = {
> > { "", NULL },
> > #ifdef CONFIG_FW_LOADER_COMPRESS_XZ
> > { ".xz", fw_decompress_xz },
> > #endif
> > #ifdef CONFIG_FW_LOADER_COMPRESS_BZIP2
> > { ".bz2", fw_decompress_bzip2 },
> > #endif
> > .
> > };
>
> But why? Why not just stick with one for now, we don't need a zillion
> different formats to start with. Let's just stick with .xz and that's
> it. There is no need to do anything else for the foreseeable future.
Yeah, that's the reason I submitted the patch in the current form;
XZ format should be good enough and it's simpler for a single format,
after all. The suggestion above is only for the case we need to
support multiple formats.
Maybe we may want to support ZSTD in future, as Fedora is moving
toward to that format. Once when the time comes, we can revisit how
the things can be cleaned up.
(And, I heard Ubuntu switching to LZ4, but LZ4 is difficult, as
mentioned in the previous mail...)
thanks,
Takashi
[PATCH] Revert "x86/module: Detect and skip invalid relocations"
This reverts commit eda9cec4c9a12208a6f69fbe68f72a6311d50032.
Since commit (eda9cec4c9a1 'x86/module: Detect and skip invalid
relocations') add some sanity check in apply_relocate_add, borke
re-insmod a kernel module which has been patched before,
The relocation informations of the livepatch module have been
overwritten since first patched, so if we rmmod and insmod the
kernel module, these values are not zero anymore, when
klp_module_coming doing, and that commit marks them as invalid
invalid_relocation.
Then the following error occurs:
module: x86/modules: Skipping invalid relocation target, existing value
is nonzero for type 2, loc (ptrval), val c000236c
livepatch: failed to initialize patch 'livepatch_0001_test' for module
'test' (-8)
livepatch: patch 'livepatch_0001_test' failed for module 'test',
refusing to load module 'test'
To fix this, just revert that commit.
Signed-off-by: Cheng Jian
---
arch/x86/kernel/module.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index d5c72cb..3eb23a8 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -160,28 +160,20 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
case R_X86_64_NONE:
break;
case R_X86_64_64:
- if (*(u64 *)loc != 0)
- goto invalid_relocation;
*(u64 *)loc = val;
break;
case R_X86_64_32:
- if (*(u32 *)loc != 0)
- goto invalid_relocation;
*(u32 *)loc = val;
if (val != *(u32 *)loc)
goto overflow;
break;
case R_X86_64_32S:
- if (*(s32 *)loc != 0)
- goto invalid_relocation;
*(s32 *)loc = val;
if ((s64)val != *(s32 *)loc)
goto overflow;
break;
case R_X86_64_PC32:
case R_X86_64_PLT32:
- if (*(u32 *)loc != 0)
- goto invalid_relocation;
val -= (u64)loc;
*(u32 *)loc = val;
#if 0
@@ -190,8 +182,6 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
#endif
break;
case R_X86_64_PC64:
- if (*(u64 *)loc != 0)
- goto invalid_relocation;
val -= (u64)loc;
*(u64 *)loc = val;
break;
@@ -203,11 +193,6 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
}
return 0;
-invalid_relocation:
- pr_err("x86/modules: Skipping invalid relocation target, existing value
is nonzero for type %d, loc %p, val %Lx\n",
- (int)ELF64_R_TYPE(rel[i].r_info), loc, val);
- return -ENOEXEC;
-
overflow:
pr_err("overflow in relocation type %d val %Lx\n",
(int)ELF64_R_TYPE(rel[i].r_info), val);
--
2.7.4
RE: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
Hi Uffe, > -Original Message- > From: Ulf Hansson > Sent: Wednesday, June 19, 2019 8:11 PM > To: Manish Narani > Cc: Michal Simek ; Rob Herring ; > Mark Rutland ; Adrian Hunter > ; Rajan Vaja ; Jolly Shah > ; Nava kishore Manne ; Olof > Johansson ; linux-...@vger.kernel.org; DTML > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux ARM > Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP > Platform Tap Delays Setup > > On Tue, 18 Jun 2019 at 06:59, Manish Narani wrote: > > > > Hi Uffe, > > > > Thanks for the review. Please find my comments below. > > > > > -Original Message- > > > From: Ulf Hansson > > > Sent: Monday, June 17, 2019 8:29 PM > > > To: Michal Simek > > > Cc: Manish Narani ; Rob Herring > > > ; Mark Rutland ; Adrian > > > Hunter ; Rajan Vaja ; Jolly > > > Shah ; Nava kishore Manne ; > Olof > > > Johansson ; linux-...@vger.kernel.org; DTML > > > ; Linux Kernel Mailing List > > ker...@vger.kernel.org>; Linux ARM ker...@lists.infradead.org> > > > Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP > > > Platform Tap Delays Setup > > > > > > [...] > > > > > > > >> > > > > >> > > > > >>> In regards to the mmc data part, I suggest to drop the > > > > >>> ->set_tap_delay() callback, but rather use a boolean flag to > > > > >>> indicate > > > > >>> whether clock phases needs to be changed for the variant. > > > > >>> Potentially > > > > >>> that could even be skipped and instead call clk_set_phase() > > > > >>> unconditionally, as the clock core deals fine with clock providers > > > > >>> that doesn't support the ->set_phase() callback. > > > > In the current implementation, I am taking care of both the input and > > output clock delays with the single clock (which is output clock) > > registration > > and differentiating these tap delays based on their values > > (<256 then input delay and >= 256 then output delay), because that is > > zynqmp specific. If we want to make this generic, we may need to > > register 'another' clock which will be there as an input (sampling) clock > > and then we can make this 'clk_set_phase()' be called unconditionally > > each for both the clocks and let the platforms handle their clock part. > > What's your take on this? > > Not sure exactly what you are suggesting, but my gut feeling says it > sounds good. > > How is tap delays managed for both the input clock and the output > clock? Is some managed by the clock provider (which is probably > firmware in your case) and some managed by the MMC controller? Yes, for the existing "xlnx,zynqmp-8.9a" controller, the tap delays will be managed by the firmware, however in the upcoming "xlnx,versal-8.9a" variant the tap delays will be managed by the MMC controller itself. I will include the Versal one in the next series of patches. Thanks, Manish
Re: [PATCH] usb: dwc3: remove unused @lock member of dwc3_ep struct
Hi,
On Thu, 2019-06-20 at 11:19 +0300, Felipe Balbi wrote:
> Hi,
>
> Chunfeng Yun writes:
>
> > The member @lock of dwc2_ep struct is only initialized,
> > and not used elsewhere, so remove it.
Sorry, I need send v2 to fix typo of dwc2_ep
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/dwc3/core.h | 2 --
> > drivers/usb/dwc3/gadget.c | 2 --
> > 2 files changed, 4 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> > index f19cbeb01087..72d28cb14bdf 100644
> > --- a/drivers/usb/dwc3/core.h
> > +++ b/drivers/usb/dwc3/core.h
> > @@ -649,7 +649,6 @@ struct dwc3_event_buffer {
> > * @cancelled_list: list of cancelled requests for this endpoint
> > * @pending_list: list of pending requests for this endpoint
> > * @started_list: list of started requests on this endpoint
> > - * @lock: spinlock for endpoint request queue traversal
> > * @regs: pointer to first endpoint register
> > * @trb_pool: array of transaction buffers
> > * @trb_pool_dma: dma address of @trb_pool
> > @@ -677,7 +676,6 @@ struct dwc3_ep {
> > struct list_headpending_list;
> > struct list_headstarted_list;
> >
> > - spinlock_t lock;
> > void __iomem*regs;
> >
> > struct dwc3_trb *trb_pool;
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index d67655384eb2..7f75da30caba 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -2251,8 +2251,6 @@ static int dwc3_gadget_init_endpoint(struct dwc3
> > *dwc, u8 epnum)
> > dep->endpoint.comp_desc = NULL;
> > }
> >
> > - spin_lock_init(&dep->lock);
>
> heh, thanks. This is left-over from when I playing with further
> paralelizing the driver. Turned out that there are not enough gains to
> justify that work. I'll apply this patch.
>
[v2 PATCH] usb: dwc3: remove unused @lock member of dwc3_ep struct
The member @lock of dwc3_ep struct is only initialized,
and not used elsewhere, so remove it.
Signed-off-by: Chunfeng Yun
---
v2: fix typo of dwc3_ep in commit log
---
drivers/usb/dwc3/core.h | 2 --
drivers/usb/dwc3/gadget.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index f19cbeb01087..72d28cb14bdf 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -649,7 +649,6 @@ struct dwc3_event_buffer {
* @cancelled_list: list of cancelled requests for this endpoint
* @pending_list: list of pending requests for this endpoint
* @started_list: list of started requests on this endpoint
- * @lock: spinlock for endpoint request queue traversal
* @regs: pointer to first endpoint register
* @trb_pool: array of transaction buffers
* @trb_pool_dma: dma address of @trb_pool
@@ -677,7 +676,6 @@ struct dwc3_ep {
struct list_headpending_list;
struct list_headstarted_list;
- spinlock_t lock;
void __iomem*regs;
struct dwc3_trb *trb_pool;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d67655384eb2..7f75da30caba 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2251,8 +2251,6 @@ static int dwc3_gadget_init_endpoint(struct dwc3 *dwc, u8
epnum)
dep->endpoint.comp_desc = NULL;
}
- spin_lock_init(&dep->lock);
-
if (num == 0)
ret = dwc3_gadget_init_control_endpoint(dep);
else if (direction)
--
2.21.0
Re: [PATCH] KVM: vmx: Fix the broken usage of vmx_xsaves_supported
On Thu, 20 Jun 2019 at 16:17, Paolo Bonzini wrote: > > On 20/06/19 08:46, Xiaoyao Li wrote: > >> > >> It depends on whether or not processors support the 1-setting instead > >> of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway, > > > > Yes, whether this field exist or not depends on whether processors > > support the 1-setting. > > > > But if "enable XSAVES/XRSTORS" is clear to 0, XSS_EXIT_BITMAP doesn't > > work. I think in this case, there is no need to set this vmcs field? > > vmx->secondary_exec_control can change; you are making the code more > complex by relying on the value of the field at the point of vmx_vcpu_setup. > > I do _think_ your version is incorrect, because at this point CPUID has > not been initialized yet and therefore > vmx_compute_secondary_exec_control has not set SECONDARY_EXEC_XSAVES. > However I may be wrong because I didn't review the code very closely: > the old code is obvious and so there is no point in changing it. Agreed, in addition, guest can enable/disable cpuid bits by grub parameter, should we call kvm_x86_ops->cpuid_update() in kvm_vcpu_reset() path to reflect the new guest cpuid influence to exec_control? e.g. the first boot guest disable xsaves in grub, kvm disables xsaves in exec_control; then guest reboot w/ xsaves enabled, it still get an #UD when executing. Regards, Wanpeng Li
Re: [PATCH 3/5] i2c: at91: add support for digital filtering
On 20/06/2019 07:16:13+, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> Add new platform data support for digital filtering for i2c.
> The sama5d4, sama5d2 and sam9x60 support this feature.
>
> Signed-off-by: Eugen Hristev
> ---
> drivers/i2c/busses/i2c-at91-core.c | 9 +
> drivers/i2c/busses/i2c-at91-master.c | 6 ++
> drivers/i2c/busses/i2c-at91.h| 4
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-at91-core.c
> b/drivers/i2c/busses/i2c-at91-core.c
> index a663a7a..62610af 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
> .has_unre_flag = true,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
As false is the default value, may we should avoid setting it
explicitly to keep the file size manageable.
> };
>
> static struct at91_twi_pdata at91sam9261_config = {
> @@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
> };
>
> static struct at91_twi_pdata at91sam9260_config = {
> @@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
> };
>
> static struct at91_twi_pdata at91sam9g20_config = {
> @@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
> };
>
> static struct at91_twi_pdata at91sam9g10_config = {
> @@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
> };
>
> static const struct platform_device_id at91_twi_devtypes[] = {
> @@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
> };
>
> static struct at91_twi_pdata sama5d4_config = {
> @@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
> .has_unre_flag = false,
> .has_alt_cmd = false,
> .has_hold_field = true,
> + .has_dig_filtr = true,
> };
>
> static struct at91_twi_pdata sama5d2_config = {
> @@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
> .has_unre_flag = true,
> .has_alt_cmd = true,
> .has_hold_field = true,
> + .has_dig_filtr = true,
> };
>
> static struct at91_twi_pdata sam9x60_config = {
> @@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
> .has_unre_flag = true,
> .has_alt_cmd = true,
> .has_hold_field = true,
> + .has_dig_filtr = true,
> };
>
> static const struct of_device_id atmel_twi_dt_ids[] = {
> diff --git a/drivers/i2c/busses/i2c-at91-master.c
> b/drivers/i2c/busses/i2c-at91-master.c
> index e87232f..366e90f 100644
> --- a/drivers/i2c/busses/i2c-at91-master.c
> +++ b/drivers/i2c/busses/i2c-at91-master.c
> @@ -31,12 +31,18 @@
>
> void at91_init_twi_bus_master(struct at91_twi_dev *dev)
> {
> + struct at91_twi_pdata *pdata = dev->pdata;
> +
> /* FIFO should be enabled immediately after the software reset */
> if (dev->fifo_size)
> at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
> at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
> at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
> at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
> +
> + /* enable digital filter */
> + if (pdata->has_dig_filtr)
> + at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
You are enabling all those filtering features by default which mean that
if we ever need to handle them using DT, the property will be a
disabling one instead of a more logical enabling one.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 3/5] media: venus: Update clock scaling
Hi Stan,
On 2019-06-17 14:28, Stanimir Varbanov wrote:
Hi Aniket,
On 6/11/19 9:05 AM, Aniket Masule wrote:
Current clock scaling calculations are same for vpu4 and
previous versions. For vpu4, Clock scaling calculations
are updated with cycles/mb. This helps in getting precise
clock required.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c | 88
+++--
1 file changed, 84 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index f7f724b..7bcc1e6 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -348,8 +348,9 @@ static u32 load_per_type(struct venus_core *core,
u32 session_type)
return mbs_per_sec;
}
-static int load_scale_clocks(struct venus_core *core)
+static int scale_clocks(struct venus_inst *inst)
{
+ struct venus_core *core = inst->core;
const struct freq_tbl *table = core->res->freq_tbl;
unsigned int num_rows = core->res->freq_tbl_size;
unsigned long freq = table[0].freq;
@@ -398,6 +399,86 @@ static int load_scale_clocks(struct venus_core
*core)
return ret;
}
+static unsigned long calculate_inst_freq(struct venus_inst *inst)
+{
+ unsigned long vpp_cycles = 0;
+ u32 mbs_per_sec;
+
+ mbs_per_sec = load_per_instance(inst);
+ vpp_cycles = mbs_per_sec * inst->clk_data.codec_data->vpp_cycles;
+ /* 21 / 20 is overhead factor */
+ vpp_cycles += vpp_cycles / 20;
shouldn't you multiply by 21?
Expansion of given expression results to the same.
+
+ return vpp_cycles;
It is not clear to me is that vpp_cycles or frequency (rate)? I just
lost in dimensions used here.
If you return vpp_cycles could you rename the function name?
Initial calculations included frequency (for bitrate based scaling),
which I removed.
I will rename it calculate_inst_vpp_cycles for this patch.
+}
+
+static int scale_clocks_vpu4(struct venus_inst *inst)
does vpu4 equivalent to HFI_VERSION_4XX? If so could you rename
function
to scale_clocks_v4.
Sure Stan, I will rename it to scale_clocks_v4.
+{
+ struct venus_core *core = inst->core;
+ const struct freq_tbl *table = core->res->freq_tbl;
+ unsigned int num_rows = core->res->freq_tbl_size;
+
+ struct clk *clk = core->clks[0];
+ struct device *dev = core->dev;
+ unsigned int i;
+ unsigned long freq = 0, freq_core0 = 0, freq_core1 = 0;
+ int ret;
+
+ freq = calculate_inst_freq(inst);
+
+ if (freq > table[0].freq)
+ goto err;
+
+ for (i = 0; i < num_rows; i++) {
+ if (freq > table[i].freq)
+ break;
+ freq = table[i].freq;
+ }
+
+ inst->clk_data.freq = freq;
+
+ mutex_lock(&core->lock);
+ list_for_each_entry(inst, &core->instances, list) {
+ if (inst->clk_data.core_id == VIDC_CORE_ID_1) {
+ freq_core0 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_2) {
+ freq_core1 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_3) {
+ freq_core0 += inst->clk_data.freq;
+ freq_core1 += inst->clk_data.freq;
+ }
+ }
+ mutex_unlock(&core->lock);
+
+ freq = max(freq_core0, freq_core1);
hmm, this doesn't look right. core0 and core1 frequencies can be
different why you get the bigger and set it on both?
We can't set separate clocks to core0 and core1.
As per the design, we can set clocks to the branch only not the
individual cores.
+
+ ret = clk_set_rate(clk, freq);
+ if (ret)
+ goto err;
+
+ ret = clk_set_rate(core->core0_clk, freq);
IMO this should set freq_core0
We need set max required frequency, due to the reason mentioned above.
+ if (ret)
+ goto err;
+
+ ret = clk_set_rate(core->core1_clk, freq);
set freq_core1
We need set max required frequency, due to the reason mentioned above.
+ if (ret)
+ goto err;
+
+ return 0;
+
+err:
+ dev_err(dev, "failed to set clock rate %lu (%d)\n", freq, ret);
+ return ret;
+}
+
+static int load_scale_clocks(struct venus_inst *inst)
+{
+ if (IS_V3(inst->core) || IS_V1(inst->core))
+ return scale_clocks(inst);
+ else
+ return scale_clocks_vpu4(inst);
could you reorder this to:
if (IS_V4())
return scale_clocks_v4(inst);
return scale_clocks(inst);
Yes Stan.
+}
+
static void fill_buffer_desc(const struct venus_buffer *buf,
struct hfi_buffer_desc *bd, bool response)
{
@@ -1053,7 +1134,7 @@ void venus_helper_vb2_stop_streaming(struct
vb2_queue *q)
venus_helper_free_dpb_
Re: [PATCH] soc: aspeed: fix probe error handling
On Wed, 19 Jun 2019 at 12:56, Arnd Bergmann wrote:
>
> gcc warns that a mising "flash" phandle node leads to undefined
> behavior later:
>
> drivers/soc/aspeed/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
> drivers/soc/aspeed/aspeed-lpc-ctrl.c:201:18: error: '*((void *)&resm+8)' may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The device cannot work without this node, so just error out here.
>
> Signed-off-by: Arnd Bergmann
Thanks Arnd. This looks like it applies on top of Vijay's recent patch?
The intent of that change was to make the driver usable for systems
that do not want to depend on the flash phandle. I think the fix we
want looks like this:
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -224,10 +224,11 @@ static int aspeed_lpc_ctrl_probe(struct
platform_device *pdev)
dev_err(dev, "Couldn't address to resource for
flash\n");
return rc;
}
+
+ lpc_ctrl->pnor_size = resource_size(&resm);
+ lpc_ctrl->pnor_base = resm.start;
}
- lpc_ctrl->pnor_size = resource_size(&resm);
- lpc_ctrl->pnor_base = resm.start;
Vijay, do you agree?
Cheers,
Joel
> ---
> drivers/soc/aspeed/aspeed-lpc-ctrl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> index 239520bb207e..81109d22af6a 100644
> --- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> +++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> @@ -212,6 +212,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
> *pdev)
> node = of_parse_phandle(dev->of_node, "flash", 0);
> if (!node) {
> dev_dbg(dev, "Didn't find host pnor flash node\n");
> + return -ENXIO;
> } else {
> rc = of_address_to_resource(node, 1, &resm);
> of_node_put(node);
> --
> 2.20.0
>
Re: [PATCH] Revert "x86/module: Detect and skip invalid relocations"
On Thu, 20 Jun 2019, Cheng Jian wrote: > This reverts commit eda9cec4c9a12208a6f69fbe68f72a6311d50032. > > Since commit (eda9cec4c9a1 'x86/module: Detect and skip invalid > relocations') add some sanity check in apply_relocate_add, borke > re-insmod a kernel module which has been patched before, > > The relocation informations of the livepatch module have been > overwritten since first patched, so if we rmmod and insmod the > kernel module, these values are not zero anymore, when > klp_module_coming doing, and that commit marks them as invalid > invalid_relocation. > > Then the following error occurs: > > module: x86/modules: Skipping invalid relocation target, existing value > is nonzero for type 2, loc (ptrval), val c000236c > livepatch: failed to initialize patch 'livepatch_0001_test' for module > 'test' (-8) > livepatch: patch 'livepatch_0001_test' failed for module 'test', > refusing to load module 'test' Oh yeah. First reported here 20180602161151.apuhs2dygsexmcg2@treble (LP ML only and there is no archive on lore.kernel.org yet. Sorry about that.). I posted v1 here https://lore.kernel.org/lkml/20180607092949.1706-1-mbe...@suse.cz/ and even started to work on v2 in March with arch-specific nullifying, but then I got sidetracked again. I'll move it up my todo list a bit. Miroslav
Re: [PATCH v2 1/1] watchdog: atmel: atmel-sama5d4-wdt: Disable watchdog on system suspend
On 14/06/2019 12:53:22+, Ken Sloat wrote:
> From: Ken Sloat
>
> Currently, the atmel-sama5d4-wdt continues to run after system suspend.
> Unless the system resumes within the watchdog timeout period so the
> userspace can kick it, the system will be reset. This change disables
> the watchdog on suspend if it is active and re-enables on resume. These
> actions occur during the late and early phases of suspend and resume
> respectively to minimize chances where a lock could occur while the
> watchdog is disabled.
>
> Signed-off-by: Ken Sloat
Acked-by: Alexandre Belloni
> ---
> Changes in v2:
> -Consolidate resume and resume early statements.
>
> drivers/watchdog/sama5d4_wdt.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
> index 111695223aae..0d123f8cbcc6 100644
> --- a/drivers/watchdog/sama5d4_wdt.c
> +++ b/drivers/watchdog/sama5d4_wdt.c
> @@ -280,7 +280,17 @@ static const struct of_device_id sama5d4_wdt_of_match[]
> = {
> MODULE_DEVICE_TABLE(of, sama5d4_wdt_of_match);
>
> #ifdef CONFIG_PM_SLEEP
> -static int sama5d4_wdt_resume(struct device *dev)
> +static int sama5d4_wdt_suspend_late(struct device *dev)
> +{
> + struct sama5d4_wdt *wdt = dev_get_drvdata(dev);
> +
> + if (watchdog_active(&wdt->wdd))
> + sama5d4_wdt_stop(&wdt->wdd);
> +
> + return 0;
> +}
> +
> +static int sama5d4_wdt_resume_early(struct device *dev)
> {
> struct sama5d4_wdt *wdt = dev_get_drvdata(dev);
>
> @@ -291,12 +301,17 @@ static int sama5d4_wdt_resume(struct device *dev)
>*/
> sama5d4_wdt_init(wdt);
>
> + if (watchdog_active(&wdt->wdd))
> + sama5d4_wdt_start(&wdt->wdd);
> +
> return 0;
> }
> #endif
>
> -static SIMPLE_DEV_PM_OPS(sama5d4_wdt_pm_ops, NULL,
> - sama5d4_wdt_resume);
> +static const struct dev_pm_ops sama5d4_wdt_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(sama5d4_wdt_suspend_late,
> + sama5d4_wdt_resume_early)
> +};
>
> static struct platform_driver sama5d4_wdt_driver = {
> .probe = sama5d4_wdt_probe,
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v6 1/2] arm64: tegra: add ACONNECT, ADMA and AGIC nodes
On 19/06/2019 12:51, Sameer Pujar wrote:
> Add DT nodes for following devices on Tegra186 and Tegra194
> * ACONNECT
> * ADMA
> * AGIC
>
> Signed-off-by: Sameer Pujar
> ---
> changes in current revision
>* updated ranges property for aconnect
>* renamed agic node
>
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 67
>
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 67
>
> 2 files changed, 134 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 426ac0b..4bb765d 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -1295,4 +1295,71 @@
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> interrupt-parent = <&gic>;
> };
> +
> + aconnect {
> + compatible = "nvidia,tegra210-aconnect";
> + clocks = <&bpmp TEGRA186_CLK_APE>,
> + <&bpmp TEGRA186_CLK_APB2APE>;
> + clock-names = "ape", "apb2ape";
> + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_AUD>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0290 0x0 0x0290 0x20>;
> + status = "disabled";
> +
> + dma-controller@293 {
> + compatible = "nvidia,tegra186-adma";
> + reg = <0x0293 0x2>;
> + interrupt-parent = <&agic>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + #dma-cells = <1>;
> + clocks = <&bpmp TEGRA186_CLK_AHUB>;
> + clock-names = "d_audio";
> + status = "disabled";
> + };
> +
> + agic: interrupt-controller@2a4 {
> + compatible = "nvidia,tegra210-agic";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x02a41000 0x1000>,
> + <0x02a42000 0x2000>;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + clocks = <&bpmp TEGRA186_CLK_APE>;
> + clock-names = "clk";
> + status = "disabled";
> + };
> + };
> };
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index c77ca21..d6aee0d 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -1054,4 +1054,71 @@
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> interrupt-parent = <&gic>;
> };
> +
> + aconnect {
> + compatible = "nvidia,tegra210-aconnect";
> + clocks = <&bpmp TEGRA194_CLK_APE>,
> + <&bpmp TEGRA194_CLK_APB2APE>;
> + clock-names = "ape", "apb2ape";
> + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_AUD>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0290 0x0 0x0290 0x20>;
> + status = "disabled";
> +
> + dma-controller@293 {
> + compatible = "nvidia,tegra186-adma";
> + reg = <0x0293 0x2>;
> + interrupt-parent = <&agic>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> +
Re: [PATCH] KVM: vmx: Fix the broken usage of vmx_xsaves_supported
On 20/06/19 10:27, Wanpeng Li wrote: > Agreed, in addition, guest can enable/disable cpuid bits by grub > parameter Through what path? Guest can disable X86_FEATURE_* but that's purely a Linux feature, the few CPUID bits that can change at runtime already call kvm_x86_ops->cpuid_update(). Paolo > , should we call kvm_x86_ops->cpuid_update() in > kvm_vcpu_reset() path to reflect the new guest cpuid influence to > exec_control? e.g. the first boot guest disable xsaves in grub, kvm > disables xsaves in exec_control; then guest reboot w/ xsaves enabled, > it still get an #UD when executing.
Re: [PATCH v6 2/2] arm64: tegra: enable ACONNECT, ADMA and AGIC
On 19/06/2019 12:51, Sameer Pujar wrote:
> Enable ACONNECT, ADMA and AGIC devices for following platforms
> * Jetson TX2
> * Jetson Xavier
>
> Verified driver probe path and devices get registered fine.
>
> Signed-off-by: Sameer Pujar
> ---
> changes in current revision
>* renamed agic, interrupt-controller, name
>
> arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 12
> arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 12
> 2 files changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
> b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
> index 5102de1..55c84bb 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
> @@ -298,4 +298,16 @@
> vin-supply = <&vdd_5v0_sys>;
> };
> };
> +
> + aconnect {
> + status = "okay";
> +
> + dma-controller@293 {
> + status = "okay";
> + };
> +
> + interrupt-controller@2a4 {
> + status = "okay";
> + };
> + };
> };
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> index 6e6df65..5981cdc 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> @@ -167,4 +167,16 @@
> };
> };
> };
> +
> + aconnect {
> + status = "okay";
> +
> + dma-controller@293 {
> + status = "okay";
> + };
> +
> + interrupt-controller@2a4 {
> + status = "okay";
> + };
> + };
> };
>
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
Re: [PATCH v2] dmaengine: tegra-apb: Support per-burst residue granularity
On 18/06/2019 12:50, Dmitry Osipenko wrote:
> Tegra's APB DMA engine updates words counter after each transferred burst
> of data, hence it can report transfer's residual with more fidelity which
> may be required in cases like audio playback. In particular this fixes
> audio stuttering during playback in a chromiuim web browser. The patch is
> based on the original work that was made by Ben Dooks. It was tested on
> Tegra20 and Tegra30 devices.
>
> Link:
> https://lore.kernel.org/lkml/20190424162348.23692-1-ben.do...@codethink.co.uk/
> Inspired-by: Ben Dooks
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v2: Addressed review comments made by Jon Hunter to v1. We won't try
> to get words count if dma_desc is on free list as it will result
> in a NULL dereference because this case wasn't handled properly.
>
> The residual value is now updated properly, avoiding potential
> integer overflow by adding the "bytes" to the "bytes_transferred"
> instead of the subtraction.
>
> drivers/dma/tegra20-apb-dma.c | 33 ++---
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index 79e9593815f1..fed18bc46479 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -797,6 +797,28 @@ static int tegra_dma_terminate_all(struct dma_chan *dc)
> return 0;
> }
>
> +static unsigned int tegra_dma_sg_bytes_xferred(struct tegra_dma_channel *tdc,
> +struct tegra_dma_sg_req *sg_req)
> +{
> + unsigned long status, wcount = 0;
> +
> + if (!list_is_first(&sg_req->node, &tdc->pending_sg_req))
> + return 0;
> +
> + if (tdc->tdma->chip_data->support_separate_wcount_reg)
> + wcount = tdc_read(tdc, TEGRA_APBDMA_CHAN_WORD_TRANSFER);
> +
> + status = tdc_read(tdc, TEGRA_APBDMA_CHAN_STATUS);
> +
> + if (!tdc->tdma->chip_data->support_separate_wcount_reg)
> + wcount = status;
> +
> + if (status & TEGRA_APBDMA_STATUS_ISE_EOC)
> + return sg_req->req_len;
> +
> + return get_current_xferred_count(tdc, sg_req, wcount);
> +}
> +
> static enum dma_status tegra_dma_tx_status(struct dma_chan *dc,
> dma_cookie_t cookie, struct dma_tx_state *txstate)
> {
> @@ -806,6 +828,7 @@ static enum dma_status tegra_dma_tx_status(struct
> dma_chan *dc,
> enum dma_status ret;
> unsigned long flags;
> unsigned int residual;
> + unsigned int bytes = 0;
>
> ret = dma_cookie_status(dc, cookie, txstate);
> if (ret == DMA_COMPLETE)
> @@ -825,6 +848,7 @@ static enum dma_status tegra_dma_tx_status(struct
> dma_chan *dc,
> list_for_each_entry(sg_req, &tdc->pending_sg_req, node) {
> dma_desc = sg_req->dma_desc;
> if (dma_desc->txd.cookie == cookie) {
> + bytes = tegra_dma_sg_bytes_xferred(tdc, sg_req);
> ret = dma_desc->dma_status;
> goto found;
> }
> @@ -836,7 +860,7 @@ static enum dma_status tegra_dma_tx_status(struct
> dma_chan *dc,
> found:
> if (dma_desc && txstate) {
> residual = dma_desc->bytes_requested -
> -(dma_desc->bytes_transferred %
> +((dma_desc->bytes_transferred + bytes) %
> dma_desc->bytes_requested);
> dma_set_residue(txstate, residual);
> }
> @@ -1441,12 +1465,7 @@ static int tegra_dma_probe(struct platform_device
> *pdev)
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> tdma->dma_dev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
> - /*
> - * XXX The hardware appears to support
> - * DMA_RESIDUE_GRANULARITY_BURST-level reporting, but it's
> - * only used by this driver during tegra_dma_terminate_all()
> - */
> - tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
> + tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> tdma->dma_dev.device_config = tegra_dma_slave_config;
> tdma->dma_dev.device_terminate_all = tegra_dma_terminate_all;
> tdma->dma_dev.device_tx_status = tegra_dma_tx_status;
>
Looks good to me. Thanks for fixing!
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
Re: [PATCH v2 4/5] mm: introduce MADV_PAGEOUT
On Thu, Jun 20, 2019 at 09:04:44AM +0200, Michal Hocko wrote:
> On Thu 20-06-19 13:16:20, Minchan Kim wrote:
> > On Wed, Jun 19, 2019 at 03:24:50PM +0200, Michal Hocko wrote:
> > > On Mon 10-06-19 20:12:51, Minchan Kim wrote:
> > > [...]
> > > > +static int madvise_pageout_pte_range(pmd_t *pmd, unsigned long addr,
> > > > + unsigned long end, struct mm_walk *walk)
> > >
> > > Again the same question about a potential code reuse...
> > > [...]
> > > > +regular_page:
> > > > + tlb_change_page_size(tlb, PAGE_SIZE);
> > > > + orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr,
> > > > &ptl);
> > > > + flush_tlb_batched_pending(mm);
> > > > + arch_enter_lazy_mmu_mode();
> > > > + for (; addr < end; pte++, addr += PAGE_SIZE) {
> > > > + ptent = *pte;
> > > > + if (!pte_present(ptent))
> > > > + continue;
> > > > +
> > > > + page = vm_normal_page(vma, addr, ptent);
> > > > + if (!page)
> > > > + continue;
> > > > +
> > > > + if (isolate_lru_page(page))
> > > > + continue;
> > > > +
> > > > + isolated++;
> > > > + if (pte_young(ptent)) {
> > > > + ptent = ptep_get_and_clear_full(mm, addr, pte,
> > > > + tlb->fullmm);
> > > > + ptent = pte_mkold(ptent);
> > > > + set_pte_at(mm, addr, pte, ptent);
> > > > + tlb_remove_tlb_entry(tlb, pte, addr);
> > > > + }
> > > > + ClearPageReferenced(page);
> > > > + test_and_clear_page_young(page);
> > > > + list_add(&page->lru, &page_list);
> > > > + if (isolated >= SWAP_CLUSTER_MAX) {
> > >
> > > Why do we need SWAP_CLUSTER_MAX batching? Especially when we need ...
> > > [...]
> >
> > It aims for preventing early OOM kill since we isolate too many LRU
> > pages concurrently.
>
> This is a good point. For some reason I thought that we consider
> isolated pages in should_reclaim_retry but we do not anymore (since we
> move from zone to node LRUs I guess). Please stick a comment there.
Sure.
>
> > > > +unsigned long reclaim_pages(struct list_head *page_list)
> > > > +{
> > > > + int nid = -1;
> > > > + unsigned long nr_reclaimed = 0;
> > > > + LIST_HEAD(node_page_list);
> > > > + struct reclaim_stat dummy_stat;
> > > > + struct scan_control sc = {
> > > > + .gfp_mask = GFP_KERNEL,
> > > > + .priority = DEF_PRIORITY,
> > > > + .may_writepage = 1,
> > > > + .may_unmap = 1,
> > > > + .may_swap = 1,
> > > > + };
> > > > +
> > > > + while (!list_empty(page_list)) {
> > > > + struct page *page;
> > > > +
> > > > + page = lru_to_page(page_list);
> > > > + if (nid == -1) {
> > > > + nid = page_to_nid(page);
> > > > + INIT_LIST_HEAD(&node_page_list);
> > > > + }
> > > > +
> > > > + if (nid == page_to_nid(page)) {
> > > > + list_move(&page->lru, &node_page_list);
> > > > + continue;
> > > > + }
> > > > +
> > > > + nr_reclaimed += shrink_page_list(&node_page_list,
> > > > + NODE_DATA(nid),
> > > > + &sc, 0,
> > > > + &dummy_stat, false);
> > >
> > > per-node batching in fact. Other than that nothing really jumped at me.
> > > Except for the shared page cache side channel timing aspect not being
> > > considered AFAICS. To be more specific. Pushing out a shared page cache
> > > is possible even now but this interface gives a much easier tool to
> > > evict shared state and perform all sorts of timing attacks. Unless I am
> > > missing something we should be doing something similar to mincore and
> > > ignore shared pages without a writeable access or at least document why
> > > we do not care.
> >
> > I'm not sure IIUC side channel attach. As you mentioned, without this
> > syscall,
> > 1. they already can do that simply by memory hogging
>
> This is way much more harder for practical attacks because the reclaim
> logic is not fully under the attackers control. Having a direct tool to
> reclaim memory directly then just opens doors to measure the other
> consumers of that memory and all sorts of side channel.
Not sure it's much more harder. It's really easy on my experience.
Just creating new memory hogger and consume memory step by step until
you newly allocated pages will be reclaimed.
Anyway, we fixed mincore so attacker cannot see when the page fault-in
if he don't enough permission for the file. Right?
What's th
Re: [PATCH v2 1/5] mm: introduce MADV_COLD
On Thu, Jun 20, 2019 at 09:08:54AM +0200, Michal Hocko wrote: > On Thu 20-06-19 09:06:51, Minchan Kim wrote: > > On Wed, Jun 19, 2019 at 02:56:12PM +0200, Michal Hocko wrote: > [...] > > > Why cannot we reuse a large part of that code and differ essentially on > > > the reclaim target check and action? Have you considered to consolidate > > > the code to share as much as possible? Maybe that is easier said than > > > done because the devil is always in details... > > > > Yub, it was not pretty when I tried. Please see last patch in this > > patchset. > > That is bad because this code is quite subtle - especially the THP part > of it. I will be staring at the code some more. Maybe some > simplification pops out. Yeah, I couldn't come up with better idea. Actually, I wanted to be left. More suggestion to make simple/readable would be great.
Re: [PATCH] media: Clarify the meaning of file descriptors in VIDIOC_DQBUF
On Wed, Jun 12, 2019 at 06:36:48PM +0900, Tomasz Figa wrote: > When the application calls VIDIOC_DQBUF with the DMABUF memory type, the > v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf > file descriptors. However, the current documentation does not explain > whether those are new file descriptors referring to the same DMA-bufs or > just the same integers as passed to VIDIOC_QBUF back in time. Clarify > the documentation that it's the latter. > > Signed-off-by: Tomasz Figa Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH 1/3] slimbus: fix kerneldoc comments
On Thu, Jun 20, 2019 at 09:11:27AM +0100, Srinivas Kandagatla wrote: > From: Jonathan Corbet > > The kerneldoc comments in drivers/slimbus/stream.c were not properly > formatted, leading to a distinctly unsatisfying "no structured comments > found" warning in the docs build. Sprinkle some asterisks around so that > the comments will be properly recognized. > > Signed-off-by: Jonathan Corbet > Signed-off-by: Srinivas Kandagatla > --- > drivers/slimbus/stream.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Turns out this was already in my tree :) Also, when sending out patches, be sure to cc: the authors, no need to suppress that in git send-email. thanks, greg k-h
Re: [PATCH 1/3] slimbus: fix kerneldoc comments
On 20/06/2019 09:46, Greg KH wrote: On Thu, Jun 20, 2019 at 09:11:27AM +0100, Srinivas Kandagatla wrote: From: Jonathan Corbet The kerneldoc comments in drivers/slimbus/stream.c were not properly formatted, leading to a distinctly unsatisfying "no structured comments found" warning in the docs build. Sprinkle some asterisks around so that the comments will be properly recognized. Signed-off-by: Jonathan Corbet Signed-off-by: Srinivas Kandagatla --- drivers/slimbus/stream.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Turns out this was already in my tree :) Ah, I should have rebased it on top of char-misc! Also, when sending out patches, be sure to cc: the authors, no need to suppress that in git send-email. Sure, I will keep that in mind! thanks, srini thanks, greg k-h
[PATCH v5 3/3] KVM: vmx: handle vm-exit for UMWAIT and TPAUSE
As the latest Intel 64 and IA-32 Architectures Software Developer's
Manual, UMWAIT and TPAUSE instructions cause a VM exit if the
RDTSC exiting and enable user wait and pause VM-execution
controls are both 1.
This patch is to handle the vm-exit for UMWAIT and TPAUSE as this
should never happen.
Co-developed-by: Jingqi Liu
Signed-off-by: Jingqi Liu
Signed-off-by: Tao Xu
---
No changes in v5.
---
arch/x86/include/uapi/asm/vmx.h | 6 +-
arch/x86/kvm/vmx/vmx.c | 16
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index d213ec5c3766..d88d7a68849b 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -85,6 +85,8 @@
#define EXIT_REASON_PML_FULL62
#define EXIT_REASON_XSAVES 63
#define EXIT_REASON_XRSTORS 64
+#define EXIT_REASON_UMWAIT 67
+#define EXIT_REASON_TPAUSE 68
#define VMX_EXIT_REASONS \
{ EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
@@ -142,7 +144,9 @@
{ EXIT_REASON_RDSEED,"RDSEED" }, \
{ EXIT_REASON_PML_FULL, "PML_FULL" }, \
{ EXIT_REASON_XSAVES,"XSAVES" }, \
- { EXIT_REASON_XRSTORS, "XRSTORS" }
+ { EXIT_REASON_XRSTORS, "XRSTORS" }, \
+ { EXIT_REASON_UMWAIT,"UMWAIT" }, \
+ { EXIT_REASON_TPAUSE,"TPAUSE" }
#define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
#define VMX_ABORT_LOAD_HOST_PDPTE_FAIL 2
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 0fb55c8426e2..d9d4977195ef 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5342,6 +5342,20 @@ static int handle_monitor(struct kvm_vcpu *vcpu)
return handle_nop(vcpu);
}
+static int handle_umwait(struct kvm_vcpu *vcpu)
+{
+ kvm_skip_emulated_instruction(vcpu);
+ WARN(1, "this should never happen\n");
+ return 1;
+}
+
+static int handle_tpause(struct kvm_vcpu *vcpu)
+{
+ kvm_skip_emulated_instruction(vcpu);
+ WARN(1, "this should never happen\n");
+ return 1;
+}
+
static int handle_invpcid(struct kvm_vcpu *vcpu)
{
u32 vmx_instruction_info;
@@ -5552,6 +5566,8 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu
*vcpu) = {
[EXIT_REASON_VMFUNC] = handle_vmx_instruction,
[EXIT_REASON_PREEMPTION_TIMER]= handle_preemption_timer,
[EXIT_REASON_ENCLS] = handle_encls,
+ [EXIT_REASON_UMWAIT] = handle_umwait,
+ [EXIT_REASON_TPAUSE] = handle_tpause,
};
static const int kvm_vmx_max_exit_handlers =
--
2.20.1
[PATCH v5 0/3] KVM: x86: Enable user wait instructions
UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions. UMONITOR arms address monitoring hardware using an address. A store to an address within the specified address range triggers the monitoring hardware to wake up the processor waiting in umwait. UMWAIT instructs the processor to enter an implementation-dependent optimized state while monitoring a range of addresses. The optimized state may be either a light-weight power/performance optimized state (c0.1 state) or an improved power/performance optimized state (c0.2 state). TPAUSE instructs the processor to enter an implementation-dependent optimized state c0.1 or c0.2 state and wake up when time-stamp counter reaches specified timeout. Availability of the user wait instructions is indicated by the presence of the CPUID feature flag WAITPKG CPUID.0x07.0x0:ECX[5]. The patches enable the umonitor, umwait and tpause features in KVM. Because umwait and tpause can put a (psysical) CPU into a power saving state, by default we dont't expose it to kvm and enable it only when guest CPUID has it. If the instruction causes a delay, the amount of time delayed is called here the physical delay. The physical delay is first computed by determining the virtual delay (the time to delay relative to the VM’s timestamp counter). The release document ref below link: Intel 64 and IA-32 Architectures Software Developer's Manual, https://software.intel.com/sites/default/files/\ managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf This patch has a dependency on https://lkml.org/lkml/2019/6/19/972 Changelog: v5: remove vmx_waitpkg_supported() to fix guest can rdmsr or wrmsr when the feature is off (Xiaoyao) rebase the patch because the kernel dependcy patch updated to v5: https://lkml.org/lkml/2019/6/19/972 v4: Set msr of IA32_UMWAIT_CONTROL can be 0 and add the check of reserved bit 1 (Radim and Xiaoyao) Use umwait_control_cached directly and add the IA32_UMWAIT_CONTROL in msrs_to_save[] to support migration (Xiaoyao) v3: Simplify the patches, expose user wait instructions when the guest has CPUID (Paolo) Use mwait_control_cached to avoid frequently rdmsr of IA32_UMWAIT_CONTROL (Paolo and Xiaoyao) Handle vm-exit for UMWAIT and TPAUSE as "never happen" (Paolo) v2: Separated from the series https://lkml.org/lkml/2018/7/10/160 Add provide a capability to enable UMONITOR, UMWAIT and TPAUSE v1: Sent out with MOVDIRI/MOVDIR64B instructions patches Tao Xu (3): KVM: x86: add support for user wait instructions KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL KVM: vmx: handle vm-exit for UMWAIT and TPAUSE arch/x86/include/asm/vmx.h | 1 + arch/x86/include/uapi/asm/vmx.h | 6 - arch/x86/kernel/cpu/umwait.c| 3 ++- arch/x86/kvm/cpuid.c| 2 +- arch/x86/kvm/vmx/vmx.c | 44 + arch/x86/kvm/vmx/vmx.h | 3 +++ arch/x86/kvm/x86.c | 1 + 7 files changed, 57 insertions(+), 3 deletions(-) -- 2.20.1
[PATCH v5 1/3] KVM: x86: add support for user wait instructions
UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions. This patch adds support for user wait instructions in KVM. Availability of the user wait instructions is indicated by the presence of the CPUID feature flag WAITPKG CPUID.0x07.0x0:ECX[5]. User wait instructions may be executed at any privilege level, and use IA32_UMWAIT_CONTROL MSR to set the maximum time. The behavior of user wait instructions in VMX non-root operation is determined first by the setting of the "enable user wait and pause" secondary processor-based VM-execution control bit 26. If the VM-execution control is 0, UMONITOR/UMWAIT/TPAUSE cause an invalid-opcode exception (#UD). If the VM-execution control is 1, treatment is based on the setting of the “RDTSC exiting” VM-execution control. Because KVM never enables RDTSC exiting, if the instruction causes a delay, the amount of time delayed is called here the physical delay. The physical delay is first computed by determining the virtual delay. If IA32_UMWAIT_CONTROL[31:2] is zero, the virtual delay is the value in EDX:EAX minus the value that RDTSC would return; if IA32_UMWAIT_CONTROL[31:2] is not zero, the virtual delay is the minimum of that difference and AND(IA32_UMWAIT_CONTROL,FFFCH). Because umwait and tpause can put a (psysical) CPU into a power saving state, by default we dont't expose it to kvm and enable it only when guest CPUID has it. Detailed information about user wait instructions can be found in the latest Intel 64 and IA-32 Architectures Software Developer's Manual. Co-developed-by: Jingqi Liu Signed-off-by: Jingqi Liu Signed-off-by: Tao Xu --- Changes in v5: remove vmx_waitpkg_supported() and use guest_cpuid_has(vcpu, X86_FEATURE_WAITPKG) directly (Xiaoyao) --- arch/x86/include/asm/vmx.h | 1 + arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/vmx/vmx.c | 4 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index a39136b0d509..8f00882664d3 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -69,6 +69,7 @@ #define SECONDARY_EXEC_PT_USE_GPA 0x0100 #define SECONDARY_EXEC_MODE_BASED_EPT_EXEC 0x0040 #define SECONDARY_EXEC_TSC_SCALING 0x0200 +#define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE 0x0400 #define PIN_BASED_EXT_INTR_MASK 0x0001 #define PIN_BASED_NMI_EXITING 0x0008 diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index e18a9f9f65b5..48bd851a6ae5 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -405,7 +405,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | - F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B); + F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/; /* cpuid 7.0.edx*/ const u32 kvm_cpuid_7_0_edx_x86_features = diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index b93e36ddee5e..b35bfac30a34 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -2250,6 +2250,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf, SECONDARY_EXEC_RDRAND_EXITING | SECONDARY_EXEC_ENABLE_PML | SECONDARY_EXEC_TSC_SCALING | + SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE | SECONDARY_EXEC_PT_USE_GPA | SECONDARY_EXEC_PT_CONCEAL_VMX | SECONDARY_EXEC_ENABLE_VMFUNC | @@ -3987,6 +3988,9 @@ static void vmx_compute_secondary_exec_control(struct vcpu_vmx *vmx) } } + if (!guest_cpuid_has(vcpu, X86_FEATURE_WAITPKG)) + exec_control &= ~SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE; + vmx->secondary_exec_control = exec_control; } -- 2.20.1
[PATCH v5 2/3] KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL
UMWAIT and TPAUSE instructions use IA32_UMWAIT_CONTROL at MSR index E1H
to determines the maximum time in TSC-quanta that the processor can reside
in either C0.1 or C0.2.
This patch emulates MSR IA32_UMWAIT_CONTROL in guest and differentiate
IA32_UMWAIT_CONTROL between host and guest. The variable
mwait_control_cached in arch/x86/power/umwait.c caches the MSR value, so
this patch uses it to avoid frequently rdmsr of IA32_UMWAIT_CONTROL.
Co-developed-by: Jingqi Liu
Signed-off-by: Jingqi Liu
Signed-off-by: Tao Xu
---
Changes in v5:
remove vmx_waitpkg_supported() to fix guest can rdmsr or wrmsr
when the feature is off (Xiaoyao)
remove the atomic_switch_ia32_umwait_control() and move the
codes into vmx_set_msr()
rebase the patch because the kernel dependcy patch updated to
v5: https://lkml.org/lkml/2019/6/19/972
---
arch/x86/kernel/cpu/umwait.c | 3 ++-
arch/x86/kvm/vmx/vmx.c | 24
arch/x86/kvm/vmx/vmx.h | 3 +++
arch/x86/kvm/x86.c | 1 +
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/umwait.c b/arch/x86/kernel/cpu/umwait.c
index 4b2aff7b2d4d..db5c193ef136 100644
--- a/arch/x86/kernel/cpu/umwait.c
+++ b/arch/x86/kernel/cpu/umwait.c
@@ -15,7 +15,8 @@
* MSR value. By default, umwait max time is 10 in TSC-quanta and C0.2
* is enabled
*/
-static u32 umwait_control_cached = UMWAIT_CTRL_VAL(10, UMWAIT_C02_ENABLED);
+u32 umwait_control_cached = UMWAIT_CTRL_VAL(10, UMWAIT_C02_ENABLED);
+EXPORT_SYMBOL_GPL(umwait_control_cached);
/*
* Serialize access to umwait_control_cached and IA32_UMWAIT_CONTROL MSR
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b35bfac30a34..0fb55c8426e2 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1679,6 +1679,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
#endif
case MSR_EFER:
return kvm_get_msr_common(vcpu, msr_info);
+ case MSR_IA32_UMWAIT_CONTROL:
+ if (!guest_cpuid_has(vcpu, X86_FEATURE_WAITPKG))
+ return 1;
+
+ msr_info->data = vmx->msr_ia32_umwait_control;
+ break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -1841,6 +1847,22 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
return 1;
vmcs_write64(GUEST_BNDCFGS, data);
break;
+ case MSR_IA32_UMWAIT_CONTROL:
+ if (!guest_cpuid_has(vcpu, X86_FEATURE_WAITPKG))
+ return 1;
+
+ /* The reserved bit IA32_UMWAIT_CONTROL[1] should be zero */
+ if (data & BIT_ULL(1))
+ return 1;
+
+ vmx->msr_ia32_umwait_control = data;
+ if (vmx->msr_ia32_umwait_control != umwait_control_cached)
+ add_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL,
+ vmx->msr_ia32_umwait_control,
+ umwait_control_cached, false);
+ else
+ clear_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL);
+ break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -4126,6 +4148,8 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
init_event)
vmx->rmode.vm86_active = 0;
vmx->spec_ctrl = 0;
+ vmx->msr_ia32_umwait_control = 0;
+
vcpu->arch.microcode_version = 0x1ULL;
vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
kvm_set_cr8(vcpu, 0);
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 61128b48c503..8485bec7c38a 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -14,6 +14,8 @@
extern const u32 vmx_msr_index[];
extern u64 host_efer;
+extern u32 umwait_control_cached;
+
#define MSR_TYPE_R 1
#define MSR_TYPE_W 2
#define MSR_TYPE_RW3
@@ -194,6 +196,7 @@ struct vcpu_vmx {
#endif
u64 spec_ctrl;
+ u64 msr_ia32_umwait_control;
u32 vm_entry_controls_shadow;
u32 vm_exit_controls_shadow;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 83aefd759846..4480de459bf4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1138,6 +1138,7 @@ static u32 msrs_to_save[] = {
MSR_IA32_RTIT_ADDR1_A, MSR_IA32_RTIT_ADDR1_B,
MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B,
MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B,
+ MSR_IA32_UMWAIT_CONTROL,
};
static unsigned num_msrs_to_save;
--
2.20.1
Re: [PATCH v2 0/3] Add support of RGB565, YUV and JPEG to MIPID02 bridge
On 6/17/19 3:43 PM, Hugues Fruchet wrote: > Add support of RGB565, YUV and JPEG to MIPID02 bridge. > > === > = history = > === > version 2: > - Link frequency could not be computed from pixel rate for JPEG, > remove JPEG case in bpp_from_code(). > > version 1: > - Initial submission > > Hugues Fruchet (3): > media: st-mipid02: add support of RGB565 > media: st-mipid02: add support of YUYV8 and UYVY8 > media: st-mipid02: add support of JPEG > > drivers/media/i2c/st-mipid02.c | 31 +-- > 1 file changed, 25 insertions(+), 6 deletions(-) > For this series: Reviewed-by: Hans Verkuil Regards, Hans
Re: [PATCH] usb: dwc3: remove unused @lock member of dwc3_ep struct
Hi, Chunfeng Yun writes: > Hi, > On Thu, 2019-06-20 at 11:19 +0300, Felipe Balbi wrote: >> Hi, >> >> Chunfeng Yun writes: >> >> > The member @lock of dwc2_ep struct is only initialized, >> > and not used elsewhere, so remove it. > Sorry, I need send v2 to fix typo of dwc2_ep I fixed when applying ;-) -- balbi
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi, On 24/05/19 9:31 PM, Kishon Vijay Abraham I wrote: > Hi, > > On 24/05/19 5:53 PM, Fabio Estevam wrote: >> Hi Kishon, >> >> On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: >>> >>> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since >>> this is an IP core it will likely be found on others in the future. So >>> instead of adding this to the nwl host driver make it a generic PHY >>> driver. >>> >>> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be >>> added once the necessary system controller bits are in via >>> mixel_dphy_devdata. >>> >>> Signed-off-by: Guido Günther >>> Co-developed-by: Robert Chiras >>> Signed-off-by: Robert Chiras >>> Reviewed-by: Fabio Estevam >>> Reviewed-by: Sam Ravnborg >> >> Would you have any comments on this series, please? > > I don't have any comments. I'll queue this once I start queuing patches for > the > next merge window. Can you fix the following checkpatch warning and repost? WARNING: quoted string split across lines #420: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:280: + dev_dbg(&phy->dev, "hs_prepare: %u, clk_prepare: %u, " + "hs_zero: %u, clk_zero: %u, " WARNING: quoted string split across lines #421: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:281: + "hs_zero: %u, clk_zero: %u, " + "hs_trail: %u, clk_trail: %u, " WARNING: quoted string split across lines #422: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:282: + "hs_trail: %u, clk_trail: %u, " + "rxhs_settle: %u\n", Thanks Kishon
Re: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support
Hi Claudiu,
sorry for the late reply.
On 13/06/2019 16:12, claudiu.bez...@microchip.com wrote:
> Hi Daniel,
>
> On 31.05.2019 13:41, Daniel Lezcano wrote:
>>
>> Hi Claudiu,
>>
>>
>> On 30/05/2019 09:46, claudiu.bez...@microchip.com wrote:
>>> Hi Daniel,
>>>
>>> Taking into account the discussion on this tread and the fact that we have
>>> no answer from Rob on this topic (I'm talking about [1]), what do you think
>>> it would be best for this driver to be accepted the soonest? Would it be OK
>>> for you to mimic the approach done by:
>>>
>>> drivers/clocksource/timer-integrator-ap.c
>>>
>>> with the following bindings in DT:
>>>
>>> aliases {
>>> arm,timer-primary = &timer2;
>>> arm,timer-secondary = &timer1;
>>> };
>>>
>>> also in PIT64B driver?
>>>
>>> Or do you think re-spinning the Alexandre's patches at [2] (which seems to
>>> me like the generic way to do it) would be better?
>>
>> This hardware / OS connection problem is getting really annoying for
>> everyone and this pattern is repeating itself since several years. It is
>> time we fix it properly.
>>
>> The first solution looks hackish from my POV. The second approach looks
>> nicer and generic as you say. So I would vote for [2]
>> flagging approach proposed by Mark [3].
>
> With this flagging approach this would mean a kind unification of
> clocksource and clockevent functionalities under a single one, right? So
> that the driver would register to the above layers only one device w/ 2
> functionalities (clocksource and clockevent)? Please correct me if I'm
> wrong? If so, from my point of view this would require major re-working of
> clocksource and clockevent subsystems. Correctly if I wrongly understood,
> please.
Well, actually I was not expecting to change all the framework but just
pass a flag to the probe function telling if the node is for a
clocksource, a clockevent or both.
> At the moment we register different functionalities (clocksource and
> clockevent) to the above layers for hardware blocks (e.g. with
> clocksource_register_hz() or clockevents_config_and_register()). If
> hardware can support clocksource and clockevent we register both these
> functionalities, if only one is supported we register only one of these.
> The above layers would choose the best clocksource/clockevent device from
> the available ones based on rating field for each clocksource/clockevent we
> register. In all this current behavior I don't see how these flags would
> interact with clocksource/clockevent subsystem. Could you please let me
> know how do you see these and the way these new flags would interact with
> the layers above the drivers?
>>
>> I added Arnd in Cc in order to have its opinion.
>>
>> [3]
>> https://lore.kernel.org/lkml/20171215113242.skmh5nzr7wqdm...@lakrids.cambridge.arm.com/
>>
>>> [1]
>>> https://lore.kernel.org/lkml/20190408151155.20279-1-alexandre.bell...@bootlin.com/#t
>>> [2]
>>> https://lore.kernel.org/lkml/20171213185313.20017-1-alexandre.bell...@free-electrons.com/
>>>
>>
>>
>>
>>
>>
>>
--
Facebook |
Twitter |
[PATCH net-next 06/11] net: hns3: modify handling of out of memory in hclge_err.c
From: Weihang Li
Users should be informed if HNS driver failed to allocate memory for
descriptor when handling hw errors. This patch solve above issues.
Signed-off-by: Weihang Li
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 3dfb265..dd7b8a8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1859,7 +1859,7 @@ static int hclge_handle_all_hw_msix_error(struct
hclge_dev *hdev,
if (ret) {
dev_err(dev, "fail(%d) to query msix int status bd num\n",
ret);
- return ret;
+ goto out;
}
mpf_bd_num = le32_to_cpu(desc_bd.data[0]);
@@ -1867,8 +1867,10 @@ static int hclge_handle_all_hw_msix_error(struct
hclge_dev *hdev,
bd_num = max_t(u32, mpf_bd_num, pf_bd_num);
desc = kcalloc(bd_num, sizeof(struct hclge_desc), GFP_KERNEL);
- if (!desc)
+ if (!desc) {
+ ret = -ENOMEM;
goto out;
+ }
ret = hclge_handle_mpf_msix_error(hdev, desc, mpf_bd_num,
reset_requests);
--
2.7.4
[PATCH net-next 04/11] net: hns3: restore the MAC autoneg state after reset
From: Jian Shen
When doing global reset, the MAC autoneg state of fibre
port is set to default, which may cause user configuration
lost. This patch fixes it by restore the MAC autoneg state
after reset.
Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre
port")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 6e97837..0772ca1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2400,6 +2400,15 @@ static int hclge_mac_init(struct hclge_dev *hdev)
return ret;
}
+ if (hdev->hw.mac.support_autoneg) {
+ ret = hclge_set_autoneg_en(hdev, hdev->hw.mac.autoneg);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "Config mac autoneg fail ret=%d\n", ret);
+ return ret;
+ }
+ }
+
mac->link = 0;
if (mac->user_fec_mode & BIT(HNAE3_FEC_USER_DEF)) {
--
2.7.4
[PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes
This patch-set includes code optimizations and bugfixes for the HNS3 ethernet controller driver. [patch 1/11] fixes a selftest issue when doing autoneg. [patch 2/11 - 3-11] adds two code optimizations about VLAN issue. [patch 4/11] restores the MAC autoneg state after reset. [patch 5/11 - 8/11] adds some code optimizations and bugfixes about HW errors handling. [patch 9/11 - 11/11] fixes some issues related to driver loading and unloading. Huazhong Tan (2): net: hns3: fix race conditions between reset and module loading & unloading net: hns3: fixes wrong place enabling ROCE HW error when loading Jian Shen (4): net: hns3: fix selftest fail issue for fibre port with autoneg on net: hns3: remove VF VLAN filter entry inexistent warning print net: hns3: sync VLAN filter entries when kill VLAN ID failed net: hns3: restore the MAC autoneg state after reset Weihang Li (5): net: hns3: code optimizaition of hclge_handle_hw_ras_error() net: hns3: modify handling of out of memory in hclge_err.c net: hns3: remove override_pci_need_reset net: hns3: add check to number of buffer descriptors net: hns3: add exception handling when enable NIC HW error interrupts drivers/net/ethernet/hisilicon/hns3/hnae3.h| 4 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 2 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 10 ++ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 117 +-- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 5 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 166 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 50 ++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 + 9 files changed, 279 insertions(+), 80 deletions(-) -- 2.7.4
Re: [PATCH] mlxsw: spectrum_ptp: fix 32-bit build
Hello!
On 19.06.2019 16:31, Arnd Bergmann wrote:
On 32-bit architectures, we cannot easily device 64-bit numbers:
s/device/divide/?
ERROR: "__aeabi_uldivmod"
[drivers/net/ethernet/mellanox/mlxsw/mlxsw_spectrum.ko] undefined!
Use do_div() to annotate the fact that we know this is an
div_u64() really?
expensive operation.
Fixes: 992aa864dca0 ("mlxsw: spectrum_ptp: Add implementation for physical hardware
clock operations")
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
index 2a9bbc90225e..618e329e1490 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
@@ -87,7 +87,7 @@ mlxsw_sp1_ptp_phc_settime(struct mlxsw_sp_ptp_clock *clock,
u64 nsec)
u32 next_sec;
int err;
- next_sec = nsec / NSEC_PER_SEC + 1;
+ next_sec = div_u64(nsec, NSEC_PER_SEC) + 1;
next_sec_in_nsec = next_sec * NSEC_PER_SEC;
spin_lock(&clock->lock);
MBR, Sergei
[PATCH net-next 10/11] net: hns3: fixes wrong place enabling ROCE HW error when loading
The ROCE HW errors should only be enabled when initializing ROCE's
client, the current code enable it no matter initializing NIC or
ROCE client.
So this patch fixes it.
Fixes: 00ea6e5fda9d ("net: hns3: delay and separate enabling of NIC and ROCE HW
errors")
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 53dbef9..b0a99c3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -8349,6 +8349,14 @@ static int hclge_init_roce_client_instance(struct
hnae3_ae_dev *ae_dev,
goto init_roce_err;
}
+ /* Enable roce ras interrupts */
+ ret = hclge_config_rocee_ras_interrupt(hdev, true);
+ if (ret) {
+ dev_err(&ae_dev->pdev->dev,
+ "fail(%d) to enable roce ras interrupts\n", ret);
+ goto init_roce_err;
+ }
+
hnae3_set_client_init_flag(client, ae_dev, 1);
return 0;
@@ -8403,12 +8411,6 @@ static int hclge_init_client_instance(struct
hnae3_client *client,
}
}
- /* Enable roce ras interrupts */
- ret = hclge_config_rocee_ras_interrupt(hdev, true);
- if (ret)
- dev_err(&ae_dev->pdev->dev,
- "fail(%d) to enable roce ras interrupts\n", ret);
-
return ret;
clear_nic:
--
2.7.4
[PATCH net-next 03/11] net: hns3: sync VLAN filter entries when kill VLAN ID failed
From: Jian Shen
When HW is resetting, firmware is unable to handle commands
from driver. So if remove VLAN device from stack at this time,
it will fail to remove the VLAN ID from HW VLAN filter, then
the VLAN filter status is unsynced with stack.
This patch fixes it by recording the VLAN ID delete failed,
and removes them again when reset complete.
Fixes: 44e626f720c3 ("net: hns3: fix VLAN offload handle for VLAN inserted by
port")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 74 ++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 1 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 50 ++-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 +
4 files changed, 112 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 90cbdbe..6e97837 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -35,6 +35,7 @@
static int hclge_set_mac_mtu(struct hclge_dev *hdev, int new_mps);
static int hclge_init_vlan_config(struct hclge_dev *hdev);
+static void hclge_sync_vlan_filter(struct hclge_dev *hdev);
static int hclge_reset_ae_dev(struct hnae3_ae_dev *ae_dev);
static bool hclge_get_hw_reset_stat(struct hnae3_handle *handle);
static int hclge_set_umv_space(struct hclge_dev *hdev, u16 space_size,
@@ -3539,6 +3540,7 @@ static void hclge_service_task(struct work_struct *work)
hclge_update_port_info(hdev);
hclge_update_link_status(hdev);
hclge_update_vport_alive(hdev);
+ hclge_sync_vlan_filter(hdev);
if (hdev->fd_arfs_expire_timer >= HCLGE_FD_ARFS_EXPIRE_TIMER_INTERVAL) {
hclge_rfs_filter_expire(hdev);
hdev->fd_arfs_expire_timer = 0;
@@ -7742,11 +7744,20 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle,
__be16 proto,
bool writen_to_tbl = false;
int ret = 0;
- /* when port based VLAN enabled, we use port based VLAN as the VLAN
-* filter entry. In this case, we don't update VLAN filter table
-* when user add new VLAN or remove exist VLAN, just update the vport
-* VLAN list. The VLAN id in VLAN list won't be writen in VLAN filter
-* table until port based VLAN disabled
+ /* When device is resetting, firmware is unable to handle
+* mailbox. Just record the vlan id, and remove it after
+* reset finished.
+*/
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state) && is_kill) {
+ set_bit(vlan_id, vport->vlan_del_fail_bmap);
+ return -EBUSY;
+ }
+
+ /* When port base vlan enabled, we use port base vlan as the vlan
+* filter entry. In this case, we don't update vlan filter table
+* when user add new vlan or remove exist vlan, just update the vport
+* vlan list. The vlan id in vlan list will be writen in vlan filter
+* table until port base vlan disabled
*/
if (handle->port_base_vlan_state == HNAE3_PORT_BASE_VLAN_DISABLE) {
ret = hclge_set_vlan_filter_hw(hdev, proto, vport->vport_id,
@@ -7754,16 +7765,53 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle,
__be16 proto,
writen_to_tbl = true;
}
- if (ret)
- return ret;
+ if (!ret) {
+ if (is_kill)
+ hclge_rm_vport_vlan_table(vport, vlan_id, false);
+ else
+ hclge_add_vport_vlan_table(vport, vlan_id,
+ writen_to_tbl);
+ } else if (is_kill) {
+ /* When remove hw vlan filter failed, record the vlan id,
+* and try to remove it from hw later, to be consistence
+* with stack
+*/
+ set_bit(vlan_id, vport->vlan_del_fail_bmap);
+ }
+ return ret;
+}
- if (is_kill)
- hclge_rm_vport_vlan_table(vport, vlan_id, false);
- else
- hclge_add_vport_vlan_table(vport, vlan_id,
- writen_to_tbl);
+static void hclge_sync_vlan_filter(struct hclge_dev *hdev)
+{
+#define HCLGE_MAX_SYNC_COUNT 60
- return 0;
+ int i, ret, sync_cnt = 0;
+ u16 vlan_id;
+
+ /* start from vport 1 for PF is always alive */
+ for (i = 0; i < hdev->num_alloc_vport; i++) {
+ struct hclge_vport *vport = &hdev->vport[i];
+
+ vlan_id = find_first_bit(vport->vlan_del_fail_bmap,
+VLAN_N_VID);
+ while (vlan_id != VLAN_N_VID) {
+ ret = hclge_set_vlan_filter_hw(hdev, htons(ETH_P_8021Q),
+ vport->vport_id,
[PATCH net-next 05/11] net: hns3: code optimizaition of hclge_handle_hw_ras_error()
From: Weihang Li
This patch optimizes hclge_handle_hw_ras_error() to make the code logic
clearer.
1. If there was no NIC or Roce RAS when we read
HCLGE_RAS_PF_OTHER_INT_STS_REG, we return directly.
2. Because NIC and Roce RAS may occurs at the same time, so we should
check value of revision at first before we handle Roce RAS instead
of only checking it in branch of no NIC RAS is detected.
3. Check HCLGE_STATE_RST_HANDLING each time before we want to return
PCI_ERS_RESULT_NEED_RESET.
4. Remove checking of HCLGE_RAS_REG_NFE_MASK and
HCLGE_RAS_REG_ROCEE_ERR_MASK because if hw_err_reset_req is not
zero, it proves that we have set it in handling of NIC or Roce RAS.
Signed-off-by: Weihang Li
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index fb616cb..3dfb265 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1606,6 +1606,8 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
if (status & HCLGE_RAS_REG_NFE_MASK ||
status & HCLGE_RAS_REG_ROCEE_ERR_MASK)
ae_dev->hw_err_reset_req = 0;
+ else
+ goto out;
/* Handling Non-fatal HNS RAS errors */
if (status & HCLGE_RAS_REG_NFE_MASK) {
@@ -1613,27 +1615,25 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
"HNS Non-Fatal RAS error(status=0x%x) identified\n",
status);
hclge_handle_all_ras_errors(hdev);
- } else {
- if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state) ||
- hdev->pdev->revision < 0x21) {
- ae_dev->override_pci_need_reset = 1;
- return PCI_ERS_RESULT_RECOVERED;
- }
}
- if (status & HCLGE_RAS_REG_ROCEE_ERR_MASK) {
- dev_warn(dev, "ROCEE uncorrected RAS error identified\n");
+ /* Handling Non-fatal Rocee RAS errors */
+ if (hdev->pdev->revision >= 0x21 &&
+ status & HCLGE_RAS_REG_ROCEE_ERR_MASK) {
+ dev_warn(dev, "ROCEE Non-Fatal RAS error identified\n");
hclge_handle_rocee_ras_error(ae_dev);
}
- if ((status & HCLGE_RAS_REG_NFE_MASK ||
-status & HCLGE_RAS_REG_ROCEE_ERR_MASK) &&
-ae_dev->hw_err_reset_req) {
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ goto out;
+
+ if (ae_dev->hw_err_reset_req) {
ae_dev->override_pci_need_reset = 0;
return PCI_ERS_RESULT_NEED_RESET;
}
- ae_dev->override_pci_need_reset = 1;
+out:
+ ae_dev->override_pci_need_reset = 1;
return PCI_ERS_RESULT_RECOVERED;
}
--
2.7.4
Re: [RESEND PATCH] block: move tag field position in struct request
Looks good, Reviewed-by: Christoph Hellwig
[PATCH net-next 01/11] net: hns3: fix selftest fail issue for fibre port with autoneg on
From: Jian Shen
When doing selftest for fibre port with autoneg on, the MAC speed
may be incorrect, which may cause the selftest failed. This patch
fixes it by halting autoneg during the selftest.
Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre
port")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 +++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 10 ++
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 12
3 files changed, 25 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index bf921ef..d78a5f6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -264,6 +264,8 @@ struct hnae3_ae_dev {
* get auto autonegotiation of pause frame use
* restart_autoneg()
* restart autonegotiation
+ * halt_autoneg()
+ * halt/resume autonegotiation when autonegotiation on
* get_coalesce_usecs()
* get usecs to delay a TX interrupt after a packet is sent
* get_rx_max_coalesced_frames()
@@ -383,6 +385,7 @@ struct hnae3_ae_ops {
int (*set_autoneg)(struct hnae3_handle *handle, bool enable);
int (*get_autoneg)(struct hnae3_handle *handle);
int (*restart_autoneg)(struct hnae3_handle *handle);
+ int (*halt_autoneg)(struct hnae3_handle *handle, bool halt);
void (*get_coalesce_usecs)(struct hnae3_handle *handle,
u32 *tx_usecs, u32 *rx_usecs);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 0998647..16034af 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -336,6 +336,13 @@ static void hns3_self_test(struct net_device *ndev,
h->ae_algo->ops->enable_vlan_filter(h, false);
#endif
+ /* Tell firmware to stop mac autoneg before loopback test start,
+* otherwise loopback test may be failed when the port is still
+* negotiating.
+*/
+ if (h->ae_algo->ops->halt_autoneg)
+ h->ae_algo->ops->halt_autoneg(h, true);
+
set_bit(HNS3_NIC_STATE_TESTING, &priv->state);
for (i = 0; i < HNS3_SELF_TEST_TYPE_NUM; i++) {
@@ -358,6 +365,9 @@ static void hns3_self_test(struct net_device *ndev,
clear_bit(HNS3_NIC_STATE_TESTING, &priv->state);
+ if (h->ae_algo->ops->halt_autoneg)
+ h->ae_algo->ops->halt_autoneg(h, false);
+
#if IS_ENABLED(CONFIG_VLAN_8021Q)
if (dis_vlan_filter)
h->ae_algo->ops->enable_vlan_filter(h, true);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fbf0c20..b328662 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2315,6 +2315,17 @@ static int hclge_restart_autoneg(struct hnae3_handle
*handle)
return hclge_notify_client(hdev, HNAE3_UP_CLIENT);
}
+static int hclge_halt_autoneg(struct hnae3_handle *handle, bool halt)
+{
+ struct hclge_vport *vport = hclge_get_vport(handle);
+ struct hclge_dev *hdev = vport->back;
+
+ if (hdev->hw.mac.support_autoneg && hdev->hw.mac.autoneg)
+ return hclge_set_autoneg_en(hdev, !halt);
+
+ return 0;
+}
+
static int hclge_set_fec_hw(struct hclge_dev *hdev, u32 fec_mode)
{
struct hclge_config_fec_cmd *req;
@@ -9265,6 +9276,7 @@ static const struct hnae3_ae_ops hclge_ops = {
.set_autoneg = hclge_set_autoneg,
.get_autoneg = hclge_get_autoneg,
.restart_autoneg = hclge_restart_autoneg,
+ .halt_autoneg = hclge_halt_autoneg,
.get_pauseparam = hclge_get_pauseparam,
.set_pauseparam = hclge_set_pauseparam,
.set_mtu = hclge_set_mtu,
--
2.7.4
[PATCH net-next 07/11] net: hns3: remove override_pci_need_reset
From: Weihang Li
We add override_pci_need_reset to prevent redundant and unwanted PF
resets if a RAS error occurs in commit 69b51bbb03f7 ("net: hns3: fix
to stop multiple HNS reset due to the AER changes").
Now in HNS3 driver, we use hw_err_reset_req to record reset level that
we need to recover from a RAS error. This variable cans solve above
issue as override_pci_need_reset, so this patch removes
override_pci_need_reset.
Signed-off-by: Weihang Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 -
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 5 +
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index d78a5f6..48c7b70 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -213,7 +213,6 @@ struct hnae3_ae_dev {
const struct hnae3_ae_ops *ops;
struct list_head node;
u32 flag;
- u8 override_pci_need_reset; /* fix to stop multiple reset happening */
unsigned long hw_err_reset_req;
enum hnae3_reset_type reset_type;
void *priv;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 58633cd..4dee7fe 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1950,7 +1950,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev
*pdev)
ops = ae_dev->ops;
/* request the reset */
if (ops->reset_event) {
- if (!ae_dev->override_pci_need_reset) {
+ if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
&ae_dev->hw_err_reset_req);
ops->set_default_reset_request(ae_dev, reset_type);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index dd7b8a8..3d8985f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1627,13 +1627,10 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
goto out;
- if (ae_dev->hw_err_reset_req) {
- ae_dev->override_pci_need_reset = 0;
+ if (ae_dev->hw_err_reset_req)
return PCI_ERS_RESULT_NEED_RESET;
- }
out:
- ae_dev->override_pci_need_reset = 1;
return PCI_ERS_RESULT_RECOVERED;
}
--
2.7.4
[PATCH net-next 08/11] net: hns3: add check to number of buffer descriptors
From: Weihang Li
This patch adds check to number of bds before we allocate memory for
them. If we get an invalid bd num in some cases, it will cause a memory
overflow.
Signed-off-by: Weihang Li
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 86 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 5 ++
2 files changed, 58 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 3d8985f..0a72438 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1060,6 +1060,52 @@ static int hclge_config_ssu_hw_err_int(struct hclge_dev
*hdev, bool en)
return ret;
}
+/* hclge_query_bd_num: query number of buffer descriptors
+ * @hdev: pointer to struct hclge_dev
+ * @is_ras: true for ras, false for msix
+ * @mpf_bd_num: number of main PF interrupt buffer descriptors
+ * @pf_bd_num: number of not main PF interrupt buffer descriptors
+ *
+ * This function querys number of mpf and pf buffer descriptors.
+ */
+static int hclge_query_bd_num(struct hclge_dev *hdev, bool is_ras,
+ int *mpf_bd_num, int *pf_bd_num)
+{
+ struct device *dev = &hdev->pdev->dev;
+ u32 mpf_min_bd_num, pf_min_bd_num;
+ enum hclge_opcode_type opcode;
+ struct hclge_desc desc_bd;
+ int ret;
+
+ if (is_ras) {
+ opcode = HCLGE_QUERY_RAS_INT_STS_BD_NUM;
+ mpf_min_bd_num = HCLGE_MPF_RAS_INT_MIN_BD_NUM;
+ pf_min_bd_num = HCLGE_PF_RAS_INT_MIN_BD_NUM;
+ } else {
+ opcode = HCLGE_QUERY_MSIX_INT_STS_BD_NUM;
+ mpf_min_bd_num = HCLGE_MPF_MSIX_INT_MIN_BD_NUM;
+ pf_min_bd_num = HCLGE_PF_MSIX_INT_MIN_BD_NUM;
+ }
+
+ hclge_cmd_setup_basic_desc(&desc_bd, opcode, true);
+ ret = hclge_cmd_send(&hdev->hw, &desc_bd, 1);
+ if (ret) {
+ dev_err(dev, "fail(%d) to query msix int status bd num\n",
+ ret);
+ return ret;
+ }
+
+ *mpf_bd_num = le32_to_cpu(desc_bd.data[0]);
+ *pf_bd_num = le32_to_cpu(desc_bd.data[1]);
+ if (*mpf_bd_num < mpf_min_bd_num || *pf_bd_num < pf_min_bd_num) {
+ dev_err(dev, "Invalid bd num: mpf(%d), pf(%d)\n",
+ *mpf_bd_num, *pf_bd_num);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/* hclge_handle_mpf_ras_error: handle all main PF RAS errors
* @hdev: pointer to struct hclge_dev
* @desc: descriptor for describing the command
@@ -1291,24 +1337,16 @@ static int hclge_handle_pf_ras_error(struct hclge_dev
*hdev,
static int hclge_handle_all_ras_errors(struct hclge_dev *hdev)
{
- struct device *dev = &hdev->pdev->dev;
u32 mpf_bd_num, pf_bd_num, bd_num;
- struct hclge_desc desc_bd;
struct hclge_desc *desc;
int ret;
/* query the number of registers in the RAS int status */
- hclge_cmd_setup_basic_desc(&desc_bd, HCLGE_QUERY_RAS_INT_STS_BD_NUM,
- true);
- ret = hclge_cmd_send(&hdev->hw, &desc_bd, 1);
- if (ret) {
- dev_err(dev, "fail(%d) to query ras int status bd num\n", ret);
+ ret = hclge_query_bd_num(hdev, true, &mpf_bd_num, &pf_bd_num);
+ if (ret)
return ret;
- }
- mpf_bd_num = le32_to_cpu(desc_bd.data[0]);
- pf_bd_num = le32_to_cpu(desc_bd.data[1]);
- bd_num = max_t(u32, mpf_bd_num, pf_bd_num);
+ bd_num = max_t(u32, mpf_bd_num, pf_bd_num);
desc = kcalloc(bd_num, sizeof(struct hclge_desc), GFP_KERNEL);
if (!desc)
return -ENOMEM;
@@ -1844,25 +1882,16 @@ static int hclge_handle_all_hw_msix_error(struct
hclge_dev *hdev,
struct hclge_mac_tnl_stats mac_tnl_stats;
struct device *dev = &hdev->pdev->dev;
u32 mpf_bd_num, pf_bd_num, bd_num;
- struct hclge_desc desc_bd;
struct hclge_desc *desc;
u32 status;
int ret;
/* query the number of bds for the MSIx int status */
- hclge_cmd_setup_basic_desc(&desc_bd, HCLGE_QUERY_MSIX_INT_STS_BD_NUM,
- true);
- ret = hclge_cmd_send(&hdev->hw, &desc_bd, 1);
- if (ret) {
- dev_err(dev, "fail(%d) to query msix int status bd num\n",
- ret);
+ ret = hclge_query_bd_num(hdev, false, &mpf_bd_num, &pf_bd_num);
+ if (ret)
goto out;
- }
- mpf_bd_num = le32_to_cpu(desc_bd.data[0]);
- pf_bd_num = le32_to_cpu(desc_bd.data[1]);
bd_num = max_t(u32, mpf_bd_num, pf_bd_num);
-
desc = kcalloc(bd_num, sizeof(struct hclge_desc), GFP_KERNEL);
if (!desc) {
ret = -ENOMEM;
@@ -1930,7 +1959,6 @@ void hclge_handle_all_hns_hw_errors(struct hnae3_ae_dev
*a
[PATCH net-next 02/11] net: hns3: remove VF VLAN filter entry inexistent warning print
From: Jian Shen
For VF VLAN filter is disabled when VF VLAN table is full, then the
new VLAN ID won't be added into VF VLAN table, it will always print
fail log when remove these VLAN IDs. If user has added too many
VLANs, it will cause massive verbose print logs.
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index b328662..90cbdbe 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7112,12 +7112,13 @@ static int hclge_set_vf_vlan_common(struct hclge_dev
*hdev, u16 vfid,
if (!req0->resp_code)
return 0;
- if (req0->resp_code == HCLGE_VF_VLAN_DEL_NO_FOUND) {
- dev_warn(&hdev->pdev->dev,
-"vlan %d filter is not in vf vlan table\n",
-vlan);
+ /* vf vlan filter is disabled when vf vlan table is full,
+* then new vlan id will not be added into vf vlan table.
+* Just return 0 without warning, avoid massive verbose
+* print logs when unload.
+*/
+ if (req0->resp_code == HCLGE_VF_VLAN_DEL_NO_FOUND)
return 0;
- }
dev_err(&hdev->pdev->dev,
"Kill vf vlan filter fail, ret =%d.\n",
--
2.7.4
[PATCH net-next 11/11] net: hns3: add exception handling when enable NIC HW error interrupts
From: Weihang Li
If we failed to enable NIC HW error interrupts during client
initialization in some cases, we should do exception handling to clear
flags and free the resources.
Fixes: 00ea6e5fda9d ("net: hns3: delay and separate enabling of NIC and ROCE HW
errors")
Signed-off-by: Weihang Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index b0a99c3..b25365c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -8297,13 +8297,15 @@ static int hclge_init_nic_client_instance(struct
hnae3_ae_dev *ae_dev,
goto init_nic_err;
}
- hnae3_set_client_init_flag(client, ae_dev, 1);
-
/* Enable nic hw error interrupts */
ret = hclge_config_nic_hw_error(hdev, true);
- if (ret)
+ if (ret) {
dev_err(&ae_dev->pdev->dev,
"fail(%d) to enable hw error interrupts\n", ret);
+ goto init_nic_err;
+ }
+
+ hnae3_set_client_init_flag(client, ae_dev, 1);
if (netif_msg_drv(&hdev->vport->nic))
hclge_info_show(hdev);
--
2.7.4
Re: [PATCH] KVM: vmx: Fix the broken usage of vmx_xsaves_supported
On 6/20/2019 4:17 PM, Paolo Bonzini wrote: On 20/06/19 08:46, Xiaoyao Li wrote: It depends on whether or not processors support the 1-setting instead of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway, Yes, whether this field exist or not depends on whether processors support the 1-setting. But if "enable XSAVES/XRSTORS" is clear to 0, XSS_EXIT_BITMAP doesn't work. I think in this case, there is no need to set this vmcs field? vmx->secondary_exec_control can change; you are making the code more complex by relying on the value of the field at the point of vmx_vcpu_setup. At this point. Agreed. It's harmless to set a default value. I do _think_ your version is incorrect, because at this point CPUID has not been initialized yet and therefore vmx_compute_secondary_exec_control has not set SECONDARY_EXEC_XSAVES. SECONDARY_EXEC_XSAVES is in the opt when setup_vmcs_config, and vmx_compute_secondary_exec_control() is to clear SECONDARY_EXEC_XSAVES based on guest cpuid. However I may be wrong because I didn't review the code very closely: the old code is obvious and so there is no point in changing it. you mean this part about XSS_EXIT_BITMAP? how about the other part in vmx_set/get_msr() in this patch? Paolo
