Lånetilbud

God dag, Dette er Central Trust Lån Aksjeselskaper tilby lån. Central Trust lån selskaper tilbyr fleksible og rimelige lån til ethvert formål, for å hjelpe deg å nå dine finansielle mål. vi lån med lav rente på 3%. Her er noen viktige trekk ved personlig lån fra midler sirkel utlån selskaper

Lånetilbud

God dag, Dette er Central Trust Lån Aksjeselskaper tilby lån. Central Trust lån selskaper tilbyr fleksible og rimelige lån til ethvert formål, for å hjelpe deg å nå dine finansielle mål. vi lån med lav rente på 3%. Her er noen viktige trekk ved personlig lån fra midler sirkel utlån selskaper

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems for platforms

[v5.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to

[v5.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to

[PATCH] drm: mediatek: add Maintainers entry for Mediatek DRM drivers

Add CK Hu and Philipp Zabel as maintainers for Mediatek DRM drivers. Signed-off-by: CK Hu --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7304d2e..2a04cdc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3973,6

[PATCH] drm: mediatek: add Maintainers entry for Mediatek DRM drivers

Add CK Hu and Philipp Zabel as maintainers for Mediatek DRM drivers. Signed-off-by: CK Hu --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7304d2e..2a04cdc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3973,6 +3973,14 @@ S:

Darlehen bieten jetzt bewerben

Schönen Tag, Wir UK CREDIT LTD KREDITFinanzGesellschaft mit Sitz in Großbritannien durch die Operationen und eine gute Kundenbasis auf der ganzen Welt. Wir bieten Darlehen zu niedrigen Zinssatz von 3%. Liebe Leser werden darauf hingewiesen, dass dieses Angebot ernst gesinnten

Darlehen bieten jetzt bewerben

Schönen Tag, Wir UK CREDIT LTD KREDITFinanzGesellschaft mit Sitz in Großbritannien durch die Operationen und eine gute Kundenbasis auf der ganzen Welt. Wir bieten Darlehen zu niedrigen Zinssatz von 3%. Liebe Leser werden darauf hingewiesen, dass dieses Angebot ernst gesinnten

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

Sean, On 07/14/2016 11:26 PM, Sean Paul wrote: On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote: Alway enable the PSR function for Rockchip analogix_dp driver. If panel don't support PSR, then the core analogix_dp would ignore this setting. Signed-off-by: Yakir Yang

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

Sean, On 07/14/2016 11:26 PM, Sean Paul wrote: On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote: Alway enable the PSR function for Rockchip analogix_dp driver. If panel don't support PSR, then the core analogix_dp would ignore this setting. Signed-off-by: Yakir Yang Reviewed-by:

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

On Wed, Jul 13, 2016 at 01:31:57PM -0700, Sargun Dhillon wrote: > > > On Wed, 13 Jul 2016, Alexei Starovoitov wrote: > > > On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote: > >> Provides BPF programs, attached to kprobes a safe way to write to > >> memory referenced by probes.

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

On Wed, Jul 13, 2016 at 01:31:57PM -0700, Sargun Dhillon wrote: > > > On Wed, 13 Jul 2016, Alexei Starovoitov wrote: > > > On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote: > >> Provides BPF programs, attached to kprobes a safe way to write to > >> memory referenced by probes.

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

into a 4.7-stable release? > > Done. > > The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: > > Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git > tags/stm-for-greg-20160714 Pulled and pushed out. thanks, greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

> Done. > > The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: > > Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git > tags/stm-for-greg-20160714 Pulled and pushed out. thanks, greg k-h

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

Hi Tejun, On Thu, Jun 16, 2016 at 03:39:05PM -0400, Tejun Heo wrote: > On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote: > > Subject: workqueue: Fix setting affinity of unbound worker threads > > From: Peter Zijlstra > > Date: Thu Jun 16 14:38:42 CEST 2016 > >

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

Hi Tejun, On Thu, Jun 16, 2016 at 03:39:05PM -0400, Tejun Heo wrote: > On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote: > > Subject: workqueue: Fix setting affinity of unbound worker threads > > From: Peter Zijlstra > > Date: Thu Jun 16 14:38:42 CEST 2016 > > > > With commit

Re: [PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

On Thu, Jul 14, 2016 at 9:05 PM, Lee, Chun-Yi wrote: > This patch adds logic to treat virtual ramdisk SPA as pmem region, then > ramdisk's /dev/pmem* device can be mounted with iso9660. > > It's useful to work with the httpboot in EFI firmware to pull a remote > ISO file

Re: [PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

On Thu, Jul 14, 2016 at 9:05 PM, Lee, Chun-Yi wrote: > This patch adds logic to treat virtual ramdisk SPA as pmem region, then > ramdisk's /dev/pmem* device can be mounted with iso9660. > > It's useful to work with the httpboot in EFI firmware to pull a remote > ISO file to the local memory

RE: Purpose of pci_remap_iospace

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > 0x0001 //io > > You have not missed anything, you

RE: Purpose of pci_remap_iospace

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > 0x0001 //io > > You have not missed anything, you

[PATCH] usb: ohci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki ---

[PATCH] usb: ohci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki ---

Re: [PATCH v4 4/4] ASoC: samsung: Add machine driver for Exynos5433 based TM2 board

Hi Sylwester, [snip] > +static int tm2_probe(struct platform_device *pdev) > +{ > + struct device *dev = >dev; > + struct snd_soc_card *card = _card; > + struct tm2_machine_priv *priv; > + struct device_node *cpu_dai_node, *codec_dai_node; > + int ret, i; > + > + if

Re: [PATCH v4 4/4] ASoC: samsung: Add machine driver for Exynos5433 based TM2 board

Hi Sylwester, [snip] > +static int tm2_probe(struct platform_device *pdev) > +{ > + struct device *dev = >dev; > + struct snd_soc_card *card = _card; > + struct tm2_machine_priv *priv; > + struct device_node *cpu_dai_node, *codec_dai_node; > + int ret, i; > + > + if

Re: [patch net-next 2/2] devlink: fix trace format string

From: Jiri Pirko Date: Thu, 14 Jul 2016 11:37:29 +0200 > From: Arnd Bergmann > > Including devlink.h on ARM and probably other 32-bit architectures results in > a harmless warning: > > In file included from ../include/trace/define_trace.h:95:0, >

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

From: Jiri Pirko Date: Thu, 14 Jul 2016 11:37:28 +0200 > From: Jiri Pirko > > Turned on that driver->owner which is struct module is not available when > modules are disabled. Better to depend on a driver name which is > always available. > > Reported-by:

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

On 2016年07月14日 21:54, Jason Cooper wrote: Hi Wan Zongshun, On Thu, Jul 14, 2016 at 11:36:53AM +0800, Wan Zongshun wrote: On 2016年07月14日 04:09, Jason Cooper wrote: On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote: This patch is to add irqchip driver support for nuc900 plat,

Re: [patch net-next 2/2] devlink: fix trace format string

From: Jiri Pirko Date: Thu, 14 Jul 2016 11:37:29 +0200 > From: Arnd Bergmann > > Including devlink.h on ARM and probably other 32-bit architectures results in > a harmless warning: > > In file included from ../include/trace/define_trace.h:95:0, > from

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

From: Jiri Pirko Date: Thu, 14 Jul 2016 11:37:28 +0200 > From: Jiri Pirko > > Turned on that driver->owner which is struct module is not available when > modules are disabled. Better to depend on a driver name which is > always available. > > Reported-by: Randy Dunlap > Fixes: e5224f0fe2

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

On 2016年07月14日 21:54, Jason Cooper wrote: Hi Wan Zongshun, On Thu, Jul 14, 2016 at 11:36:53AM +0800, Wan Zongshun wrote: On 2016年07月14日 04:09, Jason Cooper wrote: On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote: This patch is to add irqchip driver support for nuc900 plat,

Re: [PATCH] mlxsw: spectrum_router: Return -ENOENT in case of error

From: Jiri Pirko Date: Thu, 14 Jul 2016 08:28:19 +0200 > Thu, Jul 14, 2016 at 08:18:45AM CEST, christophe.jail...@wanadoo.fr wrote: >>'vr' should be a valid pointer here, so returning 'PTR_ERR(vr)' is wrong. >>Return an explicit error code (-ENOENT) instead. >> > > This is fo

Re: [PATCH] mlxsw: spectrum_router: Return -ENOENT in case of error

From: Jiri Pirko Date: Thu, 14 Jul 2016 08:28:19 +0200 > Thu, Jul 14, 2016 at 08:18:45AM CEST, christophe.jail...@wanadoo.fr wrote: >>'vr' should be a valid pointer here, so returning 'PTR_ERR(vr)' is wrong. >>Return an explicit error code (-ENOENT) instead. >> > > This is fo net-next. > >

linux-next: manual merge of the devicetree tree with the arc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arc/kernel/setup.c between commit: 1ce0b5857f66 ("ARC: fix linux-next build breakage") from the arc tree and commit: 61c78644e7f1 ("arc: Remove unnecessary of_platform_populate with default match table")

linux-next: manual merge of the devicetree tree with the arc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arc/kernel/setup.c between commit: 1ce0b5857f66 ("ARC: fix linux-next build breakage") from the arc tree and commit: 61c78644e7f1 ("arc: Remove unnecessary of_platform_populate with default match table")

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

On Fri, Jul 15, 2016 at 01:01:35AM -0400, Oleg Drokin wrote: > > + } else { > > + iov_iter_kvec(, ITER_KVEC | WRITE, > > + payload_iov, payload_niov, > > + payload_nob + payload_offset); > > + } > > iov_iter_advance(,

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

On Fri, Jul 15, 2016 at 01:01:35AM -0400, Oleg Drokin wrote: > > + } else { > > + iov_iter_kvec(, ITER_KVEC | WRITE, > > + payload_iov, payload_niov, > > + payload_nob + payload_offset); > > + } > > iov_iter_advance(,

Re: [PATCH] KVM: release anon file in failure path of vm creation

On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote: > If there is no such thread (who operates the descriptor based on > guessing), i can think the changing is safe at the point. As the fd has > not been delivered to userspace. Am i right? Expecting nice behaviour from userland code is

Re: [PATCH] KVM: release anon file in failure path of vm creation

On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote: > If there is no such thread (who operates the descriptor based on > guessing), i can think the changing is safe at the point. As the fd has > not been delivered to userspace. Am i right? Expecting nice behaviour from userland code is

[PATCH V2] usb: ehci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki

[PATCH V2] usb: ehci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki Acked-by: Alan Stern ---

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

On Jul 11, 2016, at 1:18 PM, James Simmons wrote: > With the move to iov_iter handling two issues merged > for the ko2iblnd driver. The first fix address a simple > typo of the wrong flag being used with iov_iter_kvec. > The second fix adds the payload offset to the payload > size. > >

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

On Jul 11, 2016, at 1:18 PM, James Simmons wrote: > With the move to iov_iter handling two issues merged > for the ko2iblnd driver. The first fix address a simple > typo of the wrong flag being used with iov_iter_kvec. > The second fix adds the payload offset to the payload > size. > >

Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Thu, Jul 14, 2016 at 09:46:14AM +0300, Netanel Belgazal wrote: > This is a driver for the ENA family of networking devices. > > Signed-off-by: Netanel Belgazal > --- > > Notes: ... > - Increase driver version to 1.0.2 ... > +static void

Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Thu, Jul 14, 2016 at 09:46:14AM +0300, Netanel Belgazal wrote: > This is a driver for the ENA family of networking devices. > > Signed-off-by: Netanel Belgazal > --- > > Notes: ... > - Increase driver version to 1.0.2 ... > +static void ena_get_drvinfo(struct net_device *dev, > +

Re: [PATCH] powernv: Use __printf in pe_level_printk

On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote: > Joe Perches writes: > > > > > Make the compiler detect format and argument mismatches. > > > > Signed-off-by: Joe Perches > > --- > >  arch/powerpc/platforms/powernv/pci.h | 1 + > >  1 file

Re: [PATCH] powernv: Use __printf in pe_level_printk

On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote: > Joe Perches writes: > > > > > Make the compiler detect format and argument mismatches. > > > > Signed-off-by: Joe Perches > > --- > >  arch/powerpc/platforms/powernv/pci.h | 1 + > >  1 file changed, 1 insertion(+) > > > > diff

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> >

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > +((unsigned long)end & (unsigned

[PATCH] mm: show node_pages_scanned per node, not zone

The node_pages_scanned represents the number of scanned pages of node for reclaim so it's pointless to show it as kilobytes. As well, node_pages_scanned is per-node value, not per-zone. This patch changes node_pages_scannerd per-zone-killobytes with per-node-count. Signed-off-by: Minchan Kim

[PATCH] mm: show node_pages_scanned per node, not zone

The node_pages_scanned represents the number of scanned pages of node for reclaim so it's pointless to show it as kilobytes. As well, node_pages_scanned is per-node value, not per-zone. This patch changes node_pages_scannerd per-zone-killobytes with per-node-count. Signed-off-by: Minchan Kim

[git pull] drm vmware fixes.

Hi Linus, These are some fixes for the vmware graphics driver, that fix some black screen issues on at least Ubuntu 16.04, I think VMware would like to get these in so stable can pick them up ASAP. It's up to you if you aren't comfortable with them at this stage. Dave. The following changes

[git pull] drm vmware fixes.

Hi Linus, These are some fixes for the vmware graphics driver, that fix some black screen issues on at least Ubuntu 16.04, I think VMware would like to get these in so stable can pick them up ASAP. It's up to you if you aren't comfortable with them at this stage. Dave. The following changes

[git pull] drm fixes

Hi Linus, These are just some i915 and amdgpu fixes that shows up, the amdgpu ones are polaris fixes, and i915 is one major regression fix. I've got some vmwgfx fixes that might be a bit large for this time, but I'll send them on in a separate pull so it can be decided. DAve. The following

[git pull] drm fixes

Hi Linus, These are just some i915 and amdgpu fixes that shows up, the amdgpu ones are polaris fixes, and i915 is one major regression fix. I've got some vmwgfx fixes that might be a bit large for this time, but I'll send them on in a separate pull so it can be decided. DAve. The following

linux-next: manual merge of the block tree with the ext4 tree

Hi all, Today's linux-next merge of the block tree got a conflict in: fs/ext4/crypto.c between commit: a7550b30ab70 ("ext4 crypto: migrate into vfs's crypto engine") from the ext4 tree and commits: 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio") 60a40096a3b2

linux-next: manual merge of the block tree with the ext4 tree

Hi all, Today's linux-next merge of the block tree got a conflict in: fs/ext4/crypto.c between commit: a7550b30ab70 ("ext4 crypto: migrate into vfs's crypto engine") from the ext4 tree and commits: 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio") 60a40096a3b2

Re: linux-next: build failure after merge of the drm tree

On 7/15/16, Stephen Rothwell wrote: > Hi Dave, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: > drivers/gpu/drm/i915/intel_opregion.c: In function >

Re: linux-next: build failure after merge of the drm tree

On 7/15/16, Stephen Rothwell wrote: > Hi Dave, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: > drivers/gpu/drm/i915/intel_opregion.c: In function >

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

On Thu, Jul 14, 2016 at 7:05 PM, Balbir Singh wrote: > On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote: >> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the >> SLUB allocator to catch any copies that may span objects. Includes a >> redzone

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

On Thu, Jul 14, 2016 at 7:05 PM, Balbir Singh wrote: > On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote: >> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the >> SLUB allocator to catch any copies that may span objects. Includes a >> redzone handling fix from Michael

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Thu, Jul 14, 2016 at 01:23:23PM -0700, Andrew Morton wrote: > Which changes current kernel behaviour. Can we please get some > discussion into this changelog which justifies that decision? What's > the reasoning and how do we know it won't break existing stuff? What Rostedt said and in

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Thu, Jul 14, 2016 at 01:23:23PM -0700, Andrew Morton wrote: > Which changes current kernel behaviour. Can we please get some > discussion into this changelog which justifies that decision? What's > the reasoning and how do we know it won't break existing stuff? What Rostedt said and in

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 4:20 PM, Balbir Singh wrote: > On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote: >> [...] >> +++ b/mm/usercopy.c >> @@ -0,0 +1,219 @@ >> [...] >> +/* >> + * Checks if a given pointer and length is contained by the current >> + * stack frame

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 4:20 PM, Balbir Singh wrote: > On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote: >> [...] >> +++ b/mm/usercopy.c >> @@ -0,0 +1,219 @@ >> [...] >> +/* >> + * Checks if a given pointer and length is contained by the current >> + * stack frame (if possible). >> + *

Re: mmc: dwmmc: exynos: Warn if HS400 is being used on non-Exynos5420 chipset

Hi Krzysztof, On 07/14/2016 06:52 PM, Krzysztof Kozlowski wrote: Chipsets before Exynos5420 did not support HS400 so if MMC core tries to configure HS400 timing, this might or might not work. Warn in such cases because this is DTB misconfiguration. Signed-off-by: Krzysztof Kozlowski

Re: mmc: dwmmc: exynos: Warn if HS400 is being used on non-Exynos5420 chipset

Hi Krzysztof, On 07/14/2016 06:52 PM, Krzysztof Kozlowski wrote: Chipsets before Exynos5420 did not support HS400 so if MMC core tries to configure HS400 timing, this might or might not work. Warn in such cases because this is DTB misconfiguration. Signed-off-by: Krzysztof Kozlowski ---

Re: [PATCH v2 02/30] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

On Wed, Jul 13, 2016 at 9:05 AM, Benjamin Tissoires wrote: > The type is never set but we check for it in wacom_wireless_irq(). Type was assigned in wacom_wireless_work [1] before we moved code around. It somehow failed to get into wacom_parse_and_register. The

Re: [PATCH v2 02/30] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

On Wed, Jul 13, 2016 at 9:05 AM, Benjamin Tissoires wrote: > The type is never set but we check for it in wacom_wireless_irq(). Type was assigned in wacom_wireless_work [1] before we moved code around. It somehow failed to get into wacom_parse_and_register. The value was only assigned once on

[PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

This patch adds logic to treat virtual ramdisk SPA as pmem region, then ramdisk's /dev/pmem* device can be mounted with iso9660. It's useful to work with the httpboot in EFI firmware to pull a remote ISO file to the local memory region for booting and installation. Wiki page of UEFI HTTPBoot

[PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

This patch adds logic to treat virtual ramdisk SPA as pmem region, then ramdisk's /dev/pmem* device can be mounted with iso9660. It's useful to work with the httpboot in EFI firmware to pull a remote ISO file to the local memory region for booting and installation. Wiki page of UEFI HTTPBoot

Re: [PATCH 1/2] tpm: devicetree: document properties for cr50

On Thu, Jul 14, 2016 at 7:20 PM, Andrey Pronin wrote: > Add TPM2.0-compatible interface to Cr50. Document its properties > in devicetree. > > Signed-off-by: Andrey Pronin > --- > .../devicetree/bindings/security/tpm/cr50_spi.txt | 30 >

Re: [PATCH 1/2] tpm: devicetree: document properties for cr50

On Thu, Jul 14, 2016 at 7:20 PM, Andrey Pronin wrote: > Add TPM2.0-compatible interface to Cr50. Document its properties > in devicetree. > > Signed-off-by: Andrey Pronin > --- > .../devicetree/bindings/security/tpm/cr50_spi.txt | 30 > ++ > 1 file changed, 30

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: > On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >> >> > > == >> > > +((unsigned long)end & (unsigned >> > > long)PAGE_MASK))) >> > > +

Re: [PATCH v2 02/11] mm: Hardened usercopy

On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: > On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >> >> > > == >> > > +((unsigned long)end & (unsigned >> > > long)PAGE_MASK))) >> > > + return NULL; >>

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

Hi Andrew, thanks for taking a look. On Thu, Jul 14, 2016 at 01:29:36PM -0700, Andrew Morton wrote: > Why? What's driving this? What are the benefits to our users? Are > there any downsides or back-compatibility issues? > > I see from the code that this is not actually enabled by default.

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

Hi Andrew, thanks for taking a look. On Thu, Jul 14, 2016 at 01:29:36PM -0700, Andrew Morton wrote: > Why? What's driving this? What are the benefits to our users? Are > there any downsides or back-compatibility issues? > > I see from the code that this is not actually enabled by default.

Re: [PATCH 1/2] tpm_tis_core: add optional max xfer size check

On Thu, Jul 14, 2016 at 8:25 PM, Andrey Pronin wrote: > On Thu, Jul 14, 2016 at 09:13:51PM -0600, Jason Gunthorpe wrote: >> On Thu, Jul 14, 2016 at 06:39:04PM -0700, Andrey Pronin wrote: >> >> > +static inline u16 tpm_tis_max_xfer_size(struct tpm_tis_data *data) >> > +{ >> >

Re: [PATCH 1/2] tpm_tis_core: add optional max xfer size check

On Thu, Jul 14, 2016 at 8:25 PM, Andrey Pronin wrote: > On Thu, Jul 14, 2016 at 09:13:51PM -0600, Jason Gunthorpe wrote: >> On Thu, Jul 14, 2016 at 06:39:04PM -0700, Andrey Pronin wrote: >> >> > +static inline u16 tpm_tis_max_xfer_size(struct tpm_tis_data *data) >> > +{ >> > + return

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 09:32:36PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote: > > > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 > > *result) > > +{ > > + int rc; > > + > > + rc = data->phy_ops->read_bytes(data,

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 09:32:36PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote: > > > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 > > *result) > > +{ > > + int rc; > > + > > + rc = data->phy_ops->read_bytes(data,

Re: [PATCH 2/2] tpm: support driver-specific sysfs attrs in tpm_tis_core

On Thu, Jul 14, 2016 at 09:23:27PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 06:51:36PM -0700, Andrey Pronin wrote: > > - WARN_ON(chip->groups_cnt != 0); > > Nope. > > > - const struct attribute_group *groups[3]; > > + /* up to 4 attribute groups: > > +* - driver-specific

Re: [PATCH 2/2] tpm: support driver-specific sysfs attrs in tpm_tis_core

On Thu, Jul 14, 2016 at 09:23:27PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 06:51:36PM -0700, Andrey Pronin wrote: > > - WARN_ON(chip->groups_cnt != 0); > > Nope. > > > - const struct attribute_group *groups[3]; > > + /* up to 4 attribute groups: > > +* - driver-specific

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

On Thu, Jul 14, 2016 at 08:32:01PM -0700, Andrey Pronin wrote: > tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still > just add those separately for tpm2 to groups[1] and keep groups[0] empty? I think so. Since the file never exists for tpm2, nothing coded for tpm2 will ever

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

On Thu, Jul 14, 2016 at 08:32:01PM -0700, Andrey Pronin wrote: > tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still > just add those separately for tpm2 to groups[1] and keep groups[0] empty? I think so. Since the file never exists for tpm2, nothing coded for tpm2 will ever

[PATCH] staging/lustre/llite: Close atomic_open race with several openers

Right now, if it's an open of a negative dentry, a race is possible with several openers who all try to instantiate/rehash the same dentry and would hit a BUG_ON in d_add. But in fact if we got a negative dentry in atomic_open, that means we just revalidated it so no point in talking to MDS at

linux-next: build failure after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_get_panel_type':

[PATCH] staging/lustre/llite: Close atomic_open race with several openers

Right now, if it's an open of a negative dentry, a race is possible with several openers who all try to instantiate/rehash the same dentry and would hit a BUG_ON in d_add. But in fact if we got a negative dentry in atomic_open, that means we just revalidated it so no point in talking to MDS at

linux-next: build failure after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_get_panel_type':

Re: [PATCH 2/2] tpm: fix byte-order for the value read by tpm2_get_tpm_pt

On Thu, Jul 14, 2016 at 08:17:01PM -0700, Andrey Pronin wrote: > conversion. The only place tpm2_get_tpm_pt() was used before was in > tpm2_gen_interrupt, which discarded the result. So, nobody noticed, > I guess. If you have a moment can you run sparse on this file before/after this change and

Re: [PATCH 2/2] tpm: fix byte-order for the value read by tpm2_get_tpm_pt

On Thu, Jul 14, 2016 at 08:17:01PM -0700, Andrey Pronin wrote: > conversion. The only place tpm2_get_tpm_pt() was used before was in > tpm2_gen_interrupt, which discarded the result. So, nobody noticed, > I guess. If you have a moment can you run sparse on this file before/after this change and

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote: > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result) > +{ > + int rc; > + > + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result); > + if (!rc) > + *result =

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote: > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result) > +{ > + int rc; > + > + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result); > + if (!rc) > + *result =

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

On Thu, Jul 14, 2016 at 09:21:45PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 06:51:35PM -0700, Andrey Pronin wrote: > > - sysfs_remove_link(>dev.parent->kobj, "ppi"); > > - > > - for (i = chip->groups[0]->attrs; *i != NULL; ++i) > > -

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

On Thu, Jul 14, 2016 at 09:21:45PM -0600, Jason Gunthorpe wrote: > On Thu, Jul 14, 2016 at 06:51:35PM -0700, Andrey Pronin wrote: > > - sysfs_remove_link(>dev.parent->kobj, "ppi"); > > - > > - for (i = chip->groups[0]->attrs; *i != NULL; ++i) > > -

Re: [PATCH 0/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 07:50:26PM -0700, Andrey Pronin wrote: > Yes, it has a TCG-compliant interface, however, there are several things > specific to this device: > - need to ensure a certain delay between spi transactions, or else >the chip can miss several first bytes. > - if there is no

Re: [PATCH 0/2] tpm: add driver for cr50 on SPI

On Thu, Jul 14, 2016 at 07:50:26PM -0700, Andrey Pronin wrote: > Yes, it has a TCG-compliant interface, however, there are several things > specific to this device: > - need to ensure a certain delay between spi transactions, or else >the chip can miss several first bytes. > - if there is no

Re: ARM: dts: exynos: Properly select eMMC HighSpeed mode

Hi Krzysztof, On 07/14/2016 06:17 PM, Krzysztof Kozlowski wrote: Exynos5410 supports eMMC version 4.41 so HS200 is the top mode which should be configured. This is reflected in usage of "samsung,exynos5250-dw-mshc" compatible. However DTS contained also property "mmc-hs400-1_8v" which is

Re: ARM: dts: exynos: Properly select eMMC HighSpeed mode

Hi Krzysztof, On 07/14/2016 06:17 PM, Krzysztof Kozlowski wrote: Exynos5410 supports eMMC version 4.41 so HS200 is the top mode which should be configured. This is reflected in usage of "samsung,exynos5250-dw-mshc" compatible. However DTS contained also property "mmc-hs400-1_8v" which is

  1   2   3   4   5   6   7   8   9   10   >