Re: [PATCH v2 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH v2 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH] bsg referencing bus driver module

Any thoughts on this? Can we really drop a reference from a child device (bsg_class_device) to a parent device (Scsi_Host) while the child device is still around at fc_bsg_remove time? If not, please consider a fix with module references. I realized that the previous version of the fix had a

Re: [PATCH] bsg referencing bus driver module

Any thoughts on this? Can we really drop a reference from a child device (bsg_class_device) to a parent device (Scsi_Host) while the child device is still around at fc_bsg_remove time? If not, please consider a fix with module references. I realized that the previous version of the fix had a

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote: > > We have observed a similiar problem with libvirt. As soon as entropy is > provided the boot finishes otherwise it hangs for a long time. > This is not happening with v4.17-rc1 afaict. For libvirt there is at least an easy

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote: > > We have observed a similiar problem with libvirt. As soon as entropy is > provided the boot finishes otherwise it hangs for a long time. > This is not happening with v4.17-rc1 afaict. For libvirt there is at least an easy

[PATCH v1 2/4] pinctrl: tegra20: Provide CDEV1/2 clock muxes

Muxing of pins MCLK1/2 determine the muxing of the corresponding clocks. Make pinctrl driver to provide clock muxes for the CDEV1/2 pingroups, so that main clk-controller driver could get an actual parent clock for the CDEV1/2 clocks. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 4/4] ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20"

Commit 4c9a27a6c66d ("ARM: tegra: Fix ULPI regression on Tegra20") changed "ulpi-link" clock from CDEV2 to PLL_P_OUT4. Turned out that PLL_P_OUT4 is the parent of CDEV2 clock and original clock setup of "ulpi-link" was correct. The reverted patch was fixing USB for one board and broke the other,

[PATCH v1 0/4] Restore ULPI USB on Tegra20

Hello, This series of patches fixes ULPI USB on Tegra20. The original problem was reported by Marcel Ziswiler, he found that "ulpi-link" clock was incorrectly set to CDEV2 instead of PLL_P_OUT4. Marcel made a patch that changed the "ulpi-link" clock to PLL_P_OUT4 and that fixed issue with the USB

[PATCH v1 2/4] pinctrl: tegra20: Provide CDEV1/2 clock muxes

Muxing of pins MCLK1/2 determine the muxing of the corresponding clocks. Make pinctrl driver to provide clock muxes for the CDEV1/2 pingroups, so that main clk-controller driver could get an actual parent clock for the CDEV1/2 clocks. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 4/4] ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20"

Commit 4c9a27a6c66d ("ARM: tegra: Fix ULPI regression on Tegra20") changed "ulpi-link" clock from CDEV2 to PLL_P_OUT4. Turned out that PLL_P_OUT4 is the parent of CDEV2 clock and original clock setup of "ulpi-link" was correct. The reverted patch was fixing USB for one board and broke the other,

[PATCH v1 0/4] Restore ULPI USB on Tegra20

Hello, This series of patches fixes ULPI USB on Tegra20. The original problem was reported by Marcel Ziswiler, he found that "ulpi-link" clock was incorrectly set to CDEV2 instead of PLL_P_OUT4. Marcel made a patch that changed the "ulpi-link" clock to PLL_P_OUT4 and that fixed issue with the USB

[PATCH v1 1/4] clk: tegra20: Add DEV1/DEV2 OSC dividers

CDEV1/CDEV2 clocks could have corresponding oscillator clock divider as a parent. Add these dividers in order to be able to provide that parent option. Signed-off-by: Dmitry Osipenko --- drivers/clk/tegra/clk-tegra20.c | 12 1 file changed, 12 insertions(+) diff

[PATCH v1 3/4] clk: tegra20: Set correct parents for CDEV1/2 clocks

Parents of CDEV1/2 clocks are determined by muxing of the corresponding pins. Pinctrl driver now provides the CDEV1/2 clock muxes and hence CDEV1/2 clocks could have correct parents. Set CDEV1/2 parents to the corresponding muxes to fix the parents. Signed-off-by: Dmitry Osipenko

[PATCH v1 1/4] clk: tegra20: Add DEV1/DEV2 OSC dividers

