On Mon, Jul 09, 2018 at 06:42:29PM -0400, Boris Ostrovsky wrote:
> On 07/02/2018 12:02 PM, Mark Rutland wrote:
> > On Mon, Jul 02, 2018 at 05:46:55PM +0200, Peter Zijlstra wrote:
> >> On Mon, Jul 02, 2018 at 04:12:50PM +0100, Mark Rutland wrote:
> >>> +static struct pt_regs
On Mon, Jul 09, 2018 at 06:42:29PM -0400, Boris Ostrovsky wrote:
> On 07/02/2018 12:02 PM, Mark Rutland wrote:
> > On Mon, Jul 02, 2018 at 05:46:55PM +0200, Peter Zijlstra wrote:
> >> On Mon, Jul 02, 2018 at 04:12:50PM +0100, Mark Rutland wrote:
> >>> +static struct pt_regs
On Tue, Jul 10, 2018 at 09:44:57PM -0400, Steven Rostedt wrote:
> On Wed, 2 May 2018 10:12:14 +1000
> Nicholas Piggin wrote:
>
> > > I have mixed feelings about this patch, I am Ok with this patch but I
> > > suggest its sent with the follow-up patch that shows its use of this.
> > > And also
To improve page allocator's performance for order-0 pages, each CPU has
a Per-CPU-Pageset(PCP) per zone. Whenever an order-0 page is needed,
PCP will be checked first before asking pages from Buddy. When PCP is
used up, a batch of pages will be fetched from Buddy to improve
performance and the
On Tue, Jul 10, 2018 at 09:44:57PM -0400, Steven Rostedt wrote:
> On Wed, 2 May 2018 10:12:14 +1000
> Nicholas Piggin wrote:
>
> > > I have mixed feelings about this patch, I am Ok with this patch but I
> > > suggest its sent with the follow-up patch that shows its use of this.
> > > And also
To improve page allocator's performance for order-0 pages, each CPU has
a Per-CPU-Pageset(PCP) per zone. Whenever an order-0 page is needed,
PCP will be checked first before asking pages from Buddy. When PCP is
used up, a batch of pages will be fetched from Buddy to improve
performance and the
On Wed, Jul 11, 2018 at 1:13 AM, Mike Marshall wrote:
> Hi...
>
> I applied this patch to 4.18.0-rc4. It applied cleanly and there's no xfstests
> regressions. Sorry if I held you up any...
>
> You can add: Tested-By: Mike Marshall
>
Thanks Mike. Can we get this patch in queue for 4.19 merge
On Wed, Jul 11, 2018 at 1:13 AM, Mike Marshall wrote:
> Hi...
>
> I applied this patch to 4.18.0-rc4. It applied cleanly and there's no xfstests
> regressions. Sorry if I held you up any...
>
> You can add: Tested-By: Mike Marshall
>
Thanks Mike. Can we get this patch in queue for 4.19 merge
Hi Prakash,
On 07/10/2018 09:19 PM, Prakash, Prashanth wrote:
On 7/9/2018 11:42 PM, George Cherian wrote:
Hi Prakash,
On 07/09/2018 10:12 PM, Prakash, Prashanth wrote:
Hi George,
On 7/9/2018 4:10 AM, George Cherian wrote:
Per Section 8.4.7.1.3 of ACPI 6.2, The platform provides
Hi Prakash,
On 07/10/2018 09:19 PM, Prakash, Prashanth wrote:
On 7/9/2018 11:42 PM, George Cherian wrote:
Hi Prakash,
On 07/09/2018 10:12 PM, Prakash, Prashanth wrote:
Hi George,
On 7/9/2018 4:10 AM, George Cherian wrote:
Per Section 8.4.7.1.3 of ACPI 6.2, The platform provides
Hi Stephen,
On 7 July 2018 at 03:55, Stephen Boyd wrote:
> Quoting Joel Stanley (2018-06-28 16:15:40)
>> The HPLL can be configured through a register (SCU24), however some
>> platforms chose to configure it through the strapping settings and do
>> not use the register. This was not noticed as
Hi Stephen,
On 7 July 2018 at 03:55, Stephen Boyd wrote:
> Quoting Joel Stanley (2018-06-28 16:15:40)
>> The HPLL can be configured through a register (SCU24), however some
>> platforms chose to configure it through the strapping settings and do
>> not use the register. This was not noticed as
On Tue, Jul 10, 2018 at 07:06:07PM +0100, Mark Rutland wrote:
> It's possible for userspace to control event_id. Sanitize event_id when
> using it as an array index, to inhibit the potential spectre-v1 write
> gadget.
>
> This class of issue is also known as CVE-2018-3693, or "bounds check bypass
On Tue, Jul 10, 2018 at 07:06:07PM +0100, Mark Rutland wrote:
> It's possible for userspace to control event_id. Sanitize event_id when
> using it as an array index, to inhibit the potential spectre-v1 write
> gadget.
>
> This class of issue is also known as CVE-2018-3693, or "bounds check bypass
On Wed, Jul 04, 2018 at 10:46:41AM +0200, David Sterba wrote:
> On Tue, Jul 03, 2018 at 11:01:02AM +0100, Mark Rutland wrote:
> > In many cases, it would be useful to be able to use the full
> > sanity-checked refcount helpers regardless of CONFIG_REFCOUNT_FULL, as
> > this would help to avoid
On Wed, Jul 04, 2018 at 10:46:41AM +0200, David Sterba wrote:
> On Tue, Jul 03, 2018 at 11:01:02AM +0100, Mark Rutland wrote:
> > In many cases, it would be useful to be able to use the full
> > sanity-checked refcount helpers regardless of CONFIG_REFCOUNT_FULL, as
> > this would help to avoid
Andrew,
there seem to be some renew of interest in 9P lately, so if you'd like I
can take care of rounding these up and prepare a pull request for 4.19
(as we're already well into 4.18 release cycle, I believe most of the
patches can wait)
This patch however I consider important enough to take
Andrew,
there seem to be some renew of interest in 9P lately, so if you'd like I
can take care of rounding these up and prepare a pull request for 4.19
(as we're already well into 4.18 release cycle, I believe most of the
patches can wait)
This patch however I consider important enough to take
On Mon, Jul 2, 2018 at 2:20 PM Jae Hyun Yoo
wrote:
>
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use, if a
On Mon, Jul 2, 2018 at 2:20 PM Jae Hyun Yoo
wrote:
>
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use, if a
On Tue, Jul 03, 2018 at 11:30:38AM -0700, Kees Cook wrote:
> On Tue, Jul 3, 2018 at 3:01 AM, Mark Rutland wrote:
> > In many cases, it would be useful to be able to use the full
> > sanity-checked refcount helpers regardless of CONFIG_REFCOUNT_FULL, as
> > this would help to avoid duplicate
On Tue, Jul 03, 2018 at 11:30:38AM -0700, Kees Cook wrote:
> On Tue, Jul 3, 2018 at 3:01 AM, Mark Rutland wrote:
> > In many cases, it would be useful to be able to use the full
> > sanity-checked refcount helpers regardless of CONFIG_REFCOUNT_FULL, as
> > this would help to avoid duplicate
On Wed, Jul 11, 2018 at 5:21 AM, Al Viro wrote:
[...]
> @@ -3407,8 +3407,6 @@ static int do_last(struct nameidata *nd,
> if (!error && will_truncate)
> error = handle_truncate(file);
> out:
> - if (unlikely(error) && (*opened & FILE_OPENED))
> -
On Wed, Jul 11, 2018 at 5:21 AM, Al Viro wrote:
[...]
> @@ -3407,8 +3407,6 @@ static int do_last(struct nameidata *nd,
> if (!error && will_truncate)
> error = handle_truncate(file);
> out:
> - if (unlikely(error) && (*opened & FILE_OPENED))
> -
On Mon, Jul 2, 2018 at 2:14 PM Jae Hyun Yoo
wrote:
>
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
>
> Signed-off-by: Jae Hyun Yoo
> ---
> drivers/i2c/busses/i2c-aspeed.c | 18 +-
> 1 file changed, 9 insertions(+), 9
On Mon, Jul 2, 2018 at 2:14 PM Jae Hyun Yoo
wrote:
>
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
>
> Signed-off-by: Jae Hyun Yoo
> ---
> drivers/i2c/busses/i2c-aspeed.c | 18 +-
> 1 file changed, 9 insertions(+), 9
> -Original Message-
> From: Vinod [mailto:vk...@kernel.org]
> Sent: 2018年7月10日 23:31
> To: Robin Gong
> Cc: dan.j.willi...@intel.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; Fabio Estevam ;
> li...@armlinux.org.uk; linux-arm-ker...@lists.infradead.org;
> ker...@pengutronix.de;
> -Original Message-
> From: Vinod [mailto:vk...@kernel.org]
> Sent: 2018年7月10日 23:31
> To: Robin Gong
> Cc: dan.j.willi...@intel.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; Fabio Estevam ;
> li...@armlinux.org.uk; linux-arm-ker...@lists.infradead.org;
> ker...@pengutronix.de;
> Hi Robin,
>
> On 11-07-18, 00:23, Robin Gong wrote:
> > Add MEMCPY support, meanwhile, add SDMA_BD_MAX_CNT instead of
> > '0x'.
>
> latter part should be its own patch. Never mix things
Okay, I will split it even for this minor change.
>
> > +static struct dma_async_tx_descriptor
> Hi Robin,
>
> On 11-07-18, 00:23, Robin Gong wrote:
> > Add MEMCPY support, meanwhile, add SDMA_BD_MAX_CNT instead of
> > '0x'.
>
> latter part should be its own patch. Never mix things
Okay, I will split it even for this minor change.
>
> > +static struct dma_async_tx_descriptor
The bmc-misc-ctrl platform driver stitches together the associated
devicetree bindings and the sysfs-devices-platform-field ABI to expose
fields described in the devicetree to userspace via sysfs.
While the userspace interface does not provide an abstraction over the
hardware, it does provide
The AST2500 has VGA scratch registers that are read-only, SuperIO
scratch registers that are a mix of read-only and read-write, and a
graphics DAC mux that must be read or configured in the process of
booting e.g. an OpenPOWER system.
These capabilities do not really have a place in other
Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
provide remote management of (primarily) server platforms. BMCs are
often tightly coupled to the platform in terms of behaviour and provide
many hardware features integral to booting and running the host system.
Some of these
The bmc-misc-ctrl platform driver stitches together the associated
devicetree bindings and the sysfs-devices-platform-field ABI to expose
fields described in the devicetree to userspace via sysfs.
While the userspace interface does not provide an abstraction over the
hardware, it does provide
The AST2500 has VGA scratch registers that are read-only, SuperIO
scratch registers that are a mix of read-only and read-write, and a
graphics DAC mux that must be read or configured in the process of
booting e.g. an OpenPOWER system.
These capabilities do not really have a place in other
Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
provide remote management of (primarily) server platforms. BMCs are
often tightly coupled to the platform in terms of behaviour and provide
many hardware features integral to booting and running the host system.
Some of these
Hello,
This series is a second stab at exposing hardware controls on Baseboard
Management Controllers that are hard to fit into any a coherent abstraction.
The patches introduce new devicetree bindings and sysfs attributes, along with
a platform driver to expose devicetree nodes of the former as
"Fields" expose control of hardware directly to userspace where
appropriate. Examples of expected use are single bit switches or other
small masks of registers where the range of values is entirely policy
driven and the field is not part of a larger, coherent design.
These fields can be from
Hello,
This series is a second stab at exposing hardware controls on Baseboard
Management Controllers that are hard to fit into any a coherent abstraction.
The patches introduce new devicetree bindings and sysfs attributes, along with
a platform driver to expose devicetree nodes of the former as
"Fields" expose control of hardware directly to userspace where
appropriate. Examples of expected use are single bit switches or other
small masks of registers where the range of values is entirely policy
driven and the field is not part of a larger, coherent design.
These fields can be from
On Tue, Jul 10, 2018 at 08:49:58PM -0400, Steven Rostedt wrote:
> On Thu, 28 Jun 2018 11:21:49 -0700
> Joel Fernandes wrote:
>
> > From: "Joel Fernandes (Google)"
> >
> > Here we add unit tests for the preemptoff and irqsoff tracer by using a
> > kernel module introduced previously to trigger
On Tue, Jul 10, 2018 at 08:49:58PM -0400, Steven Rostedt wrote:
> On Thu, 28 Jun 2018 11:21:49 -0700
> Joel Fernandes wrote:
>
> > From: "Joel Fernandes (Google)"
> >
> > Here we add unit tests for the preemptoff and irqsoff tracer by using a
> > kernel module introduced previously to trigger
On Tue, Jul 10, 2018 at 08:47:07PM -0400, Steven Rostedt wrote:
> On Thu, 28 Jun 2018 11:21:48 -0700
> Joel Fernandes wrote:
>
> > From: "Joel Fernandes (Google)"
> >
> > In this patch we introduce a test module for simulating a long atomic
> > section in the kernel which the preemptoff or
On Tue, Jul 10, 2018 at 08:47:07PM -0400, Steven Rostedt wrote:
> On Thu, 28 Jun 2018 11:21:48 -0700
> Joel Fernandes wrote:
>
> > From: "Joel Fernandes (Google)"
> >
> > In this patch we introduce a test module for simulating a long atomic
> > section in the kernel which the preemptoff or
Now that all producers of dev_pagemap instances in the kernel are
properly converted to EXPORT_SYMBOL_GPL, fix up implicit consumers that
interact with dev_pagemap owners via put_page(). To reiterate,
dev_pagemap producers are EXPORT_SYMBOL_GPL because they adopt and
modify core memory management
Now that all producers of dev_pagemap instances in the kernel are
properly converted to EXPORT_SYMBOL_GPL, fix up implicit consumers that
interact with dev_pagemap owners via put_page(). To reiterate,
dev_pagemap producers are EXPORT_SYMBOL_GPL because they adopt and
modify core memory management
The devm_memremap_pages() facility is tightly integrated with the
kernel's memory hotplug functionality. It injects an altmap argument
deep into the architecture specific vmemmap implementation to allow
allocating from specific reserved pages, and it has Linux specific
assumptions about page
devm semantics arrange for resources to be torn down when
device-driver-probe fails or when device-driver-release completes.
Similar to devm_memremap_pages() there is no need to support an explicit
remove operation when the users properly adhere to devm semantics.
Note that devm_kzalloc()
The routines hmm_devmem_add(), and hmm_devmem_add_resource() duplicated
devm_memremap_pages() and are now simple now wrappers around the core
facility to inject a dev_pagemap instance into the global pgmap_radix
and hook page-idle events. The devm_memremap_pages() interface is base
infrastructure
Commit e8d513483300 "memremap: change devm_memremap_pages interface to
use struct dev_pagemap" refactored devm_memremap_pages() to allow a
dev_pagemap instance to be supplied. Passing in a dev_pagemap interface
simplifies the design of pgmap type drivers in that they can rely on
container_of() to
The devm_memremap_pages() facility is tightly integrated with the
kernel's memory hotplug functionality. It injects an altmap argument
deep into the architecture specific vmemmap implementation to allow
allocating from specific reserved pages, and it has Linux specific
assumptions about page
devm semantics arrange for resources to be torn down when
device-driver-probe fails or when device-driver-release completes.
Similar to devm_memremap_pages() there is no need to support an explicit
remove operation when the users properly adhere to devm semantics.
Note that devm_kzalloc()
The routines hmm_devmem_add(), and hmm_devmem_add_resource() duplicated
devm_memremap_pages() and are now simple now wrappers around the core
facility to inject a dev_pagemap instance into the global pgmap_radix
and hook page-idle events. The devm_memremap_pages() interface is base
infrastructure
Commit e8d513483300 "memremap: change devm_memremap_pages interface to
use struct dev_pagemap" refactored devm_memremap_pages() to allow a
dev_pagemap instance to be supplied. Passing in a dev_pagemap interface
simplifies the design of pgmap type drivers in that they can rely on
container_of() to
The last step before devm_memremap_pages() returns success is to
allocate a release action, devm_memremap_pages_release(), to tear the
entire setup down. However, the result from devm_add_action() is not
checked.
Checking the error from devm_add_action() is not enough. The api
currently relies on
In preparation for consolidating all ZONE_DEVICE enabling via
devm_memremap_pages(), teach it how to handle the constraints of
MEMORY_DEVICE_PRIVATE ranges.
Cc: Christoph Hellwig
Cc: "Jérôme Glisse"
Reported-by: Logan Gunthorpe
Reviewed-by: Logan Gunthorpe
Signed-off-by: Dan Williams
---
The last step before devm_memremap_pages() returns success is to
allocate a release action, devm_memremap_pages_release(), to tear the
entire setup down. However, the result from devm_add_action() is not
checked.
Checking the error from devm_add_action() is not enough. The api
currently relies on
In preparation for consolidating all ZONE_DEVICE enabling via
devm_memremap_pages(), teach it how to handle the constraints of
MEMORY_DEVICE_PRIVATE ranges.
Cc: Christoph Hellwig
Cc: "Jérôme Glisse"
Reported-by: Logan Gunthorpe
Reviewed-by: Logan Gunthorpe
Signed-off-by: Dan Williams
---
Given the fact that devm_memremap_pages() requires a percpu_ref that is
torn down by devm_memremap_pages_release() the current support for
mapping RAM is broken.
Support for remapping "System RAM" has been broken since the beginning
and there is no existing user of this this code path, so just
Given the fact that devm_memremap_pages() requires a percpu_ref that is
torn down by devm_memremap_pages_release() the current support for
mapping RAM is broken.
Support for remapping "System RAM" has been broken since the beginning
and there is no existing user of this this code path, so just
Changes since v3 [1]:
* Collect Logan's reviewed-by on patch 3
* Collect John's and Joe's tested-by on patch 8
* Update the changelog for patch 1 and 7 to better explain the
EXPORT_SYMBOL_GPL rationale.
* Update the changelog for patch 2 to clarify that it is a cleanup to
make the following
Changes since v3 [1]:
* Collect Logan's reviewed-by on patch 3
* Collect John's and Joe's tested-by on patch 8
* Update the changelog for patch 1 and 7 to better explain the
EXPORT_SYMBOL_GPL rationale.
* Update the changelog for patch 2 to clarify that it is a cleanup to
make the following
Add support for the Zodiac Inflight Innovations i.MX51-base SCU3 Ethernet
Switch Board (ESB)
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Add support for the Zodiac Inflight Innovations i.MX51-base SCU3 Ethernet
Switch Board (ESB)
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Add DT bindings for regulators implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../bindings/regulator/uniphier-regulator.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644
Add DT bindings for regulators implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
.../bindings/regulator/uniphier-regulator.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644
Initial commit to add support for regulators implemented in UniPhier SoCs.
This supports USB VBUS only.
Signed-off-by: Kunihiko Hayashi
---
drivers/regulator/Kconfig | 8 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/uniphier-regulator.c | 213
This series add new regulator controller support for UniPhier SoCs.
Currently this supports USB3 VBUS controller only. This USB3 VBUS belongs to
USB3 glue layer.
Changes since v2:
- replace functions in regulator_ops with helper ones
Changes since v1:
- dt-bindings: add description of glue layer
Initial commit to add support for regulators implemented in UniPhier SoCs.
This supports USB VBUS only.
Signed-off-by: Kunihiko Hayashi
---
drivers/regulator/Kconfig | 8 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/uniphier-regulator.c | 213
This series add new regulator controller support for UniPhier SoCs.
Currently this supports USB3 VBUS controller only. This USB3 VBUS belongs to
USB3 glue layer.
Changes since v2:
- replace functions in regulator_ops with helper ones
Changes since v1:
- dt-bindings: add description of glue layer
On 11 July 2018 at 06:59, Eddie James wrote:
>
>
> On 07/10/2018 02:39 PM, Wolfram Sang wrote:
>>>
>>> Sorry, what do you mean "show up as"? Yes, we could first shift all our
>>> addresses in user-space before passing them to the driver, so that the
>>> msg->addr field is exactly what the
On 11 July 2018 at 06:59, Eddie James wrote:
>
>
> On 07/10/2018 02:39 PM, Wolfram Sang wrote:
>>>
>>> Sorry, what do you mean "show up as"? Yes, we could first shift all our
>>> addresses in user-space before passing them to the driver, so that the
>>> msg->addr field is exactly what the
Hi Alexei,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1e09177acae32a61586af26d83ca5ef591cdcaf5
commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from
HOSTCC
date: 5 weeks ago
config:
Hi Alexei,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1e09177acae32a61586af26d83ca5ef591cdcaf5
commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from
HOSTCC
date: 5 weeks ago
config:
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/spinlock_types.h:18:0,
from include/linux/spinlock.h:82,
from drivers/scsi/libfc/fc_rport.c:61:
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/spinlock_types.h:18:0,
from include/linux/spinlock.h:82,
from drivers/scsi/libfc/fc_rport.c:61:
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
MAINTAINERS
between commit:
54e45716a84a ("scsi: remove NCR_D700 driver")
from Linus' tree and commit:
01a21986f8ed ("MAINTAINERS: Add Sam as the maintainer for NCSI")
from the scsi-mkp tree.
I fixed it up (see
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
MAINTAINERS
between commit:
54e45716a84a ("scsi: remove NCR_D700 driver")
from Linus' tree and commit:
01a21986f8ed ("MAINTAINERS: Add Sam as the maintainer for NCSI")
from the scsi-mkp tree.
I fixed it up (see
Windows I/O, such as the real-time clock. The address register (port
0x70 in the RTC case) can use coalesced I/O, cutting the number of
userspace exits by half when reading or writing the RTC.
Guest access rtc like this: write register index to 0x70, then write or
read data from 0x71. writing
Windows I/O, such as the real-time clock. The address register (port
0x70 in the RTC case) can use coalesced I/O, cutting the number of
userspace exits by half when reading or writing the RTC.
Guest access rtc like this: write register index to 0x70, then write or
read data from 0x71. writing
Hi Michal
Sorry , I l forget to update the changlog for the second patch, but
the cpuset information is not missing. Do I still need to make the
v14 or just update the changelog for v13?
Thanks
I am on vacation away from an actual keyboard until next week. Will look at it
then.
> Le 10 juill. 2018 à 20:52, Kees Cook a écrit :
>
>> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre
>> wrote:
>> The vt code translates UTF-8 strings into glyph index values and stores
>> those glyph
Hi Michal
Sorry , I l forget to update the changlog for the second patch, but
the cpuset information is not missing. Do I still need to make the
v14 or just update the changelog for v13?
Thanks
I am on vacation away from an actual keyboard until next week. Will look at it
then.
> Le 10 juill. 2018 à 20:52, Kees Cook a écrit :
>
>> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre
>> wrote:
>> The vt code translates UTF-8 strings into glyph index values and stores
>> those glyph
On 5/14/2018 5:12 PM, Bartlomiej Zolnierkiewicz wrote:
OMAP5 sensors don't claim COUNTER feature support (they use
COUNTER_DELAY feature instead) so there is no need to set fields
of struct temp_sensor_registers which are only used for COUNTER
feature.
There should be no functional changes
On 5/14/2018 5:12 PM, Bartlomiej Zolnierkiewicz wrote:
OMAP5 sensors don't claim COUNTER feature support (they use
COUNTER_DELAY feature instead) so there is no need to set fields
of struct temp_sensor_registers which are only used for COUNTER
feature.
There should be no functional changes
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/iommu/ipmmu-vmsa.c
between commits:
0b8ac1409641 ("iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code")
3701c123e1c1 ("iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code")
98dbffd39a65
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/iommu/ipmmu-vmsa.c
between commits:
0b8ac1409641 ("iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code")
3701c123e1c1 ("iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code")
98dbffd39a65
On Tue, Jul 10, 2018 at 7:59 PM Al Viro wrote:
>
> Umm... Something like [..]
Ack.
Linus
On Tue, Jul 10, 2018 at 7:59 PM Al Viro wrote:
>
> Umm... Something like [..]
Ack.
Linus
On Tue, 10 Jul 2018, Eric W. Biederman wrote:
>
> Use the information we already have to document which signals are sent
> to a group of processes and which signals are sent to a single process
> or a single thread.
Ahh.
This is much nicer than what I was playing with yesterday, trying to
On Tue, 10 Jul 2018, Eric W. Biederman wrote:
>
> Use the information we already have to document which signals are sent
> to a group of processes and which signals are sent to a single process
> or a single thread.
Ahh.
This is much nicer than what I was playing with yesterday, trying to
mmc_select_hs400es() calls mmc_select_bus_width() which will continue
to set 4bit transfer mode if fail to set 8bit mode. The bus width
should not be set to 4bit in HS400es.
When fail to set 8bit mode, need return error directly for HS400es.
Signed-off-by: Hongjie Fang
---
mmc_select_hs400es() calls mmc_select_bus_width() which will continue
to set 4bit transfer mode if fail to set 8bit mode. The bus width
should not be set to 4bit in HS400es.
When fail to set 8bit mode, need return error directly for HS400es.
Signed-off-by: Hongjie Fang
---
On Tue, Jul 10, 2018 at 07:44:59PM -0700, Linus Torvalds wrote:
> I like the patch, I hate the commit message.
>
> It makes sense right now in this sequence, but I'd really like the
> commit message to say _why_ this sequence led up to this point.
>
> Right now I still remember you trying this,
On Tue, Jul 10, 2018 at 07:44:59PM -0700, Linus Torvalds wrote:
> I like the patch, I hate the commit message.
>
> It makes sense right now in this sequence, but I'd really like the
> commit message to say _why_ this sequence led up to this point.
>
> Right now I still remember you trying this,
Hi Douglas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on next-20180710]
[cannot apply to v4.18-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Douglas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on next-20180710]
[cannot apply to v4.18-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Ok, you didn't seem to have a coverletter email, so I'm just replying
to the first one.
Apart from the couple of totally trivial things I reacted to, this
looks very clean and nice. And now I sat in front of the computer
while reading it, so I could follow along better.
So apart from the small
Ok, you didn't seem to have a coverletter email, so I'm just replying
to the first one.
Apart from the couple of totally trivial things I reacted to, this
looks very clean and nice. And now I sat in front of the computer
while reading it, so I could follow along better.
So apart from the small
1 - 100 of 1874 matches
Mail list logo
