Analog Devices Expands over 1000 Linux Device Drivers to Support Development | Hacker News Reader

Analog Devices Expands over 1000 Linux Device Drivers to Support Development

analog.com

151 pointsteleforce78 comments

If, like me, you think of op-amps and some National Instruments analog-to-digital converters when you think of Analog Devices, you might be wondering what they're doing writing Linux drivers. The short answer is they're acquiring IP: They've bought Linear Technology (which makes tons of PMIC devices) and Maxim Integrated, who make tons of specialized PMIC, analog, RTC, interface, and other chips.

The link above is a press release, the full list of devices is here:

https://wiki.analog.com/resources/tools-software/linux-drive...

Part numbers prefixed with "LTC" are from Linear Tech, part numbers prefixed with "MAX" are Maxim, part numbers prefixed with "AD" are Analog Devices. Part numbers prefixed with "DS" are from Dallas Semiconductor, which was bought by Maxim a long time ago.

As someone who typically uses these devices in much smaller embedded systems, it's nice to have these hardware abstraction layers listed in one place, instead of having to transcribe it from the datasheet.

100%

This is the next logical step for semiconductor companies like AD, TI, etc.

AD doesn't tend to compete on cost, so high quality open source drivers become a key differentiator compared to other companies with lower cost parts, especially as these parts become increasingly complex. A 9 axis IMU with 10 different acquisition and buffering modes, built in algorithms, etc. becomes a lot more tractable if you don't have to write the whole driver from a datasheet.

Actually I think their plan is to continue not competing by acquiring all competition, as is now the norm in the semiconductor business. They call it "consolidation" but lets not mistake it for what it is.

Why are they doing Linux drivers then? They have to compete with international chips now.

I randomly clicked through the list, out of 10 drivers, 3 were written by independent devs, 5 by comapnies they acquired, and the rest by AD.

This looks just like some list of existing drivers, regardless of who wrote them.

Yes - the list on https://wiki.analog.com/linux is a consolidated list: - ADI devices (there is only one ADI, when a company is acquired, they are integrated - the group inside ADI that writes drivers doesn't care what the part prefix is) - internal ADI development and upstreamed/mainlined drivers that have been done by our customers / other contributors

It was done this way to try to make it easier for people to find the drivers, rather than rolling through kernel source. The Majority of the drivers are upstream (including the ones ADI writes), or are in process of going upstream, but some drivers - because of their development flow - will never meet upstream kernel coding guidelines.

[Disclaimer - I work at ADI].

Perfect. :)

AFAIK TI has always been very opensource friendly. All their SOCs are mainlined and maintained including pretty old ones.

Now if Broadcom starts to be opensource friendly then that would be a real change of heart.

I once tried to put OpenWRT on this nightmare... https://deviwiki.com/wiki/Actiontec_GT724WGR ; or maybe it was a very similar model; it was a long while ago.

The core SOC is a TI chip, but at least at the time while TI wasn't abhorrent, anything that might remotely help get the USB port working was a proprietary blob. I think they'd also sold the IP for that product to someone else by the time I was tinkering with it; I can't remember exactly but do recall it was either a nightmare or impossible to get a copy of the source code for the factory firmware.

This has turned me off to anything even using TI chips that I'm aware of. Maybe they've gotten better in the last decade. Probably they're fine if you're a hardware manufacturer paying for chips.

Linear Technology? I wonder if they can be convinced to open up the source of LTSpice. I'm sure that isn't something they haven't been asked about already... but if they are willing to give such a good simulator away for free, why not show off the source as well?

if they are willing to give such a good simulator away for free, why not show off the source as well?

Because giving away the source code to their simulator doesn't make any business sense in the way giving a Linux kernel driver does.

Giving away LTSPICE is an effort to commoditize their complements. The complement to an opamp is a high quality simulation model. The complement to a high speed data converter is a working Linux driver for JESD204B. Both decrease the effort involved for ADI's customer to use ADI's parts.

Giving away LTSpice source code doesn't achieve a similar aim.

