James Bottomley wrote:
Hi All,
We've got to the point where there are simply too many embedded
architectures to invite all the arch maintainers to the kernel summit.
So, this year, we thought we'd do embedded via topic driven invitations
instead. So what we're looking for is a proposal
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
We've got to the point where there are simply too many embedded
architectures to invite all the arch maintainers to the kernel summit.
So, this year, we thought we'd do embedded via topic driven invitations
instead.
On Tue, Jun 16, 2009 at 04:06:48AM -0400, Mike Frysinger wrote:
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
We've got to the point where there are simply too many embedded
architectures to invite all the arch maintainers to the kernel summit.
So, this year,
Marco wrote:
There's the checksum, but the most important feature of this fs is the
write protection. The page table entries that map the
backing-store RAM are normally marked read-only. Write operations into
the filesystem temporarily mark the affected pages as writeable, the
write operation
On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysingervapier@gmail.com wrote:
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
Another issue that affects embedded architectures is drivers initialization
order. There are a lot of cases when you need the drivers to be
Grant Likely wrote:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With this approach, a driver can use a
bus_register_notifier() variant
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Grant Likely wrote:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With
Grant Likely wrote:
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
That would work for some cases, but a lot of cases the problem is not
module init
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokierja...@shareable.org wrote:
Grant Likely wrote:
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
That would work
I know. It wasn't my intention to introduce it but as I said in my first
patch I've done a porting of this code from 2.6.10 and to remove it I
need time to analyze well the code to avoid deadlock and so on. If
someone would like to help me I'd really appreciate it. However I see
the use of
+/* init_mm.page_table_lock must be held before calling! */
+static void pram_page_writeable(unsigned long addr, int rw)
+{
+ pgd_t *pgdp;
+ pud_t *pudp;
+ pmd_t *pmdp;
+ pte_t *ptep;
+
+ pgdp = pgd_offset_k(addr);
+ if (!pgd_none(*pgdp)) {
+
Ralf Baechle wrote:
I2C or similar busses can be a particularly annoying if they contain
essential configuration information such as memory size which is needed
long before anything else. So for far a common solution is that platforms
are carrying a private (aka redundant, ugly) early-i2c
12 matches
Mail list logo