CDEV1/CDEV2 clocks could have corresponding oscillator clock divider as a parent. Add these dividers in order to be able to provide that parent option. Signed-off-by: Dmitry Osipenko --- drivers/clk/tegra/clk-tegra20.c | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v1 3/4] clk: tegra20: Set correct parents for CDEV1/2 clocks

Parents of CDEV1/2 clocks are determined by muxing of the corresponding pins. Pinctrl driver now provides the CDEV1/2 clock muxes and hence CDEV1/2 clocks could have correct parents. Set CDEV1/2 parents to the corresponding muxes to fix the parents. Signed-off-by: Dmitry Osipenko ---

[RFC PATCH] MAINTAINERS: add davem in NETWORKING DRIVERS

"./scripts/get_maintainer.pl -f" does not actually show us David as the maintainer of drivers/net directories such as team, bonding, phy or dsa. Adding him in an M: entry of NETWORKING DRIVERS fixes this. Signed-off-by: Vivien Didelot --- MAINTAINERS | 1 +

[RFC PATCH] MAINTAINERS: add davem in NETWORKING DRIVERS

"./scripts/get_maintainer.pl -f" does not actually show us David as the maintainer of drivers/net directories such as team, bonding, phy or dsa. Adding him in an M: entry of NETWORKING DRIVERS fixes this. Signed-off-by: Vivien Didelot --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

On Thu, 26 Apr 2018, Geert Uytterhoeven wrote: > > While non-native Linux filesystem support (e.g. affs/isofs/...) could be > handled by FUSE Moving to FUSE is a great divide-and-conquer strategy for those who just want the code to die and don't care about any of the data in that format. If

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

On Thu, 26 Apr 2018, Geert Uytterhoeven wrote: > > While non-native Linux filesystem support (e.g. affs/isofs/...) could be > handled by FUSE Moving to FUSE is a great divide-and-conquer strategy for those who just want the code to die and don't care about any of the data in that format. If

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote: > > Also, regardless of what's hanging on CRNG init, CRNG should be able to init > on its own in a timely > manner without the need for user-provided entropy. Userspace was working fine > before the recent CRNG > kernel changes, so

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote: > > Also, regardless of what's hanging on CRNG init, CRNG should be able to init > on its own in a timely > manner without the need for user-provided entropy. Userspace was working fine > before the recent CRNG > kernel changes, so

[RFC] vfs: skip extra attributes check on removal for symlinks

Linux filesystems cannot set extra file attributes (stx_attributes as per statx(2)) on a symbolic link. To set extra file attributes you issue ioctl(2) with FS_IOC_SETFLAGS, *all* ioctl(2) calls on a symbolic link yield EBADF. This is because ioctl(2) tries to obtain struct fd from the symbolic

[RFC] vfs: skip extra attributes check on removal for symlinks

Linux filesystems cannot set extra file attributes (stx_attributes as per statx(2)) on a symbolic link. To set extra file attributes you issue ioctl(2) with FS_IOC_SETFLAGS, *all* ioctl(2) calls on a symbolic link yield EBADF. This is because ioctl(2) tries to obtain struct fd from the symbolic

[PATCH 1/2] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area.

[PATCH 1/2] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area.

Re: [PATCH] net/mlx5: report persistent netdev stats across ifdown/ifup commands

On Thu, Apr 26, 2018 at 4:30 PM, Saeed Mahameed wrote: > On Thu, Apr 26, 2018 at 3:37 PM, Qing Huang wrote: >> >> >> On 04/26/2018 02:50 PM, Saeed Mahameed wrote: >>> >>> On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote:

Re: [PATCH] net/mlx5: report persistent netdev stats across ifdown/ifup commands

On Thu, Apr 26, 2018 at 4:30 PM, Saeed Mahameed wrote: > On Thu, Apr 26, 2018 at 3:37 PM, Qing Huang wrote: >> >> >> On 04/26/2018 02:50 PM, Saeed Mahameed wrote: >>> >>> On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote: Current stats collecting scheme in mlx5 driver is to

[PATCH 2/2] vmalloc: rename llist field in vmap_area

The vmap_area structure has a field of type struct llist_node, named purge_list and is used when performing lazy purge of the area. Such field is left unused during the actual utilization of the structure. This patch renames the field to a more generic "area_list", to allow for utilization

[PATCH 2/2] vmalloc: rename llist field in vmap_area