That won't happen. They've specifically said that they maintain it because it helps them sell more product. They also encrypt their models. If they open source it, they lose both encryption and exclusivity.

I'd be happy if they'd just open-source the UI. I couldn't care less about the simulator secret sauce, but there is no reason it has to be saddled to a user interface that makes EAGLE look sane by comparison.

I'm actually glad that they haven't overhauled the UI. It would be great if they made tiny improvements, like making the font size and color defaults more pleasant. Deep blue on black as the default plot is less than stellar.

Also, unless something has changed, ltspice is wholly written by one person.

Right, they certainly shouldn't redo the UI in the core product. But they should make it possible to fork it.

PMIC = Power management integrated circuit

Analog Devices also does DSPs such as the Blackfin which, as far as I know, were made in-house and can Linux (well, Linux without MMU, but still).

Blackfin Linux was EOL'ed ~ Mar 2019 https://ez.analog.com/dsp/software-and-development-tools/lin...

Devices with ARM A5 (like https://www.analog.com/adsp-sc589) are still supported.

Disclaimer - I work at ADI.

If, like me, you think of op-amps and some National Instruments analog-to-digital converters when you think of Analog Devices, you might be wondering what they're doing writing Linux drivers

That's a pretty dated view of ADI's business.

These days they make most of their cheddar in their high speed data converter business. They have GSPS ADCs and DACs available that are hundreds of dollars per chip.

The Kuiper Linux support for Xilinx Zynq and MPSoC is telling. That's coded language for 5G physical layer and electronic warfare/SIGINT uses.

I know it's a pretty dated view, but is it really true that most of their...profits? revenue? are in the high-speed high-dollar data converter segment? Sure, one of those chips might cost as much as a reel of other chips, but for every van with a SIGINT box, there are thousands of civilian electronic devices.

High speed A/D and D/A is a big research driver to much of their business. The advances they make in gigasample D/A fabrication, can apply across a wide range of their product portfolio. The cutting edge chips may not represent a huge chunk of silicon volume, but they are a big driver of profitability. The volume is also likely a lot higher than you realize: these ADCs/DACs are ubiquitous in modern digital radars of the type preferred by the US military.

It also forms a big part of their business to sell associated components that complement the converters: clock sources, PLLs, some discrete RF, etc.

>The Kuiper Linux support for Xilinx Zynq and MPSoC is telling.

You missed the Intel SoC and Raspberry Pi support too. :)

According to the Annual Report [1] - ADI works with 125,000+ customers. That means diversity in application. The press release was focused on Linux, but there are a lot of other ecosystems that ADI also participates in - from Arduino to Pmod to No-OS to Mbed and more.

https://www.analog.com/media/en/news-marketing-collateral/so...

[Disclaimer - I work at ADI]

[1] https://investor.analog.com/static-files/ddc81d14-3ffe-4655-...

I will be afraid if someone starts building radars using a Raspberry Pi and an AD9177.

You would be surprised what some people do :)

We are making a Pi HAT based on https://www.analog.com/ad9166 (no JESD204, NCO only) to demonstrate how to make a fast hopping CW ...

There are lots of things that Pi is a great answer for.

God, y'all make some neat mixed signal parts. Lotta respect for ADI.

Kind of a tangent, but I found:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
    {
      return (reg == LTC_REG_CONFIG) ? true : false;
    }

Oh man, c'mon. That kind of thing bugs me. Just "return reg == LTC_REG_CONFIG" already, sheesh. (And maybe make it a preprocessor directive while you're at it?)

Int-> bool conversion is something that MSVC complained about (C4800) for the longest time for some kind of obscure reason. Wouldn’t surprise me if this code was written against a longer that had a similar warning OR that maybe this code is shared with their Windows driver and this needs to compile on both (at least that’s my attempt at finding the most generous explanation for that).

Sorry, what int -> bool conversion?

parameter reg is int, return value is bool.

“reg == LTC_REG_CONFIG” is a bool. There’s no conversion going on here.

