Rather than keying the access cache with 'struct rpc_cred',
use 'struct cred'. Then use cred_fscmp() to compare
credentials rather than comparing the raw pointer.
A benefit of this approach is that in the common case we avoid the
rpc_lookup_cred_nonblock() call which can be slow when the cred
In almost all cases the credential stored in rpc_message.rpc_cred
is a "generic" credential. One of the two expections is when an
AUTH_NULL credential is used such as for RPC ping requests.
To improve consistency, don't pass an explicit credential in
these cases, but instead pass NULL and set a
This is no longer used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h |3 ---
net/sunrpc/auth_null.c |1 -
net/sunrpc/auth_unix.c |1 -
3 files changed, 5 deletions(-)
diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h
index
Use the common 'struct cred' to pass credentials for readdir.
Signed-off-by: NeilBrown
---
fs/nfs/dir.c| 15 +--
fs/nfs/nfs3proc.c | 11 +--
fs/nfs/nfs4proc.c | 13 ++---
fs/nfs/proc.c | 11 +--
include/linux/nfs_fs.h
This is no longer used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h |6 -
net/sunrpc/Makefile |2
net/sunrpc/auth.c | 18
net/sunrpc/auth_generic.c | 199 ---
net/sunrpc/auth_null.c |2
5 files
NFS needs to know when a credential is about to expire so that
it can modify write-back behaviour to finish the write inside the
expiry time.
It currently uses functions in SUNRPC code which make use of a
fairly complex callback scheme and flags in the generic credientials.
As I am working to
This lock is no longer necessary.
If nfs4_get_renew_cred() needs to hunt through the open-state
creds for a user cred, it still takes the lock to stablize
the rbtree, but otherwise there are no races.
Note that this completely removes the lock from nfs4_renew_state().
It appears that the
When NFS creates a machine credential, it is a "generic" credential,
not tied to any auth protocol, and is really just a container for
the princpal name.
This doesn't get linked to a genuine credential until rpcauth_bindcred()
is called.
The lookup always succeeds, so various places that test if
This lock is no longer necessary.
If nfs4_get_renew_cred() needs to hunt through the open-state
creds for a user cred, it still takes the lock to stablize
the rbtree, but otherwise there are no races.
Note that this completely removes the lock from nfs4_renew_state().
It appears that the
When NFS creates a machine credential, it is a "generic" credential,
not tied to any auth protocol, and is really just a container for
the princpal name.
This doesn't get linked to a genuine credential until rpcauth_bindcred()
is called.
The lookup always succeeds, so various places that test if
it is never used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/sched.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
index 7b540c066594..f542dad8d4ab 100644
--- a/include/linux/sunrpc/sched.h
+++
it is never used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/sched.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
index 7b540c066594..f542dad8d4ab 100644
--- a/include/linux/sunrpc/sched.h
+++
NFSv4 state management tries a root credential when no machine
credential is available, as can happen with kerberos.
It does this by replacing the cl_machine_cred with a root credential.
This means that any user of the machine credential needs to take
a lock while getting a reference to the
NFSv4 state management tries a root credential when no machine
credential is available, as can happen with kerberos.
It does this by replacing the cl_machine_cred with a root credential.
This means that any user of the machine credential needs to take
a lock while getting a reference to the
The cred is a machine_cred iff ->principal is set, so there is no
need for the extra flag.
There is one case which deserves some
explanation. nfs4_root_machine_cred() calls rpc_lookup_machine_cred()
with a NULL principal name which results in not getting a machine
credential, but getting a root
Use cred->fsuid and cred->fsgid instead.
Signed-off-by: NeilBrown
---
fs/nfs/flexfilelayout/flexfilelayout.c | 14 --
fs/nfsd/nfs4callback.c |6 ++
include/linux/sunrpc/auth.h|3 ---
net/sunrpc/auth.c |6 +-
It is common practice for helpers like this to silently,
accept a NULL pointer.
get_rpccred() and put_rpccred() used by NFS act this way
and using the same interface will ease the conversion
for NFS, and simplify the resulting code.
Signed-off-by: NeilBrown
---
include/linux/cred.h | 14
The cred is a machine_cred iff ->principal is set, so there is no
need for the extra flag.
There is one case which deserves some
explanation. nfs4_root_machine_cred() calls rpc_lookup_machine_cred()
with a NULL principal name which results in not getting a machine
credential, but getting a root
Use cred->fsuid and cred->fsgid instead.
Signed-off-by: NeilBrown
---
fs/nfs/flexfilelayout/flexfilelayout.c | 14 --
fs/nfsd/nfs4callback.c |6 ++
include/linux/sunrpc/auth.h|3 ---
net/sunrpc/auth.c |6 +-
It is common practice for helpers like this to silently,
accept a NULL pointer.
get_rpccred() and put_rpccred() used by NFS act this way
and using the same interface will ease the conversion
for NFS, and simplify the resulting code.
Signed-off-by: NeilBrown
---
include/linux/cred.h | 14
We can use cred->groupinfo (from the 'struct cred') instead.
Signed-off-by: NeilBrown
---
fs/nfs/flexfilelayout/flexfilelayout.c | 14 +-
include/linux/sunrpc/auth.h|1 -
net/sunrpc/auth.c |1 -
net/sunrpc/auth_generic.c | 17
The SUNRPC credential framework was put together before
Linux has 'struct cred'. Now that we have it, it makes sense to
use it.
This first step just includes a suitable 'struct cred *' pointer
in every 'struct auth_cred' and almost every 'struct rpc_cred'.
The rpc_cred used for auth_null has a
We can use cred->groupinfo (from the 'struct cred') instead.
Signed-off-by: NeilBrown
---
fs/nfs/flexfilelayout/flexfilelayout.c | 14 +-
include/linux/sunrpc/auth.h|1 -
net/sunrpc/auth.c |1 -
net/sunrpc/auth_generic.c | 17
The SUNRPC credential framework was put together before
Linux has 'struct cred'. Now that we have it, it makes sense to
use it.
This first step just includes a suitable 'struct cred *' pointer
in every 'struct auth_cred' and almost every 'struct rpc_cred'.
The rpc_cred used for auth_null has a
NFS needs to compare to credentials, to see if they can
be treated the same w.r.t. filesystem access. Sometimes
an ordering is needed when credentials are used as a key
to an rbtree.
NFS currently has its own private credential management from
before 'struct cred' existed. To move it over to
This is the same series as posted on 07 November, modified slightly
to match some recent code changes upstream - nothing substantial.
General description:
There doesn't seem to be a maintainer for the 'cred' code, so I don't
know who to ask to approve the first 4 patches. Maybe if the NFS
team
Sometimes we want to opportunistically get a
ref to a cred in an rcu_read_lock protected section.
get_task_cred() does this, and NFS does as similar thing
with its own credential structures.
To prepare for NFS converting to use 'struct cred' more
uniformly, define get_cred_rcu(), and use it in
There is no reason that modules should not be able
to use this, and NFS will need it when converted to
use 'struct cred'.
Signed-off-by: NeilBrown
---
kernel/cred.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index ba60162249e8..21f4a97085b4 100644
---
Sometimes we want to opportunistically get a
ref to a cred in an rcu_read_lock protected section.
get_task_cred() does this, and NFS does as similar thing
with its own credential structures.
To prepare for NFS converting to use 'struct cred' more
uniformly, define get_cred_rcu(), and use it in
There is no reason that modules should not be able
to use this, and NFS will need it when converted to
use 'struct cred'.
Signed-off-by: NeilBrown
---
kernel/cred.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index ba60162249e8..21f4a97085b4 100644
---
NFS needs to compare to credentials, to see if they can
be treated the same w.r.t. filesystem access. Sometimes
an ordering is needed when credentials are used as a key
to an rbtree.
NFS currently has its own private credential management from
before 'struct cred' existed. To move it over to
This is the same series as posted on 07 November, modified slightly
to match some recent code changes upstream - nothing substantial.
General description:
There doesn't seem to be a maintainer for the 'cred' code, so I don't
know who to ask to approve the first 4 patches. Maybe if the NFS
team
Hi Geert,
On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> > syscall_get_arch() is required to be implemented on all architectures
> > in order to extend the generic ptrace API with
Hi Geert,
On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> > syscall_get_arch() is required to be implemented on all architectures
> > in order to extend the generic ptrace API with
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
include/linux/fs.h
between commit:
a2bd7d2fc32c ("fs-verity: add setup code, UAPI, and Kconfig")
from the fscrypt tree and commit:
37744f3d21f8 ("vfs: Implement a filesystem superblock creation/configuration
context")
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
include/linux/fs.h
between commit:
a2bd7d2fc32c ("fs-verity: add setup code, UAPI, and Kconfig")
from the fscrypt tree and commit:
37744f3d21f8 ("vfs: Implement a filesystem superblock creation/configuration
context")
Nadav Amit writes:
[skip]
>
> Having said that, something else is sort of strange in the TLFS definitions,
> I think (I really know little about this whole protocol). Look at the
> following definitions from hyperv-tlfs.h:
>
>> struct hv_vpset {
>> u64 format;
>> u64
Nadav Amit writes:
[skip]
>
> Having said that, something else is sort of strange in the TLFS definitions,
> I think (I really know little about this whole protocol). Look at the
> following definitions from hyperv-tlfs.h:
>
>> struct hv_vpset {
>> u64 format;
>> u64
On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel
> Acked-by: Pavel Machek
>
> ---
> Changes since v1:
> - s/s16
On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel
> Acked-by: Pavel Machek
>
> ---
> Changes since v1:
> - s/s16
Hmm.. I'd like to say it was a normal week, but I'd be lying. rc5 is
the biggest rc so far (with the obvious exception of rc1), and it
looks fairly unusual in the diffstat too, with almost a third being
arch updates. Yes, another third is drivers (normal), but even there
almost half is in sound.
Hmm.. I'd like to say it was a normal week, but I'd be lying. rc5 is
the biggest rc so far (with the obvious exception of rc1), and it
looks fairly unusual in the diffstat too, with almost a third being
arch updates. Yes, another third is drivers (normal), but even there
almost half is in sound.
On Tue, Nov 27, 2018 at 02:54:22PM +0900, Minchan Kim wrote:
> Inherently, swap device has many idle pages which are rare touched since
> it was allocated. It is never problem if we use storage device as swap.
> However, it's just waste for zram-swap.
>
> This patchset supports zram idle page
On Tue, Nov 27, 2018 at 02:54:22PM +0900, Minchan Kim wrote:
> Inherently, swap device has many idle pages which are rare touched since
> it was allocated. It is never problem if we use storage device as swap.
> However, it's just waste for zram-swap.
>
> This patchset supports zram idle page
On Sun, Dec 02, 2018 at 11:29:30PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > The patch set has been tested on an OLPC XO-1.75 laptop.
> > >
> > > Excellent!
> >
> > OOooh, I have one of those... somewhere.
>
> Time to find it :-). It is still pretty great machine, can last 8?
> hours on
On Sun, Dec 02, 2018 at 11:29:30PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > The patch set has been tested on an OLPC XO-1.75 laptop.
> > >
> > > Excellent!
> >
> > OOooh, I have one of those... somewhere.
>
> Time to find it :-). It is still pretty great machine, can last 8?
> hours on
On Fri, Nov 16, 2018 at 05:23:59PM +0100, Lubomir Rintel wrote:
> Avoid using the x86 OLPC platform specific call to get the board
> version. It won't work on FDT-based ARM MMP2 platform.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
> Acked-by: Pavel Machek
>
> ---
>
On Fri, Nov 16, 2018 at 05:23:59PM +0100, Lubomir Rintel wrote:
> Avoid using the x86 OLPC platform specific call to get the board
> version. It won't work on FDT-based ARM MMP2 platform.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
> Acked-by: Pavel Machek
>
> ---
>
On Sat, Dec 01, 2018 at 02:49:09AM -0500, Sasha Levin wrote:
> On Sat, Dec 01, 2018 at 08:50:05AM +1100, Dave Chinner wrote:
> >On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> >>On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> >>>On Fri, Nov 30, 2018 at 09:40:19AM +1100,
On Sat, Dec 01, 2018 at 02:49:09AM -0500, Sasha Levin wrote:
> On Sat, Dec 01, 2018 at 08:50:05AM +1100, Dave Chinner wrote:
> >On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> >>On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> >>>On Fri, Nov 30, 2018 at 09:40:19AM +1100,
On Mon, 2018-12-03 at 00:20 +0530, Himanshu Jha wrote:
> On Sun, Dec 02, 2018 at 02:57:12PM -0200, Marcelo Schmitt wrote:
> > Add a devicetree documentation for the ad5933 and ad5934 impedance
> > converter, network analyzer.
> >
> > Co-Developed-by: Gabriel Capella
>
> checkpatch spits out:
>
On Mon, 2018-12-03 at 00:20 +0530, Himanshu Jha wrote:
> On Sun, Dec 02, 2018 at 02:57:12PM -0200, Marcelo Schmitt wrote:
> > Add a devicetree documentation for the ad5933 and ad5934 impedance
> > converter, network analyzer.
> >
> > Co-Developed-by: Gabriel Capella
>
> checkpatch spits out:
>
On Fri, Nov 30, 2018 at 01:36:56PM +0900, Sergey Senozhatsky wrote:
> On (11/27/18 14:54), Minchan Kim wrote:
> > Inherently, swap device has many idle pages which are rare touched since
> > it was allocated. It is never problem if we use storage device as swap.
> > However, it's just waste for
On Fri, Nov 30, 2018 at 01:36:56PM +0900, Sergey Senozhatsky wrote:
> On (11/27/18 14:54), Minchan Kim wrote:
> > Inherently, swap device has many idle pages which are rare touched since
> > it was allocated. It is never problem if we use storage device as swap.
> > However, it's just waste for
On Thu, Nov 29, 2018 at 11:23:58AM +0900, Sergey Senozhatsky wrote:
> On (11/27/18 14:54), Minchan Kim wrote:
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> > b/Documentation/ABI/testing/sysfs-block-zram
> > index 65fc33b2f53b..9d2339a485c8 100644
> > ---
On Thu, Nov 29, 2018 at 11:23:58AM +0900, Sergey Senozhatsky wrote:
> On (11/27/18 14:54), Minchan Kim wrote:
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> > b/Documentation/ABI/testing/sysfs-block-zram
> > index 65fc33b2f53b..9d2339a485c8 100644
> > ---
On Fri, Nov 16, 2018 at 05:23:53PM +0100, Lubomir Rintel wrote:
> Just return ENODEV, so that whoever attempted to use the EC call can
I think you meant EPROBE_DEFER here, but the language in the commit
message is a bit ambiguous here...
> defer their work.
>
> Signed-off-by: Lubomir Rintel
>
On Fri, Nov 16, 2018 at 05:23:53PM +0100, Lubomir Rintel wrote:
> Just return ENODEV, so that whoever attempted to use the EC call can
I think you meant EPROBE_DEFER here, but the language in the commit
message is a bit ambiguous here...
> defer their work.
>
> Signed-off-by: Lubomir Rintel
>
On Fri, Nov 16, 2018 at 05:23:52PM +0100, Lubomir Rintel wrote:
> It's based off the driver from the OLPC kernel sources. Somewhat
> modernized and cleaned up, for better or worse.
>
> Modified to plug into the olpc-ec driver infrastructure (so that battery
> interface and debugfs could be
On Fri, Nov 16, 2018 at 05:23:52PM +0100, Lubomir Rintel wrote:
> It's based off the driver from the OLPC kernel sources. Somewhat
> modernized and cleaned up, for better or worse.
>
> Modified to plug into the olpc-ec driver infrastructure (so that battery
> interface and debugfs could be
On Sun, Dec 02, 2018 at 10:10:36AM -0500, Mimi Zohar wrote:
> Are you asking about coordinating staging the trusted key patches to
> be upstreamed or about moving portions of the encrypted keys code out
> of the keyring subsystem?
>
> I'm not sure there needs to be a separate encrypted-keys pull
On Sun, Dec 02, 2018 at 10:10:36AM -0500, Mimi Zohar wrote:
> Are you asking about coordinating staging the trusted key patches to
> be upstreamed or about moving portions of the encrypted keys code out
> of the keyring subsystem?
>
> I'm not sure there needs to be a separate encrypted-keys pull
Hi!
> > > The patch set has been tested on an OLPC XO-1.75 laptop.
> >
> > Excellent!
>
> OOooh, I have one of those... somewhere.
Time to find it :-). It is still pretty great machine, can last 8?
hours on battery, sunlight readable screen, and if you meet a tiger
you can hit him on the head
Hi!
> > > The patch set has been tested on an OLPC XO-1.75 laptop.
> >
> > Excellent!
>
> OOooh, I have one of those... somewhere.
Time to find it :-). It is still pretty great machine, can last 8?
hours on battery, sunlight readable screen, and if you meet a tiger
you can hit him on the head
On Fri 2018-11-30 15:44:55, Numan Demirdöğen wrote:
> Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
> Numan Demirdöğen yazdı:
>
> >Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
> >Pavel Machek yazdı:
> >
> >> Hi!
> >>
> >> Here's problem bisected down to:
> >>
> >> commit
On Fri 2018-11-30 15:44:55, Numan Demirdöğen wrote:
> Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
> Numan Demirdöğen yazdı:
>
> >Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
> >Pavel Machek yazdı:
> >
> >> Hi!
> >>
> >> Here's problem bisected down to:
> >>
> >> commit
Hi Philipp,
Today's linux-next merge of the reset tree got a conflict in:
arch/arm/mach-socfpga/socfpga.c
between commit:
8f6f8c77fc4d ("reset: socfpga: add an early reset driver for SoCFPGA")
from the arm-soc tree and commit:
48e2bab90d8e ("ARM: socfpga: Clean unused functions")
from
Hi Philipp,
Today's linux-next merge of the reset tree got a conflict in:
arch/arm/mach-socfpga/socfpga.c
between commit:
8f6f8c77fc4d ("reset: socfpga: add an early reset driver for SoCFPGA")
from the arm-soc tree and commit:
48e2bab90d8e ("ARM: socfpga: Clean unused functions")
from
niedz., 2 gru 2018 o 22:56 Uwe Kleine-König
napisał(a):
>
> Hello,
>
> On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote:
> > We're getting too much into details of how to handle simulated
> > interrupts and we can continue discussing it, but meanwhile I'd like
> > to address a
niedz., 2 gru 2018 o 22:56 Uwe Kleine-König
napisał(a):
>
> Hello,
>
> On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote:
> > We're getting too much into details of how to handle simulated
> > interrupts and we can continue discussing it, but meanwhile I'd like
> > to address a
Am 02.12.18 um 21:19 schrieb Andrey Melnikov:
> чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig :
>>
>> Am 28.11.18 um 22:13 schrieb Andrey Melnikov:
>>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig :
Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov:
> In
Am 02.12.18 um 21:19 schrieb Andrey Melnikov:
> чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig :
>>
>> Am 28.11.18 um 22:13 schrieb Andrey Melnikov:
>>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig :
Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov:
> In
Add support for the RTC block on the 32-bit Amlogic Meson6, Meson8,
Meson8b and Meson8m2 SoCs.
The RTC is split in to two parts, which are both managed by this driver:
- the AHB front end
- and a simple serial connection to the actual registers
The RTC_COUNTER register which holds the time is
This series adds support for the RTC on the 32-bit Amlogic Meson SoCs.
The series does not have any build dependencies, but does require
device-tree entries for the relevant boards.
The series is tested by myself on the Meson8b EC-100 board. Earlier
versions of this series were tested on an
The 32-bit Amlogic Meson SoCs (Meson6, Meson8, Meson8b and Meson8m2)
have a built-in RTC block.
It has the following inputs:
- an 32.768kHz crystal oscillator
- an interrupt line
- a reset line
- 0.9V voltage input
Signed-off-by: Ben Dooks
[resurrected patches from Ben after 2 years]
This series adds support for the RTC on the 32-bit Amlogic Meson SoCs.
The series does not have any build dependencies, but does require
device-tree entries for the relevant boards.
The series is tested by myself on the Meson8b EC-100 board. Earlier
versions of this series were tested on an
The 32-bit Amlogic Meson SoCs (Meson6, Meson8, Meson8b and Meson8m2)
have a built-in RTC block.
It has the following inputs:
- an 32.768kHz crystal oscillator
- an interrupt line
- a reset line
- 0.9V voltage input
Signed-off-by: Ben Dooks
[resurrected patches from Ben after 2 years]
Add support for the RTC block on the 32-bit Amlogic Meson6, Meson8,
Meson8b and Meson8m2 SoCs.
The RTC is split in to two parts, which are both managed by this driver:
- the AHB front end
- and a simple serial connection to the actual registers
The RTC_COUNTER register which holds the time is
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/mach-socfpga/Kconfig
between commit:
2eac9c2dfb2b ("PCI: consolidate the PCI_DOMAINS and PCI_DOMAINS_GENERIC
config options")
from the kbuild tree and commit:
fbc125afdc50 ("ARM: socfpga: Turn on ARM
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/mach-socfpga/Kconfig
between commit:
2eac9c2dfb2b ("PCI: consolidate the PCI_DOMAINS and PCI_DOMAINS_GENERIC
config options")
from the kbuild tree and commit:
fbc125afdc50 ("ARM: socfpga: Turn on ARM
Hello,
On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote:
> We're getting too much into details of how to handle simulated
> interrupts and we can continue discussing it, but meanwhile I'd like
> to address a different thing:
>
> Thomas, Linus: after commit fa38869b0161
Hello,
On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote:
> We're getting too much into details of how to handle simulated
> interrupts and we can continue discussing it, but meanwhile I'd like
> to address a different thing:
>
> Thomas, Linus: after commit fa38869b0161
Add all clocks to give us the final video clocks within the Meson8,
Meson8b and Meson8m2 SoCs. The final video clocks are:
- cts_enct
- cts_encl
- cts_encp
- cts_enci
- cts_vdac0
- hdmi_tx_pixel
- hdmi_sys
Add multiple clocks in between which are needed to implement these
clocks:
- Opposed to
Add all clocks to give us the final video clocks within the Meson8,
Meson8b and Meson8m2 SoCs. The final video clocks are:
- cts_enct
- cts_encl
- cts_encp
- cts_enci
- cts_vdac0
- hdmi_tx_pixel
- hdmi_sys
Add multiple clocks in between which are needed to implement these
clocks:
- Opposed to
just wanted to add: although the subject says "4.19.6" the patches
apply perfectly to the top of "torvalds/linux" tree from github.
On Sun, 2 Dec 2018 at 21:01, Tigran Aivazian wrote:
>
> Hi Linus,
>
> I attached two incremental patches for BFS:
>
> 1. Make inode bitmap allocation static (applies
This is the Meson8b variant of Neil's series from [0] called "- clk:
meson: Add video clocks path".
GXBB and newer use a -- vid_pll divider IP block which doesn't exist on
the 32-bit SoCs. Instead the 32-bit SoCs use three simple dividers,
a few muxes and some fixed dividers.
I used Neil's GXBB
Unlike the other PLLs on Meson8b the N value "vid_pll_dco" (a better
name would be hdmi_pll_dco or - as the datasheet calls it - HPLL) is
located at HHI_VID_PLL_CNTL[14:10] instead of [13:9].
This results in an incorrect calculation of the rate of this PLL because
the value seen by the kernel is
This "vid_pll_dco" (which should be named HDMI_PLL or - as the datasheet
calls it - HPLL) has a 12-bit wide fractional parameter at
HHI_VID_PLL_CNTL2[11:0]. Add this so we correctly calculate the rate of
this PLL when u-boot is configured for a video mode which uses this
fractional parameter.
just wanted to add: although the subject says "4.19.6" the patches
apply perfectly to the top of "torvalds/linux" tree from github.
On Sun, 2 Dec 2018 at 21:01, Tigran Aivazian wrote:
>
> Hi Linus,
>
> I attached two incremental patches for BFS:
>
> 1. Make inode bitmap allocation static (applies
This is the Meson8b variant of Neil's series from [0] called "- clk:
meson: Add video clocks path".
GXBB and newer use a -- vid_pll divider IP block which doesn't exist on
the 32-bit SoCs. Instead the 32-bit SoCs use three simple dividers,
a few muxes and some fixed dividers.
I used Neil's GXBB
Unlike the other PLLs on Meson8b the N value "vid_pll_dco" (a better
name would be hdmi_pll_dco or - as the datasheet calls it - HPLL) is
located at HHI_VID_PLL_CNTL[14:10] instead of [13:9].
This results in an incorrect calculation of the rate of this PLL because
the value seen by the kernel is
This "vid_pll_dco" (which should be named HDMI_PLL or - as the datasheet
calls it - HPLL) has a 12-bit wide fractional parameter at
HHI_VID_PLL_CNTL2[11:0]. Add this so we correctly calculate the rate of
this PLL when u-boot is configured for a video mode which uses this
fractional parameter.
On Fri, Nov 30, 2018 at 11:27:23AM -0800, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> lib/vsprintf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>
On Fri, Nov 30, 2018 at 11:27:23AM -0800, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> lib/vsprintf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>
From: Fabio Estevam
This extends the peripherals supported by the imx7d-pico.dtsi. It
adds:
- I2C2
- Flexcan (flexcan1 and flexcan2 ports)
- USDHC1
- UART (6 and 7 ports)
- PWM (4 ports)
- eCSPI3
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
From: Fabio Estevam
The imx7d-pico-hobbit contains a imx7d-pico SoM and a hobbit baseboard.
Add support for it.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-pico-hobbit.dts | 105
From: Fabio Estevam
Pass the USBOTG1_PWR pinctrl description in the USBOTG GPIO
controlled regulator.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/imx7d-pico.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi
From: Fabio Estevam
This adds following peripherals for the imx7d-pico-pi as:
- LED
- Touchscreen
- GPIO
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/imx7d-pico-pi.dts | 56 +
1 file changed, 56 insertions(+)
diff --git
From: Fabio Estevam
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/imx7d-pico-pi.dts | 44 ++---
arch/arm/boot/dts/imx7d-pico.dtsi | 44
From: Fabio Estevam
This extends the peripherals supported by the imx7d-pico.dtsi. It
adds:
- I2C2
- Flexcan (flexcan1 and flexcan2 ports)
- USDHC1
- UART (6 and 7 ports)
- PWM (4 ports)
- eCSPI3
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
301 - 400 of 614 matches
Mail list logo