The vmap_area structure has a field of type struct llist_node, named purge_list and is used when performing lazy purge of the area. Such field is left unused during the actual utilization of the structure. This patch renames the field to a more generic "area_list", to allow for utilization

[PATCH 0/2] mm: tweaks for improving use of vmap_area

These two patches were written in preparation for the creation of protectable memory, however their use is not limited to pmalloc and can improve the use of virtally contigous memory. The first provides a faster path from struct page to the vm_struct that tracks it. The second patch renames a

[PATCH 0/2] mm: tweaks for improving use of vmap_area

These two patches were written in preparation for the creation of protectable memory, however their use is not limited to pmalloc and can improve the use of virtally contigous memory. The first provides a faster path from struct page to the vm_struct that tracks it. The second patch renames a

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Em Thu, 26 Apr 2018 16:41:56 -0500 "Gustavo A. R. Silva" escreveu: > Hi Mauro, > > On 04/23/2018 02:17 PM, Mauro Carvalho Chehab wrote: > > Em Mon, 23 Apr 2018 14:11:02 -0500 > > > > Thanks, I 'll mark this series as rejected at patchwork.linuxtv.org. > > Please feel

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Em Thu, 26 Apr 2018 16:41:56 -0500 "Gustavo A. R. Silva" escreveu: > Hi Mauro, > > On 04/23/2018 02:17 PM, Mauro Carvalho Chehab wrote: > > Em Mon, 23 Apr 2018 14:11:02 -0500 > > > > Thanks, I 'll mark this series as rejected at patchwork.linuxtv.org. > > Please feel free to resubmit any patch

Re: [v4 1/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Quoting Taniya Das (2018-04-24 05:23:18) > Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These > devices would be used for communicating resource state requests to control > the clocks managed by RPMh. > > Signed-off-by: Amit Nischal > Signed-off-by:

Re: [v4 1/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Quoting Taniya Das (2018-04-24 05:23:18) > Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These > devices would be used for communicating resource state requests to control > the clocks managed by RPMh. > > Signed-off-by: Amit Nischal > Signed-off-by: Taniya Das >

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Re: [v4 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-04-24 05:23:19) > diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c > new file mode 100644 > index 000..907a73f > --- /dev/null > +++ b/drivers/clk/qcom/clk-rpmh.c > @@ -0,0 +1,364 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c)

Re: [v4 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-04-24 05:23:19) > diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c > new file mode 100644 > index 000..907a73f > --- /dev/null > +++ b/drivers/clk/qcom/clk-rpmh.c > @@ -0,0 +1,364 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c)

Re: [PATCH] mmc: meson-gx: add device reset

Jerome Brunet writes: > Trigger the reset line of the mmc controller while probing, if available > The reset should be optional for now, at least until all related DT node > have the reset property > > Signed-off-by: Jerome Brunet Reviewed-by: Kevin

Re: [PATCH] mmc: meson-gx: add device reset

Jerome Brunet writes: > Trigger the reset line of the mmc controller while probing, if available > The reset should be optional for now, at least until all related DT node > have the reset property > > Signed-off-by: Jerome Brunet Reviewed-by: Kevin Hilman

Re: [PATCH] dm/raid1: Remove VLA usage

On Tue, Apr 10, 2018 at 9:43 PM, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this avoids VLAs > in dm-raid1.c by just using the maximum size for the stack arrays. > The nr_mirrors value was already capped at 9, so this makes it a trivial >

Re: [PATCH] dm/raid1: Remove VLA usage

On Tue, Apr 10, 2018 at 9:43 PM, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this avoids VLAs > in dm-raid1.c by just using the maximum size for the stack arrays. > The nr_mirrors value was already capped at 9, so this makes it a trivial > adjustment to the array sizes.

Re: [PATCH] net/mlx5: report persistent netdev stats across ifdown/ifup commands

On Thu, Apr 26, 2018 at 3:37 PM, Qing Huang wrote: > > > On 04/26/2018 02:50 PM, Saeed Mahameed wrote: >> >> On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote: >>> >>> Current stats collecting scheme in mlx5 driver is to periodically fetch >>>

Re: [PATCH] net/mlx5: report persistent netdev stats across ifdown/ifup commands

On Thu, Apr 26, 2018 at 3:37 PM, Qing Huang wrote: > > > On 04/26/2018 02:50 PM, Saeed Mahameed wrote: >> >> On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote: >>> >>> Current stats collecting scheme in mlx5 driver is to periodically fetch >>> aggregated stats from all the active mlx5 software

