[PATCH v5 0/6] (mostly) Arch-independent livepatch
This patchset removes livepatch's need for architecture-specific relocation
code by leveraging existing code in the module loader to perform
arch-dependent work. Specifically, instead of duplicating code and
re-implementing what the apply_relocate_add() function in the module loader
already does in livepatch's klp_write_module_reloc(), we reuse
apply_relocate_add() to write relocations. The hope is that this will make
livepatch more easily portable to other architectures and greatly reduce
the amount of arch-specific code required to port livepatch to a particular
architecture.
Background: Why does livepatch need to write its own relocations?
==
A typical livepatch module contains patched versions of functions that can
reference non-exported global symbols and non-included local symbols.
Relocations referencing these types of symbols cannot be left in as-is
since the kernel module loader cannot resolve them and will therefore
reject the livepatch module. Furthermore, we cannot apply relocations that
affect modules not loaded yet at run time (e.g. a patch to a driver). The
current kpatch build system therefore solves this problem by embedding
special "dynrela" (dynamic reloc) sections in the resulting patch module
Elf output. Using these dynrela sections, livepatch can correctly resolve
symbols while taking into account its scope and what module the symbol
belongs to, and then manually apply the dynamic relocations.
Motivation: Why is having arch-dependent relocation code a problem?
==
The original motivation for this patchset stems from the increasing
roadblocks encountered while attempting to port livepatch to s390.
Specifically, there were problems dealing with s390 PLT and GOT relocation
types (R_390_{PLT,GOT}), which are handled differently from x86's
relocation types (which are much simpler to deal with, and a single
livepatch function (klp_write_module_reloc()) has been sufficient enough).
These s390 reloc types cannot be handled by simply performing a calculation
(as in the x86 case). For s390 modules with PLT/GOT relocations, the kernel
module loader allocates and fills in PLT+GOT table entries for every symbol
referenced by a PLT/GOT reloc in module core memory. So the problem of
porting livepatch to s390 became much more complicated than simply writing
an s390-specific klp_write_module_reloc() function. How can livepatch
handle these relocation types if the s390 module loader needs to allocate
and fill PLT/GOT entries ahead of time? The potential solutions were: 1)
have livepatch possibly allocate and maintain its own PLT/GOT tables for
every patch module (requiring even more arch-specific code), 2) modify the
s390 module loader heavily to accommodate livepatch modules (i.e. allocate
all the needed PLT/GOT entries for livepatch in advance but refrain from
applying relocations for to-be-patched modules), or 3) eliminate this
potential mess by leveraging module loader code to do all the relocation
work, letting livepatch off the hook completely. Solution #3 is what this
patchset implements.
How does this patchset remedy these problems?
==
Reusing the module loader code to perform livepatch relocations means that
livepatch no longer needs arch-specific reloc code and the aforementioned
problems with s390 PLT/GOT reloc types disappear (because we let the module
loader do all the relocation work for us). It will enable livepatch to be
more easily ported to other architectures.
Summary of proposed changes
==
This patch series enables livepatch to use the module loader's
apply_relocate_add() function to apply livepatch relocations (i.e. what
used to be dynrelas). apply_relocate_add() requires access to a patch
module's section headers, symbol table, reloc section indices, etc., and all
of these are accessible through the load_info struct used in the module
loader. Therefore we persist module Elf information (copied from load_info)
for livepatch modules.
The ELF-related changes enable livepatch to patch modules that are not yet
loaded (as well as patch vmlinux when kaslr is enabled). In order to use
apply_relocate_add(), we need real SHT_RELA sections to pass in. A
complication here is that relocations for not-yet-loaded modules should not
be applied when the patch module loads; they should only be applied once
the target module is loaded. Thus kpatch build scripts were modified to
output a livepatch module that contains special .klp.rela. sections that
are managed by livepatch and are applied at the appropriate time (i.e. when
target module loads). They are marked with a special SHF_RELA_LIVEPATCH
section flag to indicate to the module loader that livepatch will handle
them. The SHN_LIVEPATCH shndx marks symbols that need to be resolved
once their respective target module loads. So, the module loader ignores
these symbols and does not attempt to resolve them. These ELF constants
were selected from OS-specific ranges according to the definitions from
glibc.
Patches based on linux-next.
Previous pa
Re: [PATCH v2] mmc: Add CONFIG_MMC_SIMULATE_MAX_SPEED
On 22 February 2016 at 18:18, Mark Salyzyn wrote: > When CONFIG_MMC_SIMULATE_MAX_SPEED is enabled, Expose max_read_speed, > max_write_speed and cache_size sysfs controls to simulate a slow > eMMC device. The boot default values, should one wish to set this > behavior right from kernel start: > > CONFIG_MMC_SIMULATE_MAX_READ_SPEED > CONFIG_MMC_SIMULATE_MAX_WRITE_SPEED > CONFIG_MMC_SIMULATE_CACHE_SIZE > > respectively; and if not defined are 0 (off), 0 (off) and 4 MB > also respectively. So this changelog doesn't really tell me *why* this feature is nice to have. Could you elaborate on this and thus also extend the information in the changelog please. Moreover, I have briefly reviewed the code, but I don't want to go into the details yet... Instead, what I am trying to understand if this is something that useful+specific for the MMC subsystem, or if it's something that belongs in the upper generic BLOCK layer. Perhaps you can comment on this as well? Kind regards Uffe > > Signed-off-by: Mark Salyzyn > --- > changes in v2: change from CONFIG_MMC_BLOCK_MAX_SPEED to > CONFIG_MMC_SIMULATE_MAX_SPEED. Add documentation. > > Documentation/block/00-INDEX | 6 + > Documentation/block/mmc-max-speed.txt | 39 + > drivers/mmc/card/Kconfig | 57 +++ > drivers/mmc/card/block.c | 294 > ++ > drivers/mmc/card/queue.h | 8 + > 5 files changed, 404 insertions(+) > create mode 100644 Documentation/block/mmc-max-speed.txt > > diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX > index e840b47..bc51487 100644 > --- a/Documentation/block/00-INDEX > +++ b/Documentation/block/00-INDEX > @@ -26,3 +26,9 @@ switching-sched.txt > - Switching I/O schedulers at runtime > writeback_cache_control.txt > - Control of volatile write back caches > +mmc-max-speed.txt > + - eMMC layer speed simulation, related to /sys/block/mmcblk*/ > + attributes: > +max_read_speed > +max_write_speed > +cache_size > diff --git a/Documentation/block/mmc-max-speed.txt > b/Documentation/block/mmc-max-speed.txt > new file mode 100644 > index 000..3ad1260 > --- /dev/null > +++ b/Documentation/block/mmc-max-speed.txt > @@ -0,0 +1,39 @@ > +eMMC Block layer simulation speed controls in /sys/block/mmcblk*/ > +=== > + > +Turned on with CONFIG_MMC_SIMULATE_MAX_SPEED which enables MMC device speed > +limiting. Used to test and simulate the behavior of the system when > +confronted with a slow MMC. > + > +Enables max_read_speed, max_write_speed and cache_size attributes to control > +the write or read maximum KB/second speed behaviors. The defaults are set > +by CONFIG_MMC_SIMULATE_MAX_READ_SPEED, CONFIG_MMC_SIMULATE_MAX_WRITE_SPEED > and > +CONFIG_MMC_SIMULATE_CACHE_SIZE config parameters respectively. > + > +NB: There is room for improving the algorithm for aspects tied directly to > +eMMC specific behavior. For instance, wear leveling and stalls from an > +exhausted erase pool. We would expect that if there was a need to provide > +similar speed simulation controls to other types of block devices, aspects of > +their behavior are modelled separately (e.g. head seek times, heat assist, > +shingling and rotational latency). > + > +/sys/block/mmcblk0/max_read_speed: > + > +Number of KB/second reads allowed to the block device. Used to test and > +simulate the behavior of the system when confronted with a slow reading MMC. > +Set to 0 or "off" to place no speed limit. > + > +/sys/block/mmcblk0/max_write_speed: > + > +Number of KB/second writes allowed to the block device. Used to test and > +simulate the behavior of the system when confronted with a slow writing MMC. > +Set to 0 or "off" to place no speed limit. > + > +/sys/block/mmcblk0/cache_size: > + > +Number of MB of high speed memory or high speed SLC cache expected on the > +eMMC device being simulated. Used to help simulate the write-back behavior > +more accurately. The assumption is the cache has no delay, but draws down > +in the background to the MLC/TLC primary store at the max_write_speed rate. > +Any write speed delays will show up when the cache is full, or when an I/O > +request to flush is issued. > diff --git a/drivers/mmc/card/Kconfig b/drivers/mmc/card/Kconfig > index 5562308..1abef59 100644 > --- a/drivers/mmc/card/Kconfig > +++ b/drivers/mmc/card/Kconfig > @@ -68,3 +68,60 @@ config MMC_TEST > > This driver is only of interest to those developing or > testing a host driver. Most people should say N here. > + > +config MMC_SIMULATE_MAX_SPEED > + bool "Turn on maximum speed control per block device" > + depends on MMC_BLOCK > + help > + Say Y here to enable MMC device speed limiting. Used to test and > + simulate the behavior of the system when confronted with a slow MMC. > + > + Enables max_read_speed, max
Re: [PATCH v3] can: rcar_canfd: Add Renesas R-Car CAN FD driver
On Tue, Mar 15, 2016 at 09:48:14AM +, Ramesh Shanmugasundaram wrote:
> This patch adds support for the CAN FD controller found in Renesas R-Car
> SoCs. The controller operates in CAN FD only mode by default.
>
> CAN FD mode supports both Classical CAN & CAN FD frame formats. The
> controller supports ISO 11898-1:2015 CAN FD format only.
>
> This controller supports two channels and the driver can enable either
> or both of the channels.
>
> Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
> per channel) for transmission. Rx filter rules are configured to the
> minimum (one per channel) and it accepts Standard, Extended, Data &
> Remote Frame combinations.
>
> Note: There are few documentation errors in R-Car Gen3 Hardware User
> Manual v0.5E with respect to CAN FD controller. They are listed below:
>
> 1. CAN FD interrupt numbers 29 & 30 are listed as per channel
> interrupts. However, they are common to both channels (i.e.) they are
> global and channel interrupts respectively.
>
> 2. CANFD clock is derived from PLL1. This is not documented.
>
> 3. CANFD clock is further divided by (1/2) within the CAN FD controller.
> This is not documented.
>
> 4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
> is specified 4 Tq in the manual.
>
> 5. The maximum number of message RAM area the controller can use is 3584
> bytes. It is specified 10752 bytes in the manual.
>
> Signed-off-by: Ramesh Shanmugasundaram
>
> ---
> Hi All,
>
>Thanks for the review comments.
>
>This updated patch is based on linux-can-next tag
> (linux-can-next-for-4.6-20160310).
>
>This patch depends on
>
>[RFC] [PATCH v3] can: fix handling of unmodifiable configuration options
>(http://comments.gmane.org/gmane.linux.can/9126)
>
> Changes since v2:
> * Rebased to latest tag (linux-can-next-for-4.6-20160310)
> * Cleaned up leftover debugfs code (Thanks Oliver H)
> * Revised devicetree documentation text (as suggested by Rob H)
>
> (https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg01597.html)
> * Used new can subsystem api to set static configuration & removed
> check in rcar_canfd_start (as suggested by Oliver H)
> (Refer: http://comments.gmane.org/gmane.linux.can/9126 &
>
> https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg01867.html)
> * Clubbed Renesas controller drivers to driver/net/can/rcar dir (as
> suggested by Oliver H)
> * Updated commit message
>
> Changes since v1:
> * Removed testmodes & debugfs code (suggested by Oliver H)
> * Fixed tx path race issue by introducing lock (suggested by Marc K)
> * Removed __maybe_unused attribute of rcar_canfd_of_table
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 89 ++
Acked-by: Rob Herring
> drivers/net/can/Kconfig| 11 +-
> drivers/net/can/Makefile |2 +-
> drivers/net/can/rcar/Kconfig | 19 +
> drivers/net/can/rcar/Makefile |6 +
> drivers/net/can/{ => rcar}/rcar_can.c |0
> drivers/net/can/rcar/rcar_canfd.c | 1614
>
> 7 files changed, 1730 insertions(+), 11 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> create mode 100644 drivers/net/can/rcar/Kconfig
> create mode 100644 drivers/net/can/rcar/Makefile
> rename drivers/net/can/{ => rcar}/rcar_can.c (100%)
> create mode 100644 drivers/net/can/rcar/rcar_canfd.c
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On Wed, Mar 16, 2016 at 11:49:04AM -0600, Jason Gunthorpe wrote: > On Wed, Mar 16, 2016 at 02:09:16PM +0200, Jarkko Sakkinen wrote: > > On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote: > > > Alternative to this would be to have /dev/vtpmx create: > > > > * /dev/vtpm0 for the server > > * /dev/tpm0 for the client > > > > This is how David Howell's PoC worked and that's why I want > > to make this alternative visible. > > > > The server could even respawn without container noticing it. > > This solution have better availability properties. > > Seriously, no, that doesn't make any sense. TPM is stateful, you can't > respawn the server side. > > If anyone is ever clever enough to make that workable then they just > go ahead and save the server fd with the other state. systemd for > instance already has everything needed to make that work. > > We don't need to have a server dev node and we certainly don't need > the leaking problem that leaves us with. Fair enough. > Jason /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On Thu, Mar 17, 2016 at 01:45:20PM -0400, Stefan Berger wrote:
> On 03/16/2016 04:42 PM, Jarkko Sakkinen wrote:
> >On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> >>+
> >>+/* above flags */
> >>+#define VTPM_PROXY_FLAG_TPM2 1 /* emulator is TPM 2 */
> >>+
> >>+/* all supported flags */
> >>+#define VTPM_PROXY_FLAGS_ALL (VTPM_PROXY_FLAG_TPM2)
> >This can be moved inside the .c-file?
>
> I can move that.
>
> >
> >>+
> >>+#define VTPM_PROXY_MAGIC 0xa1
> >>+
> >>+#define VTPM_PROXY_IOC_NEW_DEV _IOW(VTPM_PROXY_MAGIC, 0x00, \
> >>+ struct vtpm_proxy_new_dev)
> >Could we simply replace these four lines with one line:
> >
> >#deifne VTPM_PROXY_IOC_NEW_DEV _IOW('t', 0x00, struct vtpm_proxy_new_dev);
>
> Does this make it better?
>
> >
> >I changed the magic but does it matter?
>
> I would keep the magic at '0xa1'. The documentation is written to '0xa1' now
> and seems to be good just as any other.
OK. Works for me. Keep the ioctl definition as it is.
Reviewed-by: Jarkko Sakkinen
I can move the constant. You don't have to send a new patch version
anymore. I start keeping this patch in my master but will not merge it
to next before 4.6-rc5 so at the moment it would be scheduled for 4.7.
Does this sound good for you?
Further improvemnts should be sent as separate fixup patches.
>Stefan
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: module: preserve Elf information for livepatch modules
+++ Jessica Yu [16/03/16 15:47 -0400]:
For livepatch modules, copy Elf section, symbol, and string information
from the load_info struct in the module loader. Persist copies of the
original symbol table and string table.
Livepatch manages its own relocation sections in order to reuse module
loader code to write relocations. Livepatch modules must preserve Elf
information such as section indices in order to apply livepatch relocation
sections using the module loader's apply_relocate_add() function.
In order to apply livepatch relocation sections, livepatch modules must
keep a complete copy of their original symbol table in memory. Normally, a
stripped down copy of a module's symbol table (containing only "core"
symbols) is made available through module->core_symtab. But for livepatch
modules, the symbol table copied into memory on module load must be exactly
the same as the symbol table produced when the patch module was compiled.
This is because the relocations in each livepatch relocation section refer
to their respective symbols with their symbol indices, and the original
symbol indices (and thus the symtab ordering) must be preserved in order
for apply_relocate_add() to find the right symbol.
Signed-off-by: Jessica Yu
---
include/linux/module.h | 25 ++
kernel/module.c| 123 -
2 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2bb0c30..3daf2b3 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -330,6 +330,15 @@ struct mod_kallsyms {
char *strtab;
};
+#ifdef CONFIG_LIVEPATCH
+struct klp_modinfo {
+ Elf_Ehdr hdr;
+ Elf_Shdr *sechdrs;
+ char *secstrings;
+ unsigned int symndx;
+};
+#endif
+
struct module {
enum module_state state;
@@ -456,7 +465,11 @@ struct module {
#endif
#ifdef CONFIG_LIVEPATCH
+ bool klp; /* Is this a livepatch module? */
bool klp_alive;
+
+ /* Elf information */
+ struct klp_modinfo *klp_info;
#endif
#ifdef CONFIG_MODULE_UNLOAD
@@ -630,6 +643,18 @@ static inline bool module_requested_async_probing(struct
module *module)
return module && module->async_probe_requested;
}
+#ifdef CONFIG_LIVEPATCH
+static inline bool is_livepatch_module(struct module *mod)
+{
+ return mod->klp;
+}
+#else /* !CONFIG_LIVEPATCH */
+static inline bool is_livepatch_module(struct module *mod)
+{
+ return false;
+}
+#endif /* CONFIG_LIVEPATCH */
+
#else /* !CONFIG_MODULES... */
/* Given an address, look for it in the exception tables. */
diff --git a/kernel/module.c b/kernel/module.c
index 87cfeb2..80b7fd9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1971,6 +1971,82 @@ static void module_enable_nx(const struct module *mod) {
}
static void module_disable_nx(const struct module *mod) { }
#endif
+#ifdef CONFIG_LIVEPATCH
+/*
+ * Persist Elf information about a module. Copy the Elf header,
+ * section header table, section string table, and symtab section
+ * index from info to mod->klp_info.
+ */
+static int copy_module_elf(struct module *mod, struct load_info *info)
+{
+ unsigned int size, symndx;
+ int ret;
+
+ size = sizeof(*mod->klp_info);
+ mod->klp_info = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info == NULL)
+ return -ENOMEM;
+
+ /* Elf header */
+ size = sizeof(Elf_Ehdr);
+ memcpy(&mod->klp_info->hdr, info->hdr, size);
+
+ /* Elf section header table */
+ size = sizeof(Elf_Shdr) * info->hdr->e_shnum;
+ mod->klp_info->sechdrs = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info->sechdrs == NULL) {
+ ret = -ENOMEM;
+ goto free_info;
+ }
+ memcpy(mod->klp_info->sechdrs, info->sechdrs, size);
+
+ /* Elf section name string table */
+ size = info->sechdrs[info->hdr->e_shstrndx].sh_size;
+ mod->klp_info->secstrings = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info->secstrings == NULL) {
+ ret = -ENOMEM;
+ goto free_sechdrs;
+ }
+ memcpy(mod->klp_info->secstrings, info->secstrings, size);
+
+ /* Elf symbol section index */
+ symndx = info->index.sym;
+ mod->klp_info->symndx = symndx;
+
+ /*
+* For livepatch modules, core_symtab is a complete copy
+* of the original symbol table. Adjust sh_addr to point
+* to core_symtab since the copy of the symtab in module
+* init memory is freed at the end of do_init_module().
+*/
+ mod->klp_info->sechdrs[symndx].sh_addr = (unsigned long)
mod->core_kallsyms.symtab;
+
+ return 0;
+
+free_sechdrs:
+ kfree(mod->klp_info->sechdrs);
+free_info:
+ kfree(mod->klp_info);
+ return ret;
+}
+
+static void free_module_elf(struct module *mod)
+{
+ kfree(mod->klp_info->sechdrs);
+ kfree(mod->klp_info->secstrings);
+ kfree(mod->klp_info);
+}
+#el
Re: [RFC PATCH v4 7/7] powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge
On 2016/3/17 0:32, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:38 +0800
Yongji Xie wrote:
This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
we can mmap MSI-X table in vfio driver.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f90dc04..f01b9ab 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1955,6 +1955,20 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
.free = pnv_ioda2_table_free,
};
+static bool pnv_ioda_iommu_capable(enum iommu_cap cap)
+{
+ switch (cap) {
+ case IOMMU_CAP_INTR_REMAP:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static struct iommu_ops pnv_ioda_iommu_ops = {
+ .capable = pnv_ioda_iommu_capable,
+};
+
static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe, unsigned int base,
unsigned int segs)
@@ -3078,6 +3092,9 @@ static void pnv_pci_ioda_fixup(void)
/* Link NPU IODA tables to their PCI devices. */
pnv_npu_ioda_fixup();
+
+ /* Add IOMMU_CAP_INTR_REMAP */
+ bus_set_iommu(&pci_bus_type, &pnv_ioda_iommu_ops);
}
/*
Doesn't this set you up for a world of hurt? bus_set_iommu() calls
iommu_bus_init() which sets up notifiers, which maybe you don't care
about, but it also means that iommu_domain_alloc(&pci_bus_type) will
segfault because you're not providing a domain_alloc callback here.
It seems to be hard to add IOMMU_CAP_INTR_REMAP on
PPC64 platform.
And can we add a new ioctl in vfio_iommu_driver to check
if interrupt remapping is supported so that we can use our
own way to determine that on PPC64 platform?
Thanks,
Yongji Xie
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 5/7] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
On Mon, 7 Mar 2016 15:48:36 +0800
Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap
> sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
> page may be shared with other BARs.
>
> But we should allow to mmap these sub-page MMIO BARs if PCI
> resource allocator can make sure these BARs' mmio page will
> not be shared with other BARs.
>
> Signed-off-by: Yongji Xie
> ---
> drivers/vfio/pci/vfio_pci.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 1ce1d36..49d7a69 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -589,7 +589,8 @@ static long vfio_pci_ioctl(void *device_data,
>VFIO_REGION_INFO_FLAG_WRITE;
> if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
> pci_resource_flags(pdev, info.index) &
> - IORESOURCE_MEM && info.size >= PAGE_SIZE) {
> + IORESOURCE_MEM && !pci_resources_share_page(pdev,
> + info.index)) {
this would be a preferable line wrap:
IORESOURCE_MEM &&
!pci_resources_share_page(pdev, info.index)) {
> info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
> if (info.index == vdev->msix_bar) {
> ret = msix_sparse_mmap_cap(vdev, &caps);
> @@ -1016,6 +1017,10 @@ static int vfio_pci_mmap(void *device_data, struct
> vm_area_struct *vma)
> return -EINVAL;
>
> phys_len = pci_resource_len(pdev, index);
> +
> + if (!pci_resources_share_page(pdev, index))
> + phys_len = PAGE_ALIGN(phys_len);
> +
> req_len = vma->vm_end - vma->vm_start;
> pgoff = vma->vm_pgoff &
> ((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] serial: doc: Un-document non-existing uart_write_console()
On Wed, Mar 16, 2016 at 5:01 PM, Peter Hurley wrote:
> On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote:
>> uart_write_console() never existed, not even when the "new
>> uart_write_console function" was documented.
>
> Right. Should be uart_console_write()
Thx, I checked a few other possibilities, but couldn't find them.
Will update.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] clk: bcm2835: add missing osc and per clocks
ker...@martin.sperl.org writes:
> From: Martin Sperl
>
> Add definitions for the following clocks:
> * AVE0
> * DFT
> * GP0
> * GP1
> * GP2
> * PULSE
> * SLIM
> * SMI
> * TEC
>
> Signed-off-by: Martin Sperl
> ---
> drivers/clk/bcm/clk-bcm2835.c | 71
> +++
> include/dt-bindings/clock/bcm2835.h | 10 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 710cf15..f43e1ca 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -118,6 +118,8 @@
> #define CM_SDCCTL0x1a8
> #define CM_SDCDIV0x1ac
> #define CM_ARMCTL0x1b0
> +#define CM_AVEOCTL 0x1b8
> +#define CM_AVEODIV 0x1bc
> #define CM_EMMCCTL 0x1c0
> #define CM_EMMCDIV 0x1c4
>
> @@ -1738,6 +1740,18 @@ static const struct bcm2835_clk_desc clk_desc_array[]
> = {
> .div_reg = CM_TSENSDIV,
> .int_bits = 5,
> .frac_bits = 0),
> + [BCM2835_CLOCK_PULSE] = REGISTER_OSC_CLK(
> + .name = "pulse",
> + .ctl_reg = CM_PULSECTL,
> + .div_reg = CM_PULSEDIV,
> + .int_bits = 12,
> + .frac_bits = 0),
As I noted in previous review, PULSE has another divider on it that you
haven't accounted for, so it would be broken if we exposed it. I've
dropped it from the patch.
> + [BCM2835_CLOCK_TEC] = REGISTER_OSC_CLK(
> + .name = "tec",
> + .ctl_reg = CM_TECCTL,
> + .div_reg = CM_TECDIV,
> + .int_bits = 6,
> + .frac_bits = 0),
>
> /* clocks with vpu parent mux */
> [BCM2835_CLOCK_H264]= REGISTER_VPU_CLK(
> @@ -1752,6 +1766,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] =
> {
> .div_reg = CM_ISPDIV,
> .int_bits = 4,
> .frac_bits = 8),
> +
> /*
>* Secondary SDRAM clock. Used for low-voltage modes when the PLL
>* in the SDRAM controller can't be used.
> @@ -1783,6 +1798,24 @@ static const struct bcm2835_clk_desc clk_desc_array[]
> = {
> .is_vpu_clock = true),
>
> /* clocks with per parent mux */
> + [BCM2835_CLOCK_AVEO]= REGISTER_PER_CLK(
> + .name = "aveo",
> + .ctl_reg = CM_AVEOCTL,
> + .div_reg = CM_AVEODIV,
> + .int_bits = 4,
> + .frac_bits = 0),
> + [BCM2835_CLOCK_DFT] = REGISTER_PER_CLK(
> + .name = "dft",
> + .ctl_reg = CM_DFTCTL,
> + .div_reg = CM_DFTDIV,
> + .int_bits = 5,
> + .frac_bits = 0),
> + [BCM2835_CLOCK_DFT] = REGISTER_PER_CLK(
> + .name = "dpi",
> + .ctl_reg = CM_DPICTL,
> + .div_reg = CM_DPIDIV,
> + .int_bits = 4,
> + .frac_bits = 8),
>
> /* Arasan EMMC clock */
> [BCM2835_CLOCK_EMMC]= REGISTER_PER_CLK(
> @@ -1791,6 +1824,30 @@ static const struct bcm2835_clk_desc clk_desc_array[]
> = {
> .div_reg = CM_EMMCDIV,
> .int_bits = 4,
> .frac_bits = 8),
> +
> + /* General purpose (GPIO) clocks */
> + [BCM2835_CLOCK_GP0] = REGISTER_PER_CLK(
> + .name = "gp0",
> + .ctl_reg = CM_GP0CTL,
> + .div_reg = CM_GP0DIV,
> + .int_bits = 12,
> + .frac_bits = 12,
> + .is_mash_clock = true),
> + [BCM2835_CLOCK_GP1] = REGISTER_PER_CLK(
> + .name = "gp1",
> + .ctl_reg = CM_GP1CTL,
> + .div_reg = CM_GP1DIV,
> + .int_bits = 12,
> + .frac_bits = 12,
> + .is_mash_clock = true),
> + [BCM2835_CLOCK_GP2] = REGISTER_PER_CLK(
> + .name = "gp2",
> + .ctl_reg = CM_GP2CTL,
> + .div_reg = CM_GP2DIV,
> + .int_bits = 12,
> + .frac_bits = 12,
> + .is_mash_clock = true),
As I've noted previously, gp2 is not a mash clock. I've dropped that
line.
Other than these two issues, this patch looks fine.
signature.asc
Description: PGP signature
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On 03/16/2016 08:09 AM, Jarkko Sakkinen wrote: On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote: This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that is accessed using a file descriptor returned by an ioctl. The device /dev/tpmX is the usual TPM device created by the core TPM driver. Applications or kernel subsystems can send TPM commands to it and the corresponding server-side file descriptor receives these commands and delivers them to an emulated TPM. Signed-off-by: Stefan Berger CC: linux-ker...@vger.kernel.org CC: linux-doc@vger.kernel.org CC: linux-...@vger.kernel.org Alternative to this would be to have /dev/vtpmx create: * /dev/vtpm0 for the server * /dev/tpm0 for the client This is how David Howell's PoC worked and that's why I want to make this alternative visible. My initial implementation had this as well. The server could even respawn without container noticing it. This solution have better availability properties. A TPM should be stable enough to not have to be respawned... Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/4] i2c-smbus: add support for HOST NOTIFY
Hi, this is a quick respin of the series with the kbuild test bot fixes and the requested lm90 change. Again, I think applying the RMI4 input driver needs the merge of the input tree in master first, but having reviews on the Host Notify implementation would be good. Cheers, Benjamin Benjamin Tissoires (4): i2c: add a protocol parameter to the alert callback i2c-smbus: add SMBus Host Notify support i2c: i801: add support of Host Notify Input: synaptics-rmi4 - add SMBus support Documentation/i2c/smbus-protocol | 3 + drivers/char/ipmi/ipmi_ssif.c| 6 +- drivers/hwmon/lm90.c | 6 +- drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-i801.c| 85 +++- drivers/i2c/i2c-smbus.c | 112 ++- drivers/input/rmi4/Kconfig | 12 ++ drivers/input/rmi4/Makefile | 1 + drivers/input/rmi4/rmi_bus.h | 12 ++ drivers/input/rmi4/rmi_smbus.c | 416 +++ include/linux/i2c-smbus.h| 44 + include/linux/i2c.h | 10 +- include/uapi/linux/i2c.h | 1 + 13 files changed, 699 insertions(+), 10 deletions(-) create mode 100644 drivers/input/rmi4/rmi_smbus.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] clk: bcm2835: add missing PLL clock divider
Martin Sperl writes: >> On 17.03.2016, at 17:57, Eric Anholt wrote: >> >> >> These don't exist on the hardware as far as I've been able to find. "I >> found it in a header file somewhere" is not sufficient justification to >> expose it. >> >> I'm working on getting a series of all of these reviewed and ready, so >> I'm just dropping these PLLB hunks. > > Fine with that - my test shows that these are not configured by the firmware. > > As for headers: my experience is that these are the better resource > compared to all the public available documentation… > > If you remember the “frac” bit discussion where you said: > > Once again, trusting the docs turns out to be a bad idea. You're right, > the non-MASH clocks *do* have a bit 9 to enable fractional mode. Sigh. > > Also my understanding is that those headers are still used by the firmware > developers, so I guess that these are pretty stable and well maintained > (even if the ones available are by now a bit dated). > > They even contain ifdefs for some earlier versions of the chip - > see the dma-channels and their interrupts… > I.e: BCM2708A0 which does not have the DMA channels 9 to 15 > > So I would not discount all those pieces of information as totally > irrelevant. I'm looking at the hardware source, and at the place where all the other PLL dividers are, PLLB only has ARM. signature.asc Description: PGP signature
Re: [RFC PATCH v4 5/7] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:36 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs.
But we should allow to mmap these sub-page MMIO BARs if PCI
resource allocator can make sure these BARs' mmio page will
not be shared with other BARs.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1ce1d36..49d7a69 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -589,7 +589,8 @@ static long vfio_pci_ioctl(void *device_data,
VFIO_REGION_INFO_FLAG_WRITE;
if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
pci_resource_flags(pdev, info.index) &
- IORESOURCE_MEM && info.size >= PAGE_SIZE) {
+ IORESOURCE_MEM && !pci_resources_share_page(pdev,
+ info.index)) {
this would be a preferable line wrap:
IORESOURCE_MEM &&
!pci_resources_share_page(pdev, info.index)) {
OK. I'll fix it.
Thanks,
Yongji Xie
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On 03/16/2016 04:42 PM, Jarkko Sakkinen wrote:
On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
+
+/* above flags */
+#define VTPM_PROXY_FLAG_TPM2 1 /* emulator is TPM 2 */
+
+/* all supported flags */
+#define VTPM_PROXY_FLAGS_ALL (VTPM_PROXY_FLAG_TPM2)
This can be moved inside the .c-file?
I can move that.
+
+#define VTPM_PROXY_MAGIC 0xa1
+
+#define VTPM_PROXY_IOC_NEW_DEV _IOW(VTPM_PROXY_MAGIC, 0x00, \
+ struct vtpm_proxy_new_dev)
Could we simply replace these four lines with one line:
#deifne VTPM_PROXY_IOC_NEW_DEV _IOW('t', 0x00, struct vtpm_proxy_new_dev);
Does this make it better?
I changed the magic but does it matter?
I would keep the magic at '0xa1'. The documentation is written to '0xa1'
now and seems to be good just as any other.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Am 07.03.2016 um 07:57 schrieb Holger Schurig: > I know that in Germany a good amount of land-line telephone line are > still using ISDN. [...] > Especially company line are using ISDN still, and there are some Linux > programs that act on then, e.g. Asterisk and derived PBX software has > ISDN support which is actively used. AFAIK none of these uses I4L anymore. Asterisk dropped I4L support with version 2 if my memory is correct and nowadays uses CAPI, mISDN or its own DAHDI interface. -- Tilman Schmidt E-Mail: til...@imap.cc Bonn, Germany Nous, on a des fleurs et des bougies pour nous protéger. signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH v4 4/7] PCI: Modify resource_alignment to support multiple devices
On 2016/3/17 20:40, Alex Williamson wrote:
On Thu, 17 Mar 2016 19:28:34 +0800
Yongji Xie wrote:
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:35 +0800
Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio will not allow to passthrough one
BAR's mmio page which may be shared with other BARs.
To solve this performance issue, this patch modifies
resource_alignment to support syntax where multiple
devices get the same alignment. So we can use something
like "pci=resource_alignment=*:*:*.*:noresize" to
enforce the alignment of all MMIO BARs to be at least
PAGE_SIZE so that one BAR's mmio page would not be
shared with other BARs.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |2 +
drivers/pci/pci.c | 90
++-
include/linux/pci.h |4 ++
3 files changed, 85 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 8028631..74b38ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
aligned memory resources.
If is not specified,
PAGE_SIZE is used as alignment.
+ , , and can be set to
+ "*" which means match all values.
I don't see anywhere that you're automatically enabling this for your
platform, so presumably you're expecting users to determine on their
own that they have a performance problem and hoping that they'll figure
out that they need to use this option to resolve it. The first irate
question you'll get back is why doesn't this happen automatically?
Actually, I just want to make the code simple. Maybe it is
not a good idea to let users enable this option manually.
I will try to fix it like that:
That's not entirely what I meant, I think having a way for a user to
enable it is a good thing, but maybe there need to be cases where it's
enabled automatically. With 4k pages, this is often not an issue since
the PCI spec recommends 4k or 8k alignment for resources, but that
doesn't preclude an unusual device where a user might want to enable it
anyway. At 64k page size, problems become more common, so we need to
think about either enabling it automatically or somehow making it more
apparent to the user that the option is available for this purpose.
OK. I see. I will add a new arch-independent macro to indicate
the min alignments of all PCI BARs. And we can also specify the
alignments through the resource_alignment.
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6f8065a..6659752 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -30,6 +30,8 @@
#define PCIBIOS_MIN_IO 0x1000
#define PCIBIOS_MIN_MEM0x1000
+#define PCIBIOS_MIN_ALIGNMENT PAGE_SIZE
+
struct pci_dev;
/* Values for the `which' argument to sys_pciconfig_iobase syscall. */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index dadd28a..9f644e4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4593,6 +4593,8 @@ EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
static DEFINE_SPINLOCK(resource_alignment_lock);
+#define DISABLE_ARCH_ALIGNMENT -1
+#define DEFAULT_ALIGNMENT -2
/**
* pci_specified_resource_alignment - get resource alignment specified
by user.
* @dev: the PCI device to get
@@ -4609,6 +4611,9 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
char *p;
bool invalid = false;
+#ifdef PCIBIOS_MIN_ALIGNMENT
+ align = PCIBIOS_MIN_ALIGNMENT;
+#endif
spin_lock(&resource_alignment_lock);
p = resource_alignment_param;
while (*p) {
@@ -4617,7 +4622,7 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
p[count] == '@') {
p += count + 1;
} else {
- align_order = -1;
+ align_order = DEFAULT_ALIGNMENT;
}
if (p[0] == '*' && p[1] == ':') {
seg = -1;
@@ -4673,8 +4678,10 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
(bus == dev->bus->number || bus == -1) &&
(slot == PCI_SLOT(dev->devfn) || slot == -1) &&
(func == PCI_FUNC(dev->devfn) || func == -1)) {
-
Re: [RFC PATCH v4 4/7] PCI: Modify resource_alignment to support multiple devices
On Thu, 17 Mar 2016 19:28:34 +0800
Yongji Xie wrote:
> On 2016/3/17 0:30, Alex Williamson wrote:
> > On Mon, 7 Mar 2016 15:48:35 +0800
> > Yongji Xie wrote:
> >
> >> When vfio passthrough a PCI device of which MMIO BARs
> >> are smaller than PAGE_SIZE, guest will not handle the
> >> mmio accesses to the BARs which leads to mmio emulations
> >> in host.
> >>
> >> This is because vfio will not allow to passthrough one
> >> BAR's mmio page which may be shared with other BARs.
> >>
> >> To solve this performance issue, this patch modifies
> >> resource_alignment to support syntax where multiple
> >> devices get the same alignment. So we can use something
> >> like "pci=resource_alignment=*:*:*.*:noresize" to
> >> enforce the alignment of all MMIO BARs to be at least
> >> PAGE_SIZE so that one BAR's mmio page would not be
> >> shared with other BARs.
> >>
> >> Signed-off-by: Yongji Xie
> >> ---
> >> Documentation/kernel-parameters.txt |2 +
> >> drivers/pci/pci.c | 90
> >> ++-
> >> include/linux/pci.h |4 ++
> >> 3 files changed, 85 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/Documentation/kernel-parameters.txt
> >> b/Documentation/kernel-parameters.txt
> >> index 8028631..74b38ab 100644
> >> --- a/Documentation/kernel-parameters.txt
> >> +++ b/Documentation/kernel-parameters.txt
> >> @@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be
> >> entirely omitted.
> >>aligned memory resources.
> >>If is not specified,
> >>PAGE_SIZE is used as alignment.
> >> + , , and can be set to
> >> + "*" which means match all values.
> > I don't see anywhere that you're automatically enabling this for your
> > platform, so presumably you're expecting users to determine on their
> > own that they have a performance problem and hoping that they'll figure
> > out that they need to use this option to resolve it. The first irate
> > question you'll get back is why doesn't this happen automatically?
>
> Actually, I just want to make the code simple. Maybe it is
> not a good idea to let users enable this option manually.
> I will try to fix it like that:
That's not entirely what I meant, I think having a way for a user to
enable it is a good thing, but maybe there need to be cases where it's
enabled automatically. With 4k pages, this is often not an issue since
the PCI spec recommends 4k or 8k alignment for resources, but that
doesn't preclude an unusual device where a user might want to enable it
anyway. At 64k page size, problems become more common, so we need to
think about either enabling it automatically or somehow making it more
apparent to the user that the option is available for this purpose.
>
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 6f8065a..6659752 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -30,6 +30,8 @@
> #define PCIBIOS_MIN_IO 0x1000
> #define PCIBIOS_MIN_MEM0x1000
>
> +#define PCIBIOS_MIN_ALIGNMENT PAGE_SIZE
> +
> struct pci_dev;
>
> /* Values for the `which' argument to sys_pciconfig_iobase syscall. */
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index dadd28a..9f644e4 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4593,6 +4593,8 @@ EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
> static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
> static DEFINE_SPINLOCK(resource_alignment_lock);
>
> +#define DISABLE_ARCH_ALIGNMENT -1
> +#define DEFAULT_ALIGNMENT -2
> /**
>* pci_specified_resource_alignment - get resource alignment specified
> by user.
>* @dev: the PCI device to get
> @@ -4609,6 +4611,9 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> char *p;
> bool invalid = false;
>
> +#ifdef PCIBIOS_MIN_ALIGNMENT
> + align = PCIBIOS_MIN_ALIGNMENT;
> +#endif
> spin_lock(&resource_alignment_lock);
> p = resource_alignment_param;
> while (*p) {
> @@ -4617,7 +4622,7 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> p[count] == '@') {
> p += count + 1;
> } else {
> - align_order = -1;
> + align_order = DEFAULT_ALIGNMENT;
> }
> if (p[0] == '*' && p[1] == ':') {
> seg = -1;
> @@ -4673,8 +4678,10 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> (bus == dev->bus->number || bus == -1) &&
> (slot == PCI_SLOT(dev->devfn) || slot == -1) &&
> (func == PCI
Re: [PATCH v15 1/3] drm: rockchip: Add basic drm driver
On 16 March 2016 at 16:23, Tomeu Vizoso wrote:
> On 15 March 2016 at 02:30, Mark yao wrote:
>> On 2016年03月14日 21:35, Tomeu Vizoso wrote:
>>>
>>> On 2 December 2014 at 10:15, Mark Yao wrote:
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
new file mode 100644
index 000..e7ca25b
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -0,0 +1,1455 @@
>>>
>>> ...
+static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
+ return false;
>>>
>>> Hi Mark,
>>>
>>> what's the rationale for this?
>>>
>>> Disabling a CRTC as in [0] will cause mode_fixup() to be called with
>>> an empty mode, failing that test.
>>>
>>> Removing the check seems to get things working fine for a short while,
>>> but a later modeset invariably gets the VOP to hang (as reported by
>>> [1]).
>>>
>>> Do you know why that check was put in place and what exactly could be
>>> causing the hw to hang?
>>>
>>> [0]
>>> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
>>> [1]
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
>> Hi Tomeu
>>
>> Just thinking that "adjusted_mode->htotal == 0 || adjusted_mode->vtotal ==
>> 0" is not a good mode for vop.
>
> Ah, ok. Guess it should be removed then so we don't break userspace?
>
>> And you said VOP hang, only WARN_ON error message? or system hang, die?
>
> Sorry, the symptom was only the warning, I just went a bit too far and
> assumed the VOP had stopped working at all.
>
>> I think maybe crtc disable too fast, vblank is off, then no one can feed the
>> wait_update_complete.
>> Can you test it again with following patch?
>
> Actually, in today's testing I don't see that happening any more,
> sorry about that :/
>
> What I have been looking at today is a related issue when running the
> kms_flip_event_leak test from intel-gpu-tools. If I remove the check
> mentioned above so CRTCs can be disabled with the SetCRTC IOCTL, I see
> this page fault the second and subsequent times I run the test.
>
> [ 75.809031] rk_iommu ff930300.iommu: Page fault at 0x0100 of type read
> [ 75.809035] rk_iommu ff930300.iommu: iova = 0x0100: dte_index:
> 0x4 pte_index: 0x0 page_offset: 0x0
> [ 75.809040] rk_iommu ff930300.iommu: mmu_dte_addr: 0x2c258000
> dte@0x2c258010: 0x2c561001 valid: 1 pte@0x2c561000: 0x2a06 valid:
> 0 page@0x flags: 0x0
> [ 76.951288] rk_iommu ff930300.iommu: Enable stall request timed
> out, status: 0x4b
>
> I have written a smaller standalone test that is attached in case you
> want to check it out, but I haven't been able to find out why it only
> happens when the test is rerun.
>
> Apparently the VOP is still trying to read a BO (0x0100) right
> when the kernel frees it, but from what I can see, it should be
> scanning another BO at that point.
>
> Do you have any ideas on what could be happening?
Apparently, when the VOP is re-enabled, it will start scanning from
the framebuffer address that had been set last.
Because DMA addresses are recycled and there's going to be a low
number of framebuffers, this isn't going to be obvious unless we make
sure that there isn't a FB allocated at that DMA address any more.
The attached test case does just that.
Regards,
Tomeu
> Thanks,
>
> Tomeu
>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -503,6 +503,8 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>> if (!vop->is_enabled)
>> return;
>> + vop_crtc_wait_for_update(crtc);
>> +
>> drm_crtc_vblank_off(crtc);
>>
>> Thanks.
>>
>> --
>> Ｍark Yao
>>
>>
#include
#include
#include
#include
#include
#include
#include
#include
#include
__attribute__((format(printf, 1, 2)))
static void kmsg(const char *format, ...)
#define KERN_EMER "<0>"
#define KERN_ALERT "<1>"
#define KERN_CRIT "<2>"
#define KERN_ERR "<3>"
#define KERN_WARNING "<4>"
#define KERN_NOTICE "<5>"
#define KERN_INFO "<6>"
#define KERN_DEBUG "<7>"
{
va_list ap;
FILE *file;
file = fopen("/dev/kmsg", "w");
if (file == NULL)
return;
va_start(ap, format);
fprintf(file, "userspace: ");
vfprintf(file, format, ap);
va_end(ap);
fclose(file);
}
static uint32_t dumb_create(int fd, int width, int height, int bpp)
{
struct drm_mode_create_dumb create = {};
create.width = width;
create.height = height;
create.bpp = bpp;
create.handle = 0;
drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &create);
return create.handle;
}
static uint32_t fb_create(int fd, int width, int height, int format, int bo, int pitch)
{
struct drm_mode_fb_cmd2 f = {};
f.width =
[RFC v2] Documentation: mmc: Add the introduction for mmc-utils
This patch introduces one mmc test tools called mmc-utils, which is convenient if someone wants to exercise and test MMC/SD devices from userspace. Signed-off-by: Baolin Wang --- Documentation/mmc/00-INDEX |2 ++ Documentation/mmc/mmc-tools.txt | 34 ++ 2 files changed, 36 insertions(+) create mode 100644 Documentation/mmc/mmc-tools.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index a9ba672..4623bc0 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -6,3 +6,5 @@ mmc-dev-parts.txt - info on SD and MMC device partitions mmc-async-req.txt - info on mmc asynchronous requests +mmc-tools.txt + - info on mmc-utils tools diff --git a/Documentation/mmc/mmc-tools.txt b/Documentation/mmc/mmc-tools.txt new file mode 100644 index 000..499b0f4 --- /dev/null +++ b/Documentation/mmc/mmc-tools.txt @@ -0,0 +1,34 @@ +MMC tools introduction +== + +There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, +you can find it at the below public git repository: +http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + +Functions += + +The mmc-utils tools can do the following: + - Print and parse extcsd data. + - Determine the eMMC writeprotect status. + - Set the eMMC writeprotect status. + - Set the eMMC data sector size to 4KB by disabling emulation. + - Create general purpose partition. + - Enable the enhanced user area. + - Enable write reliability per partition. + - Print the response to STATUS_SEND (CMD13). + - Enable the boot partition. + - Set Boot Bus Conditions. + - Enable the eMMC BKOPS feature. + - Permanently enable the eMMC H/W Reset feature. + - Permanently disable the eMMC H/W Reset feature. + - Send Sanitize command. + - Program authentication key for the device. + - Counter value for the rpmb device will be read to stdout. + - Read from rpmb device to output. + - Write to rpmb device from data file. + - Enable the eMMC cache feature. + - Disable the eMMC cache feature. + - Print and parse CID data. + - Print and parse CSD data. + - Print and parse SCR data. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE
Please confirm receipt of my previous mail..When can i call you -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller
Hello, Parav. Sorry about the delay. On Sat, Mar 12, 2016 at 11:49:03AM +0530, Parav Pandit wrote: > > For (1) shall I have one spin lock that is uses across multiple > > hierarchy and multiple cgroup. > > Essentially one global lock among all cgroup. During hierarchical > > charging, continue to use same lock it at each level. > > Would that work in this first release? > > I am waiting for your reply. > Shall one lock for all cgroup is ok with you? Yes, when you're locking up to the root each time, splitting locks at the bottom doesn't really achieve anything. It just makes things more expensive. > If this is ok. I will keep the code as it is, because it uses common > helper functions for max and current files. Hmmm... can you please try to refactor the common part to helpers? It's not a big thing but there were both styles across different controllers and helper based ones tend to be easier to follow. > >> 3 is fine but resource [un]charging is not hot path? > > charge/uncharge is hot path from cgroup perspective. > > Considering 1 to 4 devices in system rpool list would grow upto 4 > > entry deep at each cgroup level. > > I believe this is good enough to start with. O complexity wise its > > O(N). where N is number of devices in system. I see, but if that's the case, please drop the fine locking. The fine locking doesn't make much sense - as implemented it's slower and the whole thing is not hot. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] serial: doc: Un-document obsolete tmpbuf_sem
On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote:
> uart_info.tmpbuf and uart_info.tmpbuf_sem were removed in v2.6.10, in
> full-history-linux commit a797ad7e3ae9cad4 ("[SERIAL] Clean up
> serial_core.c write functions.").
Reviewed-by: Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version
On 03/15/2016 10:50 PM, Vikas Sajjan wrote: > Hi Al Stone, > > On Wed, Mar 16, 2016 at 1:58 AM, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January 2016, >> but the arm64 kernel documentation for the use of ACPI was written for the >> 5.1 version of the spec. There were significant additions to the spec that >> had not yet been mentioned -- for example, the 6.0 mechanisms added to make >> it easier to define processors and low power idle states, as well as the >> 6.1 addition allowing regular interrupts (not just from GPIO) be used to >> signal ACPI general purpose events. >> >> This patch reflects going back through and examining the specs in detail >> and updating content appropriately. Whilst there, a few odds and ends of >> typos were caught as well. This brings the documentation up to date with >> ACPI 6.1 for arm64. >> >> RESEND: >>-- Corrected From: header and added missing Cc's >> >> Changes for v2: >>-- Clean up white space (Harb Abdulhahmid) >>-- Clarification on _CCA usage (Harb Abdulhamid) >>-- IORT moved to required from recommended (Hanjun Guo) >>-- Clarify IORT description (Hanjun Guo) >> >> Signed-off-by: Al Stone >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Jonathan Corbet >> --- >> Documentation/arm64/acpi_object_usage.txt | 445 >> ++ >> Documentation/arm64/arm-acpi.txt | 28 +- >> 2 files changed, 356 insertions(+), 117 deletions(-) >> >> diff --git a/Documentation/arm64/acpi_object_usage.txt >> b/Documentation/arm64/acpi_object_usage.txt >> index a6e1a18..29bc1a1 100644 >> --- a/Documentation/arm64/acpi_object_usage.txt >> +++ b/Documentation/arm64/acpi_object_usage.txt >> @@ -11,15 +11,16 @@ outside of the UEFI Forum (see Section 5.2.6 of the >> specification). >> >> For ACPI on arm64, tables also fall into the following categories: >> >> - -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT >> + -- Required: DSDT, FADT, GTDT, IORT, MADT, MCFG, RSDP, SPCR, XSDT >> >> - -- Recommended: BERT, EINJ, ERST, HEST, SSDT >> + -- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT >> >> - -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST, >> - MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI >> + -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI, >> + MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA, >> + TPM2, UEFI, XENV >> >> - -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, >> - LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT >> + -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT, >> + MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT >> >> >> Table Usage for ARMv8 Linux >> @@ -50,7 +51,8 @@ CSRT Signature Reserved (signature == "CSRT") >> >> DBG2 Signature Reserved (signature == "DBG2") >> == DeBuG port table 2 == >> - Microsoft only table, will not be supported. >> + License has changed and should be usable. Optional if used instead >> + of earlycon= on the command line. >> >> DBGP Signature Reserved (signature == "DBGP") >> == DeBuG Port table == >> @@ -133,10 +135,11 @@ GTDT Section 5.2.24 (signature == "GTDT") >> >> HEST Section 18.3.2 (signature == "HEST") >> == Hardware Error Source Table == >> - Until further error source types are defined, use only types 6 (AER >> - Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware >> - Error Source). Firmware first error handling is possible if and only >> - if Trusted Firmware is being used on arm64. >> + ARM-specific error sources have been defined; please use those or the >> + PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER >> + Bridge), or use type 9 (Generic Hardware Error Source). Firmware >> first >> + error handling is possible if and only if Trusted Firmware is being >> + used on arm64. >> >> Must be supplied if RAS support is provided by the platform. It >> is recommended this table be supplied. >> @@ -149,20 +152,27 @@ IBFT Signature Reserved (signature == "IBFT") >> == iSCSI Boot Firmware Table == >> Microsoft defined table, support TBD. >> >> +IORT Signature Reserved (signature == "IORT") >> + == Input Output Remapping Table == >> + arm64 only table, required in order to describe IO topology, SMMUs, >> + and GIC ITSs, and how those various components are connected >> together, >> + such as identifying which components are behind which SMMUs/ITSs. >> + >> IVRS Signature Reserved (signature == "IVRS") >> == I/O Virtualization Reporting Structure == >> x86_64 (AMD) only table, will not be supported. >> >> LPIT Signature Reserved (signature == "LPIT") >> == Low Power Idle Table == >> - x86 only ta
Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}
On Tue, Mar 15, 2016 at 2:25 PM, Laxman Dewangan wrote: > On Tuesday 15 March 2016 02:01 PM, Linus Walleij wrote: >> On Wed, Mar 9, 2016 at 3:23 PM, Laxman Dewangan >> wrote: >> Pushed the change at: Branch "devm_pinctrl_register" of https://github.com/ldewangan/linux-upstream.git. Base repo is for-next of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git If required, I can send the V2 version of list with acks. >>> >>> Let me know if I need to send full series (V2 with collected ack) again >>> or >>> fine to pull it from above location. >> >> Please collect the ACKs on your branch and ask me to pull it after >> v4.6-rc1. >> No need to resend the patches. >> >> Unfortunately it arrived too late for the merge window, but hey: we got >> the >> devm gpiochip in for v4.6. > > > Thanks for taking the GPIO patches. > > Ok, We will do pincontrol post v4.6 and probably, we will have some more > chnages for using devm_gpio in pincontrol subsystem as these APIs will be > available publicly. Awesome, then we get double the reduction in most cases, this will look nice. Let's proceed like this. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version
On Wed, Mar 16, 2016 at 10:20:23AM +0530, Vikas Sajjan wrote: > On Wed, Mar 16, 2016 at 1:58 AM, Al Stone wrote: > > The ACPI 6.1 specification was recently released at the end of January 2016, > > but the arm64 kernel documentation for the use of ACPI was written for the > > 5.1 version of the spec. There were significant additions to the spec that > > had not yet been mentioned -- for example, the 6.0 mechanisms added to make > > it easier to define processors and low power idle states, as well as the > > 6.1 addition allowing regular interrupts (not just from GPIO) be used to > > signal ACPI general purpose events. > > > > This patch reflects going back through and examining the specs in detail > > and updating content appropriately. Whilst there, a few odds and ends of > > typos were caught as well. This brings the documentation up to date with > > ACPI 6.1 for arm64. > > > > RESEND: > >-- Corrected From: header and added missing Cc's > > > > Changes for v2: > >-- Clean up white space (Harb Abdulhahmid) > >-- Clarification on _CCA usage (Harb Abdulhamid) > >-- IORT moved to required from recommended (Hanjun Guo) > >-- Clarify IORT description (Hanjun Guo) > > > > Signed-off-by: Al Stone > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Jonathan Corbet > > --- > > Documentation/arm64/acpi_object_usage.txt | 445 > > ++ > > Documentation/arm64/arm-acpi.txt | 28 +- > > 2 files changed, 356 insertions(+), 117 deletions(-) > > > > diff --git a/Documentation/arm64/acpi_object_usage.txt > > b/Documentation/arm64/acpi_object_usage.txt > > index a6e1a18..29bc1a1 100644 > > --- a/Documentation/arm64/acpi_object_usage.txt > > +++ b/Documentation/arm64/acpi_object_usage.txt > > @@ -11,15 +11,16 @@ outside of the UEFI Forum (see Section 5.2.6 of the > > specification). > > > > For ACPI on arm64, tables also fall into the following categories: > > > > - -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT > > + -- Required: DSDT, FADT, GTDT, IORT, MADT, MCFG, RSDP, SPCR, XSDT > > > > - -- Recommended: BERT, EINJ, ERST, HEST, SSDT > > + -- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT > > > > - -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST, > > - MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI > > + -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI, > > + MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA, > > + TPM2, UEFI, XENV > > > > - -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, > > - LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT > > + -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT, > > + MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT > > > > > > Table Usage for ARMv8 Linux > > @@ -50,7 +51,8 @@ CSRT Signature Reserved (signature == "CSRT") > > > > DBG2 Signature Reserved (signature == "DBG2") > > == DeBuG port table 2 == > > - Microsoft only table, will not be supported. > > + License has changed and should be usable. Optional if used instead > > + of earlycon= on the command line. > > > > DBGP Signature Reserved (signature == "DBGP") > > == DeBuG Port table == > > @@ -133,10 +135,11 @@ GTDT Section 5.2.24 (signature == "GTDT") > > > > HEST Section 18.3.2 (signature == "HEST") > > == Hardware Error Source Table == > > - Until further error source types are defined, use only types 6 (AER > > - Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware > > - Error Source). Firmware first error handling is possible if and > > only > > - if Trusted Firmware is being used on arm64. > > + ARM-specific error sources have been defined; please use those or > > the > > + PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 > > (AER > > + Bridge), or use type 9 (Generic Hardware Error Source). Firmware > > first > > + error handling is possible if and only if Trusted Firmware is being > > + used on arm64. > > > > Must be supplied if RAS support is provided by the platform. It > > is recommended this table be supplied. > > @@ -149,20 +152,27 @@ IBFT Signature Reserved (signature == "IBFT") > > == iSCSI Boot Firmware Table == > > Microsoft defined table, support TBD. > > > > +IORT Signature Reserved (signature == "IORT") > > + == Input Output Remapping Table == > > + arm64 only table, required in order to describe IO topology, SMMUs, > > + and GIC ITSs, and how those various components are connected > > together, > > + such as identifying which components are behind which SMMUs/ITSs. > > + > > IVRS Signature Reserved (signature == "IVRS") > > == I/O Virtualization Reporting Structure == > > x86_64 (AMD) only table, will not be supported
[PATCH 4/5] Documentation: update URLs for Richard Gooch's articles
Current URL for "Kernel API changes from 2.0 to 2.2" hasn't been available for some time, updating. The second article about changes from 2.2 to 2.4 is missing a URL, adding it. Signed-off-by: Luis de Bethencourt --- Documentation/kernel-docs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index 488bda7..04f6d73 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -266,14 +266,14 @@ * Title: "Kernel API changes from 2.0 to 2.2" Author: Richard Gooch. - URL: - http://www.linuxhq.com/guides/LKMPG/node28.html + URL: http://www.safe-mbox.com/~rgooch/linux/docs/porting-to-2.2.html Keywords: 2.2, changes. Description: Kernel functions/structures/variables which changed from 2.0.x to 2.2.x. * Title: "Kernel API changes from 2.2 to 2.4" Author: Richard Gooch. + URL: http://www.safe-mbox.com/~rgooch/linux/docs/porting-to-2.4.html Keywords: 2.4, changes. Description: Kernel functions/structures/variables which changed from 2.2.x to 2.4.x. -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] Documentation: add Linux Kernel Development book
The Linux Kernel Development book by Robert Love has been recommended to me by multiple kernel hackers. Worth having in the list of books in kernel-docs.txt for newbies looking for good learning resources. Signed-off-by: Luis de Bethencourt --- Hi, I really enjoyed this book and I think it deserves being listed in the kernel-docs.txt list. Thanks, Luis Documentation/kernel-docs.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index fe217c1..b250360 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -609,6 +609,13 @@ Pages: 432. ISBN: 0-201-63338-8 + * Title: "Linux Kernel Development, 3rd Edition" + Author: Robert Love + Publisher: Addison-Wesley. + Date: July, 2010 + Pages: 440 + ISBN: 978-0672329463 + MISCELLANEOUS: * Name: linux/Documentation -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] Documentation: update URL for Michael K. Johnson's articles
The URL for "Writing Linux Device Drivers" hasn't been available in some time. Updating it to the URL of Michael K. Johnson's "Linux Kernel Hackers' Guide" Signed-off-by: Luis de Bethencourt --- Documentation/kernel-docs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index b250360..9a1b0d3 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -196,7 +196,7 @@ * Title: "Writing Linux Device Drivers" Author: Michael K. Johnson. - URL: http://users.evitech.fi/~tk/rtos/writing_linux_device_d.html + URL: http://www.tldp.org/LDP/khg/HyperNews/get/khg.html Keywords: files, VFS, file operations, kernel interface, character vs block devices, I/O access, hardware interrupts, DMA, access to user memory, memory allocation, timers. -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Documentation: update URL of Analysis of the Ext2fs structure
The current URL has been down for some time, updating it to a working one. Signed-off-by: Luis de Bethencourt --- Documentation/kernel-docs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index 9a1b0d3..488bda7 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -250,7 +250,7 @@ * Title: "Analysis of the Ext2fs structure" Author: Louis-Dominique Dubeau. - URL: http://www.nondot.org/sabre/os/files/FileSystems/ext2fs/ + URL: http://teaching.csse.uwa.edu.au/units/CITS2002/fs-ext2/ Keywords: ext2, filesystem, ext2fs. Description: Description of ext2's blocks, directories, inodes, bitmaps, invariants... -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] Documentation: update URL for Porting Linux 2.0 Drivers to 2.2
The URL format of Linux Magazine articles has changed. Updating the URL of the "Porting Linux 2.0 Drivers to Linux 2.2" article by Alan Cox. Signed-off-by: Luis de Bethencourt --- Documentation/kernel-docs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index 04f6d73..bfca1ed 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -376,7 +376,7 @@ * Title: "Porting Linux 2.0 Drivers To Linux 2.2: Changes and New Features " Author: Alan Cox. - URL: http://www.linux-mag.com/1999-05/gear_01.html + URL: http://www.linux-mag.com/id/216/ Keywords: ports, porting. Description: Article from Linux Magazine on porting from 2.0 to 2.2 kernels. -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] Documentation: update URL for Michael K. Johnson's articles
On 19/03/16 12:51, Luis de Bethencourt wrote: > The URL for "Writing Linux Device Drivers" hasn't been available in some > time. Updating it to the URL of Michael K. Johnson's "Linux Kernel Hackers' > Guide" > > Signed-off-by: Luis de Bethencourt > --- > Documentation/kernel-docs.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt > index b250360..9a1b0d3 100644 > --- a/Documentation/kernel-docs.txt > +++ b/Documentation/kernel-docs.txt > @@ -196,7 +196,7 @@ > > * Title: "Writing Linux Device Drivers" > Author: Michael K. Johnson. > - URL: http://users.evitech.fi/~tk/rtos/writing_linux_device_d.html > + URL: http://www.tldp.org/LDP/khg/HyperNews/get/khg.html > Keywords: files, VFS, file operations, kernel interface, character > vs block devices, I/O access, hardware interrupts, DMA, access to > user memory, memory allocation, timers. > Hi, I separated the docs URL updates into individual commits so they can easily be cherry-picked. I am happy to squash them all into one if you think it is better. Thanks :) Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On Wed, Mar 16, 2016 at 02:09:16PM +0200, Jarkko Sakkinen wrote: > On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote: > Alternative to this would be to have /dev/vtpmx create: > > * /dev/vtpm0 for the server > * /dev/tpm0 for the client > > This is how David Howell's PoC worked and that's why I want > to make this alternative visible. > > The server could even respawn without container noticing it. > This solution have better availability properties. Seriously, no, that doesn't make any sense. TPM is stateful, you can't respawn the server side. If anyone is ever clever enough to make that workable then they just go ahead and save the server fd with the other state. systemd for instance already has everything needed to make that work. We don't need to have a server dev node and we certainly don't need the leaking problem that leaves us with. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/6] livepatch: reuse module loader code to write relocations
Reuse module loader code to write relocations, thereby eliminating the need
for architecture specific relocation code in livepatch. Specifically, reuse
the apply_relocate_add() function in the module loader to write relocations
instead of duplicating functionality in livepatch's arch-dependent
klp_write_module_reloc() function.
In order to accomplish this, livepatch modules manage their own relocation
sections (marked with the SHF_RELA_LIVEPATCH section flag) and
livepatch-specific symbols (marked with SHN_LIVEPATCH symbol section
index). To apply livepatch relocation sections, livepatch symbols
referenced by relocs are resolved and then apply_relocate_add() is called
to apply those relocations.
In addition, remove x86 livepatch relocation code and the s390
klp_write_module_reloc() function stub. They are no longer needed since
relocation work has been offloaded to module loader.
Signed-off-by: Jessica Yu
---
arch/s390/include/asm/livepatch.h | 7 --
arch/x86/include/asm/livepatch.h | 2 -
arch/x86/kernel/Makefile | 1 -
arch/x86/kernel/livepatch.c | 70 ---
include/linux/livepatch.h | 20 --
kernel/livepatch/core.c | 140 +++---
6 files changed, 84 insertions(+), 156 deletions(-)
delete mode 100644 arch/x86/kernel/livepatch.c
diff --git a/arch/s390/include/asm/livepatch.h
b/arch/s390/include/asm/livepatch.h
index d5427c7..2c12137 100644
--- a/arch/s390/include/asm/livepatch.h
+++ b/arch/s390/include/asm/livepatch.h
@@ -24,13 +24,6 @@ static inline int klp_check_compiler_support(void)
return 0;
}
-static inline int klp_write_module_reloc(struct module *mod, unsigned long
- type, unsigned long loc, unsigned long value)
-{
- /* not supported yet */
- return -ENOSYS;
-}
-
static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
{
regs->psw.addr = ip;
diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index 7e68f95..a7f9181 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -32,8 +32,6 @@ static inline int klp_check_compiler_support(void)
#endif
return 0;
}
-int klp_write_module_reloc(struct module *mod, unsigned long type,
- unsigned long loc, unsigned long value);
static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
{
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 616ebd2..89f8ade 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -79,7 +79,6 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-y += apic/
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
-obj-$(CONFIG_LIVEPATCH)+= livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
obj-$(CONFIG_X86_TSC) += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
deleted file mode 100644
index 92fc1a5..000
--- a/arch/x86/kernel/livepatch.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * livepatch.c - x86-specific Kernel Live Patching Core
- *
- * Copyright (C) 2014 Seth Jennings
- * Copyright (C) 2014 SUSE
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see
Re: [PATCH 2/8] clk: bcm2835: add missing PLL clock divider
ker...@martin.sperl.org writes:
> From: Martin Sperl
>
> Add the missing pll clock divider definitions.
>
> Signed-off-by: Martin Sperl
> ---
> drivers/clk/bcm/clk-bcm2835.c | 50
> +++
> include/dt-bindings/clock/bcm2835.h |8 ++
> 2 files changed, 58 insertions(+)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 01a48cb..710cf15 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1497,6 +1497,22 @@ static const struct bcm2835_clk_desc clk_desc_array[]
> = {
> .load_mask = CM_PLLA_LOADPER,
> .hold_mask = CM_PLLA_HOLDPER,
> .fixed_divider = 1),
> + [BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV(
> + .name = "plla_dsi0",
> + .source_pll = "plla",
> + .cm_reg = CM_PLLA,
> + .a2w_reg = A2W_PLLA_DSI0,
> + .load_mask = CM_PLLA_LOADDSI0,
> + .hold_mask = CM_PLLA_HOLDDSI0,
> + .fixed_divider = 1),
> + [BCM2835_PLLA_CCP2] = REGISTER_PLL_DIV(
> + .name = "plla_ccp2",
> + .source_pll = "plla",
> + .cm_reg = CM_PLLA,
> + .a2w_reg = A2W_PLLA_DSI0,
> + .load_mask = CM_PLLA_LOADCCP2,
> + .hold_mask = CM_PLLA_HOLDCCP2,
> + .fixed_divider = 1),
>
> /* PLLB is used for the ARM's clock. */
> [BCM2835_PLLB] = REGISTER_PLL(
> @@ -1521,6 +1537,24 @@ static const struct bcm2835_clk_desc clk_desc_array[]
> = {
> .load_mask = CM_PLLB_LOADARM,
> .hold_mask = CM_PLLB_HOLDARM,
> .fixed_divider = 1),
> + [BCM2835_PLLB_SP0] = REGISTER_PLL_DIV(
> + .name = "pllb_sp0",
> + .source_pll = "pllb",
> + .cm_reg = CM_PLLB,
> + .a2w_reg = A2W_PLLB_SP0,
> + .fixed_divider = 1),
> + [BCM2835_PLLB_SP1] = REGISTER_PLL_DIV(
> + .name = "pllb_sp1",
> + .source_pll = "pllb",
> + .cm_reg = CM_PLLB,
> + .a2w_reg = A2W_PLLB_SP1,
> + .fixed_divider = 1),
> + [BCM2835_PLLB_SP2] = REGISTER_PLL_DIV(
> + .name = "pllb_sp2",
> + .source_pll = "pllb",
> + .cm_reg = CM_PLLB,
> + .a2w_reg = A2W_PLLB_SP2,
> + .fixed_divider = 1),
These don't exist on the hardware as far as I've been able to find. "I
found it in a header file somewhere" is not sufficient justification to
expose it.
I'm working on getting a series of all of these reviewed and ready, so
I'm just dropping these PLLB hunks.
signature.asc
Description: PGP signature
Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
On 2016/3/17 0:31, Alex Williamson wrote: On Mon, 7 Mar 2016 15:48:34 +0800 Yongji Xie wrote: The resource_alignment will releases memory resources allocated by firmware so that kernel can reassign new resources later on. But this will cause the problem that no resources can be allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries platform because PCI_PROBE_ONLY force kernel to use firmware setup and not to reassign any resources. To solve this problem, this patch ignores resource_alignment if PCI_PROBE_ONLY was set. Signed-off-by: Yongji Xie --- Documentation/kernel-parameters.txt |2 ++ drivers/pci/probe.c |3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d8b29ab..8028631 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2922,6 +2922,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. windows need to be expanded. noresize: Don't change the resources' sizes when reassigning alignment. + Note that this option will not work if + PCI_PROBE_ONLY is set. How would a user have any idea if this is set? I found the PCI_PROBE_ONLY is set on pSeries, maple and arm with "firmware" kernel parameter enabled. So can we say: Note that this option will not work on pSeries, maple and arm with "firmware" kernel parameter enabled? Or do you have any suggestion? Thanks, Yongji Xie -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] i2c-smbus: add SMBus Host Notify support
On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires
wrote:
> SMBus Host Notify allows a slave device to act as a master on a bus to
> notify the host of an interrupt. On Intel chipsets, the functionality
> is directly implemented in the firmware. We just need to export a
> function to call .alert() on the proper device driver.
>
> i2c_handle_smbus_host_notify() behaves like i2c_handle_smbus_alert().
> When called, it schedules a task that will be able to sleep to go through
> the list of devices attached to the adapter.
>
> The current implementation allows one Host Notification to be scheduled
> while an other is running.
>
> Signed-off-by: Benjamin Tissoires
Tested-by: Andrew Duggan
> ---
>
> changes in v2:
> - do the actual processing of finding the device in i2c-smbus.c
> - remove the i2c-core implementations
> - remove the manual toggle of SMBus Host Notify
>
> no changes in v3
>
> changes in v4:
> - schedule the worker in i2c_handle_smbus_host_notify() -> it can now be
> called
> in an interrupt context.
> - introduce i2c_setup_smbus_host_notify()
>
> no changes in v5
>
> changes in v6:
> - fix the parameters of the inlined functions when the module is not compiled
>
> Documentation/i2c/smbus-protocol | 3 ++
> drivers/i2c/i2c-smbus.c | 113
> +--
> include/linux/i2c-smbus.h| 44 +++
> include/linux/i2c.h | 3 ++
> include/uapi/linux/i2c.h | 1 +
> 5 files changed, 159 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/i2c/smbus-protocol
> b/Documentation/i2c/smbus-protocol
> index 6012b12..4e07848 100644
> --- a/Documentation/i2c/smbus-protocol
> +++ b/Documentation/i2c/smbus-protocol
> @@ -199,6 +199,9 @@ alerting device's address.
>
> [S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
>
> +I2C drivers for devices which can trigger SMBus Host Notify should implement
> +the optional alert() callback.
> +
>
> Packet Error Checking (PEC)
> ===
> diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
> index 3b6765a..1de7ee5 100644
> --- a/drivers/i2c/i2c-smbus.c
> +++ b/drivers/i2c/i2c-smbus.c
> @@ -33,7 +33,8 @@ struct i2c_smbus_alert {
>
> struct alert_data {
> unsigned short addr;
> - u8 flag:1;
> + enum i2c_alert_protocol type;
> + unsigned intdata;
> };
>
> /* If this is the alerting device, notify its driver */
> @@ -56,8 +57,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
> if (client->dev.driver) {
> driver = to_i2c_driver(client->dev.driver);
> if (driver->alert)
> - driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
> - data->flag);
> + driver->alert(client, data->type, data->data);
> else
> dev_warn(&client->dev, "no driver alert()!\n");
> } else
> @@ -97,8 +97,9 @@ static void smbus_alert(struct work_struct *work)
> if (status < 0)
> break;
>
> - data.flag = status & 1;
> + data.data = status & 1;
> data.addr = status >> 1;
> + data.type = I2C_PROTOCOL_SMBUS_ALERT;
>
> if (data.addr == prev_addr) {
> dev_warn(&ara->dev, "Duplicate SMBALERT# from dev "
> @@ -106,7 +107,7 @@ static void smbus_alert(struct work_struct *work)
> break;
> }
> dev_dbg(&ara->dev, "SMBALERT# from dev 0x%02x, flag %d\n",
> - data.addr, data.flag);
> + data.addr, data.data);
>
> /* Notify driver for the device which issued the alert */
> device_for_each_child(&ara->adapter->dev, &data,
> @@ -240,6 +241,108 @@ int i2c_handle_smbus_alert(struct i2c_client *ara)
> }
> EXPORT_SYMBOL_GPL(i2c_handle_smbus_alert);
>
> +static void smbus_host_notify_work(struct work_struct *work)
> +{
> + struct alert_data alert;
> + struct i2c_adapter *adapter;
> + unsigned long flags;
> + u16 payload;
> + u8 addr;
> + struct smbus_host_notify *data;
> +
> + data = container_of(work, struct smbus_host_notify, work);
> +
> + spin_lock_irqsave(&data->lock, flags);
> + payload = data->payload;
> + addr = data->addr;
> + adapter = data->adapter;
> +
> + /* clear the pending bit and release the spinlock */
> + data->pending = false;
> + spin_unlock_irqrestore(&data->lock, flags);
> +
> + if (!adapter || !addr)
> + return;
> +
> + alert.type = I2C_PROTOCOL_SMBUS_HOST_NOTIFY;
> + alert.addr = addr;
> + alert.data = payload;
> +
> + device_for_each_child(&adapter->dev, &alert, smbus_do_alert);
> +}
> +
> +/**
> + * i2c_setup_smbus_host_notify - Alloca
Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
On Mon, 7 Mar 2016 15:48:34 +0800 Yongji Xie wrote: > The resource_alignment will releases memory resources > allocated by firmware so that kernel can reassign new > resources later on. But this will cause the problem > that no resources can be allocated by kernel if > PCI_PROBE_ONLY was set, e.g. on pSeries platform > because PCI_PROBE_ONLY force kernel to use firmware > setup and not to reassign any resources. > > To solve this problem, this patch ignores > resource_alignment if PCI_PROBE_ONLY was set. > > Signed-off-by: Yongji Xie > --- > Documentation/kernel-parameters.txt |2 ++ > drivers/pci/probe.c |3 ++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/kernel-parameters.txt > b/Documentation/kernel-parameters.txt > index d8b29ab..8028631 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -2922,6 +2922,8 @@ bytes respectively. Such letter suffixes can also be > entirely omitted. > windows need to be expanded. > noresize: Don't change the resources' sizes when > reassigning alignment. > + Note that this option will not work if > + PCI_PROBE_ONLY is set. How would a user have any idea if this is set? > ecrc= Enable/disable PCIe ECRC (transaction layer > end-to-end CRC checking). > bios: Use BIOS/firmware settings. This is the > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 6d7ab9b..bc31cad 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1719,7 +1719,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus > *bus) > pci_fixup_device(pci_fixup_header, dev); > > /* moved out from quirk header fixup code */ > - pci_reassigndev_resource_alignment(dev); > + if (!pci_has_flag(PCI_PROBE_ONLY)) > + pci_reassigndev_resource_alignment(dev); > > /* Clear the state_saved flag. */ > dev->state_saved = false; -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/6] samples: livepatch: mark as livepatch module
Mark the module as a livepatch module so that the module loader can
appropriately identify and initialize it.
Signed-off-by: Jessica Yu
---
samples/livepatch/livepatch-sample.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/samples/livepatch/livepatch-sample.c
b/samples/livepatch/livepatch-sample.c
index fb8c861..e34f871 100644
--- a/samples/livepatch/livepatch-sample.c
+++ b/samples/livepatch/livepatch-sample.c
@@ -89,3 +89,4 @@ static void livepatch_exit(void)
module_init(livepatch_init);
module_exit(livepatch_exit);
MODULE_LICENSE("GPL");
+MODULE_INFO(livepatch, "Y");
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 6/6] Documentation: livepatch: outline Elf format and requirements for patch modules
Document livepatch module requirements and the special Elf constants patch modules use. Signed-off-by: Jessica Yu --- Documentation/livepatch/module-elf-format.txt | 311 ++ 1 file changed, 311 insertions(+) create mode 100644 Documentation/livepatch/module-elf-format.txt diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt new file mode 100644 index 000..eedbdcf --- /dev/null +++ b/Documentation/livepatch/module-elf-format.txt @@ -0,0 +1,311 @@ +=== +Livepatch module Elf format +=== + +This document outlines the Elf format requirements that livepatch modules must follow. + +- +Table of Contents +- +0. Background and motivation +1. Livepatch modinfo field +2. Livepatch relocation sections + 2.1 What are livepatch relocation sections? + 2.2 Livepatch relocation section format + 2.2.1 Required flags + 2.2.2 Required name format + 2.2.3 Example livepatch relocation section names + 2.2.4 Example `readelf --sections` output + 2.2.5 Example `readelf --relocs` output +3. Livepatch symbols + 3.1 What are livepatch symbols? + 3.2 A livepatch module's symbol table + 3.3 Livepatch symbol format + 3.3.1 Required flags + 3.3.2 Required name format + 3.3.3 Example livepatch symbol names + 3.3.4 Example `readelf --symbols` output +4. Symbol table and Elf section access + + +0. Background and motivation + + +Formerly, livepatch required separate architecture-specific code to write +relocations. However, arch-specific code to write relocations already +exists in the module loader, so this former approach produced redundant +code. So, instead of duplicating code and re-implementing what the module +loader can already do, livepatch leverages existing code in the module +loader to perform the all the arch-specific relocation work. Specifically, +livepatch reuses the apply_relocate_add() function in the module loader to +write relocations. The patch module Elf format described in this document +enables livepatch to be able to do this. The hope is that this will make +livepatch more easily portable to other architectures and reduce the amount +of arch-specific code required to port livepatch to a particular +architecture. + +Since apply_relocate_add() requires access to a module's section header +table, symbol table, and relocation section indices, Elf information is +preserved for livepatch modules (see section 4). Livepatch manages its own +relocation sections and symbols, which are described in this document. The +Elf constants used to mark livepatch symbols and relocation sections were +selected from OS-specific ranges according to the definitions from glibc. + +0.1 Why does livepatch need to write its own relocations? +- +A typical livepatch module contains patched versions of functions that can +reference non-exported global symbols and non-included local symbols. +Relocations referencing these types of symbols cannot be left in as-is +since the kernel module loader cannot resolve them and will therefore +reject the livepatch module. Furthermore, we cannot apply relocations that +affect modules not yet loaded at patch module load time (e.g. a patch to a +driver that is not loaded). Formerly, livepatch solved this problem by +embedding special "dynrela" (dynamic rela) sections in the resulting patch +module Elf output. Using these dynrela sections, livepatch could resolve +symbols while taking into account its scope and what module the symbol +belongs to, and then manually apply the dynamic relocations. However this +approach required livepatch to supply arch-specific code in order to write +these relocations. In the new format, livepatch manages its own SHT_RELA +relocation sections in place of dynrela sections, and the symbols that the +relas reference are special livepatch symbols (see section 2 and 3). The +arch-specific livepatch relocation code is replaced by a call to +apply_relocate_add(). + + +PATCH MODULE FORMAT REQUIREMENTS + + +-- +1. Livepatch modinfo field +-- + +Livepatch modules are required to have the "livepatch" modinfo attribute. +See the sample livepatch module in samples/livepatch/ for how this is done. + +Livepatch modules can be identified by users by using the 'modinfo' command +and looking for the presence of the "livepatch" field. This field is also +used by the kernel module loader to identify livepatch modules. + +Example modinfo output: +--- +% modinfo livepatch-meminfo.ko +filename: livepatch-meminfo.ko +livepatch: Y +license: GPL +depends: +vermagic: 4.3.0+ SMP mod_unload
Re: [PATCH v6 1/4] i2c: add a protocol parameter to the alert callback
Looks ok to me. For IPMI:
Acked-by: Corey Minyard
On 03/16/2016 11:39 AM, Benjamin Tissoires wrote:
.alert() is meant to be generic, but there is currently no way
for the device driver to know which protocol generated the alert.
Add a parameter in .alert() to help the device driver to understand
what is given in data.
This patch is required to have the support of SMBus Host Notify protocol
through .alert().
Signed-off-by: Benjamin Tissoires
---
new in v2
changes in v3:
- added also lm90.c to support the new API
no changes in v4
no changes in v5
changes in v6:
- made sure lm90 also checks for the type of alert first
drivers/char/ipmi/ipmi_ssif.c | 6 +-
drivers/hwmon/lm90.c | 6 +-
drivers/i2c/i2c-smbus.c | 3 ++-
include/linux/i2c.h | 7 ++-
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 5f1c3d0..1d67fa3 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -568,12 +568,16 @@ static void retry_timeout(unsigned long data)
}
-static void ssif_alert(struct i2c_client *client, unsigned int data)
+static void ssif_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+ unsigned int data)
{
struct ssif_info *ssif_info = i2c_get_clientdata(client);
unsigned long oflags, *flags;
bool do_get = false;
+ if (type != I2C_PROTOCOL_SMBUS_ALERT)
+ return;
+
ssif_inc_stat(ssif_info, alerts);
flags = ipmi_ssif_lock_cond(ssif_info, &oflags);
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..a00fd38 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -1624,10 +1624,14 @@ static int lm90_remove(struct i2c_client *client)
return 0;
}
-static void lm90_alert(struct i2c_client *client, unsigned int flag)
+static void lm90_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+ unsigned int flag)
{
u16 alarms;
+ if (type != I2C_PROTOCOL_SMBUS_ALERT)
+ return;
+
if (lm90_is_tripped(client, &alarms)) {
/*
* Disable ALERT# output, because these chips don't implement
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index abb55d3..3b6765a 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -56,7 +56,8 @@ static int smbus_do_alert(struct device *dev, void *addrp)
if (client->dev.driver) {
driver = to_i2c_driver(client->dev.driver);
if (driver->alert)
- driver->alert(client, data->flag);
+ driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
+ data->flag);
else
dev_warn(&client->dev, "no driver alert()!\n");
} else
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 200cf13b..baae02a 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -126,6 +126,10 @@ i2c_smbus_read_i2c_block_data_or_emulated(const struct
i2c_client *client,
u8 command, u8 length, u8 *values);
#endif /* I2C */
+enum i2c_alert_protocol {
+ I2C_PROTOCOL_SMBUS_ALERT,
+};
+
/**
* struct i2c_driver - represent an I2C device driver
* @class: What kind of i2c device we instantiate (for detect)
@@ -181,7 +185,8 @@ struct i2c_driver {
* For the SMBus alert protocol, there is a single bit of data passed
* as the alert response's low bit ("event flag").
*/
- void (*alert)(struct i2c_client *, unsigned int data);
+ void (*alert)(struct i2c_client *, enum i2c_alert_protocol protocol,
+ unsigned int data);
/* a ioctl like command that can be used to perform specific functions
* with the device.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] serial: doc: .break_ctl() is called with port->mutex() held
On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote: > Note that mutex_lock() should not be called with interrupts disabled. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/serial/driver | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/Documentation/serial/driver b/Documentation/serial/driver > index 3b08df5bcc17e944..09e73e061fcf795c 100644 > --- a/Documentation/serial/driver > +++ b/Documentation/serial/driver > @@ -177,8 +177,7 @@ hardware. > should be terminated when another call is made with a zero > ctl. > > - Locking: none. > - Interrupts: caller dependent. > + Locking: caller holds port->mutex > This call must not sleep ^^^ And remove this line as well. > >startup(port) > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table
On Wed, Mar 16, 2016 at 06:51:56PM +0800, Yongji Xie wrote: > > Ping. This is mainly VFIO stuff, and Alex had some security concerns, so I'm not going to spend much time looking at this until he's satisfied. When I do, I'll be looking hard at the resource_alignment kernel parameter. I'm opposed to kernel parameters in general because they're very difficult for users to use correctly, and they lead to kernel code paths that are rarely tested and hard to maintain. So I'll be looking for an excuse to reject changes in that area. The changelog for 2/7 says it "replaces IORESOURCE_STARTALIGN with IORESOURCE_WINDOW." But even a glance at the patch itself shows that IORESOURCE_WINDOW is *added* to some places, and it doesn't *replace* IORESOURCE_STARTALIGN. The changelog for 4/7 says: This is because vfio will not allow to passthrough one BAR's mmio page which may be shared with other BARs. To solve this performance issue ... with no mention at all of the actual *reason* vfio doesn't allow that passthrough. If I understand correctly, that reason has to do with security, so your justification must be much stronger than "solving a performance issue." > On 2016/3/7 15:48, Yongji Xie wrote: > >Current vfio-pci implementation disallows to mmap > >sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because > >sub-page BARs' mmio page may be shared with other BARs and MSI-X table > >should not be accessed directly from the guest for security reasons. > > > >But these will easily cause some performance issues for mmio accesses > >in guest when vfio passthrough sub-page BARs or BARs containing MSI-X > >table on PPC64 platform. This is because PAGE_SIZE is 64KB by default > >on PPC64 platform and the big page may easily hit the sub-page MMIO > >BARs' unmmapping and cause the unmmaping of the mmio page which > >MSI-X table locate in, which lead to mmio emulation in host. > > > >For sub-page MMIO BARs' unmmapping, this patchset modifies > >resource_alignment kernel parameter to enforce the alignment of all > >MMIO BARs to be at least PAGE_SZIE so that sub-page BAR's mmio page > >will not be shared with other BARs. Then we can mmap sub-page MMIO BARs > >in vfio-pci driver with the modified resource_alignment. > > > >For MSI-X table's unmmapping, we think MSI-X table is safe to access > >directly from userspace if PCI host bridge support filtering of MSIs > >which can ensure that a given pci device can only shoot the MSIs > >assigned for it. So we allow to mmap MSI-X table if > >IOMMU_CAP_INTR_REMAP was set. And we add IOMMU_CAP_INTR_REMAP for > >IODA host bridge on PPC64 platform. > > > >With this patchset applied, we can get almost 100% improvement on > >performance for mmio accesses when we passthrough sub-page BARs to guest > >in our test. > > > >The two vfio related patches(patch 5 and patch 6) are based on the > >proposed patchset[1]. > > > >Changelog v4: > >- Rebase on v4.5-rc6 with patchset[1] applied. > >- Remove resource_page_aligned kernel parameter > >- Fix some problems with resource_alignment kernel parameter > >- Modify resource_alignment kernel parameter to support multiple > > devices. > >- Remove host bridge attribute: msi_filtered > >- Use IOMMU_CAP_INTR_REMAP to check if MSI-X table can be mmapped > >- Add IOMMU_CAP_INTR_REMAP for IODA host bridge on PPC64 platform > > > >Changelog v3: > >- Rebase on new linux kernel mainline with the patchset[1] applied. > >- Add a function to check whether PCI BARs'mmio page is shared with > > other BARs. > >- Add a host bridge attribute to indicate PCI host bridge support > > filtering of MSIs. > >- Use the new host bridge attribute to check if MSI-X table can > > be mmapped instead of CONFIG_EEH. > >- Remove Kconfig option VFIO_PCI_MMAP_MSIX > > > >Changelog v2: > >- Rebase on v4.4-rc6 with the patchset[1] applied. > >- Use kernel parameter to enforce all MMIO BARs to be page aligned > > on PCI core code instead of doing it on PPC64 arch code. > >- Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED > > VFIO_DEVICE_FLAGS_PCI_MSIX_MMAP > >- Add a Kconfig option to support for mmapping MSI-X table. > > > >[1] http://www.spinics.net/lists/kvm/msg127812.html > > > >Yongji Xie (7): > > PCI: Add a new option for resource_alignment to reassign alignment > > PCI: Use IORESOURCE_WINDOW to identify bridge resources > > PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set > > PCI: Modify resource_alignment to support multiple devices > > vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive > > vfio-pci: Allow to mmap MSI-X table if IOMMU_CAP_INTR_REMAP was set > > powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge > > > > Documentation/kernel-parameters.txt |9 ++- > > arch/powerpc/platforms/powernv/pci-ioda.c | 17 > > drivers/pci/pci.c | 126 > > - > > drivers/pci/probe.c |3 +-
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> This patch implements a proxy driver for supporting multiple emulated TPMs
> in a system.
>
> The driver implements a device /dev/vtpmx that is used to created
> a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that
> is accessed using a file descriptor returned by an ioctl.
> The device /dev/tpmX is the usual TPM device created by the core TPM
> driver. Applications or kernel subsystems can send TPM commands to it
> and the corresponding server-side file descriptor receives these
> commands and delivers them to an emulated TPM.
>
> Signed-off-by: Stefan Berger
> CC: linux-ker...@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> CC: linux-...@vger.kernel.org
> ---
> drivers/char/tpm/Kconfig | 10 +
> drivers/char/tpm/Makefile | 1 +
> drivers/char/tpm/tpm_vtpm_proxy.c | 572
> ++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/vtpm_proxy.h | 42 +++
> 5 files changed, 626 insertions(+)
> create mode 100644 drivers/char/tpm/tpm_vtpm_proxy.c
> create mode 100644 include/uapi/linux/vtpm_proxy.h
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index 3b84a8b..0eac596 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -122,5 +122,15 @@ config TCG_CRB
> from within Linux. To compile this driver as a module, choose
> M here; the module will be called tpm_crb.
>
> +config TCG_VTPM_PROXY
> + tristate "VTPM Proxy Interface"
> + depends on TCG_TPM
> + ---help---
> + This driver proxies for an emulated TPM (vTPM) running in userspace.
> + A device /dev/vtpmx is provided that creates a device pair
> + /dev/vtpmX and a server-side file descriptor on which the vTPM
> + can receive commands.
> +
> +
> source "drivers/char/tpm/st33zp24/Kconfig"
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index 56e8f1f..98de5e6 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
> obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
> obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> obj-$(CONFIG_TCG_CRB) += tpm_crb.o
> +obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> new file mode 100644
> index 000..2bb2c8c
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -0,0 +1,572 @@
> +/*
> + * Copyright (C) 2015, 2016 IBM Corporation
> + *
> + * Author: Stefan Berger
> + *
> + * Maintained by:
> + *
> + * Device driver for vTPM (vTPM proxy driver)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation, version 2 of the
> + * License.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "tpm.h"
> +
> +#define VTPM_PROXY_REQ_COMPLETE_FLAG BIT(0)
> +
> +struct proxy_dev {
> + struct tpm_chip *chip;
> +
> + u32 flags; /* public API flags */
> +
> + wait_queue_head_t wq;
> +
> + struct mutex buf_lock; /* protect buffer and flags */
> +
> + long state; /* internal state */
> +#define STATE_OPENED_FLAGBIT(0)
> +#define STATE_WAIT_RESPONSE_FLAG BIT(1) /* waiting for emulator response */
> +
> + size_t req_len; /* length of queued TPM request */
> + size_t resp_len; /* length of queued TPM response */
> + u8 buffer[TPM_BUFSIZE]; /* request/response buffer */
> +};
> +
> +
> +static void vtpm_proxy_delete_device(struct proxy_dev *proxy_dev);
> +
> +/*
> + * Functions related to 'server side'
> + */
> +
> +/**
> + * vtpm_proxy_fops_read - Read TPM commands on 'server side'
> + *
> + * Return value:
> + * Number of bytes read or negative error code
> + */
> +static ssize_t vtpm_proxy_fops_read(struct file *filp, char __user *buf,
> + size_t count, loff_t *off)
> +{
> + struct proxy_dev *proxy_dev = filp->private_data;
> + size_t len;
> + int sig, rc;
> +
> + sig = wait_event_interruptible(proxy_dev->wq, proxy_dev->req_len != 0);
> + if (sig)
> + return -EINTR;
> +
> + mutex_lock(&proxy_dev->buf_lock);
> +
> + len = proxy_dev->req_len;
> +
> + if (count < len) {
> + mutex_unlock(&proxy_dev->buf_lock);
> + pr_debug("Invalid size in recv: count=%zd, req_len=%zd\n",
> + count, len);
> + return -EIO;
> + }
> +
> + rc = copy_to_user(buf, proxy_dev->buffer, len);
> + memset(proxy_dev->buffer, 0, len);
> + proxy_dev->req_len = 0;
> +
> + if (!rc)
> + proxy_dev->
Re: [RFC PATCH v4 4/7] PCI: Modify resource_alignment to support multiple devices
On Mon, 7 Mar 2016 15:48:35 +0800
Yongji Xie wrote:
> When vfio passthrough a PCI device of which MMIO BARs
> are smaller than PAGE_SIZE, guest will not handle the
> mmio accesses to the BARs which leads to mmio emulations
> in host.
>
> This is because vfio will not allow to passthrough one
> BAR's mmio page which may be shared with other BARs.
>
> To solve this performance issue, this patch modifies
> resource_alignment to support syntax where multiple
> devices get the same alignment. So we can use something
> like "pci=resource_alignment=*:*:*.*:noresize" to
> enforce the alignment of all MMIO BARs to be at least
> PAGE_SIZE so that one BAR's mmio page would not be
> shared with other BARs.
>
> Signed-off-by: Yongji Xie
> ---
> Documentation/kernel-parameters.txt |2 +
> drivers/pci/pci.c | 90
> ++-
> include/linux/pci.h |4 ++
> 3 files changed, 85 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 8028631..74b38ab 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> aligned memory resources.
> If is not specified,
> PAGE_SIZE is used as alignment.
> + , , and can be set to
> + "*" which means match all values.
I don't see anywhere that you're automatically enabling this for your
platform, so presumably you're expecting users to determine on their
own that they have a performance problem and hoping that they'll figure
out that they need to use this option to resolve it. The first irate
question you'll get back is why doesn't this happen automatically?
> PCI-PCI bridge can be specified, if resource
> windows need to be expanded.
> noresize: Don't change the resources' sizes when
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 760cce5..44ab59f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -102,6 +102,8 @@ unsigned int pcibios_max_latency = 255;
> /* If set, the PCIe ARI capability will not be used. */
> static bool pcie_ari_disabled;
>
> +bool pci_resources_page_aligned;
> +
> /**
> * pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
> * @bus: pointer to PCI bus structure to search
> @@ -4604,6 +4606,7 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> int seg, bus, slot, func, align_order, count;
> resource_size_t align = 0;
> char *p;
> + bool invalid = false;
>
> spin_lock(&resource_alignment_lock);
> p = resource_alignment_param;
> @@ -4615,16 +4618,49 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> } else {
> align_order = -1;
> }
> - if (sscanf(p, "%x:%x:%x.%x%n",
> - &seg, &bus, &slot, &func, &count) != 4) {
> + if (p[0] == '*' && p[1] == ':') {
> + seg = -1;
> + count = 1;
> + } else if (sscanf(p, "%x%n", &seg, &count) != 1 ||
> + p[count] != ':') {
> + invalid = true;
> + break;
> + }
> + p += count + 1;
> + if (*p == '*') {
> + bus = -1;
> + count = 1;
> + } else if (sscanf(p, "%x%n", &bus, &count) != 1) {
> + invalid = true;
> + break;
> + }
> + p += count;
> + if (*p == '.') {
> + slot = bus;
> + bus = seg;
> seg = 0;
> - if (sscanf(p, "%x:%x.%x%n",
> - &bus, &slot, &func, &count) != 3) {
> - /* Invalid format */
> - printk(KERN_ERR "PCI: Can't parse
> resource_alignment parameter: %s\n",
> - p);
> + p++;
> + } else if (*p == ':') {
> + p++;
> + if (p[0] == '*' && p[1] == '.') {
> + slot = -1;
> + count = 1;
> + } else if (sscanf(p, "%x%n", &slot, &count) != 1 ||
> + p[count] != '.') {
> + invalid = true;
> break;
> }
> + p += count + 1;
> + } else {
> + invalid = true;
> +
Re: [PATCH 1/9] serial: doc: Un-document non-existing uart_write_console()
Hi Geert,
On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote:
> uart_write_console() never existed, not even when the "new
> uart_write_console function" was documented.
Right. Should be uart_console_write()
> Fixes: 67ab7f596b6adbae ("[SERIAL] Update serial driver documentation")
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/serial/driver | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/Documentation/serial/driver b/Documentation/serial/driver
> index 379468e12680dbfb..e7c6f86ee06f9927 100644
> --- a/Documentation/serial/driver
> +++ b/Documentation/serial/driver
> @@ -28,11 +28,6 @@ The serial core provides a few helper functions. This
> includes identifing
> the correct port structure (via uart_get_console) and decoding command line
> arguments (uart_parse_options).
>
> -There is also a helper function (uart_write_console) which performs a
> -character by character write, translating newlines to CRLF sequences.
> -Driver writers are recommended to use this function rather than implementing
> -their own version.
> -
>
> Locking
> ---
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] clk: bcm2835: add the dsi clocks
ker...@martin.sperl.org writes: > From: Martin Sperl > > Add the missing dsi clocks using the currently "best known" > parent-mux available for these clocks. Having been working on DSI support, there is definitely no point in DSI0 and DSI1 pixel clocks without their proper parents and this patch would just get in the way. The esc clocks look fine, though. signature.asc Description: PGP signature
Re: [PATCH v5 2/6] module: preserve Elf information for livepatch modules
Hi Jessica,
[auto build test ERROR on s390/features]
[also build test ERROR on v4.5 next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jessica-Yu/mostly-Arch-independent-livepatch/20160317-035230
base: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: x86_64-randconfig-x016-201611 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from include/linux/moduleloader.h:5,
from kernel/module.c:20:
kernel/module.c: In function 'find_livepatch_modinfo':
>> kernel/module.c:2767:10: error: expected ')' before 'mod'
mod->name);
^
include/linux/printk.h:236:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^
>> kernel/module.c:2766:3: note: in expansion of macro 'pr_err'
pr_err("%s: module is marked as livepatch module, but livepatch support
is disabled"
^
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from include/linux/moduleloader.h:5,
from kernel/module.c:20:
>> include/linux/kern_levels.h:4:18: warning: format '%s' expects a matching
>> 'char *' argument [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^
include/linux/printk.h:252:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^
>> kernel/module.c:2766:3: note: in expansion of macro 'pr_err'
pr_err("%s: module is marked as livepatch module, but livepatch support
is disabled"
^
vim +2767 kernel/module.c
2760 return 0;
2761 }
2762 #else /* !CONFIG_LIVEPATCH */
2763 static int find_livepatch_modinfo(struct module *mod, struct load_info
*info)
2764 {
2765 if (get_modinfo(info, "livepatch")) {
> 2766 pr_err("%s: module is marked as livepatch module, but
> livepatch support is disabled"
> 2767 mod->name);
2768 return -ENOEXEC;
2769 }
2770
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v6 3/4] i2c: i801: add support of Host Notify
On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires
wrote:
> The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
> in
> http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf
>
> Enable the functionality unconditionally and propagate the alert
> on each notification.
>
> With a T440s and a Synaptics touchpad that implements Host Notify, the
> payload data is always 0x, so I am not sure if the device actually
> sends the payload or if there is a problem regarding the implementation.
>
> Signed-off-by: Benjamin Tissoires
Tested-by: Andrew Duggan
> ---
>
> changes in v2:
> - removed the description of the Slave functionality support in the chip table
> (the table shows what is supported, not what the hardware is capable of)
> - use i2c-smbus to forward the notification
> - remove the fifo, and directly retrieve the address and payload in the worker
> - do not check for Host Notification is the feature is not enabled
> - use inw_p() to read the payload instead of 2 inb_p() calls
> - add /* fall-through */ comment
> - unconditionally enable Host Notify if the hardware supports it (can be
> disabled by the user)
>
> no changes in v3
>
> changes in v4:
> - make use of the new API -> no more worker spawning here
> - solved a race between the access of the Host Notify registers and the actual
> I2C transfers.
>
> changes in v5:
> - added SKL Host Notify support
>
> changes in v6:
> - select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
> is set to 'Y' while I2C_SMBUS is set to 'M'
>
> drivers/i2c/busses/Kconfig| 1 +
> drivers/i2c/busses/i2c-i801.c | 85
> +--
> 2 files changed, 83 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index faa8e68..8c8fa12 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -91,6 +91,7 @@ config I2C_I801
> tristate "Intel 82801 (ICH/PCH)"
> depends on PCI
> select CHECK_SIGNATURE if X86 && DMI
> + select I2C_SMBUS
> help
> If you say yes to this option, support will be included for the
> Intel
> 801 family of mainboard I2C interfaces. Specifically, the following
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 585a3b7..b244aa40 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -72,6 +72,7 @@
> * Block process call transaction no
> * I2C block read transaction yes (doesn't use the block buffer)
> * Slave mode no
> + * SMBus Host Notify yes
> * Interrupt processingyes
> *
> * See the file Documentation/i2c/busses/i2c-i801 for details.
> @@ -86,6 +87,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -112,6 +114,10 @@
> #define SMBPEC(p) (8 + (p)->smba) /* ICH3 and later */
> #define SMBAUXSTS(p) (12 + (p)->smba)/* ICH4 and later */
> #define SMBAUXCTL(p) (13 + (p)->smba)/* ICH4 and later */
> +#define SMBSLVSTS(p) (16 + (p)->smba)/* ICH3 and later */
> +#define SMBSLVCMD(p) (17 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDADD(p) (20 + (p)->smba)/* ICH3 and later */
> +#define SMBNTFDDAT(p) (22 + (p)->smba)/* ICH3 and later */
>
> /* PCI Address Constants */
> #define SMBBAR 4
> @@ -176,6 +182,12 @@
> #define SMBHSTSTS_INTR 0x02
> #define SMBHSTSTS_HOST_BUSY0x01
>
> +/* Host Notify Status registers bits */
> +#define SMBSLVSTS_HST_NTFY_STS 1
> +
> +/* Host Notify Command registers bits */
> +#define SMBSLVCMD_HST_NTFY_INTREN 0x01
> +
> #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
> SMBHSTSTS_DEV_ERR)
>
> @@ -244,13 +256,18 @@ struct i801_priv {
> struct platform_device *mux_pdev;
> #endif
> struct platform_device *tco_pdev;
> +
> + struct smbus_host_notify *host_notify;
> };
>
> +#define SMBHSTNTFY_SIZE8
> +
> #define FEATURE_SMBUS_PEC (1 << 0)
> #define FEATURE_BLOCK_BUFFER (1 << 1)
> #define FEATURE_BLOCK_PROC (1 << 2)
> #define FEATURE_I2C_BLOCK_READ (1 << 3)
> #define FEATURE_IRQ(1 << 4)
> +#define FEATURE_HOST_NOTIFY(1 << 5)
> /* Not really a feature, but it's convenient to handle it as such */
> #define FEATURE_IDF(1 << 15)
> #define FEATURE_TCO(1 << 16)
> @@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
> "Block process call",
> "I2C block read",
> "Interrupt",
> + "SMBus Host Notify",
> };
>
> static unsigned int disable_features;
> @@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, "Disable selected
> driver features:\n"
> "\t\t 0x01 disable SMBus PEC\n"
>
[PATCH v5 1/6] Elf: add livepatch-specific Elf constants
Livepatch manages its own relocation sections and symbols in order to be
able to reuse module loader code to write relocations. This removes
livepatch's dependence on separate "dynrela" sections to write relocations
and also allows livepatch to patch modules that are not yet loaded.
The livepatch Elf relocation section flag (SHF_RELA_LIVEPATCH),
and symbol section index (SHN_LIVEPATCH) allow both livepatch and the
module loader to identity livepatch relocation sections and livepatch
symbols.
Livepatch relocation sections are marked with SHF_RELA_LIVEPATCH to
indicate to the module loader that it should not apply that relocation
section and that livepatch will handle them.
The SHN_LIVEPATCH shndx marks symbols that will be resolved by livepatch.
The module loader ignores these symbols and does not attempt to resolve
them.
The values of these Elf constants were selected from OS-specific
ranges according to the definitions from glibc.
Signed-off-by: Jessica Yu
---
include/uapi/linux/elf.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 71e1d0e..cb4a72f 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -282,16 +282,18 @@ typedef struct elf64_phdr {
#define SHT_HIUSER 0x
/* sh_flags */
-#define SHF_WRITE 0x1
-#define SHF_ALLOC 0x2
-#define SHF_EXECINSTR 0x4
-#define SHF_MASKPROC 0xf000
+#define SHF_WRITE 0x1
+#define SHF_ALLOC 0x2
+#define SHF_EXECINSTR 0x4
+#define SHF_RELA_LIVEPATCH 0x0010
+#define SHF_MASKPROC 0xf000
/* special section indexes */
#define SHN_UNDEF 0
#define SHN_LORESERVE 0xff00
#define SHN_LOPROC 0xff00
#define SHN_HIPROC 0xff1f
+#define SHN_LIVEPATCH 0xff20
#define SHN_ABS0xfff1
#define SHN_COMMON 0xfff2
#define SHN_HIRESERVE 0x
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] Input: synaptics-rmi4 - add SMBus support
Code obtained from
https://raw.githubusercontent.com/mightybigcar/synaptics-rmi4/jf/drivers/input/rmi4/rmi_smbus.c
and updated to match upstream. And fixed to make it work.
Signed-off-by: Benjamin Tissoires
Signed-off-by: Andrew Duggan
---
new in v5
no changes in v6
drivers/input/rmi4/Kconfig | 12 ++
drivers/input/rmi4/Makefile| 1 +
drivers/input/rmi4/rmi_bus.h | 12 ++
drivers/input/rmi4/rmi_smbus.c | 416 +
4 files changed, 441 insertions(+)
create mode 100644 drivers/input/rmi4/rmi_smbus.c
diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..86a180b 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -27,6 +27,18 @@ config RMI4_SPI
If unsure, say N.
+config RMI4_SMB
+ tristate "RMI4 SMB Support"
+ depends on RMI4_CORE && I2C
+ help
+ Say Y here if you want to support RMI4 devices connected to an SMB
+ bus.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called rmi_smbus.
+
config RMI4_2D_SENSOR
bool
depends on RMI4_CORE
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..3c8ebf2 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -11,3 +11,4 @@ rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
# Transports
obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
obj-$(CONFIG_RMI4_SPI) += rmi_spi.o
+obj-$(CONFIG_RMI4_SMB) += rmi_smbus.o
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 8995798..b7625a9 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -105,6 +105,18 @@ rmi_get_platform_data(struct rmi_device *d)
bool rmi_is_physical_device(struct device *dev);
/**
+ * rmi_reset - reset a RMI4 device
+ * @d: Pointer to an RMI device
+ *
+ * Calls for a reset of each function implemented by a specific device.
+ * Returns 0 on success or a negative error code.
+ */
+static inline int rmi_reset(struct rmi_device *d)
+{
+ return d->driver->reset_handler(d);
+}
+
+/**
* rmi_read - read a single byte
* @d: Pointer to an RMI device
* @addr: The address to read from
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
new file mode 100644
index 000..eed6821
--- /dev/null
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -0,0 +1,416 @@
+/*
+ * Copyright (c) 2015 - 2016 Red Hat, Inc
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define SMB_PROTOCOL_VERSION_ADDRESS 0xfd
+#define SMB_MAX_COUNT 32
+#define RMI_SMB2_MAP_SIZE 8 /* 8 entry of 4 bytes each */
+#define RMI_SMB2_MAP_FLAGS_WE 0x01
+
+struct mapping_table_entry {
+ u16 rmiaddr;
+ u8 readcount;
+ u8 flags;
+};
+
+struct rmi_smb_xport {
+ struct rmi_transport_dev xport;
+ struct i2c_client *client;
+
+ struct mutex page_mutex;
+ int page;
+ u8 table_index;
+ struct mutex mappingtable_mutex;
+ struct mapping_table_entry mapping_table[RMI_SMB2_MAP_SIZE];
+};
+
+static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
+{
+ struct i2c_client *client = rmi_smb->client;
+ int retval;
+
+ /* Check if for SMBus new version device by reading version byte. */
+ retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
+ if (retval < 0) {
+ dev_err(&client->dev, "failed to get SMBus version number!\n");
+ return retval;
+ }
+ return retval + 1;
+}
+
+/* SMB block write - wrapper over ic2_smb_write_block */
+static int smb_block_write(struct rmi_transport_dev *xport,
+ u8 commandcode, const void *buf, size_t len)
+{
+ struct rmi_smb_xport *rmi_smb =
+ container_of(xport, struct rmi_smb_xport, xport);
+ struct i2c_client *client = rmi_smb->client;
+ int retval;
+
+ retval = i2c_smbus_write_block_data(client, commandcode, len, buf);
+
+ rmi_dbg(RMI_DEBUG_XPORT, &client->dev,
+ "wrote %zd bytes at %#04x: %d (%*ph)\n",
+ len, commandcode, retval, (int)len, buf);
+
+ return retval;
+}
+
+/*
+ * The function to get command code for smbus operations and keeps
+ * records to the driver mapping table
+ */
+static int rmi_smb_get_command_code(struct rmi_transport_dev *xport,
+ u16 rmiaddr, int bytecount, bool isread, u8 *commandcode)
+{
+ struct rmi_smb_xport *rmi_smb =
+ container_of(xport, struct rmi_smb_xp
Re: [PATCH v5 2/6] module: preserve Elf information for livepatch modules
Hi Jessica,
[auto build test WARNING on s390/features]
[also build test WARNING on v4.5 next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jessica-Yu/mostly-Arch-independent-livepatch/20160317-035230
base: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: openrisc-or1ksim_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All warnings (new ones prefixed by >>):
kernel/module.c: In function 'find_livepatch_modinfo':
kernel/module.c:2766:3: error: expected ')' before 'mod'
>> kernel/module.c:2766:3: warning: too few arguments for format
vim +2766 kernel/module.c
2750 len -= n;
2751 } while (len);
2752 return 0;
2753 }
2754
2755 #ifdef CONFIG_LIVEPATCH
2756 static int find_livepatch_modinfo(struct module *mod, struct load_info
*info)
2757 {
2758 mod->klp = get_modinfo(info, "livepatch") ? true : false;
2759
2760 return 0;
2761 }
2762 #else /* !CONFIG_LIVEPATCH */
2763 static int find_livepatch_modinfo(struct module *mod, struct load_info
*info)
2764 {
2765 if (get_modinfo(info, "livepatch")) {
> 2766 pr_err("%s: module is marked as livepatch module, but
> livepatch support is disabled"
2767 mod->name);
2768 return -ENOEXEC;
2769 }
2770
2771 return 0;
2772 }
2773 #endif /* CONFIG_LIVEPATCH */
2774
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v5 2/6] module: preserve Elf information for livepatch modules
Hi Jessica,
[auto build test WARNING on s390/features]
[also build test WARNING on v4.5 next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jessica-Yu/mostly-Arch-independent-livepatch/20160317-035230
base: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from include/linux/moduleloader.h:5,
from kernel/module.c:20:
kernel/module.c: In function 'find_livepatch_modinfo':
kernel/module.c:2767:10: error: expected ')' before 'mod'
mod->name);
^
include/linux/printk.h:236:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^
kernel/module.c:2766:3: note: in expansion of macro 'pr_err'
pr_err("%s: module is marked as livepatch module, but livepatch support
is disabled"
^
>> kernel/module.c:2767:10: warning: format '%s' expects a matching 'char *'
>> argument [-Wformat=]
mod->name);
^
include/linux/printk.h:236:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^
kernel/module.c:2766:3: note: in expansion of macro 'pr_err'
pr_err("%s: module is marked as livepatch module, but livepatch support
is disabled"
^
vim +2767 kernel/module.c
2751 } while (len);
2752 return 0;
2753 }
2754
2755 #ifdef CONFIG_LIVEPATCH
2756 static int find_livepatch_modinfo(struct module *mod, struct load_info
*info)
2757 {
2758 mod->klp = get_modinfo(info, "livepatch") ? true : false;
2759
2760 return 0;
2761 }
2762 #else /* !CONFIG_LIVEPATCH */
2763 static int find_livepatch_modinfo(struct module *mod, struct load_info
*info)
2764 {
2765 if (get_modinfo(info, "livepatch")) {
2766 pr_err("%s: module is marked as livepatch module, but
livepatch support is disabled"
> 2767 mod->name);
2768 return -ENOEXEC;
2769 }
2770
2771 return 0;
2772 }
2773 #endif /* CONFIG_LIVEPATCH */
2774
2775 /* Sets info->hdr and info->len. */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v6 1/4] i2c: add a protocol parameter to the alert callback
On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires
wrote:
> .alert() is meant to be generic, but there is currently no way
> for the device driver to know which protocol generated the alert.
> Add a parameter in .alert() to help the device driver to understand
> what is given in data.
>
> This patch is required to have the support of SMBus Host Notify protocol
> through .alert().
>
> Signed-off-by: Benjamin Tissoires
Tested-by: Andrew Duggan
> ---
>
> new in v2
>
> changes in v3:
> - added also lm90.c to support the new API
>
> no changes in v4
>
> no changes in v5
>
> changes in v6:
> - made sure lm90 also checks for the type of alert first
>
> drivers/char/ipmi/ipmi_ssif.c | 6 +-
> drivers/hwmon/lm90.c | 6 +-
> drivers/i2c/i2c-smbus.c | 3 ++-
> include/linux/i2c.h | 7 ++-
> 4 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
> index 5f1c3d0..1d67fa3 100644
> --- a/drivers/char/ipmi/ipmi_ssif.c
> +++ b/drivers/char/ipmi/ipmi_ssif.c
> @@ -568,12 +568,16 @@ static void retry_timeout(unsigned long data)
> }
>
>
> -static void ssif_alert(struct i2c_client *client, unsigned int data)
> +static void ssif_alert(struct i2c_client *client, enum i2c_alert_protocol
> type,
> + unsigned int data)
> {
> struct ssif_info *ssif_info = i2c_get_clientdata(client);
> unsigned long oflags, *flags;
> bool do_get = false;
>
> + if (type != I2C_PROTOCOL_SMBUS_ALERT)
> + return;
> +
> ssif_inc_stat(ssif_info, alerts);
>
> flags = ipmi_ssif_lock_cond(ssif_info, &oflags);
> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
> index c9ff08d..a00fd38 100644
> --- a/drivers/hwmon/lm90.c
> +++ b/drivers/hwmon/lm90.c
> @@ -1624,10 +1624,14 @@ static int lm90_remove(struct i2c_client *client)
> return 0;
> }
>
> -static void lm90_alert(struct i2c_client *client, unsigned int flag)
> +static void lm90_alert(struct i2c_client *client, enum i2c_alert_protocol
> type,
> + unsigned int flag)
> {
> u16 alarms;
>
> + if (type != I2C_PROTOCOL_SMBUS_ALERT)
> + return;
> +
> if (lm90_is_tripped(client, &alarms)) {
> /*
> * Disable ALERT# output, because these chips don't implement
> diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
> index abb55d3..3b6765a 100644
> --- a/drivers/i2c/i2c-smbus.c
> +++ b/drivers/i2c/i2c-smbus.c
> @@ -56,7 +56,8 @@ static int smbus_do_alert(struct device *dev, void *addrp)
> if (client->dev.driver) {
> driver = to_i2c_driver(client->dev.driver);
> if (driver->alert)
> - driver->alert(client, data->flag);
> + driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
> + data->flag);
> else
> dev_warn(&client->dev, "no driver alert()!\n");
> } else
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 200cf13b..baae02a 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -126,6 +126,10 @@ i2c_smbus_read_i2c_block_data_or_emulated(const struct
> i2c_client *client,
> u8 command, u8 length, u8 *values);
> #endif /* I2C */
>
> +enum i2c_alert_protocol {
> + I2C_PROTOCOL_SMBUS_ALERT,
> +};
> +
> /**
> * struct i2c_driver - represent an I2C device driver
> * @class: What kind of i2c device we instantiate (for detect)
> @@ -181,7 +185,8 @@ struct i2c_driver {
> * For the SMBus alert protocol, there is a single bit of data passed
> * as the alert response's low bit ("event flag").
> */
> - void (*alert)(struct i2c_client *, unsigned int data);
> + void (*alert)(struct i2c_client *, enum i2c_alert_protocol protocol,
> + unsigned int data);
>
> /* a ioctl like command that can be used to perform specific functions
> * with the device.
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/6] module: preserve Elf information for livepatch modules
For livepatch modules, copy Elf section, symbol, and string information
from the load_info struct in the module loader. Persist copies of the
original symbol table and string table.
Livepatch manages its own relocation sections in order to reuse module
loader code to write relocations. Livepatch modules must preserve Elf
information such as section indices in order to apply livepatch relocation
sections using the module loader's apply_relocate_add() function.
In order to apply livepatch relocation sections, livepatch modules must
keep a complete copy of their original symbol table in memory. Normally, a
stripped down copy of a module's symbol table (containing only "core"
symbols) is made available through module->core_symtab. But for livepatch
modules, the symbol table copied into memory on module load must be exactly
the same as the symbol table produced when the patch module was compiled.
This is because the relocations in each livepatch relocation section refer
to their respective symbols with their symbol indices, and the original
symbol indices (and thus the symtab ordering) must be preserved in order
for apply_relocate_add() to find the right symbol.
Signed-off-by: Jessica Yu
---
include/linux/module.h | 25 ++
kernel/module.c| 123 -
2 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2bb0c30..3daf2b3 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -330,6 +330,15 @@ struct mod_kallsyms {
char *strtab;
};
+#ifdef CONFIG_LIVEPATCH
+struct klp_modinfo {
+ Elf_Ehdr hdr;
+ Elf_Shdr *sechdrs;
+ char *secstrings;
+ unsigned int symndx;
+};
+#endif
+
struct module {
enum module_state state;
@@ -456,7 +465,11 @@ struct module {
#endif
#ifdef CONFIG_LIVEPATCH
+ bool klp; /* Is this a livepatch module? */
bool klp_alive;
+
+ /* Elf information */
+ struct klp_modinfo *klp_info;
#endif
#ifdef CONFIG_MODULE_UNLOAD
@@ -630,6 +643,18 @@ static inline bool module_requested_async_probing(struct
module *module)
return module && module->async_probe_requested;
}
+#ifdef CONFIG_LIVEPATCH
+static inline bool is_livepatch_module(struct module *mod)
+{
+ return mod->klp;
+}
+#else /* !CONFIG_LIVEPATCH */
+static inline bool is_livepatch_module(struct module *mod)
+{
+ return false;
+}
+#endif /* CONFIG_LIVEPATCH */
+
#else /* !CONFIG_MODULES... */
/* Given an address, look for it in the exception tables. */
diff --git a/kernel/module.c b/kernel/module.c
index 87cfeb2..80b7fd9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1971,6 +1971,82 @@ static void module_enable_nx(const struct module *mod) {
}
static void module_disable_nx(const struct module *mod) { }
#endif
+#ifdef CONFIG_LIVEPATCH
+/*
+ * Persist Elf information about a module. Copy the Elf header,
+ * section header table, section string table, and symtab section
+ * index from info to mod->klp_info.
+ */
+static int copy_module_elf(struct module *mod, struct load_info *info)
+{
+ unsigned int size, symndx;
+ int ret;
+
+ size = sizeof(*mod->klp_info);
+ mod->klp_info = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info == NULL)
+ return -ENOMEM;
+
+ /* Elf header */
+ size = sizeof(Elf_Ehdr);
+ memcpy(&mod->klp_info->hdr, info->hdr, size);
+
+ /* Elf section header table */
+ size = sizeof(Elf_Shdr) * info->hdr->e_shnum;
+ mod->klp_info->sechdrs = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info->sechdrs == NULL) {
+ ret = -ENOMEM;
+ goto free_info;
+ }
+ memcpy(mod->klp_info->sechdrs, info->sechdrs, size);
+
+ /* Elf section name string table */
+ size = info->sechdrs[info->hdr->e_shstrndx].sh_size;
+ mod->klp_info->secstrings = kmalloc(size, GFP_KERNEL);
+ if (mod->klp_info->secstrings == NULL) {
+ ret = -ENOMEM;
+ goto free_sechdrs;
+ }
+ memcpy(mod->klp_info->secstrings, info->secstrings, size);
+
+ /* Elf symbol section index */
+ symndx = info->index.sym;
+ mod->klp_info->symndx = symndx;
+
+ /*
+* For livepatch modules, core_symtab is a complete copy
+* of the original symbol table. Adjust sh_addr to point
+* to core_symtab since the copy of the symtab in module
+* init memory is freed at the end of do_init_module().
+*/
+ mod->klp_info->sechdrs[symndx].sh_addr = (unsigned long)
mod->core_kallsyms.symtab;
+
+ return 0;
+
+free_sechdrs:
+ kfree(mod->klp_info->sechdrs);
+free_info:
+ kfree(mod->klp_info);
+ return ret;
+}
+
+static void free_module_elf(struct module *mod)
+{
+ kfree(mod->klp_info->sechdrs);
+ kfree(mod->klp_info->secstrings);
+ kfree(mod->klp_info);
+}
+#else /* !CONFIG_LIVEPA
[PATCH v6 3/4] i2c: i801: add support of Host Notify
The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
in
http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf
Enable the functionality unconditionally and propagate the alert
on each notification.
With a T440s and a Synaptics touchpad that implements Host Notify, the
payload data is always 0x, so I am not sure if the device actually
sends the payload or if there is a problem regarding the implementation.
Signed-off-by: Benjamin Tissoires
---
changes in v2:
- removed the description of the Slave functionality support in the chip table
(the table shows what is supported, not what the hardware is capable of)
- use i2c-smbus to forward the notification
- remove the fifo, and directly retrieve the address and payload in the worker
- do not check for Host Notification is the feature is not enabled
- use inw_p() to read the payload instead of 2 inb_p() calls
- add /* fall-through */ comment
- unconditionally enable Host Notify if the hardware supports it (can be
disabled by the user)
no changes in v3
changes in v4:
- make use of the new API -> no more worker spawning here
- solved a race between the access of the Host Notify registers and the actual
I2C transfers.
changes in v5:
- added SKL Host Notify support
changes in v6:
- select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
is set to 'Y' while I2C_SMBUS is set to 'M'
drivers/i2c/busses/Kconfig| 1 +
drivers/i2c/busses/i2c-i801.c | 85 +--
2 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index faa8e68..8c8fa12 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -91,6 +91,7 @@ config I2C_I801
tristate "Intel 82801 (ICH/PCH)"
depends on PCI
select CHECK_SIGNATURE if X86 && DMI
+ select I2C_SMBUS
help
If you say yes to this option, support will be included for the Intel
801 family of mainboard I2C interfaces. Specifically, the following
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 585a3b7..b244aa40 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -72,6 +72,7 @@
* Block process call transaction no
* I2C block read transaction yes (doesn't use the block buffer)
* Slave mode no
+ * SMBus Host Notify yes
* Interrupt processingyes
*
* See the file Documentation/i2c/busses/i2c-i801 for details.
@@ -86,6 +87,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +114,10 @@
#define SMBPEC(p) (8 + (p)->smba) /* ICH3 and later */
#define SMBAUXSTS(p) (12 + (p)->smba)/* ICH4 and later */
#define SMBAUXCTL(p) (13 + (p)->smba)/* ICH4 and later */
+#define SMBSLVSTS(p) (16 + (p)->smba)/* ICH3 and later */
+#define SMBSLVCMD(p) (17 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDADD(p) (20 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDDAT(p) (22 + (p)->smba)/* ICH3 and later */
/* PCI Address Constants */
#define SMBBAR 4
@@ -176,6 +182,12 @@
#define SMBHSTSTS_INTR 0x02
#define SMBHSTSTS_HOST_BUSY0x01
+/* Host Notify Status registers bits */
+#define SMBSLVSTS_HST_NTFY_STS 1
+
+/* Host Notify Command registers bits */
+#define SMBSLVCMD_HST_NTFY_INTREN 0x01
+
#define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
SMBHSTSTS_DEV_ERR)
@@ -244,13 +256,18 @@ struct i801_priv {
struct platform_device *mux_pdev;
#endif
struct platform_device *tco_pdev;
+
+ struct smbus_host_notify *host_notify;
};
+#define SMBHSTNTFY_SIZE8
+
#define FEATURE_SMBUS_PEC (1 << 0)
#define FEATURE_BLOCK_BUFFER (1 << 1)
#define FEATURE_BLOCK_PROC (1 << 2)
#define FEATURE_I2C_BLOCK_READ (1 << 3)
#define FEATURE_IRQ(1 << 4)
+#define FEATURE_HOST_NOTIFY(1 << 5)
/* Not really a feature, but it's convenient to handle it as such */
#define FEATURE_IDF(1 << 15)
#define FEATURE_TCO(1 << 16)
@@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
"Block process call",
"I2C block read",
"Interrupt",
+ "SMBus Host Notify",
};
static unsigned int disable_features;
@@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, "Disable selected driver
features:\n"
"\t\t 0x01 disable SMBus PEC\n"
"\t\t 0x02 disable the block buffer\n"
"\t\t 0x08 disable the I2C block read functionality\n"
- "\t\t 0x10 don't use interrupts ");
+ "\t\t 0x10 don't use interrupts\n"
+ "\t\t 0x20 disable SMBus Host Notify ");
/* Make sure the SMBus host is ready to start transmitting.
Return 0 if
Re: [PATCH 3/9] serial: doc: Document .throttle()
On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > Documentation/serial/driver | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/serial/driver b/Documentation/serial/driver > index 61d520dea4c6e13a..50f3d94ed50b341e 100644 > --- a/Documentation/serial/driver > +++ b/Documentation/serial/driver > @@ -126,6 +126,13 @@ hardware. > Interrupts: locally disabled. > This call must not sleep > > + throttle(port) > + Notify the serial driver that input buffers for the line discipline are > + close to full, and it should somehow signal that no more characters > + should be sent to the serial port. > + > + Locking: none. While it's true that no _serial_ locking is performed, the tty core serializes throttle() and unthrottle(), and further guarantees termios values will not be modified concurrently with throttle()/unthrottle(). > + >send_xchar(port,ch) > Transmit a high priority character, even if the port is stopped. > This is used to implement XON/XOFF flow control and tcflow(). If > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller
Hi Tejun, On Thu, Mar 17, 2016 at 2:10 AM, Tejun Heo wrote: > >> If this is ok. I will keep the code as it is, because it uses common >> helper functions for max and current files. > > Hmmm... can you please try to refactor the common part to helpers? > It's not a big thing but there were both styles across different > controllers and helper based ones tend to be easier to follow. > in this v9 patch, To read max and current value, entry point is common function rdmacg_resource_read(). This is due to the fact that reading max and current needs to do same thing. Exceptions are taken care in below helper functions. It uses two small helper functions 1. get_cg_rpool_values 2. print_rpool_values Can I continue with this approach? > I see, but if that's the case, please drop the fine locking. The fine > locking doesn't make much sense - as implemented it's slower and the > whole thing is not hot. o.k. Also can you please confirm that once patch looks good to you, you are ok to merge this patch from Doug's linux-rdma tree as merge is clean from that tree? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 7/7] powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge
On Mon, 7 Mar 2016 15:48:38 +0800
Yongji Xie wrote:
> This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
> we can mmap MSI-X table in vfio driver.
>
> Signed-off-by: Yongji Xie
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index f90dc04..f01b9ab 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1955,6 +1955,20 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
> .free = pnv_ioda2_table_free,
> };
>
> +static bool pnv_ioda_iommu_capable(enum iommu_cap cap)
> +{
> + switch (cap) {
> + case IOMMU_CAP_INTR_REMAP:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static struct iommu_ops pnv_ioda_iommu_ops = {
> + .capable = pnv_ioda_iommu_capable,
> +};
> +
> static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
> struct pnv_ioda_pe *pe, unsigned int base,
> unsigned int segs)
> @@ -3078,6 +3092,9 @@ static void pnv_pci_ioda_fixup(void)
>
> /* Link NPU IODA tables to their PCI devices. */
> pnv_npu_ioda_fixup();
> +
> + /* Add IOMMU_CAP_INTR_REMAP */
> + bus_set_iommu(&pci_bus_type, &pnv_ioda_iommu_ops);
> }
>
> /*
Doesn't this set you up for a world of hurt? bus_set_iommu() calls
iommu_bus_init() which sets up notifiers, which maybe you don't care
about, but it also means that iommu_domain_alloc(&pci_bus_type) will
segfault because you're not providing a domain_alloc callback here.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v15 1/3] drm: rockchip: Add basic drm driver
On 15 March 2016 at 02:30, Mark yao wrote:
> On 2016年03月14日 21:35, Tomeu Vizoso wrote:
>>
>> On 2 December 2014 at 10:15, Mark Yao wrote:
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> new file mode 100644
>>> index 000..e7ca25b
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -0,0 +1,1455 @@
>>
>> ...
>>>
>>> +static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>>> + const struct drm_display_mode *mode,
>>> + struct drm_display_mode *adjusted_mode)
>>> +{
>>> + if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
>>> + return false;
>>
>> Hi Mark,
>>
>> what's the rationale for this?
>>
>> Disabling a CRTC as in [0] will cause mode_fixup() to be called with
>> an empty mode, failing that test.
>>
>> Removing the check seems to get things working fine for a short while,
>> but a later modeset invariably gets the VOP to hang (as reported by
>> [1]).
>>
>> Do you know why that check was put in place and what exactly could be
>> causing the hw to hang?
>>
>> [0]
>> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
>>
>> Thanks,
>>
>> Tomeu
>>
> Hi Tomeu
>
> Just thinking that "adjusted_mode->htotal == 0 || adjusted_mode->vtotal ==
> 0" is not a good mode for vop.
Ah, ok. Guess it should be removed then so we don't break userspace?
> And you said VOP hang, only WARN_ON error message? or system hang, die?
Sorry, the symptom was only the warning, I just went a bit too far and
assumed the VOP had stopped working at all.
> I think maybe crtc disable too fast, vblank is off, then no one can feed the
> wait_update_complete.
> Can you test it again with following patch?
Actually, in today's testing I don't see that happening any more,
sorry about that :/
What I have been looking at today is a related issue when running the
kms_flip_event_leak test from intel-gpu-tools. If I remove the check
mentioned above so CRTCs can be disabled with the SetCRTC IOCTL, I see
this page fault the second and subsequent times I run the test.
[ 75.809031] rk_iommu ff930300.iommu: Page fault at 0x0100 of type read
[ 75.809035] rk_iommu ff930300.iommu: iova = 0x0100: dte_index:
0x4 pte_index: 0x0 page_offset: 0x0
[ 75.809040] rk_iommu ff930300.iommu: mmu_dte_addr: 0x2c258000
dte@0x2c258010: 0x2c561001 valid: 1 pte@0x2c561000: 0x2a06 valid:
0 page@0x flags: 0x0
[ 76.951288] rk_iommu ff930300.iommu: Enable stall request timed
out, status: 0x4b
I have written a smaller standalone test that is attached in case you
want to check it out, but I haven't been able to find out why it only
happens when the test is rerun.
Apparently the VOP is still trying to read a BO (0x0100) right
when the kernel frees it, but from what I can see, it should be
scanning another BO at that point.
Do you have any ideas on what could be happening?
Thanks,
Tomeu
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -503,6 +503,8 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
> if (!vop->is_enabled)
> return;
> + vop_crtc_wait_for_update(crtc);
> +
> drm_crtc_vblank_off(crtc);
>
> Thanks.
>
> --
> Ｍark Yao
>
>
#include
#include
#include
#include
#include
#include
#include
#include
#include
__attribute__((format(printf, 1, 2)))
static void kmsg(const char *format, ...)
#define KERN_EMER "<0>"
#define KERN_ALERT "<1>"
#define KERN_CRIT "<2>"
#define KERN_ERR "<3>"
#define KERN_WARNING "<4>"
#define KERN_NOTICE "<5>"
#define KERN_INFO "<6>"
#define KERN_DEBUG "<7>"
{
va_list ap;
FILE *file;
file = fopen("/dev/kmsg", "w");
if (file == NULL)
return;
va_start(ap, format);
fprintf(file, "userspace: ");
vfprintf(file, format, ap);
va_end(ap);
fclose(file);
}
static uint32_t dumb_create(int fd, int width, int height, int bpp)
{
struct drm_mode_create_dumb create = {};
create.width = width;
create.height = height;
create.bpp = bpp;
create.handle = 0;
drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &create);
return create.handle;
}
static uint32_t fb_create(int fd, int width, int height, int format, int bo, int pitch)
{
struct drm_mode_fb_cmd2 f = {};
f.width = width;
f.height = height;
f.pixel_format = format;
f.handles[0] = bo;
f.pitches[0] = pitch;
f.fb_id = 0;
drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f);
return f.fb_id;
}
drmModeModeInfo *connector_get_default_mode(int fd, int conn_id)
{
drmModeConnectorPtr conn;
int i;
conn = drmModeGetConnectorCurrent(fd, conn_id);
for (i = 0; i < conn->count_modes; i++) {
if (conn->modes[i].type & DRM_MODE_TYPE_PREFERRED)
return &conn->modes[i];
}
}
static int dumb_destroy(int fd, uint32_t bo)
{
struct drm_mode_destroy_dumb arg = {};
arg.handl
Re: [PATCH 5/9] serial: doc: Document .set_ldisc()
On 03/14/2016 08:16 AM, Geert Uytterhoeven wrote: Reviewed-by: Peter Hurley > Signed-off-by: Geert Uytterhoeven > --- > Documentation/serial/driver | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/serial/driver b/Documentation/serial/driver > index 3b2a97d5ecc79491..3b08df5bcc17e944 100644 > --- a/Documentation/serial/driver > +++ b/Documentation/serial/driver > @@ -259,6 +259,11 @@ hardware. > Interrupts: caller dependent. > This call must not sleep > > + set_ldisc(port,termios) > + Notifier for discipline change. See Documentation/serial/tty.txt. > + > + Locking: caller holds port->mutex > + >pm(port,state,oldstate) > Perform any power management related activities on the specified > port. State indicates the new state (defined by > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs
On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote: > This patch implements a proxy driver for supporting multiple emulated TPMs > in a system. > > The driver implements a device /dev/vtpmx that is used to created > a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that > is accessed using a file descriptor returned by an ioctl. > The device /dev/tpmX is the usual TPM device created by the core TPM > driver. Applications or kernel subsystems can send TPM commands to it > and the corresponding server-side file descriptor receives these > commands and delivers them to an emulated TPM. > > Signed-off-by: Stefan Berger > CC: linux-ker...@vger.kernel.org > CC: linux-doc@vger.kernel.org > CC: linux-...@vger.kernel.org Alternative to this would be to have /dev/vtpmx create: * /dev/vtpm0 for the server * /dev/tpm0 for the client This is how David Howell's PoC worked and that's why I want to make this alternative visible. The server could even respawn without container noticing it. This solution have better availability properties. /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: mmc: Add the introduction for mmc-utils
This patch introduces one mmc test tool called mmc-utils, which is convenient if someone want to exercise and test MMC/SD devices from userspace. Signed-off-by: Baolin Wang --- Documentation/mmc/00-INDEX |2 ++ Documentation/mmc/mmc-tools.txt | 34 ++ 2 files changed, 36 insertions(+) create mode 100644 Documentation/mmc/mmc-tools.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index a9ba672..4623bc0 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -6,3 +6,5 @@ mmc-dev-parts.txt - info on SD and MMC device partitions mmc-async-req.txt - info on mmc asynchronous requests +mmc-tools.txt + - info on mmc-utils tools diff --git a/Documentation/mmc/mmc-tools.txt b/Documentation/mmc/mmc-tools.txt new file mode 100644 index 000..499b0f4 --- /dev/null +++ b/Documentation/mmc/mmc-tools.txt @@ -0,0 +1,34 @@ +MMC tools introduction +== + +There is one mmc test tools called mmc-utils, which is maintained by Chris Ball, +you can find it at the below public git repository: +http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + +Functions += + +The mmc-utils tools can do the following: + - Print and parse extcsd data. + - Determine the eMMC writeprotect status. + - Set the eMMC writeprotect status. + - Set the eMMC data sector size to 4KB by disabling emulation. + - Create general purpose partition. + - Enable the enhanced user area. + - Enable write reliability per partition. + - Print the response to STATUS_SEND (CMD13). + - Enable the boot partition. + - Set Boot Bus Conditions. + - Enable the eMMC BKOPS feature. + - Permanently enable the eMMC H/W Reset feature. + - Permanently disable the eMMC H/W Reset feature. + - Send Sanitize command. + - Program authentication key for the device. + - Counter value for the rpmb device will be read to stdout. + - Read from rpmb device to output. + - Write to rpmb device from data file. + - Enable the eMMC cache feature. + - Disable the eMMC cache feature. + - Print and parse CID data. + - Print and parse CSD data. + - Print and parse SCR data. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