In the C language, the result of the equality operator is an int, not a bool.

Ah, whale oil beef hooked, you're right.

> The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int. For any pair of operands, exactly one of the relations is true.

https://port70.net/~nsz/c/c11/n1570.html#6.5.9p3

Thanks for clearing that up. (Although I feel a bit foolish now.)

It's not really an explanation though. It's how the language should work.

That ternary operator "?" is just an if-statement which should have the same "problem" with an int argument. It is a broken compiler that would complain about an if statement but an identical ?-statement.

If the int nature of equals-to was a problem, you'd have to use limit its use to switch statements.

There's no problem with the "int argument". (Not sure if you mean the function argument ("reg") or the operand of the conditional operator, but either way not a problem.) The conflict is between the declared return type of the function and the type of the returned expression.

Right, but the same could be said for the ternary operator.

I don't follow. What could be said about it?

Not until quoting the above message did I realize I misread it this whole time.

There is nothing to understand. Sorry for being a bit dense.

The return type of the ternary is bool because of the explicit true/false.

No, it could not. The controlling expression of any kind of conditional statement in C can be an integer. The return type of a function which returns boolean, though, should be boolean.

The strict requirement in the standard is just a 'scalar type': every conditional expression in C, even `if (true)`, technically evaluates on unequal comparison to zero. See section 6.8.4.1 "The if statement" of the standard:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf

This applies to ternary operators, if statements, do/while loops, for loop termination conditions, etc.

However, when defining a function that returns boolean, you've asked the compiler to make your program more strict than just returning an integer that's zero or nonzero, you're not allowed to return anything but 'true' or 'false' - no, you're not allowed to pack in error codes after the fact!

It's not possible to remember all the details of C at one time. I feel like my low-level understanding shifts over different areas over time depending on the type of work I have been doing.

Then there's living in C++ land, which is 1000 times worse.

That reminds me of one of my favorite footguns:

   void foo(bool bar)
   {
   }

   int main(void)
   {
      foo("Whose bright idea was this?");
   }

No error, not even a warning, perfectly legit code. If bar had been declared int or char, you'd get an error. Instead, your code ends up less safe because you used bool, thinking you were doing the right thing. Yes, they wanted to allow it anywhere a conditional expression would fit, but implicit conversion from anything other than int and char would have been a good place to draw the line.

So I wouldn't be surprised if the GP example was prompted by a similar design flaw in either the language or a particular compiler.

Wouldn't this be a lot more meaningful if they were committing to get these drivers upstream?

It's similar to their LTspice strategy. It's free, but it's only for ADI devices. They want you to buy their stuff.

I'm not sure what you mean.

All the Linux kernel drivers found on https://github.com/analogdevicesinc/linux or upstreamed at kernel.org are released under the standard Linux kernel license - GPL 2.0. There is no "only for ADI devices" possible - doing so would be a violation of section 6 of the GPL 2 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein.")

Yes - ADI would encourage anyone to buy their devices - but no - we don't force it - There are many things that are "ADI devices only", but that's normally userspace or HDL or tools, not kernel.

Disclaimer - I work at ADI.

I see how you read that completely differently than how I meant it. I apologize, and thank you for pointing that out.

I meant to convey that creating a free software tool specifically to support a hardware catalog has precedent, makes business sense, and is useful to customers. Not everything has to conform to the FOSS die-hard ethos to upstream everything.

Most of the drivers in that list are already upstreamed.

The goal is to always upstream every driver (and we do a pretty good job at that). Depending on the lineage of the software (who developed it, what they developed it for) - it may not be possible to meet the kernel coding guidelines - so we don't send those upstream.

Disclaimer - I work at ADI.

So in other words Analog Devices won't be stuffed to upstream their driver work.

exactly, just upstream them, everyone's life will be easier

It baffles me how many times companies go "oh, instead of contributing these changes to an existing distribution, or the mainline, let's release our own shitty fork of that major distribution, which of course we will do a terrible job of keeping current with, and stop maintaining after about a year because the intern that was doing it moved on."

