On Tue, Apr 02, 2019 at 03:33:16PM -0400, Sasha Levin wrote:
> This patch adds support for a software-only implementation of a TPM
> running in TEE.
>
> There is extensive documentation of the design here:
> https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip
On Tue, Apr 02, 2019 at 01:56:43PM -0700, Stephen Hemminger wrote:
> On Tue, 2 Apr 2019 12:33:16 -0700
> "Sasha Levin" wrote:
>
> > +/*
> > + * ftpm_tee_tpm_op_recv retrieve fTPM response.
> > + * @param: chip, the tpm_chip description as specified in
> > driver/char/tpm/tpm.h.
> > + * @param: bu
Fix misspelling and capitalization of LED in the Kconfig.
Reported-by: Randy Dunlap
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a72f97fca57b..f24d31138471 100644
---
On Wed, Apr 03, 2019 at 05:56:27PM +, Christopher Lameter wrote:
> On Wed, 3 Apr 2019, Al Viro wrote:
>
> > Let's do d_invalidate() on random dentries and hope they go away.
> > With convoluted and brittle logics for deciding which ones to
> > spare, which is actually wrong. This will pick mo
On Wed, Apr 03, 2019 at 09:18:27PM +0300, Jarkko Sakkinen wrote:
> On Tue, Apr 02, 2019 at 03:33:16PM -0400, Sasha Levin wrote:
> > This patch adds support for a software-only implementation of a TPM
> > running in TEE.
> >
> > There is extensive documentation of the design here:
> > https://www.m
On Wed, Apr 03, 2019 at 11:17:27AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 3, 2019 at 11:14 AM Matthias Kaehlcke wrote:
> > Each transfer has it's own work struct (allocated on the stack), hence
> > a) does not occur. b) is still true, but shouldn't be a problem on
> > its own.
>
> Act
From: Enrico Granata
As new transfer mechanisms are added to the EC codebase, they may
not support v2 of the EC protocol.
If the v3 initial handshake transfer fails, the kernel will try
and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
will be NULL, and the code will end up causi
On 03/04/2019 10:08:52-0700, Joe Perches wrote:
> On Wed, 2019-04-03 at 18:22 +0200, Alexandre Belloni wrote:
> > The X11 license text [1] is explicitly for the X Consortium and has a
> > couple of extra clauses. The MIT license text [2] is actually what the
> > current DT files claim.
> []
> > dif
On Wed, Apr 3, 2019 at 1:05 PM Alan Tull wrote:
>
> On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote:
> >
> > Hi Richard,
> >
> > On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote:
> > > Hi Moritz,
> > >
> > >
> > > On 4/3/19 9:20 AM, Moritz Fischer wrote:
> > > > Hi Richard,
> > >
On Wed, Apr 3, 2019 at 11:30 AM Matthias Kaehlcke wrote:
> The worker is owned by this driver and supposedly we know what we are
> doing. Changing a member in the struct after calling complete() would
> likely be a bug anyway (though not necessarily a fatal one).
The work_struct is owned by the d
Fix Error: code indent
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
index 828b328a
On Wed, Apr 03, 2019 at 10:05:42AM +1100, Tobin C. Harding wrote:
> SLUB allocator makes heavy use of ifdef/endif pre-processor macros.
> The pairing of these statements is at times hard to follow e.g. if the
> pair are further than a screen apart or if there are nested pairs. We
> can reduce cogn
On Wed, Apr 03, 2019 at 10:05:43AM +1100, Tobin C. Harding wrote:
> Currently we use the page->lru list for maintaining lists of slabs. We
> have a list in the page structure (slab_list) that can be used for this
> purpose. Doing so makes the code cleaner since we are not overloading
> the lru li
On Wed, Apr 03, 2019 at 10:05:45AM +1100, Tobin C. Harding wrote:
> We now use the slab_list list_head instead of the lru list_head. This
> comment has become stale.
>
> Remove stale comment from page struct slab_list list_head.
>
> Acked-by: Christoph Lameter
> Signed-off-by: Tobin C. Harding
On Wed, Apr 03, 2019 at 10:05:44AM +1100, Tobin C. Harding wrote:
> Currently we use the page->lru list for maintaining lists of slabs. We
> have a list in the page structure (slab_list) that can be used for this
> purpose. Doing so makes the code cleaner since we are not overloading
> the lru li
Em Wed, Apr 03, 2019 at 04:27:56PM +, Song Liu escreveu:
>
>
> > On Apr 3, 2019, at 8:15 AM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Wed, Apr 03, 2019 at 11:53:53AM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Wed, Apr 03, 2019 at 04:37:38PM +0200, Jiri Olsa escreveu:
> >>> hi,
On Wed, Apr 3, 2019 at 11:31 AM wrote:
>
> From: Enrico Granata
>
> As new transfer mechanisms are added to the EC codebase, they may
> not support v2 of the EC protocol.
>
> If the v3 initial handshake transfer fails, the kernel will try
> and call cmd_xfer as a fallback. If v2 is not supported,
From: Aaro Koskinen
Add support for warm reset using SYSTEM_RESET2 introduced in PSCI
1.1 specification.
Signed-off-by: Aaro Koskinen
---
v2: Added #define PSCI_1_1_SYSTEM_RESET_WARM.
Refactored psci_probe.
v1: https://marc.info/?l=linux-arm-kernel&m=1554315142044
On Thu, 28 Feb 2019 19:48:12 +
Louis Taylor wrote:
> When compiling with -Wformat, clang emits the following warnings:
>
> drivers/vfio/pci/vfio_pci.c:1601:5: warning: format specifies type
> 'unsigned short' but the argument has type 'unsigned int' [-Wformat]
>
On Wed, 20 Mar 2019 02:47:23 -0400
Wang Hai wrote:
> Fixes the following sparse warning:
>
> drivers/vfio/vfio_iommu_spapr_tce.c:1401:36: warning:
> symbol 'tce_iommu_driver_ops' was not declared. Should it be static?
>
> Fixes: 5ffd229c0273 ("powerpc/vfio: Implement IOMMU driver for VFIO")
>
> On Apr 3, 2019, at 11:50 AM, Arnaldo Carvalho de Melo
> wrote:
>
> Em Wed, Apr 03, 2019 at 04:27:56PM +, Song Liu escreveu:
>>
>>
>>> On Apr 3, 2019, at 8:15 AM, Arnaldo Carvalho de Melo
>>> wrote:
>>>
>>> Em Wed, Apr 03, 2019 at 11:53:53AM -0300, Arnaldo Carvalho de Melo escreveu:
> On Apr 3, 2019, at 11:55 AM, Song Liu wrote:
>
>
>
>> On Apr 3, 2019, at 11:50 AM, Arnaldo Carvalho de Melo
>> wrote:
>>
>> Em Wed, Apr 03, 2019 at 04:27:56PM +, Song Liu escreveu:
>>>
>>>
On Apr 3, 2019, at 8:15 AM, Arnaldo Carvalho de Melo
wrote:
Em Wed, A
On Wed, Apr 03, 2019 at 07:24:54PM +0100, Al Viro wrote:
> If by "how to do it right" you mean "expedit kicking out something with
> non-zero refcount" - there's no way to do that. Nothing even remotely
> sane.
>
> If you mean "kick out everything in this page with zero refcount" - that
> can be
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
head: 0975e3df30eb5849284c01be66c2ec16d8a48114
commit: 701fd16f3b4e3e5f317a051b36962b8cc756c138 [2/4] locking/rwsem: Remove
arch specific rwsem files
config: um-defconfig (attached as .config)
compiler: gcc-7 (Debia
On 4/3/19 8:48 AM, Miroslav Benes wrote:
>
>> and it looks like the combined KLP_MODULE_RELOC still contains the two
>> unique symbol position values (2 and 3):
>>
>>% objcopy -O binary --only-section=.klp.module_relocs.vmlinux
>> lib/livepatch/test_klp_convert.klp.o >(hexdump -C)
>>0
On Wed 2019-04-03 13:19:22, Dan Murphy wrote:
> Fix misspelling and capitalization of LED in the Kconfig.
>
> Reported-by: Randy Dunlap
> Signed-off-by: Dan Murphy
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~
Hi Steve,
On Wed, 2019-04-03 at 13:16 -0400, Steven Rostedt wrote:
> On Mon, 25 Mar 2019 11:20:47 -0500
> Tom Zanussi wrote:
>
> > > Is it OK if I add the following tags to that patch?
> > >
> > > Reported-by: Tom Zanussi
> > > Tested-by: Tom Zanussi
> > >
> >
> > Yep, fine with me.
>
>
On Wed, Apr 03, 2019 at 10:59:32AM -0400, Vince Weaver wrote:
>
> so moving this to its own thread.
>
> There was a two-part question asked.
> 1. Can the perf-fuzzer crash a Pentium 4 system
> 2. Does anyone care anymore?
>
> The answer to #1 turns out to be "yes"
> I'm not sure abou
From: "Steven Rostedt (VMware)"
If da_tokens are allocated, but dell_smbios_init() eventually fails, it will
free the da_tokens but it does not reset the da_num_tokens number. This
leads to the possibility of a use after free in dell_smbios_find_token().
As da_tokens is not NULL and da_num_tokens
On Tue, Apr 02, 2019 at 10:15:38AM -0600, Alex Williamson wrote:
> Memory backed DMA mappings are accounted against a user's locked
> memory limit, including multiple mappings of the same memory. This
> accounting bounds the number of such mappings that a user can create.
> However, DMA mappings t
'top_base' memory region is optional. Check that the resource is valid
before using it. This avoid getting a "invalid resource" error message
printed by the kernel.
Signed-off-by: Fabien Parent
---
V2:
Fix invalid condition: check against 'res' variable instead of 'ret'.
---
drivers/mm
From: Jérôme Glisse
To avoid random config build issue, select mmu notifier when HMM is
selected. In any cases when HMM get selected it will be by users that
will also wants the mmu notifier.
Changes since v1:
- remove select MMU_NOTIFIER from HMM_MIRROR as it select HMM
which select M
From: Jérôme Glisse
The HMM mirror API can be use in two fashions. The first one where the HMM
user coalesce multiple page faults into one request and set flags per pfns
for of those faults. The second one where the HMM user want to pre-fault a
range with specific flags. For the latter one it is
From: Jérôme Glisse
Changes since v2:
- Improved the documentations
- Added more comments in the code to explain things
- Renamed bunch of functions from popular demands
This patchset improves the HMM driver API and add support for mirroring
virtual address that are mmap of hugetlbf
From: Jérôme Glisse
A common use case for HMM mirror is user trying to mirror a range
and before they could program the hardware it get invalidated by
some core mm event. Instead of having user re-try right away to
mirror the range provide a completion mechanism for them to wait
for any active in
From: Jérôme Glisse
This is a all in one helper that fault pages in a range and map them to
a device so that every single device driver do not have to re-implement
this common pattern.
This is taken from ODP RDMA in preparation of ODP RDMA convertion. It
will be use by nouveau and other drivers.
From: Jérôme Glisse
Users of HMM might be using the snapshot information to do
preparatory step like dma mapping pages to a device before
checking for invalidation through hmm_vma_range_done() so
do not erase that information and assume users will do the
right thing.
Signed-off-by: Jérôme Glisse
From: Jérôme Glisse
Rename for consistency between code, comments and documentation. Also
improves the comments on all the possible returns values. Improve the
function by returning the number of populated entries in pfns array.
Changes since v1:
- updated documentation
- reformated some
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for hugetlbfs mapping (ie range of virtual address tha
From: Jérôme Glisse
The device driver can have kernel thread or worker doing work against
a process mm and it is useful for those to test wether the mm is dead
or alive to avoid doing useless work. Add an helper to test that so
that driver can bail out early if a process is dying.
Note that the
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for mirroring mapping of file that are on a DAX block
From: Jérôme Glisse
Convert hmm_pfn_* to device_entry_* as here we are dealing with device
driver specific entry format and hmm provide helpers to allow differents
components (including HMM) to create/parse device entry.
We keep wrapper with the old name so that we can convert driver to use the
From: Jérôme Glisse
Minor optimization around hmm_pte_need_fault(). Rename for
consistency between code, comments and documentation. Also
improves the comments on all the possible returns values.
Improve the function by returning the number of populated
entries in pfns array.
Changes since v2:
From: Jérôme Glisse
Every time i read the code to check that the HMM structure does not
vanish before it should thanks to the many lock protecting its removal
i get a headache. Switch to reference counting instead it is much
easier to follow and harder to break. This also remove some code that
is
On Tue, Apr 2, 2019 at 3:45 PM Christian Lütke-Stetzkamp
wrote:
> There are two other larger differences that I found during my
> work. One is that drivers/mmc/host/mtk-sd.c has much more features,
> like voltage and clock handling and some support for high speed
> modes. I don't know if these fea
I can certainly add a "did_print_error" flag or some such, but in
practice, if the transfer function is NULL, the initial handshake will
fail, and this will in turn cause EC registration to fail, and no
further communication should occur, so no further log entries will be
printed.
Thanks
Enrico G
On Wed, 3 Apr 2019, Thomas Gleixner wrote:
> On Tue, 2 Apr 2019, Andy Lutomirski wrote:
> > > On Apr 2, 2019, at 1:29 PM, Thomas Gleixner wrote:
> > >>> How about a much better fix: make the DB stack be the same size as all
> > >>> the others and just have 4 of them (DB0, DB1, DB2, and DB3. After
On 03.04.19 01:43, Alexander Duyck wrote:
> On Tue, Apr 2, 2019 at 11:53 AM David Hildenbrand wrote:
>>
> Why do we need them running in parallel for a single guest? I don't
> think we need the hints so quickly that we would need to have multiple
> VCPUs running in parallel to provide
Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") adds
support for BPF programs annotations but the new code does not build on 32-bit.
Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
Signed-off-by: Thadeu Lima de Souza Cascardo
---
tools/perf/util/
On Wed, Apr 3, 2019 at 12:40 PM Enrico Granata wrote:
>
> I can certainly add a "did_print_error" flag or some such, but in practice,
> if the transfer function is NULL, the initial handshake will fail, and this
> will in turn cause EC registration to fail, and no further communication
> should
Because I did not know about it till right now. Thanks for the
suggestion. Will upload a v2 as soon as I get a chance.
On Wed, Apr 3, 2019 at 12:53 PM Guenter Roeck wrote:
>
> On Wed, Apr 3, 2019 at 12:40 PM Enrico Granata wrote:
> >
> > I can certainly add a "did_print_error" flag or some such,
On Tue, Mar 26, 2019 at 2:17 PM Ioana Ciornei wrote:
>
> This patch adds DPAA2 MC and AIOP console log support.
>
> The platform driver probes on the "fsl,dpaa2-console" device tree node
> which describes the base firmware address needed in order to infer the
> start address of both firmware logs:
On Wed, 3 Apr 2019 15:24:26 -0400
Jerome Glisse wrote:
> On Tue, Apr 02, 2019 at 10:15:38AM -0600, Alex Williamson wrote:
> > Memory backed DMA mappings are accounted against a user's locked
> > memory limit, including multiple mappings of the same memory. This
> > accounting bounds the number o
* Sebastian Reichel [190329 05:36]:
> Hi,
>
> On Mon, Mar 25, 2019 at 11:01:18AM -0500, Dan Murphy wrote:
> > On 3/25/19 9:54 AM, Tony Lindgren wrote:
> > > * Dan Murphy [190325 12:36]:
> > >> On 3/22/19 5:16 PM, Tony Lindgren wrote:
> > >>> I can control the backlight brightness just fine via /
pgd_alloc() and pgd_free() are identical on nohash 32 and 64.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/pgalloc.h | 11 ---
arch/powerpc/include/asm/nohash/64/pgalloc.h | 11 ---
arch/powerpc/include/asm/nohash/pgalloc.h| 12
3 files
In the same way as PPC64, implement early allocation functions and
avoid calling pte_alloc_kernel() before slab is available.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/pgtable_32.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/a
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/urgent
head: 60f52ab61c7dc0a991125903ae06a35d1812698c
commit: 6d3edaae16c6c7d238360f2841212c2b26774d5e [4/5] x86/perf/amd: Resolve
NMI latency issues for active PMCs
config: i386-allnoconfig (attached as .config)
compiler:
Currently there is no easy way to get the number of CPUs on the system.
Applications are divided into 2 groups:
One group allocates buffer and call sched_getaffinity(2) once. It works
but either underallocate or overallocates and in the future such application
will become buggy as Linux will start
On Wed, Apr 03, 2019 at 01:37:51PM -0500, Alan Tull wrote:
> >
> > it's state, not status for most fpga manager drivers. It should
> > return 'operating' if everything went well.
Yeah, sorry :)
> > It seems like there's a possible scenario where the FPGA starts up
> > with the FPGA in 'operating
Hi Dan,
Thank you for the patch.
You need Lee Jones on CC for this series.
One more comment below.
On 3/25/19 3:24 PM, Dan Murphy wrote:
The LM3697 is a single function LED driver. The single function LED
driver needs to reside in the LED directory as a dedicated LED driver
and not as a MFD d
Hi Dan,
On 4/3/19 2:02 PM, Dan Murphy wrote:
Hello
On 3/25/19 9:23 AM, Dan Murphy wrote:
All
I know that it has been a long time but I put some additional effort into this
code. The TI LMU common code right now handles brightness and ramp up/down
setting for the LM3697. This so far are the
On Wed, Apr 03, 2019 at 03:20:18PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> If da_tokens are allocated, but dell_smbios_init() eventually fails, it will
> free the da_tokens but it does not reset the da_num_tokens number. This
> leads to the possibility of a use after fr
> >>>Is the core wide lock primarily responsible for the regression? I ran
> >>>upto patch
> >>>12 which also has the core wide lock for tagged cgroups and also calls
> >>>newidle_balance() from pick_next_task(). I don't see any regression.
> >>>Of
> >>>course
> >>>the core sched version of pick_n
Hi Dan,
Thank you for the patch.
On 4/3/19 8:19 PM, Dan Murphy wrote:
Fix misspelling and capitalization of LED in the Kconfig.
Reported-by: Randy Dunlap
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds
Hi Beatriz,
Thank you for the patch, just some small comments.
Regarding the patch title, if you run
git log drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
You will see that commits starts with the following tags "staging:
rtl8723bs: "
Also, try to add a bit more information to the title,
On Wed, Mar 27, 2019 at 09:25:34AM -0500, Mario Limonciello wrote:
> When converting the driver two arguments were transposed leading
> to rfkill not working.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201427
> Reported-by: Pepijn de Vos
> Fixes: 549b49 ("platform/x86: dell-smbios:
Jacek
On 4/3/19 3:10 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> You need Lee Jones on CC for this series.
>
Yes I saw I missed Lee.
> One more comment below.
>
> On 3/25/19 3:24 PM, Dan Murphy wrote:
>> The LM3697 is a single function LED driver. The single functi
On Wed, Apr 03, 2019 at 02:33:23PM +1100, Stephen Rothwell wrote:
> Hi Corey,
>
> After merging the ipmi tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
Paul, any opinions on this? Is just running this in a workqueue
the best idea?
-corey
>
> drivers/char/ipmi/ipmi_ms
On Wed, Apr 03, 2019 at 10:19:44PM +0300, Cyrill Gorcunov wrote:
>
> You know, seems I got what happened -- p4_general_events do
> not cover all general events, they stop at PERF_COUNT_HW_BUS_CYCLES,
> while more 3 general event left. This is 'cause I've not been following
> pmu evolution in code.
The software running on the Chrome OS Embedded Controller (cros_ec)
handles SPI transfers in a bit of a wonky way. Specifically if the EC
sees too long of a delay in a SPI transfer it will give up and the
transfer will be counted as failed. Unfortunately the timeout is
fairly short, though the ac
On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
> This patch series adds the following support to the iProc I2C driver:
> - Increase maximum read transfer size to 255 bytes
> - I2C slave mode
> - Polling mode
> - NIC I2C mode
>
> This patch series is based on kernel v5.1-rc3 and available
Replace bitshifts on lines 54, 56 and 78 of ad7746.c.
Signed-off-by: Lucas Oshiro
---
drivers/staging/iio/cdc/ad7746.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 0eb28fea876e..ea48b14cee72 10
On Mon, Apr 01, 2019 at 01:14:37PM +0300, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> Make sure to free the i2c adapter on the error exit path.
>
> Signed-off-by: Laurentiu Tudor
> Reviewed-by: Mukesh Ojha
> Reviewed-by: Uwe Kleine-Konig
> Fixes: e1ab9a468e3b ("i2c: imx: improv
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
On Wed, Apr 03, 2019 at 08:02:43AM -0700, Randy Dunlap wrote:
> On 4/3/19 1:24 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190402:
> >
>
> on x86_64:
>
> arch/x86/entry/entry_64.o: warning: objtool: .entry.text+0x909: unreachable
> instruction
Your .o file looks odd. I ca
Hi,
On Thu, Mar 28, 2019 at 11:19:45AM +, Adamski, Krzysztof (Nokia -
PL/Wroclaw) wrote:
> Some recent commits to this driver were trying to make sure the TSS
> interrupt is not generated on busy system due to 25ms timer expiring
> between commands. It can still happen, however if STOP comman
On Wed, Apr 3, 2019 at 1:29 PM Andy Shevchenko
wrote:
>
> On Tue, Apr 02, 2019 at 06:02:40PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Apr 2, 2019 at 5:59 PM Andy Shevchenko
> > wrote:
> > >
> > > Since insert_resource() might return an error we don't need
> > > to shadow its error code and wou
Hi Wolfram,
On 4/3/2019 1:44 PM, Wolfram Sang wrote:
> On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
>> This patch series adds the following support to the iProc I2C driver:
>> - Increase maximum read transfer size to 255 bytes
>> - I2C slave mode
>> - Polling mode
>> - NIC I2C mode
>>
On Mon, Apr 01, 2019 at 02:37:19PM -0500, Bjorn Helgaas wrote:
> On Mon, Apr 1, 2019 at 9:08 AM Wolfram Sang wrote:
> >
> >
> > > > From: Bjorn Helgaas
> > > >
> > > > 54fb4a05af0a ("i2c: Check for ACPI resource conflicts") included
> > > > so we could use acpi_check_region(). fd46a0064af1 ("i2
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace code of the following form:
sizeof(*resp) + props_count * sizeof(struct gb_power_supply_props_desc)
with
On Thu, Apr 04, 2019 at 01:43:05AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core/objtool
> head: 64604d54d3115fee89598bfb6d8d2252f8a2d114
> commit: 37686b1353cfc30e127cef811959cdbcd0495d98 [2/25] tracing: Improve "if"
> macro code g
The Chrome OS EC has an updated set of parameters for the host
sleep event command. With the new parameters, the host can indicate
a timeout along with suspend messages. Specifically S0ix suspend
messages are supported now, though the host command format isn't
specific to S0ix. When the EC sees an
Introduce the command and response structures for the second revision
of the host sleep event. These structures are part of a new EC change
that enables detection of failure to enter S0ix. The EC waits a
kernel-specified timeout (or a default amount of time) for the S0_SLP
pin to change, and wakes
Add support in code for the new forms of the host sleep event.
Detects the presence of this version of the command at runtime,
and use whichever form the EC supports. At this time, always
request the default timeout, and only report the failing response
via a WARN_ONCE(). Future versions could acce
On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > Currently we reach inside the list_head. This is a violation of the
> > layer of abstraction provided by the list_head. It makes the code
> > fragile. More impo
On Wed, Apr 03, 2019 at 01:31:37PM -0700, Douglas Anderson wrote:
> The software running on the Chrome OS Embedded Controller (cros_ec)
> handles SPI transfers in a bit of a wonky way. Specifically if the EC
> sees too long of a delay in a SPI transfer it will give up and the
> transfer will be co
Change the iProc I2C driver to use the 'BIT' macro from all '1 << XXX'
bit operations to get rid of compiler warning and improve readability of
the code
Signed-off-by: Ray Jui
---
drivers/i2c/busses/i2c-bcm-iproc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
John identified three files which claim that RT task priorities start at
zero. As far as I understand, 0 is used for DL and has nothing to do
wihich RT priorities as identified by the RT policy.
Correct the comment, valid RT priorities are in the range from 1 to 99.
Reported-by: John Ogness
Sign
Hi,
On Wed, Apr 3, 2019 at 2:04 PM Matthias Kaehlcke wrote:
> > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
>
> nit: the fact that a high priority workqueue is used is an
> implementation detail, since the driver has no function to perform a
> transfer with 'normal'/low prior
Hi, Uladzislau!
The patch looks really good to me! I've tried hard, but didn't find
any serious issues/bugs. Some small nits below.
Thank you for working on it!
BTW, when sending a new iteration, please use "[PATCH vX]" subject prefix,
e.g. [PATCH v3 1/3] mm/vmap: keep track of free blocks for v
On Wed, Apr 03, 2019 at 03:27:29PM -0500, Corey Minyard wrote:
> On Wed, Apr 03, 2019 at 02:33:23PM +1100, Stephen Rothwell wrote:
> > Hi Corey,
> >
> > After merging the ipmi tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> Paul, any opinions on this? Is just runni
On Tue, Apr 02, 2019 at 06:25:31PM +0200, Uladzislau Rezki (Sony) wrote:
> This macro adds some debug code to check that vmap allocations
> are happened in ascending order.
>
> By default this option is set to 0 and not active. It requires
> recompilation of the kernel to activate it. Set to 1, co
On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > Currently we reach inside the list_head. This is a violation of the
> > layer of abstraction provided by the list_head. It makes the code
> > fragile. More impo
On Wed, 2019-04-03 at 13:44 +0100, Will Deacon wrote:
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -4689,8 +4689,7 @@ static void free_zapped_rcu(struct rcu_head *ch)
> > return;
> >
> > raw_local_irq_save(flags);
> > - if (!graph_lock())
> > -
On 2019-04-03, Sebastian Andrzej Siewior wrote:
> John identified three files which claim that RT task priorities start at
> zero. As far as I understand, 0 is used for DL and has nothing to do
> wihich RT priorities as identified by the RT policy.
>
> Correct the comment, valid RT priorities are
On Tue, Apr 02, 2019 at 06:25:30PM +0200, Uladzislau Rezki (Sony) wrote:
> This macro adds some debug code to check that the augment tree
> is maintained correctly, meaning that every node contains valid
> subtree_max_size value.
>
> By default this option is set to 0 and not active. It requires
>
601 - 700 of 957 matches
Mail list logo
