Re: [PATCH v4 07/15] mtd: nand: move Samsung specific init/detection logic in nand_samsung.c
On Tue, 10 Jan 2017 20:00:28 +0100
Marek Vasut wrote:
> On 01/07/2017 08:49 AM, Boris Brezillon wrote:
> > On Sat, 7 Jan 2017 00:53:24 +0100
> > Marek Vasut wrote:
> >
> >> On 01/04/2017 06:08 PM, Boris Brezillon wrote:
> >>> On Wed, 4 Jan 2017 16:14:07 +0100
> >>> Marek Vasut wrote:
> >>>
> On 01/03/2017 02:01 PM, Boris Brezillon wrote:
> > Move Samsung specific initialization and detection logic into
> > nand_samsung.c. This is part of the "separate vendor specific code from
> > core" cleanup process.
> >
> > Signed-off-by: Boris Brezillon
> >
>
> [...]
>
> > diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> > index b3a332f37e14..05e9366696c9 100644
> > --- a/drivers/mtd/nand/nand_ids.c
> > +++ b/drivers/mtd/nand/nand_ids.c
> > @@ -10,7 +10,7 @@
> > #include
> > #include
> >
> > -#define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
> > +#define LP_OPTIONS 0
> > #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
> >
> > #define SP_OPTIONS NAND_NEED_READRDY
> > @@ -169,10 +169,12 @@ struct nand_flash_dev nand_flash_ids[] = {
> > };
> >
> > /* Manufacturer IDs */
> > +extern const struct nand_manufacturer_ops samsung_nand_manuf_ops;
>
> Is the extern needed ?
> >>>
> >>> Yes, unless you have another solution. If you remove the extern keyword
> >>> you just redeclare samsung_nand_manuf_ops here, which is not what we
> >>> want.
> >>
> >> Maybe some accessor function can help ?
> >>
> >
> > You mean, in nand_ids.c
> >
> > const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops();
> >
> > struct nand_manufacturers nand_manuf_ids[] = {
> > ...
> > {NAND_MFR_SAMSUNG, "Samsung", get_samsung_nand_mafuf_ops},
> > ...
> > };
> >
> > and then, in nand_samsung.c
> >
> > const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops()
> > {
> > return &samsung_nand_mafuf_ops;
> > }
>
> Yeah, something like that.
>
> > What's the point of this extra indirection? I mean, in both cases you
> > use a symbol that is not part of the same source file, so you'll have
> > to define this symbol (using a function prototype or an extern object
> > definition).
> > Is this all about fixing checkpatch warnings, or do you have a problem
> > with objects shared between different source files?
>
> The later, separating this with an accessor function feels a bit cleaner
> to me than using extern foo.
>
> > Now, I agree that the current approach is not ideal. A real improvement
> > would be to let the NAND manufacturer drivers (nand_.c) register
> > themselves to the core. Something similar to CLK_OF_DECLARE() or
> > IRQCHIP_DECLARE() for example. But that means creating a dedicated
> > section for the nand_manufs_id table, and it's a lot more invasive than
> > the current approach.
>
> Well this would be awesome, but this can also be done later. I presume
> you'll get to it eventually anyway, as soon as you'll be annoyed enough
> with the current ugly-ish implementation.
>
If we plan to rework it this way, I'd like to keep the existing
approach (with the extern) to avoid changing the prototype of
nand_manufacturer once again when we rework the nand_manufacturer
registration logic.
Also note that in v6 I'm keeping a pointer to the nand_manfucturer
object in nand_chip, so that if we ever need to print the manufacturer
name we don't have to search again in the NAND manufacturer table.
After this rework, I no longer store the manufacturer_ops directly in
nand_chip, and have to access them by doing
chip->manufacturer.desc->ops->xxx.
Which means, with your solution, I'll have to do
ops = nand_get_manufacturer_ops(chip->manufacturer.desc);
ops->xxx();
instead of
chip->manufacturer.desc->ops->xxx();
Re: [PATCH v1 1/1] serial: 8250_dw: Allow hardware flow control to be used
On Tue, Dec 06, 2016 at 02:34:03PM -0800, Jason Uy wrote: > In the most common use case, the Synopsys DW UART driver does not > set the set_termios callback function. This prevents UPSTAT_AUTOCTS > from being set when the UART flag CRTSCTS is set. As a result, the > driver will use software flow control as opposed to hardware flow > control. > > To fix the problem, the set_termios callback function is set to the > DW specific function. The logic to set UPSTAT_AUTOCTS is moved so > that any clock error will not affect setting the hardware flow > control. > > Reviewed-by: Scott Branden > Reviewed-by: Ray Jui > Signed-off-by: Jason Uy > --- > drivers/tty/serial/8250/8250_dw.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) This patch doesn't apply at all to the latest kernel tree. Can you please refresh it and resend? thanks, greg k-h
Re: [PATCH v3 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x UART
On Thu, Jan 05, 2017 at 12:54:16PM -0600, David Lechner wrote: > This series adds a new UART port type for TI > DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x > UART. These SoCs have a non-standard register for UART power management that > needs special handling in the UART driver. > > Greg, the first two patches will need to go through your tree. Sekhar and > Santosh will pick up the 3 and 4 patches respectively. Ok, I've now taken those two. thanks, greg k-h
Re: x86-64: Maintain 16-byte stack alignment
On 11 January 2017 at 06:53, Linus Torvalds wrote: > > > On Jan 10, 2017 8:36 PM, "Herbert Xu" wrote: > > > Sure we can ban the use of attribute aligned on stacks. But > what about indirect uses through structures? > > > It should be pretty trivial to add a sparse warning for that, though. > Couldn't we update the __aligned(x) macro to emit 32 if arch == x86 and x == 16? All other cases should work just fine afaict
Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()
On 01/10/17 at 12:51pm, Matt Fleming wrote: > On Tue, 10 Jan, at 08:37:35AM, Dave Young wrote: > > > > It is true that it depends on acpi init, I was wondering if bgrt parsing can > > be moved to early acpi code. But anyway I'm not sure it is doable and > > worth. > > That's a good question. I think I gave up last time I tried to move > the BGRT code to early boot because of the dependencies involved with > having the ACPI table parsing code initialised. > > But if you want to take a crack at it, I'd be happy to review the > patches. Ok, I will have a try. Thanks Dave
Re: [PATCH] selftests/futex: Fix makefile dependencies
On Wed, Jan 11, 2017 at 01:37:19PM +0900, Stafford Horne wrote: > On Tue, Jan 10, 2017 at 02:17:18PM -0800, Darren Hart wrote: > > On Tue, Jan 10, 2017 at 02:10:42PM -0800, Darren Hart wrote: > > > On Fri, Jan 06, 2017 at 01:18:39PM +0900, Stafford Horne wrote: > > > > I am working on doing selftests for openrisc and found issues with the > > > > futex test is not building after changes to the tests source. > > > > > > > > This issue is that the TARGETS variable used in the futex Makefile is > > > > also used by the selftests Makefile, so when building from toplevel the > > > > TARGETS variable is clobbered and nothing gets built. Changed the > > > > variable name to get around that. > > > > > > > > Also, the futex makefile did not contain dependencies for all headers, > > > > so if we make changes to logging.h rebuild will not happen. Add headers > > > > to fix it up. > > > > > > > > Signed-off-by: Stafford Horne > > > > > > Thanks for catching this and the fix. > > > > > > +Shuah Khan > > > > > > Note: This appears also to be a problem for intel_pstate/Makefile > > > > Or, it would be if intel_pstate was listed in selftests/Makefile :-) > > Right, thanks for having a look. I actually have a small patch to also > add to logging.h. If you have not already fixed the > intel_pstate test I'll send them all together. Please do, thanks! -- Darren Hart Intel Open Source Technology Center
Re: [PATCH 2/3] cpu: expose pm_qos_resume_latency for each cpu
On Thu, Jan 05, 2017 at 11:29:46PM +0800, Alex Shi wrote: > The cpu-dma PM QoS constraint impacts all the cpus in the system. There > is no way to let the user to choose a PM QoS constraint per cpu. > > The following patch exposes to the userspace a per cpu based sysfs file > in order to let the userspace to change the value of the PM QoS latency > constraint. > > This change is inoperative in its form and the cpuidle governors have to > take into account the per cpu latency constraint in addition to the > global cpu-dma latency constraint in order to operate properly. > > BTW > The pm_qos_resume_latency usage defined in > Documentation/ABI/testing/sysfs-devices-power > The /sys/devices/.../power/pm_qos_resume_latency_us attribute > contains the PM QoS resume latency limit for the given device, > which is the maximum allowed time it can take to resume the > device, after it has been suspended at run time, from a resume > request to the moment the device will be ready to process I/O, > in microseconds. If it is equal to 0, however, this means that > the PM QoS resume latency may be arbitrary. > > Signed-off-by: Alex Shi > To: linux-kernel@vger.kernel.org > To: Greg Kroah-Hartman > Cc: linux...@vger.kernel.org > Cc: Ulf Hansson > Cc: Daniel Lezcano > Cc: "Rafael J. Wysocki" > --- > drivers/base/cpu.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c > index 4c28e1a..29cf3459 100644 > --- a/drivers/base/cpu.c > +++ b/drivers/base/cpu.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > > #include "base.h" > > @@ -376,6 +377,9 @@ int register_cpu(struct cpu *cpu, int num) > > per_cpu(cpu_sys_devices, num) = &cpu->dev; > register_cpu_under_node(num, cpu_to_node(num)); > +#ifdef CONFIG_CPU_IDLE_GOV_MENU > + dev_pm_qos_expose_latency_limit(&cpu->dev, 0); > +#endif No way to do this without the #ifdef? That's really not recommended for .c code :( thanks, greg k-h
Re: x86-64: Maintain 16-byte stack alignment
On Wed, Jan 11, 2017 at 08:06:54AM +, Ard Biesheuvel wrote: > > Couldn't we update the __aligned(x) macro to emit 32 if arch == x86 > and x == 16? All other cases should work just fine afaict Not everyone uses that macro. You'd also need to add some checks to stop people from using the gcc __attribute__ directly. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v7 2/7] perf/amd/iommu: Modify functions to query max banks and counters
On January 11, 2017 4:03:50 AM GMT+01:00, Suravee Suthikulpanit wrote: > >Right Thanks for catching this. Do you want me to send out V8 with >this fix? Send only the corrected version of this patch please, as a reply to this message. Thanks. -- Sent from a small device: formatting sux and brevity is inevitable.
Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
On Tue 10-01-17 15:29:43, Ross Zwisler wrote:
> As reported by Arnd:
>
> https://lkml.org/lkml/2017/1/10/756
>
> Compiling with the following configuration:
>
> # CONFIG_EXT2_FS is not set
> # CONFIG_EXT4_FS is not set
> # CONFIG_XFS_FS is not set
> # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
> CONFIG_FS_DAX=y
>
> generates build warnings about unused functions in fs/dax.c:
>
> fs/dax.c:878:12: warning: ‘dax_insert_mapping’ defined but not used
> [-Wunused-function]
> static int dax_insert_mapping(struct address_space *mapping,
> ^~
> fs/dax.c:572:12: warning: ‘copy_user_dax’ defined but not used
> [-Wunused-function]
> static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t
> size,
> ^
> fs/dax.c:542:12: warning: ‘dax_load_hole’ defined but not used
> [-Wunused-function]
> static int dax_load_hole(struct address_space *mapping, void **entry,
> ^
> fs/dax.c:312:14: warning: ‘grab_mapping_entry’ defined but not used
> [-Wunused-function]
> static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
> ^~
>
> Now that the struct buffer_head based DAX fault paths and I/O path have
> been removed we really depend on iomap support being present for DAX. Make
> this explicit by selecting FS_IOMAP if we compile in DAX support.
>
> This allows us to remove conditional selections of FS_IOMAP when FS_DAX was
> present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
>
> Signed-off-by: Ross Zwisler
> Reported-by: Arnd Bergmann
> Cc: Jan Kara
> Cc: Christoph Hellwig
Looks good. I agree that DAX without FS_IOMAP does not make sense. You can
add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/Kconfig | 1 +
> fs/dax.c| 2 --
> fs/ext2/Kconfig | 1 -
> fs/ext4/Kconfig | 1 -
> 4 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index c2a377c..83eab52 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
> bool "Direct Access (DAX) support"
> depends on MMU
> depends on !(ARM || MIPS || SPARC)
> + select FS_IOMAP
> help
> Direct Access (DAX) can be used on memory-backed block devices.
> If the block device supports DAX and the filesystem supports DAX,
> diff --git a/fs/dax.c b/fs/dax.c
> index 5c74f60..083b950 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -969,7 +969,6 @@ int __dax_zero_page_range(struct block_device *bdev,
> sector_t sector,
> }
> EXPORT_SYMBOL_GPL(__dax_zero_page_range);
>
> -#ifdef CONFIG_FS_IOMAP
> static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
> {
> return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
> @@ -1407,4 +1406,3 @@ int dax_iomap_pmd_fault(struct vm_area_struct *vma,
> unsigned long address,
> }
> EXPORT_SYMBOL_GPL(dax_iomap_pmd_fault);
> #endif /* CONFIG_FS_DAX_PMD */
> -#endif /* CONFIG_FS_IOMAP */
> diff --git a/fs/ext2/Kconfig b/fs/ext2/Kconfig
> index 36bea5a..c634874e 100644
> --- a/fs/ext2/Kconfig
> +++ b/fs/ext2/Kconfig
> @@ -1,6 +1,5 @@
> config EXT2_FS
> tristate "Second extended fs support"
> - select FS_IOMAP if FS_DAX
> help
> Ext2 is a standard Linux file system for hard disks.
>
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index 7b90691..e38039f 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -37,7 +37,6 @@ config EXT4_FS
> select CRC16
> select CRYPTO
> select CRYPTO_CRC32C
> - select FS_IOMAP if FS_DAX
> help
> This is the next generation of the ext3 filesystem.
>
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
RE: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
Hi Jean-Jacques,
> -Original Message-
> From: Jean-Jacques Hiblot [mailto:jjhib...@gmail.com]
> Sent: 2017年1月11日 0:51
> To: Alexandre Belloni
> Cc: Wenyou Yang - A41535 ; Mark Rutland
> ; devicetree ; Russell
> King ; Wenyou Yang - A41535
> ; Nicolas Ferre ;
> Linux Kernel Mailing List ; Rob Herring
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu
> idle
>
> 2017-01-10 17:18 GMT+01:00 Alexandre Belloni
> :
> > I though a bit more about it, and I don't really like the new
> > compatible string. I don't feel this should be necessary.
> >
> > What about the following:
> >
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> > b4332b727e9c..0333aca63e44 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
> > @@ -53,6 +53,7 @@ extern void at91_pinctrl_gpio_resume(void); static
> > struct {
> > unsigned long uhp_udp_mask;
> > int memctrl;
> > + bool has_l2_cache;
> > } at91_pm_data;
> >
> > void __iomem *at91_ramc_base[2];
> > @@ -267,6 +268,11 @@ static void at91_ddr_standby(void)
> > u32 lpr0, lpr1 = 0;
> > u32 saved_lpr0, saved_lpr1 = 0;
> >
>
> > + if (at91_pm_data.has_l2_cache) {
> > + flush_cache_all();
> what is the point of calling flush_cache_all() here ? Do we really care that
> dirty
> data in L1 is written to DDR ? I may be missing something but to me it's just
> extra
> latency.
Are you mean use outer_flush_all() to flush all cache lines in the outer cache
only?
> > + outer_disable();
> It seems to me that if there's no L2 cache, then outer_disable() is a no-op.
> It
> could be called unconditionally.
> > + }
> > +
> > if (at91_ramc_base[1]) {
> > saved_lpr1 = at91_ramc_read(1, AT91_DDRSDRC_LPR);
> > lpr1 = saved_lpr1 & ~AT91_DDRSDRC_LPCB; @@ -287,6
> > +293,9 @@ static void at91_ddr_standby(void)
> > at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
> > if (at91_ramc_base[1])
> > at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
> > +
> > + if (at91_pm_data.has_l2_cache)
> > + outer_resume();
>
> same remark as for outer_disable()
>
> Jean-Jacques
>
> > }
> >
> > /* We manage both DDRAM/SDRAM controllers, we need more than one
> > value
> > * to
> > @@ -353,6 +362,11 @@ static __init void at91_dt_ramc(void)
> > return;
> > }
> >
> > + np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
> > + if (np)
> > + at91_pm_data.has_l2_cache = true;
> > + of_node_put(np);
> > +
> > at91_pm_set_standby(standby);
> > }
> >
> >
> > This has the following benefits:
> > - everybody will have the fix, regardless of whether the dtb is
> > updated
> > - has_l2_cache can be used later in at91_pm_suspend instead of calling
> >it unconditionnaly (I'll send a patch)
> >
> >
> > On 06/01/2017 at 14:59:45 +0800, Wenyou Yang wrote :
> >> For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache, flush
> >> the L2 cache first before entering the cpu idle.
> >>
> >> Signed-off-by: Wenyou Yang
> >> ---
> >>
> >> arch/arm/mach-at91/pm.c | 19 +++
> >> drivers/memory/atmel-sdramc.c | 1 +
> >> 2 files changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> >> b4332b727e9c..1a60dede1a01 100644
> >> --- a/arch/arm/mach-at91/pm.c
> >> +++ b/arch/arm/mach-at91/pm.c
> >> @@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
> >> at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1); }
> >>
> >> +static void at91_ddr_cache_standby(void) {
> >> + u32 saved_lpr;
> >> +
> >> + flush_cache_all();
> >> + outer_disable();
> >> +
> >> + saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
> >> + at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
> >> + (~AT91_DDRSDRC_LPCB)) |
> >> + AT91_DDRSDRC_LPCB_SELF_REFRESH);
> >> +
> >> + cpu_do_idle();
> >> +
> >> + at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
> >> +
> >> + outer_resume();
> >> +}
> >> +
> >> /* We manage both DDRAM/SDRAM controllers, we need more than one
> value to
> >> * remember.
> >> */
> >> @@ -324,6 +342,7 @@ static const struct of_device_id const ramc_ids[]
> __initconst = {
> >> { .compatible = "atmel,at91sam9260-sdramc", .data =
> at91sam9_sdram_standby },
> >> { .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby
> >> },
> >> { .compatible = "atmel,sama5d3-ddramc", .data =
> >> at91_ddr_standby },
> >> + { .compatible = "atmel,sama5d4-ddramc", .data =
> >> + at91_ddr_cache_standby },
> >> { /*sentinel*/ }
> >> };
> >>
> >> diff --git a/drivers/memory/atmel-sdramc.c
> >> b/drivers/memory/atmel-sdramc.c index b418b39af180..7e5c5c6c1348
> >> 100644
> >> --- a/drivers/memory/atmel-sdramc.c
> >> +++ b/dr
Re: [PATCH v4 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
On Tue, Dec 13, 2016 at 05:22:50PM +0300, Serge Semin wrote:
> +struct idt_89hpesx_dev {
> + u32 eesize;
> + bool eero;
> + u8 eeaddr;
> +
> + u8 inieecmd;
> + u8 inicsrcmd;
> + u8 iniccode;
> +
> + atomic_t csr;
Why is this an atomic_t and not just a "normal" u32 or u64? I don't see
the need for an atomic variable at all here, do you?
> +
> + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> + struct mutex smb_mtx;
> +
> + struct i2c_client *client;
> +
> + struct bin_attribute *ee_file;
> + struct dentry *csr_dir;
> + struct dentry *csr_file;
> +};
> +
> +static int idt_create_dbgfs_files(struct idt_89hpesx_dev *pdev)
> +{
> + struct device *dev = &pdev->client->dev;
> + struct i2c_client *cli = pdev->client;
> + char fname[CSRNAME_LEN];
> +
> + /* Initialize basic value of CSR debugfs dentries */
> + pdev->csr_dir = NULL;
> + pdev->csr_file = NULL;
> +
> + /* Return failure if root directory doesn't exist */
> + if (!csr_dbgdir) {
> + dev_dbg(dev, "No Debugfs root directory");
> + return -EINVAL;
> + }
If debugfs is not enabled, don't error out, just keep going, it should
never stop kernel code from running properly.
Also, this test isn't really doing what you think it is doing...
> + /* Create Debugfs directory for CSR file */
> + snprintf(fname, CSRNAME_LEN, "%d-%04hx", cli->adapter->nr, cli->addr);
> + pdev->csr_dir = debugfs_create_dir(fname, csr_dbgdir);
> + if (IS_ERR_OR_NULL(pdev->csr_dir)) {
> + dev_err(dev, "Failed to create CSR node directory");
> + return -EINVAL;
Again, don't do this, you really don't care if debugfs worked or not.
> + }
> +
> + /* Create Debugfs file for CSR read/write operations */
> + pdev->csr_file = debugfs_create_file(cli->name, 0600,
> + pdev->csr_dir, pdev, &csr_dbgfs_ops);
> + if (IS_ERR_OR_NULL(pdev->csr_file)) {
> + dev_err(dev, "Failed to create CSR dbgfs-node");
> + debugfs_remove_recursive(pdev->csr_dir);
> + return -EINVAL;
Same here, just create the file and move on.
> + }
> +
> + dev_dbg(dev, "Debugfs-files created");
You do know about ftrace, right? Please remove all of these
"trace-like" debugging lines, they aren't needed for anyone.
thanks,
greg k-h
Re: [PATCH v4 2/3] watchdog: introduce watchdog.open_timeout commandline parameter
On 2017-01-10 19:08, Guenter Roeck wrote:
On Mon, Jan 09, 2017 at 04:02:32PM +0100, Rasmus Villemoes wrote:
+static unsigned open_timeout;
+module_param(open_timeout, uint, 0644);
+
+static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
+{
+ if (!open_timeout)
+ return false;
+ return time_is_before_jiffies(data->open_deadline);
Doesn't this return true if the time is _before_ the open deadline ?
Should it be time_is_after_jiffies() ?
Yes, time_is_before_jiffies(foo) means foo < jiffies, and that is what
we want when we're querying whether we've passed the deadline.
+}
+
+static void watchdog_set_open_deadline(struct watchdog_core_data *data)
+{
+ data->open_deadline = jiffies + msecs_to_jiffies(open_timeout);
The open deadline as defined applies to the time after the device was
instantiated, not to the time since boot. Would it be better to make it
"time since boot" ?
I don't have a strong opinion on that, but two small things made me do
it this way: (1) In case a hardware watchdog is somehow hotplugged long
after boot and userspace is supposed to detect that and start feeding
it, it wouldn't make sense for the framework not to take care of it for
a while. (2) The open_timeout also applies to the case where the
userspace app gracefully closes the watchdog device (e.g. because it's
been instructed to restart to load a new configuration or whatnot) but
the hardware cannot be stopped. In that case, the framework also takes
over, and the same logic as after boot should apply - if the app fails
to come up again, the framework should not feed the dog indefinitely,
but OTOH it clearly doesn't make sense to have a boot-time based deadline.
Also, are you sure about using milli-seconds (instead of seconds) ?
I can not really imagine a situation where this would be needed
(especially and even more so in the context of using "time after
instantiating").
I went back and forth on this. I did milli-seconds because that should
cover more use cases. Yes, wanting an open timeout of .7 seconds with
1.0 seconds being unacceptable is unusual, but I know of some customers
with very strict requirements. Also, even if one cannot make userspace
start that fast, one can boot with a somewhat generous open_timeout and
then write 700 to /sys/module/watchdog/parameters/open_timeout for use
in case (2) above.
Thanks,
Rasmus
--
Rasmus Villemoes
Software Developer
Prevas A/S
Hedeager 1
DK-8200 Aarhus N
+45 51210274
rasmus.villem...@prevas.dk
www.prevas.dk
Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
Hello Cedric,
On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote:
> +/*
> + * In standard mode:
> + * SCL period = SCL high period = SCL low period = CCR * I2C parent clk
> period
> + *
> + * In fast mode:
> + * If Duty = 0; SCL high period = 1 * CCR * I2C parent clk period
> + * SCL low period = 2 * CCR * I2C parent clk period
> + * If Duty = 1; SCL high period = 9 * CCR * I2C parent clk period
> + * SCL low period = 16 * CCR * I2C parent clk period
s/ \*/ */ several times
> + * In order to reach 400 kHz with lower I2C parent clk frequencies we always
> set
> + * Duty = 1
> + *
> + * For both modes, we have CCR = SCL period * I2C parent clk frequency
> + * with scl_period = 5 microseconds in Standard mode and scl_period = 1
s/mode/Mode/
> + * microsecond in Fast Mode in order to satisfy scl_high and scl_low periods
> + * constraints defined by i2c bus specification
I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
somewhere?
> + */
> +static struct stm32f4_i2c_timings i2c_timings[] = {
> [...]
> +
> +/**
> + * stm32f4_i2c_hw_config() - Prepare I2C block
> + * @i2c_dev: Controller's private data
> + */
> +static int stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
> + int ret = 0;
> +
> + /* Disable I2C */
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
> +
> + ret = stm32f4_i2c_set_periph_clk_freq(i2c_dev);
> + if (ret)
> + return ret;
> +
> + stm32f4_i2c_set_rise_time(i2c_dev);
> +
> + stm32f4_i2c_set_speed_mode(i2c_dev);
> +
> + stm32f4_i2c_set_filter(i2c_dev);
> +
> + /* Enable I2C */
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
This function is called after a hw reset, so there should be no need to
use clr_bits and set_bits because the value read from hw should be
known.
> + return ret;
return 0;
> +}
> +
> +static int stm32f4_i2c_wait_free_bus(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 status;
> + int ret;
> +
> + ret = readl_relaxed_poll_timeout(i2c_dev->base + STM32F4_I2C_SR2,
> + status,
> + !(status & STM32F4_I2C_SR2_BUSY),
> + 10, 1000);
> + if (ret) {
> + dev_dbg(i2c_dev->dev, "bus not free\n");
> + ret = -EBUSY;
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * stm32f4_i2c_write_ byte() - Write a byte in the data register
> + * @i2c_dev: Controller's private data
> + * @byte: Data to write in the register
> + */
> +static void stm32f4_i2c_write_byte(struct stm32f4_i2c_dev *i2c_dev, u8 byte)
> +{
> + writel_relaxed(byte, i2c_dev->base + STM32F4_I2C_DR);
> +}
> +
> +/**
> + * stm32f4_i2c_write_msg() - Fill the data register in write mode
> + * @i2c_dev: Controller's private data
> + *
> + * This function fills the data register with I2C transfer buffer
> + */
> +static void stm32f4_i2c_write_msg(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> +
> + stm32f4_i2c_write_byte(i2c_dev, *msg->buf++);
> + msg->count--;
> +}
> +
> +static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + u32 rbuf;
> +
> + rbuf = readl_relaxed(i2c_dev->base + STM32F4_I2C_DR);
> + *msg->buf++ = rbuf & 0xff;
This is unnecessary. buf has an 8 bit wide type so
*msg->buf++ = rbuf;
has the same effect. (ISTR this is something I already pointed out
earlier?)
> + msg->count--;
> +}
> +
> +static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> +
> + stm32f4_i2c_disable_irq(i2c_dev);
> +
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + if (msg->stop)
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> + else
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> +
> + complete(&i2c_dev->complete);
> +}
> +
> +/**
> + * stm32f4_i2c_handle_write() - Handle FIFO empty interrupt in case of write
> + * @i2c_dev: Controller's private data
> + */
> +static void stm32f4_i2c_handle_write(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> +
> + if (msg->count) {
> + stm32f4_i2c_write_msg(i2c_dev);
> + if (!msg->count) {
> + /* Disable buffer interrupts for RXNE/TXE events */
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
> + }
> + } else {
> + stm32f4_i2c_terminate_xfer(i2c_dev);
Is stm32f4_i2c_terminate_xfer also called when arbitration is lost? If
yes, is it then
Re: [PATCH v7 1/5] dt-bindings: zte: add bindings document for zx2967 power domain controller
On Fri, Jan 06, 2017 at 05:16:00PM +0800, Baoyou Xie wrote: > This patch adds device tree bindings document for ZTE zx2967 > family power domain controller. > > Signed-off-by: Baoyou Xie Applied all, thanks.
[PATCH net] r8152: fix the sw rx checksum is unavailable
Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.
Note that the RTL_VER_01 only support sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index be41856..f3b48ad 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc
*rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+ if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4356,6 +4356,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
+ if (tp->version == RTL_VER_01) {
+ netdev->features &= ~NETIF_F_RXCSUM;
+ netdev->hw_features &= ~NETIF_F_RXCSUM;
+ }
+
netdev->ethtool_ops = &ops;
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
--
2.7.4
Re: [PATCH v2 3/5] ARM: davinci_all_defconfig: enable iio and ADS7950
On Tuesday 10 January 2017 09:13 PM, David Lechner wrote: > On 01/09/2017 06:29 AM, Sekhar Nori wrote: >> On Friday 06 January 2017 10:03 AM, David Lechner wrote: >>> This enables the iio subsystem and the TI ADS7950 driver. This is >>> used by >>> LEGO MINDSTORMS EV3, which has an ADS7957 chip. >> >> Can you add your sign-off? >> >>> --- >>> >>> The CONFIG_TI_ADS7950 driver is currently in iio/testing, so some >>> coordination >>> may be needed before picking up this patch. >>> >>> arch/arm/configs/davinci_all_defconfig | 7 +++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/arch/arm/configs/davinci_all_defconfig >>> b/arch/arm/configs/davinci_all_defconfig >>> index 2b1967a..a899876 100644 >>> --- a/arch/arm/configs/davinci_all_defconfig >>> +++ b/arch/arm/configs/davinci_all_defconfig >>> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y >>> CONFIG_MEMORY=y >>> CONFIG_TI_AEMIF=m >>> CONFIG_DA8XX_DDRCTL=y >>> +CONFIG_IIO=m >>> +CONFIG_IIO_BUFFER_CB=m >>> +CONFIG_IIO_SW_DEVICE=m >>> +CONFIG_IIO_SW_TRIGGER=m >> >>> +CONFIG_TI_ADS7950=m >> >> Can you separate this from rest of the patch. I would like to enable >> this option only after I can find the symbol in linux-next. > > Will resend without CONFIG_TI_ADS7950 > >> >>> +CONFIG_IIO_HRTIMER_TRIGGER=m >>> +CONFIG_IIO_SYSFS_TRIGGER=m >> >> Need CONFIG_IIO_TRIGGER=y also for these two options to take effect. > > CONFIG_IIO_TRIGGER is selected by IIO_TRIGGERED_BUFFER [=m] && IIO [=m] > && IIO_BUFFER [=y], so save_defconfig does not pick it up. I do remember I did not see these two modules did not get enabled in .config after 'make davinci_all_defconfig'. Will check what I may have missed. Thanks, Sekhar
Re: [PATCH v2 4/5] firmware: add SmPL report for custom fallback mechanism
On Fri, Dec 16, 2016 at 03:10:37AM -0800, Luis R. Rodriguez wrote: > Even though most distributions today disable the fallback mechanism > by default we've determined that we cannot remove them from the kernel. > This is not well understood so document the reason and logic behind that. Well, the biggest reason is that some distros still rely on this. I've seen new products being made that rely on it, so let's please stop treating it like it is somehow a "deprecated" interface. We can't get rid of it, so we just have to live with it, for forever, sorry. greg k-h
[PATCH 4/4] arm: dts: mt2701: Add auxadc device node.
From: Zhiyong Tao
Add auxadc device node for MT2701.
Signed-off-by: Zhiyong Tao
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 1182c43..4f52019 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -208,6 +208,15 @@
<0 0x10216000 0 0x2000>;
};
+ auxadc: adc@11001000 {
+ compatible = "mediatek,mt2701-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2701-uart",
"mediatek,mt6577-uart";
--
1.9.1
[PATCH 1/4] arm: dts: mt2701: Add spi device node
From: Leilk Liu
Add spi device node for MT2701.
Signed-off-by: Leilk Liu
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..eb4c6fd 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,45 @@
status = "disabled";
};
+ spi0: spi@1100a000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1100a000 0 0x100>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+<&topckgen CLK_TOP_SPI0_SEL>,
+<&pericfg CLK_PERI_SPI0>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi1: spi@11016000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11016000 0 0x100>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+<&topckgen CLK_TOP_SPI1_SEL>,
+<&pericfg CLK_PERI_SPI1>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi2: spi@11017000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11017000 0 0x1000>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+<&topckgen CLK_TOP_SPI2_SEL>,
+<&pericfg CLK_PERI_SPI2>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
mmsys: syscon@1400 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
--
1.9.1
[PATCH 2/4] arm: dts: mt2701: Add iommu/smi device node
From: Honghui Zhang
Add the device node of iommu and smi for MT2701.
Signed-off-by: Honghui Zhang
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index eb4c6fd..87be52c 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "skeleton64.dtsi"
#include "mt2701-pinfunc.h"
@@ -161,6 +162,16 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi@1000c000 {
+ compatible = "mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+<&mmsys CLK_MM_SMI_COMMON>,
+<&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt2701-sysirq",
"mediatek,mt6577-sysirq";
@@ -170,6 +181,16 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: mmsys_iommu@10205000 {
+ compatible = "mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb0 &larb1 &larb2>;
+ #iommu-cells = <1>;
+ };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt2701-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
@@ -272,18 +293,51 @@
#clock-cells = <1>;
};
+ larb0: larb@1401 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x1401 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <0>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+<&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
imgsys: syscon@1500 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
#clock-cells = <1>;
};
+ larb2: larb@15001000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x15001000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <2>;
+ clocks = <&imgsys CLK_IMG_SMI_COMM>,
+<&imgsys CLK_IMG_SMI_COMM>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
#clock-cells = <1>;
};
+ larb1: larb@1601 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x1601 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <1>;
+ clocks = <&vdecsys CLK_VDEC_CKGEN>,
+<&vdecsys CLK_VDEC_LARB>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
+ };
+
hifsys: syscon@1a00 {
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a00 0 0x1000>;
--
1.9.1
[PATCH 0/4] Add spi/iommu/nand/auxadc DT nodes for Mediatek MT2701
This patch series base on v4.10-rc2, include MT2701 spi/iommu/nand/auxadc DT nodes. Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1]. [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html Honghui Zhang (1): arm: dts: mt2701: Add iommu/smi device node Leilk Liu (1): arm: dts: mt2701: Add spi device node Xiaolei Li (1): arm: dts: mt2701: Add nand device node Zhiyong Tao (1): arm: dts: mt2701: Add auxadc device node. arch/arm/boot/dts/mt2701.dtsi | 124 ++ 1 file changed, 124 insertions(+) -- 1.9.1
Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Hoegeun Kwon
>> Tested-by: Chanwoo Choi
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&dsi {
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <&ldo27_reg>;
>> +vci-supply = <&ldo28_reg>;
>> +reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.
Reasonable to remove te-gpios property but this change would make MIPI-DSI
driver probing to be failed so MIPI-DSI driver should be fixed together.
Thanks.
>
> Regards
> Andrzej
>> +};
>> +};
>> +
>> &hsi2c_9 {
>> status = "okay";
>>
>
>
>
>
Re: Problem on SCTP
yes. whenever the INIT packet send to 192.168.206.65, it will forward to 192.168.206.66. My question is when this packet arrive to 192.168.206.66, why LKSCTP never pass to user level. On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman wrote: > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote: >> Packet received (From client) >> == >> >> No. Time SourceSPort >> Destination Protocol DPort Length Info >> DSCP >> 1 2017-01-06 08:52:49.662142192.168.206.8350001 >> 192.168.206.65SCTP 3868 98 INIT >> CS0 >> >> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) >> Encapsulation type: Ethernet (1) >> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard >> Time >> [Time shift for this packet: 0.0 seconds] >> Epoch Time: 1483692769.662142000 seconds >> [Time delta from previous captured frame: 0.0 seconds] >> [Time delta from previous displayed frame: 0.0 seconds] >> [Time since reference or first frame: 0.0 seconds] >> Frame Number: 1 >> Frame Length: 98 bytes (784 bits) >> Capture Length: 98 bytes (784 bits) >> [Frame is marked: False] >> [Frame is ignored: False] >> [Protocols in frame: eth:ethertype:ip:sctp] >> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst: >> Vmware_81:41:6b (00:50:56:81:41:6b) >> Destination: Vmware_81:41:6b (00:50:56:81:41:6b) >> Address: Vmware_81:41:6b (00:50:56:81:41:6b) >> ..0. = LG bit: Globally unique >> address (factory default) >> ...0 = IG bit: Individual address (unicast) >> Source: RealtekU_54:81:87 (52:54:00:54:81:87) >> Address: RealtekU_54:81:87 (52:54:00:54:81:87) >> ..1. = LG bit: Locally administered >> address (this is NOT the factory default) >> ...0 = IG bit: Individual address (unicast) >> Type: IPv4 (0x0800) >> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65 >> 0100 = Version: 4 >> 0101 = Header Length: 20 bytes (5) >> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0)) >> 00.. = Differentiated Services Codepoint: Default (0) >> ..10 = Explicit Congestion Notification: ECN-Capable >> Transport codepoint '10' (2) >> Total Length: 84 >> Identification: 0x (0) >> Flags: 0x02 (Don't Fragment) >> 0... = Reserved bit: Not set >> .1.. = Don't fragment: Set >> ..0. = More fragments: Not set >> Fragment offset: 0 >> Time to live: 64 >> Protocol: SCTP (132) >> Header checksum: 0x1c3e [validation disabled] >> [Good: False] >> [Bad: False] >> Source: 192.168.206.83 >> Destination: 192.168.206.65 >> [Source GeoIP: Unknown] >> [Destination GeoIP: Unknown] >> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst >> Port: 3868 (3868) >> Source port: 50001 >> Destination port: 3868 >> Verification tag: 0x >> [Assocation index: 0] >> Checksum: 0xbaea49e5 (not verified) >> INIT chunk (Outbound streams: 3000, inbound streams: 3000) >> Chunk type: INIT (1) >> 0... = Bit: Stop processing of the packet >> .0.. = Bit: Do not report >> Chunk flags: 0x00 >> Chunk length: 52 >> Initiate tag: 0xe79f40cb >> Advertised receiver window credit (a_rwnd): 62464 >> Number of outbound streams: 3000 >> Number of inbound streams: 3000 >> Initial TSN: 176990880 >> IPv4 address parameter (Address: 192.168.206.83) >> Parameter type: IPv4 address (0x0005) >> 0... = Bit: Stop processing of chunk >> .0.. = Bit: Do not report >> Parameter length: 8 >> IP Version 4 address: 192.168.206.83 >> IPv4 address parameter (Address: 192.168.1.83) >> Parameter type: IPv4 address (0x0005) >> 0... = Bit: Stop processing of chunk >> .0.. = Bit: Do not report >> Parameter length: 8 >> IP Version 4 address: 192.168.1.83 >> Supported address types parameter (Supported types: IPv6, IPv4) >> Parameter type: Supported address types (0x000c) >> 0... = Bit: Stop processing of chunk >> .0.. = Bit: Do not report >> Parameter length: 8 >> Supported address type: IPv6 address (6) >> Supported address type: IPv4 address (5) >> ECN parameter >> Parameter type: ECN (0x8000) >> 1... ..
[PATCH 3/4] arm: dts: mt2701: Add nand device node
From: Xiaolei Li
Add mt2701 nand device node, include nfi and bch ecc.
Signed-off-by: Xiaolei Li
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 87be52c..1182c43 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -261,6 +261,28 @@
status = "disabled";
};
+ nandc: nfi@1100d000 {
+ compatible = "mediatek,mt2701-nfc";
+ reg = <0 0x1100d000 0 0x1000>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_NFI>,
+<&pericfg CLK_PERI_NFI_PAD>;
+ clock-names = "nfi_clk", "pad_clk";
+ status = "disabled";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ bch: ecc@1100e000 {
+ compatible = "mediatek,mt2701-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_NFI_ECC>;
+ clock-names = "nfiecc_clk";
+ status = "disabled";
+ };
+
spi1: spi@11016000 {
compatible = "mediatek,mt2701-spi";
#address-cells = <1>;
--
1.9.1
Re: [PATCH 32/62] watchdog: meson_gxbb_wdt: Convert to use device managed functions and other improvements
On 01/11/2017 01:44 AM, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Check return value from clk_prepare_enable()
> - Replace 'val = e; return val;' with 'return e;'
> - Replace 'if (e) return e; return 0;' with 'return e;'
> - Drop assignments to otherwise unused variables
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Drop remove function
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Carlo Caione
> Cc: Kevin Hilman
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/meson_gxbb_wdt.c | 38 ++
> 1 file changed, 10 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/watchdog/meson_gxbb_wdt.c
> b/drivers/watchdog/meson_gxbb_wdt.c
> index 45d47664a00a..913d8a644460 100644
> --- a/drivers/watchdog/meson_gxbb_wdt.c
> +++ b/drivers/watchdog/meson_gxbb_wdt.c
> @@ -203,7 +203,14 @@ static int meson_gxbb_wdt_probe(struct platform_device
> *pdev)
> if (IS_ERR(data->clk))
> return PTR_ERR(data->clk);
>
> - clk_prepare_enable(data->clk);
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> + ret = devm_add_action_or_reset(&pdev->dev,
> +(void(*)(void *))clk_disable_unprepare,
> +data->clk);
> + if (ret)
> + return ret;
>
> platform_set_drvdata(pdev, data);
>
> @@ -224,37 +231,12 @@ static int meson_gxbb_wdt_probe(struct platform_device
> *pdev)
>
> meson_gxbb_wdt_set_timeout(&data->wdt_dev, data->wdt_dev.timeout);
>
> - ret = watchdog_register_device(&data->wdt_dev);
> - if (ret) {
> - clk_disable_unprepare(data->clk);
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> -static int meson_gxbb_wdt_remove(struct platform_device *pdev)
> -{
> - struct meson_gxbb_wdt *data = platform_get_drvdata(pdev);
> -
> - watchdog_unregister_device(&data->wdt_dev);
> -
> - clk_disable_unprepare(data->clk);
> -
> - return 0;
> -}
> -
> -static void meson_gxbb_wdt_shutdown(struct platform_device *pdev)
> -{
> - struct meson_gxbb_wdt *data = platform_get_drvdata(pdev);
> -
> - meson_gxbb_wdt_stop(&data->wdt_dev);
> + watchdog_stop_on_reboot(&data->wdt_dev);
> + return devm_watchdog_register_device(&pdev->dev, &data->wdt_dev);
> }
>
> static struct platform_driver meson_gxbb_wdt_driver = {
> .probe = meson_gxbb_wdt_probe,
> - .remove = meson_gxbb_wdt_remove,
> - .shutdown = meson_gxbb_wdt_shutdown,
> .driver = {
> .name = "meson-gxbb-wdt",
> .pm = &meson_gxbb_wdt_pm_ops,
>
Was on my todo list, glad you did this !
Acked-by: Neil Armstrong
Re: [PATCH] selftests/futex: Fix makefile dependencies
On Wed, Jan 11, 2017 at 12:07:55AM -0800, Darren Hart wrote: > On Wed, Jan 11, 2017 at 01:37:19PM +0900, Stafford Horne wrote: > > On Tue, Jan 10, 2017 at 02:17:18PM -0800, Darren Hart wrote: > > > On Tue, Jan 10, 2017 at 02:10:42PM -0800, Darren Hart wrote: > > > > On Fri, Jan 06, 2017 at 01:18:39PM +0900, Stafford Horne wrote: > > > > > I am working on doing selftests for openrisc and found issues with the > > > > > futex test is not building after changes to the tests source. > > > > > > > > > > This issue is that the TARGETS variable used in the futex Makefile is > > > > > also used by the selftests Makefile, so when building from toplevel > > > > > the > > > > > TARGETS variable is clobbered and nothing gets built. Changed the > > > > > variable name to get around that. > > > > > > > > > > Also, the futex makefile did not contain dependencies for all headers, > > > > > so if we make changes to logging.h rebuild will not happen. Add > > > > > headers > > > > > to fix it up. > > > > > > > > > > Signed-off-by: Stafford Horne > > > > > > > > Thanks for catching this and the fix. > > > > > > > > +Shuah Khan > > > > > > > > Note: This appears also to be a problem for intel_pstate/Makefile > > > > > > Or, it would be if intel_pstate was listed in selftests/Makefile :-) > > > > Right, thanks for having a look. I actually have a small patch to also > > add to logging.h. If you have not already fixed the > > intel_pstate test I'll send them all together. > > Please do, thanks! Hello, Actually I just had a look at Shuah's linux-kselftest repo on kernel.org. It looks like Bamvor Jian has actually fixed a lot of these issues on the next branch. I will see what is missing if anything. -Stafford
Re: [PATCH 0/5 v3] adv7511 EDID probing improvements
Hi, On 01/04/2017 01:11 AM, John Stultz wrote: Hope everyone had a good newyears! Wanted to re-send out v3 of this patch set improving the EDID probing on the adv7511 used on HiKey, for consideration for merging for 4.11 The first three patches are fixups that are hopefully straight forward, integrating feedback I got from Laurant. The last two patches try to clean up and resue code, which as a side effect avoids an issue I'm seeing where something is going wrong with the regmap cache state for the ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in i2c_transfer errors if we don't do the regcache_sync/_mark_dirty() calls. I suspect there might be a better solution there, but have not gotten any other suggestions so I wanted to go ahead and submit these. Thoughts and feedback would be appreciated! Tested on DB410c on 4.10-rc3. Works well for me. Thanks, Archit thanks -john New in v3: * Addressed naming improvements and drm_kms_helper_hotplug_event usage corrections as suggested by Laurent. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org Archit Taneja (1): drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection John Stultz (4): drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 62 +++- 2 files changed, 44 insertions(+), 20 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] doc: add note on usleep_range range
On Tue, Jan 10, 2017 at 10:25:29PM +0100, Pavel Machek wrote:
> Hi!
>
> > > "to have zero jitter" at least. I believe it is "does not".
> > >
> > > I don't see how atomic vs. non-atomic context makes difference. There
> > > are sources of jitter that affect atomic context...
> >
> > The relevance is that while there is jitter in atomic context it can
> > be quite small (depending on your hardware and the specifics of system
> > config) but in non-atomic context the jitter is so large that it
> > makes no relevant difference if you give usleep_range slack of a few
> > microseconds.
>
> I disagree here. Even in non-atomic code, you'll get _no_ jitter most
> of the time. If you care about average case, small slack may still
> make sense.
yes - thats what the results say - the mean does not differe significantly
so if you care about average case - it makes no difference.
>
> > > > + less than 50 microseconds probably is only
> > > > preventing
> > > > + timer subsystem optimization but providing no
> > > > benefit.
> > >
> > > And I don't trust you here. _If_ it prevents timer optimalization,
> > > _then_ it provides benefit, at least in the average case.
> > >
> > here is the data:
> >
> > System: Intel Core i7 CPU 920 @ 2.67GHz Ocotocore
> > OS: Debian 8.1 (but thats quite irrelevant)
> > Kernel: 4.10-rc2 (localversion-next next-20170106)
> > config: x86_64_defconfig (Voluntary | Preempt)
> >
> > Test-setup - poped this into akernel module and just
> > brute force load/unload it in a loop - not very elegant
> > but it does the job.
> >
> > static int __init usleep_test_init(void)
> > {
> > ktime_t now,last;
> > unsigned long min,max;
> > min = 200;
> > max = 250;
> > last = ktime_get();
> > usleep_range(min, max);
> > now = ktime_get();
> > printk("%llu\n", ktime_to_ns(now)-ktime_to_ns(last));
> > return 0;
> > }
> >
> > Results:
> >
> > usleep_range() 5000 samples - idle system
> > 100,100 200,200 190,200
> > Min. :188481 Min. :201917 Min. :197793
> > 1st Qu.:207062 1st Qu.:207057 1st Qu.:207051
> > Median :207139 Median :207133 Median :207133
> > Mean :207254 Mean :207233 Mean :207244
> > 3rd Qu.:207341 erd Qu.:207262 3rd Qu.:207610
> > Max. :225340 Max. :214222 Max. :214885
> >
> > 100,200 to 200,200 is maybe relevant impact for
> > some systems with respect to the outliers, but
> > mean and median are almost the same, for
> > 190,200 to 200,200 there is statistically no
> > significant difference with respect to performance
> > Note that the timestamp before and after also has
> > jitter - so only part of the jitter can be attributed
> > to usleep_range() it self. But idle system optimization
> > is not that interesting for most systems.
>
> I disagree here. Most of systems are idle, most of the time. You say
> that basically everyone should provide 50 usec of slack... So I guess
> I'd like to see comparisons for 200,200 and 200,250 (and perhaps also
> 200,500 or something).
>
I did not say that everyone should use 50us of slack - rather the statement
was "makes no relevant difference if you give usleep_range slack of a few
microseconds." and that min==max makes *no* sense and that providing
even just small slack (in 10s of us range) makes a relevant difference
at system level.
Regarding idle system - the statement is that optimizing for idle
system makes no sense - not that idle system is rare. In an idle
system (as you can see in the above table) there is *no* diffeence
in the mean values - just to highligt this
100,200 200,200 190,200
Mean :207254 Mean :207233 Mean :207244
so for an idle system it makes very little difference (and I still doubt
that anyone could find this sub promille difference by testing at the
application level) - conversely for a loaded system the whole issue is
irrelevant as the jitter is completely dominated from system activity and
the usleep_range() parameters have more or less no impact.
In summary:
idle-system: 10s of us difference between min/max has if at all
marginal impact
loaded-system: no negative impact at all
but the system as a whole can profit from reducing the number of hires
timersit needs to hanle. Thus I still see no reason to not consider
usleep_range(min,max) with min==max as a mistake.
But to put a numer on it - if max-min < 10us I would consider it wrong
I think that basically never makes sense for any non RT (PREEMT-RT that
is) thread.
thx!
hofrat
Re: Dell XPS13 does not suspend with Linux 4.10-rc3
Dear Linux folks,
On 01/10/17 23:24, Jan Niehusmann wrote:
On Tue, Jan 10, 2017 at 09:43:31PM +0100, Jan Niehusmann wrote:
And I bisected the issue to commit 7279b238ba, "mei: send OS type to the
FW"
Indeed, just disabling the FIXUP implemented by that commit fixes
suspend for me, with 4.10.0-rc3. Btw, this is on a Thinkpad x201s.
(For the addressees newly added to cc, it seems like the mentioned
commit breaks suspend to ram on Dell XPS13 and Thinkpad x201s)
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -406,3 +406,3 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_WD, mei_wd),
- MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+// MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
};
I don't know what this may break, as the description of 7279b23 just
says:
"This workaround was added to support other broken OS and we need to
follow here."
Unless there is a better justification, I think the commit should be
reverted, for now.
Somebody else already created the bug 192051 in the Linux Kernel Bug
Tracker [1].
Kind regards,
Paul
[1] https://bugzilla.kernel.org/show_bug.cgi?id=192051
"[Bug 192051] [bisected] No hibernation/suspend/shutdown after
commit 7279b238badec09efd0545293e64c21feee97f73"
Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks
On Wed, 11 Jan 2017, Joe Perches wrote:
> Make these files symlinks to the .rst equivalents
If we're going to do this (and I really don't mind either way), then
please add
Fixes: 08a9a8d44c1c ("doc: re-add CodingStyle and SubmittingPatches")
and queue to v4.10-rc.
BR,
Jani.
>
> Signed-off-by: Joe Perches
> ---
> Documentation/CodingStyle | 2 +-
> Documentation/SubmittingPatches | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> mode change 100644 => 12 Documentation/CodingStyle
> mode change 100644 => 12 Documentation/SubmittingPatches
>
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> deleted file mode 100644
> index 320983ca114e..
> --- a/Documentation/CodingStyle
> +++ /dev/null
> @@ -1 +0,0 @@
> -This file has moved to process/coding-style.rst
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> new file mode 12
> index ..5aacf7ea935a
> --- /dev/null
> +++ b/Documentation/CodingStyle
> @@ -0,0 +1 @@
> +./process/coding-style.rst
> \ No newline at end of file
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> deleted file mode 100644
> index 81455705e4a6..
> --- a/Documentation/SubmittingPatches
> +++ /dev/null
> @@ -1 +0,0 @@
> -This file has moved to process/submitting-patches.rst
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> new file mode 12
> index ..5ca6e8ba3682
> --- /dev/null
> +++ b/Documentation/SubmittingPatches
> @@ -0,0 +1 @@
> +./process/submitting-patches.rst
> \ No newline at end of file
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH] clk: qcom: gdsc: Fix handling of hw control enable/disable
Hi Sricharan,
On 01/10/2017 09:29 PM, Sricharan wrote:
> Hi stan,
>
>> -Original Message-
>> From: linux-arm-msm-ow...@vger.kernel.org
>> [mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Stanimir Varbanov
>> Sent: Tuesday, January 10, 2017 10:14 PM
>> To: Rajendra Nayak ; sb...@codeaurora.org;
>> mturque...@baylibre.com
>> Cc: linux-...@vger.kernel.org; linux-arm-...@vger.kernel.org;
>> linux-kernel@vger.kernel.org; sricha...@codeaurora.org
>> Subject: Re: [PATCH] clk: qcom: gdsc: Fix handling of hw control
>> enable/disable
>>
>> Hi Rajendra,
>>
>> On 01/10/2017 07:54 AM, Rajendra Nayak wrote:
>>> Once a gdsc is brought in and out of HW control, there is a
>>> power down and up cycle which can take upto 1us. Polling on
>>> the gdsc status immediately after the hw control enable/disable
>>> can mislead software/firmware to belive the gdsc is already either on
>>> or off, while its yet to complete the power cycle.
>>> To avoid this add a 1us delay post a enable/disable of HW control
>>> mode.
>>>
>>> Also after the HW control mode is disabled, poll on the status to
>>> check gdsc status reflects its 'on' before force disabling it
>>> in software.
>>>
>>> Reported-by: Stanimir Varbanov
>>> Signed-off-by: Rajendra Nayak
>>> ---
>>>
>>> Stan,
>>> If there was a specific issue you saw with venus because of the missing
>>> delay and poll, can you check if this fixes any of that.
>>
>> Something more about the issue.
>>
>> I had re-designed venus driver on three platform drivers venus-core,
>> venus-dec and venus-enc in order to be able to control those three
>> power-domains (VENUS_GDSC, VENUS_CORE0_GDSC and VENUS_CORE1_GDSC).
>>
>> After that I abstracted MMAGIC hw on a separate mmagic driver. This
>> driver just controls mmagic clocks and GDSC in its runtime_suspend and
>> runtime_resume methods.
>>
>> The DT nodes looks like:
>>
>> mmagic_video {
>> compatible = "qcom,msm8996-mmagic";
>> clocks = <&rpmcc MSM8996_RPM_SMD_MMAXI_CLK>,
>> <&mmcc MMSS_MMAGIC_AHB_CLK>,
>> <&mmcc MMSS_MMAGIC_CFG_AHB_CLK>,
>> <&mmcc MMAGIC_VIDEO_NOC_CFG_AHB_CLK>,
>> <&mmcc MMSS_MMAGIC_MAXI_CLK>,
>> <&mmcc MMAGIC_VIDEO_AXI_CLK>,
>> <&mmcc SMMU_VIDEO_AHB_CLK>,
>> <&mmcc SMMU_VIDEO_AXI_CLK>;
>> power-domains = <&mmcc MMAGIC_VIDEO_GDSC>;
>>
>> video-codec {
>> compatible = "qcom,msm8996-venus";
>> clocks = <&mmcc VIDEO_CORE_CLK>,
>> <&mmcc VIDEO_AHB_CLK>,
>> <&mmcc VIDEO_AXI_CLK>,
>> <&mmcc VIDEO_MAXI_CLK>;
>> power-domains = <&mmcc VENUS_GDSC>;
>> ...
>>
>> video-decoder {
>> compatible = "venus-decoder";
>> clocks = "subcore0";
>> clock-names = <&mmcc VIDEO_SUBCORE0_CLK>;
>> power-domains = <&mmcc VENUS_CORE0_GDSC>;
>> };
>>
>> video-encoder {
>> compatible = "venus-encoder";
>> clocks = "subcore1";
>> clock-names = <&mmcc VIDEO_SUBCORE1_CLK>;
>> power-domains = <&mmcc VENUS_CORE1_GDSC>;
>> };
>> };
>> };
>>
>> Note that mmagic_video is a parent dt node for smmu_video DT node so
>> that clocks and mmagic_video gdsc will be enabled once smmu driver is
>> instantiated by venus-core diriver.
>>
>
> mmagic_video is a parent DT for smmu_video ? , so there are no clocks
> populated for the smmu node as such ?
Yes, I completely disabled runtime pm in the arm-smmu driver.
>
>> Now when video-dec driver calls pm_runtime_get_sync() the sequence of
>> enabling is:
>>
>> MMAGIC_VIDEO_GDSC -> MMAGIC clocks and SMMU clocks -> VENUS_GDSC ->
>> VIDEO clocks -> VENUS_CORE0_GDSC -> VIDEO subcore0 clock
>>
>> When video-dec platform driver calls pm_runtime_put_sync() we should
>> disabling of GDSC and clocks in the reversed oder.
>>
>> The issue comes when I have ran video decoder, the decoder hw finish
>> stream decoding and we want to suspend venus core. The issue is that
>> when I start disabling SMMU_VIDEO_AXI_CLK and/or MMAGIC_VIDEO_AXI_CLK
>> the system reboots.
>>
>> I have added a delay (200ms) before disabling mmagic clocks and then
>> everything is fine again.
>>
>> Any idea?
>>
>
> Can you share me a branch, i can have a quick check with a t32
> if there is any crash logged in the TZ buffer when the system reboots.
I can share a branch but you will need my initramfs too.
I don't think it is tz related, most probably it is MMAGIC sequence
issue or something in GDSC/MMCC.
--
regards,
Stan
Re: [PATCH 3/9] dma: Add dma_virt_ops
> +lib-$(CONFIG_HAS_DMA) += dma-virt.o There probably should be a config option for it for two reasons: - do not bloat kernels that don't need it. - the feature can only work for 32-bit architectures or for 64-bit architectures that set ARCH_DMA_ADDR_T_64BIT… Altenatiely this option would have to force ARCH_DMA_ADDR_T_64BIT when not yet set for 64-bit architectures. And yes, this is currently broken already for, but we'd better fix it.
Re: [patch v2] mm, thp: add new defer+madvise defrag option
On Tue, Jan 10, 2017 at 04:15:27PM -0800, David Rientjes wrote: > There is no thp defrag option that currently allows MADV_HUGEPAGE regions > to do direct compaction and reclaim while all other thp allocations simply > trigger kswapd and kcompactd in the background and fail immediately. > > The "defer" setting simply triggers background reclaim and compaction for > all regions, regardless of MADV_HUGEPAGE, which makes it unusable for our > userspace where MADV_HUGEPAGE is being used to indicate the application is > willing to wait for work for thp memory to be available. > > The "madvise" setting will do direct compaction and reclaim for these > MADV_HUGEPAGE regions, but does not trigger kswapd and kcompactd in the > background for anybody else. > > For reasonable usage, there needs to be a mesh between the two options. > This patch introduces a fifth mode, "defer+madvise", that will do direct > reclaim and compaction for MADV_HUGEPAGE regions and trigger background > reclaim and compaction for everybody else so that hugepages may be > available in the near future. > > A proposal to allow direct reclaim and compaction for MADV_HUGEPAGE > regions as part of the "defer" mode, making it a very powerful setting and > avoids breaking userspace, was offered: > http://marc.info/?t=14823661273. This additional mode is a > compromise. > > A second proposal to allow both "defer" and "madvise" to be selected at > the same time was also offered: http://marc.info/?t=14835734531. > This is possible, but there was a concern that it might break existing > userspaces the parse the output of the defrag mode, so the fifth option > was introduced instead. > > This patch also cleans up the helper function for storing to "enabled" > and "defrag" since the former supports three modes while the latter > supports five and triple_flag_store() was getting unnecessarily messy. > > Signed-off-by: David Rientjes > --- > v2: uses new naming suggested by Vlastimil > (defer+madvise order looks better in > "... defer defer+madvise madvise ...") > > v1 was acked by Mel, and it probably could have been preserved but it was > removed in case there is an issue with the name change. > There isn't Acked-by: Mel Gorman Thanks. -- Mel Gorman SUSE Labs
[PATCH 1/4] platform/x86: fujitsu-laptop: decrease indentation in acpi_fujitsu_hotkey_notify()
acpi_fujitsu_hotkey_notify() is pretty deeply nested, which hurts
readability. Strip off one level of indentation by returning early when
the event code supplied as argument is not ACPI_FUJITSU_NOTIFY_CODE1.
Signed-off-by: Michał Kępień
---
Changes introduced by this patch are best viewed when whitespace changes
are ignored.
drivers/platform/x86/fujitsu-laptop.c | 152 +-
1 file changed, 75 insertions(+), 77 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index b725a907a91f..c2022f8af51b 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1039,98 +1039,96 @@ static void acpi_fujitsu_hotkey_notify(struct
acpi_device *device, u32 event)
input = fujitsu_hotkey->input;
+ if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
+ keycode = KEY_UNKNOWN;
+ vdbg_printk(FUJLAPTOP_DBG_WARN,
+ "Unsupported event [0x%x]\n", event);
+ input_report_key(input, keycode, 1);
+ input_sync(input);
+ input_report_key(input, keycode, 0);
+ input_sync(input);
+ return;
+ }
+
if (fujitsu_hotkey->rfkill_supported)
fujitsu_hotkey->rfkill_state =
call_fext_func(FUNC_RFKILL, 0x4, 0x0, 0x0);
- switch (event) {
- case ACPI_FUJITSU_NOTIFY_CODE1:
- i = 0;
- while ((irb =
- call_fext_func(FUNC_BUTTONS, 0x1, 0x0, 0x0)) != 0
- && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) {
- switch (irb & 0x4ff) {
- case KEY1_CODE:
- keycode = fujitsu->keycode1;
- break;
- case KEY2_CODE:
- keycode = fujitsu->keycode2;
- break;
- case KEY3_CODE:
- keycode = fujitsu->keycode3;
- break;
- case KEY4_CODE:
- keycode = fujitsu->keycode4;
- break;
- case KEY5_CODE:
- keycode = fujitsu->keycode5;
- break;
- case 0:
- keycode = 0;
- break;
- default:
+ i = 0;
+ while ((irb =
+ call_fext_func(FUNC_BUTTONS, 0x1, 0x0, 0x0)) != 0
+ && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) {
+ switch (irb & 0x4ff) {
+ case KEY1_CODE:
+ keycode = fujitsu->keycode1;
+ break;
+ case KEY2_CODE:
+ keycode = fujitsu->keycode2;
+ break;
+ case KEY3_CODE:
+ keycode = fujitsu->keycode3;
+ break;
+ case KEY4_CODE:
+ keycode = fujitsu->keycode4;
+ break;
+ case KEY5_CODE:
+ keycode = fujitsu->keycode5;
+ break;
+ case 0:
+ keycode = 0;
+ break;
+ default:
+ vdbg_printk(FUJLAPTOP_DBG_WARN,
+ "Unknown GIRB result [%x]\n", irb);
+ keycode = -1;
+ break;
+ }
+ if (keycode > 0) {
+ vdbg_printk(FUJLAPTOP_DBG_TRACE,
+ "Push keycode into ringbuffer [%d]\n",
+ keycode);
+ status = kfifo_in_locked(&fujitsu_hotkey->fifo,
+ (unsigned char *)&keycode,
+ sizeof(keycode),
+ &fujitsu_hotkey->fifo_lock);
+ if (status != sizeof(keycode)) {
vdbg_printk(FUJLAPTOP_DBG_WARN,
- "Unknown GIRB result [%x]\n", irb);
- keycode = -1;
- break;
+ "Could not push keycode [0x%x]\n",
+ keycode);
+ } else {
+ input_report_key(input, keycode, 1);
+ input_sync(input);
}
- if (keycode > 0) {
+ } else if (keycode == 0) {
+ while ((status =
+ kfifo_out_locked(
+&fujitsu_hotkey->fifo,
+
[PATCH 4/4] platform/x86: fujitsu-laptop: make hotkey handling functions more similar
Make two minor tweaks to acpi_fujitsu_hotkey_press() to make it more
similar to acpi_fujitsu_hotkey_release():
* call vdbg_printk() after reporting the input event,
* return immediately when kfifo_in_locked() fails.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 06653a8594ed..96f8163d5002 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1035,18 +1035,18 @@ static void acpi_fujitsu_hotkey_press(int keycode)
struct input_dev *input = fujitsu_hotkey->input;
int status;
- vdbg_printk(FUJLAPTOP_DBG_TRACE,
- "Push keycode into ringbuffer [%d]\n", keycode);
status = kfifo_in_locked(&fujitsu_hotkey->fifo,
(unsigned char *)&keycode, sizeof(keycode),
&fujitsu_hotkey->fifo_lock);
if (status != sizeof(keycode)) {
vdbg_printk(FUJLAPTOP_DBG_WARN,
"Could not push keycode [0x%x]\n", keycode);
- } else {
- input_report_key(input, keycode, 1);
- input_sync(input);
+ return;
}
+ input_report_key(input, keycode, 1);
+ input_sync(input);
+ vdbg_printk(FUJLAPTOP_DBG_TRACE,
+ "Push keycode into ringbuffer [%d]\n", keycode);
}
static void acpi_fujitsu_hotkey_release(void)
--
2.11.0
[PATCH 3/4] platform/x86: fujitsu-laptop: break up complex loop condition
The loop condition in acpi_fujitsu_hotkey_release() includes an
assignment, a four-argument function call and a comparison, making it
hard to read. Separate the assignment from the comparison to improve
readability.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index e57d3724d2ce..06653a8594ed 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1054,11 +1054,13 @@ static void acpi_fujitsu_hotkey_release(void)
struct input_dev *input = fujitsu_hotkey->input;
int keycode, status;
- while ((status = kfifo_out_locked(&fujitsu_hotkey->fifo,
+ while (true) {
+ status = kfifo_out_locked(&fujitsu_hotkey->fifo,
(unsigned char *)&keycode,
sizeof(keycode),
- &fujitsu_hotkey->fifo_lock))
- == sizeof(keycode)) {
+ &fujitsu_hotkey->fifo_lock);
+ if (status != sizeof(keycode))
+ return;
input_report_key(input, keycode, 0);
input_sync(input);
vdbg_printk(FUJLAPTOP_DBG_TRACE,
--
2.11.0
[PATCH 0/4] fujitsu-laptop: acpi_fujitsu_hotkey_notify() cleanup
I am currently preparing a patch series which makes fujitsu-laptop use a sparse keymap for hotkey handling. Before that will happen, though, acpi_fujitsu_hotkey_notify() could use a revamp because it is pretty hard to read as it is. To avoid posting everything at once, here are a few patches which IMHO make that function easier to read. Some of these changes might be a matter of taste, so feel free to NACK them or suggest a preferred alternative. drivers/platform/x86/fujitsu-laptop.c | 174 ++ 1 file changed, 92 insertions(+), 82 deletions(-) -- 2.11.0
[PATCH 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
From: Tvrtko Ursulin
Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.
Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.
v2: Reorder parameters. (Chris Wilson)
v3: Fix incomplete reordering in v2.
v4: max_segment needs to be page aligned.
Signed-off-by: Tvrtko Ursulin
Cc: Masahiro Yamada
Cc: linux-kernel@vger.kernel.org
Cc: Chris Wilson
Reviewed-by: Chris Wilson (v2)
---
include/linux/scatterlist.h | 11 ++---
lib/scatterlist.c | 59 +++--
2 files changed, 53 insertions(+), 17 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index c981bee1a3ae..16b740afeed2 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -261,10 +261,13 @@ void sg_free_table(struct sg_table *);
int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int,
struct scatterlist *, gfp_t, sg_alloc_fn *);
int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
-int sg_alloc_table_from_pages(struct sg_table *sgt,
- struct page **pages, unsigned int n_pages,
- unsigned int offset, unsigned long size,
- gfp_t gfp_mask);
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+ unsigned int n_pages, unsigned int offset,
+ unsigned long size, unsigned int max_segment,
+ gfp_t gfp_mask);
+int sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+ unsigned int n_pages, unsigned int offset,
+ unsigned long size, gfp_t gfp_mask);
size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 4fc54801cd29..df375ff18587 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -370,14 +370,15 @@ int sg_alloc_table(struct sg_table *table, unsigned int
nents, gfp_t gfp_mask)
EXPORT_SYMBOL(sg_alloc_table);
/**
- * sg_alloc_table_from_pages - Allocate and initialize an sg table from
- *an array of pages
- * @sgt: The sg table header to use
- * @pages: Pointer to an array of page pointers
- * @n_pages: Number of pages in the pages array
- * @offset: Offset from start of the first page to the start of a buffer
- * @size: Number of valid bytes in the buffer (after offset)
- * @gfp_mask: GFP allocation mask
+ * __sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ * an array of pages
+ * @sgt:The sg table header to use
+ * @pages: Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset: Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @max_segment: Maximum size of a scatterlist node in bytes (page aligned)
+ * @gfp_mask: GFP allocation mask
*
* Description:
*Allocate and initialize an sg table from a list of pages. Contiguous
@@ -389,18 +390,20 @@ EXPORT_SYMBOL(sg_alloc_table);
* Returns:
* 0 on success, negative error on failure
*/
-int sg_alloc_table_from_pages(struct sg_table *sgt,
- struct page **pages, unsigned int n_pages,
- unsigned int offset, unsigned long size,
- gfp_t gfp_mask)
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+ unsigned int n_pages, unsigned int offset,
+ unsigned long size, unsigned int max_segment,
+ gfp_t gfp_mask)
{
- const unsigned int max_segment = rounddown(UINT_MAX, PAGE_SIZE);
unsigned int seg_len, chunks;
unsigned int i;
unsigned int cur_page;
int ret;
struct scatterlist *s;
+ if (WARN_ON(offset_in_page(max_segment)))
+ return -EINVAL;
+
/* compute number of contiguous chunks */
chunks = 1;
seg_len = PAGE_SIZE;
@@ -444,6 +447,36 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
return 0;
}
+EXPORT_SYMBOL(__sg_alloc_table_from_pages);
+
+/**
+ * sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ *an array of pages
+ * @sgt:The sg table header to use
+ * @pages: Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset: Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @gfp_mask: GFP allocation mask
+ *
+ * Description:
+ *Allocate and initialize an sg table from a list of pages. Contiguous
+ *r
Re: [PATCH] scsi: qedi: select UIO
On 11/01/17 9:40 AM, "Martin K. Petersen" wrote: >> "Ewan" == Ewan D Milne writes: > >Ewan> Randy posted a similar patch back in December but I don't think >Ewan> there was ever a reply to Christoph's question about why qedi >Ewan> depends on uio. > >I did queue up Randy's patch to shut up the build warnings. But we're >still looking for a long term fix or an explanation as to why UIO is >needed in the first place. Similar to bnx2i driver, qedi driver also has a dependency over iscsiuio to provide ARP and DHCP functionality for iscsi offload, and the communication to the driver is done via uio interface. https://github.com/open-iscsi/open-iscsi/blob/master/iscsiuio/README Thanks, Manish
[PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
From: Tvrtko Ursulin
Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.
Since these are offsets withing a page, unsigned int is
wide enough.
Also converts callers which were using unsigned long locally
with the lower_32_bits annotation to make it explicitly
clear what is happening.
v2: Use offset_in_page. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Masahiro Yamada
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Stanislawski
Cc: Matt Porter
Cc: Alexandre Bounine
Cc: linux-me...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Szyprowski (v1)
Reviewed-by: Chris Wilson
Reviewed-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
include/linux/scatterlist.h| 2 +-
lib/scatterlist.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177be461..51e8765bc3c6 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -478,7 +478,7 @@ static void *vb2_dc_get_userptr(struct device *dev,
unsigned long vaddr,
{
struct vb2_dc_buf *buf;
struct frame_vector *vec;
- unsigned long offset;
+ unsigned int offset;
int n_pages, i;
int ret = 0;
struct sg_table *sgt;
@@ -506,7 +506,7 @@ static void *vb2_dc_get_userptr(struct device *dev,
unsigned long vaddr,
buf->dev = dev;
buf->dma_dir = dma_dir;
- offset = vaddr & ~PAGE_MASK;
+ offset = lower_32_bits(offset_in_page(vaddr));
vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c
b/drivers/rapidio/devices/rio_mport_cdev.c
index 9013a585507e..0fae29ff47ba 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
* offset within the internal buffer specified by handle parameter.
*/
if (xfer->loc_addr) {
- unsigned long offset;
+ unsigned int offset;
long pinned;
- offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
+ offset = lower_32_bits(offset_in_page(xfer->loc_addr));
nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
page_list = kmalloc_array(nr_pages,
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe6acd7..c981bee1a3ae 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int,
unsigned int,
int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
- unsigned long offset, unsigned long size,
+ unsigned int offset, unsigned long size,
gfp_t gfp_mask);
size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70fc56a..e05e7fc98892 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
*/
int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
- unsigned long offset, unsigned long size,
+ unsigned int offset, unsigned long size,
gfp_t gfp_mask)
{
unsigned int chunks;
--
2.7.4
[PATCH 2/4] platform/x86: fujitsu-laptop: move keycode processing to separate functions
acpi_fujitsu_hotkey_notify() is pretty deeply nested, which hurts
readability. Move the keycode processing part to two separate functions
to make the code easier to understand and save a few line breaks.
Rename variable keycode_r to keycode as there is no longer any need to
differentiate between the two. Tweak indentations to make checkpatch
happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 76 ---
1 file changed, 43 insertions(+), 33 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index c2022f8af51b..e57d3724d2ce 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1030,12 +1030,48 @@ static int acpi_fujitsu_hotkey_remove(struct
acpi_device *device)
return 0;
}
+static void acpi_fujitsu_hotkey_press(int keycode)
+{
+ struct input_dev *input = fujitsu_hotkey->input;
+ int status;
+
+ vdbg_printk(FUJLAPTOP_DBG_TRACE,
+ "Push keycode into ringbuffer [%d]\n", keycode);
+ status = kfifo_in_locked(&fujitsu_hotkey->fifo,
+(unsigned char *)&keycode, sizeof(keycode),
+&fujitsu_hotkey->fifo_lock);
+ if (status != sizeof(keycode)) {
+ vdbg_printk(FUJLAPTOP_DBG_WARN,
+ "Could not push keycode [0x%x]\n", keycode);
+ } else {
+ input_report_key(input, keycode, 1);
+ input_sync(input);
+ }
+}
+
+static void acpi_fujitsu_hotkey_release(void)
+{
+ struct input_dev *input = fujitsu_hotkey->input;
+ int keycode, status;
+
+ while ((status = kfifo_out_locked(&fujitsu_hotkey->fifo,
+ (unsigned char *)&keycode,
+ sizeof(keycode),
+ &fujitsu_hotkey->fifo_lock))
+ == sizeof(keycode)) {
+ input_report_key(input, keycode, 0);
+ input_sync(input);
+ vdbg_printk(FUJLAPTOP_DBG_TRACE,
+ "Pop keycode from ringbuffer [%d]\n", keycode);
+ }
+}
+
static void acpi_fujitsu_hotkey_notify(struct acpi_device *device, u32 event)
{
struct input_dev *input;
- int keycode, keycode_r;
+ int keycode;
unsigned int irb = 1;
- int i, status;
+ int i;
input = fujitsu_hotkey->input;
@@ -1083,37 +1119,11 @@ static void acpi_fujitsu_hotkey_notify(struct
acpi_device *device, u32 event)
keycode = -1;
break;
}
- if (keycode > 0) {
- vdbg_printk(FUJLAPTOP_DBG_TRACE,
- "Push keycode into ringbuffer [%d]\n",
- keycode);
- status = kfifo_in_locked(&fujitsu_hotkey->fifo,
- (unsigned char *)&keycode,
- sizeof(keycode),
- &fujitsu_hotkey->fifo_lock);
- if (status != sizeof(keycode)) {
- vdbg_printk(FUJLAPTOP_DBG_WARN,
- "Could not push keycode [0x%x]\n",
- keycode);
- } else {
- input_report_key(input, keycode, 1);
- input_sync(input);
- }
- } else if (keycode == 0) {
- while ((status =
- kfifo_out_locked(
-&fujitsu_hotkey->fifo,
-(unsigned char *) &keycode_r,
-sizeof(keycode_r),
-&fujitsu_hotkey->fifo_lock))
-== sizeof(keycode_r)) {
- input_report_key(input, keycode_r, 0);
- input_sync(input);
- vdbg_printk(FUJLAPTOP_DBG_TRACE,
- "Pop keycode from ringbuffer [%d]\n",
- keycode_r);
- }
- }
+
+ if (keycode > 0)
+ acpi_fujitsu_hotkey_press(keycode);
+ else if (keycode == 0)
+ acpi_fujitsu_hotkey_release();
}
/* On some models (first seen on the Skylake-based Lifebook
--
2.11.0
[PATCH 2/4] lib/scatterlist: Avoid potential scatterlist entry overflow
From: Tvrtko Ursulin
Since the scatterlist length field is an unsigned int, make
sure that sg_alloc_table_from_pages does not overflow it while
coallescing pages to a single entry.
v2: Drop reference to future use. Use UINT_MAX.
v3: max_segment must be page aligned.
Signed-off-by: Tvrtko Ursulin
Cc: Masahiro Yamada
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Chris Wilson (v2)
---
lib/scatterlist.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index e05e7fc98892..4fc54801cd29 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -394,7 +394,8 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
unsigned int offset, unsigned long size,
gfp_t gfp_mask)
{
- unsigned int chunks;
+ const unsigned int max_segment = rounddown(UINT_MAX, PAGE_SIZE);
+ unsigned int seg_len, chunks;
unsigned int i;
unsigned int cur_page;
int ret;
@@ -402,9 +403,16 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
/* compute number of contiguous chunks */
chunks = 1;
- for (i = 1; i < n_pages; ++i)
- if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1)
+ seg_len = PAGE_SIZE;
+ for (i = 1; i < n_pages; ++i) {
+ if (seg_len >= max_segment ||
+ page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1) {
++chunks;
+ seg_len = PAGE_SIZE;
+ } else {
+ seg_len += PAGE_SIZE;
+ }
+ }
ret = sg_alloc_table(sgt, chunks, gfp_mask);
if (unlikely(ret))
@@ -413,17 +421,22 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
/* merging chunks and putting them into the scatterlist */
cur_page = 0;
for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
- unsigned long chunk_size;
+ unsigned int chunk_size;
unsigned int j;
/* look for the end of the current chunk */
+ seg_len = PAGE_SIZE;
for (j = cur_page + 1; j < n_pages; ++j)
- if (page_to_pfn(pages[j]) !=
+ if (seg_len >= max_segment ||
+ page_to_pfn(pages[j]) !=
page_to_pfn(pages[j - 1]) + 1)
break;
+ else
+ seg_len += PAGE_SIZE;
chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset;
- sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
+ sg_set_page(s, pages[cur_page],
+ min_t(unsigned long, size, chunk_size), offset);
size -= chunk_size;
offset = 0;
cur_page = j;
--
2.7.4
[PATCH 4/4] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
From: Tvrtko Ursulin
With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.
Similar to 871dfbd67d4e ("drm/i915: Allow compaction upto
SWIOTLB max segment size") this enables more compact sg lists to
be created and so has a beneficial effect on workloads with many
and/or large objects of this class.
v2:
* Rename helper to i915_sg_segment_size and fix swiotlb override.
* Commit message update.
v3:
* Actually include the swiotlb override fix.
v4:
* Regroup parameters a bit. (Chris Wilson)
v5:
* Rebase for swiotlb_max_segment.
* Add DMA map failure handling as in abb0deacb5a6
("drm/i915: Fallback to single PAGE_SIZE segments for DMA remapping").
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Chris Wilson (v4)
---
drivers/gpu/drm/i915/i915_drv.h | 10 +
drivers/gpu/drm/i915/i915_gem.c | 6 +--
drivers/gpu/drm/i915/i915_gem_userptr.c | 79 -
3 files changed, 40 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b325032fedc..a944ff0c5c68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2594,6 +2594,16 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
(((__iter).curr += PAGE_SIZE) < (__iter).max) || \
((__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0))
+static inline unsigned int i915_sg_segment_size(void)
+{
+ unsigned int size = swiotlb_max_segment();
+
+ if (size == 0)
+ size = UINT_MAX;
+
+ return rounddown(size, PAGE_SIZE);
+}
+
static inline const struct intel_device_info *
intel_info(const struct drm_i915_private *dev_priv)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 13c02015709c..421827069a2f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2248,7 +2248,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
- unsigned int max_segment;
+ unsigned int max_segment = i915_sg_segment_size();
int ret;
gfp_t gfp;
@@ -2259,10 +2259,6 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
GEM_BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
GEM_BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
- max_segment = swiotlb_max_segment();
- if (!max_segment)
- max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 6a8fa085b74e..95b62b9c5cd6 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -390,64 +390,42 @@ struct get_pages_work {
struct task_struct *task;
};
-#if IS_ENABLED(CONFIG_SWIOTLB)
-#define swiotlb_active() swiotlb_nr_tbl()
-#else
-#define swiotlb_active() 0
-#endif
-
-static int
-st_set_pages(struct sg_table **st, struct page **pvec, int num_pages)
-{
- struct scatterlist *sg;
- int ret, n;
-
- *st = kmalloc(sizeof(**st), GFP_KERNEL);
- if (*st == NULL)
- return -ENOMEM;
-
- if (swiotlb_active()) {
- ret = sg_alloc_table(*st, num_pages, GFP_KERNEL);
- if (ret)
- goto err;
-
- for_each_sg((*st)->sgl, sg, num_pages, n)
- sg_set_page(sg, pvec[n], PAGE_SIZE, 0);
- } else {
- ret = sg_alloc_table_from_pages(*st, pvec, num_pages,
- 0, num_pages << PAGE_SHIFT,
- GFP_KERNEL);
- if (ret)
- goto err;
- }
-
- return 0;
-
-err:
- kfree(*st);
- *st = NULL;
- return ret;
-}
-
static struct sg_table *
-__i915_gem_userptr_set_pages(struct drm_i915_gem_object *obj,
-struct page **pvec, int num_pages)
+__i915_gem_userptr_alloc_pages(struct drm_i915_gem_object *obj,
+ struct page **pvec, int num_pages)
{
- struct sg_table *pages;
+ unsigned int max_segment = i915_sg_segment_size();
+ struct sg_table *st;
int ret;
- ret = st_set_pages(&pages, pvec, num_pages);
- if (ret)
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return ERR_PTR(-ENOMEM);
+
+alloc_table:
+ ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
+ 0, num_pages << PAGE_SHIFT,
+
Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
Looks fine: Reviewed-by: Christoph Hellwig
Re: [PATCH 2/2] serial: sh-sci: Fix hang in sci_reset()
Hi Laurent,
On Fri, Jan 6, 2017 at 1:31 PM, Laurent Pinchart
wrote:
> On Friday 02 Dec 2016 13:35:11 Geert Uytterhoeven wrote:
>> When the .set_termios() callback resets the UART, it first waits until
>> all characters in the transmit FIFO have been transmitted, to prevent a
>> port configuration change from impacting these characters.
>>
>> However, if the previous user of the UART had dedicated RTS/CTS hardware
>> flow control enabled, these characters may have been stuck in the FIFO
>> due to CTS not being asserted. When the new user opens the port,
>> .set_termios() is called while transmission is still disabled, leading
>> to an infinite loop:
>>
>> NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>>
>> This has been observed with SCIFA (on r8a7740/armadillo) and SCIFB (on
>> r8a7791/koelsch).
>>
>> The issue does not seem to happen when using:
>> - GPIO RTS/CTS hardware flow control,
>> - No hardware flow control,
>> - HSCIF (on r8a7791/koelsch).
>>
>> To fix this, wait for the draining of the transmit FIFO only if
>> transmission is already enabled.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> To reproduce:
>>
>> stty -echo < /dev/scifb0
>> stty crtscts < /dev/scifb0
>> echo hello > /dev/scifb0 # returns early (wrote to FIFO)
>> echo hello > /dev/scifb0 # hangs
>>
>> drivers/tty/serial/sh-sci.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index c503db1900f003ed..db5de80c5399a7bd 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -2137,9 +2137,11 @@ static void sci_reset(struct uart_port *port)
>> const struct plat_sci_reg *reg;
>> unsigned int status;
>>
>> - do {
>> - status = serial_port_in(port, SCxSR);
>> - } while (!(status & SCxSR_TEND(port)));
>> + if (serial_port_in(port, SCSCR) & SCSCR_TE) {
>> + do {
>> + status = serial_port_in(port, SCxSR);
>> + } while (!(status & SCxSR_TEND(port)));
>
> Won't we still loop forever if the remote side never asserts CTS ?
Thanks, you're right.
While my patch fixes the issue for a new user opening the port, I managed
to trigger the issue when changing the UART speed after writing some data
to an otherwise disconnected SCIFB0.
Now, how do other drivers handle this (if they handle it at all)?
As CTS is under control of the remote side, set_termios() may be blocked
for an arbitrary period of time. set_termios() also returns void, so it
cannot return e.g. -ERESTARTSYS from wait_event_interruptible().
Or is it considered a bug for userspace to change the terminal settings
without flushing the output buffer? In that case, we can just drop the
loop, and zap the FIFO regardless.
Thanks for your comments!
>
>> + }
>>
>> serial_port_out(port, SCSCR, 0x00); /* TE=0, RE=0, CKE1=0 */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
On 11/01/2017 03:09, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Replace 'goto l; ... l: return e;' with 'return e;'
> - Replace 'val = e; return val;' with 'return e;'
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Use devm_watchdog_register_driver() to register watchdog device
>
> Cc: Marc Gonzalez
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/tangox_wdt.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c
> index d5fcce062920..7688e1b35867 100644
> --- a/drivers/watchdog/tangox_wdt.c
> +++ b/drivers/watchdog/tangox_wdt.c
> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device
> *pdev)
> err = clk_prepare_enable(dev->clk);
> if (err)
> return err;
> + err = devm_add_action_or_reset(&pdev->dev,
> +(void(*)(void *))clk_disable_unprepare,
> +dev->clk);
> + if (err)
> + return err;
Hello Guenter,
I would rather avoid the function pointer cast.
How about defining an auxiliary function for the cleanup action?
clk_disable_unprepare() is static inline, so gcc will have to
define an auxiliary function either way. What do you think?
Regards.
diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c
index 202c4b9cc921..1a4f6d245a83 100644
--- a/drivers/watchdog/tangox_wdt.c
+++ b/drivers/watchdog/tangox_wdt.c
@@ -114,6 +114,11 @@ static int tangox_wdt_restart(struct notifier_block *nb,
unsigned long action,
return NOTIFY_DONE;
}
+static void cleanup(void *clk)
+{
+ clk_disable_unprepare(clk);
+}
+
static int tangox_wdt_probe(struct platform_device *pdev)
{
struct tangox_wdt_device *dev;
@@ -138,6 +143,10 @@ static int tangox_wdt_probe(struct platform_device *pdev)
if (err)
return err;
+ err = devm_add_action_or_reset(&pdev->dev, cleanup, dev->clk);
+ if (err)
+ return err;
+
dev->clk_rate = clk_get_rate(dev->clk);
if (!dev->clk_rate) {
err = -EINVAL;
Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy
on 2017/1/5 7:35, Theodore Ts'o wrote:
> On Wed, Jan 04, 2017 at 01:54:24PM -0800, Darrick J. Wong wrote:
>>
>> if (inode->i_nlink == 0) {
>> ext4_warning_inode(inode, "nlink is already 0");
>> return;
>> }
>
> We can't do that because the place where Zhangyi is proposing to
> change is in fs/inode.c:drop_nlink(), so we can't add a call to
> ext4_error() or ext4_warning().
>
> So how exactly how did we get into this state? When we read the inode
> into memory, if i_nlink is zero, we declare the file system as
> corrupted immediately.
>
> So I assume this is happening the on-disk i_links_count (which is read
> into inode->i_nlink) was too low. So I think the way we should be
> handling this is in unlink and rename, before we let i_nlink drop to
> zero, we need to check to see if there are other dcache entries
> pointing at the inode. If so, we need to call ext4_error(), and in
> the errors=continue case, return EFSCORRUPTED (aka EUCLEAN).
>
> - Ted
>
Hi Theodore:
The i_nlink underflow and memory corruption problem on ext4fs remains
inconclusive.
You suggest we can check dcache entries when i_nlink drop to zero in unlink and
rename. But I think it may still have some problems, assume the following
situation:
(1) The file we want to unlink have many hard links, but only one dcache entry
in memory.
(2) open this file, but it's inode->i_nlink read from disk was 1 (too low).
(3) some one call rename and drop it's i_nlink to zero.
(4) it's inode is still in use and do not destroy (not closed), at the same
time,
some others open it's hard link and create a dcache entry.
(5) call rename again and it's i_nlink will still underflow and cause memory
corruption.
For simplicity, I think we can add underflow protection in ext4_rename or
drop_nlink as V2 and V3 patch wrote. What do you think?
yi zhang
Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
Hi Andy, On 01/11/2017 04:11 AM, Andy Lutomirski wrote: On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann wrote: On 01/11/2017 12:24 AM, Andy Lutomirski wrote: This makes it easier to add another digest algorithm down the road if needed. It also serves to force any programs that might have been written against a kernel that had the old field name to notice the change and make any necessary changes. This shouldn't violate any stable API policies, as no released kernel has ever had TCA*BPF_DIGEST. Imho, this and patch 6/8 is not really needed. Should there ever another digest alg be used (doubt it), then you'd need a new nl attribute and fdinfo line anyway to keep existing stuff intact. Nobody made the claim that you can just change this underneath and not respecting abi for existing applications when I read from above that such apps now will get "forced" to notice a change. Fair enough. I was more concerned about prerelease iproute2 versions, but maybe that's a nonissue. I'll drop these two patches. Ok. Sleeping over this a bit, how about a general rename into "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for the netlink attributes, fwiw, it might reduce any assumptions on this being made? If this would be preferable, I could cook that patch against -net for renaming it? Thanks, Daniel
Re: [PATCH] i2c: piix4: Avoid race conditions with IMC
Hi Andy
Thanks for your review!
On Wed, Jan 11, 2017 at 2:49 AM, Andy Shevchenko
wrote:
> On Tue, Jan 10, 2017 at 2:16 PM, Ricardo Ribalda Delgado
> wrote:
>> On AMD's SB800 and upwards, the SMBus is shared with the Integrated
>> Micro Controller (IMC).
>>
>> The platform provides a hardware semaphore to avoid race conditions
>> among them. (Check page 288 of the SB800-Series Southbridges Register
>> Reference Guide http://support.amd.com/TechDocs/45482.pdf)
>
> It would be nice to understand what kind of devices are accessing and to
> where.
On my platform I found out that the IMC is polling address 0x98 and
0x99 every 14 and 177 msec.
Check out:
https://postimg.org/image/bssxhlg9d
https://postimg.org/image/g37ld6lch
But be aware that the firmware on the IMC might be different on other
platforms so the addresses and interval will be different.
>
> Hans seems discovered one pretty nice issue on Intel
> BayTrail/CherryTrail platforms where I2C semaphore is used to prevent
> simultaneous access to P-Unit, but we have two paths there which are
> not synchronized (yet). It brings a set of interesting (and
> unfortunately "famous") bugs.
AFAIK on AMD the smbus is just used on this driver.
>
>>
>> Without this patch, many access to the SMBus end with an invalid
>> transaction or even with the bus stalled.
>>
>
>> Credit-to: Alexandre Desnoyers
>
> Never saw before. Did he suggested the solution or what?
He is the hardware engineer where I work (qtec), when I showed him the
the logic analyzer output and told him that I was pretty sure that the
kernel/userpace was not doing those transactions he came up with the
theory of the IMC. He found up the semaphore on the documentation
also, so he deserves a lot of credit :).
>
>> --- a/drivers/i2c/busses/i2c-piix4.c
>> +++ b/drivers/i2c/busses/i2c-piix4.c
>> @@ -585,9 +585,28 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap,
>> u16 addr,
>> u8 command, int size, union i2c_smbus_data *data)
>> {
>> struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
>> + unsigned short piix4_smba = adapdata->smba;
>> u8 smba_en_lo;
>> u8 port;
>> int retval;
>> + int timeout = 0;
>> + int smbslvcnt;
>
>> while (++timeout < MAX_TIMEOUT) {
>
> Usual pattern is countdown.
I was trying to follow the pattern on the file.
>
>> + /* SMBus is still owned by the IMC, we give up */
>> + if (timeout == MAX_TIMEOUT)
>> + return -EBUSY;
>
> Would caller do it again? Perhaps -EAGAIN?
I think in this case we should return -EBUSY. If after 500 attempts
the bus is still hold by the IMC the bus is stalled or the IMC is
crashed, we should not retry. It is also the same errcode returned by
piix4_transaction().
>
> Since the returned value is not -ETIMEDOUT, I suppose the name of
> counter variable is a bit confusing. Basically it's amount of attempts
> with some gap between them. Though, it's up to you and maintainer.
>
>> + /* Release the semaphore */
>> + outb_p(smbslvcnt | 0x20, SMBSLVCNT);
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks again, I will send a v2 with your comments!
--
Ricardo Ribalda
Re: [PATCHv14 2/3] usb: USB Type-C connector class
On Wed, 2017-01-11 at 09:57 +0200, Heikki Krogerus wrote: > On Tue, Jan 10, 2017 at 11:08:51AM +0100, Oliver Neukum wrote: > > > And since we are talking about the ABI, can we also change the listing > > > of the accessory mode back to just "audio" and "debug" like I > > > originally had it? I don't remember who and why wanted it to be > > > changed to "Audio Adapter Accessory Mode" and "Debug Accessory Mode", > > > but it differs from the style we list the other details. > > > > Yes, but can we differentiate analog and digital audio? > > I guess we need to have values "analog_audio" and "digital_audio" > instead of just "audio". Is that OK? Perfect. Regards Oliver
[PATCH v2] i2c: piix4: Avoid race conditions with IMC
On AMD's SB800 and upwards, the SMBus is shared with the Integrated
Micro Controller (IMC).
The platform provides a hardware semaphore to avoid race conditions
among them. (Check page 288 of the SB800-Series Southbridges Register
Reference Guide http://support.amd.com/TechDocs/45482.pdf)
Without this patch, many access to the SMBus end with an invalid
transaction or even with the bus stalled.
Credit-to: Alexandre Desnoyers
Signed-off-by: Ricardo Ribalda Delgado
---
v2: Suggestions by Andy Shevchenko :
-Rename timeout to retries
-Use do {} while(--retries) pattern
-Group new variables
drivers/i2c/busses/i2c-piix4.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index f0563f7ce01b..81d06be0a72d 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -585,10 +585,29 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap,
u16 addr,
u8 command, int size, union i2c_smbus_data *data)
{
struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
+ unsigned short piix4_smba = adapdata->smba;
+ int retries = MAX_TIMEOUT;
+ int smbslvcnt;
u8 smba_en_lo;
u8 port;
int retval;
+ /* Request the SMBUS semaphore, avoid conflicts with the IMC */
+ smbslvcnt = inb_p(SMBSLVCNT);
+ do {
+ outb_p(smbslvcnt | 0x10, SMBSLVCNT);
+
+ /* Check the semaphore status */
+ smbslvcnt = inb_p(SMBSLVCNT);
+ if (smbslvcnt & 0x10)
+ break;
+
+ usleep_range(1000, 2000);
+ } while (--retries);
+ /* SMBus is still owned by the IMC, we give up */
+ if (!retries)
+ return -EBUSY;
+
mutex_lock(&piix4_mutex_sb800);
outb_p(piix4_port_sel_sb800, SB800_PIIX4_SMB_IDX);
@@ -606,6 +625,9 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16
addr,
mutex_unlock(&piix4_mutex_sb800);
+ /* Release the semaphore */
+ outb_p(smbslvcnt | 0x20, SMBSLVCNT);
+
return retval;
}
--
2.11.0
Re: [PATCH v7 2/7] perf/amd/iommu: Modify functions to query max banks and counters
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point
device ID to locate an IOMMU and check the reported max banks/counters.
The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU,
and uses it to acquire a reference to the first IOMMU, which does not work
on certain systems. Instead, we modify the function to take IOMMU index,
and use it to query the corresponded AMD IOMMU instance.
Note that we currently hard-code the IOMMU index to 0, since the current
AMD IOMMU perf implementation only supports single IOMMU. Subsequent patch
will add support for multi-IOMMU, and will use proper IOMMU index.
This patch also removes unnecessary function declaration in
amd_iommu_proto.h.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Joerg Roedel
Signed-off-by: Suravee Suthikulpanit
---
NOTE: This contains the fix in get_amd_iommu() as suggested by Joerg.
arch/x86/events/amd/iommu.c | 17 +++--
arch/x86/events/amd/iommu.h | 7 ++-
drivers/iommu/amd_iommu_init.c | 36 ++--
drivers/iommu/amd_iommu_proto.h | 2 --
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c
index f387baf..cf94f48 100644
--- a/arch/x86/events/amd/iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -237,14 +237,6 @@ static int perf_iommu_event_init(struct perf_event *event)
return -EINVAL;
}
- /* integrate with iommu base devid (), assume one iommu */
- perf_iommu->max_banks =
- amd_iommu_pc_get_max_banks(IOMMU_BASE_DEVID);
- perf_iommu->max_counters =
- amd_iommu_pc_get_max_counters(IOMMU_BASE_DEVID);
- if ((perf_iommu->max_banks == 0) || (perf_iommu->max_counters == 0))
- return -EINVAL;
-
/* update the hw_perf_event struct with the iommu config data */
hwc->config = config;
hwc->extra_reg.config = config1;
@@ -456,6 +448,11 @@ static __init int _init_perf_amd_iommu(
if (_init_events_attrs(perf_iommu) != 0)
pr_err("perf: amd_iommu: Only support raw events.\n");
+ perf_iommu->max_banks = amd_iommu_pc_get_max_banks(0);
+ perf_iommu->max_counters = amd_iommu_pc_get_max_counters(0);
+ if (!perf_iommu->max_banks || !perf_iommu->max_counters)
+ return -EINVAL;
+
/* Init null attributes */
perf_iommu->null_group = NULL;
perf_iommu->pmu.attr_groups = perf_iommu->attr_groups;
@@ -466,8 +463,8 @@ static __init int _init_perf_amd_iommu(
amd_iommu_pc_exit();
} else {
pr_info("perf: amd_iommu: Detected. (%d banks, %d
counters/bank)\n",
- amd_iommu_pc_get_max_banks(IOMMU_BASE_DEVID),
- amd_iommu_pc_get_max_counters(IOMMU_BASE_DEVID));
+ amd_iommu_pc_get_max_banks(0),
+ amd_iommu_pc_get_max_counters(0));
}
return ret;
diff --git a/arch/x86/events/amd/iommu.h b/arch/x86/events/amd/iommu.h
index 845d173..432d867 100644
--- a/arch/x86/events/amd/iommu.h
+++ b/arch/x86/events/amd/iommu.h
@@ -24,15 +24,12 @@
#define PC_MAX_SPEC_BNKS 64
#define PC_MAX_SPEC_CNTRS 16
-/* iommu pc reg masks*/
-#define IOMMU_BASE_DEVID 0x
-
/* amd_iommu_init.c external support functions */
extern bool amd_iommu_pc_supported(void);
-extern u8 amd_iommu_pc_get_max_banks(u16 devid);
+extern u8 amd_iommu_pc_get_max_banks(uint idx);
-extern u8 amd_iommu_pc_get_max_counters(u16 devid);
+extern u8 amd_iommu_pc_get_max_counters(uint idx);
extern int amd_iommu_pc_get_set_reg_val(u16 devid, u8 bank, u8 cntr,
u8 fxn, u64 *value, bool is_write);
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 157e934..1a13c34 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2706,6 +2706,20 @@ bool amd_iommu_v2_supported(void)
}
EXPORT_SYMBOL(amd_iommu_v2_supported);
+static struct amd_iommu *get_amd_iommu(uint idx)
+{
+ uint i = 0;
+ struct amd_iommu *iommu, *ret = NULL;
+
+ for_each_iommu(iommu) {
+ if (i++ == idx) {
+ ret = iommu;
+ break;
+ }
+ }
+ return ret;
+}
+
/
*
* IOMMU EFR Performance Counter support functionality. This code allows
@@ -2713,17 +2727,14 @@ bool amd_iommu_v2_supported(void)
*
/
-u8 amd_iommu_pc_get_max_banks(u16 devid)
+u8 amd_iommu_pc_get_max_banks(uint idx)
{
- struct amd_iommu *iommu;
- u8 ret = 0;
+ struct amd_iommu *iommu = get_amd_iommu(idx);
- /* locate the iommu governing the devid */
- iommu = amd_iommu_rlookup_table[devid];
Re: CPU Hotplugging disabled, still cpuhp/%d threads running in my 32-bit system
On Tue, 10 Jan 2017, Enrico Mioso wrote: > Hello guys. > I disabled CPU hotplugging in my .config: still I can see what follows in the > process list. > >11 ?S 0:00 [cpuhp/0] >12 ?S 0:00 [cpuhp/1] > > And from what I can see in kernel/cpu.c:574, this is related to CPU > hotplugging. > Is this normal? And, out of curiosity, why? Yes. We need the threads for bringing up the CPUs and for modules and other functionality to set up per cpu related things. The thread makes sure that the code runs on the CPUs and handles the functionality related to install/remove of hotplug callbacks. Thanks, tglx
Re: [PATCH net-next] bridge: multicast to unicast
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
>
> [readding CCs I removed earlier]
>
> Ah! Thanks. I was worried about creating packetloss :D.
Ah, well, no - at least not in this case.
> Hm, for this other other way round, I think it does not apply for
> the bridge multicast-to-unicast patch if I'm not misreading the
> bridge code:
>
> For a packet with a link-layer multicast address but a unicast IP
> destination, the bridge MDB lookup will fail.
> (http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8
> #L178
> returns NULL)
>
> Case A): No multicast router on port:
> -> bridge, br_multicast_flood(), will drop the packet already
> (no matter if multicast-to-unicast is enabled or not)
>
> Case B): Multicast router present on port:
> -> The new patch does not apply multicast-to-unicast but just floods
> packet unaltered
> ("else { port = rport; addr = NULL; }" branch)
Ah, interesting. This is different then - the mac80211 code is not L3
aware at all.
johannes
Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
On Tue, 2017-01-10 at 17:23 +, Sean Young wrote:
> Hi Sean,
>
> > >
> > > The kernel guarantees that calls to the interrupt handler are serialised,
> > > no need to disable the interrupt in the handler.
> >
> > agreed. I will save the mtk irq disable/enable and retest again.
> >
> >
> > > > +
> > > > + /* Reset decoder state machine */
> > > > + ir_raw_event_reset(ir->rc);
> > >
> > > Not needed.
> >
> >
> > two reasons I added the line here
> >
> > 1)
> > I thought it is possible the decoder goes to the
> > middle state when getting the data not belonged
> > to the protocol. If so, that would cause the decoding
> > fails in the next time receiving the valid protocol data.
>
> The last IR event submitted will always be a long space, that's enough
> to reset the decoders. Adding a ir_raw_event_reset() will do this
> more explicitly, rather than their state machines resetting themselves
> through the trailing space.
thanks for the detailed explanation :) i got it
but some hardware limitation let me can't do it in implicit way :(
reset decoder state machine explicitly is needed because
1) the longest duration for space MTK IR hardware can record is not
safely long. e.g 12ms if rx resolution is 46us by default. There is
still the risk to satisfying every decoder to reset themselves through
long enough trailing spaces
2) the IRQ handler called guarantees that start of IR message is always
contained in and starting from register MTK_CHKDATA_REG(0).
I will add these words for hardware limitation into comments in the
driver
> > 2)
> > the mtk hardware register always contains the start of
> > IR message. So force to sync the state between
> > HW and ir-core.
> >
> >
> >
> > > > +
> > > > + /* First message must be pulse */
> > > > + rawir.pulse = false;
> > >
> > > pulse = true?
> >
> > becasue of rawir.pulse = !rawir.pulse does as below
> > so the initial value is set as false.
>
> Ah, sorry, of course. :)
>
> > > > +
> > > > + /* Handle all pulse and space IR controller captures */
> > > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > > +
> > > > + for (j = 0 ; j < 4 ; j++) {
> > > > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j *
> > > > 8;
> > > > + rawir.pulse = !rawir.pulse;
> > > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > > + }
> > >
> > > In v1 you would break out of the loop if the ir message was shorter, but
> > > now you are always passing on 68 pulses and spaces. Is that right?
> >
> > as I asked in the previous mail list as below i copied from it, so i
> > made some changes ...
> >
> > "
> > > I had another question. I found multiple and same IR messages being
> > > received when using SONY remote controller. Should driver needs to
> > > report each message or only one of these to the upper layer ?
> >
> > In general the driver shouldn't try to change any IR message, this
> > should be done in rc-core if necessary.
> >
> > rc-core should handle this correctly. If the same key is received twice
> > within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
> > layer.
> >
> >
> > for example:
> > the 68 pulse/spaces might contains 2.x IR messages when I
> > pressed one key on SONY remote control.
> >
> > the v1 proposed is passing only one IR message into ir-core ;
> > the v2 done is passing all IR messages even including the last
> > incomplete message into ir-core.
>
> Yes, agreed. Sorry if I wasn't clear. I just wanted to make sure you've
> thought about what happens when the IR message is short (e.g. rc-5 with
> 23 pulse-spaces). Are the remaining registers 0 or do we get stale data
> from a previous transmit?
Before exit from this IRQ handler , mtk_w32_mask(ir, 0x1, MTK_IRCLR,
MTK_IRCLR_REG) would be done that causes all registers used to store
pulses and spaces to be cleared, so no stale data appears in the next
transmit.
> > But I was still afraid the state machine can't go back to initial state
> > after receiving these incomplete data.
> >
> > So the ir_raw_event_reset() call in the beginning of ISR seems becoming
> > more important.
> >
> > > > + }
> > > > +
> > > > + /* The maximum number of edges the IR controller can
> > > > +* hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> > > > +* is over the limit, the last incomplete IR message would
> > > > +* be appended trailing space and still would be sent into
> > > > +* ir-rc-raw to decode. That helps it is possible that it
> > > > +* has
Re: [PATCH v2] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
On 12/30/2016 03:51 PM, Heinrich Schuchardt wrote:
> On 12/30/2016 02:40 PM, Neil Armstrong wrote:
>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>> this patch adds this reserved zone and redefines the usable memory range.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> Changes since v1 at [1] :
>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>> - only kept secmon memory zone
>>
>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
>>
>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12
>> arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
>> 11 files changed, 22 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> index 7a078be..ca3c7fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> @@ -56,7 +56,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x0 0x0 0x0 0x8000>;
>> +linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>> };
>>
>> vddio_boot: regulator-vddio_boot {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index eada0b5..7f244b5 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -55,6 +55,18 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> +reserved-memory {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +/* global autoconfigured region for contiguous allocations */
>
> This comment does not make sense here. It is what you would write over a
> compatible to "shared-dma-pool" region. Cf. hi6220-hikey.dts
>
> I suggest you use
> /* Amlogic Meson GXBB/GXL/GXM secure monitor reserved memory */
> instead.
Yes, will fix this in a similar manner.
>
> Doesn't firmware/meson/meson_sm.c already reserve a communication area
> to secmon with quite a different address range?
> So where is this new region secmon set up? And where is it used?
Yes, it gets the memory zone from the secure monitor and reserves it, only if
enabled and very late.
Neil
>
> Best regards
>
> Heinrich
>
>> +secmon: secmon {
>> +reg = <0x0 0x1000 0x0 0x20>;
>> +no-map;
>> +};
>> +};
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> index 4cbd626..c7f008a 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -62,7 +62,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x0 0x0 0x0 0x4000>;
>> +linux,usable-memory = <0x0 0x100 0x0 0x3f00>;
>> };
>>
>> leds {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 238fbea..546cbe4 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -61,7 +61,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x0 0x0 0x0 0x8000>;
>> +linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>> };
>>
>> usb_otg_pwr: regulator-usb-pwrs {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> index 4a96e0f..1fdf6da 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -55,7 +55,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x0 0x0 0x0 0x4000>;
>> +linux,usable-memory = <0x0 0x100 0x0 0x3f00>;
>> };
>>
>> usb_pwr: regulator-usb-pwrs {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
>> b/arch/arm64/boot/dts
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
On Mon, Jan 09, 2017 at 09:51:29PM -0800, Paul E. McKenney wrote:
> Definitely.
Btw, we have more breakage from RCU expedited using workqueues:
https://bugzilla.kernel.org/show_bug.cgi?id=192111
I've added you to CC but let me have other bug reporters confirm reverting
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
does fix the issue for them too.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer
> > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote: > > On older platforms the command should be just ignored by the firmware > > but some older platforms misbehave so it's safer to send the command > > only if required. > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s). What about Dell XPS13 ? Thanks Tomas
Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
okay, I will continue to work based on your changes unless someone else
has concerns
On Wed, 2017-01-11 at 07:45 +0900, Andi Shyti wrote:
> Hi Sean,
>
> >include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address':
> > unknown attribute
> > >> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for
> > >> function devm_rc_allocate_device
> >drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
> >drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function
> > 'devm_rc_allocate_device'
> > ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > ^~~
> >In file included from drivers/media/rc/mtk-cir.c:22:0:
> >include/media/rc-core.h:213:16: note: declared here
> > struct rc_dev *devm_rc_allocate_device(struct device *dev);
> >^~~
> >
> > vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c
> >
> >209 ir->base = devm_ioremap_resource(dev, res);
> >210 if (IS_ERR(ir->base)) {
> >211 dev_err(dev, "failed to map registers\n");
> >212 return PTR_ERR(ir->base);
> >213 }
> >214
> > > 215 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
>
> this error comes because the patches I pointed out have not been
> applied yet. I guess you can ignore them as long as you tested
> yours on top those patches.
>
> Andi
Re: [PATCH v1] scsi: ufs: fix arguments order some trace calls
On 11/01/17 00:48, Subhash Jadavani wrote:
> Colin Ian King reported that with
> commit 7ff5ab473633 ("scsi: ufs: add tracing support") static analysis
> is reporting that we may have swapped arguments on calls to:
> trace_ufshcd_runtime_resume,
> trace_ufshcd_runtime_suspend,
> trace_ufshcd_system_suspend,
> trace_ufshcd_system_resume,
> and trace_ufshcd_init
>
> Where:
> hba->uic_link_state is passed to dev_state
> hba->curr_dev_pwr_mode is passed to link_state
>
> This wasn't intentional so it's a bug. This change fixed this bug.
>
> Reported-by: Colin Ian King
> Signed-off-by: Subhash Jadavani
> ---
> drivers/scsi/ufs/ufshcd.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index be6322e..6b56eb0 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5805,7 +5805,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
>
> trace_ufshcd_init(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
>
> @@ -6819,7 +6819,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
> out:
> trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> if (!ret)
> hba->is_sys_suspended = true;
> return ret;
> @@ -6852,7 +6852,7 @@ int ufshcd_system_resume(struct ufs_hba *hba)
> out:
> trace_ufshcd_system_resume(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_system_resume);
> @@ -6880,7 +6880,7 @@ int ufshcd_runtime_suspend(struct ufs_hba *hba)
> out:
> trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_runtime_suspend);
> @@ -6921,7 +6921,7 @@ int ufshcd_runtime_resume(struct ufs_hba *hba)
> out:
> trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_runtime_resume);
>
Thanks, looks good to me.
Acked-by: Colin Ian King
Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks
On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2017, Joe Perches wrote:
> > Make these files symlinks to the .rst equivalents
>
> If we're going to do this (and I really don't mind either way), then
> please add
>
> Fixes: 08a9a8d44c1c ("doc: re-add CodingStyle and SubmittingPatches")
I don't believe this patch "fixes" the other, it just makes it
possible to continue to write "Read Documentation/CodingStyle"
or "Read Documentation/SubmittingPatches" to people that
submit poorly formatted or improper patches.
I attempted to do that a bit ago but then had to write out the
Documentation/process/.rst equivalents instead.
Re: [PATCH] vme: Fix wrong pointer utilization in ca91cx42_slave_get
On 10 January 2017 at 10:45, Augusto Mecking Caringi wrote: > In ca91cx42_slave_get function, the value pointed by vme_base pointer is > set through: > > *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); > > So it must be dereferenced to be used in calculation of pci_base: > > *pci_base = (dma_addr_t)*vme_base + pci_offset; > > This bug was caught thanks to the following gcc warning: > > drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: > drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to > integer of different size [-Wpointer-to-int-cast] > *pci_base = (dma_addr_t)vme_base + pci_offset; > > Signed-off-by: Augusto Mecking Caringi Acked-By: Martyn Welch > --- > drivers/vme/bridges/vme_ca91cx42.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vme/bridges/vme_ca91cx42.c > b/drivers/vme/bridges/vme_ca91cx42.c > index 6b5ee89..7cc5122 100644 > --- a/drivers/vme/bridges/vme_ca91cx42.c > +++ b/drivers/vme/bridges/vme_ca91cx42.c > @@ -464,7 +464,7 @@ static int ca91cx42_slave_get(struct vme_slave_resource > *image, int *enabled, > vme_bound = ioread32(bridge->base + CA91CX42_VSI_BD[i]); > pci_offset = ioread32(bridge->base + CA91CX42_VSI_TO[i]); > > - *pci_base = (dma_addr_t)vme_base + pci_offset; > + *pci_base = (dma_addr_t)*vme_base + pci_offset; > *size = (unsigned long long)((vme_bound - *vme_base) + granularity); > > *enabled = 0; > -- > 2.7.4 >
Re: Dell XPS13 does not suspend with Linux 4.10-rc3
On Wed, Jan 11, 2017 at 09:53:38AM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On 01/10/17 23:24, Jan Niehusmann wrote:
> > On Tue, Jan 10, 2017 at 09:43:31PM +0100, Jan Niehusmann wrote:
> > > And I bisected the issue to commit 7279b238ba, "mei: send OS type to the
> > > FW"
> >
> > Indeed, just disabling the FIXUP implemented by that commit fixes
> > suspend for me, with 4.10.0-rc3. Btw, this is on a Thinkpad x201s.
> >
> > (For the addressees newly added to cc, it seems like the mentioned
> > commit breaks suspend to ram on Dell XPS13 and Thinkpad x201s)
> >
> > --- a/drivers/misc/mei/bus-fixup.c
> > +++ b/drivers/misc/mei/bus-fixup.c
> > @@ -406,3 +406,3 @@ static struct mei_fixup {
> > MEI_FIXUP(MEI_UUID_WD, mei_wd),
> > - MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
> > +// MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
> > };
> >
> >
> > I don't know what this may break, as the description of 7279b23 just
> > says:
> > "This workaround was added to support other broken OS and we need to
> > follow here."
> >
> > Unless there is a better justification, I think the commit should be
> > reverted, for now.
>
> Somebody else already created the bug 192051 in the Linux Kernel Bug Tracker
> [1].
There's a fix for this in my tree to go to Linus for 4.10-rc4.
thanks,
greg k-h
Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 11.01.2017 09:40, Inki Dae wrote:
>
> 2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
>> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>>> From: Hyungwon Hwang
>>>
>>> This patch add the panel device tree node for S6E3HA2 display
>>> controller to TM2 dts.
>>>
>>> Signed-off-by: Hyungwon Hwang
>>> Signed-off-by: Andrzej Hajda
>>> Signed-off-by: Chanwoo Choi
>>> Signed-off-by: Hoegeun Kwon
>>> Tested-by: Chanwoo Choi
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> index ddba2f8..6d362f9 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> @@ -18,6 +18,18 @@
>>> compatible = "samsung,tm2", "samsung,exynos5433";
>>> };
>>>
>>> +&dsi {
>>> + panel@0 {
>>> + compatible = "samsung,s6e3ha2";
>>> + reg = <0>;
>>> + vdd3-supply = <&ldo27_reg>;
>>> + vci-supply = <&ldo28_reg>;
>>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> The same here (as in 1st comment) , te-gpios should be dropper - decon
>> uses hw-trigger.
> Reasonable to remove te-gpios property but this change would make MIPI-DSI
> driver probing to be failed so MIPI-DSI driver should be fixed together.
>
> Thanks.
OK, I forgot it was not yet ported to mainline.
Regards
Andrzej
>
>> Regards
>> Andrzej
>>> + };
>>> +};
>>> +
>>> &hsi2c_9 {
>>> status = "okay";
>>>
>>
>>
>>
>
[PATCH v8 10/18] iommu/arm-smmu: Implement reserved region get/put callbacks
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
---
v3 -> v4:
- do not handle PCI host bridge windows anymore
- encode prot
RFC v2 -> v3:
- use existing get/put_resv_regions
RFC v1 -> v2:
- use defines for MSI IOVA base and length
---
drivers/iommu/arm-smmu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..a354572 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -281,6 +281,9 @@ enum arm_smmu_s2cr_privcfg {
#define FSYNR0_WNR (1 << 4)
+#define MSI_IOVA_BASE 0x800
+#define MSI_IOVA_LENGTH0x10
+
static int force_stage;
module_param(force_stage, int, S_IRUGO);
MODULE_PARM_DESC(force_stage,
@@ -1549,6 +1552,29 @@ static int arm_smmu_of_xlate(struct device *dev, struct
of_phandle_args *args)
return iommu_fwspec_add_ids(dev, &fwid, 1);
}
+static void arm_smmu_get_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct iommu_resv_region *region;
+ int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+
+ region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+prot, IOMMU_RESV_MSI);
+ if (!region)
+ return;
+
+ list_add_tail(®ion->list, head);
+}
+
+static void arm_smmu_put_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct iommu_resv_region *entry, *next;
+
+ list_for_each_entry_safe(entry, next, head, list)
+ kfree(entry);
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1564,6 +1590,8 @@ static int arm_smmu_of_xlate(struct device *dev, struct
of_phandle_args *args)
.domain_get_attr= arm_smmu_domain_get_attr,
.domain_set_attr= arm_smmu_domain_set_attr,
.of_xlate = arm_smmu_of_xlate,
+ .get_resv_regions = arm_smmu_get_resv_regions,
+ .put_resv_regions = arm_smmu_put_resv_regions,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
--
1.9.1
[PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
Following LPC discussions, we now report reserved regions through the iommu-group sysfs reserved_regions attribute file. Reserved regions are populated through the IOMMU get_resv_region callback (former get_dm_regions), now implemented by amd-iommu, intel-iommu and arm-smmu: - the intel-iommu reports the [0xfee0 - 0xfeef] MSI window as a reserved region and RMRR regions as direct-mapped regions. - the amd-iommu reports device direct mapped regions, the MSI region and HT regions. - the arm-smmu reports the MSI window (arbitrarily located at 0x800 and 1MB large). Unsafe interrupt assignment is tested by enumerating all MSI irq domains and checking MSI remapping is supported in the above hierarchy. This check is done in case we detect the iommu translates MSI (an IOMMU_RESV_MSI window exists). Otherwise the IRQ remapping capability is checked at IOMMU level. Obviously this is a defensive IRQ safety assessment: Assuming there are several MSI controllers in the system and at least one does not implement IRQ remapping, the assignment will be considered as unsafe (even if this controller is not acessible from the assigned devices). The series first patch stems from Robin's branch: http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/misc Best Regards Eric Git: complete series available at https://github.com/eauger/linux/tree/v4.10-rc3-reserved-v8 istory: PATCHv7 -> PATCHv8 - take into account Marc's comments and apply his R-b - remove iommu_group_remove_file call in iommu_group_release - add Will's A-b - removed [PATCH v7 01/19] iommu/dma: Implement PCI allocation optimisation and updated iommu/dma: Allow MSI-only cookies as per Robin's indications PATCHv6 -> PATCHv7: - iommu/dma: Implement PCI allocation optimisation was added to apply iommu/dma: Allow MSI-only cookies - report Intel RMRR as direct-mapped regions - report the type in the iommu group sysfs reserved_regions file - do not merge regions of different types when building the list of reserved regions - intgeration Robin's "iommu/dma: Allow MSI-only cookies" last version - update Documentation/ABI/testing/sysfs-kernel-iommu_groups - rename IOMMU_RESV_NOMAP into IOMMU_RESV_RESERVED PATCHv5 -> PATCHv6 - Introduce IRQ_DOMAIN_FLAG_MSI as suggested by Marc - irq_domain_is_msi, irq_domain_is_msi_remap, irq_domain_hierarchical_is_msi_remap, - set IRQ_DOMAIN_FLAG_MSI in msi_create_irq_domain - fix compil issue on i386 - rework test at VFIO level RFCv4 -> PATCHv5 - fix IRQ security assessment by looking at irq domain parents - check DOMAIN_BUS_FSL_MC_MSI irq domains - AMD MSI and HT regions are exposed in iommu group sysfs RFCv3 -> RFCv4: - arm-smmu driver does not register PCI host bridge windows as reserved regions anymore - Implement reserved region get/put callbacks also in arm-smmuv3 - take the iommu_group lock on iommu_get_group_resv_regions - add a type field in iommu_resv_region instead of using prot - init the region list_head in iommu_alloc_resv_region, also add type parameter - iommu_insert_resv_region manage overlaps and sort reserved windows - address IRQ safety assessment by enumerating all the MSI irq domains and checking the MSI_REMAP flag - update Documentation/ABI/testing/sysfs-kernel-iommu_groups RFC v2 -> v3: - switch to an iommu-group sysfs API - use new dummy allocator provided by Robin - dummy allocator initialized by vfio-iommu-type1 after enumerating the reserved regions - at the moment ARM MSI base address/size is left unchanged compared to v2 - we currently report reserved regions and not usable IOVA regions as requested by Alex RFC v1 -> v2: - fix intel_add_reserved_regions - add mutex lock/unlock in vfio_iommu_type1 Eric Auger (17): iommu: Rename iommu_dm_regions into iommu_resv_regions iommu: Add a new type field in iommu_resv_region iommu: iommu_alloc_resv_region iommu: Only map direct mapped regions iommu: iommu_get_group_resv_regions iommu: Implement reserved_regions iommu-group sysfs file iommu/vt-d: Implement reserved region get/put callbacks iommu/amd: Declare MSI and HT regions as reserved IOVA regions iommu/arm-smmu: Implement reserved region get/put callbacks iommu/arm-smmu-v3: Implement reserved region get/put callbacks irqdomain: Add irq domain MSI and MSI_REMAP flags genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation irqdomain: irq_domain_check_msi_remap irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP vfio/type1: Allow transparent MSI IOVA allocation vfio/type1: Check MSI remapping at irq domain level iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore Robin Murphy (1): iommu/dma: Allow MSI-only cookies .../ABI/testing/sysfs-kernel-iommu_groups | 12 ++ drivers/iommu/amd_iommu.c | 54 --- drivers/iommu/arm-smmu-v3.c| 30 +++- drivers/iommu/arm-smmu.c | 30 +++- drivers/iommu/dma-iommu.c
[PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect to interrupts.
On ARM typically an MSI controller can sit downstream
to the IOMMU without preventing VFIO passthrough.
As such any assigned device can write into the MSI doorbell.
In case the MSI controller implements IRQ remapping, assigned
devices will not be able to trigger interrupts towards the
host. On the contrary, the assignment must be emphasized as
unsafe with respect to interrupts.
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
---
v7 -> v8:
- remove goto in irq_domain_check_msi_remap
- Added Marc's R-b
v5 -> v6:
- use irq_domain_hierarchical_is_msi_remap()
- comment rewording
v4 -> v5:
- Handle DOMAIN_BUS_FSL_MC_MSI domains
- Check parents
---
include/linux/irqdomain.h | 1 +
kernel/irq/irqdomain.c| 22 ++
2 files changed, 23 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index bc2f571..188eced 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -222,6 +222,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node
*of_node,
void *host_data);
extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
enum irq_domain_bus_token
bus_token);
+extern bool irq_domain_check_msi_remap(void);
extern void irq_set_default_host(struct irq_domain *host);
extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
irq_hw_number_t hwirq, int node,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 876e131..d889751 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -278,6 +278,28 @@ struct irq_domain *irq_find_matching_fwspec(struct
irq_fwspec *fwspec,
EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
/**
+ * irq_domain_check_msi_remap - Check whether all MSI
+ * irq domains implement IRQ remapping
+ */
+bool irq_domain_check_msi_remap(void)
+{
+ struct irq_domain *h;
+ bool ret = true;
+
+ mutex_lock(&irq_domain_mutex);
+ list_for_each_entry(h, &irq_domain_list, link) {
+ if (irq_domain_is_msi(h) &&
+ !irq_domain_hierarchical_is_msi_remap(h)) {
+ ret = false;
+ break;
+ }
+ }
+ mutex_unlock(&irq_domain_mutex);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(irq_domain_check_msi_remap);
+
+/**
* irq_set_default_host() - Set a "default" irq domain
* @domain: default domain pointer
*
--
1.9.1
[PATCH v8 16/18] vfio/type1: Allow transparent MSI IOVA allocation
When attaching a group to the container, check the group's
reserved regions and test whether the IOMMU translates MSI
transactions. If yes, we initialize an IOVA allocator through
the iommu_get_msi_cookie API. This will allow the MSI IOVAs
to be transparently allocated on MSI controller's compose().
Signed-off-by: Eric Auger
---
v3 -> v4:
- test region's type: IOMMU_RESV_MSI
- restructure the code to prepare for safety assessment
- reword title
---
drivers/vfio/vfio_iommu_type1.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 9266271..5651faf 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define DRIVER_VERSION "0.2"
#define DRIVER_AUTHOR "Alex Williamson "
@@ -1181,6 +1182,28 @@ static struct vfio_group *find_iommu_group(struct
vfio_domain *domain,
return NULL;
}
+static bool vfio_iommu_has_resv_msi(struct iommu_group *group,
+ phys_addr_t *base)
+{
+ struct list_head group_resv_regions;
+ struct iommu_resv_region *region, *next;
+ bool ret = false;
+
+ INIT_LIST_HEAD(&group_resv_regions);
+ iommu_get_group_resv_regions(group, &group_resv_regions);
+ list_for_each_entry(region, &group_resv_regions, list) {
+ if (region->type & IOMMU_RESV_MSI) {
+ *base = region->start;
+ ret = true;
+ goto out;
+ }
+ }
+out:
+ list_for_each_entry_safe(region, next, &group_resv_regions, list)
+ kfree(region);
+ return ret;
+}
+
static int vfio_iommu_type1_attach_group(void *iommu_data,
struct iommu_group *iommu_group)
{
@@ -1189,6 +1212,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
struct vfio_domain *domain, *d;
struct bus_type *bus = NULL, *mdev_bus;
int ret;
+ bool resv_msi;
+ phys_addr_t resv_msi_base;
mutex_lock(&iommu->lock);
@@ -1258,6 +1283,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
if (ret)
goto out_domain;
+ resv_msi = vfio_iommu_has_resv_msi(iommu_group, &resv_msi_base);
+
INIT_LIST_HEAD(&domain->group_list);
list_add(&group->next, &domain->group_list);
@@ -1304,6 +1331,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
if (ret)
goto out_detach;
+ if (resv_msi && iommu_get_msi_cookie(domain->domain, resv_msi_base))
+ goto out_detach;
+
list_add(&domain->next, &iommu->domain_list);
mutex_unlock(&iommu->lock);
--
1.9.1
[PATCH v8 13/18] genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
Now we have a flag value indicating an IRQ domain implements MSI, let's set it on msi_create_irq_domain(). Signed-off-by: Eric Auger Reviewed-by: Marc Zyngier --- v7 -> v8 - Added Marc's R-b v6: new --- kernel/irq/msi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c index ee23006..ddc2f54 100644 --- a/kernel/irq/msi.c +++ b/kernel/irq/msi.c @@ -270,8 +270,8 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode, if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS) msi_domain_update_chip_ops(info); - return irq_domain_create_hierarchy(parent, 0, 0, fwnode, - &msi_domain_ops, info); + return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0, + fwnode, &msi_domain_ops, info); } int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev, -- 1.9.1
[PATCH v8 18/18] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
IOMMU_CAP_INTR_REMAP has been advertised in arm-smmu(-v3) although
on ARM this property is not attached to the IOMMU but rather is
implemented in the MSI controller (GICv3 ITS).
Now vfio_iommu_type1 checks MSI remapping capability at MSI controller
level, let's correct this.
Signed-off-by: Eric Auger
Acked-by: Will Deacon
---
v7 -> v8:
- added Will's A-b
---
drivers/iommu/arm-smmu-v3.c | 2 --
drivers/iommu/arm-smmu.c| 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 6c4111c..d9cf6cb 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1375,8 +1375,6 @@ static bool arm_smmu_capable(enum iommu_cap cap)
switch (cap) {
case IOMMU_CAP_CACHE_COHERENCY:
return true;
- case IOMMU_CAP_INTR_REMAP:
- return true; /* MSIs are just memory writes */
case IOMMU_CAP_NOEXEC:
return true;
default:
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a354572..13d2600 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1374,8 +1374,6 @@ static bool arm_smmu_capable(enum iommu_cap cap)
* requests.
*/
return true;
- case IOMMU_CAP_INTR_REMAP:
- return true; /* MSIs are just memory writes */
case IOMMU_CAP_NOEXEC:
return true;
default:
--
1.9.1
[PATCH v8 11/18] iommu/arm-smmu-v3: Implement reserved region get/put callbacks
iommu/arm-smmu: Implement reserved region get/put callbacks
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
Acked-by: Will Deacon
---
v7 -> v8:
- added Will's A-b
v4: creation
---
drivers/iommu/arm-smmu-v3.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4d6ec44..6c4111c 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -412,6 +412,9 @@
/* High-level queue structures */
#define ARM_SMMU_POLL_TIMEOUT_US 100
+#define MSI_IOVA_BASE 0x800
+#define MSI_IOVA_LENGTH0x10
+
static bool disable_bypass;
module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
MODULE_PARM_DESC(disable_bypass,
@@ -1883,6 +1886,29 @@ static int arm_smmu_of_xlate(struct device *dev, struct
of_phandle_args *args)
return iommu_fwspec_add_ids(dev, args->args, 1);
}
+static void arm_smmu_get_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct iommu_resv_region *region;
+ int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+
+ region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+prot, IOMMU_RESV_MSI);
+ if (!region)
+ return;
+
+ list_add_tail(®ion->list, head);
+}
+
+static void arm_smmu_put_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct iommu_resv_region *entry, *next;
+
+ list_for_each_entry_safe(entry, next, head, list)
+ kfree(entry);
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1898,6 +1924,8 @@ static int arm_smmu_of_xlate(struct device *dev, struct
of_phandle_args *args)
.domain_get_attr= arm_smmu_domain_get_attr,
.domain_set_attr= arm_smmu_domain_set_attr,
.of_xlate = arm_smmu_of_xlate,
+ .get_resv_regions = arm_smmu_get_resv_regions,
+ .put_resv_regions = arm_smmu_put_resv_regions,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
--
1.9.1
[PATCH v8 15/18] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
The GICv3 ITS is MSI remapping capable. Let's advertise this property so that VFIO passthrough can assess IRQ safety. Signed-off-by: Eric Auger Reviewed-by: Marc Zyngier --- v7 -> v8: - added Marc's R-b --- drivers/irqchip/irq-gic-v3-its.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 69b040f..9d4fefc 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1642,6 +1642,7 @@ static int its_init_domain(struct fwnode_handle *handle, struct its_node *its) inner_domain->parent = its_parent; inner_domain->bus_token = DOMAIN_BUS_NEXUS; + inner_domain->flags |= IRQ_DOMAIN_FLAG_MSI_REMAP; info->ops = &its_msi_domain_ops; info->data = its; inner_domain->host_data = info; -- 1.9.1
[PATCH v8 12/18] irqdomain: Add irq domain MSI and MSI_REMAP flags
We introduce two new enum values for the irq domain flag:
- IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
an MSI domain
- IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
remapping capabilities.
Those values will be useful to check all MSI irq domains have
MSI remapping support when assessing the safety of IRQ assignment
to a guest.
irq_domain_hierarchical_is_msi_remap() allows to check if an
irq domain or any parent implements MSI remapping.
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
---
v7 -> v8:
- remove h variable in irq_domain_hierarchical_is_msi_remap
- add Marc's R-b
v6:
- add IRQ_DOMAIN_FLAG_MSI as suggested by Marc
- add irq_domain_is_msi, irq_domain_is_msi_remap and
irq_domain_hierarchical_is_msi_remap
---
include/linux/irqdomain.h | 35 +++
kernel/irq/irqdomain.c| 14 ++
2 files changed, 49 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index ffb8460..bc2f571 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -183,6 +183,12 @@ enum {
/* Irq domain is an IPI domain with single virq */
IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
+ /* Irq domain implements MSIs */
+ IRQ_DOMAIN_FLAG_MSI = (1 << 4),
+
+ /* Irq domain implements MSI remapping */
+ IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
+
/*
* Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
* for implementation specific purposes and ignored by the
@@ -446,6 +452,19 @@ static inline bool irq_domain_is_ipi_single(struct
irq_domain *domain)
{
return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE;
}
+
+static inline bool irq_domain_is_msi(struct irq_domain *domain)
+{
+ return domain->flags & IRQ_DOMAIN_FLAG_MSI;
+}
+
+static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
+{
+ return domain->flags & IRQ_DOMAIN_FLAG_MSI_REMAP;
+}
+
+extern bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain);
+
#else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
static inline void irq_domain_activate_irq(struct irq_data *data) { }
static inline void irq_domain_deactivate_irq(struct irq_data *data) { }
@@ -477,6 +496,22 @@ static inline bool irq_domain_is_ipi_single(struct
irq_domain *domain)
{
return false;
}
+
+static inline bool irq_domain_is_msi(struct irq_domain *domain)
+{
+ return false;
+}
+
+static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
+{
+ return false;
+}
+
+static inline bool
+irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
+{
+ return false;
+}
#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
#else /* CONFIG_IRQ_DOMAIN */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8c0a0ae..876e131 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1392,6 +1392,20 @@ static void irq_domain_check_hierarchy(struct irq_domain
*domain)
if (domain->ops->alloc)
domain->flags |= IRQ_DOMAIN_FLAG_HIERARCHY;
}
+
+/**
+ * irq_domain_hierarchical_is_msi_remap - Check if the domain or any
+ * parent has MSI remapping support
+ * @domain: domain pointer
+ */
+bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
+{
+ for (; domain; domain = domain->parent) {
+ if (irq_domain_is_msi_remap(domain))
+ return true;
+ }
+ return false;
+}
#else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
/**
* irq_domain_get_irq_data - Get irq_data associated with @virq and @domain
--
1.9.1
[PATCH v8 17/18] vfio/type1: Check MSI remapping at irq domain level
In case the IOMMU translates MSI transactions (typical case
on ARM), we check MSI remapping capability at IRQ domain
level. Otherwise it is checked at IOMMU level.
At this stage the arm-smmu-(v3) still advertise the
IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
removed in subsequent patches.
Signed-off-by: Eric Auger
---
v6: rewrite test
---
drivers/vfio/vfio_iommu_type1.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5651faf..ec903a0 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define DRIVER_VERSION "0.2"
#define DRIVER_AUTHOR "Alex Williamson "
@@ -1212,7 +1213,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
struct vfio_domain *domain, *d;
struct bus_type *bus = NULL, *mdev_bus;
int ret;
- bool resv_msi;
+ bool resv_msi, msi_remap;
phys_addr_t resv_msi_base;
mutex_lock(&iommu->lock);
@@ -1288,8 +1289,10 @@ static int vfio_iommu_type1_attach_group(void
*iommu_data,
INIT_LIST_HEAD(&domain->group_list);
list_add(&group->next, &domain->group_list);
- if (!allow_unsafe_interrupts &&
- !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
+ msi_remap = resv_msi ? irq_domain_check_msi_remap() :
+ iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+
+ if (!allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support. Use the module
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this
platform\n",
__func__);
ret = -EPERM;
--
1.9.1
[PATCH v8 02/18] iommu: Rename iommu_dm_regions into iommu_resv_regions
We want to extend the callbacks used for dm regions and
use them for reserved regions. Reserved regions can be
- directly mapped regions
- regions that cannot be iommu mapped (PCI host bridge windows, ...)
- MSI regions (because they belong to another address space or because
they are not translated by the IOMMU and need special handling)
So let's rename the struct and also the callbacks.
Signed-off-by: Eric Auger
Acked-by: Robin Murphy
---
v3 -> v4:
- add Robin's A-b
---
drivers/iommu/amd_iommu.c | 20 ++--
drivers/iommu/iommu.c | 22 +++---
include/linux/iommu.h | 29 +++--
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 3ef0f42..f7a024f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3161,8 +3161,8 @@ static bool amd_iommu_capable(enum iommu_cap cap)
return false;
}
-static void amd_iommu_get_dm_regions(struct device *dev,
-struct list_head *head)
+static void amd_iommu_get_resv_regions(struct device *dev,
+ struct list_head *head)
{
struct unity_map_entry *entry;
int devid;
@@ -3172,7 +3172,7 @@ static void amd_iommu_get_dm_regions(struct device *dev,
return;
list_for_each_entry(entry, &amd_iommu_unity_map, list) {
- struct iommu_dm_region *region;
+ struct iommu_resv_region *region;
if (devid < entry->devid_start || devid > entry->devid_end)
continue;
@@ -3195,18 +3195,18 @@ static void amd_iommu_get_dm_regions(struct device *dev,
}
}
-static void amd_iommu_put_dm_regions(struct device *dev,
+static void amd_iommu_put_resv_regions(struct device *dev,
struct list_head *head)
{
- struct iommu_dm_region *entry, *next;
+ struct iommu_resv_region *entry, *next;
list_for_each_entry_safe(entry, next, head, list)
kfree(entry);
}
-static void amd_iommu_apply_dm_region(struct device *dev,
+static void amd_iommu_apply_resv_region(struct device *dev,
struct iommu_domain *domain,
- struct iommu_dm_region *region)
+ struct iommu_resv_region *region)
{
struct dma_ops_domain *dma_dom = to_dma_ops_domain(to_pdomain(domain));
unsigned long start, end;
@@ -3230,9 +3230,9 @@ static void amd_iommu_apply_dm_region(struct device *dev,
.add_device = amd_iommu_add_device,
.remove_device = amd_iommu_remove_device,
.device_group = amd_iommu_device_group,
- .get_dm_regions = amd_iommu_get_dm_regions,
- .put_dm_regions = amd_iommu_put_dm_regions,
- .apply_dm_region = amd_iommu_apply_dm_region,
+ .get_resv_regions = amd_iommu_get_resv_regions,
+ .put_resv_regions = amd_iommu_put_resv_regions,
+ .apply_resv_region = amd_iommu_apply_resv_region,
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
};
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index dbe7f65..1cee5c3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -318,7 +318,7 @@ static int iommu_group_create_direct_mappings(struct
iommu_group *group,
struct device *dev)
{
struct iommu_domain *domain = group->default_domain;
- struct iommu_dm_region *entry;
+ struct iommu_resv_region *entry;
struct list_head mappings;
unsigned long pg_size;
int ret = 0;
@@ -331,14 +331,14 @@ static int iommu_group_create_direct_mappings(struct
iommu_group *group,
pg_size = 1UL << __ffs(domain->pgsize_bitmap);
INIT_LIST_HEAD(&mappings);
- iommu_get_dm_regions(dev, &mappings);
+ iommu_get_resv_regions(dev, &mappings);
/* We need to consider overlapping regions for different devices */
list_for_each_entry(entry, &mappings, list) {
dma_addr_t start, end, addr;
- if (domain->ops->apply_dm_region)
- domain->ops->apply_dm_region(dev, domain, entry);
+ if (domain->ops->apply_resv_region)
+ domain->ops->apply_resv_region(dev, domain, entry);
start = ALIGN(entry->start, pg_size);
end = ALIGN(entry->start + entry->length, pg_size);
@@ -358,7 +358,7 @@ static int iommu_group_create_direct_mappings(struct
iommu_group *group,
}
out:
- iommu_put_dm_regions(dev, &mappings);
+ iommu_put_resv_regions(dev, &mappings);
return ret;
}
@@ -1559,20 +1559,20 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
}
EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
-void iommu_get_dm_regions(struct device *dev, struct list_head *list)
+void iommu_get_resv_regions(s
[PATCH v8 03/18] iommu: Add a new type field in iommu_resv_region
We introduce a new field to differentiate the reserved region
types and specialize the apply_resv_region implementation.
Legacy direct mapped regions have IOMMU_RESV_DIRECT type.
We introduce 2 new reserved memory types:
- IOMMU_RESV_MSI will characterize MSI regions that are mapped
- IOMMU_RESV_RESERVED characterize regions that cannot by mapped.
Signed-off-by: Eric Auger
---
v6 -> v7:
- rename IOMMU_RESV_NOMAP into IOMMU_RESV_RESERVED
---
drivers/iommu/amd_iommu.c | 1 +
include/linux/iommu.h | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f7a024f..5f7ea4f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3186,6 +3186,7 @@ static void amd_iommu_get_resv_regions(struct device *dev,
region->start = entry->address_start;
region->length = entry->address_end - entry->address_start;
+ region->type = IOMMU_RESV_DIRECT;
if (entry->prot & IOMMU_PROT_IR)
region->prot |= IOMMU_READ;
if (entry->prot & IOMMU_PROT_IW)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index bfecb8b..233a6bf 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -117,18 +117,25 @@ enum iommu_attr {
DOMAIN_ATTR_MAX,
};
+/* These are the possible reserved region types */
+#define IOMMU_RESV_DIRECT (1 << 0)
+#define IOMMU_RESV_RESERVED(1 << 1)
+#define IOMMU_RESV_MSI (1 << 2)
+
/**
* struct iommu_resv_region - descriptor for a reserved memory region
* @list: Linked list pointers
* @start: System physical start address of the region
* @length: Length of the region in bytes
* @prot: IOMMU Protection flags (READ/WRITE/...)
+ * @type: Type of the reserved region
*/
struct iommu_resv_region {
struct list_headlist;
phys_addr_t start;
size_t length;
int prot;
+ int type;
};
#ifdef CONFIG_IOMMU_API
--
1.9.1
[PATCH v8 07/18] iommu: Implement reserved_regions iommu-group sysfs file
A new iommu-group sysfs attribute file is introduced. It contains
the list of reserved regions for the iommu-group. Each reserved
region is described on a separate line:
- first field is the start IOVA address,
- second is the end IOVA address,
- third is the type.
Signed-off-by: Eric Auger
---
v7 -> v8:
- remove iommu_group_remove_file() in iommu_group_release since
the /sys/kernel/iommu_groups/n directory seems to be removed
already
v6 -> v7:
- also report the type of the reserved region as a string
- updated ABI documentation
v3 -> v4:
- add cast to long long int when printing to avoid warning on
i386
- change S_IRUGO into 0444
- remove sort. The list is natively sorted now.
The file layout is inspired of /sys/bus/pci/devices/BDF/resource.
I also read Documentation/filesystems/sysfs.txt so I expect this
to be frowned upon.
---
.../ABI/testing/sysfs-kernel-iommu_groups | 12
drivers/iommu/iommu.c | 36 ++
2 files changed, 48 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups
b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
index 9b31556..35c64e0 100644
--- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups
+++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
@@ -12,3 +12,15 @@ Description: /sys/kernel/iommu_groups/ contains a number of
sub-
file if the IOMMU driver has chosen to register a more
common name for the group.
Users:
+
+What: /sys/kernel/iommu_groups/reserved_regions
+Date: January 2017
+KernelVersion: v4.11
+Contact: Eric Auger
+Description:/sys/kernel/iommu_groups/reserved_regions list IOVA
+ regions that are reserved. Not necessarily all
+ reserved regions are listed. This is typically used to
+ output direct-mapped, MSI, non mappable regions. Each
+ region is described on a single line: the 1st field is
+ the base IOVA, the second is the end IOVA and the third
+ field describes the type of the region.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 640056b..f4a176e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -68,6 +68,12 @@ struct iommu_group_attribute {
const char *buf, size_t count);
};
+static const char * const iommu_group_resv_type_string[] = {
+ [IOMMU_RESV_DIRECT] = "direct",
+ [IOMMU_RESV_RESERVED] = "reserved",
+ [IOMMU_RESV_MSI]= "msi",
+};
+
#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \
struct iommu_group_attribute iommu_group_attr_##_name =\
__ATTR(_name, _mode, _show, _store)
@@ -231,8 +237,33 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
}
EXPORT_SYMBOL_GPL(iommu_get_group_resv_regions);
+static ssize_t iommu_group_show_resv_regions(struct iommu_group *group,
+char *buf)
+{
+ struct iommu_resv_region *region, *next;
+ struct list_head group_resv_regions;
+ char *str = buf;
+
+ INIT_LIST_HEAD(&group_resv_regions);
+ iommu_get_group_resv_regions(group, &group_resv_regions);
+
+ list_for_each_entry_safe(region, next, &group_resv_regions, list) {
+ str += sprintf(str, "0x%016llx 0x%016llx %s\n",
+ (long long int)region->start,
+ (long long int)(region->start +
+ region->length - 1),
+ iommu_group_resv_type_string[region->type]);
+ kfree(region);
+ }
+
+ return (str - buf);
+}
+
static IOMMU_GROUP_ATTR(name, S_IRUGO, iommu_group_show_name, NULL);
+static IOMMU_GROUP_ATTR(reserved_regions, 0444,
+ iommu_group_show_resv_regions, NULL);
+
static void iommu_group_release(struct kobject *kobj)
{
struct iommu_group *group = to_iommu_group(kobj);
@@ -310,6 +341,11 @@ struct iommu_group *iommu_group_alloc(void)
*/
kobject_put(&group->kobj);
+ ret = iommu_group_create_file(group,
+ &iommu_group_attr_reserved_regions);
+ if (ret)
+ return ERR_PTR(ret);
+
pr_debug("Allocated group %d\n", group->id);
return group;
--
1.9.1
[PATCH v8 09/18] iommu/amd: Declare MSI and HT regions as reserved IOVA regions
This patch registers the MSI and HT regions as non mappable
reserved regions. They will be exposed in the iommu-group sysfs.
For direct-mapped regions let's also use iommu_alloc_resv_region().
Signed-off-by: Eric Auger
---
v6 -> v7:
- use IOMMU_RESV_RESERVED
v5: creation
---
drivers/iommu/amd_iommu.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 5f7ea4f..d109e41 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3164,6 +3164,7 @@ static bool amd_iommu_capable(enum iommu_cap cap)
static void amd_iommu_get_resv_regions(struct device *dev,
struct list_head *head)
{
+ struct iommu_resv_region *region;
struct unity_map_entry *entry;
int devid;
@@ -3172,28 +3173,42 @@ static void amd_iommu_get_resv_regions(struct device
*dev,
return;
list_for_each_entry(entry, &amd_iommu_unity_map, list) {
- struct iommu_resv_region *region;
+ size_t length;
+ int prot = 0;
if (devid < entry->devid_start || devid > entry->devid_end)
continue;
- region = kzalloc(sizeof(*region), GFP_KERNEL);
+ length = entry->address_end - entry->address_start;
+ if (entry->prot & IOMMU_PROT_IR)
+ prot |= IOMMU_READ;
+ if (entry->prot & IOMMU_PROT_IW)
+ prot |= IOMMU_WRITE;
+
+ region = iommu_alloc_resv_region(entry->address_start,
+length, prot,
+IOMMU_RESV_DIRECT);
if (!region) {
pr_err("Out of memory allocating dm-regions for %s\n",
dev_name(dev));
return;
}
-
- region->start = entry->address_start;
- region->length = entry->address_end - entry->address_start;
- region->type = IOMMU_RESV_DIRECT;
- if (entry->prot & IOMMU_PROT_IR)
- region->prot |= IOMMU_READ;
- if (entry->prot & IOMMU_PROT_IW)
- region->prot |= IOMMU_WRITE;
-
list_add_tail(®ion->list, head);
}
+
+ region = iommu_alloc_resv_region(MSI_RANGE_START,
+MSI_RANGE_END - MSI_RANGE_START + 1,
+0, IOMMU_RESV_RESERVED);
+ if (!region)
+ return;
+ list_add_tail(®ion->list, head);
+
+ region = iommu_alloc_resv_region(HT_RANGE_START,
+HT_RANGE_END - HT_RANGE_START + 1,
+0, IOMMU_RESV_RESERVED);
+ if (!region)
+ return;
+ list_add_tail(®ion->list, head);
}
static void amd_iommu_put_resv_regions(struct device *dev,
--
1.9.1
[PATCH v8 01/18] iommu/dma: Allow MSI-only cookies
From: Robin Murphy
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 119 +-
include/linux/dma-iommu.h | 6 +++
2 files changed, 102 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 2db0d64..de41ead 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,15 +37,50 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_headmsi_page_list;
- spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
+ union {
+ /* Full allocator for IOMMU_DMA_IOVA_COOKIE */
+ struct iova_domain iovad;
+ /* Trivial linear page allocator for IOMMU_DMA_MSI_COOKIE */
+ dma_addr_t msi_iova;
+ };
+ struct list_headmsi_page_list;
+ spinlock_t msi_lock;
};
+static inline size_t cookie_msi_granule(struct iommu_dma_cookie *cookie)
+{
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE)
+ return cookie->iovad.granule;
+ return PAGE_SIZE;
+}
+
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
{
- return &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad;
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE)
+ return &cookie->iovad;
+ return NULL;
+}
+
+static struct iommu_dma_cookie *cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
}
int iommu_dma_init(void)
@@ -62,25 +97,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ domain->iova_cookie = cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_dma_cookie);
+
+/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
struct iommu_dma_cookie *cookie;
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ cookie = cookie_alloc(IOMMU_DMA_MSI_COOKIE);
if (!cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->msi_iova = base;
domain->iova_cookie = cookie;
return 0;
}
-EXPORT_SYMBOL(iommu_get_dma_cookie);
+EXPORT_SYMBOL(iommu_get_msi_cookie);
/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +155,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie-
[PATCH v8 08/18] iommu/vt-d: Implement reserved region get/put callbacks
This patch registers the [FEE0_h - FEF0_000h] 1MB MSI
range as a reserved region and RMRR regions as direct regions.
This will allow to report those reserved regions in the
iommu-group sysfs.
Signed-off-by: Eric Auger
---
v6 -> v7:
- report RMRR regions as direct regions
- Due to the usage of rcu_read_lock, the rmrr reserved region
allocation is done on rmrr allocation.
- use IOMMU_RESV_RESERVED
RFCv2 -> RFCv3:
- use get/put_resv_region callbacks.
RFC v1 -> RFC v2:
- fix intel_iommu_add_reserved_regions name
- use IOAPIC_RANGE_START and IOAPIC_RANGE_END defines
- return if the MSI region is already registered;
---
drivers/iommu/intel-iommu.c | 92 -
1 file changed, 74 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 8a18525..bce59a5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -440,6 +440,7 @@ struct dmar_rmrr_unit {
u64 end_address;/* reserved end address */
struct dmar_dev_scope *devices; /* target devices */
int devices_cnt;/* target device count */
+ struct iommu_resv_region *resv; /* reserved region handle */
};
struct dmar_atsr_unit {
@@ -4246,27 +4247,40 @@ static inline void init_iommu_pm_ops(void) {}
int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg)
{
struct acpi_dmar_reserved_memory *rmrr;
+ int prot = DMA_PTE_READ|DMA_PTE_WRITE;
struct dmar_rmrr_unit *rmrru;
+ size_t length;
rmrru = kzalloc(sizeof(*rmrru), GFP_KERNEL);
if (!rmrru)
- return -ENOMEM;
+ goto out;
rmrru->hdr = header;
rmrr = (struct acpi_dmar_reserved_memory *)header;
rmrru->base_address = rmrr->base_address;
rmrru->end_address = rmrr->end_address;
+
+ length = rmrr->end_address - rmrr->base_address + 1;
+ rmrru->resv = iommu_alloc_resv_region(rmrr->base_address, length, prot,
+ IOMMU_RESV_DIRECT);
+ if (!rmrru->resv)
+ goto free_rmrru;
+
rmrru->devices = dmar_alloc_dev_scope((void *)(rmrr + 1),
((void *)rmrr) + rmrr->header.length,
&rmrru->devices_cnt);
- if (rmrru->devices_cnt && rmrru->devices == NULL) {
- kfree(rmrru);
- return -ENOMEM;
- }
+ if (rmrru->devices_cnt && rmrru->devices == NULL)
+ goto free_all;
list_add(&rmrru->list, &dmar_rmrr_units);
return 0;
+free_all:
+ kfree(rmrru->resv);
+free_rmrru:
+ kfree(rmrru);
+out:
+ return -ENOMEM;
}
static struct dmar_atsr_unit *dmar_find_atsr(struct acpi_dmar_atsr *atsr)
@@ -4480,6 +4494,7 @@ static void intel_iommu_free_dmars(void)
list_for_each_entry_safe(rmrru, rmrr_n, &dmar_rmrr_units, list) {
list_del(&rmrru->list);
dmar_free_dev_scope(&rmrru->devices, &rmrru->devices_cnt);
+ kfree(rmrru->resv);
kfree(rmrru);
}
@@ -5203,6 +5218,45 @@ static void intel_iommu_remove_device(struct device *dev)
iommu_device_unlink(iommu->iommu_dev, dev);
}
+static void intel_iommu_get_resv_regions(struct device *device,
+struct list_head *head)
+{
+ struct iommu_resv_region *reg;
+ struct dmar_rmrr_unit *rmrr;
+ struct device *i_dev;
+ int i;
+
+ rcu_read_lock();
+ for_each_rmrr_units(rmrr) {
+ for_each_active_dev_scope(rmrr->devices, rmrr->devices_cnt,
+ i, i_dev) {
+ if (i_dev != device)
+ continue;
+
+ list_add_tail(&rmrr->resv->list, head);
+ }
+ }
+ rcu_read_unlock();
+
+ reg = iommu_alloc_resv_region(IOAPIC_RANGE_START,
+ IOAPIC_RANGE_END - IOAPIC_RANGE_START + 1,
+ 0, IOMMU_RESV_RESERVED);
+ if (!reg)
+ return;
+ list_add_tail(®->list, head);
+}
+
+static void intel_iommu_put_resv_regions(struct device *dev,
+struct list_head *head)
+{
+ struct iommu_resv_region *entry, *next;
+
+ list_for_each_entry_safe(entry, next, head, list) {
+ if (entry->type == IOMMU_RESV_RESERVED)
+ kfree(entry);
+ }
+}
+
#ifdef CONFIG_INTEL_IOMMU_SVM
#define MAX_NR_PASID_BITS (20)
static inline unsigned long intel_iommu_get_pts(struct intel_iommu *iommu)
@@ -5333,19 +5387,21 @@ struct intel_iommu *intel_svm_device_to_iommu(struct
device *dev)
#endif /* CONFIG_INTEL_IOMMU_SVM */
static const struct iommu_ops intel_iommu_ops = {
- .capable= intel_iommu_capable,
- .domain_alloc = intel_iom
[PATCH v8 05/18] iommu: Only map direct mapped regions
As we introduced new reserved region types which do not require
mapping, let's make sure we only map direct mapped regions.
Signed-off-by: Eric Auger
---
v3 -> v4:
- use region's type and reword commit message and title
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 927878d..41c1906 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -343,6 +343,9 @@ static int iommu_group_create_direct_mappings(struct
iommu_group *group,
start = ALIGN(entry->start, pg_size);
end = ALIGN(entry->start + entry->length, pg_size);
+ if (entry->type != IOMMU_RESV_DIRECT)
+ continue;
+
for (addr = start; addr < end; addr += pg_size) {
phys_addr_t phys_addr;
--
1.9.1
[PATCH v8 04/18] iommu: iommu_alloc_resv_region
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.
Signed-off-by: Eric Auger
---
v3 -> v4:
- add INIT_LIST_HEAD(®ion->list)
- use int for prot param and add int type param
- remove implementation outside of CONFIG_IOMMU_API
---
drivers/iommu/iommu.c | 18 ++
include/linux/iommu.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1cee5c3..927878d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1575,6 +1575,24 @@ void iommu_put_resv_regions(struct device *dev, struct
list_head *list)
ops->put_resv_regions(dev, list);
}
+struct iommu_resv_region *iommu_alloc_resv_region(phys_addr_t start,
+ size_t length,
+ int prot, int type)
+{
+ struct iommu_resv_region *region;
+
+ region = kzalloc(sizeof(*region), GFP_KERNEL);
+ if (!region)
+ return NULL;
+
+ INIT_LIST_HEAD(®ion->list);
+ region->start = start;
+ region->length = length;
+ region->prot = prot;
+ region->type = type;
+ return region;
+}
+
/* Request that a device is direct mapped by the IOMMU */
int iommu_request_dm_for_dev(struct device *dev)
{
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 233a6bf..f6bb55d3 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -244,6 +244,8 @@ extern void iommu_set_fault_handler(struct iommu_domain
*domain,
extern void iommu_get_resv_regions(struct device *dev, struct list_head *list);
extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
extern int iommu_request_dm_for_dev(struct device *dev);
+extern struct iommu_resv_region *
+iommu_alloc_resv_region(phys_addr_t start, size_t length, int prot, int type);
extern int iommu_attach_group(struct iommu_domain *domain,
struct iommu_group *group);
--
1.9.1
[PATCH v8 06/18] iommu: iommu_get_group_resv_regions
Introduce iommu_get_group_resv_regions whose role consists in
enumerating all devices from the group and collecting their
reserved regions. The list is sorted and overlaps between
regions of the same type are handled by merging the regions.
Signed-off-by: Eric Auger
---
v6 -> v7:
- avoid merge of regions of different type
v3 -> v4:
- take the iommu_group lock in iommu_get_group_resv_regions
- the list now is sorted and overlaps are checked
NOTE:
- we do not move list elements from device to group list since
the iommu_put_resv_regions() could not be called.
- at the moment I did not introduce any iommu_put_group_resv_regions
since it simply consists in voiding/freeing the list
---
drivers/iommu/iommu.c | 98 +++
include/linux/iommu.h | 8 +
2 files changed, 106 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 41c1906..640056b 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -133,6 +133,104 @@ static ssize_t iommu_group_show_name(struct iommu_group
*group, char *buf)
return sprintf(buf, "%s\n", group->name);
}
+/**
+ * iommu_insert_resv_region - Insert a new region in the
+ * list of reserved regions.
+ * @new: new region to insert
+ * @regions: list of regions
+ *
+ * The new element is sorted by address with respect to the other
+ * regions of the same type. In case it overlaps with another
+ * region of the same type, regions are merged. In case it
+ * overlaps with another region of different type, regions are
+ * not merged.
+ */
+static int iommu_insert_resv_region(struct iommu_resv_region *new,
+ struct list_head *regions)
+{
+ struct iommu_resv_region *region;
+ phys_addr_t start = new->start;
+ phys_addr_t end = new->start + new->length - 1;
+ struct list_head *pos = regions->next;
+
+ while (pos != regions) {
+ struct iommu_resv_region *entry =
+ list_entry(pos, struct iommu_resv_region, list);
+ phys_addr_t a = entry->start;
+ phys_addr_t b = entry->start + entry->length - 1;
+ int type = entry->type;
+
+ if (end < a) {
+ goto insert;
+ } else if (start > b) {
+ pos = pos->next;
+ } else if ((start >= a) && (end <= b)) {
+ if (new->type == type)
+ goto done;
+ else
+ pos = pos->next;
+ } else {
+ if (new->type == type) {
+ phys_addr_t new_start = min(a, start);
+ phys_addr_t new_end = max(b, end);
+
+ list_del(&entry->list);
+ entry->start = new_start;
+ entry->length = new_end - new_start + 1;
+ iommu_insert_resv_region(entry, regions);
+ } else {
+ pos = pos->next;
+ }
+ }
+ }
+insert:
+ region = iommu_alloc_resv_region(new->start, new->length,
+new->prot, new->type);
+ if (!region)
+ return -ENOMEM;
+
+ list_add_tail(®ion->list, pos);
+done:
+ return 0;
+}
+
+static int
+iommu_insert_device_resv_regions(struct list_head *dev_resv_regions,
+struct list_head *group_resv_regions)
+{
+ struct iommu_resv_region *entry;
+ int ret;
+
+ list_for_each_entry(entry, dev_resv_regions, list) {
+ ret = iommu_insert_resv_region(entry, group_resv_regions);
+ if (ret)
+ break;
+ }
+ return ret;
+}
+
+int iommu_get_group_resv_regions(struct iommu_group *group,
+struct list_head *head)
+{
+ struct iommu_device *device;
+ int ret = 0;
+
+ mutex_lock(&group->mutex);
+ list_for_each_entry(device, &group->devices, list) {
+ struct list_head dev_resv_regions;
+
+ INIT_LIST_HEAD(&dev_resv_regions);
+ iommu_get_resv_regions(device->dev, &dev_resv_regions);
+ ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
+ iommu_put_resv_regions(device->dev, &dev_resv_regions);
+ if (ret)
+ break;
+ }
+ mutex_unlock(&group->mutex);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_get_group_resv_regions);
+
static IOMMU_GROUP_ATTR(name, S_IRUGO, iommu_group_show_name, NULL);
static void iommu_group_release(struct kobject *kobj)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f6bb55d3..bec3730 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -246,6 +246,8 @@ extern void iommu_s
Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks
On Wed, 11 Jan 2017, Joe Perches wrote:
> On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2017, Joe Perches wrote:
>> > Make these files symlinks to the .rst equivalents
>>
>> If we're going to do this (and I really don't mind either way), then
>> please add
>>
>> Fixes: 08a9a8d44c1c ("doc: re-add CodingStyle and SubmittingPatches")
With this I'm merely saying that wherever 08a9a8d44c1c ends up, this
patch should end up too (if we want symlinks that is). There's enough
confusion with the renames already, I'd like to ensure that v4.10
doesn't end up having one thing, and the future another.
BR,
Jani.
>
> I don't believe this patch "fixes" the other, it just makes it
> possible to continue to write "Read Documentation/CodingStyle"
> or "Read Documentation/SubmittingPatches" to people that
> submit poorly formatted or improper patches.
>
> I attempted to do that a bit ago but then had to write out the
> Documentation/process/.rst equivalents instead.
>
--
Jani Nikula, Intel Open Source Technology Center
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
On Wed, Jan 11, 2017 at 04:42:16AM +0100, Rafael J. Wysocki wrote:
> Let's try the attached one.
Works, thanks. Lemme give you the tags :)
Reported-and-tested-by: Borislav Petkov
Fixes: 174cc7187e6f ("ACPICA: Tables: Back port acpi_get_table_with_size() and
early_acpi_os_unmap_memory() from Linux kernel")
Link: https://lkml.kernel.org/r/4034dde8-ffc1-18e2-f40c-00cf37471...@intel.com
> BTW, I'm going to travel to the LCA starting tomorrow, so I guess I
> will be a bit unresponsive during the next few days.
Sure, we have time. Have a safe trip!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH v3] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxm-s912-q201 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxl-s905d-p231 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxl-nexbox-a95x : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
[2]
http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x1000 0x0 0x20>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..adcaf0b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x4000>;
+ /*
+* The first 16MiB and last 16MiB of the DDR memory
+* are reserved to the Hardware ROM Firmware
+*/
+ linux,usable-memory = <0x0 0x100 0x0 0x3f00>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..9d45fe6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>;
+ /*
+* The first 16MiB and last 16MiB of the DDR memory
+* are reserved to the Hardware ROM Firmware
+*/
+ linux,usable
[tip:timers/urgent] nohz: Fix collision between tick and other hrtimers
Commit-ID: 24b91e360ef521a2808771633d76ebc68bd5604b
Gitweb: http://git.kernel.org/tip/24b91e360ef521a2808771633d76ebc68bd5604b
Author: Frederic Weisbecker
AuthorDate: Wed, 4 Jan 2017 15:12:04 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 11 Jan 2017 10:41:33 +0100
nohz: Fix collision between tick and other hrtimers
When the tick is stopped and an interrupt occurs afterward, we check on
that interrupt exit if the next tick needs to be rescheduled. If it
doesn't need any update, we don't want to do anything.
In order to check if the tick needs an update, we compare it against the
clockevent device deadline. Now that's a problem because the clockevent
device is at a lower level than the tick itself if it is implemented
on top of hrtimer.
Every hrtimer share this clockevent device. So comparing the next tick
deadline against the clockevent device deadline is wrong because the
device may be programmed for another hrtimer whose deadline collides
with the tick. As a result we may end up not reprogramming the tick
accidentally.
In a worst case scenario under full dynticks mode, the tick stops firing
as it is supposed to every 1hz, leaving /proc/stat stalled:
Task in a full dynticks CPU
* hrtimer A is queued 2 seconds ahead
* the tick is stopped, scheduled 1 second ahead
* tick fires 1 second later
* on tick exit, nohz schedules the tick 1 second ahead but sees
the clockevent device is already programmed to that deadline,
fooled by hrtimer A, the tick isn't rescheduled.
* hrtimer A is cancelled before its deadline
* tick never fires again until an interrupt happens...
In order to fix this, store the next tick deadline to the tick_sched
local structure and reuse that value later to check whether we need to
reprogram the clock after an interrupt.
On the other hand, ts->sleep_length still wants to know about the next
clock event and not just the tick, so we want to improve the related
comment to avoid confusion.
Reported-by: James Hartsock
Signed-off-by: Frederic Weisbecker
Reviewed-by: Wanpeng Li
Acked-by: Peter Zijlstra
Acked-by: Rik van Riel
Link:
http://lkml.kernel.org/r/1483539124-5693-1-git-send-email-fweis...@gmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-sched.c | 9 +++--
kernel/time/tick-sched.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 2c115fd..74e0388 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -767,7 +767,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
tick = expires;
/* Skip reprogram of event if its not changed */
- if (ts->tick_stopped && (expires == dev->next_event))
+ if (ts->tick_stopped && (expires == ts->next_tick))
goto out;
/*
@@ -787,6 +787,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
trace_tick_stop(1, TICK_DEP_MASK_NONE);
}
+ ts->next_tick = tick;
+
/*
* If the expiration time == KTIME_MAX, then we simply stop
* the tick timer.
@@ -802,7 +804,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
else
tick_program_event(tick, 1);
out:
- /* Update the estimated sleep length */
+ /*
+* Update the estimated sleep length until the next timer
+* (not only the tick).
+*/
ts->sleep_length = ktime_sub(dev->next_event, now);
return tick;
}
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
index bf38226..075444e 100644
--- a/kernel/time/tick-sched.h
+++ b/kernel/time/tick-sched.h
@@ -27,6 +27,7 @@ enum tick_nohz_mode {
* timer is modified for nohz sleeps. This is necessary
* to resume the tick timer operation in the timeline
* when the CPU returns from nohz sleep.
+ * @next_tick: Next tick to be fired when in dynticks mode.
* @tick_stopped: Indicator that the idle tick has been stopped
* @idle_jiffies: jiffies at the entry to idle for idle time accounting
* @idle_calls:Total number of idle calls
@@ -44,6 +45,7 @@ struct tick_sched {
unsigned long check_clocks;
enum tick_nohz_mode nohz_mode;
ktime_t last_tick;
+ ktime_t next_tick;
int inidle;
int tick_stopped;
unsigned long idle_jiffies;
RE: Dell XPS13 does not suspend with Linux 4.10-rc3
> Subject: Re: Dell XPS13 does not suspend with Linux 4.10-rc3
>
> On 01/11/17 10:36, Greg Kroah-Hartman wrote:
> > On Wed, Jan 11, 2017 at 09:53:38AM +0100, Paul Menzel wrote:
>
> >> On 01/10/17 23:24, Jan Niehusmann wrote:
> >>> On Tue, Jan 10, 2017 at 09:43:31PM +0100, Jan Niehusmann wrote:
> And I bisected the issue to commit 7279b238ba, "mei: send OS type
> to the FW"
> >>>
> >>> Indeed, just disabling the FIXUP implemented by that commit fixes
> >>> suspend for me, with 4.10.0-rc3. Btw, this is on a Thinkpad x201s.
> >>>
> >>> (For the addressees newly added to cc, it seems like the mentioned
> >>> commit breaks suspend to ram on Dell XPS13 and Thinkpad x201s)
> >>>
> >>> --- a/drivers/misc/mei/bus-fixup.c
> >>> +++ b/drivers/misc/mei/bus-fixup.c
> >>> @@ -406,3 +406,3 @@ static struct mei_fixup {
> >>> MEI_FIXUP(MEI_UUID_WD, mei_wd),
> >>> - MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
> >>> +// MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
> >>> };
> >>>
> >>>
> >>> I don't know what this may break, as the description of 7279b23 just
> >>> says:
> >>> "This workaround was added to support other broken OS and we need to
> >>> follow here."
> >>>
> >>> Unless there is a better justification, I think the commit should be
> >>> reverted, for now.
> >>
> >> Somebody else already created the bug 192051 in the Linux Kernel Bug
> >> Tracker [1].
> >
> > There's a fix for this in my tree to go to Linus for 4.10-rc4.
>
> Yes, Tomas referenced it in the bug report. I test it on the Dell XPS13
> (9360) now.
>
> I would have liked if it mentioned suspend issues, and the known broken
> devices in the commit message. That way, I would have found the commit
> more easily.
Yep, I should probably add that info about the suspend issue, but looks like
we broke the whole gen of older devices so we cannot list all of them :(
Tomas
Re: Dell XPS13 does not suspend with Linux 4.10-rc3
On 01/11/17 10:36, Greg Kroah-Hartman wrote:
On Wed, Jan 11, 2017 at 09:53:38AM +0100, Paul Menzel wrote:
On 01/10/17 23:24, Jan Niehusmann wrote:
On Tue, Jan 10, 2017 at 09:43:31PM +0100, Jan Niehusmann wrote:
And I bisected the issue to commit 7279b238ba, "mei: send OS type to the
FW"
Indeed, just disabling the FIXUP implemented by that commit fixes
suspend for me, with 4.10.0-rc3. Btw, this is on a Thinkpad x201s.
(For the addressees newly added to cc, it seems like the mentioned
commit breaks suspend to ram on Dell XPS13 and Thinkpad x201s)
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -406,3 +406,3 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_WD, mei_wd),
- MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+// MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
};
I don't know what this may break, as the description of 7279b23 just
says:
"This workaround was added to support other broken OS and we need to
follow here."
Unless there is a better justification, I think the commit should be
reverted, for now.
Somebody else already created the bug 192051 in the Linux Kernel Bug Tracker
[1].
There's a fix for this in my tree to go to Linus for 4.10-rc4.
Yes, Tomas referenced it in the bug report. I test it on the Dell XPS13
(9360) now.
I would have liked if it mentioned suspend issues, and the known broken
devices in the commit message. That way, I would have found the commit
more easily.
Kind regards,
Paul
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
On Wed, Jan 11, 2017 at 10:21:06AM +0100, Borislav Petkov wrote:
> On Mon, Jan 09, 2017 at 09:51:29PM -0800, Paul E. McKenney wrote:
> > Definitely.
>
> Btw, we have more breakage from RCU expedited using workqueues:
> https://bugzilla.kernel.org/show_bug.cgi?id=192111
>
> I've added you to CC but let me have other bug reporters confirm reverting
>
> 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
>
> does fix the issue for them too.
Yes, you could make RCU expedited grace periods go back to using the
requesting task, and that would allow expedited grace periods to run early
in the boot process. But that causes problems with signals and the like
unless you revert a few other patches. The bugzilla is interesting --
it looks like ACPI was in some cases doing early-boot grace-period waits
some time back?
I have a limping prototype RCU patch that should avoid this problem.
If all goes well, I will send it out late tomorrow evening, Pacific Time.
Thanx, Paul
[PATCH RESEND] splice: introduce FMODE_SPLICE_READ and FMODE_SPLICE_WRITE
Introduce FMODE_SPLICE_READ and FMODE_SPLICE_WRITE. These modes check
whether it is legal to read or write a file using splice. Both get
automatically set on regular files and are not checked when a 'struct
fileoperations' includes the splice_{read,write} methods.
Suggested-by: Linus Torvalds
Cc: Al Viro
Signed-off-by: Johannes Thumshirn
---
fs/open.c | 4
fs/splice.c| 6 ++
include/linux/fs.h | 5 +
3 files changed, 15 insertions(+)
diff --git a/fs/open.c b/fs/open.c
index 9921f70..b71259c 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -733,6 +733,10 @@ static int do_dentry_open(struct file *f,
if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
f->f_mode |= FMODE_ATOMIC_POS;
+ if (S_ISREG(inode->i_mode))
+ f->f_mode |= FMODE_SPLICE_WRITE | FMODE_SPLICE_READ;
+
+
f->f_op = fops_get(inode->i_fop);
if (unlikely(WARN_ON(!f->f_op))) {
error = -ENODEV;
diff --git a/fs/splice.c b/fs/splice.c
index 873d831..b0cfcb2 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -397,6 +397,9 @@ static ssize_t default_file_splice_read(struct file *in,
loff_t *ppos,
if (pipe->nrbufs == pipe->buffers)
return -EAGAIN;
+ if (unlikely(!(in->f_mode & FMODE_SPLICE_READ)))
+ return -EINVAL;
+
/*
* Try to keep page boundaries matching to source pagecache ones -
* it probably won't be much help, but...
@@ -825,6 +828,9 @@ static ssize_t default_file_splice_write(struct
pipe_inode_info *pipe,
{
ssize_t ret;
+ if (unlikely(!(out->f_mode & FMODE_SPLICE_WRITE)))
+ return -EINVAL;
+
ret = splice_from_pipe(pipe, out, ppos, len, flags, write_pipe_buf);
if (ret > 0)
*ppos += ret;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2ba0743..30477c5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -143,6 +143,11 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t
offset,
/* File was opened by fanotify and shouldn't generate fanotify events */
#define FMODE_NONOTIFY ((__force fmode_t)0x400)
+/* File can be read using splice */
+#define FMODE_SPLICE_READ ((__force fmode_t)0x800)
+/* File can be written using splice */
+#define FMODE_SPLICE_WRITE ((__force fmode_t)0x1000)
+
/*
* Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector
* that indicates that they should check the contents of the iovec are
--
1.8.5.6
[RESEND PATCH v3] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
[2]
http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
[3]
http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstr...@baylibre.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x1000 0x0 0x20>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..adcaf0b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x4000>;
+ /*
+* The first 16MiB and last 16MiB of the DDR memory
+* are reserved to the Hardware ROM Firmware
+*/
+ linux,usable-memory = <0x0 0x100 0x0 0x3f00>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..9d45fe6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>;
+ /*
+
Re: [PATCH v4 2/8] PCI: Allow runtime PM on Thunderbolt ports
On Sun, Jan 08, 2017 at 09:41:45AM +0100, Lukas Wunner wrote: > Currently PCIe ports are only allowed to go to D3 if the BIOS is dated > 2015 or newer to avoid potential issues with old chipsets. However for > Thunderbolt we know that even the oldest controller, Light Ridge (2010), > is able to suspend its ports to D3 just fine. > > We're about to add runtime PM for Thunderbolt on the Mac. Apple has > released two EFI security updates in 2015 which encompass all machines > with Thunderbolt, but the achieved power saving should be made available > to users even if they haven't updated their BIOS. To this end, > special-case Thunderbolt in pci_bridge_d3_possible(). > > This allows the Thunderbolt controller to power down but the root port > to which the Thunderbolt controller is attached remains in D0 unless > the EFI update is installed. Users can pass pcie_port_pm=force on the > kernel command line if they cannot install the EFI update but still want > to benefit from the additional power saving of putting the root port > into D3. In practice, root ports can be suspended to D3 without issues > at least on 2012 Ivy Bridge machines. > > If the BIOS cut-off date is ever lowered to 2010, the Thunderbolt > special case can be removed. > > Cc: Mika Westerberg Reviewed-by: Mika Westerberg
Re: [PATCH tip/master v4] kprobes: extable: Identify kprobes' insn-slots as kernel text area
On Tue, 10 Jan 2017 15:42:07 -0600 Josh Poimboeuf wrote: > On Tue, Jan 10, 2017 at 09:59:23AM +0100, Peter Zijlstra wrote: > > On Mon, Jan 09, 2017 at 11:36:48AM -0600, Josh Poimboeuf wrote: > > > BTW, I think we'll have more problems with generated code if/when we > > > move to an x86 DWARF unwinder, because it won't have any idea how to > > > unwind past generated code. Long term I wonder if it would make sense > > > to create some kind of framework for creating or registering generated > > > code, so we can solve these types of problems in a single place. > > > > Yes, this seems like a good idea. Maybe we could pull the rbtree thing > > from modules and make that a more generic interface for code > > registration. > > Yeah, a generic fast lookup for module+generated code could be useful. > It would also be nice to associate names with generated functions and > integrate that with kallsyms. For DWARF we would also need a way to > associate CFI metadata with address ranges. >From the kprobe point of view, kallsyms and DWARF seems a bit overkill. At least for kprobe insn slots, I think one symbol per page instead of each entry will be better and CFI also should be generated for each call. Thank you, -- Masami Hiramatsu
RE: [PATCH v4 1/8] PCI: Recognize Thunderbolt devices
>
> On Sun, Jan 08, 2017 at 10:23:03AM +, Winkler, Tomas wrote:
> > > We're about to allow runtime PM on Thunderbolt ports in
> > > pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host
> > > hotplug ports in pci_dev_check_d3cold(). In both cases we need to
> > > uniquely identify if a PCI device belongs to a Thunderbolt controller.
> > >
> > > We also have the need to detect presence of a Thunderbolt controller
> > > in drivers/platform/x86/apple-gmux.c because dual GPU MacBook Pros
> > > cannot switch external DP/HDMI ports between GPUs if they have
> Thunderbolt.
> > >
> > > Furthermore, in multiple places in the DRM subsystem we need to
> > > detect whether a GPU is on-board or attached with Thunderbolt. As
> > > an example, Thunderbolt-attached GPUs shall not be registered with
> vga_switcheroo.
> > >
> > > Intel uses a Vendor-Specific Extended Capability (VSEC) with ID
> > > 0x1234 on devices belonging to a Thunderbolt controller which allows
> > > us to recognize them.
> > >
> > > Detect presence of this VSEC on device probe and cache it in a newly
> > > added is_thunderbolt bit in struct pci_dev which can then be queried
> > > by pci_bridge_d3_possible(), pci_dev_check_d3cold(), apple-gmux and
> others.
> > >
> > > Cc: Andreas Noever
> > > Cc: Tomas Winkler
> > > Cc: Amir Levy
> > > Signed-off-by: Lukas Wunner
> > > ---
> > > drivers/pci/pci.h | 2 ++
> > > drivers/pci/probe.c | 34 ++
> > > include/linux/pci.h | 1 +
> > > 3 files changed, 37 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index
> > > cb17db2..45c2b81
> > > 100644
> > > --- a/drivers/pci/pci.h
> > > +++ b/drivers/pci/pci.h
> > > @@ -3,6 +3,8 @@
> > >
> > > #define PCI_FIND_CAP_TTL 48
> > >
> > > +#define PCI_VSEC_ID_INTEL_TBT0x1234 /* Thunderbolt */
> >
> > Shouldn't bet this defined in pci_ids.h ?
>
> That file is solely intended for IDs used in multiple places, as explained in
> the
> comment at its top. This particular ID is only used in the PCI core, hence
> it's in
> the PCI core's private drivers/pci/pci.h.
>
> However the line is formatted such that it can just be moved to the global
> include/linux/pci_ids.h should it be needed someplace else in the future.
>
>
> > > extern const unsigned char pcie_link_speed[];
> > >
> > > bool pcie_cap_has_lnkctl(const struct pci_dev *dev); diff --git
> > > a/drivers/pci/probe.c b/drivers/pci/probe.c index e164b5c..891a8fa
> > > 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1206,6 +1206,37 @@ void set_pcie_hotplug_bridge(struct pci_dev
> > > *pdev)
> > > pdev->is_hotplug_bridge = 1;
> > > }
> > >
> > > +static void set_pcie_vendor_specific(struct pci_dev *dev) {
> >
> >
> > Why don't u implement this in quirk.c ?
>
> The is_thunderbolt bit signifies whether a given PCI device is part of a
> Thunderbolt daisy chain. (As explained in the comment in include/linux/pci.h,
> see below.) So it is set on all the PCI devices that comprise a Thunderbolt
> controller, but also on all endpoint devices that are attached via
> Thunderbolt.
>
> Consequently this function needs to be executed for all PCI devices, not just
> for a subset that could be identified by a vendor, device or class ID.
Ok, god it.
>
> In the DRM drivers nouveau, radeon and amdgpu I need to prevent calls to
> vga_switcheroo_register_client() and vga_switcheroo_init_domain_pm_ops()
> if the device in question is attached via Thunderbolt. That's because
> external
> GPUs can't drive the panel of a laptop or be powered down like an on-board
> Optimus/PowerXpress GPU. We've got a bug there right now that manifests
> itself once someone attaches an eGPU to a dual GPU laptop.
> With this patch I'll be able to just skip registration with vga_switcheroo if
> is_thunderbolt is set on a GPU's pci_dev, thereby fixing the bug.
>
>
> BTW do you have information on the contents/meaning of the VSEC that you
> would be able/allowed to share? What I've seen so far is that its length is
> 0x1c
> bytes on older controllers (e.g. Light Ridge, Port Ridge) and its contents are
> always the same, regardless if the controller is used in host mode or endpoint
> mode:
Sorry, currently nothing I can share.
> 500: 0b 00 01 00 34 12 c1 01|50 09 00 00 39 00 00 00
> 510: 00 00 00 00 00 00 00 00 00 00 00 00
>
> However on Alpine Ridge the size of the VSEC has increased significantly to
> 0xd8 bytes, even though the version stayed at 1 as before:
>
> 500: 0b 00 01 60 34 12 81 0d 50 09 b0 0c b9 06 18 08
> 510: 00 38 00 01 00 00 00 00 00 00 00 00 32 02 10 00
> 520: ef d3 00 40 00 00 00 00 f0 f0 30 c1 00 02 30 00
> 530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 580: 00
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Am 10.01.2017 um 21:05 schrieb Jason Gunthorpe:
On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
The kernel needs a resource manager. Everyone needs to think VERY
hard and VERY, VERY carefully about what gets put into the kernel. In
making a decision, put the ABSOLUTE smallest amount of code into the
kernel which allows various 'TPM2 personalities' to be implemented in
userspace and functionally verified and protected by the physical
instance. The emergence of commodity TEE's (SGX, et.al) should be in
the back of everyone's mind as a factor in the roadmap.
Here's my cuts for the kernel:
- Kernel virtualizes handle areas. It's mechanical.
- Kernel does not virtualize bodies. It's not mechanical.
- At least the first version of the RM will not do other than session
isolation for sessions.
This keeps the core for RM inside the kernel small and tight.
You need to do virtualization inside bodies, because TPM2_FlushContext
carries it's handles inside the parameter body.
Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)
I think this makes sense.
In addition the kernel should only permit RM operations that are known
to be 100% correct with the RM.
I think you should stick with your original design basic design,
except instead of using an ioctl to switch modes, use an ioctl to
execute the operation:
struct tpm_ioctl_operation {
u16 mode; // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
u16 locality;
u32 txlen;
u32 rxlen;
const void *txbuf;
void *rxbuf;
};
could we please get an ioctl, that switches the "mode" of the fd entirely.
I'd like to see the write()/read() support still intact.
All my current code uses main-loop based poll on the fd and I don't want
to be force to start using threads...
Thanks,
Andreas
The userspace broker would be expected to use a mixture of RM and RAW
operations.
Let's deal with the idea of another cdev some other day when someone
can figure out a comprehensive way to do that securely for unpriv..
Jason
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
tpmdd-devel mailing list
tpmdd-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [PATCH v4 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports
On Sun, Jan 08, 2017 at 09:41:45AM +0100, Lukas Wunner wrote:
> Hotplug ports generally block their parents from suspending to D3hot as
> otherwise their interrupts couldn't be delivered.
>
> An exception are Thunderbolt host controllers: They have a separate
> GPIO pin to side-band signal plug events even if the controller is
> powered down or its parent ports are suspended to D3. They can be told
> apart from Thunderbolt controllers in attached devices by checking if
> they're situated below a non-Thunderbolt device (typically a root port,
> or the downstream port of a PCIe switch in the case of the MacPro6,1).
>
> To enable runtime PM for Thunderbolt on the Mac, the downstream bridges
> of a host controller must not block runtime PM on the upstream bridge as
> power to the chip is only cut once the upstream bridge has suspended.
> Amend the condition in pci_dev_check_d3cold() accordingly.
>
> Cc: Mika Westerberg
> Cc: Rafael J. Wysocki
> Cc: Andreas Noever
> Cc: Tomas Winkler
> Cc: Amir Levy
> Signed-off-by: Lukas Wunner
> ---
> drivers/pci/pci.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8ed098d..0b03fe7 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2271,6 +2271,7 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
>
> static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
> {
> + struct pci_dev *parent, *grandparent;
> bool *d3cold_ok = data;
>
> if (/* The device needs to be allowed to go D3cold ... */
> @@ -2284,7 +2285,17 @@ static int pci_dev_check_d3cold(struct pci_dev *dev,
> void *data)
> !pci_power_manageable(dev) ||
>
> /* Hotplug interrupts cannot be delivered if the link is down. */
> - dev->is_hotplug_bridge)
> + (dev->is_hotplug_bridge &&
> +
> + /*
> + * Exception: Thunderbolt host controllers have a pin to
> + * side-band signal plug events. Their hotplug ports are
> + * recognizable by having a non-Thunderbolt device as
> + * grandparent.
> + */
> + !(dev->is_thunderbolt && (parent = pci_upstream_bridge(dev)) &&
> + (grandparent = pci_upstream_bridge(parent)) &&
> + !grandparent->is_thunderbolt)))
Can you move this to its own helper function?
>
> *d3cold_ok = false;
>
> --
> 2.11.0
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
On Wed, Jan 11, 2017 at 01:51:56AM -0800, Paul E. McKenney wrote: > Yes, you could make RCU expedited grace periods go back to using the > requesting task, and that would allow expedited grace periods to run early > in the boot process. But that causes problems with signals and the like > unless you revert a few other patches. The bugzilla is interesting -- > it looks like ACPI was in some cases doing early-boot grace-period waits > some time back? I think this and https://bugzilla.suse.com/show_bug.cgi?id=1017783 is an example of a bunch of toshiba schlaptops which cause the issue. So it looks like ACPI is doing something very early on those which tickles the issue to happen. But this is ACPI - anything can happen! > I have a limping prototype RCU patch that should avoid this problem. > > If all goes well, I will send it out late tomorrow evening, Pacific Time. Attach it to the bugzilla too, pls, because the people there trigger the issue. I have the respective(?) SUSE bug and I can ask people there to run it too. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Am 09.01.2017 um 23:39 schrieb Jarkko Sakkinen: On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote: Great to see this coming along so well. Thanks a lot to Jarkko ! I just wanted to point out a few things I deem important at this point: - Number of virtual handles: From what I see there are currently 14 slots for virtual objects in the RFC (if I'm mistaking, please correct me). I'd advice to ask the TPM2_GetCapabilities(TPM_CAP_TPM_PROPERTIES, TPM_PT_HR_TRANSIENT_MIN or TPM_PT_HR_TRANSIENT_AVAIL) [Note: there is no actual max, i.e. the TPM will allow more transient objects that e.g. 3 if they are small] and provide each TPM space with the same amount as the TPM will tell them is available. If an application needs more objects, I'd see a per-fd mini-RM module inside the TSS-libraries handling that job quite well. Same would apply for Session with TPM_PT_HR_LOADED_MIN and TPM_PT_HR_LOADED_AVAIL. This will reduce the memory consumption inside the kernel and provide userspace with a consistent view on the GetCapabilities vs its actual Allocations. I rather have a fixed size object. It keeps the implementation simple compact and stupid and that is what we want at this point. Even if I did what you proposed there would not be 1:1 match with GetCapability provided data because we need to virtual handle values. Leaving the virtualization of message bodies in the user space is a design choice from my side. The kernel will provide only basic mechanism for implementing easily an RM, not a full fledged implementation. - Enumeration of loaded (virtual) handles: The TPM allows an application to get the list of currently loaded handles TPM2_GetCapabilities(TPM_CAP_HANDLES). It would be great to have the RM be as transparent to userspace as possible. The RM spec of TCG therefore says that you need to intercept and override this command (unless it is run in an authentication session where you cannot override it, which is disadviced). It's a design choice, but I'd advice for it after long discussions. I don't buy this because it doesn't scale (new commands in the standard, vendor specific commands). It's just something that is factors easier to do in the user space. It's not an uncommon design in the Linux kernel to have basic mechanism in the kernel and do some of the heavy lifting in the user space. For example, graphics drivers are like that. - Session Limits (here it gets ugly): Even thought the TPM supports the same swapping-scheme for sessions as it does for transient objects, it only allows for a limited number of session to be opened (64 in case of PC-Client), called active sessions. This means that a single process can still DoS the TPM if it allocates 64 sessions, or 64 processes can DoS the TPM if they allocate 1 session each. There are two principle solutions: a) Limit the number of active sessions per fd, process, user and hope for the best. Of course this will not really protect you from DoS'ed TPMs. b) Kick out old sessions whenever new sessions are requested and TPM is currently full (the TCG RM spec approach). Of course applications need to handle "randomly vanishing" hmac sessions in this case. I'll think about this. The next patch set version will include session isolation. - Session ungaping (here it gets REALLY ugly): The TPM has some scheme for handling sessions that are swapped (contextSaved) out. In this scheme, it can run into the case where it will deny actions on a session handle with a TPM2_RC_GAP error. This error means that the time between last usage of the oldest session and the current session is too far apart. The reaction needs to be that the RM loads this oldest sesssion (or in my implementation all swaped sessions) into the TPM and contextsave them back right away. This becomes especially ugly, when enabling the ability of userspace to contextsave a session on one fd and contextload this session on another fd (or even from another process). This something we are not going to support in the first production version. I'm happy review patches that try to do this nicely after the first version of the feature has landed. I don't care about this feature all that much. I guess all of the above is more or less debatable. This point here however is not. It's a necessity, otherwise you will get weird machines that (seemingly) randomly stop working after a long time; i.e. months. So nobody will find this in tests or be able to reproduce. These are the kind of bugs nobody will ever track down. So please, do not release session-RM-support without taking care of ungaping... This would be highly irresponsible ! Thanks, Andreas /Jarkko
