beh...@converseincode.com writes:
> +#define current_stack_pointer ({ \
> + unsigned long current_sp; \
> + asm ("mov %0, r13" : "=r" (current_sp)); \
> + current_sp; \
> +})
Why do you use 'r13' rather than the more common '
ot;Q" (sp));
This doesn't do quite the same thing. The existing code pretends to
read something from the stack in order to create a barrier of some
sort. Your new code stores the value of the stack pointer to a location
on the stack for consumption by the "Q" memory constrain
Rob Landley writes:
> On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
>> Rob Landley writes:
>>
>> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> >> I'd strongly suggest you make your binutils compatible with newer
>> >> instruc
ce, binutils older than 2.19
or so rarely works properly for ARM.
What value is there in maintaining compatibility with a truly ancient
binutils version anyway?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
depend on
> endless new gnuisms just because they're there and nobody else is
> regression testing against them, not because they actually add anything.
Since when is assembling the instructions correctly, as specified in the
arch ref, and not in some other random way a gnuism?
-
might break your precious assembler.
>
> I've got news for you. We're *not* going to listen to that argument.
>
> END OF DISCUSSION (everything else is just a waste of time.)
I fully agree.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsub
s type 'size_t' [-Wformat]
>
> We already changed that once from %td to %zd so that the size_t works
> correctly.
If the argument is correctly of type size_t, the format should be '%zu'
since size_t is unsigned.
> Does a signed size_t make any sense?
A signed
ference manual.
LDA uses the address generation circuitry from the load/store unit, but
it does not actually access memory. It is merely a convenient way of
performing certain arithmetic operations, be it for scheduling reasons
or for the different range of immediate values available.
--
Måns
ding "software" and "free".
> This whole thread and gotten truly bizarre.
Surprised?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
ault-resistent). This way, the image
> loaded by the bootloader could be held on display up to the graphical
> login, and even as the
> desktop background, without any visible effect.
>
> Is this technically feasible?
It's technically pointless. Take a look at bootsplash, thou
persist.
>
> This is a know problem?
Probably something to do with this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecb77fa96ceda9cae88015bfe3293ffe19006159
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsu
e any say in the matter. The Windows drivers are (unrelated
violations aside) clearly not derived from GPL code.
IANAL
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk <[EMAIL PROTECTED]> writes:
> On Tue, Jan 29, 2008 at 11:25:22PM +0000, Måns Rullgård wrote:
>> Adrian Bunk <[EMAIL PROTECTED]> writes:
>>
>> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
>> >> Hello!
>> >&g
t some lawyers claim that at trade shows, you should not hand over
> a demo device running GPLed code to any interested party, as it would be
> distribution...
Lawyers tend to be overly cautious at times. That said, I am not a
lawyer, and may have misunderstood something. If that is the case, I
apo
data, except through the communication protocol. No tainting is
> involved, as all corruption in your kernel is caused by kernel bugs in
> visible code that can be debugged.
Untrusted code doesn't necessarily violate the GPL. The two issues
are orthogonal.
--
Måns Rullgård
[EMAIL
complete halt from a fork bomb.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nt speakers.
>> Off topic. Please switch to ALSA (OSS is deprecated) then ask this
>> question on the ALSA lists.
>
> What "the ALSA list" is that?
Go to http://alsa-project.org/mailing-lists.php and pick one that
seems appropriate.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To
eb links don't have mime types. The
HTTP headers from that page say content-type is text/html, so where's
the problem?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
essary at
all? I can't see that it should make a difference. Am I missing
something subtle?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Michael Tokarev <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> "Ronald S. Bultje" <[EMAIL PROTECTED]> writes:
>>
>>>--- linux-2.6.5/drivers/media/video/zr36050.c.old16 Sep 2004 22:53:27
>>>- 1.2
>>>+++ linux
Vicente Feito <[EMAIL PROTECTED]> writes:
> On Tuesday 29 March 2005 09:58 pm, you wrote:
>> Måns Rullgård wrote:
>> > "Ronald S. Bultje" <[EMAIL PROTECTED]> writes:
>> >>--- linux-2.6.5/drivers/media/video/zr36050.c.old 16 Sep 2004 22:53:27
un with a negative nice value. This can be easily accomplished with
a simple wrapper, only for the shell.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> It can be done entirely in userspace, if you want it. Just hack your
>> shell to examine some extended attribute of your choice, and adjust
>> the nice value before executing files. Then arrange to h
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>>
>> You could wrap /lib/ld-linux.so, and get all dynamically linked
>> programs done in one sweep.
>>
> That's mad idea -
Sure, but it's possible.
> keep similar things in one place! sta
lished with
>> a simple wrapper, only for the shell.
>
> Even better: Write a C wrapper for each affected program that just renices
> it as needed.
The OP was too lazy to do this.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-
gt; Without i386 support, you don't have any embedded systems. You
> need to use the garbage Motorola CPUs and the proprietary
> operating systems in embedded stuff.
In front me at the moment are two embedded devices, one PPC based, the
other MIPS, both running Linux.
--
Måns Rullgård
[EMAI
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> On Fri, 1 Apr 2005, [iso-8859-1] Måns Rullgård wrote:
>
>> linux-os <[EMAIL PROTECTED]> writes:
>>
>>> [PATCH snipped]
>>>
>>> Cruel joke. Now 80 percent of the Intel clones
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> So you are proposing the addition of a per-file attribute, with
>> restricted access, and potentially dangerous effects if set
>> incorrectly. This, combined with the fact that is unlikely to receive
>>
ute,
> accessible only for root, and if hacker has root permissions,
> existence of nice attribute is meaningless.
You forgot something: this idea of yours needs to be implemented,
tested, and debugged. Those things take time, and effort, and are
still of very little value.
--
Måns Rullgård
[EMAI
Be careful though, even reading
certain addresses will crash your computer.
If you want the virtual to physical mapping for your process, there is
no simple way.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
last 4 years...
ARM. On ARM1136 (used in the Nokia N800) a mispredicted branch takes
5-7 cycles (a correctly predicted branch takes 0-4 cycles), while a
conditional load, store or arithmetic instruction always takes one
cycle.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this l
.6.22-rcsomething works better for me than any kernel before it.
It's certainly not only getting worse.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> mechanism to enumerate all tasks is to use a do_each_thread() +
> while_each_thread() loop.
Was this always a bug or did the meaning of for_each_process() change
since this code was added?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubsc
dirt, yet distros like Fedora and RHEL use 4K stacks
> since forever, and if it gave massive problems they wouldn't do that.
> On the upside, especially on very-threaded workloads, it helps
> reliability and the VM a lot...
I guess no Fedora users run md+lvm+xfs then. That combinat
ng new blocks
to be allocated.
I don't have dedicated testing machines, so I can't afford the time
and potential data loss of testing this regularly. I have no shortage
on RAM with 8k stacks, so for me the choice is quite simple.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this
.
I've still not, after all these years, managed to figure out what KDE
(or Gnome) is supposed to be good for. I'm not missing anything from
my window manager, xterm and xemacs setup.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
at best, and
>> counter-productive in any case.
>
> Well, then please write this to the person who did attack me for no
> reason!
>
> What he did is typical trollish behavior, as he tried to turn a
> technical based discussion into a flame war for no reason.
Ah, it's
SuSE; I've not heard it on any
> other distro...
Even with that option set, the full kernel build with my configuration
finishes in one minute flat on my Gentoo box. Could it be that the
linker uses enormous amounts of memory? I have 4GB so I wouldn't
immediately notice.
--
Måns Ru
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Friday 20 April 2007 10:35:10 Måns Rullgård wrote:
>> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>>
>> > Andi Kleen wrote:
>> >> Rationale:
>> >> - It cannot be enabled in normal builds beca
rs?
>> +- linux,sched-clock: boolean, register clocksource as sched_clock
>
> Likewise, this property doesn't belong in the DT for the same reasons as
> clocksource-rating.
What would be a proper way to select a sched_clock source? I realise
it's a Linux-specific thin
what's the expected behaviour of this source w.r.t.
> power management? I expect that the kernel needs to leave the clock
> enabled at all times for this to possibly work.
The platform I'm dealing with has a 32-bit register counting cycles of
the external clock input which never stops.
Rob Herring writes:
> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård wrote:
>> Mark Rutland writes:
>>
>>> On Wed, Oct 07, 2015 at 04:37:13PM +0100, Mans Rullgard wrote:
>>>> This adds a DT binding for a generic mmio clocksource as implemented
>>>&
s device. I'll include netdev when I send an updated
version.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
interrupt-parent: Should be a phandle for the interrupt controller
>> +- clocks: Should be a phandle for the clock for the device
>> +
>> +Common properties described in ethernet.txt:
>> +- local-mac-address
>> +- mac-address
>> +- max-speed
>> +- phy-mode
&
Marc Gonzalez writes:
> On 23/10/2015 15:41, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> On 22/10/2015 16:02, Mans Rullgard wrote:
>>>
>>>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
>>>> usin
it is supported or not.
This does something to the configuration of the external pins, the
documentation is vague about what.
>> +phydev = phy_find_first(bus);
>> +if (!phydev || phy_read(phydev, MII_BMSR) <= 0) {
>
> What is this additional MII_MBSR read used for?
On one of my boards, phylib mis
MBSR read used for?
>>
>> On one of my boards, phylib misdetects a phy on the second ethernet port
>> even though there is none. Perhaps I should revisit that problem and
>> look for a better solution.
>
> I think that would be best, if you are currently using the Gener
Marc Gonzalez writes:
> On 23/10/2015 15:41, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> On 22/10/2015 16:02, Mans Rullgard wrote:
>>>
>>>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
>>>> usin
should have known better than to look at existing
bindings. Let's drop that idea.
Let's try something else:
Device trees list the exact chip, the oldest chip with the same
features, and the oldest compatible chip. From the sound of things,
that means the smp8759 should use "sigma,sm
Marc Gonzalez writes:
> On 26/10/2015 14:54, Måns Rullgård wrote:
>
>> Let's try something else:
>>
>> Device trees list the exact chip, the oldest chip with the same
>> features, and the oldest compatible chip. From the sound of things,
>> that me
igma,smp8642-ethernet", "aurora,nb8800";
> + reg = <0x26000 0x800>;
> + interrupts = <38>;
> + clocks = <&sys_clk>;
> + max-speed = <1000>;
> + phy-connection-type = "rgmii";
> + phy-handle = <ð0_phy>;
&g
gure out who the vendor is.
I've been informed it is provided by Palmchip. I'll make a new patch.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
my register layout"
>> + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
>> +
>
>So Alchemy UART got reused on ARM?
The UART is actually a Palmchip IP core used by several SoC companies.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list:
Sergei Shtylyov writes:
> On 10/2/2015 5:26 PM, Måns Rullgård wrote:
>
>>>> Some SoCs have a UART with a non-standard register layout. This
>>>> allows the debug console to work with these.
>>>
>>>> Signed-off-by: Mans Rullgard
>>>>
patch author when you claim to
> be fixing a bug in their patch.
Sorry about that. Blame the get-maintainers script.
--
Måns Rullgård
ntil we have seen one. With the
characters being added to the buffer one by one, it is enough to check
for semicolon at the end.
BTW, the parsing of this command has been broken since 3.2-rc1 due to
commit 129957069e6a.
--
Måns Rullgård
Miguel Ojeda writes:
> On Wed, Dec 5, 2018 at 6:58 PM Måns Rullgård wrote:
>>
>> Suppose the command "\e[Lx0y0;" is written to the device. The
>> charlcd_write_char() function adds one character at a time to the escape
>> sequence buffer.
>
> Ah, yes
Miguel Ojeda writes:
> Hi Måns,
>
> On Thu, Dec 6, 2018 at 1:06 PM Måns Rullgård wrote:
>>
>> >> BTW, the parsing of this command has been broken since 3.2-rc1 due to
>> >> commit 129957069e6a.
>> >
>> > Thanks for checking! Are you
e submitted the patch.
> You, implicitly, by acking a patch saying those parens are bad.
> But not me ... I don't think this patch is merge-worthy.
Would also add rules like "don't put parens around the word device"
etc? There are countless silly things one could do, and
[] sys_fstat64+0x1e/0x23
> [] vfs_readdir+0x63/0x8d
> [] filldir+0x0/0xb9
> [] sys_getdents+0x5f/0x9c
> [] syscall_call+0x7/0xb
> ===
Your Redhat kernel is probably built with 4k stacks and XFS+loop+ext3
seems to be enough to overflow it.
--
Måns Rullgård
[EMAIL
Chris Boot <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> Chris Boot <[EMAIL PROTECTED]> writes:
>>
>>
>>> All,
>>>
>>> I've got a box running RHEL5 and haven't been impressed by ext3
>>> performance on it (runn
just from bad to worse. Using filter functions
> isn't that great in the first place. And using them to pass data from
> the consumer to the DMA provider is just a horrible abuse of the API.
It seems to me the only sane way to use the dmaengine API is in
conjunction with DT.
--
ang has taken
to warning about unused inline functions, that's a regression that needs
to be addressed in clang, not the kernel.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
r arm64 or armv8 for a few
reasons:
- Those are the names people actually use to refer to the architecture
- They are more descriptive.
- I think the official name is rather silly.
Note, these are my personal opinions.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
; actual bit encoding):
>>
>> http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html
>
> "This document is only available in a PDF version to registered ARM
> customers."
>
> It would be nice to make this public :-(.
Anyone can register, so it's not all
#x27;m not trying to defend the "beauty" of this name (I
> have my own opinion) but we spend too much time arguing about it. This
> name has implications beyond the technical arguments of some script or
> another and it will be found in all the technical documents produced by
> A
* Otherwise, check whether DT indicates this device is non-removable.
+*/
+ if (of_property_read_bool(udev->dev.of_node, "non-removable")) {
+ udev->removable = USB_DEVICE_FIXED;
+ return;
+ }
+
/*
* Otherwise, check whether the hub knows whether a port is removable
* or not
--
Måns Rullgård
Greg Kroah-Hartman writes:
> On Thu, Feb 28, 2019 at 03:22:24PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Feb 28, 2019 at 02:33:44PM +, Mans Rullgard wrote:
>> >> Add a boolean property indicating that a device is
RCE_MEM, 1);
>> ...
>> rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1,
>> priv->mac_addr);
>>
>> So it there are two ranges, the slave param becomes 0. It there is only one,
>> it
>> will be 1. Since the am3517 only has a single regs entry it ends up with
>> slave 1,
>> while there is only a single davinci_emac.
>
> OK thanks for clarifying it:
>
> Acked-by: Tony Lindgren
What happened to this patch?
--
Måns Rullgård
> num_pkts < quota) {
> mbx_mask = BIT(priv->rx_next); /* next rx mailbox to process */
> --
> 2.7.4
This seems to have been lost or forgotten.
--
Måns Rullgård
r
> off, not flashing for sure.
> Though it seems the case before the patch...
The current code unconditionally flashes the light once. I though it
best to keep that behaviour as default, even if it's not seen as ideal.
--
Måns Rullgård
gt; stmfd sp!, {r4-r11, lr}
> smc #0
[...]
> diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
> index 361a8dc89804..cf2d21e5226c 100644
> --- a/arch/arm/mach-tango/smc.S
> +++ b/arch/arm/mach-tango/smc.S
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #include
>
> + .arch_extension sec
> ENTRY(tango_smc)
> push{lr}
> mov ip, r1
Is there some reason these three don't need the .arch directive?
--
Måns Rullgård
ta(pdev);
> -
> - tangox_wdt_stop(&dev->wdt);
> - clk_disable_unprepare(dev->clk);
> -
> - watchdog_unregister_device(&dev->wdt);
> -
> - return 0;
> }
>
> static const struct of_device_id tangox_wdt_dt_ids[] = {
> @@ -204,7 +196,6 @@ MODULE_DEVICE_TABLE(of, tangox_wdt_dt_ids);
>
> static struct platform_driver tangox_wdt_driver = {
> .probe = tangox_wdt_probe,
> - .remove = tangox_wdt_remove,
> .driver = {
> .name = "tangox-wdt",
> .of_match_table = tangox_wdt_dt_ids,
> --
> 2.7.4
>
--
Måns Rullgård
device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x
(Bus Powered)
--
Måns Rullgård
Johan Hovold writes:
> Adding Bjørn.
>
> On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote:
>> Johan Hovold writes:
>>
>> > On Tue, Feb 26, 2019 at 05:07:10PM +, Mans Rullgard wrote:
>> >> The SIMCom SIM5218 and compatible devices ha
used by this?
There won't be /dev/ttyS devices for ports that don't exist.
> Will ports get renumbered?
Not if they had predictable numbers to begin with.
> What harm is this causing systems today without this change?
It means I have to somehow maintain a separate list of which ports are
real and which should be ignored, or else try to distinguish real errors
from those caused by trying to access the bogus ports.
--
Måns Rullgård
Greg Kroah-Hartman writes:
> On Sun, Jan 31, 2021 at 01:18:47PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Jan 28, 2021 at 05:22:44PM +, Mans Rullgard wrote:
>> >> On systems that do not have the traditional PC ISA seria
roduces some kind of
error. How is it breaking anything to not create device nodes for
hardware that doesn't exist?
--
Måns Rullgård
t;;
> reg = <0x2010 0x1000>;
> cache-level = <2>;
> --
> 2.17.1
>
--
Måns Rullgård
e tango3 and tango4 boards.
>
> Waiting for his take on the matter.
>
> I can point out some device-specific drivers that would become
> useless if tango support were dropped.
I have tango3 and tango4 boards. Can't say I'm using them for anything,
though. With the entire platform dead at the vendor level, removal
seems like a reasonable choice.
--
Måns Rullgård
river works fine on my UP1500 machine, unless something
broke recently. I'll build the latest kernel and report back.
--
Måns Rullgård
Måns Rullgård writes:
> Christoph Hellwig writes:
>
>> On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote:
>>> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
>>> > Switch the alpha defconfig from the legacy ide driver to libata.
>
ot;, xtal_freq, 350,
> - 32, clocksource_mmio_readl_up);
> - if (ret) {
> - pr_err("%pOF: registration failed\n", np);
> - return ret;
> - }
> -
> - sched_clock_register(read_sched_clock, 32, xtal_freq);
> - register_current_timer_delay(&delay_timer);
> -
> - return 0;
> -}
> -
> -TIMER_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
> --
>
> 2.29.2
>
--
Måns Rullgård
failed to get IRQ", node);
> -
> - err = of_address_to_resource(node, 0, &res);
> - if (err)
> - panic("%pOFn: failed to get address", node);
> -
> - chip = kzalloc(sizeof(*chip), GFP_KERNEL);
> - chip->ctl = res.start - baseres->start;
> - chip->base = base;
> -
> - dom = irq_domain_add_linear(node, 64, &irq_generic_chip_ops, chip);
> - if (!dom)
> - panic("%pOFn: failed to create irqdomain", node);
> -
> - err = irq_alloc_domain_generic_chips(dom, 32, 2, node->name,
> - handle_level_irq, 0, 0, 0);
> - if (err)
> - panic("%pOFn: failed to allocate irqchip", node);
> -
> - tangox_irq_domain_init(dom);
> -
> - irq_set_chained_handler_and_data(irq, tangox_irq_handler, dom);
> -
> - return 0;
> -}
> -
> -static int __init tangox_of_irq_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - struct device_node *c;
> - struct resource res;
> - void __iomem *base;
> -
> - base = of_iomap(node, 0);
> - if (!base)
> - panic("%pOFn: of_iomap failed", node);
> -
> - of_address_to_resource(node, 0, &res);
> -
> - for_each_child_of_node(node, c)
> - tangox_irq_init(base, &res, c);
> -
> - return 0;
> -}
> -IRQCHIP_DECLARE(tangox_intc, "sigma,smp8642-intc", tangox_of_irq_init);
> --
>
> 2.29.2
>
--
Måns Rullgård
v, RC6_CARRIER);
> -
> - writel_relaxed(ACK_RC6_INT, ir->rc6_base + RC6_CTRL);
> - writel_relaxed((clkdiv >> 2) << 18 | clkdiv, ir->rc6_base + RC6_CLKDIV);
> -
> - err = devm_request_irq(dev, irq, tango_ir_irq, IRQF_SHARED,
> -dev_name(dev), ir);
> - if (err)
> - goto err_clk;
> -
> - err = devm_rc_register_device(dev, rc);
> - if (err)
> - goto err_clk;
> -
> - platform_set_drvdata(pdev, ir);
> - return 0;
> -
> -err_clk:
> - clk_disable_unprepare(ir->clk);
> - return err;
> -}
> -
> -static int tango_ir_remove(struct platform_device *pdev)
> -{
> - struct tango_ir *ir = platform_get_drvdata(pdev);
> -
> - clk_disable_unprepare(ir->clk);
> - return 0;
> -}
> -
> -static const struct of_device_id tango_ir_dt_ids[] = {
> - { .compatible = "sigma,smp8642-ir" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, tango_ir_dt_ids);
> -
> -static struct platform_driver tango_ir_driver = {
> - .probe = tango_ir_probe,
> - .remove = tango_ir_remove,
> - .driver = {
> - .name = DRIVER_NAME,
> - .of_match_table = tango_ir_dt_ids,
> - },
> -};
> -module_platform_driver(tango_ir_driver);
> -
> -MODULE_DESCRIPTION("SMP86xx IR decoder driver");
> -MODULE_AUTHOR("Mans Rullgard ");
> -MODULE_LICENSE("GPL");
> --
>
> 2.29.2
>
--
Måns Rullgård
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> The tango4 platform is getting removed, and this driver has no
> other known users, so it can be removed.
>
> Cc: Marc Gonzalez
> Cc: Mans Rullgard
> Signed-off-by: Arnd Bergmann
Acked-by: Mans Rullgard
> ---
> drivers/net/ethernet/Kconfig
; - if (readl(dev->base + WD_COUNTER)) {
> - set_bit(WDOG_HW_RUNNING, &dev->wdt.status);
> - tangox_wdt_start(&dev->wdt);
> - }
> -
> - watchdog_set_restart_priority(&dev->wdt, 128);
> -
> - watchdog_stop_on_unregi
c int __maybe_unused tango_thermal_resume(struct device *dev)
> -{
> - tango_thermal_init(dev_get_drvdata(dev));
> - return 0;
> -}
> -
> -static SIMPLE_DEV_PM_OPS(tango_thermal_pm, NULL, tango_thermal_resume);
> -
> -static const struct of_device_id tango_sensor_ids[] = {
> - {
> - .compatible = "sigma,smp8758-thermal",
> - },
> - { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(of, tango_sensor_ids);
> -
> -static struct platform_driver tango_thermal_driver = {
> - .probe = tango_thermal_probe,
> - .driver = {
> - .name = "tango-thermal",
> - .of_match_table = tango_sensor_ids,
> - .pm = &tango_thermal_pm,
> - },
> -};
> -
> -module_platform_driver(tango_thermal_driver);
> -
> -MODULE_LICENSE("GPL");
> -MODULE_AUTHOR("Sigma Designs");
> -MODULE_DESCRIPTION("Tango temperature sensor");
> --
>
> 2.29.2
>
--
Måns Rullgård
> - .compatible = "sigma,smp8759-pcie",
> - .data = &smp8759_ecam_ops,
> - },
> - { },
> -};
> -
> -static struct platform_driver tango_pcie_driver = {
> - .probe = tango_pcie_probe,
> - .driver = {
> - .name = KBUILD_MODNAME,
> - .of_match_table = tango_pcie_ids,
> - .suppress_bind_attrs = true,
> - },
> -};
> -builtin_platform_driver(tango_pcie_driver);
> -
> -/*
> - * The root complex advertises the wrong device class.
> - * Header Type 1 is for PCI-to-PCI bridges.
> - */
> -static void tango_fixup_class(struct pci_dev *dev)
> -{
> - dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> -}
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0024, tango_fixup_class);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0028, tango_fixup_class);
> -
> -/*
> - * The root complex exposes a "fake" BAR, which is used to filter
> - * bus-to-system accesses. Only accesses within the range defined by this
> - * BAR are forwarded to the host, others are ignored.
> - *
> - * By default, the DMA framework expects an identity mapping, and DRAM0 is
> - * mapped at 0x8000.
> - */
> -static void tango_fixup_bar(struct pci_dev *dev)
> -{
> - dev->non_compliant_bars = true;
> - pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x8000);
> -}
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0024, tango_fixup_bar);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0028, tango_fixup_bar);
> --
>
> 2.29.2
>
--
Måns Rullgård
thus requires the stack to be made executable in order for the
> program to work properly.
>
> That might work.
That sounds like it will only warn if a trampoline is needed. A nested
function whose address isn't taken, as is the case here, wouldn't
trigger this warning.
--
Måns R
wilful bad behavior
> unless that is shown to be necessary. Yeah, if it turns out that
> systemd really does that just to mess with us, we'd need to extend it,
> but in the absence of proof to the contrary, maybe this simple
> attached patch works?
Once is an accident. Twice is inco
s interface whatsoever, right?).
The point is that /dev/kmsg is *not* intended as a syslog replacement.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ator));
> +
> + return ret;
> + }
> +
> + return ___aeabi_idiv(numerator, denominator);
> +}
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
move the
values to/from r0/r1) that would not be needed if the div instructions
were done inline (obviously such a kernel could only run on hardware
with division support).
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
nately we still have to jump to this function. It would be great
> if we could inline this function at the call site but as I already said
> I don't know how to do that.
Ideally the bl instruction at the call site would be patched over with
sdiv/udiv when supported. This would leave th
iler might do evil things with what to it looks like
out of bounds indexing.
There should also be some cache maintenance after this patching, or is
that already happening for some other reason?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe l
hine
> endianness.[show details]
>
> 1374pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx],
> (u32 *)&count);
> 1375pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx]
> + 4, (u32 *)&count + 1);
> 1376
> 1377return count;
&
divisions) but I doubt that people would accept that.
It might be possible to extract this information from relocation tables.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Nicolas Pitre writes:
> On Tue, 12 Nov 2013, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > On Tue, 12 Nov 2013, Ben Dooks wrote:
>> >
>> >> Given these are single instructoins for ARM, is it possible we could
>> >> make a
if( adapno >= hba_count )
> return (-ENODEV);
This relies on implementation-defined behaviour when converting an
unsigned integer to signed integer. A simpler and more robust fix is to
make the local variable 'adapno' unsigned.
--
Mån
1 - 100 of 433 matches
Mail list logo
