This converts FSI scom to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 130 +
1 file changed, 80 insertions(+), 50 deletions(-)
diff --git
This converts the various FSI devices from misc dev to chardev,
as there can potentially be too much of them for misc devs limited
minors, and because there are some lifetime issues with the current
support.
This provide a common infrastructure to allocate an FSI major and
distribute minors in a
7:32 +1000)
----
Benjamin Herrenschmidt (6):
devres: Add devm_of_iomap()
dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
fsi: sbefifo: Fix inconsistent use of ffdc mutex
dt-bindings: fsi:
7:32 +1000)
----
Benjamin Herrenschmidt (6):
devres: Add devm_of_iomap()
dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
fsi: sbefifo: Fix inconsistent use of ffdc mutex
dt-bindings: fsi:
On Sat, 2018-07-21 at 09:53 +0200, Greg Kroah-Hartman wrote:
> > > So I hate using kobject_get_unless_zero(), and resisted ever adding it
> > > to the tree as it shows a bad locking/tree situation as you point out
> > > here. But for some reason, the block developers seemed to insist they
> > >
On Sat, 2018-07-21 at 09:53 +0200, Greg Kroah-Hartman wrote:
> > > So I hate using kobject_get_unless_zero(), and resisted ever adding it
> > > to the tree as it shows a bad locking/tree situation as you point out
> > > here. But for some reason, the block developers seemed to insist they
> > >
On Fri, 2018-07-20 at 09:37 +0930, Andrew Jeffery wrote:
> >
> > Andrew, can you start with a list that shows what you expect us to need
> > on our systems ?
> >
>
> Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
> currently need the following tuneables exposed:
>
>
On Fri, 2018-07-20 at 09:37 +0930, Andrew Jeffery wrote:
> >
> > Andrew, can you start with a list that shows what you expect us to need
> > on our systems ?
> >
>
> Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
> currently need the following tuneables exposed:
>
>
On Thu, 2018-07-19 at 11:58 +0930, Andrew Jeffery wrote:
> > > I agree
> > > that not using /dev/mem is a good thing, but there are several ways
> > > you could do that independent of any DT binding.
> >
> > Such as ? The only other option is to have one or more kernel drivers
> > that have
On Thu, 2018-07-19 at 11:58 +0930, Andrew Jeffery wrote:
> > > I agree
> > > that not using /dev/mem is a good thing, but there are several ways
> > > you could do that independent of any DT binding.
> >
> > Such as ? The only other option is to have one or more kernel drivers
> > that have
On Wed, 2018-07-18 at 13:50 -0600, Rob Herring wrote:
>
> > So Rob, I think that's precisely where the disconnect is.
> >
> > I think we all (well hopefully) agree that those few tunables don't fit
> > in any existing subystem and aren't likely to ever do (famous last
> > words...).
> >
> >
On Wed, 2018-07-18 at 13:50 -0600, Rob Herring wrote:
>
> > So Rob, I think that's precisely where the disconnect is.
> >
> > I think we all (well hopefully) agree that those few tunables don't fit
> > in any existing subystem and aren't likely to ever do (famous last
> > words...).
> >
> >
On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> If that data is one set per SoC, then i'm not that concerned having
> platform-specific data in the driver. That doesn't mean the driver is
> not "generic". It's still not clear to me in this thread, how much of
> this is board specific, but
On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> If that data is one set per SoC, then i'm not that concerned having
> platform-specific data in the driver. That doesn't mean the driver is
> not "generic". It's still not clear to me in this thread, how much of
> this is board specific, but
On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI p
On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI p
On Thu, 2018-07-12 at 09:11 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 6:54 PM Andrew Jeffery wrote:
> >
> > Hi Rob,
> >
> > Thanks for the response.
> >
> > On Thu, 12 Jul 2018, at 05:34, Rob Herring wrote:
> > > On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > > >
On Thu, 2018-07-12 at 09:11 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 6:54 PM Andrew Jeffery wrote:
> >
> > Hi Rob,
> >
> > Thanks for the response.
> >
> > On Thu, 12 Jul 2018, at 05:34, Rob Herring wrote:
> > > On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > > >
On Thu, 2018-07-12 at 17:53 +1000, Joel Stanley wrote:
> On 12 July 2018 at 13:48, Benjamin Herrenschmidt
> wrote:
> > The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> > is currently unused on OpenPower systems.
> >
> > This adds an alternative
On Thu, 2018-07-12 at 17:53 +1000, Joel Stanley wrote:
> On 12 July 2018 at 13:48, Benjamin Herrenschmidt
> wrote:
> > The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> > is currently unused on OpenPower systems.
> >
> > This adds an alternative
on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
.../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation
for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/Kconfig |9 +
drivers/fsi/Makefile |1 +
drivers/fsi/cf-fsi-fw.h | 157
on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
.../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation
for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/Kconfig |9 +
drivers/fsi/Makefile |1 +
drivers/fsi/cf-fsi-fw.h | 157
) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Linus Walleij
Reviewed-by: Joel Stanley
---
include/linux/device.h | 4
li
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 347938673c83..4f4e42e47e3f
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 347938673c83..4f4e42e47e3f
) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Linus Walleij
Reviewed-by: Joel Stanley
---
include/linux/device.h | 4
li
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp
This series implements support for offloading the FSI protocol bitbanging
to the ColdFire secondary core of the Aspeed SoCs. The result increases
FSI performance by a factor of 4, and on systems that don't support async
FSI clock, provide much more regular and continuous clocking which helps
This series implements support for offloading the FSI protocol bitbanging
to the ColdFire secondary core of the Aspeed SoCs. The result increases
FSI performance by a factor of 4, and on systems that don't support async
FSI clock, provide much more regular and continuous clocking which helps
to fetch changes up to fea9cf321c916e9372874e6f2af1bf0b5beb89fb:
fsi: Move various master definitions to a common header (2018-07-12 12:06:02
+1000)
----
Benjamin Herrenschmidt (17):
fsi: sbefifo: Remove unneeded semicolon
fsi: scom: Add mutex aro
to fetch changes up to fea9cf321c916e9372874e6f2af1bf0b5beb89fb:
fsi: Move various master definitions to a common header (2018-07-12 12:06:02
+1000)
----
Benjamin Herrenschmidt (17):
fsi: sbefifo: Remove unneeded semicolon
fsi: scom: Add mutex aro
On Thu, 2018-06-28 at 13:41 +0930, Joel Stanley wrote:
> On 27 June 2018 at 08:55, Benjamin Herrenschmidt
> wrote:
> > This adds a few more tracepoints that have proven useful when
> > debugging issues with the FSI bus.
> >
> > Signed-off-by: Benjamin Herrens
On Thu, 2018-06-28 at 13:41 +0930, Joel Stanley wrote:
> On 27 June 2018 at 08:55, Benjamin Herrenschmidt
> wrote:
> > This adds a few more tracepoints that have proven useful when
> > debugging issues with the FSI bus.
> >
> > Signed-off-by: Benjamin Herrens
On Wed, 2018-07-11 at 14:04 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> > provide remote management of (primarily) server platforms. BMCs are
> > often tightly coupled to
On Wed, 2018-07-11 at 14:04 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> > provide remote management of (primarily) server platforms. BMCs are
> > often tightly coupled to
On Tue, 2018-07-10 at 16:55 -0700, Linus Torvalds wrote:
> On Tue, Jul 10, 2018 at 4:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > > I like that fix, which should make this patch obsolete, right?
> >
> > Yes, for that specific issue, but Linus seemed to think
On Tue, 2018-07-10 at 16:55 -0700, Linus Torvalds wrote:
> On Tue, Jul 10, 2018 at 4:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > > I like that fix, which should make this patch obsolete, right?
> >
> > Yes, for that specific issue, but Linus seemed to think
On Tue, 2018-07-10 at 12:52 -0500, Eddie James wrote:
>
> On 07/09/2018 05:41 PM, Wolfram Sang wrote:
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> >
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
On Tue, 2018-07-10 at 12:52 -0500, Eddie James wrote:
>
> On 07/09/2018 05:41 PM, Wolfram Sang wrote:
> > > + cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
> >
> > I just noticed this and wonder: Don't you need the LSB of the address?
> > It is not the RW flag, this is encoded in msg->flags.
On Tue, 2018-07-10 at 16:55 +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 10, 2018 at 09:44:33AM +1000, Benjamin Herrenschmidt wrote:
> > On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> > > No, kobject_get() should never happen on a 0 refcount object. Tha
On Tue, 2018-07-10 at 16:55 +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 10, 2018 at 09:44:33AM +1000, Benjamin Herrenschmidt wrote:
> > On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> > > No, kobject_get() should never happen on a 0 refcount object. Tha
On Tue, 2018-07-10 at 16:55 +0200, Greg Kroah-Hartman wrote:
>
> > +/**
> > + * kobject_has_children - Returns whether a kobject has children.
> > + * @kobj: the object to test
> > + *
> > + * This will return whether a kobject has other kobjects as children.
> > + *
> > + * It does NOT account
On Tue, 2018-07-10 at 16:55 +0200, Greg Kroah-Hartman wrote:
>
> > +/**
> > + * kobject_has_children - Returns whether a kobject has children.
> > + * @kobj: the object to test
> > + *
> > + * This will return whether a kobject has other kobjects as children.
> > + *
> > + * It does NOT account
On Mon, 2018-07-09 at 17:33 -0700, Linus Torvalds wrote:
> On Mon, Jul 9, 2018 at 5:29 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directory between
> > the parent device and the new device with the class name
On Mon, 2018-07-09 at 17:33 -0700, Linus Torvalds wrote:
> On Mon, Jul 9, 2018 at 5:29 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directory between
> > the parent device and the new device with the class name
rol reaches end of non-void
> function [-Werror=return-type]
>
> Using a plain BUG() is easier here and avoids the problem.
>
> Fixes: 44ddf559d579 ("gpio: aspeed: Rework register type accessors")
> Signed-off-by: Arnd Bergmann
Acked-by: Benjamin Herrenschmidt
Linu
rol reaches end of non-void
> function [-Werror=return-type]
>
> Using a plain BUG() is easier here and avoids the problem.
>
> Fixes: 44ddf559d579 ("gpio: aspeed: Rework register type accessors")
> Signed-off-by: Arnd Bergmann
Acked-by: Benjamin Herrenschmidt
Linu
for this. It appears that this was
in fact the intent of the function, but the implementation was
wrong.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/base/core.c | 2 ++
include/linux/kobject.h | 17 +
2 files changed, 19 insertions(+)
diff --git a/drivers/base/core.c b
for this. It appears that this was
in fact the intent of the function, but the implementation was
wrong.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/base/core.c | 2 ++
include/linux/kobject.h | 17 +
2 files changed, 19 insertions(+)
diff --git a/drivers/base/core.c b
On Sat, 2018-07-07 at 18:51 +0200, Greg Kroah-Hartman wrote:
>
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index b610816eb887..e9eff2099896 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1517,11 +1517,13 @@ static struct kobject
On Sat, 2018-07-07 at 18:51 +0200, Greg Kroah-Hartman wrote:
>
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index b610816eb887..e9eff2099896 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1517,11 +1517,13 @@ static struct kobject
On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> No, kobject_get() should never happen on a 0 refcount object. That
> being said, the code does allow it, so if things are messed up, it will
> happen. I think that change happened when the switch to refcount_t
> occured, before then
On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> No, kobject_get() should never happen on a 0 refcount object. That
> being said, the code does allow it, so if things are messed up, it will
> happen. I think that change happened when the switch to refcount_t
> occured, before then
On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
>
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> >
> > I can add a vendor but what should it be ? aspeed
On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
>
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> >
> > I can add a vendor but what should it be ? aspeed
On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI p
On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI p
On Tue, 2018-07-03 at 16:21 -0500, Eddie James wrote:
> There was no unlock of the FFDC mutex.
>
> Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
> Signed-off-by: Eddie James
Thanks.
Cheers,
Ben.
> ---
> drivers/fsi/fsi-sbefifo.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Tue, 2018-07-03 at 16:21 -0500, Eddie James wrote:
> There was no unlock of the FFDC mutex.
>
> Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
> Signed-off-by: Eddie James
Thanks.
Cheers,
Ben.
> ---
> drivers/fsi/fsi-sbefifo.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Tue, 2018-07-03 at 08:46 -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 03, 2018 at 03:22:47PM +1000, Benjamin Herrenschmidt wrote:
> > +bool kernfs_has_children(struct kernfs_node *kn)
> > +{
> > + bool has_children = false;
> > + struct kernfs_nod
On Tue, 2018-07-03 at 08:46 -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 03, 2018 at 03:22:47PM +1000, Benjamin Herrenschmidt wrote:
> > +bool kernfs_has_children(struct kernfs_node *kn)
> > +{
> > + bool has_children = false;
> > + struct kernfs_nod
On Tue, 2018-07-03 at 16:31 +0200, Greg KH wrote:
> On Wed, Jul 04, 2018 at 12:16:49AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2018-07-03 at 09:50 +0200, Greg KH wrote:
> > > On Tue, Jul 03, 2018 at 05:04:10PM +1000, Andrew Jeffery wrote:
> > > >
On Tue, 2018-07-03 at 16:31 +0200, Greg KH wrote:
> On Wed, Jul 04, 2018 at 12:16:49AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2018-07-03 at 09:50 +0200, Greg KH wrote:
> > > On Tue, Jul 03, 2018 at 05:04:10PM +1000, Andrew Jeffery wrote:
> > > >
ko] undefined!
>
> Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Guenter Roeck
Thanks Guenter ! I'll include this into the fsi tree.
(I was wondering what that kbuild report on sparc64 was about...
ko] undefined!
>
> Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Guenter Roeck
Thanks Guenter ! I'll include this into the fsi tree.
(I was wondering what that kbuild report on sparc64 was about...
On Tue, 2018-07-03 at 09:50 +0200, Greg KH wrote:
> On Tue, Jul 03, 2018 at 05:04:10PM +1000, Andrew Jeffery wrote:
> > Signed-off-by: Andrew Jeffery
> > ---
>
> I can't take patches without any changelog text at all :(
Greg (and replying to your other comments as well)...
This is an RFC
On Tue, 2018-07-03 at 09:50 +0200, Greg KH wrote:
> On Tue, Jul 03, 2018 at 05:04:10PM +1000, Andrew Jeffery wrote:
> > Signed-off-by: Andrew Jeffery
> > ---
>
> I can't take patches without any changelog text at all :(
Greg (and replying to your other comments as well)...
This is an RFC
On Tue, 2018-07-03 at 12:39 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> > wrote:
> > >
> > > It's whitespace-damaged on purpose. It's probably broken
On Tue, 2018-07-03 at 12:39 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> > wrote:
> > >
> > > It's whitespace-damaged on purpose. It's probably broken
On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> wrote:
> >
> > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> > this might work, but
On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> wrote:
> >
> > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> > this might work, but
On Mon, 2018-07-02 at 19:15 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 5:57 PM Benjamin Herrenschmidt
> wrote:
> >
> > I'll have a look see if I can find a way to check that the sysfs dir is
> > empty without adding that childcount, that would at least al
On Mon, 2018-07-02 at 19:15 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 5:57 PM Benjamin Herrenschmidt
> wrote:
> >
> > I'll have a look see if I can find a way to check that the sysfs dir is
> > empty without adding that childcount, that would at least al
On Mon, 2018-07-02 at 12:24 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 3:23 AM Benjamin Herrenschmidt
> wrote:
> >
> > Let me try one last ditch attempt to convince you using maybe a
> > different perspective: this is how sysfs is intended to work and how
>
On Mon, 2018-07-02 at 12:24 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 3:23 AM Benjamin Herrenschmidt
> wrote:
> >
> > Let me try one last ditch attempt to convince you using maybe a
> > different perspective: this is how sysfs is intended to work and how
>
On Mon, 2018-07-02 at 14:06 +0100, Robin Murphy wrote:
.../...
Thanks Robin, I was starting to depair anybody would reply ;-)
> > AFAIK, dma_alloc_coherent() is defined (Documentation/DMA-API-
> > HOWTO.txt) as always allocating to the next power-of-2 order, so we
> > should never have the
On Mon, 2018-07-02 at 14:06 +0100, Robin Murphy wrote:
.../...
Thanks Robin, I was starting to depair anybody would reply ;-)
> > AFAIK, dma_alloc_coherent() is defined (Documentation/DMA-API-
> > HOWTO.txt) as always allocating to the next power-of-2 order, so we
> > should never have the
On Mon, 2018-07-02 at 09:36 +1000, Benjamin Herrenschmidt wrote:
> > No. See above. The reason I think your patch 2/2 is wrong is that is
> > actually *breaks* the above model, exactly because of that thing that
> > you hatre.
> >
> > The explicit removal is
On Mon, 2018-07-02 at 09:36 +1000, Benjamin Herrenschmidt wrote:
> > No. See above. The reason I think your patch 2/2 is wrong is that is
> > actually *breaks* the above model, exactly because of that thing that
> > you hatre.
> >
> > The explicit removal is
On Sun, 2018-07-01 at 10:04 -0700, Linus Torvalds wrote:
> On Sun, Jul 1, 2018 at 12:16 AM Benjamin Herrenschmidt
> wrote:
> >
> > I suspect you didn't read it my entire argument or I wasn't clear
> > enough :-) This is actually the crux of the problem:
> >
> &g
On Sun, 2018-07-01 at 10:04 -0700, Linus Torvalds wrote:
> On Sun, Jul 1, 2018 at 12:16 AM Benjamin Herrenschmidt
> wrote:
> >
> > I suspect you didn't read it my entire argument or I wasn't clear
> > enough :-) This is actually the crux of the problem:
> >
> &g
On Sun, 2018-07-01 at 10:04 -0700, Linus Torvalds wrote:
>
> So this is where we disagree:
>
> > Thus in that scenario the "last minute" kobject_release() done by the
> > last kobject_put() will be effectively unprotected from for example the
> > gdp_mutex (in the case of the gluedirs) or
On Sun, 2018-07-01 at 10:04 -0700, Linus Torvalds wrote:
>
> So this is where we disagree:
>
> > Thus in that scenario the "last minute" kobject_release() done by the
> > last kobject_put() will be effectively unprotected from for example the
> > gdp_mutex (in the case of the gluedirs) or
On Sat, 2018-06-30 at 20:57 -0700, Linus Torvalds wrote:
> On Sat, Jun 30, 2018 at 8:42 PM Benjamin Herrenschmidt
> wrote:
> >
> > But what if something *else* still holds a reference to the kobject ?
> > It could be anything really... t
>
> But that's fine.
On Sat, 2018-06-30 at 20:57 -0700, Linus Torvalds wrote:
> On Sat, Jun 30, 2018 at 8:42 PM Benjamin Herrenschmidt
> wrote:
> >
> > But what if something *else* still holds a reference to the kobject ?
> > It could be anything really... t
>
> But that's fine.
(This is a resend with lkml added for background & archival purposes)
On Sat, 2018-06-30 at 12:29 -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:19 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directo
(This is a resend with lkml added for background & archival purposes)
On Sat, 2018-06-30 at 12:29 -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:19 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directo
On Sat, 2018-06-30 at 19:18 -0700, Linus Torvalds wrote:
> On Sat, Jun 30, 2018 at 7:07 PM Linus Torvalds
> wrote:
> >
> > Those locks won't protect kobj races in _general_ (ie there is no
> > locking between two totally unrelated buses), but they *should*
> > serialize the case of a device
On Sat, 2018-06-30 at 19:18 -0700, Linus Torvalds wrote:
> On Sat, Jun 30, 2018 at 7:07 PM Linus Torvalds
> wrote:
> >
> > Those locks won't protect kobj races in _general_ (ie there is no
> > locking between two totally unrelated buses), but they *should*
> > serialize the case of a device
On Sat, 2018-06-30 at 19:07 -0700, Linus Torvalds wrote:
> [ Ben - feel free to post the missing emails to lkml too ]
>
> On Sat, Jun 30, 2018 at 6:56 PM Benjamin Herrenschmidt
> wrote:
> >
> > On Sat, 2018-06-30 at 12:29 -0700, Linus Torvalds wrote:
> > >
On Sat, 2018-06-30 at 19:07 -0700, Linus Torvalds wrote:
> [ Ben - feel free to post the missing emails to lkml too ]
>
> On Sat, Jun 30, 2018 at 6:56 PM Benjamin Herrenschmidt
> wrote:
> >
> > On Sat, 2018-06-30 at 12:29 -0700, Linus Torvalds wrote:
> > >
On Sat, 2018-06-30 at 11:04 +1000, Benjamin Herrenschmidt wrote:
> I had a look (see my other email). It's non-trivial. We can still look
> into it, but from what I gathered of how sysfs works, it's based on
> kernfs which doesn't have the kobjects nor access to the referenc
On Sat, 2018-06-30 at 11:04 +1000, Benjamin Herrenschmidt wrote:
> I had a look (see my other email). It's non-trivial. We can still look
> into it, but from what I gathered of how sysfs works, it's based on
> kernfs which doesn't have the kobjects nor access to the referenc
On Fri, 2018-06-29 at 23:27 +0300, Andy Shevchenko wrote:
> On Fri, Jun 29, 2018 at 12:14 PM, Linus Walleij
> wrote:
>
> > I wonder if it is easy to find these cases and replace them with
> > this neat function...
>
> Would be reasonable easy by using coccinelle.
For the obvious ones yes. A
On Fri, 2018-06-29 at 23:27 +0300, Andy Shevchenko wrote:
> On Fri, Jun 29, 2018 at 12:14 PM, Linus Walleij
> wrote:
>
> > I wonder if it is easy to find these cases and replace them with
> > this neat function...
>
> Would be reasonable easy by using coccinelle.
For the obvious ones yes. A
On Fri, 2018-06-29 at 06:56 -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:22 PM Benjamin Herrenschmidt
> wrote:
> >
> > This fixes it by instead doing an explicit kobject_del() when
> > the glue dir is empty, by keeping track of the number of
> > child de
On Fri, 2018-06-29 at 06:56 -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:22 PM Benjamin Herrenschmidt
> wrote:
> >
> > This fixes it by instead doing an explicit kobject_del() when
> > the glue dir is empty, by keeping track of the number of
> > child de
301 - 400 of 5350 matches
Mail list logo
