On Thu, Jun 14, 2018 at 7:10 PM Jin Yao wrote:
>
> When doing sampling, for example:
>
> perf record -e cycles:u ...
>
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
>
> This might be a security issue because
On Thu, Jun 14, 2018 at 7:10 PM Jin Yao wrote:
>
> When doing sampling, for example:
>
> perf record -e cycles:u ...
>
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
>
> This might be a security issue because
On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> > On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>
> >> I hate it, but... consider path_open() objections withdrawn for now.
>
> Is that an ACK for the pull if I follow
On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> > On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>
> >> I hate it, but... consider path_open() objections withdrawn for now.
>
> Is that an ACK for the pull if I follow
On 15/06/18 00:32, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Xen PV domain is not by design affected by meltdown as it's enforcing
> split CR3 itself. Let's not report such systems as "Vulnerable" in sysfs
> (we're also already forcing PTI to off in X86_HYPER_XEN_PV cases)
>
>
On 15/06/18 00:32, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Xen PV domain is not by design affected by meltdown as it's enforcing
> split CR3 itself. Let's not report such systems as "Vulnerable" in sysfs
> (we're also already forcing PTI to off in X86_HYPER_XEN_PV cases)
>
>
On 6/13/2018 4:55 AM, Stephen Boyd wrote:
Quoting Vijay Viswanath (2018-05-29 02:52:41)
@@ -137,6 +125,12 @@
/* Timeout value to avoid infinite waiting for pwr_irq */
#define MSM_PWR_IRQ_TIMEOUT_MS 5000
+#define MSM_HOST_READL(msm_host, host, offset) \
+
On 6/13/2018 4:55 AM, Stephen Boyd wrote:
Quoting Vijay Viswanath (2018-05-29 02:52:41)
@@ -137,6 +125,12 @@
/* Timeout value to avoid infinite waiting for pwr_irq */
#define MSM_PWR_IRQ_TIMEOUT_MS 5000
+#define MSM_HOST_READL(msm_host, host, offset) \
+
Hi Linus,
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git
tags/modules-for-v4.18
for you to fetch changes
Hi Linus,
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git
tags/modules-for-v4.18
for you to fetch changes
> -Original Message-
> From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org] On
> Behalf Of 'Greg Kroah-Hartman'
> Sent: Friday, June 15, 2018 1:56 PM
> To: Daniel Sangorrin
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 'Andy Lutomirski'
> ; 'Rik van Riel'
> -Original Message-
> From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org] On
> Behalf Of 'Greg Kroah-Hartman'
> Sent: Friday, June 15, 2018 1:56 PM
> To: Daniel Sangorrin
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 'Andy Lutomirski'
> ; 'Rik van Riel'
On Thu, Jun 14, 2018 at 04:31:26PM -0600, Shuah Khan wrote:
> On 06/14/2018 08:03 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.2 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Thu, Jun 14, 2018 at 04:31:26PM -0600, Shuah Khan wrote:
> On 06/14/2018 08:03 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.2 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, Jun 15, 2018 at 06:15:48AM +0530, Naresh Kamboju wrote:
> On 14 June 2018 at 19:33, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.17.2 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one. If anyone
On Fri, Jun 15, 2018 at 06:15:48AM +0530, Naresh Kamboju wrote:
> On 14 June 2018 at 19:33, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.17.2 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one. If anyone
On 6/15/2018 11:35 AM, Kyle Huey wrote:
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually
On 6/15/2018 11:35 AM, Kyle Huey wrote:
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually
On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote:
This would allow registering various TLS data structures with a single
system call without hindering flexibility on the user-space side. For
instance, we could still use initial-exec and the __rseq_abi symbol for
rseq with this approach.
Thoughts
On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote:
This would allow registering various TLS data structures with a single
system call without hindering flexibility on the user-space side. For
instance, we could still use initial-exec and the __rseq_abi symbol for
rseq with this approach.
Thoughts
On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote:
Another alternative would be to somehow let glibc handle the registration,
perhaps only doing it for applications expressing their interest for rseq.
That's not really possible. We can't rely on the visibility of symbol
bindings due to lazy
On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote:
Another alternative would be to somehow let glibc handle the registration,
perhaps only doing it for applications expressing their interest for rseq.
That's not really possible. We can't rely on the visibility of symbol
bindings due to lazy
* Nishanth Menon [180614 13:07]:
> On 12:38-20180614, Tony Lindgren wrote:
> > Some comments on the ranges below.
>
> Thanks for reviewing in detail (I understand we are in the middle of
> merge window, so thanks for the extra effort).
>
> >
> > * Nishanth Me
* Nishanth Menon [180614 13:07]:
> On 12:38-20180614, Tony Lindgren wrote:
> > Some comments on the ranges below.
>
> Thanks for reviewing in detail (I understand we are in the middle of
> merge window, so thanks for the extra effort).
>
> >
> > * Nishanth Me
On 06/14/2018 02:27 PM, Pavel Machek wrote:
Should we treat it the same way? Always allocate it for each new thread
and register it with the kernel?
That would be an efficient way to do it, indeed. There is very little
performance overhead to have rseq registered for all threads, whether or
On 06/14/2018 02:27 PM, Pavel Machek wrote:
Should we treat it the same way? Always allocate it for each new thread
and register it with the kernel?
That would be an efficient way to do it, indeed. There is very little
performance overhead to have rseq registered for all threads, whether or
Hi Stephen,
On 6/13/2018 5:06 AM, Stephen Boyd wrote:
Quoting Vijay Viswanath (2018-05-29 02:52:39)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 4050c99..2a66aa0 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -226,6 +226,24 @@
Hi Stephen,
On 6/13/2018 5:06 AM, Stephen Boyd wrote:
Quoting Vijay Viswanath (2018-05-29 02:52:39)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 4050c99..2a66aa0 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -226,6 +226,24 @@
On Fri, Jun 15, 2018 at 01:24:27PM +0900, Daniel Sangorrin wrote:
> Hi Greg,
>
> > /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
> > --- a/arch/x86/include/asm/fpu/internal.h
> > +++ b/arch/x86/include/asm/fpu/internal.h
> > @@ -58,7 +58,7 @@ extern u64
On Fri, Jun 15, 2018 at 01:24:27PM +0900, Daniel Sangorrin wrote:
> Hi Greg,
>
> > /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
> > --- a/arch/x86/include/asm/fpu/internal.h
> > +++ b/arch/x86/include/asm/fpu/internal.h
> > @@ -58,7 +58,7 @@ extern u64
Greetings,
We are contracted probate researchers. This is an investigation about a late
client with whom you share the same surname; your assistance will be greatly
appreciated. Are you aware of any investment made by such a person with us?
Please clarify,
EmaiL Reply to :
Greetings,
We are contracted probate researchers. This is an investigation about a late
client with whom you share the same surname; your assistance will be greatly
appreciated. Are you aware of any investment made by such a person with us?
Please clarify,
EmaiL Reply to :
Hi all,
Note: please do *not* add any v4.19 material to your linux-next included
branches until after v4.18-rc1 has been released.
Changes since 20180614:
The overlayfs tree gained conflicts against Linus' tree.
Non-merge commits (relative to Linus' tree): 778
600 files changed, 13285
Hi all,
Note: please do *not* add any v4.19 material to your linux-next included
branches until after v4.18-rc1 has been released.
Changes since 20180614:
The overlayfs tree gained conflicts against Linus' tree.
Non-merge commits (relative to Linus' tree): 778
600 files changed, 13285
Hi Greg,
> /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
> --- a/arch/x86/include/asm/fpu/internal.h
> +++ b/arch/x86/include/asm/fpu/internal.h
> @@ -58,7 +58,7 @@ extern u64 fpu__get_supported_xfeatures_
> */
> static __always_inline __pure bool use_eager_fpu(void)
Hi Greg,
> /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
> --- a/arch/x86/include/asm/fpu/internal.h
> +++ b/arch/x86/include/asm/fpu/internal.h
> @@ -58,7 +58,7 @@ extern u64 fpu__get_supported_xfeatures_
> */
> static __always_inline __pure bool use_eager_fpu(void)
David Howells writes:
> Here are a set of patches to create a filesystem context prior to setting
> up a new mount, populating it with the parsed options/binary data, creating
> the superblock and then effecting the mount. This is also used for remount
> since much of the parsing stuff is
David Howells writes:
> Here are a set of patches to create a filesystem context prior to setting
> up a new mount, populating it with the parsed options/binary data, creating
> the superblock and then effecting the mount. This is also used for remount
> since much of the parsing stuff is
This flag was introduce in 2.1.37pre1 and the only place it was tested
was removed in 2.1.43pre1. The flag was never set.
Let's discard it properly.
Signed-off-by: NeilBrown
---
fs/hostfs/hostfs.h | 3 +--
include/linux/fs.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git
This flag was introduce in 2.1.37pre1 and the only place it was tested
was removed in 2.1.43pre1. The flag was never set.
Let's discard it properly.
Signed-off-by: NeilBrown
---
fs/hostfs/hostfs.h | 3 +--
include/linux/fs.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git
Hello --
I'm running into an issue where sar, mpstat, top, and other tools show
less cpu utilization compared to emon [1]. Sar uses /proc/stat as its
source, and was configured to collect in 1s intervals. Emon reads
hardware counter MSRs in the PMU in timer intervals, 0.1s for this
scenario.
The
Hello --
I'm running into an issue where sar, mpstat, top, and other tools show
less cpu utilization compared to emon [1]. Sar uses /proc/stat as its
source, and was configured to collect in 1s intervals. Emon reads
hardware counter MSRs in the PMU in timer intervals, 0.1s for this
scenario.
The
On Fri, 2018-06-15 at 08:06 +0800, Ian Kent wrote:
Opps, missing Signed-off-by, please add it!
> Depending on how it is configured the autofs user space daemon can
> leave in use mounts mounted at exit and re-connect to them at start
> up. But for this to work best the state of the autofs file
On Fri, 2018-06-15 at 08:06 +0800, Ian Kent wrote:
Opps, missing Signed-off-by, please add it!
> Depending on how it is configured the autofs user space daemon can
> leave in use mounts mounted at exit and re-connect to them at start
> up. But for this to work best the state of the autofs file
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
On Thu, Jun 14, 2018 at 04:14:13PM -0700, Cong Wang wrote:
> On Thu, Jun 14, 2018 at 10:24 AM, Jason Gunthorpe wrote:
> > On Thu, Jun 14, 2018 at 10:03:09AM -0700, Cong Wang wrote:
> >> On Thu, Jun 14, 2018 at 7:24 AM, Jason Gunthorpe wrote:
> >> >
> >> > This was my brief reaction too, this
On Thu, Jun 14, 2018 at 04:14:13PM -0700, Cong Wang wrote:
> On Thu, Jun 14, 2018 at 10:24 AM, Jason Gunthorpe wrote:
> > On Thu, Jun 14, 2018 at 10:03:09AM -0700, Cong Wang wrote:
> >> On Thu, Jun 14, 2018 at 7:24 AM, Jason Gunthorpe wrote:
> >> >
> >> > This was my brief reaction too, this
On Fri, 2018-06-01 at 13:52 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
> wrote:
> > On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> >> On Fri, Jun 1, 2018 at 6:04 AM, wrote:
> >> > From: Honghui Zhang
> >>
> >> > +#ifdef CONFIG_PM_SLEEP
> >> >
On Fri, 2018-06-01 at 13:52 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
> wrote:
> > On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> >> On Fri, Jun 1, 2018 at 6:04 AM, wrote:
> >> > From: Honghui Zhang
> >>
> >> > +#ifdef CONFIG_PM_SLEEP
> >> >
On 14-06-18, 22:29, ilia@gmail.com wrote:
> From: Ilia Lin
>
> In event of error returned by the nvmem_cell_read() non-pointer value
> may be dereferenced. Fix this with error handling.
>
> Signed-off-by: Ilia Lin
Fixes tag ?
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 2 ++
> 1 file
On 14-06-18, 22:29, ilia@gmail.com wrote:
> From: Ilia Lin
>
> In event of error returned by the nvmem_cell_read() non-pointer value
> may be dereferenced. Fix this with error handling.
>
> Signed-off-by: Ilia Lin
Fixes tag ?
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 2 ++
> 1 file
On 14-06-18, 22:42, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
>
On 14-06-18, 22:42, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
>
On Thu, Jun 14, 2018 at 09:46:36AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 14, 2018 at 2:40 AM, Don Bollinger wrote:
> > On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> >> On Mon, Jun 11, 2018 at 6:25 AM, Don Bollinger
> >> wrote:
>
> >>
> >> I don't understand this part: I
On Thu, Jun 14, 2018 at 09:46:36AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 14, 2018 at 2:40 AM, Don Bollinger wrote:
> > On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> >> On Mon, Jun 11, 2018 at 6:25 AM, Don Bollinger
> >> wrote:
>
> >>
> >> I don't understand this part: I
Hi all,
This is now a conflict between the overlayfs tree and Linus' tree. (I
restarted my merging after I noticed that Linus merged more stuff.)
On Fri, 15 Jun 2018 10:43:24 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the y2038 tree got conflicts in:
>
> fs/inode.c
>
Hi all,
This is now a conflict between the overlayfs tree and Linus' tree. (I
restarted my merging after I noticed that Linus merged more stuff.)
On Fri, 15 Jun 2018 10:43:24 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the y2038 tree got conflicts in:
>
> fs/inode.c
>
On Thu, 2018-06-14 at 10:58 +0200, Ulf Hansson wrote:
> On Thu, 14 Jun 2018 at 09:14, wrote:
> >
> > From: Sean Wang
> >
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to
On Thu, 2018-06-14 at 10:58 +0200, Ulf Hansson wrote:
> On Thu, 14 Jun 2018 at 09:14, wrote:
> >
> > From: Sean Wang
> >
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to
Change in V3:
[PATCH v3 1/4]: Correct description
[PATCH v3 2/4]: Use an SPDX tag instead.
[PATCH v3 3/4]: Use an SPDX tag instead,
parent_rate might overflow and fix it.
fix up the checkpatch warning.
add more CMPOSITE_xxx_HALFdiv.
Change in V2:
Change in V3:
[PATCH v3 1/4]: Correct description
[PATCH v3 2/4]: Use an SPDX tag instead.
[PATCH v3 3/4]: Use an SPDX tag instead,
parent_rate might overflow and fix it.
fix up the checkpatch warning.
add more CMPOSITE_xxx_HALFdiv.
Change in V2:
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Signed-off-by: Elaine Zhang
---
.../bindings/clock/rockchip,px30-cru.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Signed-off-by: Elaine Zhang
---
.../bindings/clock/rockchip,px30-cru.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644
Add the clock tree definition for the new px30 SoC.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-px30.c | 1080 +++
drivers/clk/rockchip/clk.h | 41 +-
3 files changed, 1121 insertions(+), 1
Add the clock tree definition for the new px30 SoC.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-px30.c | 1080 +++
drivers/clk/rockchip/clk.h | 41 +-
3 files changed, 1121 insertions(+), 1
Add the dt-bindings header for the px30, that gets shared between
the clock controller and the clock references in the dts.
Add softreset ID for px30.
Signed-off-by: Elaine Zhang
Reviewed-by: Rob Herring
---
include/dt-bindings/clock/px30-cru.h | 389 +++
1 file
The new Rockchip socs have optional half divider:
The formula is shown as:
freq_out = 2*freq_in / (2*div + 3)
Is this the same for all of new SoCs.
So we use "branch_half_divider" + "COMPOSITE_NOMUX_HALFDIV \
DIV_HALF \ COMPOSITE_HALFDIV \ CMPOSITE_NOGATE_HALFDIV"
to hook that special
Add the dt-bindings header for the px30, that gets shared between
the clock controller and the clock references in the dts.
Add softreset ID for px30.
Signed-off-by: Elaine Zhang
Reviewed-by: Rob Herring
---
include/dt-bindings/clock/px30-cru.h | 389 +++
1 file
The new Rockchip socs have optional half divider:
The formula is shown as:
freq_out = 2*freq_in / (2*div + 3)
Is this the same for all of new SoCs.
So we use "branch_half_divider" + "COMPOSITE_NOMUX_HALFDIV \
DIV_HALF \ COMPOSITE_HALFDIV \ CMPOSITE_NOGATE_HALFDIV"
to hook that special
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel addresses even
though kernel sampling support is disabled.
One patch "perf/core: Drop kernel samples even
When doing sampling, for example:
perf record -e cycles:u ...
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel addresses even
though kernel sampling
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel addresses even
though kernel sampling support is disabled.
One patch "perf/core: Drop kernel samples even
When doing sampling, for example:
perf record -e cycles:u ...
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel addresses even
though kernel sampling
Introduce a new sysctl /sys/devices/cpu/perf_allow_sample_leakage, which
turns on/off dropping leaked kernel samples.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-record.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
Introduce a new sysctl /sys/devices/cpu/perf_allow_sample_leakage, which
turns on/off dropping leaked kernel samples.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-record.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
From: Chunyan Zhang
This patch adds the initial support of Secure Digital Host Controller
Interface compliant controller found in some latest Spreadtrum chipsets.
This patch has been tested on the version of SPRD-R11 controller.
R11 is a variant based on SD v4.0 specification.
With this
When Host Version 4 is enabled, SDMA System Address register is
re-defined as 32-bit Block Count, and SDMA uses ADMA System
Address register (05Fh-058h) instead.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+),
Host Driver Version 4.10 adds a new bit in Host Control 2 Register
for selecting Auto CMD23 or Auto CMD12 for ADMA3 data transfer.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 16 +++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 16 insertions(+), 1 deletion(-)
From: Chunyan Zhang
This patch adds the device-tree binding documentation for Spreadtrum
SDHCI driver.
Signed-off-by: Chunyan Zhang
---
.../devicetree/bindings/mmc/sdhci-sprd.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
From: Chunyan Zhang
This patch adds the initial support of Secure Digital Host Controller
Interface compliant controller found in some latest Spreadtrum chipsets.
This patch has been tested on the version of SPRD-R11 controller.
R11 is a variant based on SD v4.0 specification.
With this
When Host Version 4 is enabled, SDMA System Address register is
re-defined as 32-bit Block Count, and SDMA uses ADMA System
Address register (05Fh-058h) instead.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+),
Host Driver Version 4.10 adds a new bit in Host Control 2 Register
for selecting Auto CMD23 or Auto CMD12 for ADMA3 data transfer.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 16 +++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 16 insertions(+), 1 deletion(-)
From: Chunyan Zhang
This patch adds the device-tree binding documentation for Spreadtrum
SDHCI driver.
Signed-off-by: Chunyan Zhang
---
.../devicetree/bindings/mmc/sdhci-sprd.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
According to the SD host controller specification version 4.10, when
Host Version 4 is enabled, SDMA uses ADMA System Address register
(05Fh-058h) instead of using SDMA System Address register to
support both 32-bit and 64-bit addressing.
Signed-off-by: Chunyan Zhang
---
ADMA2 64-bit addressing support is divided into V3 mode and V4 mode.
So there are two kinds of descriptors for ADMA2 64-bit addressing
i.e. 96-bit Descriptor for V3 mode, and 128-bit Descriptor for V4
mode. 128-bit Descriptor is aligned to 8-byte.
For V4 mode, ADMA2 64-bit addressing is enabled
According to the SD host controller specification version 4.10, when
Host Version 4 is enabled, SDMA uses ADMA System Address register
(05Fh-058h) instead of using SDMA System Address register to
support both 32-bit and 64-bit addressing.
Signed-off-by: Chunyan Zhang
---
ADMA2 64-bit addressing support is divided into V3 mode and V4 mode.
So there are two kinds of descriptors for ADMA2 64-bit addressing
i.e. 96-bit Descriptor for V3 mode, and 128-bit Descriptor for V4
mode. 128-bit Descriptor is aligned to 8-byte.
For V4 mode, ADMA2 64-bit addressing is enabled
From: Chunyan Zhang
>From the SD host controller version 4.0 on, SDHCI implementation either
is version 3 compatible or version 4 mode. This patch-set covers those
changes which are common for SDHCI 4.0 version, regardless of whether
they are used with SD or eMMC storage devices.
This patchset
From: Chunyan Zhang
>From the SD host controller version 4.0 on, SDHCI implementation either
is version 3 compatible or version 4 mode. This patch-set covers those
changes which are common for SDHCI 4.0 version, regardless of whether
they are used with SD or eMMC storage devices.
This patchset
For SD host controller version 4.00 or later ones, there're two
modes of implementation - Version 3.00 compatible mode or
Version 4 mode. This patch introduces a flag to record this.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 6 ++
drivers/mmc/host/sdhci.h | 6 ++
2
For SD host controller version 4.00 or later ones, there're two
modes of implementation - Version 3.00 compatible mode or
Version 4 mode. This patch introduces a flag to record this.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 6 ++
drivers/mmc/host/sdhci.h | 6 ++
2
Hi Ben,
> (The log message about Write Protect status also reports the
> underlying SCSI device flag and not the combined ro flag, but maybe
> that was intentional.)
I'd prefer for the printk in question to reflect the device-reported
state, not the state of the block device.
> I think this
Hi Ben,
> (The log message about Write Protect status also reports the
> underlying SCSI device flag and not the combined ro flag, but maybe
> that was intentional.)
I'd prefer for the printk in question to reflect the device-reported
state, not the state of the block device.
> I think this
According to the Denali User's Guide, this IP needs three clocks:
- clk: controller core clock
- clk_x: bus interface clock
- ecc_clk: clock at which ECC circuitry is run
Currently, denali_dt.c requires a single anonymous clock and its
frequency. However, the driver needs to get the
The ->setup_data_interface() hook needs to know the clock frequency.
In fact, this IP needs three clocks, bus "which clock?" is really
confusing. (It is not described in the DT-binding at all.)
This series adds more clocks. In the new binding, three clocks
are required: core clock, bus
According to the Denali User's Guide, this IP needs three clocks:
- clk: controller core clock
- clk_x: bus interface clock
- ecc_clk: clock at which ECC circuitry is run
Currently, denali_dt.c requires a single anonymous clock and its
frequency. However, the driver needs to get the
The ->setup_data_interface() hook needs to know the clock frequency.
In fact, this IP needs three clocks, bus "which clock?" is really
confusing. (It is not described in the DT-binding at all.)
This series adds more clocks. In the new binding, three clocks
are required: core clock, bus
This commit improves the ->setup_data_interface() hook.
The denali_setup_data_interface() needs the frequency of clk_x
and the ratio of clk_x / clk.
The latter is currently hardcoded in the driver, like this:
#define DENALI_CLK_X_MULT 6
The IP datasheet requires that clk_x / clk be 4,
This commit improves the ->setup_data_interface() hook.
The denali_setup_data_interface() needs the frequency of clk_x
and the ratio of clk_x / clk.
The latter is currently hardcoded in the driver, like this:
#define DENALI_CLK_X_MULT 6
The IP datasheet requires that clk_x / clk be 4,
1 - 100 of 1344 matches
Mail list logo
