Re: [PATCH V2 5/6] thermal: max77620: Add thermal driver for reporting junction temp
On Thursday 10 March 2016 12:57 AM, Eduardo Valentin wrote: * PGP Signed by an unknown key On Wed, Mar 09, 2016 at 06:40:09PM +0530, Laxman Dewangan wrote: Maxim Semiconductor Max77620 supports alarm interrupts when its die temperature crosses 120C and 140C. These threshold temperatures are not configurable. Add thermal driver to register PMIC die temperature as thermal zone sensor and capture the die temperature warning interrupts to notifying the client. Signed-off-by: Laxman Dewangan --- Changes from V1: - checkpatch warning fix and simplifying the dev.of_node initialisation. drivers/thermal/Kconfig| 10 +++ drivers/thermal/Makefile | 1 + drivers/thermal/thermal-max77620.c | 151 + 3 files changed, 162 insertions(+) create mode 100644 drivers/thermal/thermal-max77620.c diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 5e7c97a..fc856eb 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -194,6 +194,16 @@ config IMX_THERMAL cpufreq is used as the cooling device to throttle CPUs when the passive trip is crossed. +config MAX77620_THERMAL + tristate "Temperature sensor driver for Maxim MAX77620 PMIC" + depends on MFD_MAX77620 + depends on OF The previous question on compile test was more if we could add depends on COMPILE_TEST flag. Sorry if I was not clear enough. I am adding the flag here: config MAX77620_THERMAL tristate "Temperature sensor driver for Maxim MAX77620 PMIC" - depends on MFD_MAX77620 + depends on MFD_MAX77620 || COMPILE_TEST + depends on HAS_IOMEM depends on OF help Support for die junction temperature warning alarm for Maxim but I still cannot compile test the file because of the missing header. drivers/thermal/thermal-max77620.c:16:32: fatal error: linux/mfd/max77620.h: No such file or directory #include I wont be able to merge this as it is. We need to sort out the dependency first. I will update you once the mfd patches will merge as this header is on that patch. -- 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 V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620
On Thursday 10 March 2016 01:02 AM, Eduardo Valentin wrote:
* PGP Signed by an unknown key
On Wed, Mar 09, 2016 at 06:40:04PM +0530, Laxman Dewangan wrote:
The series add the devm_ version of thermal_zone_of_sensor_register/
unregister, interface details, and use this in new thermal driver
for max77620.
The header file for max77620 is part of MFD patch
https://lkml.org/lkml/2016/2/11/186
Changes from V1:
- Run checkpatch with --strict and fix all warnings.
- Added details of interfaces in spifs-api.txt
- Added DT binding doc.
Laxman Dewangan (6):
thermal: doc: Add details of
thermal_zone_of_sensor_{register,unregister}
thermal: of-thermal: Add devm version of
thermal_zone_of_sensor_register
thermal: Add devm_thermal_zone_of_sensor_register() in managed devices
list
thermal: doc: Add details of
devm_thermal_zone_of_sensor_{register,unregister}
thermal: max77620: Add thermal driver for reporting junction temp
thermal: Add DT binding doc for thermal of PMIC max77620
Add patches 1-3 in my tree. Patch 4 should probably go via documentation
tree. And patch 5 needs dependency to be sorted, and 6 need minor changes.
Thanks for accepting patches.
patch 5 needs mfd patches which is under review. So until that is
merged, compilation will fail due to header dependency.
Will add complete information on example of patch 6.
--
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 1/7] PCI: Add a new option for resource_alignment to reassign alignment
On 2016/3/10 10:19, Alexey Kardashevskiy wrote:
On 03/07/2016 06:48 PM, Yongji Xie wrote:
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers.
How can this possibly break any driver?... It rounds up, not down,
what do I miss here?
If the driver uses the size to locate some register, e.g. the length of
register is related to the size, or get some other information of the
device. The wrong size may break this driver.
So I think it's better not to touch the size here. The resource_size()
should be the real size.
So this patch adds a new option "noresize" for the parameter
to solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 36
+--
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a53c92..d8b29ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2912,13 +2912,16 @@ bytes respectively. Such letter suffixes can
also be entirely omitted.
window. The default value is 64 megabytes.
resource_alignment=
Format:
-[@][:]:.[;
...]
+[@][:]:.
+[:noresize][; ...]
Specifies alignment and device to reassign
aligned memory resources.
If is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+noresize: Don't change the resources' sizes when
+reassigning alignment.
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/pci.c b/drivers/pci/pci.c
index 602eb42..760cce5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4598,7 +4598,8 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
* RETURNS: Resource alignment if it is specified.
* Zero if it is not specified.
*/
-static resource_size_t pci_specified_resource_alignment(struct
pci_dev *dev)
+static resource_size_t pci_specified_resource_alignment(struct
pci_dev *dev,
+bool *resize)
{
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
@@ -4626,6 +4627,11 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev)
}
}
p += count;
+if (!strncmp(p, ":noresize", 9)) {
+*resize = false;
+p += 9;
+} else
+*resize = true;
if (seg == pci_domain_nr(dev->bus) &&
bus == dev->bus->number &&
slot == PCI_SLOT(dev->devfn) &&
@@ -4658,11 +4664,12 @@ void
pci_reassigndev_resource_alignment(struct pci_dev *dev)
{
int i;
struct resource *r;
+bool resize;
resource_size_t align, size;
u16 command;
/* check if specified PCI is target device to reassign */
-align = pci_specified_resource_alignment(dev);
+align = pci_specified_resource_alignment(dev, &resize);
A compiler should have warned here about passing a pointer to
unitialized @resize.
OK. I'll fix it.
Thanks,
Yongji Xie
if (!align)
return;
@@ -4684,15 +4691,24 @@ void
pci_reassigndev_resource_alignment(struct pci_dev *dev)
if (!(r->flags & IORESOURCE_MEM))
continue;
size = resource_size(r);
-if (size < align) {
-size = align;
-dev_info(&dev->dev,
-"Rounding up size of resource #%d to %#llx.\n",
-i, (unsigned long long)size);
+if (resize) {
+if (size < align) {
+size = align;
+dev_info(&dev->dev,
+"Rounding up size of resource #%d to %#llx.\n",
+i, (unsigned long long)size);
+}
+r->flags |= IORESOURCE_UNSET;
+r->end = size - 1;
+r->start = 0;
+} else {
+if (size > align)
+align = size;
+r->flags &= ~IORESOURCE_SIZEALIGN;
+r->flags |= IORESOURCE_STARTALIGN | IORESOURCE_UNSET;
+r->start = align;
+r->end = r->start + size - 1;
}
-r->flags |= IORESOURCE_UNSET;
-r->end = size - 1;
-r->start = 0;
}
/* Need to disable bridge's resource window,
* to enable the kernel to reassign new resource
--
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.ke
RE: [PATCH] modsign: Fix documentation on module signing enforcement parameter.
> > > Modify the documentation to match the actual parameter as implemented > > > in kernel/module.c:273. > > > > So I was going to apply this to the docs tree, but it's been white-space > > mangled. Care to fix your mail client and resend? > > > > Thanks, > > > > jon > > Sorry about that. I assume you are talking about the wrapping my client did > at 76 characters. Let's try this again... > > It's also available at https://github.com/JohnstonJ/linux.git in the > fix-modsign-enforcement-doc branch. My mail client is determined to embarrass me. :( Trying again... James >From 033be2a07878841081a30408aecce3a6b6c8f677 Mon Sep 17 00:00:00 2001 From: James Johnston Date: Sun, 6 Mar 2016 19:54:38 -0500 Subject: [PATCH] modsign: Fix documentation on module signing enforcement parameter. Modify the documentation to match the actual parameter as implemented in kernel/module.c:273. Signed-off-by: James Johnston --- Documentation/module-signing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index a78bf1f..696d5ca 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -254,7 +254,7 @@ signature checking is all done within the kernel. NON-VALID SIGNATURES AND UNSIGNED MODULES = -If CONFIG_MODULE_SIG_FORCE is enabled or enforcemodulesig=1 is supplied on +If CONFIG_MODULE_SIG_FORCE is enabled or module.sig_enforce=1 is supplied on the kernel command line, the kernel will only load validly signed modules for which it has a public key. Otherwise, it will also load modules that are unsigned. Any module for which the kernel has a key, but which proves to have -- 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] modsign: Fix documentation on module signing enforcement parameter.
> > Modify the documentation to match the actual parameter as implemented > > in kernel/module.c:273. > > So I was going to apply this to the docs tree, but it's been white-space > mangled. Care to fix your mail client and resend? > > Thanks, > > jon Sorry about that. I assume you are talking about the wrapping my client did at 76 characters. Let's try this again... It's also available at https://github.com/JohnstonJ/linux.git in the fix-modsign-enforcement-doc branch. >From 033be2a07878841081a30408aecce3a6b6c8f677 Mon Sep 17 00:00:00 2001 From: James Johnston Date: Sun, 6 Mar 2016 19:54:38 -0500 Subject: [PATCH] modsign: Fix documentation on module signing enforcement parameter. Modify the documentation to match the actual parameter as implemented in kernel/module.c:273. Signed-off-by: James Johnston --- Documentation/module-signing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index a78bf1f..696d5ca 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -254,7 +254,7 @@ signature checking is all done within the kernel. NON-VALID SIGNATURES AND UNSIGNED MODULES = -If CONFIG_MODULE_SIG_FORCE is enabled or enforcemodulesig=1 is supplied on +If CONFIG_MODULE_SIG_FORCE is enabled or module.sig_enforce=1 is supplied on the kernel command line, the kernel will only load validly signed modules for which it has a public key. Otherwise, it will also load modules that are unsigned. Any module for which the kernel has a key, but which proves to have -- 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 v6 08/11] tpm: Driver for supporting multiple emulated TPMs
On Wed, Mar 9, 2016 at 6:34 PM, Stefan Berger wrote: > On 03/09/2016 01:01 PM, Andy Lutomirski wrote: >> >> On Wed, Mar 9, 2016 at 9:39 AM, Stefan Berger >> wrote: >>> >>> This patch implements a 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. >> >> Nifty! >> >> Is anyone considering writing a modification or replacement of >> trousers that creates claims the real tpm and exposes a vtpm that >> handles multiplexing internally? Does the vtpm driver intelligently >> support multiple simultaneous clients? > > > The vtpm driver allows to use an independent trousers instance in each > container. > > Using the VTPM_NEW_DEV ioctl the container mgmt. stack can create a > /dev/tpmX (X=0,1,2,...) device and a file descriptor. The file descriptor is > passed to a vTPM instance, the /dev/tpmX is moved into the container, > meaning a device with the same major/minor numbers is created in the > container. This then allows each container to talk to an independent vTPM. > The vTPM can either be 1.2 or 2. What I meant was: If two clients connect to the same vTPM slave node, can the master program tell requests from the two clients apart? If so, great! If not, then I'd consider that to be somewhat sad. --Andy -- 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 08/11] tpm: Driver for supporting multiple emulated TPMs
On 03/09/2016 01:01 PM, Andy Lutomirski wrote: On Wed, Mar 9, 2016 at 9:39 AM, Stefan Berger wrote: This patch implements a 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. Nifty! Is anyone considering writing a modification or replacement of trousers that creates claims the real tpm and exposes a vtpm that handles multiplexing internally? Does the vtpm driver intelligently support multiple simultaneous clients? The vtpm driver allows to use an independent trousers instance in each container. Using the VTPM_NEW_DEV ioctl the container mgmt. stack can create a /dev/tpmX (X=0,1,2,...) device and a file descriptor. The file descriptor is passed to a vTPM instance, the /dev/tpmX is moved into the container, meaning a device with the same major/minor numbers is created in the container. This then allows each container to talk to an independent vTPM. The vTPM can either be 1.2 or 2. Stefan --Andy -- 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 -- 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 1/7] PCI: Add a new option for resource_alignment to reassign alignment
On 03/07/2016 06:48 PM, Yongji Xie wrote:
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers.
How can this possibly break any driver?... It rounds up, not down, what do
I miss here?
So this patch adds a new option "noresize" for the parameter
to solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 36 +--
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a53c92..d8b29ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2912,13 +2912,16 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
window. The default value is 64 megabytes.
resource_alignment=
Format:
- [@][:]:.[; ...]
+ [@][:]:.
+ [:noresize][; ...]
Specifies alignment and device to reassign
aligned memory resources.
If is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+ noresize: Don't change the resources' sizes when
+ reassigning alignment.
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/pci.c b/drivers/pci/pci.c
index 602eb42..760cce5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4598,7 +4598,8 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
* RETURNS: Resource alignment if it is specified.
* Zero if it is not specified.
*/
-static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
+static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
+ bool *resize)
{
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
@@ -4626,6 +4627,11 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev)
}
}
p += count;
+ if (!strncmp(p, ":noresize", 9)) {
+ *resize = false;
+ p += 9;
+ } else
+ *resize = true;
if (seg == pci_domain_nr(dev->bus) &&
bus == dev->bus->number &&
slot == PCI_SLOT(dev->devfn) &&
@@ -4658,11 +4664,12 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
{
int i;
struct resource *r;
+ bool resize;
resource_size_t align, size;
u16 command;
/* check if specified PCI is target device to reassign */
- align = pci_specified_resource_alignment(dev);
+ align = pci_specified_resource_alignment(dev, &resize);
A compiler should have warned here about passing a pointer to unitialized
@resize.
if (!align)
return;
@@ -4684,15 +4691,24 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
if (!(r->flags & IORESOURCE_MEM))
continue;
size = resource_size(r);
- if (size < align) {
- size = align;
- dev_info(&dev->dev,
- "Rounding up size of resource #%d to %#llx.\n",
- i, (unsigned long long)size);
+ if (resize) {
+ if (size < align) {
+ size = align;
+ dev_info(&dev->dev,
+ "Rounding up size of resource #%d to
%#llx.\n",
+ i, (unsigned long long)size);
+ }
+ r->flags |= IORESOURCE_UNSET;
+ r->end = size - 1;
+ r->start = 0;
+ } else {
+ if (size > align)
+ align = size;
+ r->flags &= ~IORESOURCE_SIZEALIGN;
+ r->flags |= IORESOURCE_STARTALIGN | IORESOURCE_UNSET;
+ r->start = align;
+ r->end = r->start + size - 1;
}
- r->flags |= IORESOURCE_UNSET;
- r->end = size - 1;
- r->start
Re: [PATCH 0/5] Add Korean translation of memory-barriers.txt
On Thu, Mar 10, 2016 at 09:48:54AM +0900, SeongJae Park wrote:
> This patchset aims to add Korean translation of memory-barriers document.
>
> The patchset starts from fixing minor and trivial problems in the original
> document that found during translation. After that, the final patch adds the
> Korean translation of the document.
>
> The patches are based on recent next tree:
> 0f6dd067b9c3c712b1177fa2fc0deb21805c771c ("Add linux-next specific files for
> 20160309")
I have queued this series for review, thank you!
Of course, I cannot do anything to the Korean translation other than to
pass it through unchanged. ;-)
Thanx, Paul
> SeongJae Park (5):
> doc/memory-barriers: fix missed renaming: s/lock/acquire
> doc/memory-barriers: add missed subsection in TOC
> doc/memory-barriers: fix typo
> doc/memory-barriers: Insert white spaces consistently
> Doc/memory-barriers: add Korean translation
>
> Documentation/ko_KR/memory-barriers.txt | 3048
> +++
> Documentation/memory-barriers.txt | 62 +-
> 2 files changed, 3081 insertions(+), 29 deletions(-)
> create mode 100644 Documentation/ko_KR/memory-barriers.txt
>
> --
> 1.9.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 4/5] doc/memory-barriers: Insert white spaces consistently
The document uses two newlines between sections, one newline between item and its detailed description, and two spaces between sentences. However, there is few point that missed the rule. This commit fix them to use the rule consistently. Signed-off-by: SeongJae Park --- Documentation/memory-barriers.txt | 43 +-- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 89f96af..19612b7 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1732,15 +1732,15 @@ The Linux kernel has eight basic CPU memory barriers: All memory barriers except the data dependency barriers imply a compiler -barrier. Data dependencies do not impose any additional compiler ordering. +barrier. Data dependencies do not impose any additional compiler ordering. Aside: In the case of data dependencies, the compiler would be expected to issue the loads in the correct order (eg. `a[b]` would have to load the value of b before loading a[b]), however there is no guarantee in the C specification that the compiler may not speculate the value of b (eg. is equal to 1) and load a before b (eg. tmp = a[1]; if (b != 1) -tmp = a[b]; ). There is also the problem of a compiler reloading b after -having loaded a[b], thus having a newer copy of b than a[b]. A consensus +tmp = a[b]; ). There is also the problem of a compiler reloading b after +having loaded a[b], thus having a newer copy of b than a[b]. A consensus has not yet been reached about these problems, however the READ_ONCE() macro is a good place to start looking. @@ -1795,6 +1795,7 @@ There are some more advanced barrier functions: (*) lockless_dereference(); + This can be thought of as a pointer-fetch wrapper around the smp_read_barrier_depends() data-dependency barrier. @@ -1896,7 +1897,7 @@ for each construct. These operations all imply certain barriers: Memory operations issued before the ACQUIRE may be completed after the ACQUIRE operation has completed. An smp_mb__before_spinlock(), combined with a following ACQUIRE, orders prior stores against - subsequent loads and stores. Note that this is weaker than smp_mb()! + subsequent loads and stores. Note that this is weaker than smp_mb()! The smp_mb__before_spinlock() primitive is free on many architectures. (2) RELEASE operation implication: @@ -2091,9 +2092,9 @@ or: event_indicated = 1; wake_up_process(event_daemon); -A write memory barrier is implied by wake_up() and co. if and only if they wake -something up. The barrier occurs before the task state is cleared, and so sits -between the STORE to indicate the event and the STORE to set TASK_RUNNING: +A write memory barrier is implied by wake_up() and co. if and only if they +wake something up. The barrier occurs before the task state is cleared, and so +sits between the STORE to indicate the event and the STORE to set TASK_RUNNING: CPU 1 CPU 2 === === @@ -2207,7 +2208,7 @@ three CPUs; then should the following sequence of events occur: Then there is no guarantee as to what order CPU 3 will see the accesses to *A through *H occur in, other than the constraints imposed by the separate locks -on the separate CPUs. It might, for example, see: +on the separate CPUs. It might, for example, see: *E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M @@ -2487,9 +2488,9 @@ The following operations are special locking primitives: clear_bit_unlock(); __clear_bit_unlock(); -These implement ACQUIRE-class and RELEASE-class operations. These should be used in -preference to other operations when implementing locking primitives, because -their implementations can be optimised on many architectures. +These implement ACQUIRE-class and RELEASE-class operations. These should be +used in preference to other operations when implementing locking primitives, +because their implementations can be optimised on many architectures. [!] Note that special memory barrier primitives are available for these situations because on some CPUs the atomic instructions used imply full memory @@ -2569,12 +2570,12 @@ explicit barriers are used. Normally this won't be a problem because the I/O accesses done inside such sections will include synchronous load operations on strictly ordered I/O -registers that form implicit I/O barriers. If this isn't sufficient then an +registers that form implicit I/O barriers. If this isn't sufficient then an mmiowb() may need to be used explicitly. A similar situation may occur between an interrupt routine and two routines -running on separate CPUs that communicate with each other. If such a case is +running on separate CPUs that communicate with each other. If such a
[PATCH 2/5] doc/memory-barriers: add missed subsection in TOC
Virtual Machine Guests subsection has added with commit
6a65d26385bf487926a0616650927303058551e3 ("asm-generic: implement
virt_xxx memory barriers") in memory-barriers.txt but it forgot to add
the subsection in 'table of contents'. This commit adds the subsection
in the 'table of contents'.
Signed-off-by: SeongJae Park
---
Documentation/memory-barriers.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 6b453f9..0560a49 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -61,6 +61,7 @@ Contents:
(*) The things CPUs get up to.
- And then there's the Alpha.
+ - Virtual Machine Guests.
(*) Example uses.
--
1.9.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] doc/memory-barriers: fix typo
Signed-off-by: SeongJae Park
---
Documentation/memory-barriers.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 0560a49..89f96af 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -149,7 +149,7 @@ As a further example, consider this sequence of events:
CPU 1 CPU 2
=== ===
- { A == 1, B == 2, C = 3, P == &A, Q == &C }
+ { A == 1, B == 2, C == 3, P == &A, Q == &C }
B = 4; Q = P;
P = &B D = *Q;
@@ -518,7 +518,7 @@ following sequence of events:
CPU 1 CPU 2
=== ===
- { A == 1, B == 2, C = 3, P == &A, Q == &C }
+ { A == 1, B == 2, C == 3, P == &A, Q == &C }
B = 4;
WRITE_ONCE(P, &B)
@@ -545,7 +545,7 @@ between the address load and the data load:
CPU 1 CPU 2
=== ===
- { A == 1, B == 2, C = 3, P == &A, Q == &C }
+ { A == 1, B == 2, C == 3, P == &A, Q == &C }
B = 4;
WRITE_ONCE(P, &B);
@@ -3042,7 +3042,7 @@ The Alpha defines the Linux kernel's memory barrier model.
See the subsection on "Cache Coherency" above.
VIRTUAL MACHINE GUESTS
+--
Guests running within virtual machines might be affected by SMP effects even if
the guest itself is compiled without SMP support. This is an artifact of
--
1.9.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] doc/memory-barriers: fix missed renaming: s/lock/acquire
Terms `lock` and `unlock` have changed to `acquire` / `release` by
commit 2e4f5382d12a441b5cccfdde00308df15c2ce300 ("locking/doc: Rename
LOCK/UNLOCK to ACQUIRE/RELEASE"). However, the commit missed to change
the table of content. This commit changes the missed parts.
Signed-off-by: SeongJae Park
---
Documentation/memory-barriers.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 3729cbe..6b453f9 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -31,15 +31,15 @@ Contents:
(*) Implicit kernel memory barriers.
- - Locking functions.
+ - Acquiring functions.
- Interrupt disabling functions.
- Sleep and wake-up functions.
- Miscellaneous functions.
- (*) Inter-CPU locking barrier effects.
+ (*) Inter-CPU acquiring barrier effects.
- - Locks vs memory accesses.
- - Locks vs I/O accesses.
+ - Acquires vs memory accesses.
+ - Acquires vs I/O accesses.
(*) Where are memory barriers needed?
@@ -1858,7 +1858,7 @@ This is a variation on the mandatory write barrier that
causes writes to weakly
ordered I/O regions to be partially ordered. Its effects may go beyond the
CPU->Hardware interface and actually affect the hardware at some level.
-See the subsection "Locks vs I/O accesses" for more information.
+See the subsection "Acquires vs I/O accesses" for more information.
===
--
1.9.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 0/5] Add Korean translation of memory-barriers.txt
This patchset aims to add Korean translation of memory-barriers document.
The patchset starts from fixing minor and trivial problems in the original
document that found during translation. After that, the final patch adds the
Korean translation of the document.
The patches are based on recent next tree:
0f6dd067b9c3c712b1177fa2fc0deb21805c771c ("Add linux-next specific files for
20160309")
SeongJae Park (5):
doc/memory-barriers: fix missed renaming: s/lock/acquire
doc/memory-barriers: add missed subsection in TOC
doc/memory-barriers: fix typo
doc/memory-barriers: Insert white spaces consistently
Doc/memory-barriers: add Korean translation
Documentation/ko_KR/memory-barriers.txt | 3048 +++
Documentation/memory-barriers.txt | 62 +-
2 files changed, 3081 insertions(+), 29 deletions(-)
create mode 100644 Documentation/ko_KR/memory-barriers.txt
--
1.9.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] Doc: nfs: Fix typos in Documentation/filesystems/nfs
On Thu, 18 Feb 2016 12:26:13 +0900 Masanari Iida wrote: > This patch fix spelling typos found in Documentation/filesystems/nfs I've applied this to the docs tree. I fixed the two "reacquire" instances that Randy pointed out; it would have been nice to get an updated patch so I didn't have to do that. Thanks, jon -- 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] Documentation: kselftest: Remove duplicate word
On Wed, 24 Feb 2016 00:08:11 +0800 Zhiyi Sun wrote: > Remove duplicate word "for" in kselftest.txt. Applied to the docs tree, thanks. jon -- 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] doc: fix grammar
On Thu, 25 Feb 2016 11:19:56 + Javi Merino wrote: > Some minor typos: > > - make is unbindable -> make it unbindable > - a underlying -> an underlying > - different version -> different versions Applied to the docs tree, thanks. jon -- 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] Documentation: Howto: Fixed subtitles style
On Mon, 7 Mar 2016 02:36:18 +0100 Philippe Loctaux wrote: > Fixed subtitles style, aligned them with their header. Applied to the docs tree, thanks. jon -- 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] modsign: Fix documentation on module signing enforcement parameter.
On Mon, 7 Mar 2016 01:45:17 - "James Johnston" wrote: > Modify the documentation to match the actual parameter as implemented in > kernel/module.c:273. So I was going to apply this to the docs tree, but it's been white-space mangled. Care to fix your mail client and resend? Thanks, jon -- 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 09:48 schrieb Paul Bolle: > On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote: >> As a consequence, owners of HiSAX type adapters are in fact stuck with >> the old hisax driver if they want to continue using i4l userspace >> tools. > > Do you know whether or not mISDN tools offer functionality comparable to > i4l tools? AFAICS they don't. mISDN seems very much geared towards voice use, for example with Asterisk. The entire topic of ISDN data connections appears to be missing. I don't see how someone currently using i4l for Internet dial-in (either client or server side) could migrate to mISDN. -- 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: Kernel docs: muddying the waters a bit
Em Tue, 8 Mar 2016 12:39:21 -0300 Mauro Carvalho Chehab escreveu: > Pandoc failed to fully convert it, but at least it left all the texts, > with prevented rewriting it from scratch. This is the manual fix > I applied to it: > > https://git.linuxtv.org/mchehab/asciidoc-poc.git/commit/func-ioctl.adoc?id=801d336c3742f26731e08c284290c32c0b4632fc > > FYI, we have 133 xml files at the media uAPI doc with refmeta. I used pandoc to convert from the html files and manually edited it. I also fixed lots of other issues with the conversion. I guess the conversion to asciidoc format is now in good shape, at least to demonstrate that it is possible to use this format for the media docbook. Still, there are lots of broken references. The proof of concept html file is at: https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/media_api.html I also added the ascii doc files there, at: https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/ And I'm keeping the git tree, with helps to identify the work that was needed to make it work: https://git.linuxtv.org/mchehab/asciidoc-poc.git In summary, AsciiDoc, formatted via AsciiDoctor worked fine to produce an html file. PROBLEMS 1) I was not able to produce outputs on any other format. For example, when trying to generate docbook45 output, it sems that part of the trouble was due to pandoc conversion. It produces links like: link:#ftn.id-1.4.11.43.5.11.2.7.2.6.2[^[a]^] Which causes errors with DocBook parsers, like xmllint: media_api.xml:32300: parser error : Opening and ending tag mismatch: superscript line 32300 and ulink [a] ^ I suspect that this is fixable. I may try to fix it later. 2) It seems that Asciidoctor doesn't allow annexes per document part. It numberates them as chapters, instead of using A, B, C, ... 3) Even producing the html without troubles, it produces an error: asciidoctor: ERROR: media_api.adoc: line 57: invalid part, must have at least one section (e.g., chapter, appendix, etc.) 4) There are some things that got lost during the conversion, like copyright notes and revision notes. This could be simply a problem with pandoc conversion. Nothing serious, I guess, as we could insert the lost data manually. Yet, it means that, to move from the PoC to the Kernel, there are still lots of work to do. I was unable do discover why, nor to suppress this error message. Yet, from my side, if we're willing to get rid of DocBook, then Asciidoctor seems to be the *only* alternative so far to parse the complex media documents. Regards, Mauro -- 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 v9 04/13] task_isolation: add initial support
Frederic, Thanks for the detailed feedback on the task isolation stuff. This reply kind of turned into an essay, so I've added a little "TL;DR" sentence before each section. TL;DR: Let's make an explicit decision about whether task isolation should be "persistent" or "one-shot". Both have some advantages. = An important high-level issue is how "sticky" task isolation mode is. We need to choose one of these two options: "Persistent mode": A task switches state to "task isolation" mode (kind of a level-triggered analogy) and stays there indefinitely. It can make a syscall, take a page fault, etc., if it wants to, but the kernel protects it from incurring any further asynchronous interrupts. This is the model I've been advocating for. "One-shot mode": A task requests isolation via prctl(), the kernel ensures it is isolated on return from the prctl(), but then as soon as it enters the kernel again, task isolation is switched off until another prctl is issued. This is what you recommended in your last email. There are a number of pros and cons to the two models. I think on balance I still like the "persistent mode" approach, but here's all the pros/cons I can think of: PRO for persistent mode: A somewhat easier programming model. Users can just imagine "task isolation" as a way for them to still be able to use the kernel exactly as they always have; it's just slower to get back out of the kernel so you use it judiciously. For example, a process is free to call write() on a socket to perform a diagnostic, but when returning from the write() syscall, the kernel will hold the task in kernel mode until any timer ticks (perhaps from networking stuff) are complete, and then let it return to userspace to continue in task isolation mode. This is convenient to the user since they don't have to fret about re-enabling task isolation after that syscall, page fault, or whatever; they can just continue running. With your suggestion, the user pretty much has to leave STRICT mode enabled so he gets notified of any unexpected return to kernel space (in fact we might make it required so you always get a signal when leaving task isolation unless it's via a prctl or exit syscall). PRO for one-shot mode: A somewhat crisper interaction with sched_setaffinity() etc. With a persistent mode approach, a task can start up task isolation, then later another task can be placed on its cpu and break it (it won't return to userspace until killed or the new process affinitizes itself away or stops running). By contrast, in one-shot mode, any return to kernel spaces turns off task isolation anyway, so it's very clear what the interaction looks like. I suspect this is more a theoretical advantage to one-shot mode than a practical one, though. CON for one-shot mode: It's actually hard to catch every kernel entry so we can turn the task-isolation flag off again - and we really do need to have a flag, just so that we can suitably debug any bad actions that bring us into the kernel when we're not expecting it. Right now there are things that bring us into the kernel that we don't bother annotating for task isolation STRICT mode, just because they're visible to the user anyway: e.g., a bus fault or segmentation violation. I think we can actually make both modes available to users with just another flag bit, so maybe we can look at what that looks like in v11: adding a PR_TASK_ISOLATION_ONESHOT flag would turn off task isolation at the next syscall entry, page fault, etc. Then we can think more specifically about whether we want to remove the flag or not, and if we remove it, whether we want to make the code that was controlled by it unconditionally true or unconditionally false (i.e. remove it again). TL;DR: We should be more willing to return -EINVAL from prctl(). = One thing you've argued is that we should be more aggressive about failing the prctl() call. I think, in any case, that this is probably reasonable. We already check that the task's affinity is limited to the current core and that that core is a task_isolation cpu; I think we can also require that can_stop_full_tick() return true (or the moral equivalent given your recent patch series). This will mean you can't even try to go into task isolation mode if another task is schedulable, among other things, which seems like a good thing. However, it is important to note that the current task_isolation_ready and task_isolation_enter calls that are in the prepare_exit_to_userspace routine are still required even with your proposed one-shot mode. We have to be sure that no interrupts occur on the way back to userspace that might then in principle lead to timer interrupts being scheduled, and the way to do that is make sure task_isolation_ready returns true with interrupts disabled, and interrupts are not then re-enabled before return to userspace. Anything else is just keeping your fingers crossed and guessing. TL;DR: Returning -EBUSY from pr
Re: [PATCH V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620
On Wed, Mar 09, 2016 at 06:40:04PM +0530, Laxman Dewangan wrote:
> The series add the devm_ version of thermal_zone_of_sensor_register/
> unregister, interface details, and use this in new thermal driver
> for max77620.
>
> The header file for max77620 is part of MFD patch
> https://lkml.org/lkml/2016/2/11/186
>
> Changes from V1:
> - Run checkpatch with --strict and fix all warnings.
> - Added details of interfaces in spifs-api.txt
> - Added DT binding doc.
>
> Laxman Dewangan (6):
> thermal: doc: Add details of
> thermal_zone_of_sensor_{register,unregister}
> thermal: of-thermal: Add devm version of
> thermal_zone_of_sensor_register
> thermal: Add devm_thermal_zone_of_sensor_register() in managed devices
> list
> thermal: doc: Add details of
> devm_thermal_zone_of_sensor_{register,unregister}
> thermal: max77620: Add thermal driver for reporting junction temp
> thermal: Add DT binding doc for thermal of PMIC max77620
Add patches 1-3 in my tree. Patch 4 should probably go via documentation
tree. And patch 5 needs dependency to be sorted, and 6 need minor changes.
signature.asc
Description: Digital signature
Re: [PATCH V2 3/6] thermal: Add devm_thermal_zone_of_sensor_register() in managed devices list
On Wed, Mar 09, 2016 at 06:40:07PM +0530, Laxman Dewangan wrote: > The interface thermal_zone_of_sensor_register() and > thermal_zone_of_sensor_unregister() gained their devm_ > wrappers. Add these APIs in the list of managed devices. > > Signed-off-by: Laxman Dewangan Acked-by: Eduardo Valentin This should probably go via the documentation tree. > > --- > Changes from V1: > - No change. > > Documentation/driver-model/devres.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/driver-model/devres.txt > b/Documentation/driver-model/devres.txt > index 5930d9a..dd7ce58 100644 > --- a/Documentation/driver-model/devres.txt > +++ b/Documentation/driver-model/devres.txt > @@ -342,6 +342,10 @@ SLAVE DMA ENGINE > SPI >devm_spi_register_master() > > +THERMAL > + devm_thermal_zone_of_sensor_register() > + devm_thermal_zone_of_sensor_unregister() > + > WATCHDOG >devm_watchdog_register_device() >devm_watchdog_unregister_device() > -- > 2.1.4 > -- 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 V2 6/6] thermal: Add DT binding doc for thermal of PMIC max77620
On Wed, Mar 09, 2016 at 06:40:10PM +0530, Laxman Dewangan wrote:
> Maxim Semiconductor MAX77620 supports alarm interrupts when
> its die temperature crosses 120C and 140C. These threshold
> temperatures are not configurable.
>
> Add DT binding document to details out the DT property related
> to MAX77620 thermal functionality.
>
> Signed-off-by: Laxman Dewangan
>
> ---
> Changes from V1:
> - New in series to add DT binding doc per V1 review.
>
> .../bindings/thermal/thermal-max77620.txt | 43
> ++
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/thermal-max77620.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
> b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
> new file mode 100644
> index 000..d76412f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
> @@ -0,0 +1,43 @@
> +Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
> +
> +Maxim Semiconductor MAX77620 supports alarm interrupts when its
> +die temperature crosses 120C and 140C. These threshold temperatures
> +are not configurable. Device does not provide the real temperature
> +of die other than just indicating whether temperature is above or
> +below threshold level.
> +
> +Required properties:
> +---
> +#thermal-sensor-cells: Please refer
>
> + for more details.
> + The value must be 0.
> +
> +For more details, please refer generic thermal DT binding document
> +.
> +
> +Please refer for mfd DT binding
> +document for the MAX77620.
> +
> +Example:
> +
> +#include
> +...
> +spmic: max77620@3c {
> + compatible = "maxim,max77620";
> +
> + #thermal-sensor-cells = <0>;
> +};
> +
> +thermal-zones {
> + PMIC-Die {
> + thermal-sensors = <&spmic>;
> + trips {
> + die_temp_thresh: hot-die {
> + temperature = <12>;
> + type = "active";
> + hysteresis = <0>;
> + };
> + };
> + };
> +};
Considering that this is an example (and people will copy and paste it),
please add all the required DT properties for a thermal-zone node.
> +
> --
> 2.1.4
>
--
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 V2 5/6] thermal: max77620: Add thermal driver for reporting junction temp
On Wed, Mar 09, 2016 at 06:40:09PM +0530, Laxman Dewangan wrote:
> Maxim Semiconductor Max77620 supports alarm interrupts when
> its die temperature crosses 120C and 140C. These threshold
> temperatures are not configurable.
>
> Add thermal driver to register PMIC die temperature as thermal
> zone sensor and capture the die temperature warning interrupts
> to notifying the client.
>
> Signed-off-by: Laxman Dewangan
>
> ---
> Changes from V1:
> - checkpatch warning fix and simplifying the dev.of_node
> initialisation.
>
> drivers/thermal/Kconfig| 10 +++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/thermal-max77620.c | 151
> +
> 3 files changed, 162 insertions(+)
> create mode 100644 drivers/thermal/thermal-max77620.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5e7c97a..fc856eb 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -194,6 +194,16 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>
> +config MAX77620_THERMAL
> + tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> + depends on MFD_MAX77620
> + depends on OF
The previous question on compile test was more if we could add depends
on COMPILE_TEST flag. Sorry if I was not clear enough.
I am adding the flag here:
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
- depends on MFD_MAX77620
+ depends on MFD_MAX77620 || COMPILE_TEST
+ depends on HAS_IOMEM
depends on OF
help
Support for die junction temperature
warning alarm for Maxim
but I still cannot compile test the file because of the missing header.
drivers/thermal/thermal-max77620.c:16:32: fatal error:
linux/mfd/max77620.h: No such file or directory
#include
I wont be able to merge this as it is. We need to sort out the
dependency first.
The patches with devm_ helpers could go, though.
> + help
> + Support for die junction temperature warning alarm for Maxim
> + Semiconductor PMIC MAX77620 device. Device generates two alarm
> + interrupts when PMIC die temperature cross the threshold of
> + 120 degC and 140 degC.
> +
> config SPEAR_THERMAL
> tristate "SPEAr thermal sensor driver"
> depends on PLAT_SPEAR || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8e9cbc3..c6bc2bd 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_MAX77620_THERMAL) += thermal-max77620.o
> obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
> obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
> obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
> diff --git a/drivers/thermal/thermal-max77620.c
> b/drivers/thermal/thermal-max77620.c
> new file mode 100644
> index 000..5fba00f
> --- /dev/null
> +++ b/drivers/thermal/thermal-max77620.c
> @@ -0,0 +1,151 @@
> +/*
> + * Junction temperature thermal driver for Maxim Max77620.
> + *
> + * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
> + *
> + * Author: Laxman Dewangan
> + * Mallikarjun Kasoju
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX77620_NORMAL_OPERATING_TEMP 10
> +#define MAX77620_TJALARM1_TEMP 12
> +#define MAX77620_TJALARM2_TEMP 14
> +
> +struct max77620_therm_info {
> + struct device *dev;
> + struct regmap *rmap;
> + struct thermal_zone_device *tz_device;
> + int irq_tjalarm1;
> + int irq_tjalarm2;
> +};
> +
> +static int max77620_thermal_read_temp(void *data, int *temp)
> +{
> + struct max77620_therm_info *mtherm = data;
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(mtherm->rmap, MAX77620_REG_STATLBT, &val);
> + if (ret < 0) {
> + dev_err(mtherm->dev, "Failed to read STATLBT, %d\n", ret);
> + return -EINVAL;
> + }
> +
> + if (val & MAX77620_IRQ_TJALRM2_MASK)
> + *temp = MAX77620_TJALARM2_TEMP;
> + else if (val & MAX77620_IRQ_TJALRM1_MASK)
> +
Re: [PATCH V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620
Laxman, On Wed, Mar 09, 2016 at 06:40:04PM +0530, Laxman Dewangan wrote: > The series add the devm_ version of thermal_zone_of_sensor_register/ > unregister, interface details, and use this in new thermal driver > for max77620. > > The header file for max77620 is part of MFD patch > https://lkml.org/lkml/2016/2/11/186 > > Changes from V1: > - Run checkpatch with --strict and fix all warnings. > - Added details of interfaces in spifs-api.txt > - Added DT binding doc. Thanks a lot for working on the comments. I don't see anything specific right now. So, I am starting a couple of automated testing on this series. If I find something, I will let you know. signature.asc Description: Digital signature
Re: [PATCH v6 08/11] tpm: Driver for supporting multiple emulated TPMs
On Wed, Mar 9, 2016 at 9:39 AM, Stefan Berger wrote: > This patch implements a 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. Nifty! Is anyone considering writing a modification or replacement of trousers that creates claims the real tpm and exposes a vtpm that handles multiplexing internally? Does the vtpm driver intelligently support multiple simultaneous clients? --Andy -- 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 09/11] tpm: Initialize TPM and get durations and timeouts
Add the retrieval of TPM 1.2 durations and timeouts. Since this requires
the startup of the TPM, do this for TPM 1.2 and TPM 2.
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/tpm_vtpm.c | 94 -
1 file changed, 85 insertions(+), 9 deletions(-)
diff --git a/drivers/char/tpm/tpm_vtpm.c b/drivers/char/tpm/tpm_vtpm.c
index 0da311b..4f75248 100644
--- a/drivers/char/tpm/tpm_vtpm.c
+++ b/drivers/char/tpm/tpm_vtpm.c
@@ -45,8 +45,11 @@ struct vtpm_dev {
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 */
+
+ struct work_struct work; /* task that retrieves TPM timeouts */
};
+static struct workqueue_struct *workqueue;
static void vtpm_delete_device(struct vtpm_dev *vtpm_dev);
@@ -67,6 +70,15 @@ static ssize_t vtpm_fops_read(struct file *filp, char __user
*buf,
size_t len;
int sig, rc;
+ mutex_lock(&vtpm_dev->buf_lock);
+
+ if (!(vtpm_dev->state & STATE_OPENED_FLAG)) {
+ mutex_unlock(&vtpm_dev->buf_lock);
+ return -EPIPE;
+ }
+
+ mutex_unlock(&vtpm_dev->buf_lock);
+
sig = wait_event_interruptible(vtpm_dev->wq, vtpm_dev->req_len != 0);
if (sig)
return -EINTR;
@@ -110,6 +122,11 @@ static ssize_t vtpm_fops_write(struct file *filp, const
char __user *buf,
mutex_lock(&vtpm_dev->buf_lock);
+ if (!(vtpm_dev->state & STATE_OPENED_FLAG)) {
+ mutex_unlock(&vtpm_dev->buf_lock);
+ return -EPIPE;
+ }
+
if (count > sizeof(vtpm_dev->buffer) ||
!(vtpm_dev->state & STATE_WAIT_RESPONSE_FLAG)) {
mutex_unlock(&vtpm_dev->buf_lock);
@@ -154,6 +171,9 @@ static unsigned int vtpm_fops_poll(struct file *filp,
poll_table *wait)
if (vtpm_dev->req_len)
ret |= POLLIN | POLLRDNORM;
+ if (!(vtpm_dev->state & STATE_OPENED_FLAG))
+ ret |= POLLHUP;
+
mutex_unlock(&vtpm_dev->buf_lock);
return ret;
@@ -341,6 +361,54 @@ static const struct tpm_class_ops vtpm_tpm_ops = {
};
/*
+ * Code related to the startup of the TPM 2 and startup of TPM 1.2 +
+ * retrieval of timeouts and durations.
+ */
+
+static void vtpm_dev_work(struct work_struct *work)
+{
+ struct vtpm_dev *vtpm_dev = container_of(work, struct vtpm_dev, work);
+ int rc;
+
+ if (vtpm_dev->flags & VTPM_FLAG_TPM2)
+ rc = tpm2_startup(vtpm_dev->chip, TPM2_SU_CLEAR);
+ else
+ rc = tpm_get_timeouts(vtpm_dev->chip);
+
+ if (rc)
+ goto err;
+
+ rc = tpm_chip_register(vtpm_dev->chip);
+ if (rc)
+ goto err;
+
+ return;
+
+err:
+ vtpm_fops_undo_open(vtpm_dev);
+}
+
+/*
+ * vtpm_dev_work_stop: make sure the work has finished
+ *
+ * This function is useful when user space closed the fd
+ * while the driver still determines timeouts.
+ */
+static void vtpm_dev_work_stop(struct vtpm_dev *vtpm_dev)
+{
+ vtpm_fops_undo_open(vtpm_dev);
+ flush_work(&vtpm_dev->work);
+}
+
+/*
+ * vtpm_dev_work_start: Schedule the work for TPM 1.2 & 2 initialization
+ */
+static inline void vtpm_dev_work_start(struct vtpm_dev *vtpm_dev)
+{
+ queue_work(workqueue, &vtpm_dev->work);
+}
+
+/*
* Code related to creation and deletion of device pairs
*/
static struct vtpm_dev *vtpm_create_vtpm_dev(void)
@@ -355,6 +423,7 @@ static struct vtpm_dev *vtpm_create_vtpm_dev(void)
init_waitqueue_head(&vtpm_dev->wq);
mutex_init(&vtpm_dev->buf_lock);
+ INIT_WORK(&vtpm_dev->work, vtpm_dev_work);
chip = tpm_chip_alloc(NULL, &vtpm_tpm_ops);
if (IS_ERR(chip)) {
@@ -424,9 +493,7 @@ static struct file *vtpm_create_device(
if (vtpm_dev->flags & VTPM_FLAG_TPM2)
vtpm_dev->chip->flags |= TPM_CHIP_FLAG_TPM2;
- rc = tpm_chip_register(vtpm_dev->chip);
- if (rc)
- goto err_vtpm_fput;
+ vtpm_dev_work_start(vtpm_dev);
vtpm_new_dev->fd = fd;
vtpm_new_dev->major = MAJOR(vtpm_dev->chip->dev.devt);
@@ -435,12 +502,6 @@ static struct file *vtpm_create_device(
return file;
-err_vtpm_fput:
- put_unused_fd(fd);
- fput(file);
-
- return ERR_PTR(rc);
-
err_put_unused_fd:
put_unused_fd(fd);
@@ -455,6 +516,8 @@ err_delete_vtpm_dev:
*/
static void vtpm_delete_device(struct vtpm_dev *vtpm_dev)
{
+ vtpm_dev_work_stop(vtpm_dev);
+
tpm_chip_unregister(vtpm_dev->chip);
vtpm_fops_undo_open(vtpm_dev);
@@ -549,11 +612,24 @@ static int __init vtpm_module_init(void)
return rc;
}
+ workqueue = create_workqueue("tpm-vtpm");
+ if (!workqueue) {
+ pr_er
[PATCH v6 10/11] tpm: Add documentation for the tpm_vtpm device driver
Add documentation for the tpm_vtpm device driver that implements
support for providing TPM functionality to Linux containers.
Parts of this documentation were recycled from the Xen vTPM
device driver documentation.
Signed-off-by: Stefan Berger
CC: linux-ker...@vger.kernel.org
CC: linux-doc@vger.kernel.org
CC: linux-...@vger.kernel.org
---
Documentation/tpm/tpm_vtpm.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/tpm/tpm_vtpm.txt
diff --git a/Documentation/tpm/tpm_vtpm.txt b/Documentation/tpm/tpm_vtpm.txt
new file mode 100644
index 000..d193573
--- /dev/null
+++ b/Documentation/tpm/tpm_vtpm.txt
@@ -0,0 +1,54 @@
+Virtual TPM Device Driver for Linux Containers
+
+Authors: Stefan Berger (IBM)
+
+This document describes the virtual Trusted Platform Module (vTPM) device
+driver for Linux containers.
+
+INTRODUCTION
+
+
+The goal of this work is to provide TPM functionality to each Linux
+container. This allows programs to interact with a TPM in a container
+the same way they interact with a TPM on the physical system. Each
+container gets its own unique, emulated, software TPM.
+
+
+DESIGN
+--
+
+To make an emulated software TPM available to each container, the container
+management stack needs to create a device pair consisting of a client TPM
+character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
+descriptor. The former is moved into the container by creating a character
+device with the appropriate major and minor numbers while the file descriptor
+is passed to the TPM emulator. Software inside the container can then send
+TPM commands using the character device and the emulator will receive the
+commands via the file descriptor and use it for sending back responses.
+
+To support this, the virtual TPM device driver provides a device /dev/vtpmx
+that is used to create device pairs using an ioctl. The ioctl takes as
+an input flags for configuring the device. The flags for example indicate
+whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
+The result of the ioctl are the file descriptor for the 'server side'
+as well as the major and minor numbers of the character device that was
created.
+Besides that the number of the TPM character device is return. If for
+example /dev/tpm10 was created, the number (dev_num) 10 is returned.
+
+The following is the data structure of the VTPM_NEW_DEV ioctl:
+
+struct vtpm_new_dev {
+ __u32 flags; /* input */
+ __u32 dev_num; /* output */
+ __u32 fd;/* output */
+ __u32 major; /* output */
+ __u32 minor; /* output */
+};
+
+Note that if unsupported flags are passed to the device driver, the ioctl will
+fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl is
+called on the device driver, the ioctl will fail and errno will be set to
+ENOTTY.
+
+See /usr/include/linux/vtpm.h for definitions related to the public interface
+of this vTPM device driver.
--
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 08/11] tpm: Driver for supporting multiple emulated TPMs
This patch implements a 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.c | 566
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/vtpm.h | 41
5 files changed, 619 insertions(+)
create mode 100644 drivers/char/tpm/tpm_vtpm.c
create mode 100644 include/uapi/linux/vtpm.h
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 3b84a8b..4c4e843 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
+ tristate "VTPM Interface"
+ depends on TCG_TPM
+ ---help---
+ This driver supports 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..1a409c57 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) += tpm_vtpm.o
diff --git a/drivers/char/tpm/tpm_vtpm.c b/drivers/char/tpm/tpm_vtpm.c
new file mode 100644
index 000..0da311b
--- /dev/null
+++ b/drivers/char/tpm/tpm_vtpm.c
@@ -0,0 +1,566 @@
+/*
+ * Copyright (C) 2015, 2016 IBM Corporation
+ *
+ * Author: Stefan Berger
+ *
+ * Maintained by:
+ *
+ * Device driver for vTPM.
+ *
+ * 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_REQ_COMPLETE_FLAG BIT(0)
+
+struct vtpm_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_delete_device(struct vtpm_dev *vtpm_dev);
+
+/*
+ * Functions related to 'server side'
+ */
+
+/**
+ * vtpm_fops_read - Read TPM commands on 'server side'
+ *
+ * Return value:
+ * Number of bytes read or negative error code
+ */
+static ssize_t vtpm_fops_read(struct file *filp, char __user *buf,
+ size_t count, loff_t *off)
+{
+ struct vtpm_dev *vtpm_dev = filp->private_data;
+ size_t len;
+ int sig, rc;
+
+ sig = wait_event_interruptible(vtpm_dev->wq, vtpm_dev->req_len != 0);
+ if (sig)
+ return -EINTR;
+
+ mutex_lock(&vtpm_dev->buf_lock);
+
+ len = vtpm_dev->req_len;
+
+ if (count < len) {
+ mutex_unlock(&vtpm_dev->buf_lock);
+ pr_debug("Invalid size in recv: count=%zd, req_len=%zd\n",
+count, len);
+ return -EIO;
+ }
+
+ rc = copy_to_user(buf, vtpm_dev->buffer, len);
+ memset(vtpm_dev->buffer, 0, len);
+ vtpm_dev->req_len = 0;
+
+ if (!rc)
+ vtpm_dev->state |= STATE_WAIT_RESPONSE_FLAG;
+
+ mutex_unlock(&vtpm_dev->buf_lock);
+
+ if (rc)
+ return -EFAULT;
+
+ return len;
+}
+
+/**
+ * vtpm_fops_write - Write TPM responses on 'server side'
+ *
+ * Return value:
+ * Number of bytes read or negative error value
+ */
+static ssize_t vtpm_fops_write(struct file *filp, const char __user *buf,
+ size_t count, loff_t *off)
+{
+
Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}
Hi Linus, On Sunday 28 February 2016 08:14 PM, Laxman Dewangan wrote: On Thursday 25 February 2016 07:43 PM, Linus Walleij wrote: On Wed, Feb 24, 2016 at 2:15 PM, Laxman Dewangan wrote: Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister() and use these new APIs on hw driver to reduce the error path code and remove callback for driver. As you can probably guess I like this too, so wait a while, collect ACKs and send me a branch to pull for this too. Got lots of ack/reviewed by and captured all. Also did code changes per review: - Optimizing in devm_ apis. - Correcting the description of devm_ apis. - Simplifying probe in digicolor. - Removing unwanted pfc->pinctrl in ish. 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. Thanks, Laxman -- 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 V2 2/6] thermal: of-thermal: Add devm version of thermal_zone_of_sensor_register
Add resource managed version of thermal_zone_of_sensor_register() and
thermal_zone_of_sensor_unregister().
This helps in reducing the code size in error path, remove of
driver remove callbacks and making proper sequence for deallocations.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Run checkpatch --strict and fix the issue.
drivers/thermal/of-thermal.c | 81
include/linux/thermal.h | 18 ++
2 files changed, 99 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 9043f8f..49ac23d 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -555,6 +555,87 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
}
EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+static void devm_thermal_zone_of_sensor_release(struct device *dev, void *res)
+{
+ thermal_zone_of_sensor_unregister(dev,
+ *(struct thermal_zone_device **)res);
+}
+
+static int devm_thermal_zone_of_sensor_match(struct device *dev, void *res,
+void *data)
+{
+ struct thermal_zone_device **r = res;
+
+ if (WARN_ON(!r || !*r))
+ return 0;
+
+ return *r == data;
+}
+
+/**
+ * devm_thermal_zone_of_sensor_register - Resource managed version of
+ * thermal_zone_of_sensor_register()
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ * a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ * back, when a temperature reading is needed.
+ * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
+ *
+ * Refer thermal_zone_of_sensor_register() for more details.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ * Registered hermal_zone_device device will automatically be
+ * released when device is unbounded.
+ */
+struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
+ struct device *dev, int sensor_id,
+ void *data, const struct thermal_zone_of_device_ops *ops)
+{
+ struct thermal_zone_device **ptr, *tzd;
+
+ ptr = devres_alloc(devm_thermal_zone_of_sensor_release, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ tzd = thermal_zone_of_sensor_register(dev, sensor_id, data, ops);
+ if (IS_ERR(tzd)) {
+ devres_free(ptr);
+ return tzd;
+ }
+
+ *ptr = tzd;
+ devres_add(dev, ptr);
+
+ return tzd;
+}
+EXPORT_SYMBOL_GPL(devm_thermal_zone_of_sensor_register);
+
+/**
+ * devm_thermal_zone_of_sensor_unregister - Resource managed version of
+ * thermal_zone_of_sensor_unregister().
+ * @dev: Device for which which resource was allocated.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is
registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with devm_thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ * Normally this function will not need to be called and the resource
+ * management code will ensure that the resource is freed.
+ */
+void devm_thermal_zone_of_sensor_unregister(struct device *dev,
+ struct thermal_zone_device *tzd)
+{
+ WARN_ON(devres_release(dev, devm_thermal_zone_of_sensor_release,
+ devm_thermal_zone_of_sensor_match, tzd));
+}
+EXPORT_SYMBOL_GPL(devm_thermal_zone_of_sensor_unregister);
+
/*** functions parsing device tree nodes ***/
/**
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index e13a1ac..9c48199 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -362,6 +362,11 @@ thermal_zone_of_sensor_register(struct device *dev, int
id, void *data,
const struct thermal_zone_of_device_ops *ops);
void thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tz);
+struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
+ struct device *dev, int id, void *data,
+ const struct thermal_zone_of_device_ops *ops);
+void devm_thermal_zone_of_sensor_unregister(struct device *dev,
+ struct thermal_zone_device *tz);
#else
static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
@@ -376,6 +381,19 @
[PATCH V2 6/6] thermal: Add DT binding doc for thermal of PMIC max77620
Maxim Semiconductor MAX77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.
Add DT binding document to details out the DT property related
to MAX77620 thermal functionality.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- New in series to add DT binding doc per V1 review.
.../bindings/thermal/thermal-max77620.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/thermal-max77620.txt
diff --git a/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
new file mode 100644
index 000..d76412f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
@@ -0,0 +1,43 @@
+Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Maxim Semiconductor MAX77620 supports alarm interrupts when its
+die temperature crosses 120C and 140C. These threshold temperatures
+are not configurable. Device does not provide the real temperature
+of die other than just indicating whether temperature is above or
+below threshold level.
+
+Required properties:
+---
+#thermal-sensor-cells: Please refer
+ for more details.
+ The value must be 0.
+
+For more details, please refer generic thermal DT binding document
+.
+
+Please refer for mfd DT binding
+document for the MAX77620.
+
+Example:
+
+#include
+...
+spmic: max77620@3c {
+ compatible = "maxim,max77620";
+
+ #thermal-sensor-cells = <0>;
+};
+
+thermal-zones {
+ PMIC-Die {
+ thermal-sensors = <&spmic>;
+ trips {
+ die_temp_thresh: hot-die {
+ temperature = <12>;
+ type = "active";
+ hysteresis = <0>;
+ };
+ };
+ };
+};
+
--
2.1.4
--
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 V2 3/6] thermal: Add devm_thermal_zone_of_sensor_register() in managed devices list
The interface thermal_zone_of_sensor_register() and thermal_zone_of_sensor_unregister() gained their devm_ wrappers. Add these APIs in the list of managed devices. Signed-off-by: Laxman Dewangan --- Changes from V1: - No change. Documentation/driver-model/devres.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 5930d9a..dd7ce58 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -342,6 +342,10 @@ SLAVE DMA ENGINE SPI devm_spi_register_master() +THERMAL + devm_thermal_zone_of_sensor_register() + devm_thermal_zone_of_sensor_unregister() + WATCHDOG devm_watchdog_register_device() devm_watchdog_unregister_device() -- 2.1.4 -- 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 V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620
The series add the devm_ version of thermal_zone_of_sensor_register/
unregister, interface details, and use this in new thermal driver
for max77620.
The header file for max77620 is part of MFD patch
https://lkml.org/lkml/2016/2/11/186
Changes from V1:
- Run checkpatch with --strict and fix all warnings.
- Added details of interfaces in spifs-api.txt
- Added DT binding doc.
Laxman Dewangan (6):
thermal: doc: Add details of
thermal_zone_of_sensor_{register,unregister}
thermal: of-thermal: Add devm version of
thermal_zone_of_sensor_register
thermal: Add devm_thermal_zone_of_sensor_register() in managed devices
list
thermal: doc: Add details of
devm_thermal_zone_of_sensor_{register,unregister}
thermal: max77620: Add thermal driver for reporting junction temp
thermal: Add DT binding doc for thermal of PMIC max77620
.../bindings/thermal/thermal-max77620.txt | 43 ++
Documentation/driver-model/devres.txt | 4 +
Documentation/thermal/sysfs-api.txt| 68 ++
drivers/thermal/Kconfig| 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/of-thermal.c | 81 +++
drivers/thermal/thermal-max77620.c | 151 +
include/linux/thermal.h| 18 +++
8 files changed, 376 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/thermal-max77620.txt
create mode 100644 drivers/thermal/thermal-max77620.c
--
2.1.4
--
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 V2 4/6] thermal: doc: Add details of devm_thermal_zone_of_sensor_{register,unregister}
Add details of the interface devm_thermal_zone_of_sensor_register() and devm_thermal_zone_of_sensor_unregister() in the . Signed-off-by: Laxman Dewangan --- Changes from V1: - New in series. Documentation/thermal/sysfs-api.txt | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 18a3a5e..ed419d6 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -117,6 +117,29 @@ temperature) and throttle appropriate devices. interface. It will also silent the zone by remove the .get_temp() and get_trend() thermal zone device callbacks. +1.1.5 struct thermal_zone_device *devm_thermal_zone_of_sensor_register( + struct device *dev, int sensor_id, + void *data, const struct thermal_zone_of_device_ops *ops) + + This interface is resource managed version of + thermal_zone_of_sensor_register(). + All details of thermal_zone_of_sensor_register() described in + section 1.1.3 is applicable here. + The benefit of using this interface to register sensor is that it + is not require to explicitly call thermal_zone_of_sensor_unregister() + in error path or during driver unbinding as this is done by driver + resource manager. + +1.1.6 void devm_thermal_zone_of_sensor_unregister(struct device *dev, + struct thermal_zone_device *tzd) + + This interface is resource managed version of + thermal_zone_of_sensor_unregister(). + All details of thermal_zone_of_sensor_unregister() described in + section 1.1.4 is applicable here. + Normally this function will not need to be called and the resource + management code will ensure that the resource is freed. + 1.2 thermal cooling device interface 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name, void *devdata, struct thermal_cooling_device_ops *) -- 2.1.4 -- 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 V2 5/6] thermal: max77620: Add thermal driver for reporting junction temp
Maxim Semiconductor Max77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.
Add thermal driver to register PMIC die temperature as thermal
zone sensor and capture the die temperature warning interrupts
to notifying the client.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- checkpatch warning fix and simplifying the dev.of_node
initialisation.
drivers/thermal/Kconfig| 10 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/thermal-max77620.c | 151 +
3 files changed, 162 insertions(+)
create mode 100644 drivers/thermal/thermal-max77620.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5e7c97a..fc856eb 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -194,6 +194,16 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config MAX77620_THERMAL
+ tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
+ depends on MFD_MAX77620
+ depends on OF
+ help
+ Support for die junction temperature warning alarm for Maxim
+ Semiconductor PMIC MAX77620 device. Device generates two alarm
+ interrupts when PMIC die temperature cross the threshold of
+ 120 degC and 140 degC.
+
config SPEAR_THERMAL
tristate "SPEAr thermal sensor driver"
depends on PLAT_SPEAR || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 8e9cbc3..c6bc2bd 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_DOVE_THERMAL)+= dove_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_MAX77620_THERMAL) += thermal-max77620.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
diff --git a/drivers/thermal/thermal-max77620.c
b/drivers/thermal/thermal-max77620.c
new file mode 100644
index 000..5fba00f
--- /dev/null
+++ b/drivers/thermal/thermal-max77620.c
@@ -0,0 +1,151 @@
+/*
+ * Junction temperature thermal driver for Maxim Max77620.
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author: Laxman Dewangan
+ *Mallikarjun Kasoju
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX77620_NORMAL_OPERATING_TEMP 10
+#define MAX77620_TJALARM1_TEMP 12
+#define MAX77620_TJALARM2_TEMP 14
+
+struct max77620_therm_info {
+ struct device *dev;
+ struct regmap *rmap;
+ struct thermal_zone_device *tz_device;
+ int irq_tjalarm1;
+ int irq_tjalarm2;
+};
+
+static int max77620_thermal_read_temp(void *data, int *temp)
+{
+ struct max77620_therm_info *mtherm = data;
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(mtherm->rmap, MAX77620_REG_STATLBT, &val);
+ if (ret < 0) {
+ dev_err(mtherm->dev, "Failed to read STATLBT, %d\n", ret);
+ return -EINVAL;
+ }
+
+ if (val & MAX77620_IRQ_TJALRM2_MASK)
+ *temp = MAX77620_TJALARM2_TEMP;
+ else if (val & MAX77620_IRQ_TJALRM1_MASK)
+ *temp = MAX77620_TJALARM1_TEMP;
+ else
+ *temp = MAX77620_NORMAL_OPERATING_TEMP;
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops max77620_thermal_ops = {
+ .get_temp = max77620_thermal_read_temp,
+};
+
+static irqreturn_t max77620_thermal_irq(int irq, void *data)
+{
+ struct max77620_therm_info *mtherm = data;
+
+ if (irq == mtherm->irq_tjalarm1)
+ dev_warn(mtherm->dev, "Junction Temp Alarm1(120C) occurred\n");
+ else if (irq == mtherm->irq_tjalarm2)
+ dev_warn(mtherm->dev, "Junction Temp Alarm2(140C) occurred\n");
+
+ thermal_zone_device_update(mtherm->tz_device);
+
+ return IRQ_HANDLED;
+}
+
+static int max77620_thermal_probe(struct platform_device *pdev)
+{
+ struct max77620_therm_info *mtherm;
+ int ret;
+
+ pdev->dev.of_node = pdev->dev.parent->of_node;
+
+ mtherm = devm_kzalloc(&pdev->dev, sizeof(*mtherm), GFP_KERNEL);
+ if (!mtherm)
+ return -ENOMEM;
+
+ mtherm->irq_tjalarm1 = platform_get_irq(pdev, 0);
+ mtherm->irq_tjalarm2 = platform_get_irq(pdev, 1);
+ if ((mtherm->irq_tjalar
[PATCH V2 1/6] thermal: doc: Add details of thermal_zone_of_sensor_{register,unregister}
Add details of the interface thermal_zone_of_sensor_register() and thermal_zone_of_sensor_unregister() in the thermal/sysfs-api.txt. The details describes the functionality and parameter which are passed to these interfaces. Signed-off-by: Laxman Dewangan --- Changes from V1: - This is new in series per review comment from V1. Documentation/thermal/sysfs-api.txt | 45 + 1 file changed, 45 insertions(+) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 8c745c8..18a3a5e 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -72,6 +72,51 @@ temperature) and throttle appropriate devices. It deletes the corresponding entry form /sys/class/thermal folder and unbind all the thermal cooling devices it uses. +1.1.3 struct thermal_zone_device *thermal_zone_of_sensor_register( + struct device *dev, int sensor_id, void *data, + const struct thermal_zone_of_device_ops *ops) + + This interface adds a new sensor to a DT thermal zone. + This function will search the list of thermal zones described in + device tree and look for the zone that refer to the sensor device + pointed by dev->of_node as temperature providers. For the zone + pointing to the sensor node, the sensor will be added to the DT + thermal zone device. + + The parameters for this interface are: + dev:Device node of sensor containing valid node pointer in + dev->of_node. + sensor_id: a sensor identifier, in case the sensor IP has more + than one sensors + data: a private pointer (owned by the caller) that will be + passed back, when a temperature reading is needed. + ops:struct thermal_zone_of_device_ops *. + + get_temp: a pointer to a function that reads the + sensor temperature. This is mandatory + callback provided by sensor driver. + get_trend: a pointer to a function that reads the + sensor temperature trend. + set_emul_temp: a pointer to a function that sets + sensor emulated temperature. + The thermal zone temperature is provided by the get_temp() function + pointer of thermal_zone_of_device_ops. When called, it will + have the private pointer @data back. + + It returns error pointer if fails otherwise valid thermal zone device + handle. Caller should check the return handle with IS_ERR() for finding + whether success or not. + +1.1.4 void thermal_zone_of_sensor_unregister(struct device *dev, + struct thermal_zone_device *tzd) + + This interface unregisters a sensor from a DT thermal zone which was + successfully added by interface thermal_zone_of_sensor_register(). + This function removes the sensor callbacks and private data from the + thermal zone device registered with thermal_zone_of_sensor_register() + interface. It will also silent the zone by remove the .get_temp() and + get_trend() thermal zone device callbacks. + 1.2 thermal cooling device interface 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name, void *devdata, struct thermal_cooling_device_ops *) -- 2.1.4 -- 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/3] thermal: max77620: Add thermal driver for reporting junction temp
On Wednesday 09 March 2016 02:54 AM, Eduardo Valentin wrote: On Fri, Mar 04, 2016 at 07:10:10PM +0530, Laxman Dewangan wrote: Maxim Semiconductor Max77620 supports alarm interrupts when its die temperature crosses 120C and 140C. These threshold temperatures are not configurable. Add thermal driver to register PMIC die temperature as thermal zone sensor and capture the die temperature warning interrupts to notifying the client. Are any of these critical? Datasheet says that two alarm interrupt at 120 and 140degC. 165 degC is shutdown temp on which PMIC get shutdown. So just says as the warning interrupt. Signed-off-by: Laxman Dewangan --- drivers/thermal/Kconfig| 9 +++ drivers/thermal/Makefile | 1 + drivers/thermal/thermal-max77620.c | 151 + Given that it is a DT based driver, please add also a binding entry under Documentation/devicetree/bindings/thermal/ There is no new DT property and so did not added. But will add the doc saying the mandatory properties from thermal framework i.e. #thermal-sensor-cells + depends on MFD_MAX77620 Can this be COMPILE_TEST'ed? Yes, I compile and tested . + depends on OF + help + Support for die junction temperature warning alarm for Maxim + Semiconductor PMIC MAX77620 device. Device generates alert + signal/interrupt when die temperature cross its threshold. + Somehow checkpatch.pl --strict is complaining about this entry. Can you please check? The help should be minimum 4 lines otherwise warning is generated. I made it for next patch. Second warning is: /** WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #57: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 174 lines checked 0001-thermal-max77620-Add-thermal-driver-for-reporting-ju.patch has style problems, please review. **/ This is because new file get added and I think we can ignore it. + if (val & MAX77620_IRQ_TJALRM2_MASK) + *temp = MAX77620_TJALARM2_TEMP; + else if (val & MAX77620_IRQ_TJALRM1_MASK) + *temp = MAX77620_TJALARM1_TEMP; + else + *temp = MAX77620_NORMAL_OPERATING_TEMP; So, no way at all to get a temp? yaah, there is no way other than getting the bit for whether temp crossed threshold or not. + + if (!pdev->dev.of_node) + pdev->dev.of_node = pdev->dev.parent->of_node; Why is this needed? This driver is sub mfd devices and it is registered without device node pointer. The DT binding doc for the mfdmax77620 is flat, does not have thermal sub node. hence to get the of_node for sensor, I am making the device node as node pointer for thermal sensor. I can overwrite as pdev->dev.of_node = pdev->dev.parent->of_node also without check for simplification. -- 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/3] thermal: of-thermal: Add devm version of thermal_zone_of_sensor_register
Hi Edurado, Thanks for review. On Wednesday 09 March 2016 02:59 AM, Eduardo Valentin wrote: Hello Laxman, Minor as follows. Can you please run ./scripts/checkpatch.pl --strict on this and remove the warnings, errors, checks? Taken from existing function and so borrowed the error. Will fix in next revision. On Fri, Mar 04, 2016 at 07:10:08PM +0530, Laxman Dewangan wrote: Add resource managed version of thermal_zone_of_sensor_register() and thermal_zone_of_sensor_unregister(). This helps in reducing the code size in error path, remove of driver remove callbacks and making proper sequence for deallocations. Signed-off-by: Laxman Dewangan --- drivers/thermal/of-thermal.c | 81 include/linux/thermal.h | 18 ++ Could you also please document these under Documentation/thermal/sysfs-api.txt? Sure, I saw that thermal_zone_of_sensor_register/unregister is also not documented. So I will add the details for this first and then add for newly added interfaces. Will take care in next series. -- 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: Kernel docs: muddying the waters a bit
On Wed, 09 Mar 2016, Dan Allen wrote: > On Tue, Mar 8, 2016 at 6:58 AM, Jani Nikula wrote: > >> I need to look into this again. Is there a specific option or directive >> to produce split output for includes? When I tried this, the result was >> just one big output file. (And indeed we'd need both. Some includes we >> want embedded, some includes should produce separate outputs.) >> > > Nope. What I'm saying is that you run Asciidoctor on each sub-master > include file (an include that manages a part or chapter). That gives you > your individual part/chapter files. Then you need to make an index page, > probably by using the Asciidoctor API to itemize all the chapters as a list > or something. Bummer. Getting the inter-document cross references right may become tricky. We'll be generating plenty of snippets of lightweight markup from source code documentation comments. At the time of processing, we won't know where e.g. a specific function to be cross referenced is documented, if at all. We can't require the documentation comment writers to figure that out either; it's too burdensome, too ugly in the code, and they'll bitrot quickly. Cross referencing in the asciidoc proofs of concept have worked because they've all done the processing as a single single unit, with includes. These hacks have also ignored any broken links, and there have been > Yes, it does require some thinking about cross references. There is a lot > more we can do out of the box, but all those references can be fixed with a > little bit of post-processing in the meantime. It seems to me Sphinx provides much better support regarding cross references, out of the box, within documents and to external documents (intersphinx), with target roles and domains, including validation and not creating broken links in the output. Looking at the current hacks we have for post-processing references, I'm really not thrilled about the prospect of keeping or redoing that. See how this works in Jon's Sphinx test [1]. At the time of generating the markup from source comments, there is no idea if and where gem_init_hw() and intel_guc_ucode_init() are documented. Indeed, documentation for the former does not exist, but there's no broken link. BR, Jani. [1] http://static.lwn.net/kerneldoc/gpu.html#c.intel_guc_ucode_load -- Jani Nikula, Intel Open Source Technology Center -- 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
