On 19-06-18, 15:20, Marek Szyprowski wrote:
> The reported residue is already calculated in BURST unit granularity, so
> advertise this capability properly to other devices in the system.
Applied, thanks
--
~Vinod
On 19-06-18, 15:20, Marek Szyprowski wrote:
> The reported residue is already calculated in BURST unit granularity, so
> advertise this capability properly to other devices in the system.
Applied, thanks
--
~Vinod
On Tue, Jun 26, 2018 at 09:57:07AM +0100, David Howells wrote:
> Andrei Vagin wrote:
>
> > > > > - mnt = kern_mount_data(_fs_type, ns, 0);
> > >
> > > Here ns->user_ns and get_current_cred()->user_ns are not always equal
> >
> > What do you think about the attached patch?
> > ...
> > -
On Tue, Jun 26, 2018 at 09:57:07AM +0100, David Howells wrote:
> Andrei Vagin wrote:
>
> > > > > - mnt = kern_mount_data(_fs_type, ns, 0);
> > >
> > > Here ns->user_ns and get_current_cred()->user_ns are not always equal
> >
> > What do you think about the attached patch?
> > ...
> > -
. Amigoids screamed. I tried
to tell them I was there, it was my machine, and 1.1 was, indeed, crap.
{o.o}
On 20180627 02:00, Michael Schmitz wrote:
Joanne,
I'm not at all allergic to avoiding RDB at all cost for new disks. If
AmigaOS 4.1 supports more recent partition formats, all the better.
T
. Amigoids screamed. I tried
to tell them I was there, it was my machine, and 1.1 was, indeed, crap.
{o.o}
On 20180627 02:00, Michael Schmitz wrote:
Joanne,
I'm not at all allergic to avoiding RDB at all cost for new disks. If
AmigaOS 4.1 supports more recent partition formats, all the better.
T
The real name of the board is ZedBoard, from Avnet
Signed-off-by: Luis Araneda
---
Documentation/devicetree/bindings/arm/xilinx.txt | 2 +-
arch/arm/boot/dts/Makefile| 2 +-
arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} | 2 +-
3 files changed, 3
The real name of the board is ZedBoard, from Avnet
Signed-off-by: Luis Araneda
---
Documentation/devicetree/bindings/arm/xilinx.txt | 2 +-
arch/arm/boot/dts/Makefile| 2 +-
arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} | 2 +-
3 files changed, 3
This series attempts to standardize device naming and improve
its information for better identification
The values of the "compatible" and "model" device-tree properties
are corrected for some devices, adding complementary information
when necessary
Additionally, a device-tree file is renamed to
The bindings were missing when adding the device-tree files
Also, improve description of existing boards
Signed-off-by: Luis Araneda
---
.../devicetree/bindings/arm/xilinx.txt| 22 +--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git
The value "zynq" isn't officially part of the model on any board.
Additionally, the value is redundant as it's included in a
subsequent value of the property.
Signed-off-by: Luis Araneda
---
.../devicetree/bindings/arm/xilinx.txt| 22 +--
arch/arm/boot/dts/zynq-cc108.dts
This series attempts to standardize device naming and improve
its information for better identification
The values of the "compatible" and "model" device-tree properties
are corrected for some devices, adding complementary information
when necessary
Additionally, a device-tree file is renamed to
The bindings were missing when adding the device-tree files
Also, improve description of existing boards
Signed-off-by: Luis Araneda
---
.../devicetree/bindings/arm/xilinx.txt| 22 +--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git
The value "zynq" isn't officially part of the model on any board.
Additionally, the value is redundant as it's included in a
subsequent value of the property.
Signed-off-by: Luis Araneda
---
.../devicetree/bindings/arm/xilinx.txt| 22 +--
arch/arm/boot/dts/zynq-cc108.dts
Replace the current value of the model property by a more accurate
description of each board (which includes the manufacturer), as some
of the boards had the same value ("Xilinx Zynq")
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
Replace the current value of the model property by a more accurate
description of each board (which includes the manufacturer), as some
of the boards had the same value ("Xilinx Zynq")
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
Both boards are made by Avnet, Inc.
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
Both boards are made by Avnet, Inc.
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
On Wed, 27 Jun 2018 20:54:34 +0200,
Guy Chronister wrote:
>
> Signed-off-by: Guy Chronister
The code change itself is good, but the subject is wrong, and there is
no changelog texts. Please describe what it really fixes. It's not
about typo fix, but it fixes a real bug, and this has to be
On Wed, 27 Jun 2018 20:54:34 +0200,
Guy Chronister wrote:
>
> Signed-off-by: Guy Chronister
The code change itself is good, but the subject is wrong, and there is
no changelog texts. Please describe what it really fixes. It's not
about typo fix, but it fixes a real bug, and this has to be
Andrew Morton writes:
> On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying"
> wrote:
>
>> Andrew Morton writes:
>>
>> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying"
>> > wrote:
>> >
>> >> This is the final step of THP (Transparent Huge Page) swap
>> >> optimization. After the first and
Andrew Morton writes:
> On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying"
> wrote:
>
>> Andrew Morton writes:
>>
>> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying"
>> > wrote:
>> >
>> >> This is the final step of THP (Transparent Huge Page) swap
>> >> optimization. After the first and
On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" wrote:
> Andrew Morton writes:
>
> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying"
> > wrote:
> >
> >> This is the final step of THP (Transparent Huge Page) swap
> >> optimization. After the first and second step, the splitting huge
> >>
On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" wrote:
> Andrew Morton writes:
>
> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying"
> > wrote:
> >
> >> This is the final step of THP (Transparent Huge Page) swap
> >> optimization. After the first and second step, the splitting huge
> >>
Andrew Morton writes:
> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote:
>
>> This is the final step of THP (Transparent Huge Page) swap
>> optimization. After the first and second step, the splitting huge
>> page is delayed from almost the first step of swapout to after swapout
>> has
Andrew Morton writes:
> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote:
>
>> This is the final step of THP (Transparent Huge Page) swap
>> optimization. After the first and second step, the splitting huge
>> page is delayed from almost the first step of swapout to after swapout
>> has
On Sat, Apr 14, 2018 at 3:07 AM, syzbot
wrote:
> syzbot has found reproducer for the following crash on upstream commit
> 1bad9ce155a7c010a9a5f3261ad12a6a8eccfb2c (Fri Apr 13 19:27:11 2018 +)
> Merge tag 'sh-for-4.17' of git://git.libc.org/linux-sh
> syzbot dashboard link:
>
On Sat, Apr 14, 2018 at 3:07 AM, syzbot
wrote:
> syzbot has found reproducer for the following crash on upstream commit
> 1bad9ce155a7c010a9a5f3261ad12a6a8eccfb2c (Fri Apr 13 19:27:11 2018 +)
> Merge tag 'sh-for-4.17' of git://git.libc.org/linux-sh
> syzbot dashboard link:
>
On Thu, Jun 28, 2018 at 7:24 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80
> kernel config:
On Thu, Jun 28, 2018 at 7:24 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80
> kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80
kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370
Hello,
syzbot found the following crash on:
HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80
kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370
On Thu, Jun 28, 2018 at 11:06:13AM +0800, Sean Wang wrote:
> On Wed, 2018-06-27 at 20:04 +0300, Andy Shevchenko wrote:
> > On Wed, Jun 27, 2018 at 7:59 PM, Andy Shevchenko
> > wrote:
> > > On Wed, Jun 27, 2018 at 8:43 AM, wrote:
> > >> From: Sean Wang
> > >> +#include
> > >> +#include
> >
On Thu, Jun 28, 2018 at 11:06:13AM +0800, Sean Wang wrote:
> On Wed, 2018-06-27 at 20:04 +0300, Andy Shevchenko wrote:
> > On Wed, Jun 27, 2018 at 7:59 PM, Andy Shevchenko
> > wrote:
> > > On Wed, Jun 27, 2018 at 8:43 AM, wrote:
> > >> From: Sean Wang
> > >> +#include
> > >> +#include
> >
This patch implements the 'pattern_set', 'pattern_get' and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
Changes from v1:
- No updates.
---
drivers/leds/leds-sc27xx-bltc.c | 160 +++
1 file changed, 160
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support such functionality as well as a new device
This patch implements the 'pattern_set', 'pattern_get' and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
Changes from v1:
- No updates.
---
drivers/leds/leds-sc27xx-bltc.c | 160 +++
1 file changed, 160
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support such functionality as well as a new device
On Wed, Jun 27, 2018 at 07:51:34PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 27, 2018 at 08:57:21AM -0700, Paul E. McKenney wrote:
> > > Another variant, which simply skips the wakeup whever ran on an offline
> > > CPU, relying on the wakeup from rcutree_migrate_callbacks() right after
> > > the
On Wed, Jun 27, 2018 at 07:51:34PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 27, 2018 at 08:57:21AM -0700, Paul E. McKenney wrote:
> > > Another variant, which simply skips the wakeup whever ran on an offline
> > > CPU, relying on the wakeup from rcutree_migrate_callbacks() right after
> > > the
On Wed, Jun 27, 2018 at 11:27:26AM -0700, Joel Fernandes wrote:
[..]
> > > > s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
> > > >
> > >
> > > I agree with Peter's suggestions for both the verbiage reduction in the
> > > comments in the header, as the new code he is proposing is more
> > >
On Wed, Jun 27, 2018 at 11:27:26AM -0700, Joel Fernandes wrote:
[..]
> > > > s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
> > > >
> > >
> > > I agree with Peter's suggestions for both the verbiage reduction in the
> > > comments in the header, as the new code he is proposing is more
> > >
Hi Ben,
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
Hi Ben,
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
Hi Miquel,
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Wednesday, June 27, 2018 8:53 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
Hi Miquel,
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Wednesday, June 27, 2018 8:53 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote:
> This is the final step of THP (Transparent Huge Page) swap
> optimization. After the first and second step, the splitting huge
> page is delayed from almost the first step of swapout to after swapout
> has been finished. In this step,
On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote:
> This is the final step of THP (Transparent Huge Page) swap
> optimization. After the first and second step, the splitting huge
> page is delayed from almost the first step of swapout to after swapout
> has been finished. In this step,
On Wed, 27 Jun 2018 21:18:34 -0700 Joe Perches wrote:
> On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote:
> > On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote:
> >
> > > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote:
> > > > I know I'll regret it.
> > >
> > > This wasn't
On Wed, 27 Jun 2018 21:18:34 -0700 Joe Perches wrote:
> On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote:
> > On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote:
> >
> > > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote:
> > > > I know I'll regret it.
> > >
> > > This wasn't
On Wed, Jun 27, 2018 at 9:24 PM Andrey Smirnov wrote:
>
> ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
Ugh, the description should read RDU2, not RDU1. Will fix in v2,
tomorrow. Sorry about that.
Thanks,
Andrey Smirnov
> corresponding nodes to make them availible.
>
> Cc: Fabio
On Wed, Jun 27, 2018 at 9:24 PM Andrey Smirnov wrote:
>
> ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
Ugh, the description should read RDU2, not RDU1. Will fix in v2,
tomorrow. Sorry about that.
Thanks,
Andrey Smirnov
> corresponding nodes to make them availible.
>
> Cc: Fabio
Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by
usbh1phy, but is not referenced by that node. Fix that.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by
usbh1phy, but is not referenced by that node. Fix that.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
There's already a USB PHY with reg of zero on that bus - usbphy0, used
by usbotg (included from imx51.dtsi). Move usbh1phy to @1 avoid
address collision.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
There's already a USB PHY with reg of zero on that bus - usbphy0, used
by usbotg (included from imx51.dtsi). Move usbh1phy to @1 avoid
address collision.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
Hi Thierry,
On 6/27/2018 3:01 PM, Thierry Escande wrote:
> Hi Sricharan,
>
> On 19/06/2018 15:45, Sricharan R wrote:
>> Sricharan R (2):
>> clk: qcom: Add safe switch hook for krait mux clocks
>> dt-bindings: cpufreq: Document operating-points-v2-krait-cpu
>>
>> Stephen Boyd (12):
>>
Hi Thierry,
On 6/27/2018 3:01 PM, Thierry Escande wrote:
> Hi Sricharan,
>
> On 19/06/2018 15:45, Sricharan R wrote:
>> Sricharan R (2):
>> clk: qcom: Add safe switch hook for krait mux clocks
>> dt-bindings: cpufreq: Document operating-points-v2-krait-cpu
>>
>> Stephen Boyd (12):
>>
RAVE SP found on RDU2 implements backlight control compatible with the
rave-sp-backlight driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc:
ZII's RDU1s come with up to 3 EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc:
ZII's RDU1s come with up to 3 EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc:
RAVE SP found on RDU2 implements backlight control compatible with the
rave-sp-backlight driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc:
RAVE SP found on RDU2 implements power button control compatible with
the rave-sp-pwrbutton driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc:
ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Shawn:
These are patches adding the rest of RAVE SP child nodes covering all
the rest of currently supported MFD cells. There's more to be added,
once more drivers get accepted upstream.
The bindings three drivers mentioned are availible in:
RAVE SP found on RDU2 implements power button control compatible with
the rave-sp-pwrbutton driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc:
ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Shawn:
These are patches adding the rest of RAVE SP child nodes covering all
the rest of currently supported MFD cells. There's more to be added,
once more drivers get accepted upstream.
The bindings three drivers mentioned are availible in:
On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote:
> On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote:
>
> > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote:
> > > I know I'll regret it.
> >
> > This wasn't applied back in February?
>
> Well I thought it was, but I can't find
On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote:
> On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote:
>
> > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote:
> > > I know I'll regret it.
> >
> > This wasn't applied back in February?
>
> Well I thought it was, but I can't find
Santosh,
On Friday 22 June 2018 03:46 PM, Kishon Vijay Abraham I wrote:
> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
> binding.
>
> I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
> Everyone who use a custom .config should also enable
>
Santosh,
On Friday 22 June 2018 03:46 PM, Kishon Vijay Abraham I wrote:
> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
> binding.
>
> I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
> Everyone who use a custom .config should also enable
>
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> This switches away from userspace bitbanging to kernel FSI
> using the coprocessor.
>
> Signed-off-by: Benjamin Herrenschmidt
As with the other patch, I will take this through the ASPEED SoC tree
once we've got acks on the bindings.
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> This switches away from userspace bitbanging to kernel FSI
> using the coprocessor.
>
> Signed-off-by: Benjamin Herrenschmidt
As with the other patch, I will take this through the ASPEED SoC tree
once we've got acks on the bindings.
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> Signed-off-by: Benjamin Herrenschmidt
I will take this through the ASPEED SoC tree once we've got acks on
the bindings.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 15 +--
> 1 file changed, 13
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> Signed-off-by: Benjamin Herrenschmidt
I will take this through the ASPEED SoC tree once we've got acks on
the bindings.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 15 +--
> 1 file changed, 13
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> The embedded struct device needs a release function to be
> able to successfully remove the driver.
>
> We remove the devm_gpiod_put() as they are unnecessary
> (the resources will be released automatically) and because
>
On 27 June 2018 at 08:56, 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 protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
>
> Thus it's a drop-in
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> The embedded struct device needs a release function to be
> able to successfully remove the driver.
>
> We remove the devm_gpiod_put() as they are unnecessary
> (the resources will be released automatically) and because
>
On 27 June 2018 at 08:56, 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 protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
>
> Thus it's a drop-in
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Some definitions are generic to the FSI protocol or any
> give master implementation. Rename them to remove the
> "GPIO" prefix in preparation for moving them to a common
> header.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by:
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> This moves the definitions for various protocol details
> (message & response codes, delays etc...) out of
> fsi-master-gpio.c to fsi-master.h in order to share them
> with other master implementations.
>
> Signed-off-by: Benjamin
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Some definitions are generic to the FSI protocol or any
> give master implementation. Rename them to remove the
> "GPIO" prefix in preparation for moving them to a common
> header.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by:
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> This moves the definitions for various protocol details
> (message & response codes, delays etc...) out of
> fsi-master-gpio.c to fsi-master.h in order to share them
> with other master implementations.
>
> Signed-off-by: Benjamin
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 Herrenschmidt
Reviewed-by: Joel Stanley
> ---
> drivers/fsi/fsi-master-gpio.c | 16 ---
>
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 Herrenschmidt
Reviewed-by: Joel Stanley
> ---
> drivers/fsi/fsi-master-gpio.c | 16 ---
>
On 27 June 2018 at 08:53, Benjamin Herrenschmidt
wrote:
> Move fsi_slave_set_smode() and its helpers to before it's
> first user and remove the corresponding forward declaration.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:53, Benjamin Herrenschmidt
wrote:
> Move fsi_slave_set_smode() and its helpers to before it's
> first user and remove the corresponding forward declaration.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> To configure the send and echo delays
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Those values control the amount of "dummy" clocks between commands and
> between a command and its response.
>
> This adds a way to configure them from sysfs (to be later extended to
> defaults in the device-tree). The default remains 16
On 27 June 2018 at 08:53, Benjamin Herrenschmidt
wrote:
> What the driver called "FSI_GPIO_PRIME_SLAVE_CLOCKS" is what
> the FSI spec calls tSendDelay and should be 16 clocks by
> default.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> To configure the send and echo delays
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Those values control the amount of "dummy" clocks between commands and
> between a command and its response.
>
> This adds a way to configure them from sysfs (to be later extended to
> defaults in the device-tree). The default remains 16
On 27 June 2018 at 08:53, Benjamin Herrenschmidt
wrote:
> What the driver called "FSI_GPIO_PRIME_SLAVE_CLOCKS" is what
> the FSI spec calls tSendDelay and should be 16 clocks by
> default.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
> -Original Message-
> From: stable-ow...@vger.kernel.org On Behalf
> Of Ben Hutchings
[..]
> 3.18 and 4.4 are still missing this important fix to early parameter
> parsing:
>
> commit 02afeaae9843733a39cd9b11053748b2d1dc5ae7
> Author: Dave Hansen
> Date: Tue Dec 22 14:52:38 2015
> -Original Message-
> From: stable-ow...@vger.kernel.org On Behalf
> Of Ben Hutchings
[..]
> 3.18 and 4.4 are still missing this important fix to early parameter
> parsing:
>
> commit 02afeaae9843733a39cd9b11053748b2d1dc5ae7
> Author: Dave Hansen
> Date: Tue Dec 22 14:52:38 2015
Hello Darrick,
Lockdep is reporting a deadlock with following trace. Saw this on my
powerpc vm with 4GB of ram, running Linus/master kernel. Though, I
don't have exact testcase to reproduce it. Is this something known?
[ 1797.620389] ==
[
Hello Darrick,
Lockdep is reporting a deadlock with following trace. Saw this on my
powerpc vm with 4GB of ram, running Linus/master kernel. Though, I
don't have exact testcase to reproduce it. Is this something known?
[ 1797.620389] ==
[
1 - 100 of 1028 matches
Mail list logo