Re: [PATCH 04/61] bus: simplify getting .drvdata

On 04/19/2018 07:05 AM, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Looks reasonable, would you want to use dev_set_drvdata() while we

Re: [PATCH 04/61] bus: simplify getting .drvdata

On 04/19/2018 07:05 AM, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Looks reasonable, would you want to use dev_set_drvdata() while we are it? That would bring more

[PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

When DMA will be performed to a MIPS32 1004K CPS, the L1-cache for the range needs to be flushed and invalidated first. The code currently takes one of two approaches. 1/ If the range is less than the size of the dcache, then HIT type requests flush/invalidate cache lines for the particular

[PATCH v2] MIPS: c-r4k: fix data corruption related to cache coherence.

When DMA will be performed to a MIPS32 1004K CPS, the L1-cache for the range needs to be flushed and invalidated first. The code currently takes one of two approaches. 1/ If the range is less than the size of the dcache, then HIT type requests flush/invalidate cache lines for the particular

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs wrote: > On 14 March 2018 at 21:08, Thierry Reding wrote: >> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >>> In preparation to enabling -Wvla, remove VLA. In this particular >>> case

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs wrote: > On 14 March 2018 at 21:08, Thierry Reding wrote: >> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >>> In preparation to enabling -Wvla, remove VLA. In this particular >>> case directly use macro

RE: [PATCH 3/5] X86: Hyper-V: Enhanced IPI enlightenment

On Wed, 25 Apr 2018, KY Srinivasan wrote: > > +struct ipi_arg_ex { > + u32 vector; > + u32 reserved; > + struct hv_vpset vp_set; > +}; Again, suggest moving to hyperv-tlfs.h. And the 5.0b version of the TLFS has: u32 vector; u8

RE: [PATCH 3/5] X86: Hyper-V: Enhanced IPI enlightenment

On Wed, 25 Apr 2018, KY Srinivasan wrote: > > +struct ipi_arg_ex { > + u32 vector; > + u32 reserved; > + struct hv_vpset vp_set; > +}; Again, suggest moving to hyperv-tlfs.h. And the 5.0b version of the TLFS has: u32 vector; u8 targetvtl;

Re: [PATCH] drm/bridge: tc358767: fix mode_valid's return type

Hi Luc, Thank you for the patch. On Tuesday, 24 April 2018 16:14:52 EEST Luc Van Oostenryck wrote: > The method struct drm_connector_helper_funcs::mode_valid is defined > as returning an 'enum drm_mode_status' but the driver implementation > for this method uses an 'int' for it. > > Fix this by

Re: [PATCH] drm/bridge: tc358767: fix mode_valid's return type

Hi Luc, Thank you for the patch. On Tuesday, 24 April 2018 16:14:52 EEST Luc Van Oostenryck wrote: > The method struct drm_connector_helper_funcs::mode_valid is defined > as returning an 'enum drm_mode_status' but the driver implementation > for this method uses an 'int' for it. > > Fix this by

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

On 2018-04-27 00:40, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patches. > > On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote: >> Hi! >> >> It was noted by Russel King [1] that bridges (not using components) >> might disappear unexpectedly if the owner of the bridge was

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

On 2018-04-27 00:40, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patches. > > On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote: >> Hi! >> >> It was noted by Russel King [1] that bridges (not using components) >> might disappear unexpectedly if the owner of the bridge was

Re: [PATCH v2 1/2] pinctrl/samsung: Correct EINTG banks order

On Wed, Apr 18, 2018 at 5:47 PM, Krzysztof Kozlowski wrote: > I fixed this, re-wrapped commit for 72-column and applied to my tree. > > Linus, > I'll send them to you in pull request for next release cycle. OK waiting for that. Yours, Linus Walleij

Re: [PATCH v2 1/2] pinctrl/samsung: Correct EINTG banks order

On Wed, Apr 18, 2018 at 5:47 PM, Krzysztof Kozlowski wrote: > I fixed this, re-wrapped commit for 72-column and applied to my tree. > > Linus, > I'll send them to you in pull request for next release cycle. OK waiting for that. Yours, Linus Walleij

Re: [PATCH] gpio: make several const arrays static, shrinks object size

On Wed, Apr 18, 2018 at 7:26 PM, Colin King wrote: > From: Colin Ian King > > Don't populate the const read-only arrays 'port' on the stack but > instead make them static. Makes the object code smaller: > > Before: > textdata bss

Re: [PATCH] gpio: make several const arrays static, shrinks object size

On Wed, Apr 18, 2018 at 7:26 PM, Colin King wrote: > From: Colin Ian King > > Don't populate the const read-only arrays 'port' on the stack but > instead make them static. Makes the object code smaller: > > Before: > textdata bss dechex filename > 85424088 672

[PATCH v3 0/6] Add chrdev and name query support for GLINK

Add support for the GLINK rpmsg transport to register a rpmsg chrdev. This will create the rpmsg_ctrl nodes for userspace clients to open rpmsg epts. Create a label property that will help userspace clients distinguish between the different GLINK links. The rpmsg chrdev allocation is done by

[PATCH v3 4/6] rpmsg: Guard against null endpoint ops in destroy

In RPMSG GLINK the chrdev device will allocate an ept as part of the rpdev creation. This device will not register endpoint ops even though it has an allocated ept. Protect against the case where the device is being destroyed. Signed-off-by: Chris Lew --- Changes since v1:

[PATCH v3 3/6] rpmsg: glink: Use complete_all for open states

The open_req and open_ack completion variables are the state variables to represet a remote channel as open. Use complete_all so there are no races with waiters and using completion_done. Signed-off-by: Chris Lew --- Changes since v1: - New change

[PATCH v3 3/6] rpmsg: glink: Use complete_all for open states

The open_req and open_ack completion variables are the state variables to represet a remote channel as open. Use complete_all so there are no races with waiters and using completion_done. Signed-off-by: Chris Lew --- Changes since v1: - New change drivers/rpmsg/qcom_glink_native.c | 4 ++-- 1

[PATCH v3 0/6] Add chrdev and name query support for GLINK

Add support for the GLINK rpmsg transport to register a rpmsg chrdev. This will create the rpmsg_ctrl nodes for userspace clients to open rpmsg epts. Create a label property that will help userspace clients distinguish between the different GLINK links. The rpmsg chrdev allocation is done by

[PATCH v3 4/6] rpmsg: Guard against null endpoint ops in destroy

In RPMSG GLINK the chrdev device will allocate an ept as part of the rpdev creation. This device will not register endpoint ops even though it has an allocated ept. Protect against the case where the device is being destroyed. Signed-off-by: Chris Lew --- Changes since v1: - New change

[PATCH v3 2/6] rpmsg: glink: Store edge name for glink device

Channels may need to identify the edge their channel was probed for. Store the edge name by reading the label property from device tree or default to the node name. Signed-off-by: Chris Lew --- Changes since v1: - None drivers/rpmsg/qcom_glink_native.c | 6 ++ 1 file

[PATCH v3 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings

There are GLINK clients who open the same channel on multiple GLINK links. These clients need a way to distinguish which remoteproc they are communicating to. Add a label property to identify the edge this node represents. Signed-off-by: Chris Lew --- Changes since v1: -

[PATCH v3 2/6] rpmsg: glink: Store edge name for glink device

Channels may need to identify the edge their channel was probed for. Store the edge name by reading the label property from device tree or default to the node name. Signed-off-by: Chris Lew --- Changes since v1: - None drivers/rpmsg/qcom_glink_native.c | 6 ++ 1 file changed, 6

[PATCH v3 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings

There are GLINK clients who open the same channel on multiple GLINK links. These clients need a way to distinguish which remoteproc they are communicating to. Add a label property to identify the edge this node represents. Signed-off-by: Chris Lew --- Changes since v1: - Add explanation for

[PATCH v3 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Expose the name field as an attr so clients listening to uevents for rpmsg can identify the edge the events correspond to. Signed-off-by: Chris Lew --- Changes since v2: - Remove const on attribute struct Changes since v1: - Add const to attribute struct - Get name from

[PATCH v3 5/6] rpmsg: glink: Add support for rpmsg glink chrdev

RPMSG provides a char device interface to userspace. Probe the rpmsg chrdev channel to enable the rpmsg_ctrl device creation on glink transports. Signed-off-by: Chris Lew --- Changes since v1: - Use qcom_glink_alloc_channel to create the chrdev rpmsg device

[PATCH v3 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Expose the name field as an attr so clients listening to uevents for rpmsg can identify the edge the events correspond to. Signed-off-by: Chris Lew --- Changes since v2: - Remove const on attribute struct Changes since v1: - Add const to attribute struct - Get name from glink channel

[PATCH v3 5/6] rpmsg: glink: Add support for rpmsg glink chrdev

RPMSG provides a char device interface to userspace. Probe the rpmsg chrdev channel to enable the rpmsg_ctrl device creation on glink transports. Signed-off-by: Chris Lew --- Changes since v1: - Use qcom_glink_alloc_channel to create the chrdev rpmsg device drivers/rpmsg/qcom_glink_native.c |

Re: [PATCH v9 7/9] pinctrl: madera: Add DT bindings for Cirrus Logic Madera codecs

On Tue, Apr 17, 2018 at 10:53 AM, Richard Fitzgerald wrote: > What is your opinion of the i.MX6 pinctrl failure after my bugfix patch > for the hogs? Don't know yet. I will answer to that patch, when I get to it. > If you would want to revert my patch I would need

Re: [PATCH v9 7/9] pinctrl: madera: Add DT bindings for Cirrus Logic Madera codecs

On Tue, Apr 17, 2018 at 10:53 AM, Richard Fitzgerald wrote: > What is your opinion of the i.MX6 pinctrl failure after my bugfix patch > for the hogs? Don't know yet. I will answer to that patch, when I get to it. > If you would want to revert my patch I would need to change this pinctrl >

Re: [PATCH 2/2] gpio: pcie-idio-24: Fix port memory offset for get_multiple/set_multiple callbacks

On Wed, Apr 18, 2018 at 2:53 PM, William Breathitt Gray wrote: > The ioread8/iowrite8 functions expect a memory offset argument. This > patch fixes the ports array to provide the memory addresses of the > respective device I/O registers. > > Fixes: ca37081595a2 ("gpio:

Re: [PATCH 2/2] gpio: pcie-idio-24: Fix port memory offset for get_multiple/set_multiple callbacks

On Wed, Apr 18, 2018 at 2:53 PM, William Breathitt Gray wrote: > The ioread8/iowrite8 functions expect a memory offset argument. This > patch fixes the ports array to provide the memory addresses of the > respective device I/O registers. > > Fixes: ca37081595a2 ("gpio: pcie-idio-24: Implement

Re: [PATCH 1/2] gpio: pci-idio-16: Fix port memory offset for get_multiple callback

On Wed, Apr 18, 2018 at 2:53 PM, William Breathitt Gray wrote: > The ioread8 function expects a memory offset argument. This patch fixes > the ports array to provide the memory addresses of the respective device > I/O registers. > > Fixes: 810ebfc5efca ("gpio:

Re: [PATCH 1/2] gpio: pci-idio-16: Fix port memory offset for get_multiple callback

On Wed, Apr 18, 2018 at 2:53 PM, William Breathitt Gray wrote: > The ioread8 function expects a memory offset argument. This patch fixes > the ports array to provide the memory addresses of the respective device > I/O registers. > > Fixes: 810ebfc5efca ("gpio: pci-idio-16: Implement get_multiple

RE: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

Michael, On Thu, 26 Apr 2018, Michael Kelley (EOSG) wrote: > > -Original Message- > > From: k...@linuxonhyperv.com > > Sent: Wednesday, April 25, 2018 11:13 AM > > To: x...@kernel.org; gre...@linuxfoundation.org; > > linux-kernel@vger.kernel.org; > >

RE: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

Michael, On Thu, 26 Apr 2018, Michael Kelley (EOSG) wrote: > > -Original Message- > > From: k...@linuxonhyperv.com > > Sent: Wednesday, April 25, 2018 11:13 AM > > To: x...@kernel.org; gre...@linuxfoundation.org; > > linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org;

RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

> -Original Message- > From: k...@linuxonhyperv.com > Sent: Wednesday, April 25, 2018 11:13 AM > To: x...@kernel.org; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; >

RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

> -Original Message- > From: k...@linuxonhyperv.com > Sent: Wednesday, April 25, 2018 11:13 AM > To: x...@kernel.org; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; > t...@linutronix.de;

Re: [PATCH] pinctrl: mediatek: update pinmux defintions for MT7623

On Mon, Apr 16, 2018 at 4:32 AM, Ryder Lee wrote: > Fulfill the pinmux macros for MT7623 > > Signed-off-by: Ryder Lee Patch applied with Rob's review tag. Yours, Linus Walleij

Re: [PATCH] pinctrl: mediatek: update pinmux defintions for MT7623

On Mon, Apr 16, 2018 at 4:32 AM, Ryder Lee wrote: > Fulfill the pinmux macros for MT7623 > > Signed-off-by: Ryder Lee Patch applied with Rob's review tag. Yours, Linus Walleij

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 05:50:20PM -0400, Mikulas Patocka wrote: > > How is the user or developer supposed to learn about this option, if > > he gets no crash at all? > > Look in /sys/kernel/debug/fail* ? That actually lets you > filter by

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 05:50:20PM -0400, Mikulas Patocka wrote: > > How is the user or developer supposed to learn about this option, if > > he gets no crash at all? > > Look in /sys/kernel/debug/fail* ? That actually lets you > filter by

Re: [PATCH] dt-bindings: pinctrl: mcp23s08: Clarify gpiospec flags cell usage

On Wed, Apr 11, 2018 at 11:42 PM, Ricardo Silva wrote: > The pinctrl-mcp23s08 driver doesn't provide a specific gpiospec > of_xlate() function, causing the gpiolib-of's of_gpio_simple_xlate() > function to be used instead, which takes the gpiospec's second cell as > the

Re: [PATCH] dt-bindings: pinctrl: mcp23s08: Clarify gpiospec flags cell usage

On Wed, Apr 11, 2018 at 11:42 PM, Ricardo Silva wrote: > The pinctrl-mcp23s08 driver doesn't provide a specific gpiospec > of_xlate() function, causing the gpiolib-of's of_gpio_simple_xlate() > function to be used instead, which takes the gpiospec's second cell as > the flags specifier according

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

On Tue, Apr 24, 2018 at 8:40 PM, Richard Guy Briggs wrote: > On 2018-04-24 15:01, Paul Moore wrote: >> On Mon, Apr 23, 2018 at 10:02 PM, Richard Guy Briggs wrote: >> > On 2018-04-23 19:15, Paul Moore wrote: >> >> On Sat, Apr 21, 2018 at 10:34 AM, Richard Guy

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

On Tue, Apr 24, 2018 at 8:40 PM, Richard Guy Briggs wrote: > On 2018-04-24 15:01, Paul Moore wrote: >> On Mon, Apr 23, 2018 at 10:02 PM, Richard Guy Briggs wrote: >> > On 2018-04-23 19:15, Paul Moore wrote: >> >> On Sat, Apr 21, 2018 at 10:34 AM, Richard Guy Briggs >> >> wrote: >> >> > On

Re: [PATCH v2] dt-bindings: gpio: Add support for r8a77965

On Mon, Apr 16, 2018 at 8:55 PM, Jacopo Mondi wrote: > Add compatible string for R-Car M3-N (r8a77965) in gpio-rcar. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Geert Uytterhoeven > Reviewed-by: Simon Horman

Re: [PATCH v2] dt-bindings: gpio: Add support for r8a77965

On Mon, Apr 16, 2018 at 8:55 PM, Jacopo Mondi wrote: > Add compatible string for R-Car M3-N (r8a77965) in gpio-rcar. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Geert Uytterhoeven > Reviewed-by: Simon Horman > Reviewed-by: Rob Herring > --- > > Renesas R-Car M3-N support has been merged

Re: [PATCH] dt-bindings: panel: lvds: Fix path to display timing bindings

Hi Geert, Thank you for the patch. On Wednesday, 25 April 2018 10:49:38 EEST Geert Uytterhoeven wrote: > Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common > panel properties") > Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart

Re: [PATCH] dt-bindings: panel: lvds: Fix path to display timing bindings

Hi Geert, Thank you for the patch. On Wednesday, 25 April 2018 10:49:38 EEST Geert Uytterhoeven wrote: > Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common > panel properties") > Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart > --- >

[PATCH 03/24] drm/bridge/analogix: core: specify the .owner of the bridge

This will become mandatory. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index

[PATCH 03/24] drm/bridge/analogix: core: specify the .owner of the bridge

This will become mandatory. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index

<    1   2   3   4   5   6   7   8   9   10   >