Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot
spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde
Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines
Vermögens auf eine Reihe von
Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot
spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde
Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines
Vermögens auf eine Reihe von
Andrew Morton writes:
> Dude, lighten up.
This was in response to being asked by a the maintainers of a bot that has
wasted copious quanties of my time to please not waste their time.
To prevent the wasting of time it was requested that when syzbot would
be enabled on linux-next again that it
Andrew Morton writes:
> Dude, lighten up.
This was in response to being asked by a the maintainers of a bot that has
wasted copious quanties of my time to please not waste their time.
To prevent the wasting of time it was requested that when syzbot would
be enabled on linux-next again that it
Hi Boris,
Thanks for the review.
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com;
Hi Boris,
Thanks for the review.
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com;
Sir/Madam,
I have access to very vital information that can be used to move huge amount of
money. I have done my homework very well and i have the machineries in place to
get it done since I am still in active service. If it was possible for me to do
it alone I would not have bothered
Sir/Madam,
I have access to very vital information that can be used to move huge amount of
money. I have done my homework very well and i have the machineries in place to
get it done since I am still in active service. If it was possible for me to do
it alone I would not have bothered
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Friday, August 17, 2018 8:08 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com;
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Friday, August 17, 2018 8:08 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com;
On Fri, 2018-08-17 at 20:15 +0200, Lukas Wunner wrote:
>
> The two steps (enumeration and driver attachment) are protected by
> pci_lock_rescan_remove(). Initially, when a pci_dev is newly allocated
> with kzalloc(), is_added is 0. The transition from 0 to 1 happens while
> under
On Fri, 2018-08-17 at 20:15 +0200, Lukas Wunner wrote:
>
> The two steps (enumeration and driver attachment) are protected by
> pci_lock_rescan_remove(). Initially, when a pci_dev is newly allocated
> with kzalloc(), is_added is 0. The transition from 0 to 1 happens while
> under
On Fri, 2018-08-17 at 11:25 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> > This re-fixes the bug reported by Hari Vyas
> > after my revert of his commit but in a much simpler way.
> >
> > The main issues is that is_added was being set
On Fri, 2018-08-17 at 11:25 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> > This re-fixes the bug reported by Hari Vyas
> > after my revert of his commit but in a much simpler way.
> >
> > The main issues is that is_added was being set
On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
>
> Just to be clear, if I understand correctly, this is a pure revert of
> 44bda4b7d26e and as such
On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
>
> Just to be clear, if I understand correctly, this is a pure revert of
> 44bda4b7d26e and as such
> Plus I'd have expected the problem to have been in mainline too, and
> apparently it's just the 4.4 and 4.9 backports.
There's another problem in 4.17, but not 4.18, see
https://bugzilla.redhat.com/show_bug.cgi?id=1618792
Could be the same or different.
-Andi
>
> Your test-case does have
> Plus I'd have expected the problem to have been in mainline too, and
> apparently it's just the 4.4 and 4.9 backports.
There's another problem in 4.17, but not 4.18, see
https://bugzilla.redhat.com/show_bug.cgi?id=1618792
Could be the same or different.
-Andi
>
> Your test-case does have
This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.
Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.
Link:
This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.
Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.
Link:
Quoting Taniya Das (2018-08-10 18:53:54)
> [v4]
> * Add recalc_clk_ops to calculate the clock frequency reading the current
> perf state, also add CLK_GET_RATE_NOCACHE flag.
> * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
> * cleanup return from function
Quoting Taniya Das (2018-08-10 18:53:54)
> [v4]
> * Add recalc_clk_ops to calculate the clock frequency reading the current
> perf state, also add CLK_GET_RATE_NOCACHE flag.
> * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
> * cleanup return from function
On 8/15/18 11:21 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra wrote:
On 8/15/18 10:02 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides
On 8/15/18 11:21 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra wrote:
On 8/15/18 10:02 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides
On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> - scan = div64_u64(scan * fraction[file],
> - denominator);
> + if (scan > 1)
> + scan = div64_u64(scan * fraction[file],
> +
On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> - scan = div64_u64(scan * fraction[file],
> - denominator);
> + if (scan > 1)
> + scan = div64_u64(scan * fraction[file],
> +
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get:
- a new driver for Rohm BU21029 touch controller
- new bitmap APIs: bitmap_alloc, bitmap_zalloc and bitmap_free
- updates to
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get:
- a new driver for Rohm BU21029 touch controller
- new bitmap APIs: bitmap_alloc, bitmap_zalloc and bitmap_free
- updates to
On Fri, Aug 17, 2018 at 04:47:39PM -0700, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks.
Hi Justin
This is coming from DT? Why do you put 0 width banks in DT in the
first
On Fri, Aug 17, 2018 at 04:47:39PM -0700, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks.
Hi Justin
This is coming from DT? Why do you put 0 width banks in DT in the
first
On 08/17/2018 05:25 PM, Linus Torvalds wrote:
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
[6.689082] RIP: 0010:[] []
On Fri, Aug 17, 2018 at 4:40 PM, Moritz Fischer wrote:
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
> FME")
>
On 08/17/2018 05:25 PM, Linus Torvalds wrote:
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
[6.689082] RIP: 0010:[] []
On Fri, Aug 17, 2018 at 4:40 PM, Moritz Fischer wrote:
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
> FME")
>
Hi,
Looks like I missed the email to read for a patch
(mmots/broken-out/fat-propagate-64-bit-inode-timestamps.patch). Well,
so FWIW,
Acked-by: OGAWA Hirofumi
And additionally cleanup patch here (this would be better to be folded
into his patch).
Thanks.
--
OGAWA Hirofumi
[PATCH] Cleanup
Hi,
Looks like I missed the email to read for a patch
(mmots/broken-out/fat-propagate-64-bit-inode-timestamps.patch). Well,
so FWIW,
Acked-by: OGAWA Hirofumi
And additionally cleanup patch here (this would be better to be folded
into his patch).
Thanks.
--
OGAWA Hirofumi
[PATCH] Cleanup
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
>
> [6.649970] random: crng init done
> [6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
> [6.689082] RIP: 0010:[] []
> page_remove_rmap+0x10/0x230
> [6.689082] RSP:
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
>
> [6.649970] random: crng init done
> [6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
> [6.689082] RIP: 0010:[] []
> page_remove_rmap+0x10/0x230
> [6.689082] RSP:
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
---
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt | 15
Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
---
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
---
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt | 15
Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
---
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports erp for Last Level Cache
Controller (LLCC). This driver takes care of dumping registers and adding
config options to enable and disable panic when the
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. This driver also takes care of dumping registers
and
Currently, boradcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT).
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. This driver also takes care of dumping registers
and
Currently, boradcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT).
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports erp for Last Level Cache
Controller (LLCC). This driver takes care of dumping registers and adding
config options to enable and disable panic when the
On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe wrote:
>
> Would you like a patch to remove that CONFIG option?
I've definitely considered it and would almost certainly just apply a
patch that removed it.
We haven't had this issue for a while (because people stopped using
the deprecated thing),
On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe wrote:
>
> Would you like a patch to remove that CONFIG option?
I've definitely considered it and would almost certainly just apply a
patch that removed it.
We haven't had this issue for a while (because people stopped using
the deprecated thing),
Replace dev_get_drvdata() with platform_get_drvdata() to
match the platform_set_drvdata() in the probe function of
the platform driver.
Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
FME")
Signed-off-by: Moritz Fischer
---
drivers/fpga/dfl-fme-region.c | 2 +-
1 file
Replace dev_get_drvdata() with platform_get_drvdata() to
match the platform_set_drvdata() in the probe function of
the platform driver.
Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
FME")
Signed-off-by: Moritz Fischer
---
drivers/fpga/dfl-fme-region.c | 2 +-
1 file
On 08/17/2018 04:47 PM, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
>
On 08/17/2018 04:47 PM, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
>
From: Justin Chen
Sometimes we have empty banks within the GPIO block. This commit allows
proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
incrementing the bank and number of GPIOs, but not initializing them.
This will mean a call into the non-existent GPIOs will return an
From: Justin Chen
Sometimes we have empty banks within the GPIO block. This commit allows
proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
incrementing the bank and number of GPIOs, but not initializing them.
This will mean a call into the non-existent GPIOs will return an
Dear Friend, My sincere apologies for this unsolicited mail to
you, my name is Barrister Luis Carlos Delgado, theCEO/founder
of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs,
Companiesand individuals on Family Law, Intellectual Property,
Dear Friend, My sincere apologies for this unsolicited mail to
you, my name is Barrister Luis Carlos Delgado, theCEO/founder
of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs,
Companiesand individuals on Family Law, Intellectual Property,
I've noticed, that dying memory cgroups are often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.
My investigation showed that the problem is caused by
applying the LRU pressure balancing
I've noticed, that dying memory cgroups are often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.
My investigation showed that the problem is caused by
applying the LRU pressure balancing
On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:
> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.
Huh? If filesystem wants to create a new instance on each ->mount(),
it can bloody
On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:
> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.
Huh? If filesystem wants to create a new instance on each ->mount(),
it can bloody
The mm-of-the-moment snapshot 2018-08-17-15-48 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-08-17-15-48 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Fri, Aug 17, 2018 at 03:39:07PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>
On Fri, Aug 17, 2018 at 03:39:07PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>
On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> Hi,
>
> the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
Just to confirm, it's not in mainline right? So only in backports?
On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> Hi,
>
> the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
Just to confirm, it's not in mainline right? So only in backports?
Hi,
the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
[6.689082] IP: []
Hi,
the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
[6.689082] IP: []
On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually
On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually
On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> drivers/xen/gntdev.c
>>
>> between commit:
>>
>> 1d3145675538 ("xen/gntdev: Make private
On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> drivers/xen/gntdev.c
>>
>> between commit:
>>
>> 1d3145675538 ("xen/gntdev: Make private
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/hwlock-v4.19
for you to fetch changes up to ddb34f480d1b8051bc18e6ff22e93a6c9a33f94f:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rpmsg-v4.19
for you to fetch changes up to 00b645e0b4e4a3e5f8d88a4e9acf7e80045c34b4:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/hwlock-v4.19
for you to fetch changes up to ddb34f480d1b8051bc18e6ff22e93a6c9a33f94f:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rpmsg-v4.19
for you to fetch changes up to 00b645e0b4e4a3e5f8d88a4e9acf7e80045c34b4:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rproc-v4.19
for you to fetch changes up to b2201ee554a5811f569f31280b0079e7d6177606:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rproc-v4.19
for you to fetch changes up to b2201ee554a5811f569f31280b0079e7d6177606:
On Tue 14 Aug 10:06 PDT 2018, Douglas Anderson wrote:
> Not all regulator consumers call regulator_set_load(). On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a dumb
On Tue 14 Aug 10:06 PDT 2018, Douglas Anderson wrote:
> Not all regulator consumers call regulator_set_load(). On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a dumb
On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
> >
> > We often have merge conflicts with RDMA, how do you prefer to get the
> > PR? I'm actually not very clear on this part of the process.
>
> I generally prefer the
On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
> >
> > We often have merge conflicts with RDMA, how do you prefer to get the
> > PR? I'm actually not very clear on this part of the process.
>
> I generally prefer the
The WaRP7 has one mikroBUS socket on the back to plug click boards.
This patch allows to interact with some of these
i2c modules (EEPROM, RTC and so on).
Signed-off-by: Pierre-Jean Texier
---
arch/arm/boot/dts/imx7s-warp.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git
The WaRP7 has one mikroBUS socket on the back to plug click boards.
This patch allows to interact with some of these
i2c modules (EEPROM, RTC and so on).
Signed-off-by: Pierre-Jean Texier
---
arch/arm/boot/dts/imx7s-warp.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git
From: RaviChandra Sadineni
hi Merek,
Unfortunately I could not get the device to boot even after using the
exynos_defconfig.
Can you please try this patch and see if this fixes the issue. If not can you
enable the
debug logs and send me the logs.
Currently on every resume we check for mkbp
From: RaviChandra Sadineni
hi Merek,
Unfortunately I could not get the device to boot even after using the
exynos_defconfig.
Can you please try this patch and see if this fixes the issue. If not can you
enable the
debug logs and send me the logs.
Currently on every resume we check for mkbp
On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
> wrote:
> >
> > Ok, everything but the max_sge thing was trivial. I just took yours.
>
> Oh, and doing the full test compile, I notice there are new warnings.
>
> That is *NOT* ok.
On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
> wrote:
> >
> > Ok, everything but the max_sge thing was trivial. I just took yours.
>
> Oh, and doing the full test compile, I notice there are new warnings.
>
> That is *NOT* ok.
On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
wrote:
>
> Ok, everything but the max_sge thing was trivial. I just took yours.
Oh, and doing the full test compile, I notice there are new warnings.
That is *NOT* ok.
The whole "x is deprecated" is not a useful warning. If you can't
remove
On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
wrote:
>
> Ok, everything but the max_sge thing was trivial. I just took yours.
Oh, and doing the full test compile, I notice there are new warnings.
That is *NOT* ok.
The whole "x is deprecated" is not a useful warning. If you can't
remove
On August 17, 2018 1:39:35 PM PDT, Andrew Morton
wrote:
>On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
> wrote:
>
>> Appararently, it's possible to have a non-trivial TU include a few
>headers,
>> including linux/build_bug.h, without ending up with linux/types.h. So
>> the 0day bot sent me
On August 17, 2018 1:39:35 PM PDT, Andrew Morton
wrote:
>On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
> wrote:
>
>> Appararently, it's possible to have a non-trivial TU include a few
>headers,
>> including linux/build_bug.h, without ending up with linux/types.h. So
>> the 0day bot sent me
On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
wrote:
> Appararently, it's possible to have a non-trivial TU include a few headers,
> including linux/build_bug.h, without ending up with linux/types.h. So
> the 0day bot sent me
What's a "TU"?
>
> config: um-x86_64_defconfig (attached as
On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
wrote:
> Appararently, it's possible to have a non-trivial TU include a few headers,
> including linux/build_bug.h, without ending up with linux/types.h. So
> the 0day bot sent me
What's a "TU"?
>
> config: um-x86_64_defconfig (attached as
On Fri, 2018-08-17 at 22:16 +0200, Andreas Bosch wrote:
> Added PCI ID for Sunrise Point-H ISH.
>
> Signed-off-by: Andreas Bosch
Acked-by: Srinivas Pandruvada
> ---
> I hope this patch arrives correctly.
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
>
On Fri, 2018-08-17 at 22:16 +0200, Andreas Bosch wrote:
> Added PCI ID for Sunrise Point-H ISH.
>
> Signed-off-by: Andreas Bosch
Acked-by: Srinivas Pandruvada
> ---
> I hope this patch arrives correctly.
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
>
I remember having sent this on Wednesday, but for some reason I don't see it in
your tree or my outbox so I might be crazy. I was planning submitting some
more patches next week anyway, so while I'm OK just rolling these up as well
it'd be slightly easier if we can get these into -rc1 so we can
I remember having sent this on Wednesday, but for some reason I don't see it in
your tree or my outbox so I might be crazy. I was planning submitting some
more patches next week anyway, so while I'm OK just rolling these up as well
it'd be slightly easier if we can get these into -rc1 so we can
1 - 100 of 714 matches
Mail list logo
