6x, enable the timer after requesting the irq, consistent with
mvme147.
Cc: Michael Pavone
Fixes: 7529b90d051e ("m68k: mvme147: Handle timer counter overflow")
Fixes: 1a8b8782 ("m68k: mvme16x: Handle timer counter overflow")
Reported-and-tested-by: Michael Pavone
Signed-off-
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> Hi all,
>
> we've been trying to get rid of the legacy ide driver for a while now,
> and finally scheduled a removal for 2021, which is three month old now.
>
> In general distros and most defconfigs have switched to libata long ago,
> but there
On Sun, 3 Jan 2021, Jens Axboe wrote:
> >
> > This patch was sent in September and subsequently resent in November.
> > I've since learned that the maintainer has been ill. What's the best
> > way forward for fixes like this?
>
> I can queue it up.
>
That would be great.
On Wed, 24 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> Realtime requirement is definitely a true requirement on ARM Linux.
>
> I once talked/worked with some guys who were using ARM for realtime
> system.
> The feasible approaches include:
> 1. Dual OS(RTOS + Linux): e.g. QNX+Linux
On Tue, 23 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > Regarding m68k, your analysis overlooks the timing issue. E.g. patch
> > 11/32 could be a problem because removing the irqsave would allow PDMA
> > transfers to be interrupted. Aside from the timing issues, I agree
> > with your
On Mon, 22 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Thu, 18 Feb 2021, Xiaofei Tan wrote:
> >
> > > On 2021/2/9 13:06, Finn Thain wrote:
> > > > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
>
On Thu, 18 Feb 2021, Arnd Bergmann wrote:
> On Thu, Feb 18, 2021 at 6:30 AM Finn Thain wrote:
> > On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > That scenario se
On Thu, 18 Feb 2021, Xiaofei Tan wrote:
> On 2021/2/9 13:06, Finn Thain wrote:
> > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote:
> > > >
> > > > > Replace spin_lock_irqsave
On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > >
> > > So what is really confusing and a pain to me is that: For years
> > > people like me have been writing device drivers with the idea that
> > > irq handlers run with
On Mon, 15 Feb 2021, Andy Shevchenko wrote:
> On Sun, Feb 14, 2021 at 7:12 AM Finn Thain wrote:
> > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > So what is really confusing and a pain to me is that:
> > > For years people like me have
On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> So what is really confusing and a pain to me is that:
> For years people like me have been writing device drivers
> with the idea that irq handlers run with interrupts
> disabled after those commits in genirq. So I don't need
> to care
On Fri, 12 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> > -Original Message-
> > From: Finn Thain [mailto:fth...@telegraphics.com.au]
> > Sent: Friday, February 12, 2021 12:57 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: tanxiaofei ; j...@linux.ibm.co
On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > > TBH, that is why m68k is so confusing. irqs_disabled() on m68k
> > > > > should just reflect the
On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> Actually in m68k, I also saw its IRQ entry disabled interrupts by
> ' move#0x2700,%sr /* disable intrs */'
>
> arch/m68k/include/asm/entry.h:
>
> .macro SAVE_ALL_SYS
> move#0x2700,%sr /*
On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > > > There is no warning from m68k builds. That's because
> > > > > > arch_irqs_disabled() returns
On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > >
> > > > There is no warning from m68k builds. That's because
> > > > arch_irqs_disabled() returns true when the IPL is non-zero.
> > >
> > > So for m68k, the case is
> > >
On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > > sonic_interrupt() uses an irq lock within an interrupt handler
> > > > > to avoid issues relating to this. This kind of locking may be
> > > > > needed in the drivers
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > sonic_interrupt() uses an irq lock within an interrupt handler to
> > > avoid issues relating to this. This kind of locking may be needed in
> > > the drivers you are trying to patch. Or it might not. Apparently,
> > > no-one has
On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote:
> > > > > >
> > > > > > > Replace spin_lock_irqsave with
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote:
> > > >
> > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI
> > > > > drivers. There are no function changes, but
On Tue, 9 Feb 2021, tanxiaofei wrote:
> Hi Finn,
> Thanks for reviewing the patch set.
>
> On 2021/2/8 15:57, Finn Thain wrote:
> > On Sun, 7 Feb 2021, Xiaofei Tan wrote:
> >
> > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers.
> > &
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > -Original Message-
> > From: Finn Thain [mailto:fth...@telegraphics.com.au]
> > Sent: Monday, February 8, 2021 8:57 PM
> > To: tanxiaofei
> > Cc: j...@linux.ibm.com; martin.peter...@oracle.com;
> &g
On Sun, 7 Feb 2021, Xiaofei Tan wrote:
> Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers.
> There are no function changes, but may speed up if interrupt happen too
> often.
This change doesn't necessarily work on platforms that support nested
interrupts.
Were you able to
=efa1cdf01850b28c2f6f7035ebd4420259494615
References: commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver")
References: commit cafa0010cd51 ("Raise the minimum required gcc version to
4.6")
Signed-off-by: Finn Thain
---
arch/m68k/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/
On Sat, 16 Jan 2021, Rob Landley wrote:
> Speaking of which, my qemu m68k system has failed to boot ever since commit:
>
> commit f93bfeb55255bddaa16597e187a99ae6131b964a
> Author: Finn Thain
> Date: Sun Jun 28 14:23:12 2020 +1000
>
> macintosh/via-macii: Poll t
On Thu, 14 Jan 2021, Arnd Bergmann wrote:
> I think it's mainly a misunderstanding of what I am trying to do
> in finding the platforms that have been completely abandoned.
Have you tried to identify those drivers and Kconfig symbols in mainline
that are used only by devices that don't function
On Wed, 13 Jan 2021, Arnd Bergmann wrote:
>
> It's usually one of two things that happened before a platform gets
> deleted for good:
>
> * The platform port was (almost) exclusively done by one company
>with a commercial interest in it, and the company shifts its priorities
>for some
On Tue, 12 Jan 2021, John Paul Adrian Glaubitz wrote:
>
> There has to be a healthy balance between hobbyist and commercial use.
>
Yes, both of those, and everything in-between, including for-profit
businesses that serve mostly hobbyists. Also start-up companies that may
never be
On Mon, 4 Jan 2021, Bart Van Assche wrote:
> On 6/16/20 7:07 PM, Finn Thain wrote:
> > On Tue, 16 Jun 2020, Bart Van Assche wrote:
> >> As far as I know the sbp driver only has had one user ever and that
> >> user is no longer user the sbp driver.
> >
> >
Ethernet device for the
XT2000 board.")
Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Signed-off-by: Christophe JAILLET
Signed-off-by: Finn Thain
---
Changed since v3:
- Update commit log.
Changed since v2:
- Dropped whitespace change.
---
drivers/net/et
Hi All,
This patch was sent in September and subsequently resent in November. I've
since learned that the maintainer has been ill. What's the best way
forward for fixes like this?
Regards,
Finn
On Fri, 20 Nov 2020, Finn Thain wrote:
> Unloading the falconide module results in a cr
politely2()
> -> NCR5380_dma_complete()
>-> NCR5380_transfer_pio()
> -> NCR5380_poll_politely()
> - NCR5380_transfer_pio() -> NCR5380_poll_politely
>
> - NCR5380_reselect(), atomic, always called with hostdata spinlock
>
0_poll_politely2()
> -> NCR5380_dma_complete()
>-> NCR5380_transfer_pio()
> -> NCR5380_poll_politely()
> - NCR5380_transfer_pio() -> NCR5380_poll_politely
>
> - NCR5380_reselect(), atomic, always called with hostdata spinlock
>
ingly.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Joshua Thompson
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: Finn Thain
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 867157311dc8..e8
On Fri, 4 Dec 2020, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Fri, Nov 20, 2020 at 5:54 AM Finn Thain wrote:
> > The behaviour of the IOP firmware is not well documented but we do know
> > that IOP message reply data can be used to issue new ADB commands.
> > Use
On Fri, 4 Dec 2020, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Fri, Nov 20, 2020 at 5:54 AM Finn Thain wrote:
> > A recent patch incorrectly altered the adb-iop state machine behaviour
> > and introduced a regression that can appear intermittently as a
> > malf
136046n Tue, 1 Dec 2020, Sebastian Andrzej Siewior wrote:
> On 2020-12-01 17:46:36 [+1100], Finn Thain wrote:
> > The in_interrupt() macro is deprecated. Also, it's usage in
> > NCR5380_poll_politely2() has long been redundant.
>
> So you rely on the assumption that
The in_interrupt() macro is deprecated. Also, it's usage in
NCR5380_poll_politely2() has long been redundant.
Cc: Sebastian Andrzej Siewior
Cc: Ahmed S. Darwish
Cc: Thomas Gleixner
Link: https://lore.kernel.org/r/20201126132952.2287996-1-bige...@linutronix.de
Signed-off-by: Finn Thain
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any case
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain
> wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any c
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> So developers and distributions using Clang can't have
> -Wimplicit-fallthrough enabled because GCC is less strict (which has
> been shown in this thread to lead to bugs)? We'd like to have nice
> things too, you know.
>
Apparently the GCC
On Wed, 25 Nov 2020, Miguel Ojeda wrote:
>
> The C standard has nothing to do with this. We use compiler extensions
> of several kinds, for many years. Even discounting those extensions, the
> kernel is not even conforming to C due to e.g. strict aliasing. I am not
> sure what you are
On Tue, 24 Nov 2020, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at
> > all ... we really shouldn't be wasting maintainer time with it because
> > it has a cost to merge. I'm not
On Mon, 23 Nov 2020, Joe Perches wrote:
> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code
> > generation. That's for the patch author and (unfortunately) for
> > reviewers.
>
> Ideally, t
On Mon, 23 Nov 2020, Miguel Ojeda wrote:
> On Mon, 23 Nov 2020, Finn Thain wrote:
>
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> >
> > >
> > > It isn't that much effort, isn't it? Plus we need to take into
> > > account the future mistakes t
On Sun, 22 Nov 2020, Miguel Ojeda wrote:
>
> It isn't that much effort, isn't it? Plus we need to take into account
> the future mistakes that it might prevent, too.
We should also take into account optimisim about future improvements in
tooling.
> So even if there were zero problems found
On Sun, 22 Nov 2020, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote:
> > We can enforce sysfs_emit going forwards
> > using tools like checkpatch
>
> It's not really possible for checkpatch to find or warn about
> sysfs uses of sprintf. checkpatch is really just
uot;driver core: platform: Clarify that IRQ 0 is
invalid")
Reported-by: Laurent Vivier
Signed-off-by: Finn Thain
---
Changed since v1:
- Add a comment to explain the need for the global structs.
- Expand the commit log to better explain the intention of the patch.
---
arch/m68k/mac/config.c
On Fri, 20 Nov 2020, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Fri, Nov 20, 2020 at 5:51 AM Finn Thain wrote:
> > Don't add platform resources that won't be used. This avoids a
> > recently-added warning from the driver core, that can show up on a
> > multi-platfo
river_data pointer is uninitialized.
Add the missing platform_set_drvdata() call. For clarity, use the
matching platform_get_drvdata() as well.
Cc: Michael Schmitz
Cc: Bartlomiej Zolnierkiewicz
Fixes: 5ed0794cde593 ("m68k/atari: Convert Falcon IDE drivers to platform
drivers")
Revi
Signed-off-by: Finn Thain
---
arch/m68k/Kconfig.machine | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 17e8c3a292d7..054ff6392329 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -30,11
Cc: Joshua Thompson
Signed-off-by: Finn Thain
---
arch/m68k/mac/via.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index 66209cb7696f..4226ae2e7501 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -305,21 +305,6
There's no need to write the same value to the timer latch and timer
counter registers. Values written to the counter registers get stored
in the latches anyway. The write to vT1CH copies the latch values to
the counter.
Cc: Joshua Thompson
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
Stan Johnson
Signed-off-by: Finn Thain
---
drivers/macintosh/adb-iop.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index 6b26b6a2c463..0ee327249150 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/
it might as well part of iop_init().
Cc: Joshua Thompson
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/mac/config.c | 8 ---
arch/m68k/mac/iop.c| 54 ++
2 files changed, 18 insertions(+), 44 deletions(-)
diff --git a/arch/m68k/mac
-macii driver. This poll command is addressed to
that device which last received a Talk command (explicit or otherwise).
Cc: Joshua Thompson
Fixes: fa3b5a9929fc ("macintosh/adb-iop: Implement idle -> sending state
transition")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
a lost DMA interrupt and a command timeout. Fix this by excluding
EH and interrupt handlers while the new command is enqueued.
Signed-off-by: Finn Thain
---
Michael, would you please send your Acked-by or Reviewed-and-tested-by?
These two patches taken together should be equivalent to the one you t
a...@vger.kernel.org # v5.8+
References: commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is
invalid")
Reported-by: Laurent Vivier
Signed-off-by: Finn Thain
---
The global platform_device structs provide the equivalent of a direct
search of the OpenFirmware tree, for platfor
Refactor to avoid needless calls to NCR5380_maybe_release_dma_irq().
This makes the machine code smaller and the source more readable.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b
On Fri, 30 Oct 2020, Greg Ungerer wrote:
> >
> > > ...
> > > > The other 11 platforms in that category also have 'synthetic'
> > > > clocksources derived from a timer reload interrupt. In 3 cases,
> > > > the clocksource read method does not (or can not) check for a
> > > > pending counter
On Fri, 23 Oct 2020, Geert Uytterhoeven wrote:
> > > > The arm/rpc timer seems to be roughly in the same category as most
> > > > of the m68k ones or the i8253 counter on a PC. It's possible that
> > > > some of them could use the same logic as
> > > > drivers/clocksource/i8253.o as long as
On Fri, 30 Oct 2020, Arnd Bergmann wrote:
> CONFIG_ARCH_GETTIMEOFFSET has been gradually phased out from all
> platforms, with only ARM EBSA110 recently. As this has no more known
> users, the first three patches remove EBSA110 along with one platform
> specific driver and the
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain
> wrote:
> > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain
> > > wrote:
> > > > On Sat, 10 Oct 2020, Arnd Bergma
On Tue, 27 Oct 2020, t...@redhat.com wrote:
> This rfc will describe
> An upcoming treewide cleanup.
> How clang tooling was used to programatically do the clean up.
> Solicit opinions on how to generally use clang tooling.
>
This tooling is very impressive. It makes possible an idea that I
On Thu, 22 Oct 2020, Geert Uytterhoeven wrote:
>
> Thanks for your patch...
>
You're welcome.
> I can't say I'm a fan of this...
>
Sorry.
>
> The real issue is this "extern struct platform_device scc_a_pdev,
> scc_b_pdev", circumventing the driver framework.
>
> Can we get rid of that?
On Thu, 22 Oct 2020, Tianxianting wrote:
> I see, If we add this patch, we need to get all cpu arch that support
> nested interrupts.
>
I was just calling into question 1. the benefit (does it improve
performance?) and 2. the code style (is it less portable?).
It's really the style question
On Thu, 22 Oct 2020, Tianxianting wrote:
> Do you mean Megasas raid can be used in m68k arch?
m68k is one example of an architecture on which the unstated assumptions
in your patch would be invalid. Does this help to clarify what I wrote?
If Megasas raid did work on m68k, I'm sure it could
On Wed, 21 Oct 2020, Laurent Vivier wrote:
> Le 21/10/2020 à 01:43, Finn Thain a écrit :
>
> > Laurent, can we avoid the irq == 0 warning splat like this?
> >
> > diff --git a/drivers/tty/serial/pmac_zilog.c
> > b/drivers/tty/serial/pmac_zilog.c
> > ind
On Wed, 21 Oct 2020, Xianting Tian wrote:
> Since we already in hard IRQ context when running megasas_isr(),
On m68k, hard irq context does not mean interrupts are disabled. Are there
no other architectures in that category?
> so use spin_lock() is enough, which is faster than
On Tue, 20 Oct 2020, Brad Boyer wrote:
>
> Wouldn't it be better to rearrange this code to only run if the devices
> are present? This is a macio driver on pmac and a platform driver on
> mac, so shouldn't it be possible to only run this code when the
> appropriate entries are present in the
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote:
> >
> > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > > > Perhaps patch 13 does not belong in this series (?).
> > > >
> > > > All m68k plat
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> > Perhaps patch 13 does not belong in this series (?).
> >
> > All m68k platforms will need conversion before the TODO can be removed
> > from Documentation/features/time/clockevents/arch-support.txt.
>
> Yes, correct. I marked this patch as RFC
On Tue, 13 Oct 2020, Daniel Wagner wrote:
> On Tue, Oct 13, 2020 at 10:59:18AM +1100, Finn Thain wrote:
> >
> > On Mon, 12 Oct 2020, Daniel Wagner wrote:
> >
> > > When the fcport is about to be deleted we should return EBUSY
> > > instea
On Mon, 12 Oct 2020, Daniel Wagner wrote:
> When the fcport is about to be deleted we should return EBUSY instead
> of ENODEV. Only for EBUSY the request will be requeued in a multipath
> setup.
>
> Also in case we have a valid qpair but the firmware has not yet
> started return EBUSY to avoid
Hi Arnd,
Perhaps patch 13 does not belong in this series (?).
All m68k platforms will need conversion before the TODO can be removed
from Documentation/features/time/clockevents/arch-support.txt.
On m68k, HZ is fixed at 100. Without addressing that, would there be any
benefit from adopting
Hi Arnd,
On Thu, 8 Oct 2020, Arnd Bergmann wrote:
> All platforms that currently do not use generic clockevents roughly call
> the same set of functions in their timer interrupts: xtime_update(),
> update_process_times() and profile_tick(), sometimes in a different
> sequence.
>
> Add a helper
On Fri, 9 Oct 2020, Laurent Vivier wrote:
> This information is unused since the discontinuous memory support
> has been introduced in 2007.
>
> Fixes: 12d810c1b8c2 ("m68k: discontinuous memory support")
Does this qualify as a bug fix?
On Wed, 7 Oct 2020, Tony Asleson wrote:
> The log information is not helpful without the information to correlate
> to the actual device.
Log messages that associate one entity with another can be generated
whenever such an association comes into existence, which is probably when
devices get
river_data pointer is uninitialized.
Add the missing platform_set_drvdata() call. For clarity, use the
matching platform_get_drvdata() as well.
Cc: Michael Schmitz
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-m...@lists.linux-m68k.org
Fixes: 5ed0794cde593 ("m68k/atari: Convert Falcon IDE drive
Hi Geert,
On Wed, 16 Sep 2020, Finn Thain wrote:
> On Tue, 15 Sep 2020, Geert Uytterhoeven wrote:
>
> > > > > --- a/drivers/ide/macide.c
> > > > > +++ b/drivers/ide/macide.c
> > > >
> > > > > @@ -109,42 +110,61 @@ static const
ed the legacy IDE
driver")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
This patch was tested successfully on a Powerbook 190 (MAC_IDE_BABOON)
using both pata_platform and ide_platform drivers.
The next step will be to try using these generic drivers with the other
IDE controller variants
On Sat, 19 Sep 2020, Arnd Bergmann wrote:
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
> > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
> > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > > Said that, why not provide a variant that would take an explicit
On Fri, 18 Sep 2020, Jing Xiangfeng wrote:
> The variable ret is being initialized with '-ENOMEM' that is
> meaningless. So remove it.
>
Acked-by: Finn Thain
On Tue, 15 Sep 2020, Geert Uytterhoeven wrote:
> > > > --- a/drivers/ide/macide.c
> > > > +++ b/drivers/ide/macide.c
> > >
> > > > @@ -109,42 +110,61 @@ static const char *mac_ide_name[] =
> > > > * Probe for a Macintosh IDE interface
> > > > */
> > > >
> > > > -static int __init
ed the legacy IDE
driver")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
This patch was tested successfully on a Powerbook 190 (MAC_IDE_BABOON)
using both pata_platform and ide_platform drivers.
The next step will be to try using these generic drivers with the other
IDE controller variants
On Mon, 14 Sep 2020, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Mon, Sep 14, 2020 at 4:47 AM Finn Thain wrote:
> > Add platform devices for the Mac IDE controller variants. Convert the
> > macide module into a platform driver to support two of those variants.
> > F
ed the legacy IDE
driver")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
This patch was tested successfully on a Powerbook 190 (MAC_IDE_BABOON)
using both pata_platform and ide_platform drivers.
The next step will be to try using these generic drivers with the other
IDE controller variants
On Fri, 11 Sep 2020, Geert Uytterhoeven wrote:
>
> Sorry, I completely missed that the Baboon case registers a
> "pata_platform" device instead of a "macide" device. Hence please
> ignore my comments related to that. Sorry for the noise.
>
No problem. That misunderstanding got me thinking
On Thu, 10 Sep 2020, Geert Uytterhoeven wrote:
> On Thu, Sep 10, 2020 at 2:23 AM Finn Thain wrote:
> > I prefer a declarative or data-driven style, even if it takes a few
> > more lines of code. But there is a compromise:
> >
> > static const struct resource mac_id
On Wed, 9 Sep 2020, Geert Uytterhoeven wrote:
>
> Thanks for your patch!
>
Thanks for your review.
> > --- a/arch/m68k/mac/config.c +++ b/arch/m68k/mac/config.c
>
> > @@ -940,6 +941,50 @@ static const struct resource mac_scsi_ccl_rsrc[]
> > __initconst = {
> > },
> > };
> >
> >
, there is also a factor of 266 that has to be
applied to this value on certain parts i.e. speed sort above 266 MHz.)
Always use the maximum cycle count, as recommended by the Datasheet.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
ar
This patch series fixes various bugs in the Thermal Assist Unit driver.
It was tested on 266 MHz and 292 MHz PowerBook G3 laptops.
Finn Thain (5):
powerpc/tau: Use appropriate temperature sample interval
powerpc/tau: Convert from timer to workqueue
powerpc/tau: Remove duplicated
because tau_timeout() does so.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/powerpc/kernel/tau_6xx.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
index 268
34a886e47819c2eb ]---
Don't call on_each_cpu() from a timer callback, call it from a worker
thread instead.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/powerpc/kernel/tau_6xx.c | 38 +--
1 file cha
an Johnson
Signed-off-by: Finn Thain
---
arch/powerpc/kernel/tau_6xx.c | 65 +-
arch/powerpc/platforms/Kconfig | 9 ++---
2 files changed, 26 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
index 614
According to Freescale's documentation, MPC74XX processors have an
erratum that prevents the TAU interrupt from working, so don't try to
use it when running on those processors.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/powe
On Thu, 27 Aug 2020, Joe Perches wrote:
>
> checkpatch already does this.
>
Did you use checkpatch to generate this patch?
> @@ -109,34 +111,28 @@ static void get_z2ram(void)
...
> }
> -
> - return;
> }
>
It would be good to have a semantic patch for that change.
>
> - if (z2ram_map[z2ram_size] == 0) {
> + if (z2ram_map[z2ram_size] == 0)
> break;
> -
On Wed, 26 Aug 2020, Geert Uytterhoeven wrote:
> > @@ -2654,7 +2654,7 @@ func_startmmu_get_page_table_entry,%d0/%a1
> > jne 2f
> >
> > /* If the page table entry doesn't exist, we allocate a complete new
> > -* page and use it as one continues big page table
ed the legacy IDE
driver")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
This patch was tested successfully on a Powerbook 190 (MAC_IDE_BABOON)
using both pata_platform and ide_platform drivers.
The next step will be to try using these generic drivers with the other
IDE controller variants
1 - 100 of 2949 matches
Mail list logo
