Re: Do I need strong mathematical bases to work in the memory subsystem?
On 10/2/19 9:42 PM, Ruben Safir wrote: General plumbing is not needed, but predictive trees, and crypto certainly do and some hardware problems need calc, or even integration. Those sound like hyper specific things and decidedly specif subsets of the kernel. I believe that there is a LOT of room for kernel development that does not need advanced mathematics. The harder the job, the more math is needed. math ≠ advanced mathematics I concede that quite a bit of math is used in the kernel. But advanced mathematics is a ⊂ of mathematics. Maybe, but I don't think so. And the hardware is getting more exotic. IMHO the eccentricity of the hardware has no direct correlation to the complexity of the device driver controlling said hardware. Driving an external serial attached modem does not require advanced mathematics. Creating a software based modem, be it kernel space and / or user space, does require advanced mathematics. Notice how the simpler hardware requires more math conversely the more complex hardware does more of the work, thus needing simpler drivers. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Remote I/O bus
On Sun, 06 Oct 2019 00:29:18 +0200, Luca Ceresoli said: > BTW I guess having an FPGA external to the SoC connected via SPI or I2C > is not uncommon. Am I wrong? Look at it this way - as a practical matter, if you have an FPGA, it's probably going to be hanging off an SPI, I2C, or PCI. And if you're an SoC, especially at the low end, PCI may be too much silicon to bother with. Oddly enough, I've not seen any FPGA over USB. That of course doesn't mean that some maniac hasn't tried to do it :) pgpy4C0bc1VWU.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Remote I/O bus
Hi Valdis, On 04/10/19 23:51, Valdis Klētnieks wrote: > On Fri, 04 Oct 2019 17:08:30 +0200, Luca Ceresoli said: >> Yes, the read/write helpers are nicely isolated. However this sits in a >> vendor kernel that tends to change a lot from one release to another, so > > I admit having a hard time wrapping my head around "vendor kernel that > changes a lot from one release to another", unless you mean something like > the RedHat Enterprise releases that updates every 2 years, and at that point > you get hit > with a jump of 8 or 10 kernel releases. > > And of course, the right answer is to fix up the driver and upstream it, so > that > in 2022 when your vendor does a new release, the updated driver will already > be > there waiting for you. > > And don't worry about having to do patches to update the driver to a new > kernel > release because APIs change - that's only a problem for out-of-tree drivers. > If it's > in-tree, the person making the API change is supposed to fix your driver for > you. Thanks for your words! I totally agree, and I do upstream my work whenever I can. I also use the same arguments you used to convince other people to do so. Weird enough, the whole idea of an io-over-spi bridge came exactly because I want my work to be as close to upstream as possible -- even the non-upstreamable hacks I need in embedded products. All the drivers I'm going to use in the FPGA are platform drivers, and there is no way my-own-io-over-spi bus support in those drivers will ever be mainlined. That's why I came up with the idea of keeping those drivers as platform drivers (the devices after all expose a real I/O bus, not SPI) and have the io-over-spi logic in a "bridge" driver (which is what the microprocessor in the FPGA does). This would allow to use *exactly* the mainlined driver when one is in mainline, without any change. But it looks like mine was not the right idea. BTW I guess having an FPGA external to the SoC connected via SPI or I2C is not uncommon. Am I wrong? -- Luca ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
suspend mode
Hi all, I have a HWMON driver which is using simple pm options. So, I have a suspend() and resume() where I try to lock a mutex before suspending/resuming. This mutex is shared with the read/write path of the hwmon attributes. I also have a flag which is set when suspend() is done so that, if someone tries to read some attribute, will get an error since doing a read/write on the device bus will wake it up. Im starting to think that this does not make any sense. Is there any way that a userland process runs during suspend? As I understand, all tasks should be frozen before starting to suspend the HW devices. Is this right? Furthermore, now that I think about this, trying to lock the mutex on the PM callbacks seems dangerous since it can lead to deadlock (if some frozen task is helding the lock?). However, I definitely saw drivers trying to lock shared mutexes in the PM callbacks. Aren't these callbacks atomic? Is there any scenario where it makes to sense to care about concurrency in these functions? Thanks for the help! - Nuno Sá ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