glares at Hardkernel, Banana Pi

I always thought the reason for this is that you can't just dump any half-baked crap into the kernel repo, it needs to have a certain level of quality. Its just cheaper that way, and there is no back-and-forth discussing issues for several months. But maybe I'm wrong?

under drivers/ there is a place called staging/ that you put your drivers there until it's solid then becomes official, to encourage exactly that, it's way better a place to host drivers than vendor's own repo or distro, in my opinion.

Ah that is interesting - and drivers in staging are fully available for users to try them?

yes, most of them are in pretty good shape.

As I understand, Linux doesn't have a kernel-to-driver API so "upstreaming" a driver means that you have to maintain it and update every time something in the kernel changes.

Windows driver model is so much better. Windows driver model allows you (in theory) to run drivers written 20 years ago.

Linux model doesn't scale because the more drivers the kernel includes, the more work is required to update them when something changes.

Also Linux model doesn't allow reusing unmodified drivers by other operating systems. So developers of other OS's have to duplicate the work that already has been done.

That's what you have to do if you don't upstream. The Linux community is responsible for updating any upstreamed drivers that are affected by code changes that they make.

Disclaimer - I work at ADI.

Cookie consent form literally just has a giant accept button. (Decline is hidden in the text, one level deeper and the button is purposefully made to look like grey text - no clickable button outline).

Props for the driver thing though

file a complaint and make them pay out for it.

Somehow doubt a US company is going to give a f about GDPR

They have a privacy policy for the EU [0].

This seems just plain wrong:

> We process your personal data ... to understand website usage and present you with content and advertising based on your browsing activities and interests, provided you have not opted out of such data processing.

GDPR is clear that the default is opt-in, not opt-out. And yes, the consent popup does not seem compliant to me.

I highly recommend you file a complaint with your DPA [1].

[0] https://www.analog.com/en/about-adi/landing-pages/001/privac...

[1] https://ec.europa.eu/info/law/law-topic/data-protection/refo...

Extra disclaimers apply - I work for ADI, but I am not familiar with the details of GDPR, I don't live in the EU so I'm not covered by the GDPR, nor am I a lawyer, nor do I work on/with the web or compliance team.

I did forward your concern to the folks responsible for the web site and GDPR compliance - which I know they take very seriously.

From a personal opinion standpoint - while I'm sure there is some clarification to be made on the description, things like " ... provided you have not opted out of such data processing." could have been written " ... provided you have opted into such data processing." Neither says what the default is (the way I read it), just that there is an option.

The EU web site that you point to (for making a complaint), has options for "opt-in" and "opt-in less" (their words are "Accept All Cookies" or "Accept Only Essential Cookies"); there is no opt-out there either. Who is to say which are "essential"? On their cookie description page https://ec.europa.eu/info/cookies_en (which is actually pretty good, and more detailed than most), they don't say which are essential and what are not.... so still have no idea what I'm agreeing to...

Not saying that the ADI site is compliant or not (I only know that lots of folks worked on it and spent a lot of time on it), also acknowledge there are always room for improvements - which may or may not happen (Again - not on that team) - only that's its hard to communicate some of these things sometimes...

Thanks for taking the time to respond, I really appreciate it.

By the looks of it, the analytics cookies (eg SC_ANALYTICS_GLOBAL_COOKIE) are not set when not clicking "Accept and proceed". So my issue is only with the wording. In practice it is already opt in, so the text can and should be changed to opt in. The wording opt out does say the default is to accept, and you have to explicitly protest to not accept. (It looks like the wording was already changed?)

Imho, you shouldn't look at it as cookies vs no-cookies. The GDPR is not really about cookies, but about protecting your personal data. You're allowed to set cookies! But if you're processing personal data (such as non-anonymous analytics), you do have to ask permission.

What bothers me the most is the consent modal: I have to click the small blue text "cookie details" (vs the large green "Accept and proceed"), and then click the gray "Decline cookies" to not have my personal data processed and shared.

Why not give visitors 2 options equally?

- "Please use (and share) my personal data to improve this (and other) sites", and

- "No thanks, I'm just browsing"

If you offer those 2 options (and don't try to hide the "no thanks" behind an extra click and a hidden link), I would seriously reconsider consenting. As a sidenote: I would be even more likely to consent if it's not the first thing you force on me. Visiting a press release with a fresh session cookie? Or landing directly on a datasheet from a google search? Why even bother with non-anonymous analytics and ask me for consent? But if I'm clicking through and visiting other pages? Sure, ask to track me. My personal default is to decline, but if you can show mutual benefits I'm way more likely to consent.

As for the comments on the EU website I linked to: I agree. The wording is not clear as to what I'm accepting. As far as I understand:

- "visitor preferences" and "operational cookies" are required

- analytics cookies can be declined (even though they are already anonymous)

- third party cookies are handled separately, when viewing third party content

Following my own advice, I will contact the European Union DPO, and ask them to clarify the consent popup.

This should really be an import addendum to my previous post!: the first step is to contact the site's DPO, and only escalate to your nation's data protection agency when this approach fails.

Thank you again rgetz for taking the time to respond, and for raising this issue internally. It looks like wording of the privacy policy was already changed. I hope the consent popup can also be improved. Your response and the quick update of the privacy policy has greatly improved my opinion of Analog Devices.

I hope they'll try to upstream some of those drivers at least. I've written driver code for some parts before and I was better off not even looking at their code and only going by the datasheet. Except when the code worked around silicon bugs not mentioned in the errata. Fun times.

Or Linux could provide a somewhat stable driver interface.

Most of the drivers in that list are already upstreamed.

Disclaimer - I work at ADI.

Thank you, Analog! I've used a number of these chips -- first-party driver support will also raise the quality of ported drivers to other systems.

So good. Thank you!

Your title is misleading.

They’re not expanding 1000 drivers, but their own Linux distribution with over 1000 drivers, i.e. they’re adding drivers to their own distribution.

> Analog Devices Expands Linux Distribution with Over 1000 Device Drivers to Support the Development of High-Performance Solutions

Isn't their own best commercial interest to get their drivers accepted into the mainline Linux kernel? Why they would just release a random distribution??

Yes - we attempt to push all drivers upstream, but there are many people who want to just try something out, and don't want to compile kernel and userspace from source.

The Kuiper distribution is about convenience for those people who want to be users, not developers.

[Disclaimer - I work at ADI]

I couldn't parse the text. Are (or will) these drivers mainlined?

Yes - the goal is to always upstream every driver (and we do a pretty good job at that). Depending on the lineage of the software (who developed it, what they developed it for) - it may not be possible to meet the kernel coding guidelines - so we don't send those upstream.

Disclaimer - I work at ADI.

They'd rather make NetBSD device drivers to support development - every OS (incl. Haiku etc.) would be able to port them then.

This seems very interesting to me, but is it any kind of big deal?

I use some of these chips, and took a random stab at one of the files to see what it contained, a SPI-bus i/o expander. It looks pretty useful.

I usually write my own drivers, but that gets to be more and more effort if I want to make use of more sophisticated functions, plus I can make mistakes by mis-reading the datasheet or just counting wrong. I might be discouraged from using a function that I don't quite understand, but a pre-written driver might get me past that.

Note that these "drivers" are routines that talk to fairly low level hardware ports of a Linux computer, and I might modify the code for use on a microcontroller without an OS.

Why are you writing your own drivers?

Good question. Maybe I'm unclear on the definition of "driver." I've used the term to describe the code that exercises the functions of the chip but provides human readable function headers. It's usually not ridiculously hard, interpreting things like register bit definitions and timing diagrams. And in the absence of published code, I'd have been on the hook to write it myself anyway. Often, talking to something like an ADC through a SPI port on a microcontroller might be 10 or 20 lines of code.

Reply on news.ycombinator.com